Re: New class in PEAR: Translation

On 2002-10-01 13:11, while getting another beer from the fridge I saw a little yellow card, on which Markus Wolff wrote:

Am Tue, 01 Oct 2002 12:30:35 +0200 schrieb Wojciech Zieliñski <voyteck@caffe.com.pl>: In case you´re wondering what I have in mind when I think of a translation class, it´s basically this: When I need to output strings in a script, I make an instance of a translation class... $t = new Translation("DE"); // For translating into german To get a translated string, I´d simply do something like this: $trans = $t->get("Translation is good"); Or this: printf($t->get("You have %s unread mails", $num); The "get" method will look up the string in a database table that looks like this:

BASE (Primary Key)      | DE                            | FR

------------------------+-------------------------------+-------------------------

Translation is good     | Übersetzung ist gut           | Je ne parle pas Francais

You have % unread mails | Sie haben %s ungelesene Mails | The field "BASE" will always contain the original strings in the base language. This is the language that I´m using in my PHP code and will be English in most cases I guess. This way my code is very easy to read and understand. Also, it doesn´t matter on which page I am which is especially important as I sometimes need to output stuff in scripts when I can´t possibly know where I am at the moment. When a string is not yet in the database, it will be added for future reference. The other column names are identical to the language string that is passed to the translation class constructor. If no translation for a specific string is available (meaning the target language´s column is empty or doesn´t exist), the string will always be returned in the base language. This is a drop-dead-simple method of translation that is not only easy to use but also easy to maintain even with tools like phpMyAdmin. If someone here knows a class that already does this or something very similar, please drop me a line. If not, I´ll have to write this myself as I need something like this and have no use for page-oriented translation. I had several reasons why I didn't do it like this, but used more I would say sophisticated engine:

1. If we'll use as the base key the full-string field - the search will be significantly slower. Besides not all the DB servers supported by PEAR supports also full-text fields as primary indexes. 2. I used the page_id's to avoid searching through the whole DB every time I wish to get the string. If you have the WWW server and DB server on the same machine - this is not the problems. But imagine, that you use some distant machine - then every query is quite time consuming. When you use Translation class with page_id's - you load into some kind of cache on the WWW server all the strings, and while the page is generated - the WWW server already knows all the strings that may occure on this page. 3. I use separate tables for every language also becouse of search performance issue. Of course - I could keep all the strings in the single table and use the views - but again it would limit the DB servers for only the ones, that are supporting views (e.g. MySQL does not support views). However the approach you need will be (as far as I know) soon available on I18N class - as me and Wolfram are trying to merge our classes. And becouse I18N is supporting the described approach, but only on the files, and my class is supporting the DBs - then maybe sooner or later your wish to have the class that allows you do the things described will come true :) Besides I also think about some tools for Translation class that will help people to translate their websites - but this is right now in the project phase - so it will be rather later, then sooner :) Voyteck