Standardize language-fallback modules on entity_language_fallback

language_hierarchy and language_fallback only support one fallback language per language (which cascades then but does not allow some real world use cases).

It's true that there is a real world case, implemented by entity_language_fallback, outlined in #2552663-27: Consider deprecating language_fallback in favor of entity_language_fallback, which is not supported by LH or LF.
However, the opposite is also true; LH is built around the idea of a single global fallback hierarchy across all languages - which is possible with ELF, but not enforced. The real-world cases when we have used LH on projects usually do require an enforced single hierarchy. i.e. there are real world cases that are not currently supported by all 3 projects, not just LH & LF :-)

Anyway, I probably sound a bit defensive there, sorry!

I'd asked in #2552663-28: Consider deprecating language_fallback in favor of entity_language_fallback whether ELF was really about ordering language fallbacks, or narrowing them. I think answering that is key to understanding the true way that the 3 projects overlap/approach the problem space. There may be a case for one project that focusses on ordering, and another on narrowing. Maybe a project could do both, but that might be unnecessary conflation.

(This was cross-posted with comment 4!)

I suppose that's fair enough. I suspect (but could be wrong) that Drupal itself may well have scaling issues for 50+ languages!

I've added this fairly major thing that ELF is missing: handling interface translations (I really do think this is an absolute essential for any project in this problem space), and any operations other than entity_view & entity_upcast that may also go through the hook_language_fallback_candidates_alter() hook.

To be fair, it wouldn't be hard to add handling for those operations to ELF. Though just going by the name of entity_language_fallback, it wouldn't be obvious that the project is handling more than just entity translations, so that may not even be appropriate!

Note that there's also a good amount of progress that has been done in the language hierarchy 8.x-1.x issue queue, such as patches for SQL-based views & URL aliases. I realise those are mostly in the 'needs work' state, but I mean they're further along in each area than issues on the other two projects? It might not be too hard to re-roll all those patches for a different project name, but that's certainly not ideal.

So I recognise that I would probably be biased, so I don't want that to get in the way, but I'm not convinced ELF is the best one to standardize on, given it only has these advantages so far:

* Search API support
* Different fallback chains per-language

Versus the following advantages for starting from LH:

* Supports interface translations already, as well as entity views/upcasts
* Supports any other contrib operations that will go through hook_language_fallback_candidates_alter()
* Higher D8 usage already
* Numerous patches in progress for further improvements

I would also say that language_fallback probably has the most appropriate project name, if we want to ensure support for different fallback chains per-language, whilst supporting fallbacks for more than just entities! In my mind, language hierarchy, suggests a single global hierarchy, because the concept of multiple hierarchies (which is what different fallback chains per-language is) is unusual in the Drupal world.

(So, right now, I don't agree with the 'Reasons to propose entity_language_fallback' list in the issue summary. Maybe we need to end up with a table of the advantages & disadvantages of each of the 3 projects?! I suggest we just discuss with comments some more before we have a more agreed-upon set of reasons to propose any single solution.)

The idea is, according to Drupal principles, to unite not split efforts.

Yes, I agree ... sorry if it seems like I'm blocking this idea! I do want the right solution to be found :-)

Entity language fallback's entity_language_fallback_language_fallback_candidates_alter() hook has this check on line 20, which means it will only do anything if the check passes:

if ($operation == 'entity_upcast' || $operation == 'entity_view') {

So only those two operations are currently supported. (Interface translations use the 'locale_lookup' operation.) It wouldn't be hard to change that, but even if we did, is it appropriate that a project named entity_language_fallback is acting on more than just entities?

You're certainly right about the numerous patches meaning it's important to unite as soon as possible. But only once we've decided on the right course of action to unite, I don't think we need to rush. So far it's only the two of us talking, I think? At the very least, we need to hear from maintainers of entity_language_fallback, for example.

DO you see the path to a uniting feature superset module shorter from LH than from ELF?

If we ignored the patches in progress in issue queues, ELF is probably the shortest route. But if we want to account for patches, then LH is the shortest route.

Would you be willing to take over the additional features of ELF and work together with the other maintainer(s)?

I don't have much time to work on the module(s) myself at the moment. Of the two things ELF has that LH does not, I would happy enough to incorporate Search API support in some form, but I'm still not convinced different fallback chains per-language is appropriate for LH, given its name and stated purpose.
To be honest, I'm beginning to think that language_fallback is actually the most appropriate project name! Given that the D8 branch for LF already exists, and is nearly identical to LH's D8 code, I wonder if we should all move back to language_fallback? It would be a longer route, but perhaps the most ideal if there were no time/effort constraints?

Thanks for the input folks!
I'll spend this weekend considering the questions raised in this issue

Has a decision been made on this yet?

Trying to bring this issue back into attention again. Read up on the different threads, looks like the discussion just died out. Are non of these module no longer needed? I know there is no UI to define the fallback behaviour pr. lang in core though.