Right now if you run yarn run i18n-download-translations from a clean repo, it will delete kolibri_explore_plugin/locale/es_419/LC_MESSAGES/*.json. This is because that process converts the translated strings in the CSV files into the JSON format consumable by formatjs. If the CSV files aren't present in the repo, then kolibri-tools i18n-create-message-files deletes the associated JSON files since are no translations. This works for LE because the CSV files are managed in crowdin and actually downloaded at the time this is executed.
As a corollary, i18n-extract-messages explicitly only generates en CSV file. I presume that's then uploaded to crowdin where it's merged with the existing CSV files for other languages.
Since we have no such "download" process, the CSV files should be checked in to the repo. And, sadly, I think we're going to have to manually handle the merge when the en version is updated. I have a feeling we're going to have to write our own tooling for this longer term.
Right now if you run
yarn run i18n-download-translationsfrom a clean repo, it will deletekolibri_explore_plugin/locale/es_419/LC_MESSAGES/*.json. This is because that process converts the translated strings in the CSV files into the JSON format consumable by formatjs. If the CSV files aren't present in the repo, thenkolibri-tools i18n-create-message-filesdeletes the associated JSON files since are no translations. This works for LE because the CSV files are managed in crowdin and actually downloaded at the time this is executed.As a corollary,
i18n-extract-messagesexplicitly only generatesenCSV file. I presume that's then uploaded to crowdin where it's merged with the existing CSV files for other languages.Since we have no such "download" process, the CSV files should be checked in to the repo. And, sadly, I think we're going to have to manually handle the merge when the
enversion is updated. I have a feeling we're going to have to write our own tooling for this longer term.