Re: Translation class proposal

Wojciech Zielin'ski wrote:

On 2002-09-23 00:54, while getting another beer from the fridge I saw a little yellow card, on which Wolfram Kriesing wrote:

btw to see a simple example using IT[X] see I18N/examples/I18N_Message_Translate.php have fun making translations easy :-)

Well - I looked at this example - and looks quite OK. However you approach is that each page has it's "first language" - I mean laguage in which it is written. Then the keyword for the translated word is the text, that appears on that first-lang page. This is quite a nice qpproach - especially if someone already has some page and wants to translate it quite fast. But still you need the user to use your template system. In the result - he has to convert the whole site into the template system. But what if use does not want to use the templates - he wants to have his whole code (additional - not connected with translation) in the pagefile ? And not to use some *.tpl files ? Besides - I see another potential problem: what if user wants to translate 2 identical strings in different way ? e.g. word "cheers" can have many meanings - depending on situation. And in Polish we have at least 10 equivalents of cheers - and on each page this workd may be needed to translate differently. That's why I used the keyword for the strings - and the search on the DB is performed on the keywords. Nect thing - I found in the Messages.php code the following query: "SELECT d.string FROM %s%s s,%s%s d WHERE s.string=%s AND s.id=d.id" As we can see one of the WHERE clouses is string - while string is not indexed in your tables (as found out in the SQL code craeting the tables found on http://wolfram.kriesing.de/libs/php/SimpleTemplate/examples/translate.sql ). This couses this query not to be runned optimally - and in case of really large tables - it can be kind a slowly and resource consuming. But of course you cannot index on the full text column - it would be also very resource consuming.

that is true. but for the case it is meant to be (or as i use it) the templates are only translated once and saved with a name indicating the language, such as 'index.tpl.en.php' which is the template _compiled_ into english, so the translation is only done once. it wont be done again until the template needs to be recompiled. this should work fine with engines like smarty too (and SimpleTemplate of course, that's where i sue it heavily). IT[X] of course is not compiling the tempaltes, so the load would be as u mentioned, that's right! in this case ur approach would be the better one, definitely!

My proposal of merging your class and main is the following: 1. Add to your translate_xx tables 2 indexed columns: page_id and string_id. 2. Allow user to use in the templates the KEYWORDS - e.g. in the following format: &&PAGENAME.STRINGNAME&& where PAGENAME=page_id, STRINGNAME=string_id or &&STRINGNAME&& (but before this will be called - user will have to in someway specify the &&PAGENAME&& When your parser will occure such a thing - he will use my class to retrieve the string. In any other occasion - parser will use your functions. 3. Allow calling the gstr function for your Template object - when it'll be called - the same function from Translation class will be called. Besides I think user should be able to use only the Translation class - and becouse the DB schema for I18N and Translation cals will be the same - user can e.g. on one page use your templates, and on another one (in the same site) - use only Translation. What do ya think ? Any comments will be very desirable.

sounds really cool! yes i think that is a very good approach. so we dont have to split up using a wrapper or factory class. that makes it even faster. or should we do it anyway? -- Wolfram ... translating template engine .... http://sf.net/projects/simpletpl ... authentication system .... http://sf.net/projects/auth