Re: [PEPr] Comment on Internationalisation::Maketext

From: Date: Thu, 08 Apr 2004 16:59:49 +0000
Subject: Re: [PEPr] Comment on Internationalisation::Maketext
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27202@lists.php.net to get a copy of this message
Hi Jean-Michel > From: Jean-Michel POURE <jm@poure.com> > > 1) Maintenance nightmare > > > "Ich bin der Besitzer von [quant,_1,grünen Kuh,grünen > > Kühen] [quantf,_2,und %s grünen Flagge,und %s grünen > > Flaggen,besitze aber keine grüne Flagge]." > > > > "Je suis le propriétaire [quantf,_1,de %s vache vert,des > > %s vaches vertes] [quantf,_2,et de %s drapeau vert,et > > des %s drapeaux vertes,mais je n'ais pas un drapeau > > vert]." > > In your example, it seems clear that a programmer should > know both English, French and German to be able to code > sentences (to be able to detect accusative for example or > even code plural). NO, this is where you get it wrong! Not the programmer will code Maketext strings, the translator will do this. The programmer's job is just to supply the translator with Maketext functions (quant,numerate,quantf,...) which obey the rules for the language in question. Let's take an example of the translation process - English Original: "[quant,_1,day]" # Default: append "s" - Translation for German requested - German Translator: "[quant,_1,Tag,Tage]" - Translation for Hebrew requested - Hebrew Translator comes back, says he cannot translate this in proper Hebrew grammer, because he needs a case for dual. Talks to programmer about the exact rules. - Programmer agrees with Translator on special quant() API for Hebrew (1st argument singular, 2nd dual, 3rd plural). - Programmer codes the Locale_Maketext_iw_IL::quant() - Hebrew translator: "[quant,_1,yom,yamin,yomaim]." > 4) Free software > > Free Software is designed for the international masses. > The power of Gettext is to leave end-users and translators > the choice to translate complete sentences as they wish. > > Maketext is a valuable attempt to correct Plural Gettext > historical mistakes. But it still goes in the wrong > direction, because it does leave humans the choice to > translate as they whish. That is an invalid statement. Each translator can translate EXACTLY the way he wishes to do. I think that you have the conception that the translator will have to use the same functions in the same places within a sentence as the original string. Well this is wrong. He can choose to use another function instead, or even not use a function at all if the target language doesn't need it. He can use whatever he needs to produce the text in correct grammar for his language. Just look at my examples again: "I am the owner of [quant,_1,green cow,green cows] [quantf,_2,and %s green flag,and %s green flags,but I do not own a green flag]." "Je suis le propriétaire [quantf,_1,de %s vache vert,des %s vaches vertes] [quantf,_2,et de %s drapeau vert,et des %s drapeaux vertes,mais je n'ais pas un drapeau vert]." Did you notice, to produce the french version I used a different method (quantf vs quant) because of the "de|des". Looking at this now, I am actually not sure now if this was correct French, would you say ..proprietere des 2 vaches, or ..proprietere de 2 vaches? I'm not sure but it doesn't matter, because this will NOT be MY problem, it's the translator's and he will know best. > 3) Disclaimer > At a minimum, I am asking for a disclaimer about this package. i.e.: > > a) MakeText belongs to the domain of language automation and automatic > translation. Maketext is by no means about automatic translation! You got this completely wrong. Sorry. > It is not a localisation package and cannot be defined as > such. Do not use I10N or I18N prefix which could lead > programmers in error. Why??? > b) Maketext should be used by linguist who have a > knowledge of the source/target languages that they are > using. Wrong. It should be used by translators, and extended by programmers, with translators specifying the requirements. > For each new language addition, it is very likely that the > programmer will need to modify source sentences and code > them again. Therefore, this package should be considered > experimental and should not be used in production where > time and money matters. Wrong. The programmer will only need to extend Maketext. No source sentences will need to be changed. > b) In the worst case scenarios, people should be aware > that MakeText sentences written in English may simply not > be translatable in some languages. Also wrong, see above. Sorry, I cannot accept anything from this disclaimer. And for now, I will not take the time to discuss this any further. Please check the comment from Scott Chacon, he basically got the right idea about Maketext. I do see something positive in this discussion though, it will provide me with good snippets for the documenation :-) > I was thinking of Hungarian. Someone on the list took the > example of Japanese. There are many other examples and > GNU/Linux covers the whole world. I think what Scott Chacon said also covers the Japanese "problem": there isn't one. The noun is usually known in a sentence that a computer program spits out. Hans

« previous php.pear.dev (#27202) next »