Subject: Re: [boost] Fw: [locale] Formal review of Boost.Locale library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-15 10:41:46
> > 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.
> 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.
I would address you to this answer as well:
I hand't remembered all the reasons at 1AM. Especially
all encoding and charset related issues
There are quite a lot of good reasons to limit yourself
to ASCII. I understand that it may be not always
"nice" but it is the best guideline for development
of application for different cultures.
One more important thing is when you have a small customer
and do not have enough resources to supports
its languages directly, the customer itself
can easily localize its application. Given
good program like KDE's "lokalize" it would
take him from several hours to translate
all strings in a small application.
But if the original strings are not English
this would never happen.
The methodology is very important as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk