Open Stack

> > On 4/26/2020 9:31 PM, Andreas Jaeger wrote:
> >> Looking at the work to branch a new release and the amount of
> >> translation done on stable branches for the non-ui projects (ceilometer,
> >> cinder, nova etc), I propose to translate them *only* on master.

Generally agree with the proposal, but we should consider what are actually
translated in addition to the translation stats.
>From my knowledge, what we (not me :p but most translators) translate are
dashboard strings (in stable branches) and release notes (in the master branch).
Considering this, the proposal makes sense to me.

I am replying one by one below.

On Mon, Apr 27, 2020 at 3:06 AM Andreas Jaeger <aj at suse.com> wrote:
>
> On 26/04/2020 19.56, Ian Y. Choi wrote:
> > Let's discuss after Ussuri release. Agree with reflecting the current
> > translator nature today.
>
> The change is WIP for now, I wanted to start the discussion so that we
> can make a decision after Ussuri release.
>
> >
> > Related thoughts and discussions might be:
> >
> > - List of UI projects: how we get this information?
>
> You have it already on translate.o.o with " Ussuri Dashboard translation
> project list" UI = Dashboards

I think Ian's point is how to maintain the list in Zanata with the
minimum effort.

In horizon, we generate horizon plugin lists based on the deliverable
files in the releases repo.
The script checks the deliverable type is "horizon-plugin". It is now
run manually.
https://opendev.org/openstack/horizon/src/branch/master/tools/list-horizon-plugins.py

Perhaps, you can do the similar thing combined with
project-config/gerrit/projects.yaml
which defines which projects turn on translation.

> > - Target release: only for cycle-with-rc or including
> > cycle-with-intermediary
> >
> > - I18n team needs to stay with deeper eyes on release model changes
> > (e.g., Horizon's cycle-with-rc -> cycle-with-intermediary during Ussuri
> > cycle) & translation effort (e.g., how many translations are going on
> > many projects)
>
> I'm not understanding how these play a role here. Creating intermediate
> releases does not create new branches, so no change needed.

I think it affects when stable branches are created.
For projects with cycle-with-rc, we can expect that stable branches
are created at the week of RC1,
but for projects with cycle-with-intermediary, it is up to individual
teams and we cannot have
the general expectation on when stable branches are created.

> > - Needs to think about procedure how to deal with translation bugs on
> > stable branches for master-only projects
>
> How many did we get in the past for the projects I propose to change to
> master only?
>
> I guess 99 % of the translation effort is on UI/Dashboard projects and
> there's no change.

Andreas's proposal is based on the fact that non-UI projects only have
translations
on release notes and other contents like exception messages are not
translated at all.
Release notes translations only happen in the master branch, so there
is no need to
consider translation bugs on stable branches.

This reminds me a topic on translation bugs on older stable branches
which I raised before.
I got no reply on that. Perhaps we should accept direct fixes via
gerrit for such stable branches
which are no longer supported in zanata.

Akihiro

>
>
> Andreas
>
> >
> >
> >
> > With many thanks,
> >
> >
> > /Ian
> >
> > On 4/26/2020 9:31 PM, Andreas Jaeger wrote:
> >> Looking at the work to branch a new release and the amount of
> >> translation done on stable branches for the non-ui projects (ceilometer,
> >> cinder, nova etc), I propose to translate them *only* on master.
> >>
> >> So, we would continue to translate on master and stable horizon and
> >> friends - and that's all.
> >>
> >> If there's a specific project that needs translation, we can change that
> >> one for sure.
> >>
> >> This reflects IMHO how translators translate today.
> >>
> >> I've proposed the following change and marked it WIP for discussion here
> >> and waiting until Ussuri release:
> >> https://review.opendev.org/723217
> >>
> >> Andreas
>
>
> --
>  Andreas Jaeger aj at suse.com Twitter: jaegerandi
>   SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg
>    (HRB 36809, AG Nürnberg) GF: Felix Imendörffer
>     GPG fingerprint = EF18 1673 38C4 A372 86B1  E699 5294 24A3 FF91 2ACB
>
> _______________________________________________
> OpenStack-I18n mailing list
> OpenStack-I18n at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n