>> gettext handles that. It will reencode the strings to the user's
>> locale (or a forced locale supplied by the program).
>
>
> But does it do that everywhere? Or rather, does that mean you need
> iconv on Windows in order to compile gettext? Seems like a bit of
> overkill, given that we already have apr_iconv...
>
> Anyway, this is a pretty problem, and obviously adding I18N to the SVN
> sources involves more than just adding _() in the right places. So
> instead of a bunch of _()-ing patches, I'd like to see a document
> outlining the plan of attack and covering all the possible corner
> cases. We've had so many problems with incorrect encoding conversions
> in our code that we have to either do this right the first time, or
> not do it at all.
Such a document can only be made after the relevant issues have been
discussed, and a consensus has been reached. I've pointed all the issues
I saw about implementing i18n. However the encoding issue is something
that we should give more thought.
You say that strings in Subversion are in UTF-8. That a function will
convert them to the current locale. I can see that's true for errors,
and for some other things which call svn_cmdline_cstring_from_utf8().
But what about all those simple printf's and fprintf's? They should
probably replaced by some kind of svn_cmdline_printf function that takes
UTF8 strings. After doing this we can call bind_textdomain_codeset(...,
"UTF-8). After doing that gettext will feed only UTF-8 to subversion, no
matter which is the current stdout encoding.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 14 22:59:35 2004