[OpenStack-I18n] translated release note: import criteria and publishing

Akihiro Motoki amotoki at gmail.com
Fri Mar 10 12:32:14 UTC 2017


2017-03-10 2:13 GMT+09:00 Robert Simai <robert.simai at 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 at 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



More information about the OpenStack-I18n mailing list