Standardize language-fallback modules on entity_language_fallback

Created on 31 July 2018, over 6 years ago
Updated 1 February 2023, almost 2 years ago

After we have seen now 3 modules that duplicate this task, I'd take an attempt to join forces and standardise on one latest and greatest module. The modules are:
* Entity Language Fallback (this one, which i propose to standardise on)
* Language fallback | Drupal.org (which i propose to deprecate)
* Language Hierarchy (which i propose to deplecate)

This means
* Reach a consensus that this module (and its maintainers ;-) are the best to work with
* Implement all features that this module lacks and any of the other has (or reach consensus that there are none)
* Deprecate the other modules

List of (possibly) lacking features

(Make an issue once we agree)

* Support for interface translations, and any other fallback operations other than entity view/upcast.

Of course if my assumptions below are wrong or lacking something different, feel free to correct this here.

Reasons to propose entity_language_fallback

* All 3 modules implement hook_language_fallback_candidates_alter (entity_language_fallback, language_fallback, language_hierarchy) with no significate difference (except that language_fallback misses #2654296: Allow all entities to respect language fallback )
* entity_language_fallback supports different fallback language lists per language, while language_hierarchy - For more information about this repository, visit the project page at https://drupal.org/project/language_hierarchy and language_fallback only support one fallback language per language (which cascades then but does not allow some real world use cases).
* entity_language_fallback now contains Search API support ( #2984071: Search API support )

📌 Task
Status

Active

Version

1.0

Component

Code

Created by

🇩🇪Germany geek-merlin Freiburg, Germany

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇴Norway steinmb

    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.

  • 🇬🇧United Kingdom james.williams

    Linking a couple of issues which are for functionality that language hierarchy already has. (From my point of view, their functionality is essential. But the ELF maintainers don't seem to have recognised either as so necessary for ELF, given neither issue has progressed for over a year, despite each having already been supported in LH for much longer.)

    Even if these were resolved and the two modules could reach feature parity, the fundamental difference in approach is still whether to have different fallback chains per-language vs a single global hierarchy of fallbacks.

    FWIW, if we want to unite efforts - I'd love some help in completing the core issue about fallbacks for path aliases, which holds back each of our projects: 🐛 path.alias_repository service does not use a proper language fallback mechanism Needs work .

Production build 0.71.5 2024