Re: [PEPr] Comment on Internationalisation::Maketext

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Hans, I know many programmers who would like to be able to code human sentences. They would probably give positive feedback. Why not build a babylon tower? Here is a summary of my point of view: 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). Please understand that with more than 20 languages, it ends up in a maintenance nightmare. IMHO, each sentence should be coded in 'plain' Gettext, without using plural coding. The role of the translator is to adapt the sentence. The use of fuzzy database in PO software can help the translator maintain coherence in very similar sentences. 2) Fuzzy results Languages can be defined as a system of signs, which are so complex that they are tightly linked to the human intelligence. You can only speak if you are intelligent and conversly intelligence can be defined by the notion of language. The same goes for translation. As a consequence, any attempt to mimic human languages is an attempt to build a conscious software. Suffice not to say that a simple coding like : > "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]." is a "joke" in the domain of translation for a linguist. It is like coding 'if/then/case of/etc..." to mimic human sentences. It can only end-up with fuzzy wordings or even false results. Again, you will be able to manage 3 or 4 translation pairs (English/German, English/French, English/Spanish, etc...) including close languages, but not 30 language pairs. It is a clear problem in the case of PHP which is truely international. 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. 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. b) Maketext should be used by linguist who have a knowledge of the source/target languages that they are using. 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. b) In the worst case scenarios, people should be aware that MakeText sentences written in English may simply not be translatable in some languages. 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. 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. With MakeText, programmers need to be linguists, and conversly translators need to be able to code. A nightmare. Cheers, Jean-Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdSEEextoHHj2YFMRAj3HAKCwymd3np1EgnAG8xZ8GBukO4cTxQCgnEhF fZqqQZhUOdHxIxcVbPyTDuk= =qCDx -----END PGP SIGNATURE-----