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

I added 2 people to CC - Makisalo Kari and Valberg Larusson - they are from my information already using this class, and some feedback or information from the user point of view I think will be very precious :) Makisalo, Valberg - please see below comments and proposals - maybe you have some other ideas. I alos forward you the original mail I received. As for the idea of redesigning the class - think quite good idea. Especially that last times I can't find time even for removing bugs :) However I would be really gratefull, if my oppinions and ideas would be aos taken in mind :) Please find my comments below: The compatibility - the main thing I think should be left is lowe versions comaptibility. From my information there are quite several sites that already uses this class (e.g. sites in Island or Finland - these 2 I personally know, besides I develop my systems basing on this class), therefore they should not be forced to change the existing code to work. Besides in Poland I have published one article about this class - so quite many people uses this class and learns how to use it with "old" interface. This means the new parameters or methods may be added - but the old ones should also work just like they work right now - even if they use the new backend. The filenames should be also retained. > 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. +1 from me > 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). +1 from me > 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. Solution should be connected with optimization switch on the translation class cosntructor. If the optimization is set on the php-mode - the query may be bandwidth-intensive, while on db-mode enabled - the bandwidth should be limited (as db-mode was designed for the sites, that uses separate machines for DB and PHP servers). Besides I would propose the possibility to show the PAGE_ID.STRING_ID instead of "lang non avail" text (should be configurable). > 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. This is already implemented as you can specify same table for different languages. > > 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. +1 from me... > 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! I think ading a method is OK, however the gstr() method should be retained for the previous versions compatibility. > 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. Right now the only cache that is done is the cache on request... I would think about integrating the cache with some caching engines already implemented i.e. in Smarty. > 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. +1 from me As for the question in the class body: The parameters allows to parametrize the returned string. e.g.: Suppose we have the "User &&1&& logged in" string in the DB as "LOGGEDIN" indetifier; We call: $tr->gstr("LOGGEDIN", array($Username)); We get: "User voyteck logged in" if the $Username == "voyteck", or "User lorenzo logged in" if the $Username == "lorenzo". Of course the parameters &&2&&, &&3&& etc. will be replaced with next array elements. Best regards Wojciech Zielinski