Re: [xwiki-devs] [Brainstorming] Should we support multibranch translations?

On 22 May 2018, at 13:41, Adel Atallah <adel.atallah(a)xwiki.com> wrote: So for 1), we still need to decide how we merge new translations into LTS releases (or other branches).

An idea would be to write a script to let the RM apply new changes to a specific branch. One way to do it would be to write a script to find every translation commits since a date then review and apply them.

An other way would be to use the list of translation files that we already have and write a script to replace (checkout) those files from master to the specified branch.

WDYT?

Thanks, Adel Adel Atallah Product developer intern adel.atallah(a)xwiki.com tel: +33 (0)6 12 96 35 06 On Fri, May 18, 2018 at 6:47 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com> wrote: > +1 for 1) > Make sure the commit has a marker like "[Translations]" or "[Weblate]" for > the the step in the release process, so that we can look for them in the > history in order to apply them, in case we really need them. > In practice we don't commit translations for LTS, because usually we make > changes in UI and we don't want to manually check and validate each > translation. > > Thanks, > Caty > > > On Fri, May 18, 2018 at 5:47 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> > wrote: > >> Option 2) would create too much of a mess on weblate side IMO (until >> we can hide branches at least). >> >> I would go for 1) for now and follow progress on Weblate product to >> provide a clean solution for this use case. >> >> That being said we need to find a solution for LTS (I don't think we >> care about stable branch bugfixes releases and we could do it by hand >> for RC branches since it's only 1 week usually). Here are some ideas: >> a) it should not be hard to write a script which get all the weblate >> commits from master since last weblate commit we can find in the >> branch and cherry-pick them (probably also display a diff and ask for >> confirmation for each of them). This would be executed before the >> release by the release manager. >> b) I guess it's possible to write or find a tool which automatically >> create a pull request on the LTS branch when a weblate pull request is >> applied >> c) Anyone who apply a weblate pull request is responsible for applying >> it on LTS branch. I don't trust us too much on that. >> >> >> >> a does not seems complex to do (but of course someone need to spend time >> on it). >> c does not require any tooling but I don't think it will work, I'm >> sure we will keep forgetting to cherry-pick. >> >> >> b would be nice if someone find a tool to do that. If not then I guess >> the more realistic option is a. >> >> On Fri, May 18, 2018 at 5:11 PM, Vincent Massol <vincent(a)massol.net> >> wrote: >>> Hi Adel, >>> >>>> On 18 May 2018, at 11:40, Adel Atallah <adel.atallah(a)xwiki.com> wrote: >>>> >>>> Hi, >>>> >>>> Following my previous email on "How should we review translations?", I'd >>>> like to know here if we should support automatic multibranch >> translations >>>> in Weblate. >>>> >>>> What I mean here is that with the old l10n platform, we would apply new >>>> translations on multiple git branches (for some projects like XWiki >>>> Platform). It was important to have new translations applied on LTS >>>> releases and other branches. >>>> >>>> The problem is that we can't tell Weblate to automatically push changes >> on >>>> multiple branches. We have discuss the problem with the maintainer here: >>>> https://github.com/WeblateOrg/weblate/issues/2016. >>>> What we can do is to duplicate Weblate components (a component is just a >>>> file to translate) for as many branches as we need. Making a change to a >>>> translation key (e.g. tour.homepageTour.pageMenu.contentB) will >> propagate >>>> the change to every other components with the same key. This way we can >>>> have a PR made with the same change on every branch we want. >>>> >>>> So here are the two options: >>>> >>>> 1) We keep the actual behavior >>>> Pros: >>>> - We will only have one PR to review (on master branch) >>>> Cons: >>>> - We will have to apply new changes to other branches ourselves when >>>> needed >>> >>> This is not fully the current behavior since right now the merge on a >> branch is done by the RM in one go for all translations. >>> >>> With this proposal 1) someone (whom?) will need to merge the *various* >> commits done by the weblate PRs, on a need-be basis. >>> >>> So this raises the following questions: >>> * Who is responsible for the branch merges and more specifically the LTS >> one. The RM? >>> * If so, what strategy do we decide, i.e. which translations do we want >> to merge or not? And what tool would be provide the RM or someone else to >> list all commits related to translations? >>> >>>> >>>> 2) We duplicate components >>>> Pros: >>>> - Changes will automatically be made for every specified branches >>>> Cons: >>>> - Some work to do: we can't create all the new components by hand so we >>>> will have to generate every components in some way >>>> - It will make Weblate much more complex because you can't hide >>>> components (https://i.imgur.com/YJ8qtUz.png) >>> >>> This option 2 is complex because not only the hassle of creating and >> *Deleting* components (when the branch is closed) but also we need to >> decide which components to duplicate (there might components that only >> exist on master for ex). Ideally we would need a script to automatically >> add translation components for a branch. >>> >>> If we can automate this then it’s not too bad but still complex. And >> indeed there’s the risk that users will translate branches by mistake >> instead of translating master. >>> >>>> I prefer option 1 because it will make Weblate easier to use. >>>> >>>> For option 2, we can also disable translation propagation and let people >>>> make translations on the branch they want. >>> >>> I can’t say which one I prefer yet because we need to answer the >> questions I raised for 1) first. >>> >>> The general question is: what translations do we want to merge for the >> LTS branch? I think we can agree that we don’t really care about merging >> translations for the short-lived branches such as 10.4.x. >>> >>> Thanks >>> -Vincent >>> >>>> >>>> Thanks, >>>> Adel >>> >> >> >> >> -- >> Thomas Mortagne >>