Closed (fixed)
Project:
Language Hierarchy
Version:
2.x-dev
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Sep 2025 at 21:36 UTC
Updated:
24 Feb 2026 at 08:39 UTC
Jump to comment: Most recent
Comments
Comment #2
bwaindwain commentedComment #4
bwaindwain commentedComment #5
bwaindwain commentedComment #6
bwaindwain commentedImagine 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.
Comment #7
james.williamsAhh 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
$languagesarray instead of loading them again, asgetThirdPartySetting()should be available on the configurable language entities there.Comment #8
bwaindwain commentedComment #9
james.williamsThanks 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.
Comment #11
james.williams