Open Stack

https://zanata.atlassian.net/browse/ZNTA-727
Let's wait for their response.

Best regards
Ying Chun Guo (Daisy)


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

> From: Ying Chun Guo/China/IBM at IBMCN
> To: Akihiro Motoki <amotoki at gmail.com>
> Cc: Openstack-i18n <openstack-i18n at 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 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
> > _______________________________________________
> 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/deab4be4/attachment-0001.html>