Boost logo

Boost :

Subject: Re: [boost] Fw: [locale] Formal review of Boost.Locale library
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-04-15 04:14:29

>> The point if you use Japanese - inline then you don't need to translate
>> strings, and if you do translate then write source code with ASCII strings
>> that would work with any encoding and would be understandable for any
>> software)
>> This is how all translation systems I know work.
>> Having original text strings in Japanese and translating
>> them to French or Hebrew is very-very-bad idea as it
>> is much simpler to find somebody to be able to translate
>> the text from English to Hebrew then from Japanese to Hebrew.
> This is just plain silly. Telling someone who uses language X that in order
> to translate their code to language Y they need to first translate their
> code to English and then translate English to language Y, and that this is
> somehow superior, is just inane reasoning. Supporting such reasoning by
> saying that "everyone" does it that way is equally inane for many obvious
> reasons. It is much better to admit that the "translate" part of a locale
> library may be flawed, or limited, than to have to justify such illogical
> nonsense.

This is, however, basically the only reasonable thing to do, with the
current state of things
and the whole string literal encoding mess in C++. One of the
alternatives that people
who don't speak English can use, is to transliterate the strings to
plain Latin alphabet
(7-bit ASCII) i.e. for example instead of doing
translate( "Пожалуйста") you do translate("pa-zhal-sta");

> I am not saying that your following the way that gnu Gettext does
> translation is not understandable, in that you chose to follow a popular way
> ot doing something. But I am saying that trying to justify it in the
> illogical way that you do, given a perfectly reasonable objection, is
> completely wrong.

What other options do you see, the support for UTF-8 character
literals being as it is ?



Boost list run by bdawes at, gregod at, cpdaniel at, john at