<html><body>
<p><font size="2" face="sans-serif">Thank you for deep thinking.</font><br>
<font size="2" face="sans-serif">They are all useful information to the team.</font><br>
<font size="2" face="sans-serif">See my comments below.</font><br>
<br>
<tt><font size="2">Akihiro Motoki <amotoki@gmail.com> wrote on 2015/10/13 14:01:36:<br>
<br>
> From: Akihiro Motoki <amotoki@gmail.com></font></tt><br>
<tt><font size="2">> To: Ying Chun Guo/China/IBM@IBMCN</font></tt><br>
<tt><font size="2">> Cc: Openstack-i18n <openstack-i18n@lists.openstack.org></font></tt><br>
<tt><font size="2">> Date: 2015/10/13 14:02</font></tt><br>
<tt><font size="2">> Subject: Re: [Openstack-i18n] Approved & rejected translations after<br>
> versions merging</font></tt><br>
<tt><font size="2">> <br>
> Hi Daisy,<br>
> <br>
> Your test result on version merging below is true, and I found all I<br>
> encountered<br>
> are based on this behavior. I think these behaviors may sometimes beconfusing,<br>
> so I summarize my lessons learned.<br>
> <br>
> I would like to know opinions from all.<br>
> Honestly speaking I don't have a good workaround for Case 1.<br>
> <br>
> ----------------<br>
> <br>
> Lessons I learned are:<br>
> <br>
> (Case 1)<br>
> If you made some changes in stable-xxx version but still mark them as<br>
> "rejected",<br>
> these changes will not be merged back into the master version.<br>
> <br>
> *** As a practice, you should not remain "rejected" strings in<br>
> stable-xxxx version.<br>
> Otherwise we manually need to "reject" them in the master version<br>
> again. ***<br>
> <br>
> It means if you don't have enough time to consider better translations<br>
> for rejected strings<br>
> in stable-xxxx version, you need to mark them as "rejected" again in<br>
> the master version.<br>
> I don't have a good workaround for this except encouraging finishing reviews.<br>
></font></tt><br>
<br>
<tt><font size="2">I don't have too.</font></tt><br>
<tt><font size="2">When copying translations and merging versions, Zanata will only handle</font></tt><br>
<tt><font size="2">the translated and approved translations. So "rejected" and "fuzzy" translations</font></tt><br>
<tt><font size="2">will not be copied.</font></tt><br>
<tt><font size="2">I think we could discuss with Zanata team about whether it is a common requirement.</font></tt><br>
<tt><font size="2">If it's a common requirement, when copying trans, we want the review results</font></tt><br>
<tt><font size="2">to be copied too, let's raise a new requirement to Zanata team.</font></tt><br>
<tt><font size="2">If Zanata team don't think it's a common requirement, we could ask them</font></tt><br>
<tt><font size="2">to provide either CLI or API, let's write scripts to do the copy by ourselves.</font></tt><br>
<tt><font size="2"> <br>
> (Case 2)<br>
> If you do nothing for a string in stable-xxx and reject a<br>
> corresponding string in the master branch,<br>
> the "rejected" string in the master branch will be reset to<br>
> "translated" when merging back<br>
> stable-xxx version. (Note that a change made in a master version will<br>
> be overridden<br>
> by the untouched string in stable-xxx if you mark the changed string<br>
> in the master version as "rejected")<br>
> <br>
> *** You should not work on the master version after branching<br>
> stable-xxx branch. ***<br>
> <br>
> ----------------<br>
> <br>
> Why I encountered?<br>
> <br>
> For Case 1, I tried to focus on avoiding shipping non-good<br>
> translations in Liberty release.<br>
> I knew I had no enough time to improve them. As a result, I was forced<br>
> to reject again the same strings<br>
> in the master version. I have no idea on what I could do better.<br>
> <br>
> For Case 2, both master and stable-liberty versions were kept open for<br>
> some resources.<br>
> I used shortcut links to access translation pages directly, so I did<br>
> not notice stable-liberty version.<br>
> It seems I started IBM translation reviews too early.<br>
> <br>
> ----------------<br>
> What we can do for the next release?<br>
> <br>
> For Case 1:<br>
> I have no idea except finishing reviews and cleaning up all rejected<br>
> strings, but<br>
> Only rejecting strings may force reviewers to reject them again.<br>
> It is a resource problem. Is the only way to add more reviewers?<br>
> <br>
> For Case 2:<br>
> We should mark the master version as read-only at the same time we<br>
> create a stable-liberty<br>
> if we plan to merge back stable-xxxx version into the master version.<br>
> <br>
> I hope the community find a good way.<br>
> <br>
> Best Regards,<br>
> Akihiro<br>
> <br>
> -----<br>
> <br>
> Personally speaking, I have no interest in translating server and<br>
> client projects<br>
> at the moment based on our survey result (as my translation effort).<br>
> It might be changed if Horizon starts to use server-side <br>
> translations directly.<br>
> I am okay to ship unreviewed translations for server side project<br>
> AS LONG AS they are not visible in default configurations.<br>
> If visible by default but we have no enough resource to check them, we<br>
> may be better<br>
> to consider not shipping translations based on each language team decision.<br>
> <br>
> 2015-10-09 1:49 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:<br>
> > During checking "ceilometer" Japanese translation, I found another issue.<br>
> > I noticed some rejected strings in the master branch is overridden by<br>
> > old translation in stable-liberty<br>
> > and the status was reset to "Translated". I suspect it is a<br>
> > side-effect of merging stable-liberty.<br>
> ><br>
> > <a href="https://translate.openstack.org/webtrans/translate?">https://translate.openstack.org/webtrans/translate?</a><br>
> project=ceilometer&iteration=master&localeId=ja&locale=ja#view:doc;doc:ceilometer<br>
> > resource ID 93fc08cfc55420bbf5e5b340296a3905 is an example.<br>
> ><br>
> > The detail situation is as follows.<br>
> > - The string was copied from ibm-translation-for-review to master<br>
> > branch at Sep 21.<br>
> > - It was also copied to stable-liberty branch when stable-liberty <br>
> was created.<br>
> > - On Sep 27, I change the string in the master branch by using<br>
> > "Project-wide search and replace".<br>
> > (Note that changes in "Project-wide search and replace" are not<br>
> > recorded as "Translated"<br>
> > and they are recorded as "Rejected" for new strings)<br>
> > - On Oct 08, the string was overridden by the from stable-liberty branch<br>
> ><br>
> > Apparently the string in the master branch is newer than the<br>
> > corresponding string in stable-liberty branch.<br>
> > I wonder why it was overridden.<br>
> ><br>
> > The following are the history both in master and stable-liberty branches.<br>
> ><br>
> > In master branch, (a lower one is older)<br>
> ><br>
> > - Tom Cocozzello created a Translated revision<br>
> > パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ<br>
> ログラム・瘢雹インスタンス %(name)s をセットアップします<br>
> > 08/10/15 22:17 Revision 3<br>
> > Merge version: translation copied from project 'ceilometer', version<br>
> > 'stable-liberty', document 'ceilometer', author 'Tom Cocozzello'<br>
> > - Akihiro Motoki created a Rejected revision<br>
> > パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ<br>
> ログラムインスタンス %(name)s をセットアップします<br>
> > 27/09/15 23:50<br>
> > - Mie Yamamoto created a Rejected revision<br>
> > パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ<br>
> ログラム・瘢雹インスタンス %(name)s をセットアップします<br>
> > 27/09/15 09:30<br>
> > - Mie Yamamoto left a comment<br>
> > 中黒（・瘢雹）は使用しない<br>
> > 27/09/15 09:30<br>
> > - Tom Cocozzello created a Translated revision<br>
> > パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ<br>
> ログラム・瘢雹インスタンス %(name)s をセットアップします<br>
> > 21/09/15 22:27<br>
> > Copy translation: translation copied from project 'ceilometer',<br>
> > version 'ibm-translation-for-review', document 'ceilometer', author<br>
> > 'Tom Cocozzello'<br>
> ><br>
> > In stable-liberty branch, only one history.<br>
> ><br>
> > - Tom Cocozzello created a Translated revision<br>
> > パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ<br>
> ログラム・瘢雹インスタンス %(name)s をセットアップします<br>
> > 21/09/15 22:27 Revision 1<br>
> > Copy version: translation copied from project 'ceilometer', version<br>
> > 'ibm-translation-for-review', document 'ceilometer', author 'Tom<br>
> > Cocozzello'<br>
> ><br>
> > 2015-10-09 0:57 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:<br>
> >> Akihiro Motoki <amotoki@gmail.com> wrote on 10/08/2015 10:37:21 PM:<br>
> >><br>
> >>> From: Akihiro Motoki <amotoki@gmail.com><br>
> >>> To: Ying Chun Guo/China/IBM@IBMCN<br>
> >>> Cc: Openstack-i18n <openstack-i18n@lists.openstack.org><br>
> >>> Date: 10/08/2015 10:38 PM<br>
> >>> Subject: Re: [Openstack-i18n] Approved & rejected translations after<br>
> >>> versions merging<br>
> >>><br>
> >>> Thanks Daisy,<br>
> >>><br>
> >>> You are correct.<br>
> >>><br>
> >>> I rechecked both master and stable-liberty translations more carefully<br>
> >>> and it turned out it is a corner case.<br>
> >>> I noticed all of such strings are rejected in both master and<br>
> >>> stable-liberty<br>
> >>> and most of them (all? I am not sure) are edited through "Project-<br>
> >>> wide Search & Replace".<br>
> >>> When we edit "rejected" strings with "Project-wide Search & Replace",<br>
> >>> the strings still remains in "rejected" status.<br>
> >><br>
> >> The lesson learned is valuable to the whole team.<br>
> >> I didn't know the rejected strings still remain in "rejected"<br>
> >> even they are updated.<br>
> >> Thank you, Akihiro.<br>
> >> We are all learning to play with Zanata.<br>
> >> We will get better and better.<br>
> >><br>
> >>><br>
> >>> It seems that I started to review nova translations too early and<br>
> >>> unfortunately we cannot complete reviews due to the volume.<br>
> >>> As a result, we hit "not a good practice" you said.<br>
> >>><br>
> >>> I learned one practice that if we are not confident with addressing<br>
> >>> "rejected" strings<br>
> >>> which already exist in master branch, we should not touch such string,<br>
> >>> I learned much more detail conditions, but perhaps it only applies to me.<br>
> >>><br>
> >>> Thanks,<br>
> >>> Akihiro<br>
> >>><br>
> >>> 2015-10-08 22:39 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:<br>
> >>> I cannot agree with you, Akihiro.<br>
> >>> When stable-liberty version was created, we set master version as "Read<br>
> >>> Only".<br>
> >>> Translators had to improve stable-liberty branch.<br>
> >>> The corrections made in stable-liberty version is newer than the old<br>
> >>> translations in master version.<br>
> >>> So when I merged, the newer translations will be copied and replaced<br>
> >>> the old translations.<br>
> >>> So the corrections will be moved to the master version.<br>
> >>><br>
> >>> But the rejections will not.<br>
> >>> So it's not a good practise to only reject translations in stable-<br>
> >>> liberty without input the correct translations.<br>
> >>><br>
> >>> Could you check in Nova master version?<br>
> >>> I think your corrections to IBM translations should be moved to<br>
> >>> master version.<br>
> >>><br>
> >>> Best regards<br>
> >>> Ying Chun Guo (Daisy)<br>
> >>><br>
> >>><br>
> >>> Akihiro Motoki <amotoki@gmail.com> wrote on 10/08/2015 09:31:36 PM:<br>
> >>><br>
> >>> > From: Akihiro Motoki <amotoki@gmail.com><br>
> >>> > To: Ying Chun Guo/China/IBM@IBMCN<br>
> >>> > Cc: Openstack-i18n <openstack-i18n@lists.openstack.org><br>
> >>> > Date: 10/08/2015 09:32 PM<br>
> >>> > Subject: Re: [Openstack-i18n] Approved & rejected translations after<br>
> >>> > versions merging<br>
> >>> ><br>
> >>> > On a second thought, I start to think this can happen in every<br>
> >>> > OpenStack release.<br>
> >>> ><br>
> >>> > What can possibly happen?<br>
> >>> ><br>
> >>> > Most reviews are done after RC1 is released. It means reviews and<br>
> >>> > corrections are done in stable-xxxx branch.<br>
> >>> > It is not a rare case that strings are also translated in the master<br>
> >>> > branch.<br>
> >>> > In this case, corrections in stable-xxxx branch will not be<br>
> >>> > feedback-ed to the master branch<br>
> >>> > and this means that translators/reviewers need to do the same thing<br>
> >>> > again and can lead to<br>
> >>> > inconsistent translations.<br>
> >>> ><br>
> >>> > What can we do?<br>
> >>> ><br>
> >>> > I don't think we have a general solution to this.<br>
> >>> > Zanata's current behavior may work well in most cases, but does not<br>
> >>> > work for us.<br>
> >>> ><br>
> >>> > One possible solution is to allow language coordinators (or<br>
> >>> > reviewers) to upload PO files.<br>
> >>> > Language coordinators (or reviewers) can use diff tools locally and<br>
> >>> > merge translations<br>
> >>> > more efficiently. The demand may be different among languages.<br>
> >>> > If they can upload PO files, we can cope with this lang by lang.<br>
> >>> ><br>
> >>> > Thought?<br>
> >>> ><br>
> >>> > Akihiro<br>
> >>> ><br>
> >>> > 2015-10-08 19:37 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:<br>
> >>> > Daisy,<br>
> >>> ><br>
> >>> > Is there any way to apply modifications made in stable-liberty branch<br>
> >>> > to the master branch?<br>
> >>> ><br>
> >>> > We made a lot of modifications/fixes to strings from IBM translation<br>
> >>> > contribution<br>
> >>> > in stable-liberty branch. The master branch already has translations<br>
> >>> > because<br>
> >>> > it is contributed by IBM, so merging from liberty to master does<br>
> >>> not help us.<br>
> >>> ><br>
> >>> > It seems translators or language coordinator cannot upload PO files,<br>
> >>> > so I cannot have a way to replace the master translation with the<br>
> >>> > liberty version<br>
> >>> > in a batch way.<br>
> >>> ><br>
> >>> > We don't want to check >100 rejected strings and copy >100 modified<br>
> >>> > strings<br>
> >>> > from liberty manually.<br>
> >>> ><br>
> >>> > Is there any suggestion?<br>
> >>> ><br>
> >>> > Akihiro<br>
> >>> ><br>
> >>> > 2015-10-03 2:12 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:<br>
> >>> > Hi,<br>
> >>> ><br>
> >>> > A translation could be approved or rejected. This action is called<br>
> >>> > translation review.<br>
> >>> > A version merging is to copy all matching translated/approved<br>
> >>> > translations from the source version to the target version.<br>
> >>> > If there is an existing translated/approved translation, the newer<br>
> >>> > translation will be used.<br>
> >>> > After liberty translations are closed, we will merge translations<br>
> >>> > from stable-liberty version to master version,<br>
> >>> > and then open both stable-liberty version and master version to<br>
> >>> > accept translations.<br>
> >>> > I investigated whether translation review would be copied after<br>
> >>> > version merging.<br>
> >>> ><br>
> >>> > Here are the results:<br>
> >>> > The review result - "approve" will be copied to the target version,<br>
> >>> > while the review result - "reject" will not.<br>
> >>> > Only "rejecting" existing translations will not have the same<br>
> >>> > translations rejected in master version.<br>
> >>> > But "approving" existing translations will have the same<br>
> >>> > translations approved in the master version.<br>
> >>> > That means, if there are "rejected" translations in stable-liberty,<br>
> >>> > it's better to input the correct translations.<br>
> >>> ><br>
> >>> > The investigation result is OK with me.<br>
> >>> > If you have different opinions, please propose here.<br>
> >>> > If you want to understand more about version merging, please let me<br>
> >>> > know.<br>
> >>> ><br>
> >>> > Best regards<br>
> >>> > Ying Chun Guo (Daisy)<br>
> >>><br>
> >>> > _______________________________________________<br>
> >>> > Openstack-i18n mailing list<br>
> >>> > Openstack-i18n@lists.openstack.org<br>
> >>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n</a><br>
> <br>
</font></tt></body></html>