Language Hierarchy: More power and flexibility without extra effort

Several of our recent projects have involved setting up languages that feel like 'child' languages of other languages, for a variety of reasons. Sometimes it's for marketing, so that content can be overridden for markets using a specific currency, other times it's to target a specific audience. A traditional example would be Canadian French - where most content would be the same as French, but some pages would want different spellings or customisations. We have done similar to set up special cases of regular English: British English and Euro/€ English - to allow specific content per-location or currency. Amazee Labs' work on 'total language fallback' inspired us to work on the Language Hierarchy project.

The concept of these projects is to allow content in languages to inherit or fallback from each other. So an editor can set content up in one language, and then sub-languages would just use that content unless it is specifically overridden for them. That gives editors much more flexibility as they don't have to go back & forth keeping very similar content in sync, and more power as they can reach wider audiences whilst also being able to target specific markets.

The Language Fallback project breaks anonymous page caching (with Varnish), due to the way it integrates with the Smart IP project to geolocate users, so this wasn't an option for us, as the majority of our clients' sites traffic is anonymous. Instead we turned to Language Hierarchy, which integrates with a wider range functionality across Drupal core & contributed modules anyway anyway:

• Support for both the 'node translation' and 'entity translation' approaches
• Support for menu translations hierarchy
• Integration with xmlsitemap
• Supports hreflang annotations
• Includes automated tests

We contributed additional work to bring over some functionality from the Language Fallback project that was lacking, and added further features too:

• Support for editable interface translations provided by contributed modules (for example, for views, fields, field groups, etc)
• Support for translatable configuration (working with the i18n_variable module)
• and various other extensions & bugfixes

This brings the Language Hierarchy project to the point where everything possible on our site could inherit translations from a parent language. We even ended up becoming co-maintainers of the Language Hierarchy project to help turn all this into a new release (7.x-1.4). Hopefully a common roadmap can be found with the Language Fallback project, as the two are incompatible. If you're interested in ensuring the Drupal community gets the best solution, especially as all this moves towards Drupal 8 (a basic port has begun), then do add your comments to that issue.

Update: we have produced a Drupal 8 release of Language Hierarchy!