Re: [PEPr] Comment on Internationalisation::Maketext

Hi Jean-Michel, I am still not convinced. I have not done projects in as many languages as you have, only five languages (de,en,fr,it,nl). But there, I did not have any problems and have gotten very positive feedback from both the screendesigners (who did the initial German version) and from the translators. Even if I had to code something special for a difficult language, I'd be happy that I have a place (in OO Terms) where this kind of logic belongs to (an extended Maketext class).

"I am the owner of 2 green cows and 3 green flags". "I am the owner of 2 green cows but I do not own a green flags".

This sentence is (in at least English, German, French - I don't speak more languages) easily doable, without even having to extend Maketext: "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]." "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]." (French is not exactly one of my strengths :-) surely you will be able to correct this example.) OK, it's a little long and there is some redundancy, but it is still doable within one single .po entry. And thus, if it needs to be changed, it will be changed in only one place. Oh, and one thing we shouldn't forget: In my own experience such complicated sentences are rare in computer programs!

If an Arabic does not like the word 'your' (as explained in your article) it is his translator choice to forget the word "your" in Arabic.

This one I do not get. What has "your" to do with quantification, numeration, gender-dependent rules, etc? Leaving something away in a sentence because the term doesn't exist in the language is one and the same "translator issue" in either gettext or Maketext, which should not need any "programming" at all. Maybe I'm overlooking something here, please explain it to me.

In short, your class was designed with a programmer view willing to reduce the number of strings. But to be honest, it has some hidden buffer ***overflow***, especially for projects including many languages.

As I said above, it's not just about reducing strings. It also gives you a means of separating grammatical logic from other logic. You are free to make a special Maketext function for one single sentence and there is a place for the logic of that function: in your Locale_Maketext_xx_YY (I am intending to rename Maketext to Locale_Maketext, when I get the time to code again, instead of argue :-))

After managing projects in 40 languages, I came to the conclusion that languages are as diverse as Men. You cannot "code" sentences using a computer language, be it PHP or some class.

So you say that sentences can't be "coded" in some cases. Well, I can't think of any (I am not a linguist) but I am willing to believe this. Nevertheless, should this insight mean that for all the many other cases, where Maketext is perfectly suited, I should avoid the simple, elegant solution that Maketext provides? After all, if it can not be done in Maketext, Maketext does not prevent you from doing something the "old-fashioned" way.

I will send you privately the address of my site so that you can check yourself.

Yes, please send me the link. In another post you suggested a warning to users in the documentation. OK, just contribute this and I will review it for inclusion. Hans