Hi everyone,
while browsing the documentation of Weblate this morning I had a new idea for providing support of translations to multiple branches for XS.
To sum up quickly the context: in XWiki Standard we want to have translations provided to the main branches of our repository, but we also want to have them propagated to the supported branches (e.g. LTS). Right now, the process is to backport the changes with some scripts during the release, but it’s currently tedious and error prone, and at the moment we regularly avoid doing those backports to avoid breaking something.
The idea I have is fairly simple: it consists in duplicating every components in Weblate for all supported branches, and to configure those components to pull and push on their branches, and to use a smart little configuration name “Allow translation propagation” which ensures that all translations related to the same key are propagated in different components.
There’s several benefits of this solution:
- we would really only translate what is in the source translation file in the given branches, we won’t have risk anymore to wrongly backport translations changes
- obviously the release process would be simplified a lot
- we manage everything from Weblate itself: no other tooling,
no need to extra script anywhere(edit: not really true actually, see below)
And I can see at least 3 major problems:
- it will create a lot of components in Weblate, and AFAIU from the “Allow translation propagation” they’ll need to be put in same Weblate Project for that config to work. So for example in XWiki Platform project in Weblate, right now we have 124 components: we’d need to multiply this by the number of branches we support, so it would be around 124 * 3 branches = 372 components in Weblate for that project (the biggest one)
- we will need to handle the creation and deletion of those components in Weblate when a new supported branch is created/deleted (or maybe to update their branch info)
- we will get more Weblate PR to handle: any propagated translation will create other PR(s) for the branches it impacts
For point 1, there’s 2 aspects, a performance aspect on Weblate, and an organizational aspect to not loose everyone with duplicated components. For the performance aspect, I don’t think it’s a real issue: we never had performance problems in the past, I might investigate a bit more on the subject but I believe it should fit on the current machine. For the organization aspect, one of the first idea I have is to use Weblate “Categories”: those can be seen as “folders” in the UI where we can put other categories and/or components. I started to use them to organize a bit the components already in XWiki Platform (e.g. the xwiki-platform-extension category), we could add another layer such as one category per branch, and then reorganize below those categories. We could also check to use labels, but I think it might not be enough as we would still see all components when accessing the UI. An important thing also will be to have proper naming for the component on branches to identify them quickly in UIs that might present several components at once (and for administration tasks). Now another idea to be discussed for helping translators, could be to decide to make those branch components private: we would decide that those are only technical, propagation is allowed but they shouldn’t be directly translated and so they shouldn’t be visible. I’d need to check how it works exactly, but it would avoid seeing too many things in the UI for our translators.
For point 2, we will obviously need custom tooling. Now the REST API of Weblate is properly documented and I think it shouldn’t be too complicated to use that (e.g. see creating a component with REST API). Note that we might also only need to create a single component: we’re already using a Weblate addon to automatically discover components based on regular expressions: we could probably use same mechanism. Basically we’d create oldcore component, and all other ones of the repo would be created automatically by the discovery addon. So could be actually quite easier than I even thought before writing this 
I don’t think point 3 is a real issue: it’s just another PR to handle and it should probably be very fast to handle them.
Note that my idea so far for solving the main problem was already to automatically create backport PRs for other branches, so it wouldn’t change anything here.
WDYT? Unless someone strongly disagrees, I’d like to give a try just by creating manually a single branch components on xwiki-platform, e.g. for 15.10.x knowing that we had quite a changes and we haven’t propagated translation there: it would be an interesting test to see how it goes.