Approved & rejected translations after versions merging
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)
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
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
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
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. 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
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
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
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 be confusing, 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. (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
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.
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
contribution in stable-liberty branch. The master branch already has
project=ceilometer&iteration=master&localeId=ja&locale=ja#view:doc;doc:ceilometer translation 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
https://zanata.atlassian.net/browse/ZNTA-727 Let's wait for their response. Best regards Ying Chun Guo (Daisy) 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.
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
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
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
contribution in stable-liberty branch. The master branch already has
project=ceilometer&iteration=master&localeId=ja&locale=ja#view:doc;doc:ceilometer old thing translation 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
participants (2)
-
Akihiro Motoki
-
Ying Chun Guo