Dongsheng Song <dongsheng.s...@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.
> 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?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
