RE: [PEAR-DEV] [PEPr] Comment on Internationalisation::Maketext
| From: | Scott Chacon | 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