On 27.04.20 03:36, Akihiro Motoki wrote:
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@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-p...
This seldom changes, doesn't it? We should update the docs on which job to run, so that teams following the docs make the right choice.
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.
Ah, I see. But nothing on the timng changes my proposal - that is more a question on when to create branches, correct? Andreas -- Andreas Jaeger aj@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