Re: [PEPr] Comment on Internationalisation::Maketext

Hi Jean-Michel, I think we can settle this now. I agree with you, that the description for Maketext needs to be more precise. I was a little too quick with the proposal, you probably know what it's like, the code is written and you'd like to get your module seen as soon as possible and thus pay too little attention to your documentation. I will fix this before the module goes into voting stage. > From: Jean-Michel POURE <jm@poure.com> > > > The only person who reviewed all source strings was the > > translator, and that is his job, or should he GUESS > > translations? (sorry, sarcasm, i know...) > > This is sarcasm, I am rather crying when thinking of these > poor people reviewing Maketext source stings in large > project. But a translator DOES need to look at all source strings of the language he intends to use as source for hist translation to the target language. Surely you must acknowledge this. > In large projects, we cannot ask each translator to review > all source strings, because most of us work on their free > time. "Free time" does not mean "Loose time". I simply don't see how your translators can translate anything without knowing what to translate. This is ridicuolous. Maybe you think he needs to look at ALL of the other translations? Well, this is not the case. He only needs to review the source language that he bases his translation on (usually English). > After each modification of sources, all translators will > need to provide updates. Let's take an example with 30 > languages: > > 1) Hebrew translator reviews all source strings and > modifies some of them. > 2) The other 29 translators are obliged to provide > updates. During updating, some of them might detect new > coding requirements for source strings. NO, I don't understand how you get the idea that this is necessary. I can assure you that this WON'T EVER be the case. Clearly, you must misunderstand something about how to use Maketext within a project, but I don't really understand what it is. > 3) As a result, everyone goes on with a new series of > updates... > > Because of the diversity of languages, you will not be > able to stop people from modifying the source strings. It > will result in "non-ending" loops. But nobody modifies source strings! A translator will only add new source strings for his language! I just don't see how you get the idea that source strings in one language, which is finished in the project, need any modification when a new language is added. This usually just means adding a new .po file, or adding new strings in the DB for that language. Additionally, if current Maketext functions are not enough for that language, it means extending Maketext for that language. No other modifications are needed. Also, if a maintainer of an existing translation whishes to modify his translation this will only ever affect his own message resources. Again, with the exception that if he decides he needs some smarter Maketext functionality, he can ask the programmer to provide that functionality in the extended Maketext class for his language. Other languages use their own Maketext class, or the default one and will thus not be affected by such changes. You see, the Locale_Maketext_iw_IL::quant() function will solely be used for the iw_IL messages. Other .po files will use other quant() functions which still work exactly the same as they did before Locale_Maketext_iw_IL::quant() was added. One more thing. I found, that within a project, the number of strings that actually require Maketext functions is usually very small. http://www.sixti.de/ for example, is completely built with Locale::Maketext (the Perl module). The site has 819 msgids in the .po for any language. From these 819 entries, only 8 entries make use of Maketext functions!! www.sixti.de was translated to Italian two months ago. This involved NEITHER any programming NOR modifications of .po files for the other languages. (Yes, I know Italian is simple, but it doesn't matter how difficult a language is, this scenario would still be valid for complicated languages, with the excepction of language-level, spezialized Maketext functions which may need to be added by the programmer) > For example, in the description of the package, you write: > > "Maketext overcomes the shortcomings of gettext with > respect to grammatical differences among languages (1). > Maketext is extensible and works nicely together with > PHP's gettext extension such that you can still use > gettext's features to store, manage, and retreive text > resources. Besides, it is simple to extend Maketext to use > other sources of translated resources such as a DB for > example (2)." > > I agree with (2) completely, but I laugh at the first > statement (1), which is vague and incomplete. Agreed (1) is really too vague. I am going to supply a better description. As I said before, I should have enough text by now, resulting from this discussion with you, to do this. Hans