Repository navigation
Allow users to change the site language from anywhere in the UI #558
Description
Description
Open edX ships in a large number of display languages, but a user's ability to switch between them depends on where they happen to be. The control exists in some parts of the platform and not others, in different places and different forms, and code that wants to offer a language change has no single supported way to ask for one. The result is that switching language is harder to find than it should be for a setting that changes every word on the screen.
This epic covers making language switching a consistent capability of the platform rather than a feature of particular pages.
What this looks like when it is done
A user can change the language they see from wherever they are. The control is in a predictable, prominent place, it is the same control everywhere, and reaching it never requires abandoning what they were in the middle of. It offers the languages the site actually has available and makes the current one obvious.
Changing language takes effect immediately and completely. The page they are looking at is in the new language, so is the next one, and so is the platform when they come back tomorrow. Right-to-left languages lay the interface out correctly. If the change cannot be completed, the user is told, rather than clicking a language and watching nothing happen.
For a signed-in user the choice belongs to their account, so it follows them to other devices and sessions and agrees with what their account settings report. Anyone can switch, signed in or not, and a choice made before signing in behaves predictably afterwards rather than being silently overwritten.
For anyone building on the platform, changing the current user's language is one supported call that does the whole job, so no application has to reassemble the steps for itself or risk leaving a user half-switched.
For operators, the control is theirs to place or remove, how it labels itself is theirs to choose, and the set of languages it offers reflects what they have actually made available on their site.
Out of scope
This is about changing the language a user sees, not about which languages exist or how good they are. Adding, releasing, and improving translations is handled elsewhere and is unchanged by this work.
Related work
Two pull requests proposed this capability and are useful as prior art, though neither was merged and the platform has since covered some of the same ground.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
- Status
Activity
[-]Allow users to change the site language from anywhere in the UI[/-][+]Make site language switching a shared, reachable capability[/+][-]Make site language switching a shared, reachable capability[/-][+]Allow users to change the site language from anywhere in the UI[/+]edschema commentedon Aug 13, 2026
Adding a couple quick sketches. Note: I think we should consider a couple things: 1. using the full language name where possible (ie dropdowns, etc). the i18n codes aren't really common knowledge for most people so I'd prefer either the full language or no label. and 2. removing the border from AvatarButton.
We can consider how the top bar should appear in narrow viewports as well.
Option A: Full language text
Option B: Icons only
maguilarUXUI commentedon Aug 26, 2026
I'd lean towards Option A's approach, showing language context (not just the icon) since it gives users immediate confirmation of the selected language without needing to click. For narrow viewports, we could abbreviate progressively instead of switching to icon-only: e.g. "English ⌄" on wider screens, "EN ⌄" as the viewport narrows, keeping the globe/context but adapting the label length to available space.
This way we don't lose the "which language am I in" context Option B lacks, while still solving the space constraint you flagged for narrow viewports.
What do you think @edschema ?
edschema commentedon Aug 26, 2026
I agree, full language is best. I don't know if there is a clean abbreviation to use for a narrow viewport... We should consider collapsing to just the icon for small viewports (plus down chevron), since I think the other information on the top bar is much more important in common use cases, but whatever the team thinks I support!
dcoa commentedon Sep 7, 2026
Thank you @maguilarUXUI @edschema I am working on this and already apply the Option A for desktop. However, for mobile I feel on small screens (<576px) it is cramped even adding only the icon, and I would like to have your expert opinion here. I am using
frontend-basetest site that has the basic header.I has thinking what could be a possible solution. I have 2 ideas but I am not sure what gives better user experience or if there is a better solution.
So the ideas are:
maguilarUXUI commentedon Sep 14, 2026
I think the language option could also live inside the menu once the screen size becomes too small to support that many options in the header. I also think it would be a good idea to place it near the top of the menu rather than at the end, so we don't sacrifice too much discoverability. What do you think? @dcoa @edschema
edschema commentedon Sep 18, 2026
adding to the menu makes sense. I'd put it at the bottom of the menu because of frequency of daily use, but thats just my opinion!
arbrandes commentedon Sep 22, 2026
This is live in the master sandbox (https://master.openedx.io). Thanks @edschema and @maguilarUXUI for the design, and for the implementation, @dcoa!
Please review!