[Openstack-i18n] Approved & rejected translations after versions merging

Ying Chun Guo guoyingc at cn.ibm.com
Tue Oct 13 09:21:11 UTC 2015


Thank you for deep thinking.
They are all useful information to the team.
See my comments below.

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

> From: Akihiro Motoki <amotoki at gmail.com>
> To: Ying Chun Guo/China/IBM at IBMCN
> Cc: Openstack-i18n <openstack-i18n at 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 at 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 at cn.ibm.com>:
> >> Akihiro Motoki <amotoki at gmail.com> wrote on 10/08/2015 10:37:21 PM:
> >>
> >>> From: Akihiro Motoki <amotoki at gmail.com>
> >>> To: Ying Chun Guo/China/IBM at IBMCN
> >>> Cc: Openstack-i18n <openstack-i18n at 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 at 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 at gmail.com> wrote on 10/08/2015 09:31:36 PM:
> >>>
> >>> > From: Akihiro Motoki <amotoki at gmail.com>
> >>> > To: Ying Chun Guo/China/IBM at IBMCN
> >>> > Cc: Openstack-i18n <openstack-i18n at 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 at 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 at 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 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/20151013/30f8b77d/attachment-0001.html>


More information about the Openstack-i18n mailing list