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.
openedx/frontend-platform#786
openedx/frontend-component-header#586
openedx/frontend-component-footer#493
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.
openedx/frontend-platform#786
openedx/frontend-component-header#586
openedx/frontend-component-footer#493