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 <[email protected]> wrote: > Hi Adel, > >> On 18 May 2018, at 11:40, Adel Atallah <[email protected]> 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
