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

> 