Re: Translation class new features - RFC

sorry that it took so long for me to get to really look at your suggestions. at first, i want to suggest to split the I18N_Messages to become a seperate package nad not as it is now to be all in I18N any objections? in general about the I18N_Messages i imagine something like a DB-Abstraction layer, only that we abstract the possible translation mechanisms, like: gettext, DB, text-files, arrays, etc... Wojciech Zieliński wrote:

Hi, I finally found some time to think over again the features of Translation class and make the full list of additions I would like to add to this class. However before starting coding I would like to see some you comments for these features - so I won't do something that is completelly unusable, or do something, that will be not used becouse of comlicity of the solution. Please find the description below and any comments will be highly desirable. 1. Error handling - all the languages will have the string, that will be showed to the user, if the string has not been found for the specified language - e.g. if string STRING1 has only the Polish version, then for English there will be "No english available" showed.

i would say that this should be configurable, either this way of leaving the original string. since i for examples have a software where the translation is not completely done and the real string tells the meaning better instead of 'no english availbale'. i could imagine to have this mode configurable in the following ways: (1) leave as it is, that means untranslated (should be default) (2) as (1) but add an additional user-configured string, like '***' (3) replace by a string such as 'no english available'

2. Custom table and column names - user will be able to specify the names for the tables and columns in which all the information will be stored. This will be passed to the class constructor as additional parameter - CustomTables.

it should be an 'option' in my eyes, not a parameter of the constructor. so the constructor wont be bloated, since most user use default settings anyway.

This parameter will be the array with the following structure:

    "langsavail" -> table, in which all the information of the possible languages is kept. This array item may be the string - then the structure of the table remains as original, but the name is specified here; or the array with the following items:
        "name" - the name of the table.

if you look in the current implementation you can see that there is a table for each language, what do u think that?

        "lang_id" - the name of the column, that stores the language identifier. Original column name is "lang_id".
        "lang_name" - the name of the column, that stores the language name. Original column name is "name".
        "metatags" - the metatags that should be included in the page header, so the page will be displayed properly. Original column name is "metatags".
        "nostringtext" - the text that will be displayed if the string for the specified string_id has not been found in the language. This is new feature available since this version (please refer point 1).
    "strings_en_tablename" -> table, in which the strings of language "en" (the corresponding lang_id) are kept. This array item may be the string - then the structure of the table remains as original, but the name is specified here; or the array with the following items:
        "name" - the name of the table.
        "page_id" - the page identifier. Original column name is  "page_id".
        "string_id" - the string indetifier. Original column name is "string_id".
        "string" - the string itself. Original column name is "string".

again, i think those should be options.

3. Reducing the DB connections by possibility to use the existing ones - the constructor right now needs the PEAR DB DSN to make the connection do the DB. The new version will allow user to use the existing DB connection (PEAR DB connection) instead of making the new one. To do so he just needs to pass to the constructor the handle for this connection instead of DSN.

of course!

4. Getting the strings in more then one way - adding more flexibility for gstr() method, so it will be able to get the strings in the following ways:

    gstr("PAGE_ID.STRING_ID") - this will get the string not for the current, but for the specified page_id.
    gstr("STRING","LANG") - this will ry to find the STRING in the strings table of the specified LANG and will retrieve the translation for the current language - e.g. if the current language is "pl", and we will make the gstr("Some string","en") - this will return as the corresponding string in Polish (in this example "Jakiś napis"). This method is not recommened as the indexes are not made on the string

i would like to see this being very good performing too :-) we wil find a way, i am sure

column, but sometimes - if we simply need the translation, and have no page_id and string_id - this might be usefull.

in general i would like to change the behaviour to work this way, as it is for the I18N_DateTime now, that you instanciate the I18N_Message-class once with the current locale/language $translate = new I18N_Message('de'); and then you dont have to worry about passing the language as a paramter anymore. and since webpages and applications always/mainly work in one language at a time this makes more sense in my eyes.

5. Ability to use the PHP native gettext support - instead of db_handle the constructor may be provided with hadle (DSN in fact) in the following format: gettext://LOCALE:LANG:BINDTEXTDOMAIN:TEXTDOMAINFILE:TEXTDOMAIN:CONFIGFILE LOCALE - the locale id (e.g. "LC_ALL") LANG - language id (e.g. "de") BINDTEXTDOMAIN - localization tables (e.g. "myPHPApp") TEXTDOMAINFILE - localization tables file (e.g. "./locale") - if not supplied - it equals "./locale". TEXTDOMAIN - text domain (e.g. "myPHPApp") - if not supplied - it equals BINDTEXTDOMAIN CONFIGFILE - the config file directory. Config file should be in the following format: pl_langname = "Polish" pl_metatags = "<!--meta...--!>" pl_nostringtext = "Brak polskiej wersji !" en_langname = "English" en_metatags = "<!--meta...--!>" en_nostringtext = "English version not available" ... In this file the first 2 characters are the language code. This functionality is the most advanced - so I would really appreciate the comments from people, that actively uses the gettext functions (in fact - I have never used these functions, so I might missunderstood something :) ). As I said before - any comments highly requested :) Regards Voyteck

-- Wolfram .. opensource @ vision:produktion ... http://opensource.visionp.de .. translating template engine .... http://sf.net/projects/simpletpl .. authentication system .... http://sf.net/projects/auth