/
Notes and TODOs on the i18n workflow

Notes and TODOs on the i18n workflow

Owned by Omar Al-Ithawi
Last updated: Mar 24, 2023
2 min read

Repos notes

RecommenderXBlock

It needs a refactoring to remove Mako templates, extract Mustache templates.

Admin Portal MFE

May not need i18n.

Transitioning into Atlas workflow

Mar 20, 2023

  • Cut off date.

  • Option 1: Have both systems working at the same time. (“low downtime strategy”)

    • Adds a bit of overhead

    • Leaves

      • Sarina: XBlocks might could have a more aggressive cut off as long as we bump a version

      • Sarina: MFEs, edX Platform and other “root” repos deploy from master, while others like XBlocks and packages are versioned.

      • Sarina: Big PR template so new reviewers will understand it

      • Omar: Use feature flags (waffle) to have two i18n service for XBlocks

  • Option 3: Use feature branches

  • Option 2: Break the old bot as we work (“with downtime”)

    • Bumping a version e.g. v3.1.2 → v4.0.0

  • Sarina: Next release Palm is going to be cut on ~ April 10th.

  • Sarina: Write a docs.openedx.org/source/developers at main · openedx/docs.openedx.org

  • Brian: Test the XBlocks is part of this project

Atlas

LMS/CMS: XBlock merge and JavaScript i18n:

There’s a little known feature in XBlocks which makes them self-contain the i18n scripts in two ways:

  • Python translations are merged and managed via the i18n service.

  • JavaScript translations are self-contained via an object e.g. DragAndDropi18n.

Suggestion: Make Atlas manage and merge those files into the platform on build/deploy time. But atlas is written in shell, which makes it rather limited for such operations.

LMS needs to pull the following set of message:

  • All relevant LMS messages (loaded directly via Django)

  • All included XBlock set of messages (loaded via the new i18n service)

    • Brian: The constrain is to make the Developer Experience easier to update everything: make pull_translations in edX Platform works fine, that’s a

    • Sarina: Keep i18n docs in a single place except for the gotchas on the specific packages

    • Sarina: Outside the scope of this project, how to use i18n service to test Esperanto fake strings

MFEs and dependency translations

MFEs tend to have more than a set of messages for example:

  • A single MFE could have messages from:

    • paragon

    • messages from content-components-frontend-lib

    • the messages of the micro-frontend itself

Suggestion: Make Atlas manage and merge those files into the MFE on build/deploy time. But atlas is written in shell, which makes it rather limited for such operations.

 

Learning MFE needs the following set of messages:

  • Paragon:

    • Omar: keep translations outside paragon

  • Special exam components

  • Learning MFE

 

Related content