Re: I18N for PEAR (before Language class for PEAR?)
| From: | Wolfram Kriesing | Date: | Mon, 11 Feb 2002 11:08:34 +0000 |
| Subject: | Re: I18N for PEAR (before Language class for PEAR?) | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-4588@lists.php.net to get a copy of this message | ||
(can someone please forward that, since my mails are always rejected
by the list :-( )
On Sunday 10 February 2002 19:52, you wrote:
> Before you get too embroiled in writing all this may I suggest that
> you have a look at Binarycloud's Locale handling and how they do
> it? Full specs/code can be found at
> <http://binarycloud.tigris.org>. They are also building
> a
> repository of international telephone, date, postcode etc formats
> which you may be able to use.
can you please point me to the source where i can see how the locale
stuff is embedded in the BC structure
http://binarycloud.tigris.org/source/browse/binarycloud/r2/...????
and how the stuff discussed on the list is realized to see if/how it
fits in PEAR
There are a lot of defines (the iso codes) for this I18N stuff, how
can we best do that?
1.
we can define all the iso-codes in a file, like: array(
'en'=>'english', ... ) and array('en_US'=>'american
english', ...),
etc.
This will make the php-code quite big. And not all variables are
needed all the time. This might be a performance issue, or not?
(Where are the PHP-core experts :-) )
2.
we can put it in an XML file as BC does it.
This will require parsing the XML file everytime you need a locale
which in PHP would be quite costly, since every request to a site
might need some locale stuff, which would mean reading the file for
every request. Seems even worse, at first sight.
3.
let the user define the method how PEAR shall do that, either read it
from a file, DB, array, ... .
This makes programming all that a little more complex.
But seems more customizable on first sight.
And if the user knows he will only have his page in english and
spanish, then he will only need 2 iso-codes for the language
('en','es') and the array (if he chooses to read it from one) will be
tiny and the application faster, than one that reads all the locales.
This might not be the most important issue on the I18N stuff, but it
just came to my mind :-)
I will give it a thought too :-)
--
Wolfram
... translating template system ...
http://wolfram.kriesing.de/SimpleTemplate