RE: [PEAR-DEV] [PEPr] Comment on Internationalisation::Maketext

From: Date: Wed, 07 Apr 2004 17:23:24 +0000
Subject: RE: [PEAR-DEV] [PEPr] Comment on Internationalisation::Maketext
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27135@lists.php.net to get a copy of this message
However, I would think that in most cases the subject of the numeral classifier would not be one of the variables. I could see this being a problem if the sentence to translate would be something like : "You have (number) (noun)" - where the form of the number would be different if the (noun) were a pencil or a dog, or even the same object in a different shape, such as a rug that was rolled up as opposed to laid flat. To write a function to figure out what classifier group (noun) is in in order to modify (number) given absolutely no contextual constraints would be nearly impossible, however, a more reasonable assumption for a sentance to be translated in a computer program (which tend to have highly contextually limited domains) would be : "You have (number) message(s)" - in which case the translator would know the semantic class and could add the proper prefix modifier to the number accordingly (in japanese, at least). That is completely do-able, and often neccesary, and possibly easier to do with Maketext than previous tools. The point of this library is not to be able to translate anything in any possible context, its to make it easier to do some more difficult things in limited contexts that are normal for computer programs that other tools dont easily allow for. Jean-Michels base argument seems to be that the usefulness of the library degrades the more contextually arbitrary the sentence becomes : "You have (number) message(s)" "(subject) (have/has) (number) message(s)" "(subject) (verb) (number) (noun)" "Subject Verb Object" "Subject Predicate" Of course MakeText will not be useful for translations of any but the top sentence, but niether are they likely to be found in a normal computer program, especially a PHP one. If you want to do full semantic and morphological breakdowns, PHP is not what you should be programming in anyhow. The bottom line seems to be that this tool is simply more flexible than Gettext, so how does that possibly hurt things? Also, just as an aside for Jean-Michel - English is not a simple language. It is uninflected, but it has a ridiculous number of seemingly arbitrary rules and grammatical constraints, a comparitively enormous vocabulary, and a looser word order. I know a great number of people that found English very difficult to pick up compared to other, more gramatically ruled languages - plus, that arbitrariness makes it particularly difficult for computer work on it, given the logical nature of computing. I am looking forward to trying this out in an upcoming project. Thanks, Scott -----Original Message----- From: Ignatius Reilly [mailto:ignatius.reilly@free.fr] Sent: Wednesday, April 07, 2004 12:29 AM To: pear-dev@lists.php.net Subject: Re: [PEAR-DEV] [PEPr] Comment on Internationalisation::Maketext I have not yet dealt with 33 languages under my belt, but I have Japanese. I would concur with Jean-Michel's strong statement. Just to give a flavour of Japanese language quirks: the numeral depends on the shape of the counted object (elongated, flat, bulky, cattle, two-legged animal, etc.) The list uncannily resembles that Chinese encyclopedia quoted by J.L. Borges. _________________________ "Jean-Michel Poure" <jm@poure.com> wrote in message news:200404070005.30303.jm@poure.com... > > first of all, let me point out, that there is nothing forcing you to use > > this module. Are you suggesting this module should not make it into > > PEAR, because it is not useful? > > Yes, just a suggestion. > > As explained in your article, English is a very simple language. In comparison > most other languages are very complex. > > Basically, your class is supposed to allow a better coding than Gettext simple > %s and %d (with support of accusative and so on). But this simply does not > work in many languages. Even if you code cases (accusative), numbers > (including zero), MANY sentences will break. > > The only known solution is to write complete sentences > and test them within PHP: > > "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". > > 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. > > 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. > > 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. I will send you privately the address of > my site so that you can check yourself. > > Cheers, > Jean-Michel -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

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