Stop translating non-UI projects for stable branches?
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@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
Let's discuss after Ussuri release. Agree with reflecting the current translator nature today. Related thoughts and discussions might be: - List of UI projects: how we get this information? - 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) - Needs to think about procedure how to deal with translation bugs on stable branches for master-only projects 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
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
- 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.
- 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
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@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
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... 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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
On 27.04.20 03:36, Akihiro Motoki wrote:
[..] 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.
Agreed - but I would only do it for severe ones, not for nits, 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
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
On 27.04.20 03:36, Akihiro Motoki wrote:
[...] 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...
I've updated my change https://review.opendev.org/723217 to add stable translations for those in the list, which moved networking-bgpvpn and cloudkitty-dashboard to translate stable branches as well. Change is still WIP - but shows what I'm proposing, 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
I had to rebase my change https://review.opendev.org/723217 Should we move forward with it? 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
I noticed one point we haven't discussed yet. The subject says "Stop translating non-UI projects for stable branches?". Does "non-UI" include document translation? As my hat of Japanese language coordinator, we no longer translate documentation much, so it does not matter much. However, I believe we need to clarify it. -amotoki On Thu, May 14, 2020 at 5:11 PM Andreas Jaeger <aj@suse.com> wrote:
I had to rebase my change https://review.opendev.org/723217
Should we move forward with it?
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
On 14.05.20 17:56, Akihiro Motoki wrote:
I noticed one point we haven't discussed yet. The subject says "Stop translating non-UI projects for stable branches?". Does "non-UI" include document translation?
Most docs repos have no stable branches. I'm only aware of docs translation on horizon on stable branches - and that would not change. openstack-manuals, security-doc etc have no stable branches. So, this should not make any difference. Can somebody check our documents to double check, please? Andreas
As my hat of Japanese language coordinator, we no longer translate documentation much, so it does not matter much.
However, I believe we need to clarify it.
-amotoki
On Thu, May 14, 2020 at 5:11 PM Andreas Jaeger <aj@suse.com> wrote:
I had to rebase my change https://review.opendev.org/723217
Should we move forward with it?
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
-- 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
Sorry for my late reply. I have not heard any additional requirements on translating stable branches on documents except Horizon, and I recognize that openstack-manuals and security-doc now have only master branch maintained. Andreas, would you give me more time slots (e.g., ~1 week) before moving forward on https://review.opendev.org/#/c/723217/ ? I18n team has just become SIG - no actual differences IMO but will try to more figure out current status and get back to you. Appreciate such kind understanding in advance. With many thanks, /Ian On 2020-05-15 2:05 AM, Andreas Jaeger wrote:
I noticed one point we haven't discussed yet. The subject says "Stop translating non-UI projects for stable branches?". Does "non-UI" include document translation? Most docs repos have no stable branches. I'm only aware of docs
On 14.05.20 17:56, Akihiro Motoki wrote: translation on horizon on stable branches - and that would not change.
openstack-manuals, security-doc etc have no stable branches.
So, this should not make any difference. Can somebody check our documents to double check, please?
Andreas
As my hat of Japanese language coordinator, we no longer translate documentation much, so it does not matter much.
However, I believe we need to clarify it.
-amotoki
On Thu, May 14, 2020 at 5:11 PM Andreas Jaeger <aj@suse.com> wrote:
I had to rebase my change https://review.opendev.org/723217
Should we move forward with it?
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
On 27.05.20 18:47, Ian Y. Choi wrote:
Sorry for my late reply. I have not heard any additional requirements on translating stable branches on documents except Horizon,
Which would continue under my proposal.
and I recognize that openstack-manuals and security-doc now have only master branch maintained.
Andreas, would you give me more time slots (e.g., ~1 week) before moving forward on https://review.opendev.org/#/c/723217/ ?
Sure.
I18n team has just become SIG - no actual differences IMO but will try to more figure out current status and get back to you.
Appreciate such kind understanding in advance.
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
On 27.05.20 18:47, Ian Y. Choi wrote:
Sorry for my late reply. I have not heard any additional requirements on translating stable branches on documents except Horizon,
and I recognize that openstack-manuals and security-doc now have only master branch maintained.
Andreas, would you give me more time slots (e.g., ~1 week) before moving forward on https://review.opendev.org/#/c/723217/ ?
Ian, your request was three weeks ago, I'll un-WIP 72317 later today, 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
participants (3)
-
Akihiro Motoki
-
Andreas Jaeger
-
Ian Y. Choi