Problem/Motivation

The form allows two languages to fallback to each other, creating a loop, which can cause problems (yes, we had this happen on a site!).

Proposed resolution

Remove the used language <option>s from the <select> list.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

bwaindwain created an issue. See original summary.

bwaindwain’s picture

Issue summary: View changes

bwaindwain’s picture

Status: Active » Needs review
bwaindwain’s picture

Issue summary: View changes
bwaindwain’s picture

Imagine a website with 3 languages:

1 English
2 + Swahili
3 + + Pokomo (default)

With the drag-n-drop, I can set language hierarchy correctly (Pokomo > Swahili > English). But, what if I want Pokomo (the default) at the top of the list in the language switcher?

Our org is hosting 1400+ minority language websites, many have 3 or more languages. But we have update status module turned off.

james.williams’s picture

Status: Needs review » Needs work

With the drag-n-drop, I can set language hierarchy correctly (Pokomo > Swahili > English). But, what if I want Pokomo (the default) at the top of the list in the language switcher?

Ahh that's a great question, and that really helps me understand where you're coming from - thank you! The order in the switcher block is a separate piece of functionality that can be dealt with separately. hook_language_switch_links_alter() allows specifically adjusting the links in the switcher - including changing their order. I've already got that on clients' sites that I use Language Hierarchy on, because yes, customisations to the language switcher are often needed, which are beyond the scope of what LH can provide. But I can now see how arbitrary language sorting in the way you describe is currently possible as useful for this anyway. So my suggestion of forcing the drag-and-drop for configuring the hierarchy could be unnecessary, if we can address the original problem in another suitable way.

The actual merge request is now very close to being acceptable. We have an open unresolved thread about just getting languages from the existing $languages array instead of loading them again, as getThirdPartySetting() should be available on the configurable language entities there.

bwaindwain’s picture

Status: Needs work » Needs review
james.williams’s picture

Status: Needs review » Reviewed & tested by the community

Thanks for working hard on this! I'm happy and have set this to merge. If we wanted to improve this further in future, I suggest we find a more efficient way of iterating through all the languages. But at least they won't be repeatedly loaded now, which was my bigger concern.

james.williams’s picture

Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.