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