[OpenStack-I18n] translated release note: import criteria and publishing
robert.simai at suse.com
Thu Mar 9 17:13:58 UTC 2017
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
>From your example,
you can back by releases in the left menu, with this order:
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 ...
More information about the OpenStack-I18n