a new translation staging setup
so, now that we are on gitlab, i want to try a different setup for the branches we have with more languages that are being translated.
when contributors are translating a website, if they have a preview available their translations are better, they self-learn and are closer to the web development process, giving out solutions for problems they encounter or reporting bugs.
so we have this translation 'staging' site, where they can see the locale they are translating. this is a lektor very similar to the one in production, but i also add more languages to its configuration and sometimes delay the content a bit whenthe strings are not ready for translation.
currently, we have this setup:
- one branch in each lektor, called
translations, i.e. https://gitlab.torproject.org/tpo/web/community/-/tree/translations
- special versions of the 3 configuration files we need to edit to add new languages on the branch
- once in a while i merge the content changes from the master branch on it, generate a new translation file, and commit
- transifex checks that file twice a day and updates their system.
- when new translations arrive, they (used to) trigger a build on https://lektor-staging.torproject.org/community/translations/ with all those extra languages. so if you are translating you can see your changes on the website like 2 hours later.
what i want to do now is build the translations branch dynamically:
- have a gitlabCI job (a version is available at https://gitlab.torproject.org/tpo/community/l10n/-/blob/main/ci-templates/lektor-with-more-langs.yml)
- this is triggered by pushes to https://gitlab.torproject.org/tpo/translation/, for example for the community branch by adding this gitlab-ci.yml file to the branch: https://gitlab.torproject.org/emmapeel/translation/-/blob/communitytpo-contentspot/.gitlab-ci.yml
- when a change comes from transifex (or weblate in the future), the changes on the community portal trigger the lektor job, and a build:
- overwrite with special config files hosted on this repo
- generate the staging site and the translation file
- when i am happy with the state of the strings, i can commit the i18n/contents.pot file somewhere where transifex (or later weblate) will pick it. maybe on the main website, as a submodule.
(i want to be able to audit the strings before they go to translation, because otherwise many times we make translators translate several small deviations from the same strings, which is really boring. since i practising gatekeeping, i got positive feedback from the translators about finding 'real strings' to translate. other things i do is to try to translate strings when they have changed small details like an end period, or a change of link, so the translators that speak that language can concentrate on the real content to translate, and dont need to retranslate the same string only because the link has changed.)