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.

Enable language detection based on URL at /admin/config/regional/language/configure.
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'.
Order the languages to:
English
Spanish
-- Spanish (Mexico)
-- Spanish (Spain)
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'.
Go to the body field edit page at /admin/structure/types/manage/page/fields/body and
select 'Enable translations'.
Add some page content in English, then click the translate tab and add in a Spanish translation.
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!

Drupal 8 version

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 have Drupal 8.8 installed, and this core patch from #3091336: path.alias_repository service does not use a proper language fallback mechanism, in order to work. If you don't have either of those, you just don't get URL alias fallbacks for the language hierarchy. Help towards getting that core issue reviewed & resolved would be much appreciated!

Drupal 7 version

Sometimes it's appropriate to apply the language hierarchy to content, but nothing else. Other times everything on a site should go through the same fallbacks. So many of the fallbacks are provided by optional submodules. On Drupal's Modules page, they are all grouped under the 'Language Hierarchy' section. The following systems are covered for Drupal 7:

Core's content/node translation system as well as field/entity translations (with submodules that add extra functionality, e.g. to translation overview pages)
Interface & any i18n string translations (e.g. views, fields, field groups, taxonomies, panels, etc)
Listings in views
System settings (variables/configuration)
URL aliases
Menus
XML sitemap links
Hreflang annotations
And more!

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.

RTBC issues for Language Hierarchy

Filters