18 May
2018
18 May
'18
6:47 p.m.
+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:
branch is
done by the RM in one go for all translations.
*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.
questions I
raised for 1) first.
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
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 
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
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
--
Thomas Mortagne
Thanks,
Adel