Nicolás Lichtmaier wrote:
>
>>> I do not know which side of the discussion this effect will support
>>> but it is worth noting that the message text can differ not only
>>> because of language, but also because of encoding. For instance,
>>> using Polish, Windows machines encode text using win-1250 encoding
>>> while others use iso-8859-2. Therefore in case server formats
>>> message, it should get from the client encoding it needs, mark the
>>> encoding it used or use always unicode and force clients to convert
>>> from unicode.
>>>
>>>
>> All our .po have to be in UTF-8 regardless server-side L10N, because
>> a) we'll use the same .po files on all ploatforms, b) LC_MESSAGES can
>> be different from LC_CTYPE, and c) the Subversion libraries require
>> UTF-8 anyway and expect the client to convert to the native encoding
>> (this is what the command-line client and other cmdline tools
>> currently do).
>
>
>
> 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.
-- Brane
---------------------------------------------------------------------
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:46:18 2004