[RFC] PEAR::Translation 2.0 (was: Pear::Translation,bug)

On Mon, 24 Nov 2003 21:15:38 +0100, Lukas Smith wrote: > ok you have showed your dedication to the cause :-) > Also it seems you were right that the author is unable to provide > the necessary support (atm). > Generally I would like to propose the following course of action. > Lorenzo takes over lead for now and you feed him your patches. Ok, so I'm ready to start. Before committing anything to CVS, though, I'd like to hear back from the original developer (CC'ed) if he's ok with this course of action. Here's a brief RFC on what I plan to do: Note: here I'm referring to "pages" as to "groups of strings", not as to an html page... 1) new class model, allowing different containers (DB, MDB, xml...). I've jotted down a first draft along the lines of PEAR::Auth, since its design is proven to be a good one and PEAR users should be already familiar with it. 2) separation of translation retrieval (main class) and storage (admin class) for a minor memory footprint in a common usage (i.e. include the admin class only when it's needed to add a new translation and such). The admin class is the one responsible for the creation of the structure of a new language and for the addition/editing of the translated strings. A third admin-related class could be written to ease the conversion of already existent translations (i.e. a file-dump importer or sth like that). 3) add a new fallbackLang option to specify an alternate language when the string in the main language is empty, before resorting to the "lang not available" message. Which one is better, though? a) fetch all the strings of the specified page of the fallback lang first, then overwrite them with the non-empty strings in the default lang. This option requires only two queries per page, but the first one can be bandwith-intensive if the db is not hosted on the same machine. b) fetch all the strings of the specified page in the default lang, then retrieve the fallback-lang-strings for each string which is empty in the first language. This option requires as many queries as the number of requested strings that are empty in the default language, but each one is small (single row). c) implement both things, and let the user choose the preferred behaviour with an option. 4) revise container structure. The current one has one table for each different language. My idea is to use the same table for all the languages, with a column for each lang. It's much better from the db-normalization POV. This approach can have its drawbacks, though, since I don't know if different containers (I'm referring to file-based ones) would scale well. Maybe for file-based containers the "one-file-per-lang" approach would be better, but I'd like to collect some opinions on this subject. Should the containers have different "models"? I.e. should the db-based-container handle the "one-table-for-all-langs", while the file-based-container should have one-file-per-lang? Should this be handled transparently, or via container-specific options? Or with an external config file? I hope I expressed my concerns clearly. 5) Drop the "gstr("PAGE_ID.STRING_ID")" syntax: I think that using a special-char separator to divide what should be treated as *two* different parameters limits the type of characters allowed for stringIDs (i.e. in the current class, the dot is not an allowed char... why should we impose it?) and is in general A Bad Thing(TM). PHP allows methods with a variable parameter number, let's use this feat. 6) Simplify gstr(). It has very un-intuitive features, which may separated in different functions. For instance, let's add a translate() method, and drop that functionality from gstr(). Having more simple methods is better from many POV (more scalable, easier to maintain, easier to remember) than one method with a very complex and overloaded syntax. KISS! 7) cache, cache, cache! But to what extent? a) cache the strings of the called pages in an array, for the default language only: $data['page1'] = array('string1' => 'a string in the 1st page', 'string2' => 'another string'); $data['page2'] = array('string1' => 'a string in the 2nd page', ...); b) cache the strings of the called pages for each requested language. For instance, if the user wants a string in a different language, let's cache the whole page in that language, because it's likely that the user will fetch other strings in that page in that lang. 8) metatags can be anything the user wants to associate with the lang: an array of <meta> tags, the ISO-string, a number, an object... So, for maximum flexibility, I'd serialize/unserialize them when storing/retrieving them from the container. My idea is to treat this var as a generic "meta-info", let the user choose its value AND type. A first preliminary draft can be found here: ======================== main class: http://cambiano.onlinein.it/pearzone/Translation/Translation.phps container base class: http://cambiano.onlinein.it/pearzone/Translation/Container.phps sample MDB container: http://cambiano.onlinein.it/pearzone/Translation/Container/MDB.phps ============ NB: this is just a first NON-working draft, please don't jump mad at it if there's something you don't like. It's just a work-in-progress at an early stage, and I'm open to suggestions :-) Best regards, Lorenzo