On Tue, May 22, 2018 at 1:51 PM, Vincent Massol <[email protected]> wrote: > FTR this is what I discussed with Adel and I asked him to post it here so > that we can agree. > >> On 22 May 2018, at 13:41, Adel Atallah <[email protected]> wrote: >> >> So for 1), we still need to decide how we merge new translations into >> LTS releases (or other branches). > > Idea 1: > >> 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. > > More specifically this is about finding all commits done by a given user (the > weblate user). In practice the commits are done under the translation > contributor’s name so we would need to find the merge commit (done with the > weblate user name) and find all associated commits (children?). > > Idea 2: > >> 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. > > The problem with this approach is that we can have commits related to the > translation files that are not related to translations and thus generate > false positives. > >> >> WDYT? > > Idea 3: For each translation files in the known list, query weblate (using > the REST API) to get the latest translation and apply them locally. > > In practice this will mean find keys in the translation file and replace with > the value retrieved from weblate.
I don't think we need API calls for that, we can write a script that will merge only the translations from two translation files (master and LTS). It's a bit of work to do though. > > One improvement is that we could parse the keys from the local files and file > updated translations for them from weblate. > > The advantage of idea3 is that I don’t think there are false positives nor > merge conflicts which can happen with ideas 1 and 2. The downside is that it > may take a lot of time and a lot of REST calls to get them all. > > For all these ideas, it’ll the responsibility of the user (RM?) to check the > diff and decide to merge/push on the branch the full translations or only a > subpart of it. > > Aso note that we’re only talking about LTS here since we should not bother > for the temporary branches (such as stable-10.4.x). > > WDYT? > > Thanks > -Vincent > > >> >> Thanks, >> Adel >> Adel Atallah >> Product developer intern >> [email protected] >> tel: +33 (0)6 12 96 35 06 >> >> >> On Fri, May 18, 2018 at 6:47 PM, Ecaterina Moraru (Valica) >> <[email protected]> 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 <[email protected]> >>> 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 <[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 >>>> >
