Translation update process for stable branch(es)
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@gmail.com>
Le 03/10/2014 11:41, Akihiro Motoki a écrit :
Thought? Any volunteer?
Do we have to be already part of https://review.openstack.org/#/admin/groups/120,members to volunteer or not? -- Yves-Gwenaël Bourhis
On Fri, Oct 3, 2014 at 9:57 PM, Yves-Gwenaël Bourhis <yves-gwenael.bourhis@cloudwatt.com> wrote:
Le 03/10/2014 11:41, Akihiro Motoki a écrit :
Thought? Any volunteer?
Do we have to be already part of https://review.openstack.org/#/admin/groups/120,members to volunteer or not?
I don't think we need to be a part of stable-maint core team because everyone can propose a patch. What we need is just to propose a patch to import translations. Perhaps I usually serve the role but I am not sure I always can. Just I think it is better to be a part of I18N team jobs. I have a script to do it and we can share my repository. -- Akihiro Motoki <amotoki@gmail.com>
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. (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. 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/openstac... On Fri, Oct 3, 2014 at 6:41 PM, Akihiro Motoki <amotoki@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@gmail.com>
-- Akihiro Motoki <amotoki@gmail.com>
Akihiro Motoki <amotoki@gmail.com> 2014/10/22 21:09
To
"openstack-i18n@lists.openstack.org" <Openstack-i18n@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
Akihiro Motoki <amotoki@gmail.com> wrote on 2014/10/22 21:09:51: 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"?
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
Hi all,
In this mail I would like to discuss what releases do we accept
On Fri, Oct 3, 2014 at 6:41 PM, Akihiro Motoki <amotoki@gmail.com> wrote: 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@gmail.com>
-- Akihiro Motoki <amotoki@gmail.com>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
2014年10月23日木曜日、Ying Chun Guo<guoyingc@cn.ibm.com>さんは書きました:
Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> wrote on 2014/10/22 21:09:51:
Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> 2014/10/22 21:09
To
"openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','openstack-i18n@lists.openstack.org');>" < Openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','Openstack-i18n@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"? 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
Hi all,
In this mail I would like to discuss what releases do we accept
On Fri, Oct 3, 2014 at 6:41 PM, Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> wrote: 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@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>>
-- Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','Openstack-i18n@lists.openstack.org');> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Akihiro Motoki <amotoki@gmail.com>
On 23/10/14 21:07, Akihiro Motoki wrote:
2014年10月23日木曜日、Ying Chun Guo<guoyingc@cn.ibm.com <mailto:guoyingc@cn.ibm.com>>さんは書きました:
Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> wrote on 2014/10/22 21:09:51:
> Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > 2014/10/22 21:09 > > To > > "openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','openstack-i18n@lists.openstack.org');>" <Openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','Openstack-i18n@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 :)
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@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@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@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > > > -- > Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > _______________________________________________ > Openstack-i18n mailing list > Openstack-i18n@lists.openstack.org <javascript:_e(%7B%7D,'cvml','Openstack-i18n@lists.openstack.org');> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >
-- Akihiro Motoki <amotoki@gmail.com <mailto:amotoki@gmail.com>>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
On 23/10/14 21:07, Akihiro Motoki wrote:
2014年10月23日木曜日、Ying Chun Guo<guoyingc@cn.ibm.com <javascript:;> <mailto:guoyingc@cn.ibm.com <javascript:;>>>さんは書きました:
Akihiro Motoki <amotoki@gmail.com <javascript:;> <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com <javascript:;>');>>
wrote on
2014/10/22 21:09:51:
> Akihiro Motoki <amotoki@gmail.com <javascript:;> <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com <javascript:;>');>> > 2014/10/22 21:09 > > To > > "openstack-i18n@lists.openstack.org <javascript:;> <javascript:_e(%7B%7D,'cvml','openstack-i18n@lists.openstack.org
<javascript:;>');>" <Openstack-i18n@lists.openstack.org <javascript:;>
<javascript:_e(%7B%7D,'cvml','Openstack-i18n@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
On Thu, Oct 23, 2014 at 10:17 PM, Tom Fifield <tom@openstack.org <javascript:;>> wrote: 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
> 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@gmail.com
<javascript:;>
<javascript:_e(%7B%7D,'cvml','amotoki@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
> > 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
for translations. 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@gmail.com <javascript:;> <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com <javascript:;>');>> > > > > -- > Akihiro Motoki <amotoki@gmail.com <javascript:;> <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com <javascript:;>');>> > > _______________________________________________ > Openstack-i18n mailing list > Openstack-i18n@lists.openstack.org <javascript:;> <javascript:_e(%7B%7D,'cvml','Openstack-i18n@lists.openstack.org
<javascript:;>');>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >
-- Akihiro Motoki <amotoki@gmail.com <javascript:;> <mailto:
amotoki@gmail.com <javascript:;>>>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org <javascript:;> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org <javascript:;> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Akihiro Motoki <amotoki@gmail.com <javascript:;>> -- Akihiro Motoki <amotoki@gmail.com>
Akihiro Motoki <amotoki@gmail.com> 2014/10/24 08:01
To
Tom Fifield <tom@openstack.org>,
cc
"openstack-i18n@lists.openstack.org" <openstack-i18n@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@openstack.org> wrote:
On 23/10/14 21:07, Akihiro Motoki wrote:
2014年10月23日木曜日、Ying Chun Guo<guoyingc@cn.ibm.com <mailto:guoyingc@cn.ibm.com>>さんは書きました:
Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> wrote on 2014/10/22 21:09:51:
> Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > 2014/10/22 21:09 > > To > > "openstack-i18n@lists.openstack.org <javascript:_e
(%7B%7D,'cvml','openstack-i18n@lists.openstack.org');>" < Openstack-i18n@lists.openstack.org
<javascript:_e (%7B%7D,'cvml','Openstack-i18n@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
Akihiro Motoki <amotoki@gmail.com> wrote on 2014/10/24 08:01:25: 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@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@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
> > 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
update > > (mainly in Japanese :-)), I propose a patch to import
> > 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
> > 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
> > the deadline of translations import proposal is 3 day after
It's not clearly documented. I have sent a question to Transifex support team and wait for the response. translations translation translations. the that the
freeze date. > > The freeze date of a stable maintenance release is usually announced > > in stable-maint list. > > > > Thought? Any volunteer? > > > > -- > > Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > > > -- > Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > _______________________________________________ > Openstack-i18n mailing list > Openstack-i18n@lists.openstack.org <javascript:_e (%7B%7D,'cvml','Openstack-i18n@lists.openstack.org');> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >
-- Akihiro Motoki <amotoki@gmail.com <mailto:amotoki@gmail.com>>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Akihiro Motoki <amotoki@gmail.com>
-- Akihiro Motoki <amotoki@gmail.com> _______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
Akihiro Motoki <amotoki@gmail.com> 2014/10/24 08:01
To
Tom Fifield <tom@openstack.org>,
cc
"openstack-i18n@lists.openstack.org" <openstack-i18n@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@openstack.org> wrote:
On 23/10/14 21:07, Akihiro Motoki wrote:
2014年10月23日木曜日、Ying Chun Guo<guoyingc@cn.ibm.com <mailto:guoyingc@cn.ibm.com>>さんは書きました:
Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> wrote on 2014/10/22 21:09:51:
> Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > 2014/10/22 21:09 > > To > > "openstack-i18n@lists.openstack.org <javascript:_e
(%7B%7D,'cvml','openstack-i18n@lists.openstack.org');>" < Openstack-i18n@lists.openstack.org
<javascript:_e (%7B%7D,'cvml','Openstack-i18n@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
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@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@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
> > 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
update > > (mainly in Japanese :-)), I propose a patch to import
> > 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
> > 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
> > the deadline of translations import proposal is 3 day after
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@gmail.com> wrote on 2014/10/24 08:01:25: translation"? translations translation translations. the that the
freeze date. > > The freeze date of a stable maintenance release is usually announced > > in stable-maint list. > > > > Thought? Any volunteer? > > > > -- > > Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > > > -- > Akihiro Motoki <amotoki@gmail.com <javascript:_e(%7B%7D,'cvml','amotoki@gmail.com');>> > > _______________________________________________ > Openstack-i18n mailing list > Openstack-i18n@lists.openstack.org <javascript:_e (%7B%7D,'cvml','Openstack-i18n@lists.openstack.org');> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >
-- Akihiro Motoki <amotoki@gmail.com <mailto:amotoki@gmail.com>>
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Akihiro Motoki <amotoki@gmail.com>
-- Akihiro Motoki <amotoki@gmail.com> _______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
participants (4)
-
Akihiro Motoki
-
Tom Fifield
-
Ying Chun Guo
-
Yves-Gwenaël Bourhis