Consider deprecating language_hierarchy in favor of entity_language_fallback

language_fallback is not really achieving the same as language_hierarchy. Language fallback defines hierarchy for interface translation strings only, it doesn't do much for content translation, menu translation or any other use case that involves multilingual.

Language Hierarchy uses hook_language_fallback_candidates_alter to achieve its goals, which makes it useful for all multilingual use cases. We are also introducing a lot of alterations to UI - for example using hierarchical Table Sort for language list interface, etc.

The Language Fallback's 7.x-2.x branch now covers content (entity) translation too, amongst other things, so I'm re-opening this question. How do these two modules differ, and would it better to combine efforts into one?

I agree, Language Fallback 2.x is attempting to solve exactly the same problem, and as a D8 port has already been started for that it seems logical for me to work with Language Fallback at this stage. Would be great to combine efforts.

Language Hierarchy won't be merged into Language Fallback since it covers much more than Language Fallback and because of that it makes more sense to merge Language Fallback into Language Hierarchy instead.

List of differences:

1. Support for node translations hierarchy
2. Support for menu translations hierarchy
3. Support for xmlsitemap links hierarchy
4. Supports hreflang
5. Includes automated tests

If that's the case, then discussion needs to be had between the two modules. Keeping both modules going in their own little silos is unhelpful -- combining efforts would still be the best way forward. I certainly prefer Language Hierarchy on the whole, as it doesn't mess with sessions, but there are areas that Language Fallback supports that Language Hierarchy does not. The best situation has to be one module that covers all the areas, with the best solutions used where the two existing modules cover the same things.

I would cite the example of the Apache Solr Search & Search API modules -- two approaches, where the two sides came together to agree on the best ways forward foe the community, rather than unhelpfully going in two different directions.
Has there been any communication between the maintainers of these two modules? Perhaps in-person discussions might be helpful to thrash this out, e.g. at an upcoming conference/sprint if both would be there? (I believe that is what was necessary for those two search modules)

After looking into this a bit further, I see that the start of the D8 port for language fallback came from Gábor Hojtsy, named 'sublanguage': https://www.drupal.org/sandbox/goba/2546832 - which ports the very basic functionality for D8, though that will apply to both interface & field translations, since D8 handles both through the same hook. Perhaps a new full project, 'sublanguage' should become the way forward for language hierarchy/fallback, with any functionality from either module put into that, or where there is specific functionality (e.g. geolocation), that could be moved into sub-modules in that project? That way, all the best functionality from the two D7 projects could be brought together, without conflicting? I'll suggest similar over on the language fallback queue...

I think we can now consider this ticket as a duplicate of #2552663: Consider deprecating language_fallback in favor of entity_language_fallback, as that one has had more fruitful discussion to move forwards, particularly for the current version of Drupal.

Reopening and postponing this on the related issue. I hope we can build trust and join forces this way.

We could probably close this now as outdated?