Boost logo

Boost :

Subject: Re: [boost] [locale] Formal review of Boost.Locale library EXTENDED
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-04-19 03:17:39


On Tue, Apr 19, 2011 at 2:10 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 4/18/2011 9:53 AM, Paul A. Bristow wrote:
>
>> PS Without wishing to sound too British - "If the natives don't
>> understand,
>> just shout louder.",
>
> Now I know why Gandhi fought so hard for an independent country. Yes, I
> understand, then above is British humour.

+1
Funny but a little arrogant.

>
>> I have little sympathy with the view expressed that no knowledge of
>> English
>> should be required.
>> (Is this the cost of Japanese failure in the 80's to succeed in their
>> ambition to dominate hardware and software with a world-beating language
>> in
>> Japanese?)
>
> What language was that ?
>
>>
>> C++ just is a language in English, so you must surely expect to have some
>> rudimentary knowledge of this useful language.
>
> The amount of rudimentary knowledge of English necessay to use C++ keywords
> and C++ standard library classes is so incredibly little compared to an
> actual knowledge of English grammar, that I doubt whether a knowledge of
> English is really necessary in any way in order to program in C++.

I'm not a native English speaker and it took me nearly a decade
to learn English in such a way that I was able to communicate
more elaborate "thoughts" than "Hello", "My name is X Y", I'm N year old" :)
and it still could be much better.

But, I accept English as the necessary and very useful tool for my work
in IT/CS. (just as most medical doctors accept the use of Latin, I guess)
Most of the documentation and basically every mainstream programming
language uses English so knowing the language at least at some level
is a "must" here.

>
> My personal objection to Gnu gettext and its English bias has nothing to do
> with any desire myself to use a language other than English in order to
> communicate, since English ( or perhaps Americanese ) is the language of the
> country in which I was born, but nearly everything to do with my sense of
> the problems of translating even computer program phraseology from one
> language to another without complicating things by having to put some other
> language, even a very popular one, in the middle.
>
> Was that a single sentence ? I wonder if it can be translated to Japanese ?

These are all valid points Speaking in a particular language means
to be thinking in a certain way and many things can be lost in the translation.
But I don't see above any solutions to the actual problem.

>From how I see it there are several ways to handle this:

1) Stick to English phrases
(-) Requires good knowledge of the English language
(+) Easy to find someone to translate to language Y
(+) Portable
(+) Lots of mature l10n libraries work this way
(+) Works (for English speakers) even if the translation fails

2) Use English identifier strings (as Peter Dimov suggested)
(-) Still requires some English
(-) Hard to keep unique in large applications
(-) Doesn't look good if the translation fails for some reason
(+) Requires "less" English

3) Use the u"" U"" literals
(-) Current support by the compilers
(-) Requires the u/U/... prefix
(+) Will be portable in the future
(+) Does not require English

4) Use wchar_t and the L"" prefix literals
(-) Non-portable and platform dependent
(-) Requires the L prefix
(+) Works if you are limited to a single platform
(+) Does not require English

5) use char with some GUID literals/hashes
(-) Completely unusable if the translation fails
(-) Takes a lot of using to (easier for GIT users :))
(-) Requires a GUID/hash generator
(+) Portable
(+) Does not require English

6) keep in original language but transliterate to Latin characters [a-z0-9]
(-) Requires picking a good transliteration scheme
(-) Hard to read in the code
(-) Pretty unusable if the translation fails
(+) Does not require the use of English
(+) Portable

Take your pick :-)

Matus


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk