Re: [PEPr] Comment on Internationalisation::Maketext

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi Jean-Michel Hi Hans, > - 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]." You will not be able to add some African languages. In some African languages, the word "day" can have different meanings in "summer" and "winter". Therefore, you may need more than quantifiers to translate the word "day". Just an example, the world of languages is very-very-very diverse. A language is a system of signs. The signs need to be expressed (at least) in a complete sentence/paragraph with a SINGLE meaning, otherwise the translation cannot be garanted. Conversly, a single word can have SEVERAL meanings according to the context. For this reason, I am opposed to the idea of "coding" source/target sentences, because coding offers, by definition, several meanings. > 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. The translator will be coding the target sentence. I hope that he can calculate all combinations mentaly. In a factorial environment, there is no possibility to garantee a translation. With your respect, I would rather call MakeText a "language automation" class as it can save time, but not garantee quality, portability and meaning. > "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]." Why do you try to code human languages? Your coding depends (obviously) on the English. Your example may not be translatable in two kinds of languages: - - agregative languages (i.e. the word "owner" would be sticked with "green" and "cow"). Something like "Green12CowOwner GreenFlagNoOwner". And do not answer, "The programmer can code this" and "The translator can code that". Sometimes, the words depend on the context, therefore there are too many combinations to garantee anything. Programmer do not have time reviewing large projects. A nightmare. - - languages where nouns depends on the number (i.e. the word "owner" can depend on the number of things you own.) In short, your coding approach of languages is the mental abstraction of a European language native speaker. It does not fit the vast majority of languages, which offers a real potential of development for free software. By 2040, India will have 1.600 million inhabitants. There are hundreds of languages and dialects in India. Can you garantee that the source coding of a sentence fits all Indian languages? Answer : no. > 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. The problem is : - - the maintenance of the source (you may need to modify source text to reflect the addition of languages) = time and money - - the complexity of coding in the translation pairs (factorial problem. No garantee that you can code source/target right). = false translations > > 3) Disclaimer > > 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. I confirm. The encoded translation is processed automatically by PHP and results in a sentence. Because of the number of cases/situations/combinations, it may result in false translations. > > 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. I confirm. Apparently, you are aware of the problem. Can you confirm that translators need to specify requirements for each additional language. So, whenever I am adding a language, I need to review all source strings. Whaaoooooo ! Boooommmmm. > > 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. Sorry, MakeText alone cannot be used to "abstract" the complexity of languages. This is an abstraction dream. In programming, you can move the complexity of code to libraries. But you cannot move the complexity of Hindi to any extended Maketext class. > > 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. I confirm, see below. > 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. You are pointing out the real problem of MakeText: MakeText really answers a need for abstraction, because programmers would love to be able to code human sentences to fasten development. Therefore, programmers will probably love MakeText. As a result, if MakeText happens to be publised into PEAR without strong disclaimer, thousands of people will be using the class, without really understanding the consequences: - - need to review all string whenever adding a new languages, - - lack or reliability of translations, - - complexity of coding leading to factorial problems, - - ethnocentric sentences designed by/for European speakers, - - translators may need to be able to code, - - etc... Cheers, Jean-Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAda/fextoHHj2YFMRAhsQAJ99Pk27C7MSAhPhIxA1V4ikSLXd3ACgsvpn DCFKopYP14QwDQECip+C5yU= =Daxm -----END PGP SIGNATURE-----