On Tue, Apr 19, 2011 at 4:17 PM, Matus Chochlik <chochlik@gmail.com> wrote:
On Tue, Apr 19, 2011 at 2:10 AM, Edward Diener <eldiener@tropicsoft.com> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
char is not portable too. It can be any encodings. -- Ryou Ezoe