How does this module differ to the Language Hierarchy module (https://www.drupal.org/project/language_hierarchy)?

Would it be better to combine efforts into one in order to cover the problem more effectively? (I suspect so)

The same question has been asked in that module's issue queue too: https://www.drupal.org/node/2145151

Comments

james.williams created an issue. See original summary.

james.williams’s picture

As pointed out in the issue in Language Hierarchy module's queue in #2145151-5: Consider deprecating language_hierarchy in favor of entity_language_fallback, there are various areas that are covered by that module but not by Language Fallback module.

I strongly suggest that these two projects should head towards a single more powerful solution by combining efforts. I have raised a patch against Language Hierarchy that is based on functionality in Language Fallback (#2565711: Handle i18n_strings) already, moving perhaps the most useful thing across. I cannot use Language Fallback as it puts things in the user session, which completely breaks anonymous page caching, which is very frustrating (particularly as I have the smart_ip module installed, but I have configured much of its functionality to be disabled... yet Language Fallback still uses it, monkeying with the user session). Is there really much of a case for continuing as two separate projects?

I don't claim that one project should become the single solution, but rather that the best parts of each where they have common solutions should be used. I see this as a similar situation to where the Apache Solr Search & Search API module maintainers ended up -- they agreed to find a best single way forward together rather than taking the community in different directions. I hope a common way forward can be found.

james.williams’s picture

Given that a D8 port has begun here in the language fallback project (based on https://www.drupal.org/sandbox/goba/2546832), but that it only covers the most basic functionality, I wonder whether it would be sensible to make that into a main 'shared' module that covers the basics of language fallback/hierarchy functionality, and then add submodules that cover the various other parts of functionality that the two D7 projects currently cover? For example, as referenced in #2145151-5: Consider deprecating language_hierarchy in favor of entity_language_fallback, these areas are covered by language hierarchy:

1. Support for node translations hierarchy (as well as for entity translation)
2. Support for menu translations hierarchy
3. Support for xmlsitemap links hierarchy
4. Supports hreflang
5. Includes automated tests
6. Support for translatable configuration, or in D7-speak: i18n_variable (#2577439: Integrate with i18n_variable which is just awaiting tests). Though perhaps core's handling of translatable configuration already uses the hook_language_fallback_candidates_OPERATION_alter() hook that is currently used by the D8 port, so is already covered?

And language fallback (which I am less familiar with, so do add to this or correct me if I'm wrong!):

1. Country-specific fallback chains
2. Integration with user geolocation (though this would need to be written to be compatible with anonymous page caching, as it is not in D7, but is enabled by default in D8, so will be even more important to resolve)

So some of the above items could go into the shared 'parent' module, and then others can go into submodules, so site builders can then choose what parts are wanted (e.g. they can opt in/out of using user geolocation, which is built very deeply into language_fallback, but won't always be wanted on sites, or the same for integration with menus, etc)

I wonder whether it would really be best to promote Gabor's sandbox to become a full project, using that 'sublanguage' namespace, as that is a more neutral ground to move forward from? Then with submodules like sublanguage_geolocation_fallback, sublanguage_menu_hierarchy, etc.

There's a lot of good work in these projects that would be a shame to miss out on by keeping the D7 functionality in separate (incompatible) projects, and D8 provides a good opportunity to unite efforts for good.

It would be good to hear the thoughts of the maintainers of Language Fallback please?

attiks’s picture

Category: Task » Plan

I like the plan, we're checking the D8 version right now.

We will make the main module very minimal to avoid any problems, and move all the rest to submodules. We definitely have to avoid the use of SESSION, so it doesn't break caching. It was added in the 7.x-2.x branch but we never used it.

1. Node translation no longer exists in D8, so I think we can skip it
2. + 3. I think these can be part of core, unless there's a good reason to have a different fallback chain for menu's and content
4. Probably part of core as well, but maybe some sites would not like to include it?
5. Yes for tests
6. I think it is covered, but I'll have to double check

Country and geo should be in a separate module

kalpaitch’s picture

Hi,

For 1. Entity translation is also important, wouldn't want to skip that. Would you consider this core functionality?

attiks’s picture

#5

Of course, sorry for the confusion

james.williams’s picture

To clarify the situation for the existing projects, especially for D7 users, please can a 'similar modules' section be added to Language Fallback's project page that includes Language Hierarchy, linking to this discussion? It's pretty common for modules to have a section like that, and it's particularly helpful for people to work out whether they are actually after your module's functionality, or something a bit different.
I've ensured this has been done for Language Hierarchy here. Feel free to copy the other related modules I've put there. Let me know if you want me to adjust the description of Language Fallback there, I tried to write something as fair as I could whilst showing why one would want to use one over the other to guide visitors to the project page.

attiks’s picture

Added a link on the project page pointing to https://www.drupal.org/project/language_hierarchy, for the moment I don't have any time to work on this, but I have no objection to phase out this module in favor of https://www.drupal.org/project/language_hierarchy.

For D7 this will be troublesome, but for D8 it might be an idea to contribute to language_hierarchy

james.williams’s picture

Thanks very much -- and any contributions are extremely welcome!! I see the D8 branch of language_fallback has started out as a good minimal base, I'd be very happy for that to exist as the start point for language_hierarchy's D8 version.

Sorry to hear that means work on language_fallback may be coming to an end -- but thank you for the hard work that has helped push the concept along in both projects.

james.williams’s picture

I've made the start of the D8 port at Language Hierarchy: https://www.drupal.org/project/language_hierarchy/releases/8.x-1.x-dev, which also includes an adapted version of the patch from #2654296: Allow all entities to respect language fallback, which was the only open 8.x issue against Language Fallback.

Given this, should the D8 version of Language Fallback be removed?

(I don't want to step on any toes, I've just gone with what I understood to have been agreed previously on this ticket.)

pacproduct’s picture

Hi all.
There is one situation where I believe language_hierarchy does not provide what language_fallback can do:
Here is my setup: I have 3 languages (en, fr, nl) and here is the behavior we're looking for:

  • When the site is displayed in EN: should fallback to FR, then NL
  • When the site is displayed in FR: should fallback to EN, then NL
  • When the site is displayed in NL: should fallback to FR, then EN

Because of the hierarchical nature of how language_hierarchy works, I don't believe the set-up above can be achieved with language_hierarchy. It works great for entities with language_fallback v2.x-dev (I'm facing some issues with menus though, see https://www.drupal.org/node/2856978).

Am I right? If so, this is something to keep in mind if the 2 modules were to be merged together.

james.williams’s picture

@pacproduct yes, that's a fair comment. Essentially, that's about defining a different fallback structure, as in your case, each language actually has a different fallback based on the originally-requested language. Feel free to raise an feature request in the Language Hierarchy queue -- patches are welcome! I suspect the implementation could be best done as a separate module or a sub-module.

kalpaitch’s picture

I remember doing this patch https://www.drupal.org/node/2654296 and it got moved to Language Hierarchy. I recall that you can have language specific fallbacks, and even context specific fallbacks, I think what you are after @pacproduct could be achieved pretty much as is with Language Hierarchy or with not too much change. I'd really suggest not duplicating work on the Language Fallback module, would be really good to get everyone working together.

Edit: I see someone got there first with a response :)

pacproduct’s picture

@kalpaitch: As is, I can't find any option for having language specific fallbacks, where exactly is that configurable?
At least for D7, which is the version of Drupal I'm using.

@james.williams: I created https://www.drupal.org/node/2858869 for addressing this specific feature request.

Any insights/leads on how to go forward with this would be valuable ^^

kalpaitch’s picture

It's part of the language configuration - /admin/config/regional/language/edit/{langcode}
Translation fallback language

That seems to be it.

james.williams’s picture

Thanks @pacproduct - let's keep the discussion about your feature request to that ticket then (#2858869: Support language specific fallbacks), especially as it's a D7 request. It's only D8 and onwards where we're sticking to one project, as D7 already has the two projects with different approaches. I think we can agree that the two separate projects are ok to exist separately in the D7 world, as it's unlikely anyone has appetite to work on merging for D7 as the solutions are relatively stable, and work should be focussed on the newer D8 versions really.

You have raised a good point generally though, that since the LH and LF projects have fundamentally different approaches, there may be use-cases that don't quite fit a single project. So let's keep an open mind to that, but concentrate efforts on a single project where possible. If solutions are required that can't be done that way, we can think again, possibly branching from the same starting point at least. For now though, the D8 functionality is relatively basic (though does a good job), so efforts should be focussed on more essential functionality (see #2825186: META: Drupal 8 version (D8) of Language Hierarchy roadmap for our initial plan).

pacproduct’s picture

@kalpaitch: Aah sorry yes, sure that's where it is for the language_fallback module.

But because you said "I think what you are after @pacproduct could be achieved pretty much as is with Language Hierarchy" I thought you meant that I could do it with the language_hierarchy module too.

@james.williams: Alright I understand, no worries :)

geek-merlin’s picture

@attiks wrote in #8:

Added a link on the project page pointing to https://www.drupal.org/project/language_hierarchy, for the moment I don't have any time to work on this, but I have no objection to phase out this module in favor of https://www.drupal.org/project/language_hierarchy.

For D7 this will be troublesome, but for D8 it might be an idea to contribute to language_hierarchy

So @attiks it would be a good thing to unpublish the D8 branch from language_fallback, to minimize confusion. Tentatively setting the module to dupicate in #2593903: [language_fallback] Language Fallback.

geek-merlin’s picture

Version: 7.x-2.x-dev » 8.x-1.x-dev
beltofte’s picture

@axel.rutz: Is the functionality really overlapping? Language Fallback support some use cases not supported by Language Hierarchy. For example that the same language can be fallback language to several other languages, or that a language can act both as primary language, but also be fallback language to other languages. Lets say that my site has both Danish, Norwegian and Swedish languages enabled. I want Danish to be fallback to both Norwegian and Swedish, and Norwegian as fallback to Danish. This use case is not possible with Language Hierarchy.

I have personally 14 days published https://www.drupal.org/project/entity_language_fallback on d.o after it has been living in our own Github for some months. This module support a prioritised list of fallback languages set per language. So no hierarchy. See #2948100: Comparison with language hierarchy? for more details about the differences.

james.williams’s picture

Is the functionality really overlapping? Language Fallback support some use cases not supported by Language Hierarchy.

For D8, the functionality is currently one & the same (excluding a single commit added to LH), hence axel's suggestion to unpublish the D8 branch from language_fallback. The suggestion to 'merge' modules, or at least work in one or the other, is to get as much of the shared functionality done, without duplicating effort.

Lets say that my site has both Danish, Norwegian and Swedish languages enabled. I want Danish to be fallback to both Norwegian and Swedish, and Norwegian as fallback to Danish. This use case is not possible with Language Hierarchy.

This sounds like you're creating a circular fallback chain? Danish -> Norwegian -> Danish? I'm surprised if language_fallback supported that. language_hierarchy won't, because it enforces a single strict hierarchy tree. You can at least chain languages though, so both Norwegian & Swedish could fall back to Danish. I haven't tried it, but there wouldn't actually be anything at the moment to stop you selecting Norwegian as a fall back to Danish too, but I'd expect bugs!

james.williams’s picture

I've just done a brief review of the entity_language_fallback module's code, it looks to me as though it only supports nodes? Language hierarchy (even its D8 version) supports any type of content entity, interface translations, and anything else that uses the hook_language_fallback_candidates_alter() hook.

So the only feature that entity_language_fallback provides that LH does not, is to allow different fallback chains for different original request languages. (Whereas LH enforces a strict single hierarchy.) Otherwise LH has many more features than entity_language_fallback. Perhaps the latter should be renamed to node_language_fallback to better reflect it's more specific feature set?

geek-merlin’s picture

#22: Thanks for bringing entity_language_fallback into the game.

So let's look at the code:
* language_hierarchy
* language_fallback
* entity_language_fallback

Each and every one is essentially a 10-liner implementation of hook_language_fallback_candidates_alter().

There are minor differences:
* one more commit in language_hierarchy than language_fallback
* entity_language_fallback is restricted to nodes, and OTOH has multiple fallbacks per language. (which i don't see the use case of, but maybe there is one)

So the issue is primarily not about code, but to
a) agree on one module and deprecate the others
b) merge in what is needed

james.williams’s picture

Thanks for the summary Axel. I recognise I'm biased as a co-maintainer of LH by the way, so weigh what I say appropriately!

I would also point out one other difference - maintenance status & future plans.

language_hierarchy has a number of open tickets around extending the D8 functionality, whereas the others don't. (More patches & contributions are very welcome! I haven't had much time to spend on the project myself recently, but that doesn't need to hold it back.)

entity_language_fallback appears to be more actively maintained, although on the other hand, that could just be because its new - there have only been 3 commits, all made on the same day, and nothing since. It's biggest contribution to the scene is allowing different fallback chains per original request language, which I do recognise as a potentially useful thing. Maybe that could be a sub-module or a setting in LH, I wonder? It could quite seriously affect the UI though. Ideally, LH would show the hierarchy on the language overview page (like vocabularies) (work in progress at #2825187: D8 languages overview UI and language edit page), but that wouldn't make sense for different fallbacks per-language. Maybe we should handle that just like core does with vocabularies, supporting the possibility of multiple hierarchies? Some more thought might be needed, but anyway, it's a possibility.

So my suggestion would be to proceed with language_hierarchy as the single module for all these use cases, with a new ticket opened to allow for multiple hierarchies (and any tickets for any D7 language_fallback-specific functionality that might be wanted too, like geolocation integration or country-specific languages/fallbacks). We'd already followed through on this when this duplicate module question arose between language_hierarchy & language_fallback, I see no reason for things to be any different with entity_language_fallback.

I'd like to hear back from the entity_language_fallback maintainer (beltofte) really though please!

geek-merlin’s picture

> I'd like to hear back from the entity_language_fallback maintainer (beltofte) really though please!

Did you ping him? Or want to?

> So my suggestion would be to proceed with language_hierarchy as the single module for all these use cases, with a new ticket opened to allow for multiple hierarchies.

I'd be all for this.

If you take the other maintainers aboard and we fiddle out together how to do-the-right-thing(tm), we'll all win.

geek-merlin’s picture

Title: Duplicate module? » Consider deprecating in favor of Language Hierarchy
beltofte’s picture

Sorry for not responding before. Is extremely busy with a large tender to be delivered soon. ¨

> * entity_language_fallback is restricted to nodes, and OTOH has multiple fallbacks per language. (which i don't see the use case of, but maybe there is one)
This is definitely a mistake that it is restricted to nodes.

In regards to multiple fallbacks, then is our use case a situation like:

  • Primary language (fallback languages in prioritised order)
  • Swedish (Norwegian, Danish, English)
  • Danish (Norwegian, Swedish, English)
  • Norwegian (Danish, Swedish, English)
  • English (no fallback)

A comment posted elsewhere mentioned that this could cause a loop or circular fallback situation. I have tested this (manually) with different nodes with and without translations to some of the languages, and not been able to trigger such situation.

I fully agree that merging all the modules makes most sense. Language Hierarchy has the most attraction, so this module should of course be the one that is not marked as "duplicate". I'm close down Entity Language Fallback and mark it is as duplicate, as long as Language Hierarchy get support for multiple fallback languages.

As I mentioned in the beginning, then am I really busy till end of next week. Might be able to find some time after next week to help with the merger.

james.williams’s picture

@beltofte thanks for finding the time to reply, I appreciate that sometimes discussions need to slow down to accommodate everyone. We don't need to rush to deprecate anything, as long as we can move towards agreement, which it sounds like we have. Hooray!

By the way, I don't have much time to work on the merger either, so I'm quite happy to find a compromise between what's best in the long-term and what needs doing sooner.

I'm quite happy for entity_language_fallback to remain open whilst it is the only one providing different fallback chains per-language, which is exactly the use case you have outlined. (I'm glad to hear you don't run into looping issues with it!) From your example, Language Hierarchy can't currently cover these two points (and others):

* Swedish (Norwegian, Danish, English)
* Danish (Norwegian, Swedish, English)

In the first chain, the parent of Swedish is Norwegian, but in the second, its parent is English. LH enforces each language to only ever have a single parent. (This is what I mean by 'multiple hierarchies'.) I do think your use case is mostly focussed on customising the order of existing fallbacks provided by core, to be different for each request language, rather than narrowing the list of fallbacks? (Please correct me if I'm wrong!) I would say that LH's current use case is to narrow the list of languages used as fallbacks for a language, using a single global hierarchy. That last clause could be up for debate, as your use case has helped us recognise that a single global hierarchy might not always be helpful.

This hypothetical question might help focus the projects: Would you want to handle additional languages on your site that should never be included as a fallback for your existing European languages? e.g. Japanese. Drupal core would allow that as a fallback, while language_hierarchy makes it possible to avoid ever using that as a fallback for other languages, or using other languages as a fallback for it.
If entity_language_fallback simply doesn't need to cover that use case, then it is only really ordering fallbacks, not restricting the existing set of fallbacks provided by core.

Anyway, I suggest two options to move towards then:

1) entity_language_fallback could remain open as a project, if it was clearly about ordering the existing fallback chain for each individual language. If it focussed that way, I can quite happily see that as a simpler alternative to LH for sites that need that. I think the minimum work required for this is probably to change the project page descriptions to be clear about this, perhaps comparing the use cases, or carefully stating the different aims. (Although I wonder if changing the project name might also be worthwhile.) I've already added a brief mention of entity_language_fallback on the language_hierarchy project page.

2) Multiple hierarchies could be introduced as a new feature to language_hierarchy, and once that is at the point of feature parity with entity_language_fallback, then entity_language_fallback could be deprecated/closed. I'm quite up for this, but I think this option might be more work?

As for entity_language_fallback being restricted to nodes, I can raise an issue against your project for you if you like? Here's the line that restricts it: https://cgit.drupalcode.org/entity_language_fallback/tree/entity_languag...

geek-merlin’s picture

Title: Consider deprecating in favor of Language Hierarchy » Consider deprecating in favor of entity_language_fallback
Status: Active » Postponed
Related issues: +#2989537: Standardize language-fallback modules on entity_language_fallback

So i give this another push via related issue. Postponing this to tentatively discuss in the other one. Hope we can build trust and join forces.

geek-merlin’s picture

Title: Consider deprecating in favor of entity_language_fallback » Consider deprecating language_fallback in favor of entity_language_fallback