Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.0.4

Request #2619 Falling back to language code if fully qualified locale is not available
Submitted: 2004-10-26 11:30 UTC
From: ylf at xung dot org Assigned: quipo
Status: Wont fix Package: Translation2
PHP Version: 4.3.4 OS: Linux Debian
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 7 + 27 = ?

 
 [2004-10-26 11:30 UTC] ylf at xung dot org
Description: ------------ Hi, I'd appreciate to see support for another option in addition to fallbackLang. Say I request fr_CH but it's either not an available locale, or the specified string is not available with this locale. If this happens, I'd like to fall back to "fr", that is : the language code part of the locale name. If it's not available either, then "fallbackLang" would be used. So, in the translations definition (the strings table), one could put both fully qualified locale (fr_FR, fr_CH), and language code only ones (fr, en). In my case, most of the strings would be attached to 'fr', and a few to 'fr_CH' overriding 'fr' translations for the rare swiss differences. Regards

Comments

 [2004-10-26 11:44 UTC] quipo
With Translation2 you can have multiple fallback langs (i.e. multiple layers of the lang decorator): $tr->setLang('fr_CH'); $tr =& $tr->getDecorator('Lang'); $tr->setOption('fallbackLang', 'fr_FR'); $tr =& $tr->getDecorator('Lang'); $tr->setOption('fallbackLang', 'fr'); If you mean something else, that can't be emulated like in this example, please let me know.
 [2004-10-26 12:14 UTC] ylf at xung dot org
This kind of fallback 'stack' is nice. The point is my application will be told to work on a fully qualified locale, say 'fr_CH'. Then it's gonna edit some administrative documents, for which it will query Translation2 in order to get the properly translated strings. With what you describe, I'll have to do this : // the user has set $locale to 'fr_CH' but it could be any // fully qualified locale (lang code + country code) $tr->setLang($locale); $language_code = substr($locale,0,2); $tr =& $tr->getDecorator('Lang'); $tr->setOption('fallbackLang', $language_code); Or with an array, falling back to a fully qualified locale : $fallbacks = array ('fr_CH' => 'fr_FR', 'de_AT' => 'de_DE'); if (isset($fallbacks[$locale])) { $tr =& $tr->getDecorator('Lang'); $tr->setOption('fallbackLang', $fallbacks[$locale]); } I think this last method is the most flexible. What about supporting it as a setting in the languages meta info ? Like : +-------+--------------+------------+------------+---------+ | id | name | meta | error_text | fallback| +-------+--------------+------------+------------+---------+ | fr_CH | Swiss french | iso-8859-1 | ... | fr_FR | +-------+--------------+------------+------------+---------+ Or +-----+-----------------------------------+-----+ | ... | meta | ... | +-----+-----------------------------------+-----+ | |encoding=iso-8859-1,fallback=fr_FR | ... | +-----+-----------------------------------+-----+ ?
 [2004-11-11 18:24 UTC] quipo
the idea is nice, even though I'd prefer not adding this feature in the official package, I want it to be as slim as possible. I think this feature can be implemented with a small amount of code in the userland script, maybe wrapped in a convenience function/class. Anyway, I will think about it.