[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin upgrade output message i18n issue

From: Dongsheng Song <dongsheng.song_at_gmail.com>
Date: Fri, 24 May 2013 00:52:00 +0800

On Thu, May 23, 2013 at 11:29 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Dongsheng Song <dongsheng.song_at_gmail.com> writes:
>
>> Even ALL the translations are UTF-8, GETTEXT(3) still return the
>> string encoded by the ***current locale's codeset***.
>>
>> Here is sniped from the GETTEXT(3) man pages:
>>
>> In both cases, the functions also use the LC_CTYPE locale facet in
>> order to convert the translated message from the translator's
>> codeset to the ***current locale's codeset***, unless overridden by a
>> prior call to the bind_textdomain_codeset function.
>
> We do call bind_textdomain_codeset if it is available so we should be
> getting UTF8 translations.
>

For non-autotools system, e.g. Windows, user may not define
HAVE_BIND_TEXTDOMAIN_CODESET.

>> So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
>> coded, it it encoded to the ***current locale's codeset***.
>>
>> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
>> messages, write it ***AS IS***, since GETTEXT(3) already do the
>> correct conversion for us.
>
> It's not that simple. We would have to change almost every error:
>
> svn_error_createf(SVN_ERR_BAD_RELATIVE_PATH, NULL, \
> _("Path '%s' must be an immediate child of " \
> "the directory '%s'"), path, relative_to_dir)
>
> and convert variable like 'path' and 'relative_to_dir' from UTF8 to
> native before combining with the native translation.
>
> What would be the gain for all that work? The only problem at present
> is a system that doesn't have bind_textdomain_codeset but where gettext
> returns the current locale encoding having converted it from the UTF8 in
> the file. Are there any such systems? What about the opposite problem:
> systems that don't have bind_textdomain_codeset and where gettext
> returns UTF8 because that is the encoding in the file. Are there any
> systems like that?
>

Or we should call bind_textdomain_codeset as possible, and warn the
user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:

#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
  bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
#else
  fprintf(sdterr, "bind_textdomain_codeset not available, or not
configured. Non-UTF8 locales maybe see garbled output.\n");
#endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
Received on 2013-05-23 18:52:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.