In the OFN stack we use Transifex to manage locales for all the different languages/regions OFN is starting to support.
Currently the process goes a little something like this:
Code changes are made in which some translatable text is updated or added. This change is always made in en.yml and possibly in one or more translation files at the same time, particularly if the developer was not in Aus.
When a release is created @maikel pushes the release to our transifex branch on GitHub so that any recent changes to the en.yml locale file are picked up by Transifex.
Transifex does some magic and all the other local files are updated to require the same translation strings as the en.yml file.
Translators around the world manually make changes to their locale files within Transifex.
Whenever a translation is complete, it triggers our CI server which commits these translations to the transifex branch and pushes to Github.
People can deploy the transifex branch to get the latest release with translations or do some manual work.
Just before the next release, Maikel merges the transifex branch into the master branch manually. There can be conflicts if people touched locales other than en.yml. Sometimes we forget to do this step, especially if @maikel is not the one who does the release.
In our ideal future world, among other things (many unrelated to this issue), we would like:
To clarify release management so that there is a clear process that avoids forgotten branch merges
To decouple the translation process from the Aus team as much as possible, to take it off their plates.
Something else we are thinking about in the Oz team are looking to decouple the release process from the Australian build pipeline so that we work in the same way as all other instances. Another step in us letting go of control as more dev teams come onboard around the world
Thanks Lynne, it’s great to document this to better understand how it works and how we can change it. The current state is actually a bit more advanced already. Maybe you can incorporate the following into your post.
Transifex is configured to pull the en.yml file from Github automatically. This happens once a day. But it’s not pulling from the master branch due to release management.
The release management problem is that most other groups don’t use the master branch, they use releases. If we would translate only the master branch, we wouldn’t have a matching locale for the last release. We need to translate the latest release.
So first we code, then we release. And afterwards other people can translate. That means that a release never contains all translations.
We decided to create the transifex branch on Github. The process is this:
We release.
We push the released version to the transifex branch.
Transifex downloads the released en.yml from that branch.
People start translating.
Whenever a translation is complete, it triggers our CI server which commits these translations to the transifex branch and pushes to Github.
People can deploy the transifex branch to get the latest release with translations or do some manual work.
Just before the next release, I merge the transifex branch into the master branch manually. There can be conflicts if people touched locales other than en.yml. Sometimes we forget to do this step, especially if I’m not the one who does the release.
Now it starts with step one again.
That’s the best we have come up with so far. If we wanted to avoid the conflicts, we would need a translate window before every release. It would look like this:
Before a release we declare a language-freeze.
The master branch can’t change in any way that would affect locales.
People translate into there languages on Transifex.
Complete translations are automatically pushed to the master branch.
We release at the end of the language-freeze period.
Later translations will be included in the next release.
But we thought that our development speed is too quick to ensure a language-freeze period. It would also require all translators to be at call for these periods.
Or, if we would translate only master, then translators would need to check Transifex all the time for updates and be quick to translate and review before a release. That’s probably unrealistic as well.
So maybe the solution is more about release management than about Transifex? It would be great if Transifex would understand versioning, but I haven’t seen it yet.
I emailed the support after we had some complaints about lost translations. Here is an interesting part of the email I got:
1. New strings that are being added to your source file are considered as new ones. They will appear as untranslated in the editor so that translator users can easily identify the new content that should be translated.
2. Modified strings (values/source text) are considered as new ones as well.
This means that after source file is updated, the previous translations won’t be available in the translation area anymore BUT they can be found in the translation history of each string since we keep track of previously submitted translations.
For example, let’s assume that the initial version of your source entry is the following one:
FORGOT_PASSWORD: “Forgot my password?”
and the string has already been translated in Transifex.
If you replace the above entry with the following new version:
FORGOT_PASSWORD: “Forgot password?”
after updating your source file, Transifex will identify that your text has been modified which means that the translation of this string should be evaluated again.
That’s why the translation is removed from the translation area and the string is considered as an untranslated one. However, the translation history of the string can be found under the History tab in the editor so your translators can rely on it in order to properly re-translate the string.
3. Modified strings (keys/identifiers) are considered as new ones.
This means that after source file is updated, the previous translations won’t be available in the translation area anymore AND also the translation history of the string won’t be available as well.
However, keep in mind that old translations are kept in the Translation Memory of your project. So, if the feature “Fill up resources from TM” enabled, TM detects the old strings and automatically kicks in all the previously submitted translations if the match is 100%.
In case the match is not 100% but other matches are found then they come in the editor as “Suggestions”.
A translation is successfully submitted when your translators hit the save button. After that, the translation string is automatically added to your Translation Memory instance and it is used as a suggestion for future instances.
Any strings that have been translated before the updates take place will lose their translation if their text or key is modified.
At the global meeting today a step to improve the current process was mentioned. We already have a branch called “transifex” at Github. All completed translations are committed to it. I have to manually merge that branch into the master once in every release cycle. The new idea is to automatically create a pull request in each release cycle. That makes the process more transparent. Merging would be as easy as clicking one button. And that pull request can be added to the current milestone so that it’s not forgotten in a release cycle (any ideas how to do that manually?)
