Better management of translations through branches

[surli]

Hi everyone,

our current status for development is to support several branches in parallel (LTS, stable and master at least) but as of now we are only pushing our translations on master when using our Weblate platform (http://l10n.xwiki.org). Now it does not mean we never push on other branches our translations: we do it whenever we release by applying some custom scripts to retrieve the translations, and by checking manually the diff.

This however has two impacts when we release outside master:

1. we rarely take the time to properly review this diff containing all new translations, because it’s really not user friendly, we might be in a rush, and we don’t want to take any risk (generally those are bug fix releases)
2. we don’t credit the translators when we indeed apply the translations, because we retrieve them and created new commits, and the credits we put on our release notes comes from our commits authors.

So I’m wondering how we could improve the situation, and I see for now 3 options:
A. Stop updating translations in maintained branches: we could decide that those translations should only be updated in master as they can be seen as improvments. And we should only push bug fixes in other branches.

B. On the contrary, start to automatically push every translation commit to our supported branches: we should never update a translation source when it’s committed, but create a new one according to our rules, and we should never delete any translation key according to the same rules. So the possibility to a regression should be limited, where we’d allow the community to have new languages earlier. Moreover it would allow to directly execute the CI with the new translations, so our release process would be potentially less fragile.

C. Use Weblate to support different branches of XWiki: quite frankly I have not yet thought a lot about this option, but it’s possible to configure Weblate to use a specific branch of a repository, so I guess we should be able to create new components / projects corresponding to our different branches. It would allow to maintain different translations on different branches, even if I’m not sure it would be really useful. It would also imply more work on the community to translate.

Personally I’d be more in favor of B: I don’t really see how harmful it could be to always cherry-pick our translations to our supported branches, if we follow properly our own rules. WDYT?

[vmassol]

we don’t credit the translators when we indeed apply the translations, because we retrieve them and created new commits, and the credits we put on our release notes comes from our commits authors.

The weblate translators are credited since their translations are included on master. I don’t see why they’d be credited on the branch releases since they only translate o-for master and not for branches.

C. Use Weblate to support different branches of XWiki:

IMO that’s the only real solution that can fully work because translation keys may not be the same on master and branches so from a logical POV it’s normal that we need branching at the translation level too. In practice, it would mean a very similar solution as option A since most translators would want to translate for master. But it’s still interesting since we can imagine a translator using XWiki LTS and wanting to improve translations for the next LTS bugfix release.

Option B could work (it’s what we do already but at release time). It’s just a bit more dangerous and not perfect. The issues:

• Translations that are not used (for new keys not used on the branch). That’s ok and acceptable
• Translations for keys that been deprecated. We need to be quite strict and make sure we never delete keys (instead we move them to the deprecated section). Question: I don’t remember if we display deprecated keys in the weblate UI for translators. Any idea?
• We also need to be very careful to not reuse existing keys for new purposes. We’ve seen this done recently and this can completely break the UI.
• So IMO we would need some checkers for these last 2 points, if we want to push automatically to branches, instead of letting the RM verify that. This is essentially the role of the RM ATM.
• Then we have a whole set of risks such as: we decide to rename the keys because we change some concept. For example in the past we used to talk about Spaces in the translation keys. At some point we introduced nested pages and decided to never talk about Spaces in the UI, and changed all translations. If we had pushed this automatically to the LTS we would have broken the LTS.

To summarize, if we want to push automatically to branches we might need to:

• Have an automated check to verify that keys are never removed
• Have an automated check to verify that keys don’t have a change in parameters
• Make sure we have a human review translation pushes to branches so that we are careful to not introduce wording changes that don’t have a meaning on branches. This is the bigger risk IMO.

Thanks

[surli]

I don’t see why they’d be credited on the branch releases since they only translate o-for master and not for branches.

IMO it’s irrelevant if they contributed for master or another branch. What’s revelant is that their contribution is used in that specific release. For example, if I contributed to master for a fix, and then someone else cherry-picked my commit to another branch B, I will be marked as contributor for B, even if it’s not me who pushed the fix.

Now on a more practical point of view, if we decide that’s normal to not mention the translator contributors in the other branches, then our sentence in credits is misleading:

The following people have contributed code and translations to this release (sorted alphabetically):

But it’s still interesting since we can imagine a translator using XWiki LTS and wanting to improve translations for the next LTS bugfix release.

I don’t agree with you on it being the only real solution, but yeah I also think it’s interesting I’ll try to start the discussion on Weblate side, to have more opinions about this works on other projects.

Question: I don’t remember if we display deprecated keys in the weblate UI for translators. Any idea?

I’d need to check properly on Weblate, but AFAICS in our scripts, we do import them in Weblate, we just perform some tricks when writing back the translations, so they should be normally displayed right now.

• Have an automated check to verify that keys are never removed
• Have an automated check to verify that keys don’t have a change in parameters

I agree on that, I’m wondering how much it could be done directly on Weblate side: the checks already exists when performing changes on the platform, maybe some could be triggered when pulling the changes.

Make sure we have a human review translation pushes to branches so that we are careful to not introduce wording changes that don’t have a meaning on branches. This is the bigger risk IMO.

I’m actually wondering if we shouldn’t enforce a rule such as “never edit a translation key value that have been already released.”

[vmassol]

I’m actually wondering if we shouldn’t enforce a rule such as “never edit a translation key value that have been already released.”

That would be too strict. Look at the history, you’ll find plenty of translation improvements and they make sense. Having to go through new keys is really really hard (and you loose data too) and translators cannot do this without the devs.

[vmassol]

I agree on that, I’m wondering how much it could be done directly on Weblate side: the checks already exists when performing changes on the platform, maybe some could be triggered when pulling the changes.

vmassol:

I would not do it on weblate side but in our build since it’s related to committers push changes. Ideally it should be noticed locally on the dev’s machine.

[vmassol]

I don’t agree with you on it being the only real solution

You didn’t comment on the main point I made:

Then we have a whole set of risks such as: we decide to rename the keys because we change some concept. For example in the past we used to talk about Spaces in the translation keys. At some point we introduced nested pages and decided to never talk about Spaces in the UI, and changed all translations. If we had pushed this automatically to the LTS we would have broken the LTS.

Which IMO shows that it’s the only real solution

By “real” I mean that is not hackish.

[surli]

At some point we introduced nested pages and decided to never talk about Spaces in the UI, and changed all translations.

IMO such change of concept in the UI would have need new translations keys everywhere the new concept has to be used.