Re: Translation class proposal

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

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? So - I think the development plan and tasks for us should be the following:

Translation class - Voyteck 1. Allow the class to use the custom table names - so the Translation class won't be dependend of tr_strings_xx classes, but will be able to use also translation_xx tables. This will be added as addtional non-mandatory parameter of constructor method - and will be able to give the following : Translation($PageName, $LanguageID, $pear_DSN, $tableNames), where tableNames can be "something_&&" where && will be replaced with language name (en, de, pl etc. - 2 characters). 2. Modify the gstr method, so it can handle the &&PAGENAME.STRINGNAME&& string ids. The PAGENAME will be added as 3rd non-mandatory parameter - to maintain lower versions compatibility. Besides the function will return -1 (integer value) if the given string will be a pagename, and 0 if the given string will not be found in the DB. 3. Modify the costructor so it'll allow to give the Db access handle, not only the connection string (so user can give the handle, not the string "mysql\..."). This handle may be given instead of connection string - to maintain the lower versions compatibility - so the consructor will check if this variable is the DBhandle or DBconnection string. 4. Add some error handling and destructor methods - this was to be done by me some time ago :) The error handling also should handle the errors that some strings can have blank string_id and page_id. 5. Make the documentation compliant with PHPDoc (it's not quite yet :) ) 6. Verify the code, so it'll be compliant with PEAR coding standards (I am not sure, if everything is like that) 7. Separate the code of string management routines. IT[X] class - Wolfram Kriesing 1. Make the parser to handle the keywords &&PAGENAME.STRINGNAME&&. My proposal is that the parsing engine will work as following: a) &&SOMEPAGE1&& --> $tr = new Translation("SOMEPAGE1",{LanguageExtension},{DBAccess}) (where LanguageExtension and DBAccess will be took from the IT[X] object) b) &&SOMESTRING1&& --> $tr->gstr("SOMESTRING1") c) &&SOMESTRING3.["param1","param2"]&& --> $tr->gstr("SOMESTRING3",array("param1","param2")); d) &&SOMEPAGE2.SOMESTRING1&& --> $tr->gstr("SOMESTRING1",array(),"SOMEPAGE2") e) &&SOMEPAGE2.SOMESTRING3.["param1","param2"]&& --> $tr->gstr("SOMESTRING3",array("param1","param2"),"SOMEPAGE2") You will be able to distinguish if the single given string is a page_id or string_id by checking the result of $tr-gstr("STRING") function - if it'll result -1 - then you know, you should perform the a) action. If the result will be 0 - you perform error handling (no such string). In any other case - it should work as it is described on the b) point. 2. Allow calling the gstr() Translation calss method from inside the IT[X] class. 3. Update the documentation so it will contain the information about the keywords. 4. Think out how the tr_langsavail table can be used in the templates (maybe another keywords or something). What do you think ? I post this message also to the group - so maybe someone will have some ideas - I will be very gratefull for any of them :) Regards Voyteck