My site is pretty small and will have low traffic (in an Administrative area of an Intranet) but must be in a minimum of English, Japanese, and Korean.
Respectfully, Ligaya Turmelle
Jochem Maas wrote:
Jacob Singh wrote:
What is the common framework people use for I18N on your sites? John Coggenshall has an article in PHPBuilder about using smarty filters. I don't really approve of this approach because it is forcing me into Smarty, which I am not particularly fond of.
I like the look of PEAR::translation2, but I am not sure about the best way to implement it. I feel that a good I18N package, like any other package, doesn't compromise your framework intentions. This one seems to require that you use PEAR:DB through their connection, which is a problem because of connection pooling, and the fact that I don't use PEAR:DB, I am using propel.
Any thoughts on this? I need to make a site that is UTF-8 and has translations not only for labels and images, but in many cases for actual data.
a few thoughts:
1. I believe translation is integral to any web framework because a framework is about managing contextual content display (and the language is a variable attribute of the content). Also I wouldn't expect alot of code out there that doesn't come with some baggage (from the point fo view of your own framework), then again there is nothing to stop you from stripping down a PEAR module to suit your needs.
2. I view static text (e.g. button labels) and user text as fundamentally different - for the static texts I use a class that handles translating placeholder strings and for user created text I have an integrated translation service in my data objects - one tells the DB class to attempt (if a translation for the current language is not found then the original value is shown) to translate relevant values (i.e. fields marked in the data objects as 'translatable') when 'getting' values, the translations
are stored in a seperate table ala:
KEY - a user created string taken from an arbitrary row & table in the DB. LANG - a language code relating to the language of the value of the TEXT field TEXT - the translated value of KEY
I'm thinking of storing my data in an XML format in MySQL with multiple translations and making my own search index for each language. The problem with this is that I have to grab the entire XML doc for each field which may have 10-15 translations, parse and then display, wasting lots of processing and database time.
I'm not farmilliar with XML databases, and I'm told they are bad voodo, but what is another solution if you have to store user entered records in 'n' languages?
the table I describe above actaully covers that scenario - how you present the management interface is ofcourse up to you. for a given KEY (text te translate) and LANG (id of the desired language) it is possible to retrieve a translation - the table stipulate the 3 bits of information required for every/any specific translation that needs to occur. you could alternatively implement it as a set of arrays (one for each lang). e.g.
$Lang['KEY'] = 'TEXT';
(I do something like this for what I call 'static' texts).
Bare in mind that you could use foreign key relationships to create
a M-to-N joining table(s) that stores translations for given entities in the DB e.g.
WEBPAGES id title url
WEBPAGE_CONTENTS webpage_id --> WEBPAGES.id lang_id --> LANGS.id content
LANGS id name
(another trick I use when it is not feasable to use a default value as a key - i.e. a whole page of text makes rather a large key value - rather larger than most DBs expect for indexable key fields)
You mention John C.'s article about smarty filters - you might then want to look at Apache2 output filters, very cool stuff by all accounts, although I have no personal experience with them
---
I18N / L10N can be a bitch, I mean not only do you have to implement it but then you have users who want to quickly/easily manage 100's/10,000's of translatable text. on top of which you will find yourself in the murky waters of encoding translation and/or Unicode (UTF8/16) - the reason I say this is that these things can be complex enough with out making life even harder by starting off determined to use XML as part of the solution. besides unless you are going to use some serious caching of output (e.g. smarty caching, homebrewed output caching, squid etc etc) then extracting large chunks of XML from a DB and then having to parse it before extracting the relevant values (probably repeated more than once per request) is probably going to make your site alot slower. I'll say that another way - deciding to use XML should be the endpoint of your investigation not the starting point.
Hope thats given you some stuff to think about and maybe spark some ideas!
grds, Jochem
Thanks Jacob
-- PHP Internationalization Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
