See https://www.drupal.org/project/translation_fallback.
As a new optional submodule, perhaps we could support _context_ fallbacks for string translations (i.e. those that use t() or i18n_string()). I could be open to persuasion, but I reckon the fallback should be 'depth-first' - in the sense that we should only fallback to empty context translations if no translation could be found in the language fallback chain. For example, recurse through the following until a match is found, where the language fallback chain is A->B->C, with C being most specific:
* Language C, respecting context
* Language B, respecting context
* Language A, respecting context
* Language C, without context
* Language B, without context
* Language A, without context
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | language_hierarchy_textgroup_fallback-2650924-5.patch | 10.96 KB | james.williams |
Comments
Comment #2
james.williamsI'd be open to persuasion that the following order should be iterated over until a match is found:
* Language C, respecting context
* Language C, without context
* Language B, respecting context
* Language B, without context
* Language A, respecting context
* Language A, without context
Thinking out loud...
Unfortunately, I suspect the best order to iterate may be different for different strings. For example, the context used for i18n_strings is little more than a technical namespace, so the order posted in this comment may be better, however the original concept of a context as used by core was to actually declare a string as a very different meaning. Given that, I suppose in those cases, context genuinely shouldn't be used as a fallback... so maybe this should only apply when context is recognised as a i18n_string identifier... in which case the order in this comment would be best after all!
Comment #3
james.williamsHere's a first pass at this. Rather than making a whole new module, I've just added a setting (that has no UI) - so set the 'language_hierarchy_textgroup_fallback' variable to 1 in settings.php or use drush vset in order to apply the setting.
It's only been very minimally tested, and it does not cover loading multiple translations (as is done for field allowed values) yet. But the basics seem to work :-D
Comment #4
james.williamsRight, this is patch covers getting multiple translations at once (i.e. for field allowed values), and adds a checkbox to the UI (which is on the i18n_string module's config page, since that's what is being worked with, and we really don't have our own settings page so it seemed silly to make one just for this), using the variable module (since i18n_string depends on that being around anyway and uses it for its settings page).
Tests would still be required.
Comment #5
james.williamsUpon review, here's a slightly nicer patch (just renamed a function and removed some unnecessary refactoring). Ready for tests & testing.
Comment #6
james.williams