[Openstack-i18n] Translation update process for stable branch(es)

Akihiro Motoki amotoki at gmail.com
Fri Oct 24 00:01:25 UTC 2014


On Thu, Oct 23, 2014 at 10:17 PM, Tom Fifield <tom at openstack.org
<javascript:;>> wrote:
> On 23/10/14 21:07, Akihiro Motoki wrote:
>>
>>
>> 2014年10月23日木曜日、Ying Chun Guo<guoyingc at cn.ibm.com <javascript:;>
>> <mailto:guoyingc at cn.ibm.com <javascript:;>>>さんは書きました:
>>
>>     Akihiro Motoki <amotoki at gmail.com <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com <javascript:;>');>>
wrote on
>>     2014/10/22 21:09:51:
>>
>>     > Akihiro Motoki <amotoki at gmail.com <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com <javascript:;>');>>
>>     > 2014/10/22 21:09
>>     >
>>     > To
>>     >
>>     > "openstack-i18n at lists.openstack.org <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','openstack-i18n at lists.openstack.org
<javascript:;>');>" <Openstack-i18n at lists.openstack.org <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','Openstack-i18n at lists.openstack.org
<javascript:;>');>>,
>>     >
>>     > cc
>>     >
>>     > Subject
>>     >
>>     > Re: [Openstack-i18n] Translation update process for stable
branch(es)
>>     >
>>     > Hi all,
>>     >
>>     > I can have time to read the meeting log of the I18N team this week
>>     [1].
>>     >
>>     > According to the log, the team agreed that we maintain two
resources
>>     > (1 stable + current)
>>     > for accepting translations. Now Juno is released, so we maintain
>>     > resources for Juno and current,
>>     > and we no longer accepts translations for Icehouse. I think it is
>>     reasonable.
>>     >
>>     > According to this policy, we will delete havana and Icehouse
>>     > translations from Transifex. Right?
>>     >
>>     > Now it raise me a couple of questions on how to handle Icehouse
>>     translations.
>>     >
>>     > (1) Until when we accept Icehouse (previous current stable)?
>>     >
>>     > My idea is we accept translations until the first stable update
>>     for Icehouse
>>     > after the new stable (Juno) is released, i.e, until Icehouse
2014.1.4.
>>     > By doing so, we don't lose Icehouse translations before Juno
release.
>>     > I see Russian translation made a great progress after the last
import
>>     > for Icehouse (2014.1.2)
>>     > and it is worth imported.
>>     >
>>     +1
>>
>>     > (2) When we remove the previous current stable (Icehouse) from
>>     Transifex?
>>     >
>>     > My idea is just after the timing of (1), i.e., just after Icehouse
>>     > udpate 2014.1.4 is released.
>>     >
>>
>>     How do you think of just marking them as "not accept translation"?
>>
>>
>> What is a merit of keeping old translations with "not accept
translation"?
>
>
> This is my understanding (could be 100% wrong) of how the translation
> dictionary works...
>
> Scenario 1 "Keep old translations":
> * String from old version appears as suggestion in new version
>
> Scenario 2 "Delete old translations":
> * No suggestion strings based on old versions appear when translating
> new versions
>
>
> So, potentially, removing the old translations destroys some useful
> translation dictionary entries. I could be completely wrong here, so it
> is worth confirming this, if such translation dictionary entries are
> deemed useful :)

Yes. this is a very important point.
We need to check if the translation memory is kept after deleting some
resources.
IIRC Daisy said she will check it.
I just would like to clarify the reason of decisions. If we need more time
to check it, it is also a good reason to keep resources.

Thanks
Akihiro
>
>
>> When we mark them so? When will they be deleted?
>>
>> I am okay with either option as long as there is a concrete proposal.
>> Honestly just an question does not help me.
>> I am tired from coordinating various dates.
>>
>> Personally I don't like the progress percentage is displayed with higher
>> value
>> due to old translation?
>>
>>
>>
>>     > Thought?
>>     >
>>     > Note that the above proposal does not necessarily mean I can work
for
>>     > importing them.
>>     >
>>     > [1] http://eavesdrop.openstack.org/meetings/openstack_i18n_meeting/
>>     > 2014/openstack_i18n_meeting.2014-10-16-08.00.log.html
>>     >
>>     > On Fri, Oct 3, 2014 at 6:41 PM, Akihiro Motoki <amotoki at gmail.com
<javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com <javascript:;>');>>
wrote:
>>     > > Hi all,
>>     > >
>>     > > In this mail I would like to discuss what releases do we accept
>>     > translations.
>>     > >
>>     > > At now there is no systematic process when we import translations
>>     > > after the initial release of some version (Juno, Icehouse, ...).
>>     > > Importing translations to stable update is done occasionally so
far.
>>     > > It is almost up to me. When I noticed some need for translation
>>     update
>>     > > (mainly in Japanese :-)), I propose a patch to import
translations.
>>     > > It is really not systematic. If I am busy, I don't check it.
>>     > > This is the reason the first Icehouse update didn't have
>>     translation update.
>>     > >
>>     > > Questions are:
>>     > >
>>     > > - What release(s) we accept translations?
>>     > >   Note that "Accept translations" means translations will be
>>     imported
>>     > > into a stable branch and releases as a part of the stable update
>>     > > release.
>>     > >
>>     > >   My idea is to accept translations only for the latest stable
>>     release.
>>     > >
>>     > > - When should we import translations to a stable branch?
>>     > >   Systematically (as a team)? Occasionally (up to someone's
>>     interest)?
>>     > >
>>     > >   My vote is to import translations for each stable update of the
>>     > > latest stable branch.
>>     > >   At least the first and second stable update (201X.Y.1 or .2)
>>     need to
>>     > > be considered.
>>     > >
>>     > >
>>     > > If we decide to do import as a stable release process as a team,
>>     > > we should assign someone to work on for each stable update
>>     > > (because I can't always take care of it).
>>     > > Assigned person(s) should check the date of a next stable update,
>>     > > check if there are new translations to be imported, and then
propose
>>     > > a patch to import translations to a corresponding stable branch.
>>     > >
>>     > > I already have a consensus with the stable maintenance team that
>>     > > the deadline of translations import proposal is 3 day after the
>>     freeze date.
>>     > > The freeze date of a stable maintenance release is usually
announced
>>     > > in stable-maint list.
>>     > >
>>     > > Thought? Any volunteer?
>>     > >
>>     > > --
>>     > > Akihiro Motoki <amotoki at gmail.com <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com <javascript:;>');>>
>>     >
>>     >
>>     >
>>     > --
>>     > Akihiro Motoki <amotoki at gmail.com <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com <javascript:;>');>>
>>     >
>>     > _______________________________________________
>>     > Openstack-i18n mailing list
>>     > Openstack-i18n at lists.openstack.org <javascript:;>
>>     <javascript:_e(%7B%7D,'cvml','Openstack-i18n at lists.openstack.org
<javascript:;>');>
>>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>>     >
>>
>>
>>
>> --
>> Akihiro Motoki <amotoki at gmail.com <javascript:;> <mailto:
amotoki at gmail.com <javascript:;>>>
>>
>>
>> _______________________________________________
>> Openstack-i18n mailing list
>> Openstack-i18n at lists.openstack.org <javascript:;>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>>
>
>
> _______________________________________________
> Openstack-i18n mailing list
> Openstack-i18n at lists.openstack.org <javascript:;>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n



--
Akihiro Motoki <amotoki at gmail.com <javascript:;>>


-- 
Akihiro Motoki <amotoki at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20141024/cc755c64/attachment.html>


More information about the Openstack-i18n mailing list