openedx / openedx/openedx-platform
Make dark_lang work in MFEs or deprecate it
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 8.2k
- Forks
- 4.4k
- Avg merge
- 6d 18h
- Merged PRs (30d)
- 42
Description
Background
The "dark_lang" app is an admin-only feature that lets you preview the site in unsupported languages, like eo (a fake version of "esperanto"). Unfortunately it doesn't seem apply to MFEs. It only manifests legacy frontends, the latter of which are almost all disabled by default.
Furthermore, its interface (at <LMS_ROOT>/update_lang) is a legacy frontend itself, so we'll need to port it to an MFE, or accept that it's an admin-only feature.
For context, we learned of this issue while implementing:
in which we removed the legacy Studio version of the frontend so that we only had only legacy frontend (the LMS one) to deal with.
Tasks
- Consult with product: Do we want the ability for admins to preview the site in not-yet-supported languages?
- If no: Deprecate and remove the entire app.
- If yes:
- Consult with product: Does it need to be an interface, or is Django admin OK?
- If Django admin is OK: Deprecate and remove just the UI; keep the app available via Django admin.
- If we need an interface: Create a ticket to reimplement the UI in an MFE
- In either case: Create a frontend-base(?) ticket to propagate the preview language setting into frontend apps as an override to the user's language setting.
- Consult with product: Does it need to be an interface, or is Django admin OK?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review issue #36277 and the dark_lang app, including the legacy <LMS_ROOT>/update_lang entry point. Start by confirming the product decision about admin language previews; done means documenting the chosen path and creating the specified follow-up work for removal, Django admin support, MFE reimplementation, or frontend-base propagation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- backend, frontend, localization
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100