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

Here are some comments about your plans : > 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 > 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 Yes and i think the admin class will be very important because if will have to be fast and intuitive to use. > 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. +1 for c) I think we must let user choose, for i think i prefer to have the code of the string returned instead of an arbitrary language.. Because does it make sense to display an english traduction when we are in a german page ? We must also think about a method that would quickly tell us, what variable are missing for witch langage.. > 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. One table... Yes it will be better from the performance POV, but it's true that a table with one table per langage is more "clean" for maintenance.. But if all traductions are managed from Admins classes it will not be a real problem... > 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. Yes true, "." is not a goog idea.. When using the current package i had to make additional constant "adm/index" instead of adm/index.php" ... About this, another thing that i think it is very important. Actually, suppose you have a "txtHelloWorld" traduction... and you want to use it in to different pages, we had to call the var of the page and then use this calling method : "index.txtHelloWorld" because txtHelloWorld is not in this page_id. But can't we find another method to tell that a given traduction variable can be present in several others page_id ? The var would have a "Parent" page_id, that's the page where the trad was first created or where the trad is the more used... And others "page_id" where the var appear... One other thing i was thinking but may be it is silly ( tell me ! ) I was thinking that sometimes traduction can be put together in "group" instead of "page_id", for example, for an application that would send mail, we would have a group of var : GROUP_EMAIL: txtSubject; txtFrom; txtTo; txtBody; And so, this group would be called in the page that send the email and in the page that display the email... So instead of assiging all var to the page_id, we would only assign the group email to the page_id, i don't know if was clear... And this method would be less easy to implement and of course it would decrease performance because we will have to do more queries... it was just an idea... > 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! +1 > 7) cache, cache, cache! But to what extent? Ok. > 8) metatags can be anything the user wants to ... OK. > Bugs Lorenzo you found the first, one other in the current classe is : >>>>>>>> $result = $this->db->getRow("SELECT " .$this->TableDefinitions['langsavail']['lang_name'] . " FROM " .$this->TableDefinitions['langsavail']['name'] . " WHERE " .$this->TableDefinitions['langsavail']['langid'] . " = '" .$this->LanguageID . "'"); # replace with : $result = $this->db->getRow("SELECT " .$this->TableDefinitions['langsavail']['lang_name'] . " FROM " .$this->TableDefinitions['langsavail']['name'] . " WHERE " .$this->TableDefinitions['langsavail']['lang_id'] . " = '" .$this->LanguageID . "'"); >>>> ( lang_id ) ... 9) For the keeping of actual behavior and method, i think as Lorenzo that it is quiet impossible to maintain comptability because it will have too much changes from all POV... COil :) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com