Re[2]: [PEAR-DEV] Translation2 ...

Hi, >> 1. String retrival process >> -------------------------- >> When I set a pageId and try to get a value for a key that is not >> defined with that pageId but is defined with a NULL pageId, I think >> Translation2 should return that value instead of the general >> fallback string. > > there's a subtle syntax difference here, as explained in the "HANDLE > CONFLICTS" section of the example. > > ============================ > //call #1 > $tr->get('conflicting')); //pageID defaults to null => get current pageID > //call #2 > $tr->get('conflicting', '')); //pageID='' => get strings > with no pageID (i.e. > the one with a "NULL" in the pageID field > //call #3 > $tr->get('conflicting', 'in_page')); // => force pageID > ============================ > > what you want is #2, I guess... No, that's not what I want. I have set a pageId in the beginning of the script, and I just call the get() method with its first parameter where I need it. What I want seems then to be #1, but with a different fallback method. Your method is the following: 1. pageId parameter is null, so you get current pageId. 2. there is no string for current pageId, so you get global fallback string. The method I would like to have is: 1. pageId parameter is null, so you get current pageId. 2. there is no string for current pageId, so you try with no pageId. 3. there is no string either for no pageId, so you get global fallback string. What do you think of this? >> 2. Language parameters >> ---------------------- >> It should be possible to use as many fields as needed in the >> language list table [...] > > I've never been satisfied with the getLang() method, there's > definitely room for improvements there. OK ;) > Right now, you can serialize your extra fields and put the > serialized value in the meta field. Why not just use as many fields as wanted? >> 3. Fallback languages >> --------------------- >> It should be possible to use lists of fallback languages instead of >> just one, with fallback mechanism in the order of the list. [...] > > I think that having a fallback language is *really* useful, [...] More than usefull, it's necessary... ;) > OTOH, having more than one could led to serious performance issues. Maybe, yes. > Anyway, after looking at the beauty of WACT, I'm seriously > considering the implementation of filters/decorators. This way you > could add as many filters/decorators as you may need, and the > decision on the tradeoff between performance and functionality is > left to you. Still have to think on how to do it, though... That would be nice, but I don't know either how to do that. >> 4. Automagical prefered language detection > > nice idea. Will look at it. OK > thanks for your feedback I use it, so I give feedback... ;) -Nicolas -- Nicolas "Brush" HOIZEY Free PHP projects http://www.phpheaven.net Veille tous azimuts http://www.gasteroprod.com Clever Age http://www.clever-age.com