Ying Chun Guo/China/IBM@IBMCN wrote on 2015/10/13 17:21:11:

> From: Ying Chun Guo/China/IBM@IBMCN
> To: Akihiro Motoki <amotoki@gmail.com>
> Cc: Openstack-i18n <openstack-i18n@lists.openstack.org>
> Date: 2015/10/13 17:25
> Subject: Re: [Openstack-i18n] Approved & rejected translations after

> versions merging
> 

> Thank you for deep thinking.

> They are all useful information to the team.

> See my comments below.

> 

> Akihiro Motoki <amotoki@gmail.com> wrote on 2015/10/13 14:01:36:

> 

> > From: Akihiro Motoki <amotoki@gmail.com>

> > To: Ying Chun Guo/China/IBM@IBMCN

> > Cc: Openstack-i18n <openstack-i18n@lists.openstack.org>

> > Date: 2015/10/13 14:02

> > Subject: Re: [Openstack-i18n] Approved & rejected translations after

> > versions merging

> > 

> > Hi Daisy,

> > 

> > Your test result on version merging below is true, and I found all I

> > encountered

> > are based on this behavior. I think these behaviors may sometimes 

> beconfusing,

> > so I summarize my lessons learned.

> > 

> > I would like to know opinions from all.

> > Honestly speaking I don't have a good workaround for Case 1.

> > 

> > ----------------

> > 

> > Lessons I learned are:

> > 

> > (Case 1)

> > If you made some changes in stable-xxx version but still mark them as

> > "rejected",

> > these changes will not be merged back into the master version.

> > 

> > *** As a practice, you should not remain "rejected" strings in

> > stable-xxxx version.

> >      Otherwise we manually need to "reject" them in the master version

> > again. ***

> > 

> > It means if you don't have enough time to consider better translations

> > for rejected strings

> > in stable-xxxx version, you need to mark them as "rejected" again in

> > the master version.

> > I don't have a good workaround for this except encouraging 

> finishing reviews.

> >

> 

> I don't have too.

> When copying translations and merging versions, Zanata will only handle

> the translated and approved translations. So "rejected" and "fuzzy" 

> translations

> will not be copied.

> I think we could discuss with Zanata team about whether it is a 

> common requirement.

> If it's a common requirement, when copying trans, we want the review results

> to be copied too, let's raise a new requirement to Zanata team.

> If Zanata team don't think it's a common requirement, we could ask them

> to provide either CLI or API, let's write scripts to do the copy by ourselves.

>  

> > (Case 2)

> > If you do nothing for a string in stable-xxx and reject a

> > corresponding string in the master branch,

> > the "rejected" string in the master branch will be reset to

> > "translated" when merging back

> > stable-xxx version. (Note that a change made in a master version will

> > be overridden

> > by the untouched string in stable-xxx if you mark the changed string

> > in the master version as "rejected")

> > 

> > *** You should not work on the master version after branching

> > stable-xxx branch. ***

> > 

> > ----------------

> > 

> > Why I encountered?

> > 

> > For Case 1, I tried to focus on avoiding shipping non-good

> > translations in Liberty release.

> > I knew I had no enough time to improve them. As a result, I was forced

> > to reject again the same strings

> > in the master version. I have no idea on what I could do better.

> > 

> > For Case 2, both master and stable-liberty versions were kept open for

> > some resources.

> > I used shortcut links to access translation pages directly, so I did

> > not notice stable-liberty version.

> > It seems I started IBM translation reviews too early.

> > 

> > ----------------

> > What we can do for the next release?

> > 

> > For Case 1:

> > I have no idea except finishing reviews and cleaning up all rejected

> > strings, but

> > Only rejecting strings may force reviewers to reject them again.

> > It is a resource problem. Is the only way to add more reviewers?

> > 

> > For Case 2:

> > We should mark the master version as read-only at the same time we

> > create a stable-liberty

> > if we plan to merge back stable-xxxx version into the master version.

> > 

> > I hope the community find a good way.

> > 

> > Best Regards,

> > Akihiro

> > 

> > -----

> > 

> > Personally speaking, I have no interest in translating server and

> > client projects

> > at the moment based on our survey result (as my translation effort).

> > It might be changed if Horizon starts to use server-side 

> > translations directly.

> > I am okay to ship unreviewed translations for server side project

> > AS LONG AS they are not visible in default configurations.

> > If visible by default but we have no enough resource to check them, we

> > may be better

> > to consider not shipping translations based on each language team decision.

> > 

> > 2015-10-09 1:49 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:

> > > During checking "ceilometer" Japanese translation, I found another issue.

> > > I noticed some rejected strings in the master branch is overridden by

> > > old translation in stable-liberty

> > > and the status was reset to "Translated". I suspect it is a

> > > side-effect of merging stable-liberty.

> > >

> > > https://translate.openstack.org/webtrans/translate?

> > 

> project=ceilometer&iteration=master&localeId=ja&locale=ja#view:doc;doc:ceilometer

> > > resource ID 93fc08cfc55420bbf5e5b340296a3905 is an example.

> > >

> > > The detail situation is as follows.

> > > - The string was copied from ibm-translation-for-review to master

> > > branch at Sep 21.

> > > - It was also copied to stable-liberty branch when stable-liberty 

> > was created.

> > > - On Sep 27, I change the string in the master branch by using

> > > "Project-wide search and replace".

> > >   (Note that changes in "Project-wide search and replace" are not

> > > recorded as "Translated"

> > >   and they are recorded as "Rejected" for new strings)

> > > - On Oct 08, the string was overridden by the from stable-liberty branch

> > >

> > > Apparently the string in the master branch is newer than the

> > > corresponding string in stable-liberty branch.

> > > I wonder why it was overridden.

> > >

> > > The following are the history both in master and stable-liberty branches.

> > >

> > > In master branch, (a lower one is older)

> > >

> > > - Tom Cocozzello created a Translated revision

> > >   パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ

> > ログラム・インスタンス %(name)s をセットアップします

> > >   08/10/15 22:17  Revision 3

> > >   Merge version: translation copied from project 'ceilometer', version

> > > 'stable-liberty', document 'ceilometer', author 'Tom Cocozzello'

> > > - Akihiro Motoki created a Rejected revision

> > >   パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ

> > ログラムインスタンス %(name)s をセットアップします

> > >   27/09/15 23:50

> > > - Mie Yamamoto created a Rejected revision

> > >   パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ

> > ログラム・インスタンス %(name)s をセットアップします

> > >   27/09/15 09:30

> > > - Mie Yamamoto left a comment

> > >   中黒（・）は使用しない

> > >   27/09/15 09:30

> > > - Tom Cocozzello created a Translated revision

> > >   パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ

> > ログラム・インスタンス %(name)s をセットアップします

> > >   21/09/15 22:27

> > >   Copy translation: translation copied from project 'ceilometer',

> > > version 'ibm-translation-for-review', document 'ceilometer', author

> > > 'Tom Cocozzello'

> > >

> > > In stable-liberty branch, only one history.

> > >

> > > - Tom Cocozzello created a Translated revision

> > >   パイプライン %(pipeline)s: パラメーター %(param)s を使用して変換プ

> > ログラム・インスタンス %(name)s をセットアップします

> > >   21/09/15 22:27  Revision 1

> > >   Copy version: translation copied from project 'ceilometer', version

> > > 'ibm-translation-for-review', document 'ceilometer', author 'Tom

> > > Cocozzello'

> > >

> > > 2015-10-09 0:57 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

> > >> Akihiro Motoki <amotoki@gmail.com> wrote on 10/08/2015 10:37:21 PM:

> > >>

> > >>> From: Akihiro Motoki <amotoki@gmail.com>

> > >>> To: Ying Chun Guo/China/IBM@IBMCN

> > >>> Cc: Openstack-i18n <openstack-i18n@lists.openstack.org>

> > >>> Date: 10/08/2015 10:38 PM

> > >>> Subject: Re: [Openstack-i18n] Approved & rejected translations after

> > >>> versions merging

> > >>>

> > >>> Thanks Daisy,

> > >>>

> > >>> You are correct.

> > >>>

> > >>> I rechecked both master and stable-liberty translations more carefully

> > >>> and it turned out it is a corner case.

> > >>> I noticed all of such strings are rejected in both master and

> > >>> stable-liberty

> > >>> and most of them (all? I am not sure) are edited through "Project-

> > >>> wide Search & Replace".

> > >>> When we edit "rejected" strings with "Project-wide Search & Replace",

> > >>> the strings still remains in "rejected" status.

> > >>

> > >> The lesson learned is valuable to the whole team.

> > >> I didn't know the rejected strings still remain in "rejected"

> > >> even they are updated.

> > >> Thank you, Akihiro.

> > >> We are all learning to play with Zanata.

> > >> We will get better and better.

> > >>

> > >>>

> > >>> It seems that I started to review nova translations too early and

> > >>> unfortunately we cannot complete reviews due to the volume.

> > >>> As a result, we hit "not a good practice" you said.

> > >>>

> > >>> I learned one practice that if we are not confident with addressing

> > >>> "rejected" strings

> > >>> which already exist in master branch, we should not touch such string,

> > >>> I learned much more detail conditions, but perhaps it only 

> applies to me.

> > >>>

> > >>> Thanks,

> > >>> Akihiro

> > >>>

> > >>> 2015-10-08 22:39 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

> > >>> I cannot agree with you, Akihiro.

> > >>> When stable-liberty version was created, we set master version as "Read

> > >>> Only".

> > >>> Translators had to improve stable-liberty branch.

> > >>> The corrections made in stable-liberty version is newer than the old

> > >>> translations in master version.

> > >>> So when I merged, the newer translations will be copied and replaced

> > >>> the old translations.

> > >>> So the corrections will be moved to the master version.

> > >>>

> > >>> But the rejections will not.

> > >>> So it's not a good practise to only reject translations in stable-

> > >>> liberty without input the correct translations.

> > >>>

> > >>> Could you check in Nova master version?

> > >>> I think your corrections to IBM translations should be moved to

> > >>> master version.

> > >>>

> > >>> Best regards

> > >>> Ying Chun Guo (Daisy)

> > >>>

> > >>>

> > >>> Akihiro Motoki <amotoki@gmail.com> wrote on 10/08/2015 09:31:36 PM:

> > >>>

> > >>> > From: Akihiro Motoki <amotoki@gmail.com>

> > >>> > To: Ying Chun Guo/China/IBM@IBMCN

> > >>> > Cc: Openstack-i18n <openstack-i18n@lists.openstack.org>

> > >>> > Date: 10/08/2015 09:32 PM

> > >>> > Subject: Re: [Openstack-i18n] Approved & rejected translations after

> > >>> > versions merging

> > >>> >

> > >>> > On a second thought, I start to think this can happen in every

> > >>> > OpenStack release.

> > >>> >

> > >>> > What can possibly happen?

> > >>> >

> > >>> > Most reviews are done after RC1 is released. It means reviews and

> > >>> > corrections are done in stable-xxxx branch.

> > >>> > It is not a rare case that strings are also translated in the master

> > >>> > branch.

> > >>> > In this case, corrections in stable-xxxx branch will not be

> > >>> > feedback-ed to the master branch

> > >>> > and this means that translators/reviewers need to do the same thing

> > >>> > again and can lead to

> > >>> > inconsistent translations.

> > >>> >

> > >>> > What can we do?

> > >>> >

> > >>> > I don't think we have a general solution to this.

> > >>> > Zanata's current behavior may work well in most cases, but does not

> > >>> > work for us.

> > >>> >

> > >>> > One possible solution is to allow language coordinators (or

> > >>> > reviewers) to upload PO files.

> > >>> > Language coordinators (or reviewers) can use diff tools locally and

> > >>> > merge translations

> > >>> > more efficiently. The demand may be different among languages.

> > >>> > If they can upload PO files, we can cope with this lang by lang.

> > >>> >

> > >>> > Thought?

> > >>> >

> > >>> > Akihiro

> > >>> >

> > >>> > 2015-10-08 19:37 GMT+09:00 Akihiro Motoki <amotoki@gmail.com>:

> > >>> > Daisy,

> > >>> >

> > >>> > Is there any way to apply modifications made in stable-liberty branch

> > >>> > to the master branch?

> > >>> >

> > >>> > We made a lot of modifications/fixes to strings from IBM translation

> > >>> > contribution

> > >>> > in stable-liberty branch. The master branch already has translations

> > >>> > because

> > >>> > it is contributed by IBM, so merging from liberty to master does

> > >>> not help us.

> > >>> >

> > >>> > It seems translators or language coordinator cannot upload PO files,

> > >>> > so I cannot have a way to replace the master translation with the

> > >>> > liberty version

> > >>> > in a batch way.

> > >>> >

> > >>> > We don't want to check >100 rejected strings and copy >100 modified

> > >>> > strings

> > >>> > from liberty manually.

> > >>> >

> > >>> > Is there any suggestion?

> > >>> >

> > >>> > Akihiro

> > >>> >

> > >>> > 2015-10-03 2:12 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

> > >>> > Hi,

> > >>> >

> > >>> > A translation could be approved or rejected. This action is called

> > >>> > translation review.

> > >>> > A version merging is to copy all matching translated/approved

> > >>> > translations from the source version to the target version.

> > >>> > If there is an existing translated/approved translation, the newer

> > >>> > translation will be used.

> > >>> > After liberty translations are closed, we will merge translations

> > >>> > from stable-liberty version to master version,

> > >>> > and then open both stable-liberty version and master version to

> > >>> > accept translations.

> > >>> > I investigated whether translation review would be copied after

> > >>> > version merging.

> > >>> >

> > >>> > Here are the results:

> > >>> > The review result - "approve" will be copied to the target version,

> > >>> > while the review result - "reject" will not.

> > >>> > Only "rejecting" existing translations will not have the same

> > >>> > translations rejected in master version.

> > >>> > But "approving" existing translations will have the same

> > >>> > translations approved in the master version.

> > >>> > That means, if there are "rejected" translations in stable-liberty,

> > >>> > it's better to input the correct translations.

> > >>> >

> > >>> > The investigation result is OK with me.

> > >>> > If you have different opinions, please propose here.

> > >>> > If you want to understand more about version merging, please let me

> > >>> > know.

> > >>> >

> > >>> > Best regards

> > >>> > Ying Chun Guo (Daisy)

> > >>>

> > >>> > _______________________________________________

> > >>> > 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