Follow-Up Work

Compilation Error Prevention

CI Check

CI compilation linting check to ensure translation files are valid and correctly formatted. In some repos its part of quality. (link to original comment)

openedx-translations

Branches

When a new release is cut, a new branch of the translations corresponding to the release branch will also be made. And then a new project can track that branch on Transifex. We can update the GitHub Action to run for multiple branches to keep the translation source files for the new release up to date. And with every new release, the old release's Transifex project will be archived, but the translations will still be available on GitHub in the old release's branch.

The first outstanding issue to this approach would be making sure that Translators have access to this new project as well. It will be up to the Translations WG to manage the latest translation files for the entire platform as well as minor fixes to the latest release. (link to original comment)

Maintenance

It may be unreasonable to expect any one group to maintain openedx-translations as there are lots of stakeholders. Translators are expected to translate, but may not get to see if their translations will cause errors. Developers may see that there are errors, but may not understand the language of the translation. There will have to be cooperation. (link to original comment)

Issues

We should set up an issue request form on openedx-translations (much like the Github Requests in tcril-engineering) that notifies the Translations WG on slack when there is a translation error that needs to be fixed. This way, Translators can be notified of an error in a way they will be able to digest it, and Developers can write the problem and proposed solution in a way that is common to them. (link to original comment)

Intermittent Folder

Create an intermediate "repos" folder, such that we have openedx-translations/repos/edx-platform. Otherwise we will have a lot of repos located at the root, which will quickly become unwieldy. And if we need extra translations-specific folders at the root (e.g: "docs"), they will be mixed with repo names. (link to original comment)

openedx-atlas

Scripting

Release openedx-atlas in binary format, so developers wouldn't have to think about their python version when they want to install it, which can be useful specifically in MFEs development. And make CI/CD workflow more efficient as well. (link to original comment)

Having atlas built in python adds complexity to the deployment of MFEs. It seems there are a few paths that we could go down:

• The first option would be to keep atlas in python, and to use the python implementation everywhere

• Another option would be to write atlas in bash, that way python would not be required in build/deployment environments for MFEs

• A third option would be to also write atlas functionality in js and package for NPM so MFEs (or frontend-build) could import it (link to original comment)

• a fourth option: get rid of openedx-atlas, and publish releases of .tar.gz/.zip files from the openedx-translations repository (link to original comment)

Additional Parameters

Add a feature to openedx-atlas CLI tool that is able to pull a specific commit from openedx-translations, along with a specific branch and directory. This way you can fully customize which translation files you want to use, instead of using the latest version or a version tied to a named open release. (link to original comment)

Third Party Extensions

The openedx-atlas CLI tool can pull translation files from any repository that works with git. And the GitHub Action that generates translations and moves them to openedx-translations can also be reappropriated for private repos. The work involved will be: copying the github action that generates the translations to another repository, changing the organization and names of the repos, and attaching it to a separate Transifex project via the app. (link to original comment)