translated release note: import criteria and publishing
Hi i18n team, CC: Doug from the release team. We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great. == Problem == Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole. If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole. The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time. == Proposal == I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release. If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo. I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited. == Open question == Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes. For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all? My vote is not to publish less-translated version of release notes. == Note == Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/ Akihiro
On Oct 8, 2016, at 5:55 AM, Akihiro Motoki <amotoki@gmail.com> wrote:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release.
I agree that it makes sense to translate by release, if we can make the tool changes needed. I don’t have an opinion about what percent of the text needs to be translated for it to be useful — I’m sure all of you have more insight into that than I do.
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ <https://review.openstack.org/#/c/383622/> Proposed threshold 75% and 40% might need to be revisited.
== Open question ==
Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all?
My vote is not to publish less-translated version of release notes.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html <https://releases.openstack.org/newton/index.html> [2] http://docs.openstack.org/releasenotes/horizon/ <http://docs.openstack.org/releasenotes/horizon/>
Akihiro
Thank you Akihiro and Doug! Please see my comment inline. Doug Hellmann wrote on 10/8/2016 11:35 PM:
On Oct 8, 2016, at 5:55 AM, Akihiro Motoki <amotoki@gmail.com <mailto:amotoki@gmail.com>> wrote:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release.
I agree that it makes sense to translate by release, if we can make the tool changes needed. I don’t have an opinion about what percent of the text needs to be translated for it to be useful — I’m sure all of you have more insight into that than I do.
I just thought that we needed to take care of all releases since Zanata has 'only' master branch for releasenotes, and so I have not thought 'translate by release' concept. It will be great for translation by release. Thank you Akihiro-san for 'translate by release' idea with implementation commit request. IMO upper percent value is fine, since the values are the same in common_translate_update.sh [3]. [3] http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/sc...
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited.
By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script).
I have updated [4] about several months ago. At that time I just referred Wiki documentation [5]. On March, the value was still 20% [6]. IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team? [4] http://docs.openstack.org/developer/i18n/infra.html#translation-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Translation_perc... [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-March/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/
== Open question ==
Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all?
My vote is not to publish less-translated version of release notes.
+1
Also I have a question. So the criteria "for release notes translation to 75% at least for a specific release" means for all the project repositories, or for one project repository? For example, if one language team is interested mainly in Nova Newton release, the team translated only releasenotes strings for Newton release in openstack/nova repository, then would it be published? I am not currently sure how translated releasenotes landing page will be built and/or organized, but I think it is not a good idea to add just a link to Newton horizon releasenotes page in docs.o.o/[language]/index.html page.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/
Oh I have not thought such methods: using two web browser windows, one is for English release notes and and the other is for string search in Zanata :)
With many thanks, /Ian
Akihiro
_______________________________________________ OpenStack-I18n mailing list OpenStack-I18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
On 10/09/2016 07:50 AM, Ian Y. Choi wrote:
[...] By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script).
8 % only for two specific files - and those files don't exist in this form anymore...
I have updated [4] about several months ago. At that time I just referred Wiki documentation [5]. On March, the value was still 20% [6].
IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team?
[4] http://docs.openstack.org/developer/i18n/infra.html#translation-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Translation_perc... [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-March/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/
We agreed some time ago (a year or two?) that as "release criteria" we have 60 % as minimum for translationed - and so we removed some files manually prior to releases that had low translation rate. This time I didn't want to check all repositories again, so looked at a different way. Initially, I didn't want to hardcode the 60 % value into the scripts out of fear of a jo-jo effect, specially for smaller files: A couple of untranslated strings might easily make the percent go from 75 % to 60 % - and that's why we had 20 % initially. Seeing how it worked over time, I slowly raised the values while monitoring the effect in the daily imports. So, should we keep it at 40 % for the scripts? Btw. let's document at one place only - on docs.o.o, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 10/09/2016 10:45 AM, Andreas Jaeger wrote:
On 10/09/2016 07:50 AM, Ian Y. Choi wrote:
[...] By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script).
8 % only for two specific files - and those files don't exist in this form anymore...
I have updated [4] about several months ago. At that time I just referred Wiki documentation [5]. On March, the value was still 20% [6].
IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team?
[4] http://docs.openstack.org/developer/i18n/infra.html#translation-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Translation_perc... [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-March/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/
We agreed some time ago (a year or two?) that as "release criteria" we have 60 % as minimum for translationed - and so we removed some files manually prior to releases that had low translation rate.
This time I didn't want to check all repositories again, so looked at a different way.
Initially, I didn't want to hardcode the 60 % value into the scripts out
66 % percent - see http://git.openstack.org/cgit/openstack-infra/release-tools/tree/translation... # For partial translations and choosing 75% , see # https://bugs.launchpad.net/horizon/+bug/1317794. The number 66 % # was choosen for releases so that partial translation does not get # removed due to last minute string changes.
of fear of a jo-jo effect, specially for smaller files: A couple of untranslated strings might easily make the percent go from 75 % to 60 % - and that's why we had 20 % initially. Seeing how it worked over time, I slowly raised the values while monitoring the effect in the daily imports.
So, should we keep it at 40 % for the scripts?
Btw. let's document at one place only - on docs.o.o,
Andreas
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 10/09/2016 10:54 AM, Andreas Jaeger wrote:
On 10/09/2016 10:45 AM, Andreas Jaeger wrote:
On 10/09/2016 07:50 AM, Ian Y. Choi wrote:
[...] By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script).
8 % only for two specific files - and those files don't exist in this form anymore...
I have updated [4] about several months ago. At that time I just referred Wiki documentation [5]. On March, the value was still 20% [6].
IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team?
[4] http://docs.openstack.org/developer/i18n/infra.html#translation-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Translation_perc... [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-March/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/
We agreed some time ago (a year or two?) that as "release criteria" we have 60 % as minimum for translationed - and so we removed some files manually prior to releases that had low translation rate.
This time I didn't want to check all repositories again, so looked at a different way.
Initially, I didn't want to hardcode the 60 % value into the scripts out
66 % percent - see http://git.openstack.org/cgit/openstack-infra/release-tools/tree/translation...
# For partial translations and choosing 75% , see # https://bugs.launchpad.net/horizon/+bug/1317794. The number 66 % # was choosen for releases so that partial translation does not get # removed due to last minute string changes.
What about https://review.openstack.org/384183 ? I've WIP'ed it until we finished this discussion. Andreas
of fear of a jo-jo effect, specially for smaller files: A couple of untranslated strings might easily make the percent go from 75 % to 60 % - and that's why we had 20 % initially. Seeing how it worked over time, I slowly raised the values while monitoring the effect in the daily imports.
So, should we keep it at 40 % for the scripts?
Btw. let's document at one place only - on docs.o.o,
Andreas
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Dear language coordinators and translators, Please write opinions on https://review.openstack.org/#/c/384183/ for this issue :) Andreas Jaeger wrote on 10/9/2016 6:03 PM:
On 10/09/2016 10:54 AM, Andreas Jaeger wrote:
On 10/09/2016 10:45 AM, Andreas Jaeger wrote:
[...] By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script). 8 % only for two specific files - and those files don't exist in this
On 10/09/2016 07:50 AM, Ian Y. Choi wrote: form anymore...
I have updated [4] about several months ago. At that time I just referred Wiki documentation [5]. On March, the value was still 20% [6].
IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team?
[4] http://docs.openstack.org/developer/i18n/infra.html#translation-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Translation_perc... [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-March/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/ We agreed some time ago (a year or two?) that as "release criteria" we have 60 % as minimum for translationed - and so we removed some files manually prior to releases that had low translation rate.
This time I didn't want to check all repositories again, so looked at a different way.
Initially, I didn't want to hardcode the 60 % value into the scripts out 66 % percent - see http://git.openstack.org/cgit/openstack-infra/release-tools/tree/translation...
# For partial translations and choosing 75% , see # https://bugs.launchpad.net/horizon/+bug/1317794. The number 66 % # was choosen for releases so that partial translation does not get # removed due to last minute string changes. What about https://review.openstack.org/384183 ? I've WIP'ed it until we finished this discussion.
Andreas
Thank you for explanation and caring with it.
of fear of a jo-jo effect, specially for smaller files: A couple of untranslated strings might easily make the percent go from 75 % to 60 % - and that's why we had 20 % initially. Seeing how it worked over time, I slowly raised the values while monitoring the effect in the daily imports.
So, should we keep it at 40 % for the scripts?
Btw. let's document at one place only - on docs.o.o, Now I am inclined to agree with minimum *40%* after I saw Andreas's comments. But I would like to wait for a few days more to collect opinions.
With many thanks, /Ian
Andreas
Hi, +1, minimum 40%. thinks, sungjin 2016-10-10 15:37 GMT+09:00 Ian Y. Choi <ianyrchoi@gmail.com>:
Dear language coordinators and translators,
Please write opinions on https://review.openstack.org/#/c/384183/ for this issue :)
Andreas Jaeger wrote on 10/9/2016 6:03 PM:
On 10/09/2016 10:54 AM, Andreas Jaeger wrote:
On 10/09/2016 10:45 AM, Andreas Jaeger wrote:
On 10/09/2016 07:50 AM, Ian Y. Choi wrote:
[...] By the way, I think we need to discuss the value minimum: 40%, since the value has been changed from previous 20% (actually 8% in script).
8 % only for two specific files - and those files don't exist in this form anymore...
I have updated [4] about several months ago. At that time I just
referred Wiki documentation [5]. On March, the value was still 20% [6].
IMO Andreas temporally changed the value from 20% to 30% [7] and 40% [8] for cleaning up purposes. So which minimum percent value would be appropriate for I18n team?
[4] http://docs.openstack.org/developer/i18n/infra.html#translat ion-jobs [5] https://wiki.openstack.org/wiki/Translations/Infrastructure# Translation_percentage_changes [6] http://lists.openstack.org/pipermail/openstack-i18n/2016-Mar ch/001993.html [7] https://review.openstack.org/#/c/372141/ [8] https://review.openstack.org/#/c/375285/
We agreed some time ago (a year or two?) that as "release criteria" we have 60 % as minimum for translationed - and so we removed some files manually prior to releases that had low translation rate.
This time I didn't want to check all repositories again, so looked at a different way.
Initially, I didn't want to hardcode the 60 % value into the scripts out
66 % percent - see http://git.openstack.org/cgit/openstack-infra/release-tools/ tree/translation-cleanup.sh#n192
# For partial translations and choosing 75% , see # https://bugs.launchpad.net/horizon/+bug/1317794. The number 66 % # was choosen for releases so that partial translation does not get # removed due to last minute string changes.
What about https://review.openstack.org/384183 ? I've WIP'ed it until we finished this discussion.
Andreas
Thank you for explanation and caring with it.
of fear of a jo-jo effect, specially for smaller files: A couple of
untranslated strings might easily make the percent go from 75 % to 60 % - and that's why we had 20 % initially. Seeing how it worked over time, I slowly raised the values while monitoring the effect in the daily imports.
So, should we keep it at 40 % for the scripts?
Btw. let's document at one place only - on docs.o.o,
Now I am inclined to agree with minimum *40%* after I saw Andreas's comments. But I would like to wait for a few days more to collect opinions.
With many thanks,
/Ian
Andreas
_______________________________________________ OpenStack-I18n mailing list OpenStack-I18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
The original thread on the release note criteria created a couple of forked topics. On the original topic, I have no plan to move it forward until the summit is over. If someone wants to move this forward sooner, feel free to update the original review. Talking about myself, I cannot join the regular i18n IRC meetings as the time does not work for me due to my personal regular/usual schedule, so I cannot join the discussion. Akihiro 2016-10-08 18:55 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release.
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited.
== Open question ==
Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all?
My vote is not to publish less-translated version of release notes.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/
Akihiro
Hi I18n team, Do we want to move this forward or abandon it? When I sent the original mail last October, we mainly discussed the threshold values themselves and the approach itself was not discussed well. Most feedbacks I received are positive though. I would like to know we agree the original idea "to publish release notes translation based on per release progress" or not. I kept my patch implementing this idea for a long time [1]. If there is no agreement, I will abandon it. [1] https://review.openstack.org/#/c/383622/ Thanks, Akihiro 2016-10-08 18:55 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release.
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited.
== Open question ==
Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all?
My vote is not to publish less-translated version of release notes.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/
Akihiro
Hi Akihiro, I'm not exactly sure what you're asking for. Is it to either apply the threshold to the whole release notes, including all previous releases, or to just one release? If yes, then I personally have no real preference. We could make it a bit easier by looking at the per release progress and publish based on that. I however wonder how you make sure in this situation that readers can navigate properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no translated release notes document for a release? -- Thanks, Robert On Wednesday, 8 March 2017, 15:59:01 CET, Akihiro Motoki wrote:
Hi I18n team,
Do we want to move this forward or abandon it?
When I sent the original mail last October, we mainly discussed the threshold values themselves and the approach itself was not discussed well. Most feedbacks I received are positive though.
I would like to know we agree the original idea "to publish release notes translation based on per release progress" or not.
I kept my patch implementing this idea for a long time [1]. If there is no agreement, I will abandon it.
[1] https://review.openstack.org/#/c/383622/
Thanks, Akihiro
2016-10-08 18:55 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes translation. If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is translated. 75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes translation to 75% at least for a specific release.
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited.
== Open question ==
Do we publish translated release notes for a release with <75% progress? This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to publish all?
My vote is not to publish less-translated version of release notes.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/
Akihiro
_______________________________________________ OpenStack-I18n mailing list OpenStack-I18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
Hi Robert, 2017-03-09 19:12 GMT+09:00 Robert Simai <robert.simai@suse.com>:
Hi Akihiro,
I'm not exactly sure what you're asking for. Is it to either apply the threshold to the whole release notes, including all previous releases, or to just one release?
If yes, then I personally have no real preference. We could make it a bit easier by looking at the per release progress and publish based on that.
I however wonder how you make sure in this situation that readers can
properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no
Yes, that is what I would like to discuss. navigate translated
release notes document for a release?
Actually the whole release notes are generated. If corresponding strings are translated translated versions are used, and if not original strings are used, so I think there is no navigation problem. For example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html contains untranslated strings. the same thing happens for untranslated releases. Akihiro
-- Thanks, Robert
On Wednesday, 8 March 2017, 15:59:01 CET, Akihiro Motoki wrote:
Hi I18n team,
Do we want to move this forward or abandon it?
When I sent the original mail last October, we mainly discussed the threshold values themselves and the approach itself was not discussed well. Most feedbacks I received are positive though.
I would like to know we agree the original idea "to publish release notes translation based on per release progress" or not.
I kept my patch implementing this idea for a long time [1]. If there is no agreement, I will abandon it.
[1] https://review.openstack.org/#/c/383622/
Thanks, Akihiro
2016-10-08 18:55 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:
Hi i18n team, CC: Doug from the release team.
We are now preparing translated version of release notes. I would like to discuss the import criteria of release notes
If there is a better way, it would be great.
== Problem ==
Release notes translation is imported when 75% of a PO file is
75% is calculated as a whole.
If a language team wants to translate release notes of a specific release, the team needs to translate release notes of other releases. This comes from the fact that the translation percentage is calculated as a whole.
The development teams started to use reno for translation at the beginning of Mitaka cycle and Liberty release notes are converted into reno-based release notes. This mean if we want to publish Newton release notes translation, we need to translate release notes for Liberty and Mitaka at the same time.
== Proposal ==
I hope we can publish translated release notes per release. If Newton release notes translation completes, I want to publish Newton release notes. My proposal is to change the import criteria for release notes
to 75% at least for a specific release.
If translation progress of release notes are less than 40% for all releases, a corresponding PO file will be removed from the repo.
I proposed an infra scirpt change to implement the above. https://review.openstack.org/#/c/383622/ Proposed threshold 75% and 40% might need to be revisited.
== Open question ==
Do we publish translated release notes for a release with <75%
This is about publishing rendered release notes.
For example, assume my lang team have translated release notes 90% for Newton, 10% for Mitaka and Liberty. In this case, which is better not to publish Mitaka and Liberty release notes translation or to
translation. translated. translation progress? publish
all?
My vote is not to publish less-translated version of release notes.
== Note ==
Question from Ian on the gerrit review. By the way, is it possible to see only Newton release note strings in Zanata? Answer: The current Zanata version we use does not support filtering by an original filename. You need to check English release notes like [1] or [2] and search strings on Zanata. [1] https://releases.openstack.org/newton/index.html [2] http://docs.openstack.org/releasenotes/horizon/
Akihiro
_______________________________________________ OpenStack-I18n mailing list OpenStack-I18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
On Thursday, 9 March 2017, 14:31:50 CET, Akihiro Motoki wrote: [...]
I however wonder how you make sure in this situation that readers can
navigate
properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no
translated
release notes document for a release?
Actually the whole release notes are generated. If corresponding strings are translated translated versions are used, and if not original strings are used, so I think there is no navigation problem. For example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html contains untranslated strings. the same thing happens for untranslated releases.
From this page you can go back in time (previous and next topic in the left side menu), to access the previous releases.
My concern is, if not all release notes files from all releases are published, then this navigation will break, even if you link back to the original language page. On the other hand, if you publish translations for all releases, even if only one is above threshold, then this is not really helpful for users. -- Thanks, Robert
2017-03-09 23:50 GMT+09:00 Robert Simai <robert.simai@suse.com>:
On Thursday, 9 March 2017, 14:31:50 CET, Akihiro Motoki wrote:
[...]
I however wonder how you make sure in this situation that readers can
navigate
properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no
translated
release notes document for a release?
Actually the whole release notes are generated. If corresponding strings are translated translated versions are used, and if not original strings are used, so I think there is no navigation problem. For example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html contains untranslated strings. the same thing happens for untranslated releases.
From this page you can go back in time (previous and next topic in the left side menu), to access the previous releases.
My concern is, if not all release notes files from all releases are published, then this navigation will break, even if you link back to the original language page.
How will the navigation break? I cannot understand what in your mind. previous and next topic always exist even if they are not well translated. This is what sphinx does. More work will be needed if we want to publish only well translated page and do not publish less translated pages. I have no good idea on this at now.
On the other hand, if you publish translations for all releases, even if only one is above threshold, then this is not really helpful for users.
This is a valid concern. I see two types of readers. The one type of readers want to read release notes of various projects of a specific release. For example, Ocata nova, neutron, cinder and so on. The other is type of readers want to read release notes of several releases of a specific project. Perhaps I mainly take care of the former, and you mainly concerns the latter. I have no perfect answer to this. What is the good approach? All or nothing? Publish gradually? In addition, if some translators are interested in a specific (or recent) release(s), do they have to translate all of releases? It requires much more efforts to publish translated version of release notes. More releases we have, more translation required to publish only recent releases. I know there are several opinions, and this is the reason I raised this topic to the ML. Although there might be a line we can compromise, I would like to know a consensus of the I18n team before moving my approach forward. I will once stop my response here and wait other opinions. Do you all satisfy the current situation of release note translations? What can we do gradually? Akihiro
-- Thanks, Robert
On Friday, 10 March 2017, 01:14:35 CET, Akihiro Motoki wrote:
2017-03-09 23:50 GMT+09:00 Robert Simai <robert.simai@suse.com>:
On Thursday, 9 March 2017, 14:31:50 CET, Akihiro Motoki wrote:
[...]
I however wonder how you make sure in this situation that readers can
navigate
properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no
translated
release notes document for a release?
Actually the whole release notes are generated. If corresponding strings are translated translated versions are used, and if not original strings are used, so I think there is no navigation problem. For example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html contains untranslated strings. the same thing happens for untranslated releases.
From this page you can go back in time (previous and next topic in the left side menu), to access the previous releases.
My concern is, if not all release notes files from all releases are published, then this navigation will break, even if you link back to the original language page.
How will the navigation break? I cannot understand what in your mind. previous and next topic always exist even if they are not well translated. This is what sphinx does.
More work will be needed if we want to publish only well translated page and do not publish less translated pages. I have no good idea on this at now.
From your example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html you can back by releases in the left menu, with this order:
https://docs.openstack.org/releasenotes/horizon/ja/ocata.html https://docs.openstack.org/releasenotes/horizon/ja/newton.html https://docs.openstack.org/releasenotes/horizon/ja/mitaka.html https://docs.openstack.org/releasenotes/horizon/ja/liberty.html [...] and you can also go forward. Let's say ja/mitaka.html doesn't exist, then navigation breaks. Options: - fallback to the untranslated mitaka page -> if you continue to switch releases you'll stay in the untranslated versions - page exists but is untranslated -> not helpful for users That makes me think that the percentage should be applied to the complete release notes of a project, not only one release.
On the other hand, if you publish translations for all releases, even if only one is above threshold, then this is not really helpful for users.
This is a valid concern.
I see two types of readers. The one type of readers want to read release notes of various projects of a specific release. For example, Ocata nova, neutron, cinder and so on. The other is type of readers want to read release notes of several releases of a specific project.
I think the latter is usual and what you people do if they're looking for changes within the project.
Perhaps I mainly take care of the former, and you mainly concerns the latter. I have no perfect answer to this.
Indeed, it seems so :-)
What is the good approach? All or nothing? Publish gradually?
Here I don't have a good answer either...
In addition, if some translators are interested in a specific (or recent) release(s), do they have to translate all of releases? It requires much more efforts to publish translated version of release notes. More releases we have, more translation required to publish only recent releases.
I know there are several opinions, and this is the reason I raised this topic to the ML. Although there might be a line we can compromise, I would like to know a consensus of the I18n team before moving my approach forward. I will once stop my response here and wait other opinions.
Do you all satisfy the current situation of release note translations? What can we do gradually?
Let's see what the group thinks ... -- Cheers, Robert
2017-03-10 2:13 GMT+09:00 Robert Simai <robert.simai@suse.com>:
On Friday, 10 March 2017, 01:14:35 CET, Akihiro Motoki wrote:
2017-03-09 23:50 GMT+09:00 Robert Simai <robert.simai@suse.com>:
On Thursday, 9 March 2017, 14:31:50 CET, Akihiro Motoki wrote:
[...]
I however wonder how you make sure in this situation that readers can
navigate
properly through the release notes of a project if only some of them are translated. (How) do you fall back to the original if there's no
translated
release notes document for a release?
Actually the whole release notes are generated. If corresponding strings are translated translated versions are used, and if not original strings are used, so I think there is no navigation problem. For example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html contains untranslated strings. the same thing happens for untranslated releases.
From this page you can go back in time (previous and next topic in the left side menu), to access the previous releases.
My concern is, if not all release notes files from all releases are published, then this navigation will break, even if you link back to the original language page.
How will the navigation break? I cannot understand what in your mind. previous and next topic always exist even if they are not well translated. This is what sphinx does.
More work will be needed if we want to publish only well translated page and do not publish less translated pages. I have no good idea on this at now.
From your example, https://docs.openstack.org/releasenotes/horizon/ja/unreleased.html you can back by releases in the left menu, with this order:
https://docs.openstack.org/releasenotes/horizon/ja/ocata.html https://docs.openstack.org/releasenotes/horizon/ja/newton.html https://docs.openstack.org/releasenotes/horizon/ja/mitaka.html https://docs.openstack.org/releasenotes/horizon/ja/liberty.html [...]
and you can also go forward. Let's say ja/mitaka.html doesn't exist, then navigation breaks. Options:
Have you tried sphinx actually? Based on what sphinx does, ja/mitaka.html will exist even if the page was not translated at all.
- fallback to the untranslated mitaka page -> if you continue to switch releases you'll stay in the untranslated versions
- page exists but is untranslated -> not helpful for users
That's true, but translators are not supermen. Do you want translators to translate all releases? For example, in case of horizon, horizon release notes contains 702 messages and ocata release notes contains only 57 messages (this is a word count). The recent three releases (O/L/M) have 202 messages. Although it is some special example, I don't think it is a good balance to translate the whole strings to have several releases translated (33% vs 100% (or 75%)). Most translators are volunteers and they do not translate them as their job.
That makes me think that the percentage should be applied to the complete release notes of a project, not only one release.
On the other hand, if you publish translations for all releases, even if only one is above threshold, then this is not really helpful for users.
This is a valid concern.
I see two types of readers. The one type of readers want to read release notes of various projects of a specific release. For example, Ocata nova, neutron, cinder and so on. The other is type of readers want to read release notes of several releases of a specific project.
I think the latter is usual and what you people do if they're looking for changes within the project.
So, in your view, release notes like https://wiki.openstack.org/wiki/ReleaseNotes/Liberty is not a usual case? The page like this is what in my mind and this is catagorized into the former. Perhaps it is *usual* in your point of view. If you are interested in a specific project or you are in charge of a specific project, you should think the latter is usual. As one of operators, I need to check what are new or change in a specific release like Ocata. https://releases.openstack.org/ocata/ contains English version of release notes for Ocata. As an upstream core developer of neutron and horizon, the latter is sometimes useful. It depends on a personal role.
Perhaps I mainly take care of the former, and you mainly concerns the latter. I have no perfect answer to this.
Indeed, it seems so :-)
What is the good approach? All or nothing? Publish gradually?
Here I don't have a good answer either...
In addition, if some translators are interested in a specific (or recent) release(s), do they have to translate all of releases? It requires much more efforts to publish translated version of release notes. More releases we have, more translation required to publish only recent releases.
I know there are several opinions, and this is the reason I raised this topic to the ML. Although there might be a line we can compromise, I would like to know a consensus of the I18n team before moving my approach forward. I will once stop my response here and wait other opinions.
Do you all satisfy the current situation of release note translations? What can we do gradually?
Let's see what the group thinks ...
-- Cheers, Robert
On Friday, 10 March 2017, 21:32:14 CET, Akihiro Motoki wrote:
2017-03-10 2:13 GMT+09:00 Robert Simai <robert.simai@suse.com>:
[...]
Have you tried sphinx actually?
Based on what sphinx does, ja/mitaka.html will exist even if the page was not translated at all.
Good to know, thanks.
- fallback to the untranslated mitaka page -> if you continue to switch releases you'll stay in the untranslated versions
- page exists but is untranslated -> not helpful for users
That's true, but translators are not supermen.
Well, I know. And I'm also putting spare time into translations.
Do you want translators to translate all releases?
Long story short, I just tried to express my view as I thought you had asked for that. If you think publishing should be based on the percentage per release I'm absolutely fine. We don't need to enforce anything here. [...] -- Regards, Robert
Robert, Thank you very much anyway. I understand your view too. You reminds me that there are various views. That is very important point. I also know we need better navigation even after we publish translated release notes per release. It is not a short way, but I believe we can move things forward gradually. Akihiro 2017-03-10 21:40 GMT+09:00 Robert Simai <robert.simai@suse.com>:
On Friday, 10 March 2017, 21:32:14 CET, Akihiro Motoki wrote:
2017-03-10 2:13 GMT+09:00 Robert Simai <robert.simai@suse.com>:
[...]
Have you tried sphinx actually?
Based on what sphinx does, ja/mitaka.html will exist even if the page was not translated at all.
Good to know, thanks.
- fallback to the untranslated mitaka page -> if you continue to switch releases you'll stay in the untranslated versions
- page exists but is untranslated -> not helpful for users
That's true, but translators are not supermen.
Well, I know. And I'm also putting spare time into translations.
Do you want translators to translate all releases?
Long story short, I just tried to express my view as I thought you had asked for that. If you think publishing should be based on the percentage per release I'm absolutely fine. We don't need to enforce anything here.
[...]
-- Regards, Robert
Hello, Sorry for my late reply from this thread. I was very busy on my lots of business stuff (also dealing with some other I18n issues) but I have been following the discussion on translating release notes in this mail thread. Some stories were already mentioned from Akihiro, but I would like repeat and tell more background & details for more translators (sometimes they might be unfamiliar with the detail context in the thread) to involve in the discussion. Before OpenStack release team published release notes on releases.openstack.org, release notes had been published through wiki.openstack.org, and I have seen that so many I18n people were interested & participated in translating release notes - for example, [1]. At that time, translators focused on per-release translation. After the transition to releases.openstack.org, translation support on release notes needed additional effort, and it took about one year to support release note translation (from [2] to [3]). Now I see that there are translated release notes for some projects - for example, Horizon [4], but it seems that the translation participation is not rather high comparing to the previous period (wiki.openstack.org). From such experiences, in my opinion, encouraging per-release note translations would be more attractive for translators to more participate in release note translation, and minor embarrassing on publication would have less priority than such encouragement. Developers also contribute translation, and they are able to improve current UI/UX for better publication, but for the perspective from developer side, the feedback would be very important to precisely collect new requirements and decide the best approach to be implemented. Thanks a lot, Robert - for such kind asking & discussion, and I hope that more translators and language coordinators will share & express their perspective and opinion not only in here but also through many I18n communication channels like IRC meeting, Summit, and so on. (By the way, would it fine for me to change the status [2] as "Implemented"?) With many thanks, /Ian [1] https://wiki.openstack.org/wiki/ReleaseNotes/Kilo [2] https://blueprints.launchpad.net/openstack-i18n/+spec/release-notes-translat... [3] http://lists.openstack.org/pipermail/openstack-i18n/2016-October/002502.html [4] https://docs.openstack.org/releasenotes/horizon/index.html Robert Simai wrote on 3/10/2017 9:40 PM:
On Friday, 10 March 2017, 21:32:14 CET, Akihiro Motoki wrote:
2017-03-10 2:13 GMT+09:00 Robert Simai <robert.simai@suse.com>: [...]
Have you tried sphinx actually?
Based on what sphinx does, ja/mitaka.html will exist even if the page was not translated at all. Good to know, thanks.
- fallback to the untranslated mitaka page -> if you continue to switch releases you'll stay in the untranslated versions
- page exists but is untranslated -> not helpful for users That's true, but translators are not supermen. Well, I know. And I'm also putting spare time into translations.
Do you want translators to translate all releases? Long story short, I just tried to express my view as I thought you had asked for that. If you think publishing should be based on the percentage per release I'm absolutely fine. We don't need to enforce anything here.
[...]
participants (6)
-
Akihiro Motoki
-
Andreas Jaeger
-
Doug Hellmann
-
Ian Y. Choi
-
Robert Simai
-
SungJin Kang