RFC: Merging Satellite translations back into upstream

Bryan_Kearney · May 1, 2015, 8:20pm

As part of the productization of Satellite we have had a team of
professional translators localize the software into 10 languages. They
have worked across foreman core, several plugins, hammer, and several
hammer plugins to provide a consistent language experience. Because of
branding, not all the strings are applicable, but a large percentage
are. In order to make the experience consistent, some upstream
translations were changed.

Now that 1.8 is out, I would like to merge the applicable translations
into the upstream code base. My proposed process is below. However,
before I begin, I would like to know if there are any objections to
changing the upstream translations. I can not think of an easy way to
notify the community member who did the translation. To aid the
discussion, I have put a sample merge at [1]. The commit provides
details of how the merge was done.

My proposed process would be:

Announce a day when this would be done, and ask for no translations
on that day.
Work with a project maintainer to pull the latest strings from
transifex into the develop branch.
Merge in the strings, and submit a pull request.
Have the maintainer ack the pull request, and push the latest
translations up to transifex.

We have translated 8 projects, so the entire process should only take an
hour or two. Ideally, we could do this every time downstream releases.
This would ensure that the translations are improved over time.

Please let me know your thoughts.

– bk

[1]

dLobatog · May 4, 2015, 7:13am

> As part of the productization of Satellite we have had a team of
> professional translators localize the software into 10 languages. They have
> worked across foreman core, several plugins, hammer, and several hammer
> plugins to provide a consistent language experience. Because of branding,
> not all the strings are applicable, but a large percentage are. In order to
> make the experience consistent, some upstream translations were changed.
>
> Now that 1.8 is out, I would like to merge the applicable translations into
> the upstream code base. My proposed process is below. However, before I
> begin, I would like to know if there are any objections to changing the
> upstream translations. I can not think of an easy way to notify the
> community member who did the translation. To aid the discussion, I have put
> a sample merge at [1]. The commit provides details of how the merge was
> done.
>
> My proposed process would be:
>
> 0) Announce a day when this would be done, and ask for no translations on
> that day.
Ideally announce more than day in advance, and maybe tell what strings
will be translated, we still would want translations for strings that
won't be pulled.
> 1) Work with a project maintainer to pull the latest strings from transifex
> into the develop branch.
> 2) Merge in the strings, and submit a pull request.
> 3) Have the maintainer ack the pull request, and push the latest
> translations up to transifex.
>
> We have translated 8 projects, so the entire process should only take an
> hour or two. Ideally, we could do this every time downstream releases. This
> would ensure that the translations are improved over time.
>
> Please let me know your thoughts.
Good idea! Doing this once per downstream release seems reasonable.

···

On 05/01, Bryan Kearney wrote: > > -- bk > > > > [1] https://github.com/bkearney/foreman/commit/b89ade4f64773151be69fed15fbf68ebe08e13b1 > > -- > You received this message because you are subscribed to the Google Groups "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout.

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

Bryan_Kearney · May 4, 2015, 12:00pm

There are alot of strings :). The logic is such that upstream is kept if
there is no downstream edits.

– bk

···

On 05/04/2015 03:13 AM, Daniel Lobato Garcia wrote: > On 05/01, Bryan Kearney wrote: >> As part of the productization of Satellite we have had a team of >> professional translators localize the software into 10 languages. They have >> worked across foreman core, several plugins, hammer, and several hammer >> plugins to provide a consistent language experience. Because of branding, >> not all the strings are applicable, but a large percentage are. In order to >> make the experience consistent, some upstream translations were changed. >> >> Now that 1.8 is out, I would like to merge the applicable translations into >> the upstream code base. My proposed process is below. However, before I >> begin, I would like to know if there are any objections to changing the >> upstream translations. I can not think of an easy way to notify the >> community member who did the translation. To aid the discussion, I have put >> a sample merge at [1]. The commit provides details of how the merge was >> done. >> >> My proposed process would be: >> >> 0) Announce a day when this would be done, and ask for no translations on >> that day. > Ideally announce more than day in advance, and maybe tell what strings > will be translated, we still would want translations for strings that > won't be pulled.

Claer · May 4, 2015, 5:02pm

All strings with empty translation on community side can be imported without
review. I'm concerned about conflicting edits since they imported the strings.

Ex:

I created a translation A0
RH Translators updated the translation to A1 because it was wrong
I saw a mistake in my translation and updated it to A1'

In the PR on [1] I saw at least 1 occurence of these conflics.
(line 7281 of french translation)

It would be good if updating translations could be done like a patch to
existing translation that can be commented by opensource translators within the
pull request instead of the whole file being pushed again.
To call for arms for patch review, Transifex anounces can be used.

Claer

···

On Mon, May 04 2015 at 00:08, Bryan Kearney wrote: > On 05/04/2015 03:13 AM, Daniel Lobato Garcia wrote: > >On 05/01, Bryan Kearney wrote: > >>As part of the productization of Satellite we have had a team of > >>professional translators localize the software into 10 languages. They have > >>worked across foreman core, several plugins, hammer, and several hammer > >>plugins to provide a consistent language experience. Because of branding, > >>not all the strings are applicable, but a large percentage are. In order to > >>make the experience consistent, some upstream translations were changed. > >> > >>Now that 1.8 is out, I would like to merge the applicable translations into > >>the upstream code base. My proposed process is below. However, before I > >>begin, I would like to know if there are any objections to changing the > >>upstream translations. I can not think of an easy way to notify the > >>community member who did the translation. To aid the discussion, I have put > >>a sample merge at [1]. The commit provides details of how the merge was > >>done. > >> > >>My proposed process would be: > >> > >>0) Announce a day when this would be done, and ask for no translations on > >>that day. > >Ideally announce more than day in advance, and maybe tell what strings > >will be translated, we still would want translations for strings that > >won't be pulled. > > There are alot of strings :). The logic is such that upstream is > kept if there is no downstream edits.

Bryan_Kearney · May 4, 2015, 5:10pm

If We pull from transifex right before the pull request, that way the
latest strings are used, does that mitigate the issue?

Also… is this the diff which is the issue

-"Si vous choisissez une authentification LDAP, alors vous devez saisir
les info"
-"rmations du fournisseur d'authentification sur la page %s"
+"Si vous choisissez une authentification LDAP, alors vous devez saisir
les "
+"informations du fournisseur d'authentification sur la page %s"

– bk

···

On 05/04/2015 01:02 PM, Claer wrote: > On Mon, May 04 2015 at 00:08, Bryan Kearney wrote: >> On 05/04/2015 03:13 AM, Daniel Lobato Garcia wrote: >>> On 05/01, Bryan Kearney wrote: >>>> As part of the productization of Satellite we have had a team of >>>> professional translators localize the software into 10 languages. They have >>>> worked across foreman core, several plugins, hammer, and several hammer >>>> plugins to provide a consistent language experience. Because of branding, >>>> not all the strings are applicable, but a large percentage are. In order to >>>> make the experience consistent, some upstream translations were changed. >>>> >>>> Now that 1.8 is out, I would like to merge the applicable translations into >>>> the upstream code base. My proposed process is below. However, before I >>>> begin, I would like to know if there are any objections to changing the >>>> upstream translations. I can not think of an easy way to notify the >>>> community member who did the translation. To aid the discussion, I have put >>>> a sample merge at [1]. The commit provides details of how the merge was >>>> done. >>>> >>>> My proposed process would be: >>>> >>>> 0) Announce a day when this would be done, and ask for no translations on >>>> that day. >>> Ideally announce more than day in advance, and maybe tell what strings >>> will be translated, we still would want translations for strings that >>> won't be pulled. >> >> There are alot of strings :). The logic is such that upstream is >> kept if there is no downstream edits. > > All strings with empty translation on community side can be imported without > review. I'm concerned about conflicting edits since they imported the strings. > > Ex: > - I created a translation A0 > - RH Translators updated the translation to A1 because it was wrong > - I saw a mistake in my translation and updated it to A1' > > In the PR on [1] I saw at least 1 occurence of these conflics. > (line 7281 of french translation) > > It would be good if updating translations could be done like a patch to > existing translation that can be commented by opensource translators within the > pull request instead of the whole file being pushed again. > To call for arms for patch review, Transifex anounces can be used. >

Claer · May 4, 2015, 5:17pm

Oh I should have written it exactly

This is the following string : "Eager zero"
First bad translated string : "Zéro gourmand (eager)"
New fixed translation : "Provisionné à zero"

In your pr I can see the bad translation in the .po file.

If you pull from Transifex right before the merge, you will just
overwrite the translation the other way around. I may be happy but RH
translators will have the same mistakes to correct every foreman release.
The only possible decision is doing manual merge for those conflicting strings.

Claer

···

On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: > On 05/04/2015 01:02 PM, Claer wrote: > >On Mon, May 04 2015 at 00:08, Bryan Kearney wrote: > >>On 05/04/2015 03:13 AM, Daniel Lobato Garcia wrote: > >>>On 05/01, Bryan Kearney wrote: > >>>>As part of the productization of Satellite we have had a team of > >>>>professional translators localize the software into 10 languages. They have > >>>>worked across foreman core, several plugins, hammer, and several hammer > >>>>plugins to provide a consistent language experience. Because of branding, > >>>>not all the strings are applicable, but a large percentage are. In order to > >>>>make the experience consistent, some upstream translations were changed. > >>>> > >>>>Now that 1.8 is out, I would like to merge the applicable translations into > >>>>the upstream code base. My proposed process is below. However, before I > >>>>begin, I would like to know if there are any objections to changing the > >>>>upstream translations. I can not think of an easy way to notify the > >>>>community member who did the translation. To aid the discussion, I have put > >>>>a sample merge at [1]. The commit provides details of how the merge was > >>>>done. > >>>> > >>>>My proposed process would be: > >>>> > >>>>0) Announce a day when this would be done, and ask for no translations on > >>>>that day. > >>>Ideally announce more than day in advance, and maybe tell what strings > >>>will be translated, we still would want translations for strings that > >>>won't be pulled. > >> > >>There are alot of strings :). The logic is such that upstream is > >>kept if there is no downstream edits. > > > >All strings with empty translation on community side can be imported without > >review. I'm concerned about conflicting edits since they imported the strings. > > > >Ex: > > - I created a translation A0 > > - RH Translators updated the translation to A1 because it was wrong > > - I saw a mistake in my translation and updated it to A1' > > > >In the PR on [1] I saw at least 1 occurence of these conflics. > >(line 7281 of french translation) > > > >It would be good if updating translations could be done like a patch to > >existing translation that can be commented by opensource translators within the > >pull request instead of the whole file being pushed again. > >To call for arms for patch review, Transifex anounces can be used. > > > > If We pull from transifex right before the pull request, that way > the latest strings are used, does that mitigate the issue? > > Also.. is this the diff which is the issue > > -"Si vous choisissez une authentification LDAP, alors vous devez > saisir les info" > -"rmations du fournisseur d'authentification sur la page %s" > +"Si vous choisissez une authentification LDAP, alors vous devez > saisir les " > +"informations du fournisseur d'authentification sur la page %s"

Bryan_Kearney · May 4, 2015, 5:31pm

In this case, could the language maintainer just re-apply the changes in
transifex after reviewing the merge? That would mean the next cycle is:

a) Upstream merges in strings from transifex before the release.
b) Upstream releases 1.9
c) Downstream pulls in translations from 1.9, verfies and reviews them.
d) We repeat this process

Over time… it is improved. The alternative i can think of is this;

Announce a week out a day when this would be done, and ask for no
translations on that day.
Work with a project maintainer to pull the latest strings from
transifex into the develop branch.
Merge in the strings from downstream into develop, and submit a pull
request.
Allow one day to review the pull request
Have the maintainer ack the pull request, and push the latest
translations up to transifex.

I honestly dont know if it is better to review the patch in 3 for one
day, or to just fix it after the fact in transifex.
– bk

···

On 05/04/2015 01:17 PM, Claer wrote: > On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: >> On 05/04/2015 01:02 PM, Claer wrote: >>> On Mon, May 04 2015 at 00:08, Bryan Kearney wrote: >>>> On 05/04/2015 03:13 AM, Daniel Lobato Garcia wrote: >>>>> On 05/01, Bryan Kearney wrote: >>>>>> As part of the productization of Satellite we have had a team of >>>>>> professional translators localize the software into 10 languages. They have >>>>>> worked across foreman core, several plugins, hammer, and several hammer >>>>>> plugins to provide a consistent language experience. Because of branding, >>>>>> not all the strings are applicable, but a large percentage are. In order to >>>>>> make the experience consistent, some upstream translations were changed. >>>>>> >>>>>> Now that 1.8 is out, I would like to merge the applicable translations into >>>>>> the upstream code base. My proposed process is below. However, before I >>>>>> begin, I would like to know if there are any objections to changing the >>>>>> upstream translations. I can not think of an easy way to notify the >>>>>> community member who did the translation. To aid the discussion, I have put >>>>>> a sample merge at [1]. The commit provides details of how the merge was >>>>>> done. >>>>>> >>>>>> My proposed process would be: >>>>>> >>>>>> 0) Announce a day when this would be done, and ask for no translations on >>>>>> that day. >>>>> Ideally announce more than day in advance, and maybe tell what strings >>>>> will be translated, we still would want translations for strings that >>>>> won't be pulled. >>>> >>>> There are alot of strings :). The logic is such that upstream is >>>> kept if there is no downstream edits. >>> >>> All strings with empty translation on community side can be imported without >>> review. I'm concerned about conflicting edits since they imported the strings. >>> >>> Ex: >>> - I created a translation A0 >>> - RH Translators updated the translation to A1 because it was wrong >>> - I saw a mistake in my translation and updated it to A1' >>> >>> In the PR on [1] I saw at least 1 occurence of these conflics. >>> (line 7281 of french translation) >>> >>> It would be good if updating translations could be done like a patch to >>> existing translation that can be commented by opensource translators within the >>> pull request instead of the whole file being pushed again. >>> To call for arms for patch review, Transifex anounces can be used. >>> >> >> If We pull from transifex right before the pull request, that way >> the latest strings are used, does that mitigate the issue? >> >> Also.. is this the diff which is the issue >> >> -"Si vous choisissez une authentification LDAP, alors vous devez >> saisir les info" >> -"rmations du fournisseur d'authentification sur la page %s" >> +"Si vous choisissez une authentification LDAP, alors vous devez >> saisir les " >> +"informations du fournisseur d'authentification sur la page %s" > > Oh I should have written it exactly :) > > This is the following string : "Eager zero" > First bad translated string : "Zéro gourmand (eager)" > New fixed translation : "Provisionné à zero" > > In your pr I can see the bad translation in the .po file. > > If you pull from Transifex right before the merge, you will just > overwrite the translation the other way around. I may be happy but RH > translators will have the same mistakes to correct every foreman release. > The only possible decision is doing manual merge for those conflicting strings. > > > Claer >

Dominic_Cleal · May 5, 2015, 2:27pm

-dev is a much better place for this discussion, as it's about our dev
and release process.

>>>> All strings with empty translation on community side can be imported without
>>>> review. I'm concerned about conflicting edits since they imported the strings.
>>>>
>>>> Ex:
>>>> - I created a translation A0
>>>> - RH Translators updated the translation to A1 because it was wrong
>>>> - I saw a mistake in my translation and updated it to A1'
>>>>
>>>> In the PR on [1] I saw at least 1 occurence of these conflics.
>>>> (line 7281 of french translation)
>>>>
>>>> It would be good if updating translations could be done like a patch to
>>>> existing translation that can be commented by opensource translators within the
>>>> pull request instead of the whole file being pushed again.
>>>> To call for arms for patch review, Transifex anounces can be used.
>>>>
>>>
>>> If We pull from transifex right before the pull request, that way
>>> the latest strings are used, does that mitigate the issue?
>>>
>>> Also… is this the diff which is the issue
>>>
>>> -"Si vous choisissez une authentification LDAP, alors vous devez
>>> saisir les info"
>>> -"rmations du fournisseur d'authentification sur la page %s"
>>> +"Si vous choisissez une authentification LDAP, alors vous devez
>>> saisir les "
>>> +"informations du fournisseur d'authentification sur la page %s"
>>
>> Oh I should have written it exactly
>>
>> This is the following string : "Eager zero"
>> First bad translated string : "Zéro gourmand (eager)"
>> New fixed translation : "Provisionné à zero"
>>
>> In your pr I can see the bad translation in the .po file.
>>
>> If you pull from Transifex right before the merge, you will just
>> overwrite the translation the other way around. I may be happy but RH
>> translators will have the same mistakes to correct every foreman release.
>> The only possible decision is doing manual merge for those conflicting strings.
>
> In this case, could the language maintainer just re-apply the changes in
> transifex after reviewing the merge? That would mean the next cycle is:

If somebody has already changed it in Transifex, then that should take
precedence. The onus is on you when proposing the change to identify
whether it's needed or not, not the Transifex team who have already
fixed it to change it again after being reverted.

The base translations you're using from Transifex are probably a few
months old, prior to a major 1.8 release, so it's really too late at
this point to sync back in wholesale.

Any string that has changed in Transifex since your base copy was taken
should be preferred, and if you still think it needs changing, then
provide review feedback through Transifex.

In future, fixes should be submitted straight to Transifex.

> a) Upstream merges in strings from transifex before the release.
> b) Upstream releases 1.9
> c) Downstream pulls in translations from 1.9, verfies and reviews them.
> d) We repeat this process

As long as the review is done in Transifex, it already has the features
for this. Anybody can do this today.

It should happen before a 1.9 release, not after. We release at least
two RCs, which are a perfect time to test and fix these things.

···

On 04/05/15 18:31, Bryan Kearney wrote: > On 05/04/2015 01:17 PM, Claer wrote: >> On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: >>> On 05/04/2015 01:02 PM, Claer wrote:

–
Dominic Cleal
Red Hat Engineering

Bryan_Kearney · May 5, 2015, 3:15pm

I will move this to foreman dev per Dominic's comments. Please see that
list for followups.

– bk

···

On 05/05/2015 10:27 AM, Dominic Cleal wrote: > -dev is a much better place for this discussion, as it's about our dev > and release process. > > On 04/05/15 18:31, Bryan Kearney wrote: >> On 05/04/2015 01:17 PM, Claer wrote: >>> On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: >>>> On 05/04/2015 01:02 PM, Claer wrote: >>>>> All strings with empty translation on community side can be imported without >>>>> review. I'm concerned about conflicting edits since they imported the strings. >>>>> >>>>> Ex: >>>>> - I created a translation A0 >>>>> - RH Translators updated the translation to A1 because it was wrong >>>>> - I saw a mistake in my translation and updated it to A1' >>>>> >>>>> In the PR on [1] I saw at least 1 occurence of these conflics. >>>>> (line 7281 of french translation) >>>>> >>>>> It would be good if updating translations could be done like a patch to >>>>> existing translation that can be commented by opensource translators within the >>>>> pull request instead of the whole file being pushed again. >>>>> To call for arms for patch review, Transifex anounces can be used. >>>>> >>>> >>>> If We pull from transifex right before the pull request, that way >>>> the latest strings are used, does that mitigate the issue? >>>> >>>> Also.. is this the diff which is the issue >>>> >>>> -"Si vous choisissez une authentification LDAP, alors vous devez >>>> saisir les info" >>>> -"rmations du fournisseur d'authentification sur la page %s" >>>> +"Si vous choisissez une authentification LDAP, alors vous devez >>>> saisir les " >>>> +"informations du fournisseur d'authentification sur la page %s" >>> >>> Oh I should have written it exactly :) >>> >>> This is the following string : "Eager zero" >>> First bad translated string : "Zéro gourmand (eager)" >>> New fixed translation : "Provisionné à zero" >>> >>> In your pr I can see the bad translation in the .po file. >>> >>> If you pull from Transifex right before the merge, you will just >>> overwrite the translation the other way around. I may be happy but RH >>> translators will have the same mistakes to correct every foreman release. >>> The only possible decision is doing manual merge for those conflicting strings. >> >> In this case, could the language maintainer just re-apply the changes in >> transifex after reviewing the merge? That would mean the next cycle is: > > If somebody has already changed it in Transifex, then that should take > precedence. The onus is on you when proposing the change to identify > whether it's needed or not, not the Transifex team who have already > fixed it to change it again after being reverted. > > The base translations you're using from Transifex are probably a few > months old, prior to a major 1.8 release, so it's really too late at > this point to sync back in wholesale. > > Any string that has changed in Transifex since your base copy was taken > should be preferred, and if you still think it needs changing, then > provide review feedback through Transifex. > > In future, fixes should be submitted straight to Transifex. > >> a) Upstream merges in strings from transifex before the release. >> b) Upstream releases 1.9 >> c) Downstream pulls in translations from 1.9, verfies and reviews them. >> d) We repeat this process > > As long as the review is done in Transifex, it already has the features > for this. Anybody can do this today. > > It should happen before a 1.9 release, not after. We release at least > two RCs, which are a perfect time to test and fix these things. >

Bryan_Kearney · May 5, 2015, 3:25pm

> -dev is a much better place for this discussion, as it's about our dev
> and release process.

Done!

>
>>>>> All strings with empty translation on community side can be imported without
>>>>> review. I'm concerned about conflicting edits since they imported the strings.
>>>>>
>>>>> Ex:
>>>>> - I created a translation A0
>>>>> - RH Translators updated the translation to A1 because it was wrong
>>>>> - I saw a mistake in my translation and updated it to A1'
>>>>>
>>>>> In the PR on [1] I saw at least 1 occurence of these conflics.
>>>>> (line 7281 of french translation)
>>>>>
>>>>> It would be good if updating translations could be done like a patch to
>>>>> existing translation that can be commented by opensource translators within the
>>>>> pull request instead of the whole file being pushed again.
>>>>> To call for arms for patch review, Transifex anounces can be used.
>>>>>
>>>>
>>>> If We pull from transifex right before the pull request, that way
>>>> the latest strings are used, does that mitigate the issue?
>>>>
>>>> Also… is this the diff which is the issue
>>>>
>>>> -"Si vous choisissez une authentification LDAP, alors vous devez
>>>> saisir les info"
>>>> -"rmations du fournisseur d'authentification sur la page %s"
>>>> +"Si vous choisissez une authentification LDAP, alors vous devez
>>>> saisir les "
>>>> +"informations du fournisseur d'authentification sur la page %s"
>>>
>>> Oh I should have written it exactly
>>>
>>> This is the following string : "Eager zero"
>>> First bad translated string : "Zéro gourmand (eager)"
>>> New fixed translation : "Provisionné à zero"
>>>
>>> In your pr I can see the bad translation in the .po file.
>>>
>>> If you pull from Transifex right before the merge, you will just
>>> overwrite the translation the other way around. I may be happy but RH
>>> translators will have the same mistakes to correct every foreman release.
>>> The only possible decision is doing manual merge for those conflicting strings.
>>
>> In this case, could the language maintainer just re-apply the changes in
>> transifex after reviewing the merge? That would mean the next cycle is:
>
> If somebody has already changed it in Transifex, then that should take
> precedence. The onus is on you when proposing the change to identify
> whether it's needed or not, not the Transifex team who have already
> fixed it to change it again after being reverted.

The feedback which I have gotten is that the translations to need to be
improved. Is there a way for me to understand from the transifex tool
how many translations have actually changed? The commitlog does not
preserve the order so that is not reallu useful.

>
> The base translations you're using from Transifex are probably a few
> months old, prior to a major 1.8 release, so it's really too late at
> this point to sync back in wholesale.

I disagree. I think the only issue we have is the one which Clear
pointed out… which is an issue which was fixed the upstream translator
and not fixed by the downstream translator.

>
> Any string that has changed in Transifex since your base copy was taken
> should be preferred, and if you still think it needs changing, then
> provide review feedback through Transifex.

This is an issue, in that I have a professional review and they will not
use Transifex. I believe it would be short sited to ignore these
improvements because they will not use the preferred tool. Clear was
able to identify the issues very quickly, so can we agree on a modified
model to make sure we close that gap:

Announce a week out a day when this would be done, and ask for no
translations on that day.
Work with a project maintainer to pull the latest strings from
transifex into the develop branch.
Merge in the strings from downstream into develop, and submit a pull
request.
Allow one day to review the pull request
Have the maintainer ack the pull request, and push the latest
translations up to transifex.

– bk

···

On 05/05/2015 10:27 AM, Dominic Cleal wrote: > On 04/05/15 18:31, Bryan Kearney wrote: >> On 05/04/2015 01:17 PM, Claer wrote: >>> On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: >>>> On 05/04/2015 01:02 PM, Claer wrote:

Claer · May 5, 2015, 4:02pm

To continue the discution here, I prefer your 1st process as long as we
can see witch non empty strings are modified when merging. May be the
solution is to write a small script for parsing .po files in order to
facilitate this. 1 day is definitively not manageable for us who are not
working full time for The Foreman

Claer

···

On Tue, May 05 2015 at 25:11, Bryan Kearney wrote: > On 05/05/2015 10:27 AM, Dominic Cleal wrote: > >-dev is a much better place for this discussion, as it's about our dev > >and release process. > > Done! > > >On 04/05/15 18:31, Bryan Kearney wrote: > >>On 05/04/2015 01:17 PM, Claer wrote: > >>>On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: > >>>>On 05/04/2015 01:02 PM, Claer wrote: > >>>>>All strings with empty translation on community side can be imported without > >>>>>review. I'm concerned about conflicting edits since they imported the strings. > >>>>> > >>>>>Ex: > >>>>> - I created a translation A0 > >>>>> - RH Translators updated the translation to A1 because it was wrong > >>>>> - I saw a mistake in my translation and updated it to A1' > >>>>> > >>>>>In the PR on [1] I saw at least 1 occurence of these conflics. > >>>>>(line 7281 of french translation) > >>>>> > >>>>>It would be good if updating translations could be done like a patch to > >>>>>existing translation that can be commented by opensource translators within the > >>>>>pull request instead of the whole file being pushed again. > >>>>>To call for arms for patch review, Transifex anounces can be used. > >>>>> > >>>> > >>>>If We pull from transifex right before the pull request, that way > >>>>the latest strings are used, does that mitigate the issue? > >>>> > >>>>Also.. is this the diff which is the issue > >>>> > >>>>-"Si vous choisissez une authentification LDAP, alors vous devez > >>>>saisir les info" > >>>>-"rmations du fournisseur d'authentification sur la page %s" > >>>>+"Si vous choisissez une authentification LDAP, alors vous devez > >>>>saisir les " > >>>>+"informations du fournisseur d'authentification sur la page %s" > >>> > >>>Oh I should have written it exactly :) > >>> > >>>This is the following string : "Eager zero" > >>>First bad translated string : "Zéro gourmand (eager)" > >>>New fixed translation : "Provisionné à zero" > >>> > >>>In your pr I can see the bad translation in the .po file. > >>> > >>>If you pull from Transifex right before the merge, you will just > >>>overwrite the translation the other way around. I may be happy but RH > >>>translators will have the same mistakes to correct every foreman release. > >>>The only possible decision is doing manual merge for those conflicting strings. > >> > >>In this case, could the language maintainer just re-apply the changes in > >>transifex after reviewing the merge? That would mean the next cycle is: > > > >If somebody has already changed it in Transifex, then that should take > >precedence. The onus is on you when proposing the change to identify > >whether it's needed or not, not the Transifex team who have already > >fixed it to change it again after being reverted. > > The feedback which I have gotten is that the translations to need to > be improved. Is there a way for me to understand from the transifex > tool how many translations have actually changed? The commitlog does > not preserve the order so that is not reallu useful. > > > > >The base translations you're using from Transifex are probably a few > >months old, prior to a major 1.8 release, so it's really too late at > >this point to sync back in wholesale. > > I disagree. I think the only issue we have is the one which Clear > pointed out.. which is an issue which was fixed the upstream > translator and not fixed by the downstream translator. > > > > >Any string that has changed in Transifex since your base copy was taken > >should be preferred, and if you still think it needs changing, then > >provide review feedback through Transifex. > > This is an issue, in that I have a professional review and they will > not use Transifex. I believe it would be short sited to ignore these > improvements because they will not use the preferred tool. Clear was > able to identify the issues very quickly, so can we agree on a > modified model to make sure we close that gap: > > 0) Announce a week out a day when this would be done, and ask for no > translations on that day. > 1) Work with a project maintainer to pull the latest strings from > transifex into the develop branch. > 2) Merge in the strings from downstream into develop, and submit a > pull request. > 3) Allow one day to review the pull request > 4) Have the maintainer ack the pull request, and push the latest > translations up to transifex.

Dominic_Cleal · May 6, 2015, 9:10am

>
>
>> -dev is a much better place for this discussion, as it's about our dev
>> and release process.
>
> Done!
>
>>
>>>>>> All strings with empty translation on community side can be imported without
>>>>>> review. I'm concerned about conflicting edits since they imported the strings.
>>>>>>
>>>>>> Ex:
>>>>>> - I created a translation A0
>>>>>> - RH Translators updated the translation to A1 because it was wrong
>>>>>> - I saw a mistake in my translation and updated it to A1'
>>>>>>
>>>>>> In the PR on [1] I saw at least 1 occurence of these conflics.
>>>>>> (line 7281 of french translation)
>>>>>>
>>>>>> It would be good if updating translations could be done like a patch to
>>>>>> existing translation that can be commented by opensource translators within the
>>>>>> pull request instead of the whole file being pushed again.
>>>>>> To call for arms for patch review, Transifex anounces can be used.
>>>>>>
>>>>>
>>>>> If We pull from transifex right before the pull request, that way
>>>>> the latest strings are used, does that mitigate the issue?
>>>>>
>>>>> Also… is this the diff which is the issue
>>>>>
>>>>> -"Si vous choisissez une authentification LDAP, alors vous devez
>>>>> saisir les info"
>>>>> -"rmations du fournisseur d'authentification sur la page %s"
>>>>> +"Si vous choisissez une authentification LDAP, alors vous devez
>>>>> saisir les "
>>>>> +"informations du fournisseur d'authentification sur la page %s"
>>>>
>>>> Oh I should have written it exactly
>>>>
>>>> This is the following string : "Eager zero"
>>>> First bad translated string : "Zéro gourmand (eager)"
>>>> New fixed translation : "Provisionné à zero"
>>>>
>>>> In your pr I can see the bad translation in the .po file.
>>>>
>>>> If you pull from Transifex right before the merge, you will just
>>>> overwrite the translation the other way around. I may be happy but RH
>>>> translators will have the same mistakes to correct every foreman release.
>>>> The only possible decision is doing manual merge for those conflicting strings.
>>>
>>> In this case, could the language maintainer just re-apply the changes in
>>> transifex after reviewing the merge? That would mean the next cycle is:
>>
>> If somebody has already changed it in Transifex, then that should take
>> precedence. The onus is on you when proposing the change to identify
>> whether it's needed or not, not the Transifex team who have already
>> fixed it to change it again after being reverted.
>
> The feedback which I have gotten is that the translations to need to be
> improved. Is there a way for me to understand from the transifex tool
> how many translations have actually changed? The commitlog does not
> preserve the order so that is not reallu useful.

In the UI, you can filter by date translated, perhaps that'd help?

>> The base translations you're using from Transifex are probably a few
>> months old, prior to a major 1.8 release, so it's really too late at
>> this point to sync back in wholesale.
>
> I disagree. I think the only issue we have is the one which Clear
> pointed out… which is an issue which was fixed the upstream translator
> and not fixed by the downstream translator.

Sure, and that's potentially quite a large issue when you're
re-proposing translations that are based on 1.7-stable(?). Some
translations have changed a lot since then.

>> Any string that has changed in Transifex since your base copy was taken
>> should be preferred, and if you still think it needs changing, then
>> provide review feedback through Transifex.
>
> This is an issue, in that I have a professional review and they will not
> use Transifex. I believe it would be short sited to ignore these
> improvements because they will not use the preferred tool.

Perhaps, but generally we require co-operation with our existing
processes for all other contributions.

Clear was
> able to identify the issues very quickly, so can we agree on a modified
> model to make sure we close that gap:
>
> 0) Announce a week out a day when this would be done, and ask for no
> translations on that day.
> 1) Work with a project maintainer to pull the latest strings from
> transifex into the develop branch.

Stable branch, not develop.

> 2) Merge in the strings from downstream into develop, and submit a pull
> request.
> 3) Allow one day to review the pull request

As Claer said, this is probably unreasonable for many language teams,
depending on the size of the diff.

···

On 05/05/15 16:25, Bryan Kearney wrote: > On 05/05/2015 10:27 AM, Dominic Cleal wrote: >> On 04/05/15 18:31, Bryan Kearney wrote: >>> On 05/04/2015 01:17 PM, Claer wrote: >>>> On Mon, May 04 2015 at 10:13, Bryan Kearney wrote: >>>>> On 05/04/2015 01:02 PM, Claer wrote:

Have the maintainer ack the pull request, and push the latest
translations up to transifex.

–
Dominic Cleal
Red Hat Engineering

Bryan_Kearney · May 5, 2015, 5:41pm

<SNIP>
>>>
>>> If somebody has already changed it in Transifex, then that should take
>>> precedence. The onus is on you when proposing the change to identify
>>> whether it's needed or not, not the Transifex team who have already
>>> fixed it to change it again after being reverted.
>>
>> The feedback which I have gotten is that the translations to need to
>> be improved. Is there a way for me to understand from the transifex
>> tool how many translations have actually changed? The commitlog does
>> not preserve the order so that is not reallu useful.
>>
>>>
>>> The base translations you're using from Transifex are probably a few
>>> months old, prior to a major 1.8 release, so it's really too late at
>>> this point to sync back in wholesale.
>>
>> I disagree. I think the only issue we have is the one which Clear
>> pointed out… which is an issue which was fixed the upstream
>> translator and not fixed by the downstream translator.
>>
>>>
>>> Any string that has changed in Transifex since your base copy was taken
>>> should be preferred, and if you still think it needs changing, then
>>> provide review feedback through Transifex.
>>
>> This is an issue, in that I have a professional review and they will
>> not use Transifex. I believe it would be short sited to ignore these
>> improvements because they will not use the preferred tool. Clear was
>> able to identify the issues very quickly, so can we agree on a
>> modified model to make sure we close that gap:
>>
>> 0) Announce a week out a day when this would be done, and ask for no
>> translations on that day.
>> 1) Work with a project maintainer to pull the latest strings from
>> transifex into the develop branch.
>> 2) Merge in the strings from downstream into develop, and submit a
>> pull request.
>> 3) Allow one day to review the pull request
>> 4) Have the maintainer ack the pull request, and push the latest
>> translations up to transifex.
>
> To continue the discution here, I prefer your 1st process as long as we
> can see witch non empty strings are modified when merging. May be the
> solution is to write a small script for parsing .po files in order to
> facilitate this. 1 day is definitively not manageable for us who are not
> working full time for The Foreman
>
> Claer
>

Would A report like [1] help with the review? if we make step (3) 2-3
days and I generate this would that work?

[1] only has those strings which were overidden. It does not report on
blank strings. There are some false positives, but it is much less noise.

– bk

[1] http://pastebin.com/jLZf5HgQ

···

On 05/05/2015 12:02 PM, Claer wrote:

Dominic_Cleal · May 6, 2015, 9:32am

That appears useful, but I think you need to be able to differentiate
between the three main cases:

strings that are unchanged upstream (X), and that are changed in your
patch, as they need reviewing
strings that were X upstream, and are now Y and Y' as we will need to
pick one version
warn about strings that were X upstream in the old stable branch, are
now Y upstream in current stable and your upload is proposing changing
back to X, so they can be removed from the patch

···

On 05/05/15 18:41, Bryan Kearney wrote: > On 05/05/2015 12:02 PM, Claer wrote: >> To continue the discution here, I prefer your 1st process as long as we >> can see witch non empty strings are modified when merging. May be the >> solution is to write a small script for parsing .po files in order to >> facilitate this. 1 day is definitively not manageable for us who are not > > Would A report like [1] help with the review? if we make step (3) 2-3 > days and I generate this would that work? > > [1] only has those strings which were overidden. It does not report on > blank strings. There are some false positives, but it is much less noise. > > -- bk > > > [1] http://pastebin.com/jLZf5HgQ

–
Dominic Cleal
Red Hat Engineering

Claer · May 6, 2015, 9:18am

Works for me for the merge process.

The result is readable, I can see improvements from a pro TL team. The
first pass will necesary be bigger than the others, as they used some
different translations for functionnalities as I did. For ex. they
translated differently "Computer Resources", so first review will be big.

My only concern is the delay, 2-3 days is still small
At least 1 week would be nice.

Claer

···

On Tue, May 05 2015 at 41:13, Bryan Kearney wrote: > On 05/05/2015 12:02 PM, Claer wrote: > > >>> > >>>If somebody has already changed it in Transifex, then that should take > >>>precedence. The onus is on you when proposing the change to identify > >>>whether it's needed or not, not the Transifex team who have already > >>>fixed it to change it again after being reverted. > >> > >>The feedback which I have gotten is that the translations to need to > >>be improved. Is there a way for me to understand from the transifex > >>tool how many translations have actually changed? The commitlog does > >>not preserve the order so that is not reallu useful. > >> > >>> > >>>The base translations you're using from Transifex are probably a few > >>>months old, prior to a major 1.8 release, so it's really too late at > >>>this point to sync back in wholesale. > >> > >>I disagree. I think the only issue we have is the one which Clear > >>pointed out.. which is an issue which was fixed the upstream > >>translator and not fixed by the downstream translator. > >> > >>> > >>>Any string that has changed in Transifex since your base copy was taken > >>>should be preferred, and if you still think it needs changing, then > >>>provide review feedback through Transifex. > >> > >>This is an issue, in that I have a professional review and they will > >>not use Transifex. I believe it would be short sited to ignore these > >>improvements because they will not use the preferred tool. Clear was > >>able to identify the issues very quickly, so can we agree on a > >>modified model to make sure we close that gap: > >> > >>0) Announce a week out a day when this would be done, and ask for no > >>translations on that day. > >>1) Work with a project maintainer to pull the latest strings from > >>transifex into the develop branch. > >>2) Merge in the strings from downstream into develop, and submit a > >>pull request. > >>3) Allow one day to review the pull request > >>4) Have the maintainer ack the pull request, and push the latest > >>translations up to transifex. > > > >To continue the discution here, I prefer your 1st process as long as we > >can see witch non empty strings are modified when merging. May be the > >solution is to write a small script for parsing .po files in order to > >facilitate this. 1 day is definitively not manageable for us who are not > >working full time for The Foreman ;) > > > >Claer > > > > Would A report like [1] help with the review? if we make step (3) > 2-3 days and I generate this would that work? > > [1] only has those strings which were overidden. It does not report > on blank strings. There are some false positives, but it is much > less noise. > > -- bk > > [1] http://pastebin.com/jLZf5HgQ

Bryan_Kearney · May 6, 2015, 11:14pm

What about this output:

http://pastebin.com/rwParLLh

It seems that strings are not merged into develop, which seems odd to
me. So… I ran a comparison of 1.8, 1.7, and downstream. This output shows

The "current" translation from 1.8
The translation when we pulled in 1.7
The downstream suggested translation

There are a few false positives, but not many.

I could easily generate a report like this and have it grouped for
locales. That way, the reviewer could ignore net new translations.

– bk

···

On 05/06/2015 05:32 AM, Dominic Cleal wrote: > On 05/05/15 18:41, Bryan Kearney wrote: >> On 05/05/2015 12:02 PM, Claer wrote: >>> To continue the discution here, I prefer your 1st process as long as we >>> can see witch non empty strings are modified when merging. May be the >>> solution is to write a small script for parsing .po files in order to >>> facilitate this. 1 day is definitively not manageable for us who are not >> >> Would A report like [1] help with the review? if we make step (3) 2-3 >> days and I generate this would that work? >> >> [1] only has those strings which were overidden. It does not report on >> blank strings. There are some false positives, but it is much less noise. >> >> -- bk >> >> >> [1] http://pastebin.com/jLZf5HgQ > > That appears useful, but I think you need to be able to differentiate > between the three main cases: > > 1. strings that are unchanged upstream (X), and that are changed in your > patch, as they need reviewing > > 2. strings that were X upstream, and are now Y and Y' as we will need to > pick one version > > 3. warn about strings that were X upstream in the old stable branch, are > now Y upstream in current stable and your upload is proposing changing > back to X, so they can be removed from the patch >

Dominic_Cleal · May 7, 2015, 9:31am

>>>> To continue the discution here, I prefer your 1st process as long as we
>>>> can see witch non empty strings are modified when merging. May be the
>>>> solution is to write a small script for parsing .po files in order to
>>>> facilitate this. 1 day is definitively not manageable for us who are not
>>>
>>> Would A report like [1] help with the review? if we make step (3) 2-3
>>> days and I generate this would that work?
>>>
>>> [1] only has those strings which were overidden. It does not report on
>>> blank strings. There are some false positives, but it is much less noise.
>>>
>>> – bk
>>>
>>>
>>> [1] http://pastebin.com/jLZf5HgQ
>>
>> That appears useful, but I think you need to be able to differentiate
>> between the three main cases:
>>
>> 1. strings that are unchanged upstream (X), and that are changed in your
>> patch, as they need reviewing
>>
>> 2. strings that were X upstream, and are now Y and Y' as we will need to
>> pick one version
>>
>> 3. warn about strings that were X upstream in the old stable branch, are
>> now Y upstream in current stable and your upload is proposing changing
>> back to X, so they can be removed from the patch
>>
>
> What about this output:
>
> http://pastebin.com/rwParLLh
>
> It seems that strings are not merged into develop, which seems odd to
> me.

Translating develop might be a lot of effort for a moving target, and of
use to only a few people. Translating our releases seems like a better
use of a finite resource, so usually strings are maintained only on
stable branches.

> So… I ran a comparison of 1.8, 1.7, and downstream. This output shows
>
> The "current" translation from 1.8
> The translation when we pulled in 1.7
> The downstream suggested translation
>
> There are a few false positives, but not many.

Should be easy to remove entries that are entirely identical?

> I could easily generate a report like this and have it grouped for
> locales. That way, the reviewer could ignore net new translations.

Yeah, it would have to be produced per locale for each language
maintainer(s).

Also check how it handles plurals, I see '%{cpus} CPUs and %{memory} MB
memory' which doesn't look like it's been reported on correctly.

···

On 07/05/15 00:14, Bryan Kearney wrote: > On 05/06/2015 05:32 AM, Dominic Cleal wrote: >> On 05/05/15 18:41, Bryan Kearney wrote: >>> On 05/05/2015 12:02 PM, Claer wrote:

–
Dominic Cleal
Red Hat Engineering

Bryan_Kearney · May 7, 2015, 1:39pm

<SNIP>
>
> Should be easy to remove entries that are entirely identical?

I wish. I am tyring to force the encoding but there are still false
positives. The actual script i am using is at [1]

>
>> I could easily generate a report like this and have it grouped for
>> locales. That way, the reviewer could ignore net new translations.
>
> Yeah, it would have to be produced per locale for each language
> maintainer(s).
>
> Also check how it handles plurals, I see '%{cpus} CPUs and %{memory} MB
> memory' which doesn't look like it's been reported on correctly.

How do you mean?

– bk

>

[1] http://pastebin.com/v3gVGcc9

···

On 05/07/2015 05:31 AM, Dominic Cleal wrote:

Dominic_Cleal · May 7, 2015, 1:47pm

Oh, disregard that please, oddly it isn't a plural string, I assumed it
was. That's probably why the translations differ - probably a bug.

···

On 07/05/15 14:39, Bryan Kearney wrote: > On 05/07/2015 05:31 AM, Dominic Cleal wrote: >> > Also check how it handles plurals, I see '%{cpus} CPUs and %{memory} MB >> > memory' which doesn't look like it's been reported on correctly. > How do you mean?

–
Dominic Cleal
Red Hat Engineering