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

Ying Chun Guo guoyingc at cn.ibm.com
Tue Oct 28 01:55:47 UTC 2014


Responses from Transfix support team:
"Even when you'll remove the A file, its old translations will be still
kept in the Translation Memory of your project."

So it will be safe to remove the old translation files from Transifex.

Yet things may be different in other translation tools.
In Zanata, 'archived projects', or removed documents' translations will not
show up in the translation memory.
There is a feature in Zanata where you can set your project or version to
"Read-only" mode. This guarantees that nobody can submit new translations,
but these translations still show up in the translation memory.

I agree to remove the old translation files from Transifex.
But when we move to other translation tool, we may need to be reconsider
it.

Regards
Daisy


Akihiro Motoki <amotoki at gmail.com> wrote on 2014/10/24 08:01:25:

> Akihiro Motoki <amotoki at gmail.com>
> 2014/10/24 08:01
>
> To
>
> Tom Fifield <tom at openstack.org>,
>
> cc
>
> "openstack-i18n at lists.openstack.org" <openstack-i18n at lists.openstack.org>
>
> Subject
>
> [Openstack-i18n] Translation update process for stable branch(es)
>
>
>
> On Thu, Oct 23, 2014 at 10:17 PM, Tom Fifield <tom at openstack.org> wrote:
> > On 23/10/14 21:07, Akihiro Motoki wrote:
> >>
> >>
> >> 2014年10月23日木曜日、Ying Chun Guo<guoyingc at cn.ibm.com
> >> <mailto:guoyingc at cn.ibm.com>>さんは書きました:
> >>
> >>     Akihiro Motoki <amotoki at gmail.com
> >>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com');>> wrote on
> >>     2014/10/22 21:09:51:
> >>
> >>     > Akihiro Motoki <amotoki at gmail.com
> >>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com');>>
> >>     > 2014/10/22 21:09
> >>     >
> >>     > To
> >>     >
> >>     > "openstack-i18n at lists.openstack.org
> >>     <javascript:_e
(%7B%7D,'cvml','openstack-i18n at lists.openstack.org');>" <
> Openstack-i18n at lists.openstack.org
> >>     <javascript:_e
(%7B%7D,'cvml','Openstack-i18n at lists.openstack.org');>>,
> >>     >
> >>     > 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:_e(%7B%7D,'cvml','amotoki at gmail.com');>> 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:_e(%7B%7D,'cvml','amotoki at gmail.com');>>
> >>     >
> >>     >
> >>     >
> >>     > --
> >>     > Akihiro Motoki <amotoki at gmail.com
> >>     <javascript:_e(%7B%7D,'cvml','amotoki at gmail.com');>>
> >>     >
> >>     > _______________________________________________
> >>     > Openstack-i18n mailing list
> >>     > Openstack-i18n at lists.openstack.org
> >>     <javascript:_e
(%7B%7D,'cvml','Openstack-i18n at lists.openstack.org');>
> >>     >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> >>     >
> >>
> >>
> >>
> >> --
> >> Akihiro Motoki <amotoki at gmail.com <mailto:amotoki at gmail.com>>
> >>
> >>
> >> _______________________________________________
> >> Openstack-i18n mailing list
> >> Openstack-i18n at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> >>
> >
> >
> > _______________________________________________
> > Openstack-i18n mailing list
> > Openstack-i18n at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
>
>
> --
> Akihiro Motoki <amotoki at gmail.com>
>
>
> --
> Akihiro Motoki <amotoki at gmail.com>
> _______________________________________________
> Openstack-i18n mailing list
> Openstack-i18n at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20141028/751923e3/attachment-0001.html>


More information about the Openstack-i18n mailing list