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

On Mon, 1 Dec 2003 12:23:24 +0100, Wojciech Zielinski wrote: > some feedback or information from the user point of view I think > will be very precious indeed > The compatibility - the main thing I think should be left is lowe > versions comaptibility. Sorry, but this is something that can't be done. The multi-backend structure alone doesn't allow BC, and there are many more issues that require a BC break. This is why i put the "2.0" version in the email title. Anyway, those who are concerned with having to change their code, well, they can keep on using the 1.x version. I've just committed it to PEAR CVS, and I've already fixed a bug. When I have some more ideas and comments on v.2.0, I'll create a new branch in CVS, so v.1.x development (mostly bug-fixes, I guess) and v.2.x development (where the biggest changes should go) can coexist. More comments follow: >> 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. here I meant: a) requires only two queries IF the two language strings are hosted on different tables, while it requires only one query if there's only one table: SELECT id, en, pl FROM i18n_table WHERE pageid=XXX but yes, the returned resource size is bigger, so it is an heavier bandwith load, but not as much as two different queries. >> 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). ok, so both options should be provided. > Besides I would propose the possibility to show the > PAGE_ID.STRING_ID instead of "lang non avail" text (should be > configurable). agreed >> 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. ok, fine. I hoped to reduce the number of options the user has to write, but no big deal... Then probably it's just a problem of missing documentation: let's make it clear: "...you can use the same table for all the languages". And MAYBE we should fix "translation.str_mgmt.php" to make it effective, uh? :-) With the current implementation, removing a language means "DROP the whole table!"... and adding a new language means "CREATE a new table"! Of course the method need some more checks... if the table is the same for all the languages, we can't drop it as a whole, we need to drop a column only... >> 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. no, I'm not talking of external cache, such as the one provided by Cache_Lite or such package. I'm talking about caching the db-results within the class. When I wrote: "cache, but to what extent", I meant two things: 1) should we cache the strings in other languages too, when they are requested? In other words: should we store them in a class var (such as $this->data)? If so, what is the best array structure? - $data[lang][pageid][string], - $data[pageid][lang][string], - $data[pageid][string][lang], or should we use one array for each lang? 2) should we *preload and cache* the whole string-group (aka "page") in the language requested, when it's different from the default one? Or should we limit the cache to the single strings requested? The first case can be useful when there are more request for strings in the same page. > 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". great, now I understand. Thanks for the explanation :-) Best regards, Lorenzo