Language Hierarchy

This module allows you to setup language hierarchies where translations of a site's content, settings and interface can fall back to parent language translations, without ever falling back to English or other irrelevant languages.

It implements hook_language_fallback_candidates_alter(), without which translations from any available language are used as fallbacks, which is usually unexpected.

An Example

In this example, we assume Drupal's default language is English and that you're using Entity Translation module to handle content translation.

1. Enable language detection based on URL at /admin/config/regional/language/configure.
2. Goto /admin/config/regional/language and:
   Create Spanish language, with code 'es'.
   Create Spanish (Mexico) language, with code 'es-MX'.
   Create Spanish (Spain) language, with code 'es-ES'.
3. Order the languages to:
   English
   Spanish
   -- Spanish (Mexico)
   -- Spanish (Spain)
4. If you have a default Drupal install, go to /admin/structure/types/manage/page and in the
   Publishing options tab select 'Enabled, with field translation' under 'Multilingual support'.
5. Go to the body field edit page at /admin/structure/types/manage/page/fields/body and
   select 'Enable translations'.
6. Add some page content in English, then click the translate tab and add in a Spanish translation.
7. If the node created was node 10, then you should see the following;

   /node/10 - English content
   /es/node/10 - Spanish content
   /es-ES/node/10 - There is no Spain-specific content, so it will display the Spanish content.
   /es-MX/node/10 - There is no Mexico-specific content, so it will display the Spanish content.

Note that, as with some parts of Drupal core and a number of modules that support multilingual functionality, using this module may affect your site's performance. That is not expected to be an issue for many configurations, but you should probably check how your site performs. It is always wise to be mindful of what drawback any added functionality has, from any module!

Contributions & more testing are very welcome!

Interface translations, content entities (nodes, terms, etc), configuration and URL aliases are covered. For URL aliases to use the full language hierarchy for fallbacks, you must apply the changes from this core merge request from #3091336: Allow altering of the language fallback for path aliases, in order to work. Without that, you just don't get URL alias fallbacks for the language hierarchy. Help towards getting that core issue reviewed & resolved would be much appreciated!

Similar modules

• Language fallback:
  Another approach to providing language fallback functionality, with different features such as country-specific fallback chains and user geolocation integration, though that is incompatible with page caching. Does not cover menus, site maps, variables, and lacks some other features of Language Hierarchy. See this issue for full comparison & discussion.
• Entity Language Fallback:
  Provides different fallback chains depending on the original request language, rather than a single 'global' hierarchy of fallbacks, which is what Language Hierarchy does.See this issue for full comparison & discussion.
• Sublanguage for Drupal 8 (sandbox):
  A start on fallback functionality for D8, which has been merged into this project already.
• Translation Clone:
  Sometimes it's appropriate to duplicate a language from an original language, including all its translations (i.e. for content, interface & configuration), rather than just using the 'fallback' approach.
• Translation fallback:
  Rather than providing fallback from one language to another, instead provides fallbacks for i18n string translations to the general interface translation rather than being specific to each textgroup/context. This functionality can be used with Language Hierarchy via the patch in this issue.