The use case is the following desired behaviour:
Where a localisation string is not found, rather than just returning the source code English string, return the translation in a nominated other language (which is assumed to be more fully localised). This is required in minority language situations where lack of resources or humanpower might mean that localisation has not been completed, but resorting to English is culturally or politically unacceptable.

The desired behaviour will never make it into core, but in order to implement it in contrib I need a hook_locale_alter (or some other name!) which allows a module to implement a different database query (or different logic) at the point where the query is made in locale(). I'm assuming this can be done efficiently so that we find out once whether such a hook is defined, remember that and, if so, call that hook after (or instead of?) the existing DB query, i.e. only where the outcome is not already stored in cache. The overhead for any site not implementing the hook would therefore be one single call to module_implements - can we afford that?

Comments

Gábor Hojtsy’s picture

Status: Active » Closed (works as designed)

No, you can in fact implement an object which implements http://php.net/manual/en/class.arrayaccess.php, and put that into $conf["locale_custom_strings_$langcode"]. Then your object can implement whatever fallback mechanism you want to for lookups.

martin_q’s picture

Category: feature » support

Thanks for the pointer, Gábor. I've had a go at developing some code based on your suggestion and have posted on the forum with the question about best-practice that has resulted from it: http://drupal.org/node/1266882

Gábor Hojtsy’s picture

Issue tags: +language-ui

Adding UI language translation tag.