Description
frontend-base already performs a complete language switch, in updateSiteLanguage (shell/footer/data/api.ts): it saves the pref-lang account preference, posts to the LMS setlang endpoint, and calls updateLocale. Four things keep it from meeting the goals of openedx/public-engineering#558.
Make it callable
It is private to the shell footer and exported by neither the footer nor the runtime, so nothing else can offer a language change without reimplementing it. Move it into the i18n runtime alongside getLocale and updateLocale, export it, and document it as the supported way to change a user's language, leaving the footer menu as an ordinary consumer.
Stop depending on the server to set the cookie
updateLocale takes no locale. It and SiteProvider both re-read getLocale, which reads the language cookie, and nothing in the frontend ever writes that cookie. The switch therefore only appears to work if the setlang response's Set-Cookie arrives first, which depends on the deployment having SHARED_COOKIE_DOMAIN covering the MFE. Where it does not, every call succeeds and the interface silently stays in the old language. Set the cookie client-side, or pass the new locale through updateLocale, so the change does not depend on a server round-trip side effect.
Report failures
Neither network call is guarded and the footer's call site does not await. A failed preference save skips updateLocale entirely, so the user picks a language and nothing happens, with no indication why. Errors need to reach the caller so it can show a pending or failed state.
Work for anonymous users
They have no preference to save, but the current path reaches for the authenticated HTTP client regardless. Confirm the switch works signed out, and decide what happens when a signed-out choice is followed by a sign-in carrying a different saved preference.
Context
Prior art from the previous framework, proposed but not merged: openedx/frontend-platform#786
Description
frontend-base already performs a complete language switch, in
updateSiteLanguage(shell/footer/data/api.ts): it saves thepref-langaccount preference, posts to the LMSsetlangendpoint, and callsupdateLocale. Four things keep it from meeting the goals of openedx/public-engineering#558.Make it callable
It is private to the shell footer and exported by neither the footer nor the runtime, so nothing else can offer a language change without reimplementing it. Move it into the i18n runtime alongside
getLocaleandupdateLocale, export it, and document it as the supported way to change a user's language, leaving the footer menu as an ordinary consumer.Stop depending on the server to set the cookie
updateLocaletakes no locale. It andSiteProviderboth re-readgetLocale, which reads the language cookie, and nothing in the frontend ever writes that cookie. The switch therefore only appears to work if thesetlangresponse'sSet-Cookiearrives first, which depends on the deployment havingSHARED_COOKIE_DOMAINcovering the MFE. Where it does not, every call succeeds and the interface silently stays in the old language. Set the cookie client-side, or pass the new locale throughupdateLocale, so the change does not depend on a server round-trip side effect.Report failures
Neither network call is guarded and the footer's call site does not await. A failed preference save skips
updateLocaleentirely, so the user picks a language and nothing happens, with no indication why. Errors need to reach the caller so it can show a pending or failed state.Work for anonymous users
They have no preference to save, but the current path reaches for the authenticated HTTP client regardless. Confirm the switch works signed out, and decide what happens when a signed-out choice is followed by a sign-in carrying a different saved preference.
Context
Prior art from the previous framework, proposed but not merged: openedx/frontend-platform#786