Re: I18N for PEAR (before Language class for PEAR?)

I'm becoming very interested in multi-language frameworks for web applications (as I should be, the web is supposed to be universal :)). Perhaps my question is a bit off-topic, but aside from handling the smaller elements on a site (ie. gettext et al) and the images (using /pix/$lang/image.png), what is an effective framework for handling multi-language content? For example, say a products table had these fields: id, title, price, description Is it more effective to create a products_en, products_fr, etc. table or to duplicate just the necessary fields, ie. id, title_en, title_fr, price, description_en, description_fr Or is there any other way of handling this? And what would be the issues involved in managing duplicate tables, etc.? Also, are there any good articles on things like PHP's multi-byte character support? Thanks, Lux On Mon, 2002-02-11 at 12:07, Alex Black wrote: > > Hi Alex, > > > > Can you help? This is a thread on the PEAR-DEV mailing list and I emailed > > the poster off-list to tell him about Binarycloud's support > > hi Peter and Wolfram, > > wolfram, peter asked me to give you a bit of info about binarycloud's > localization capabilities... here goes: > > >>> 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. > > Yes. We currently have an extensive XML repository of ISO locale > information: countries, languages (w/charset), currencies, etc etc. We're > turning those files into metabase XML database schema files so we can do > queries on the lists for use within applications. We will also ship default > "entity" (data i/o control or "business object") classes which developers > can use to get lists, etc from the localization tables in the DB. > > >> 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 > > Browsing the source will not do you much good, as the format will be > changing quite significantly in the near future. (Couple other things to do, > then the final build) > > >> 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 :-) ) > > It is a performance issue. Thus our decision to put locale information into > a database. > > >> 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. > > It is :) > We wanted to use XML first to get all the data into a malleable state. I > thought we might end up putting it all in a DB or building lists of > countries, languages, etc at build time. Database is obviously better > because of query support. > > >> 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. > > We decided against _any_ runtime string lookup, as it unnecessarily > sacrifices peroformance (i.e. GNU gettext). Instead, we use XML string > repositories and "keys" in source code and elsewhere to build > language-specific distros from a master source tree. However, that requires > a make system. (we've built one, which will likely be submitted to PEAR) > > Which means: > -We can check that all translations exist _before_ runtime > -We can key in 10 or 10,000 strings, with _zero_ runtime overhead > > both of these are good :) > > >> 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. > > Yep, that's what we do: we have a locale configuation file which allows > developers to explicitly specify what locales are valid for a given project, > which also controls how many language specific trees are built by the make > system. That way you can support english and german or english and every > other language :) > > >> 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 :-) > > It is extremely important. I gave it a lot of thought, and decided that the > best (and highest performance) method was to preprocess files. It's clean > and simple. > > We will probably build a developer app that allows translators to enter > translations into a database, and export language packs from the DB into the > source tree. First thing's first, though :) > > best, > > _alex > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > >