Lets treat this like a canary pull request to test the process. I
decided to start with hammer-cli since it is small, uses the new gettext
correctly, and upstream translations in Transifex have not been touched
since 3 July.
The pull request [1] has two commits. The first pulls in the latest
strings from transifex. The second puts the upstream translations on top
of it.
There is a report at [2] which provides a better way (I hope) to review
the translations. We branched downstream off of 0.1.4, and upstream is
now at 0.2.0. It categorizes the changes as
New String: A translation did not exist in 0.2.0, and is being added.
Change: A translation existed in 0.2.0, unchanged or non existant in
0.1.4 with a new change from Downstream (D.S.)
Change to Modified String: A translation existed in 0.2.0, which was
modified since 0.1.4, with a new change from Downstream
My goal is to do the following:
Get this merge request approved
Once approved, create a edit.po file for each .po file and load the
strings back into transifex. Assuming no changes, this should not impact
translations.
Comments are welcome on how I can improve the process and the reports.
Dominic suggested that I reach out to the translators. I sent PM's on
transifex to all active translators. I also posted this message at [3]. Any
other suggestions? Should I cross post to foreman-users?
···
On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
>
> Lets treat this like a canary pull request to test the process. I
> decided to start with hammer-cli since it is small, uses the new gettext
> correctly, and upstream translations in Transifex have not been touched
> since 3 July.
>
> The pull request [1] has two commits. The first pulls in the latest
> strings from transifex. The second puts the upstream translations on top
> of it.
>
> There is a report at [2] which provides a better way (I hope) to review
> the translations. We branched downstream off of 0.1.4, and upstream is
> now at 0.2.0. It categorizes the changes as
>
> * New String: A translation did not exist in 0.2.0, and is being added.
> * Change: A translation existed in 0.2.0, unchanged or non existant in
> 0.1.4 with a new change from Downstream (D.S.)
> * Change to Modified String: A translation existed in 0.2.0, which was
> modified since 0.1.4, with a new change from Downstream
>
> My goal is to do the following:
>
> 1) Get this merge request approved
> 2) Once approved, create a edit.po file for each .po file and load the
> strings back into transifex. Assuming no changes, this should not impact
> translations.
>
> Comments are welcome on how I can improve the process and the reports.
>
> Thanks!
>
> -- bk
>
>
> [1] https://github.com/theforeman/hammer-cli/pull/175
> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>
I checked the file and indeed, this is a good test. In the french translation,
there are only 2 strings that are updated. I agree on the last one but not on
the first one. The translation for the 1st one is good if the string is taken
out of context. But inside the context of "hammer --help", the string is
wrongly translated. That also highlight other strings, that are not capitalized
correctly.
The example being very good, my question is how do you want to proceed from now?
If the number of strings is big as in foreman core, I suggest to delay my
modification to the other strings after you merge your accepted changes as it
can conflict with something.
The rejection of strings is the easiest to handle, just not use the new
translation strings. I suggest to notify those in the github web site, is that
ok with other translators?
Anyway, it is a good idea to improve translations by sharing what you guys do
at Red Hat and our work.
Best regards,
Benjamin Papillon
···
On Wed, Jul 22 2015 at 58:06, bk wrote:
> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
> >
> > Lets treat this like a canary pull request to test the process. I
> > decided to start with hammer-cli since it is small, uses the new gettext
> > correctly, and upstream translations in Transifex have not been touched
> > since 3 July.
> >
> > The pull request [1] has two commits. The first pulls in the latest
> > strings from transifex. The second puts the upstream translations on top
> > of it.
> >
> > There is a report at [2] which provides a better way (I hope) to review
> > the translations. We branched downstream off of 0.1.4, and upstream is
> > now at 0.2.0. It categorizes the changes as
> >
> > * New String: A translation did not exist in 0.2.0, and is being added.
> > * Change: A translation existed in 0.2.0, unchanged or non existant in
> > 0.1.4 with a new change from Downstream (D.S.)
> > * Change to Modified String: A translation existed in 0.2.0, which was
> > modified since 0.1.4, with a new change from Downstream
> >
> > My goal is to do the following:
> >
> > 1) Get this merge request approved
> > 2) Once approved, create a edit.po file for each .po file and load the
> > strings back into transifex. Assuming no changes, this should not impact
> > translations.
> >
> > Comments are welcome on how I can improve the process and the reports.
> >
> > Thanks!
> >
> > -- bk
> >
> >
> > [1] https://github.com/theforeman/hammer-cli/pull/175
> > [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
> >
>
> Dominic suggested that I reach out to the translators. I sent PM's on
> transifex to all active translators. I also posted this message at [3]. Any
> other suggestions? Should I cross post to foreman-users?
>
> -- bk
>
> [3] https://www.transifex.com/organization/foreman/team/114/discussions/
>>>
>>> Lets treat this like a canary pull request to test the process. I
>>> decided to start with hammer-cli since it is small, uses the new gettext
>>> correctly, and upstream translations in Transifex have not been touched
>>> since 3 July.
>>>
>>> The pull request [1] has two commits. The first pulls in the latest
>>> strings from transifex. The second puts the upstream translations on top
>>> of it.
>>>
>>> There is a report at [2] which provides a better way (I hope) to review
>>> the translations. We branched downstream off of 0.1.4, and upstream is
>>> now at 0.2.0. It categorizes the changes as
>>>
>>> * New String: A translation did not exist in 0.2.0, and is being added.
>>> * Change: A translation existed in 0.2.0, unchanged or non existant in
>>> 0.1.4 with a new change from Downstream (D.S.)
>>> * Change to Modified String: A translation existed in 0.2.0, which was
>>> modified since 0.1.4, with a new change from Downstream
>>>
>>> My goal is to do the following:
>>>
>>> 1) Get this merge request approved
>>> 2) Once approved, create a edit.po file for each .po file and load the
>>> strings back into transifex. Assuming no changes, this should not impact
>>> translations.
>>>
>>> Comments are welcome on how I can improve the process and the reports.
>>>
>>> Thanks!
>>>
>>> – bk
>>>
>>>
>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>>>
>>
>> Dominic suggested that I reach out to the translators. I sent PM's on
>> transifex to all active translators. I also posted this message at [3]. Any
>> other suggestions? Should I cross post to foreman-users?
>>
>> – bk
>>
>> [3] https://www.transifex.com/organization/foreman/team/114/discussions/
>
> Hello,
>
> I checked the file and indeed, this is a good test. In the french translation,
> there are only 2 strings that are updated. I agree on the last one but not on
> the first one. The translation for the 1st one is good if the string is taken
> out of context. But inside the context of "hammer --help", the string is
> wrongly translated. That also highlight other strings, that are not capitalized
> correctly.
I added your comments to the pull request and modified the commit.
>
> The example being very good, my question is how do you want to proceed from now?
> If the number of strings is big as in foreman core, I suggest to delay my
> modification to the other strings after you merge your accepted changes as it
> can conflict with something.
I would agree with that.
>
> The rejection of strings is the easiest to handle, just not use the new
> translation strings. I suggest to notify those in the github web site, is that
> ok with other translators?
That is fine, Could you ack there as well?
>
> Anyway, it is a good idea to improve translations by sharing what you guys do
> at Red Hat and our work.
Agree… I would like to find the most painles way to do this. The Red
Hat translators have their own tool, so this is the best way so far. Any
suggestions on a better process I wold appreciate.
I am thinking for the next round tha i do 2 commits, one for only
additions, and then one for changes. Is thre a review process in transifex?
– bk
···
On 07/22/2015 12:17 PM, Claer wrote:
> On Wed, Jul 22 2015 at 58:06, bk wrote:
>> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
Ok… I dont think there is a great way to get review of patches from
folks who have put translations into transifex. Let me throw this out
there, Red Hat had professional translators do the work, so can we move
to a model where no comments after X days means we push the translations
in? I believe the benefits of all the changes outweigh the risks of a
few poor translations.
I have two pull requets out now for hammer-cli. One [1] is for all
dwonstream changes and additions. The second is for new strings only
[3]. Summary reports are listed in the commit messages. [1] has the
comment from Clear.
Can folks give a quick vote on this, and then Tomas would you be willing
to merge one of these and then push the translations into transifex? I
would like to get these done before the 1.10 branching so that the
strings make it into that release.
···
On 07/22/2015 12:17 PM, Claer wrote:
> On Wed, Jul 22 2015 at 58:06, bk wrote:
>> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
>>>
>>> Lets treat this like a canary pull request to test the process. I
>>> decided to start with hammer-cli since it is small, uses the new gettext
>>> correctly, and upstream translations in Transifex have not been touched
>>> since 3 July.
>>>
>>> The pull request [1] has two commits. The first pulls in the latest
>>> strings from transifex. The second puts the upstream translations on top
>>> of it.
>>>
>>> There is a report at [2] which provides a better way (I hope) to review
>>> the translations. We branched downstream off of 0.1.4, and upstream is
>>> now at 0.2.0. It categorizes the changes as
>>>
>>> * New String: A translation did not exist in 0.2.0, and is being added.
>>> * Change: A translation existed in 0.2.0, unchanged or non existant in
>>> 0.1.4 with a new change from Downstream (D.S.)
>>> * Change to Modified String: A translation existed in 0.2.0, which was
>>> modified since 0.1.4, with a new change from Downstream
>>>
>>> My goal is to do the following:
>>>
>>> 1) Get this merge request approved
>>> 2) Once approved, create a edit.po file for each .po file and load the
>>> strings back into transifex. Assuming no changes, this should not impact
>>> translations.
>>>
>>> Comments are welcome on how I can improve the process and the reports.
>>>
>>> Thanks!
>>>
>>> -- bk
>>>
>>>
>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>>>
>>
>> Dominic suggested that I reach out to the translators. I sent PM's on
>> transifex to all active translators. I also posted this message at [3]. Any
>> other suggestions? Should I cross post to foreman-users?
>>
>> -- bk
>>
>> [3] https://www.transifex.com/organization/foreman/team/114/discussions/
>
> Hello,
>
> I checked the file and indeed, this is a good test. In the french translation,
> there are only 2 strings that are updated. I agree on the last one but not on
> the first one. The translation for the 1st one is good if the string is taken
> out of context. But inside the context of "hammer --help", the string is
> wrongly translated. That also highlight other strings, that are not capitalized
> correctly.
>
> The example being very good, my question is how do you want to proceed from now?
> If the number of strings is big as in foreman core, I suggest to delay my
> modification to the other strings after you merge your accepted changes as it
> can conflict with something.
>
> The rejection of strings is the easiest to handle, just not use the new
> translation strings. I suggest to notify those in the github web site, is that
> ok with other translators?
>
> Anyway, it is a good idea to improve translations by sharing what you guys do
> at Red Hat and our work.
>
> Best regards,
>
> Benjamin Papillon
>
···
On 09/11/2015 03:27 PM, Bryan Kearney wrote:
> Ok.. I dont think there is a great way to get review of patches from
> folks who have put translations into transifex. Let me throw this out
> there, Red Hat had professional translators do the work, so can we move
> to a model where no comments after X days means we push the translations
> in? I believe the benefits of all the changes outweigh the risks of a
> few poor translations.
>
> I have two pull requets out now for hammer-cli. One [1] is for all
> dwonstream changes and additions. The second is for new strings only
> [3]. Summary reports are listed in the commit messages. [1] has the
> comment from Clear.
>
> Can folks give a quick vote on this, and then Tomas would you be willing
> to merge one of these and then push the translations into transifex? I
> would like to get these done before the 1.10 branching so that the
> strings make it into that release.
>
> -- bk
>
> [1] https://github.com/theforeman/hammer-cli/pull/175
> [3] https://github.com/theforeman/hammer-cli/pull/181
>
>
> On 07/22/2015 12:17 PM, Claer wrote:
>> On Wed, Jul 22 2015 at 58:06, bk wrote:
>>> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
>>>>
>>>> Lets treat this like a canary pull request to test the process. I
>>>> decided to start with hammer-cli since it is small, uses the new
>>>> gettext
>>>> correctly, and upstream translations in Transifex have not been touched
>>>> since 3 July.
>>>>
>>>> The pull request [1] has two commits. The first pulls in the latest
>>>> strings from transifex. The second puts the upstream translations on
>>>> top
>>>> of it.
>>>>
>>>> There is a report at [2] which provides a better way (I hope) to review
>>>> the translations. We branched downstream off of 0.1.4, and upstream is
>>>> now at 0.2.0. It categorizes the changes as
>>>>
>>>> * New String: A translation did not exist in 0.2.0, and is being added.
>>>> * Change: A translation existed in 0.2.0, unchanged or non existant in
>>>> 0.1.4 with a new change from Downstream (D.S.)
>>>> * Change to Modified String: A translation existed in 0.2.0, which was
>>>> modified since 0.1.4, with a new change from Downstream
>>>>
>>>> My goal is to do the following:
>>>>
>>>> 1) Get this merge request approved
>>>> 2) Once approved, create a edit.po file for each .po file and load the
>>>> strings back into transifex. Assuming no changes, this should not
>>>> impact
>>>> translations.
>>>>
>>>> Comments are welcome on how I can improve the process and the reports.
>>>>
>>>> Thanks!
>>>>
>>>> -- bk
>>>>
>>>>
>>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>>> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>>>>
>>>
>>> Dominic suggested that I reach out to the translators. I sent PM's on
>>> transifex to all active translators. I also posted this message at
>>> [3]. Any
>>> other suggestions? Should I cross post to foreman-users?
>>>
>>> -- bk
>>>
>>> [3] https://www.transifex.com/organization/foreman/team/114/discussions/
>>
>> Hello,
>>
>> I checked the file and indeed, this is a good test. In the french
>> translation,
>> there are only 2 strings that are updated. I agree on the last one but
>> not on
>> the first one. The translation for the 1st one is good if the string
>> is taken
>> out of context. But inside the context of "hammer --help", the string is
>> wrongly translated. That also highlight other strings, that are not
>> capitalized
>> correctly.
>>
>> The example being very good, my question is how do you want to proceed
>> from now?
>> If the number of strings is big as in foreman core, I suggest to delay my
>> modification to the other strings after you merge your accepted
>> changes as it
>> can conflict with something.
>>
>> The rejection of strings is the easiest to handle, just not use the new
>> translation strings. I suggest to notify those in the github web site,
>> is that
>> ok with other translators?
>>
>> Anyway, it is a good idea to improve translations by sharing what you
>> guys do
>> at Red Hat and our work.
>>
>> Best regards,
>>
>> Benjamin Papillon
>>
> Ok… I dont think there is a great way to get review of patches from
> folks who have put translations into transifex. Let me throw this out
> there, Red Hat had professional translators do the work, so can we
> move to a model where no comments after X days means we push the
> translations in? I believe the benefits of all the changes outweigh
> the risks of a few poor translations.
>
> I have two pull requets out now for hammer-cli. One [1] is for all
> dwonstream changes and additions. The second is for new strings only
> [3]. Summary reports are listed in the commit messages. [1] has the
> comment from Clear.
>
> Can folks give a quick vote on this, and then Tomas would you be
> willing to merge one of these and then push the translations into
> transifex? I would like to get these done before the 1.10 branching so
> that the strings make it into that release.
>
> – bk
>
> [1] https://github.com/theforeman/hammer-cli/pull/175
> [3] https://github.com/theforeman/hammer-cli/pull/181
>
It seems fair to get these merged after 2 months of the PR being public.
During the merge I can fix the trailing WS Claer has mentioned.
So I vote for merge.
Bryan, thanks for pushing this forward.
M.
···
On 09/11/2015 09:27 PM, Bryan Kearney wrote:
>
> On 07/22/2015 12:17 PM, Claer wrote:
>> On Wed, Jul 22 2015 at 58:06, bk wrote:
>>> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
>>>>
>>>> Lets treat this like a canary pull request to test the process. I
>>>> decided to start with hammer-cli since it is small, uses the new
>>>> gettext
>>>> correctly, and upstream translations in Transifex have not been
>>>> touched
>>>> since 3 July.
>>>>
>>>> The pull request [1] has two commits. The first pulls in the latest
>>>> strings from transifex. The second puts the upstream translations
>>>> on top
>>>> of it.
>>>>
>>>> There is a report at [2] which provides a better way (I hope) to
>>>> review
>>>> the translations. We branched downstream off of 0.1.4, and upstream is
>>>> now at 0.2.0. It categorizes the changes as
>>>>
>>>> * New String: A translation did not exist in 0.2.0, and is being
>>>> added.
>>>> * Change: A translation existed in 0.2.0, unchanged or non existant in
>>>> 0.1.4 with a new change from Downstream (D.S.)
>>>> * Change to Modified String: A translation existed in 0.2.0, which was
>>>> modified since 0.1.4, with a new change from Downstream
>>>>
>>>> My goal is to do the following:
>>>>
>>>> 1) Get this merge request approved
>>>> 2) Once approved, create a edit.po file for each .po file and load the
>>>> strings back into transifex. Assuming no changes, this should not
>>>> impact
>>>> translations.
>>>>
>>>> Comments are welcome on how I can improve the process and the reports.
>>>>
>>>> Thanks!
>>>>
>>>> -- bk
>>>>
>>>>
>>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>>> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>>>>
>>>
>>> Dominic suggested that I reach out to the translators. I sent PM's on
>>> transifex to all active translators. I also posted this message at
>>> [3]. Any
>>> other suggestions? Should I cross post to foreman-users?
>>>
>>> -- bk
>>>
>>> [3]
>>> https://www.transifex.com/organization/foreman/team/114/discussions/
>>
>> Hello,
>>
>> I checked the file and indeed, this is a good test. In the french
>> translation,
>> there are only 2 strings that are updated. I agree on the last one
>> but not on
>> the first one. The translation for the 1st one is good if the string
>> is taken
>> out of context. But inside the context of "hammer --help", the string is
>> wrongly translated. That also highlight other strings, that are not
>> capitalized
>> correctly.
>>
>> The example being very good, my question is how do you want to
>> proceed from now?
>> If the number of strings is big as in foreman core, I suggest to
>> delay my
>> modification to the other strings after you merge your accepted
>> changes as it
>> can conflict with something.
>>
>> The rejection of strings is the easiest to handle, just not use the new
>> translation strings. I suggest to notify those in the github web
>> site, is that
>> ok with other translators?
>>
>> Anyway, it is a good idea to improve translations by sharing what you
>> guys do
>> at Red Hat and our work.
>>
>> Best regards,
>>
>> Benjamin Papillon
>>
>
···
On 09/11/2015 04:20 PM, Bryan Kearney wrote:
> Here is the same pattern for the discovery plugin. Lukas, could you take
> a look and coordinate with Tomas:
>
> discovery
> * Downstream is 2.0.0
> * Upstream is 4.0.0
> Pull Request with Changes and Additions:
> https://github.com/theforeman/foreman_discovery/pull/215
> Pull Request with Additions only:
> https://github.com/theforeman/foreman_discovery/pull/216
>
> -- bk
>
>
> On 09/11/2015 03:27 PM, Bryan Kearney wrote:
>> Ok.. I dont think there is a great way to get review of patches from
>> folks who have put translations into transifex. Let me throw this out
>> there, Red Hat had professional translators do the work, so can we move
>> to a model where no comments after X days means we push the translations
>> in? I believe the benefits of all the changes outweigh the risks of a
>> few poor translations.
>>
>> I have two pull requets out now for hammer-cli. One [1] is for all
>> dwonstream changes and additions. The second is for new strings only
>> [3]. Summary reports are listed in the commit messages. [1] has the
>> comment from Clear.
>>
>> Can folks give a quick vote on this, and then Tomas would you be willing
>> to merge one of these and then push the translations into transifex? I
>> would like to get these done before the 1.10 branching so that the
>> strings make it into that release.
>>
>> -- bk
>>
>> [1] https://github.com/theforeman/hammer-cli/pull/175
>> [3] https://github.com/theforeman/hammer-cli/pull/181
>>
>>
>> On 07/22/2015 12:17 PM, Claer wrote:
>>> On Wed, Jul 22 2015 at 58:06, bk wrote:
>>>> On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
>>>>>
>>>>> Lets treat this like a canary pull request to test the process. I
>>>>> decided to start with hammer-cli since it is small, uses the new
>>>>> gettext
>>>>> correctly, and upstream translations in Transifex have not been
>>>>> touched
>>>>> since 3 July.
>>>>>
>>>>> The pull request [1] has two commits. The first pulls in the latest
>>>>> strings from transifex. The second puts the upstream translations on
>>>>> top
>>>>> of it.
>>>>>
>>>>> There is a report at [2] which provides a better way (I hope) to
>>>>> review
>>>>> the translations. We branched downstream off of 0.1.4, and upstream is
>>>>> now at 0.2.0. It categorizes the changes as
>>>>>
>>>>> * New String: A translation did not exist in 0.2.0, and is being
>>>>> added.
>>>>> * Change: A translation existed in 0.2.0, unchanged or non existant in
>>>>> 0.1.4 with a new change from Downstream (D.S.)
>>>>> * Change to Modified String: A translation existed in 0.2.0, which was
>>>>> modified since 0.1.4, with a new change from Downstream
>>>>>
>>>>> My goal is to do the following:
>>>>>
>>>>> 1) Get this merge request approved
>>>>> 2) Once approved, create a edit.po file for each .po file and load the
>>>>> strings back into transifex. Assuming no changes, this should not
>>>>> impact
>>>>> translations.
>>>>>
>>>>> Comments are welcome on how I can improve the process and the reports.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- bk
>>>>>
>>>>>
>>>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>>>> [2] https://gist.github.com/bkearney/65cc0f36bdfdf94e079e
>>>>>
>>>>
>>>> Dominic suggested that I reach out to the translators. I sent PM's on
>>>> transifex to all active translators. I also posted this message at
>>>> [3]. Any
>>>> other suggestions? Should I cross post to foreman-users?
>>>>
>>>> -- bk
>>>>
>>>> [3]
>>>> https://www.transifex.com/organization/foreman/team/114/discussions/
>>>
>>> Hello,
>>>
>>> I checked the file and indeed, this is a good test. In the french
>>> translation,
>>> there are only 2 strings that are updated. I agree on the last one but
>>> not on
>>> the first one. The translation for the 1st one is good if the string
>>> is taken
>>> out of context. But inside the context of "hammer --help", the string is
>>> wrongly translated. That also highlight other strings, that are not
>>> capitalized
>>> correctly.
>>>
>>> The example being very good, my question is how do you want to proceed
>>> from now?
>>> If the number of strings is big as in foreman core, I suggest to
>>> delay my
>>> modification to the other strings after you merge your accepted
>>> changes as it
>>> can conflict with something.
>>>
>>> The rejection of strings is the easiest to handle, just not use the new
>>> translation strings. I suggest to notify those in the github web site,
>>> is that
>>> ok with other translators?
>>>
>>> Anyway, it is a good idea to improve translations by sharing what you
>>> guys do
>>> at Red Hat and our work.
>>>
>>> Best regards,
>>>
>>> Benjamin Papillon
>>>
>> Ok… I dont think there is a great way to get review of patches from
>> folks who have put translations into transifex. Let me throw this out
>> there, Red Hat had professional translators do the work, so can we
>> move to a model where no comments after X days means we push the
>> translations in? I believe the benefits of all the changes outweigh
>> the risks of a few poor translations.
>>
>> I have two pull requets out now for hammer-cli. One [1] is for all
>> dwonstream changes and additions. The second is for new strings only
>> [3]. Summary reports are listed in the commit messages. [1] has the
>> comment from Clear.
>>
>> Can folks give a quick vote on this, and then Tomas would you be
>> willing to merge one of these and then push the translations into
>> transifex? I would like to get these done before the 1.10 branching so
>> that the strings make it into that release.
>>
>> – bk
>>
>> [1] https://github.com/theforeman/hammer-cli/pull/175
>> [3] https://github.com/theforeman/hammer-cli/pull/181
>>
> It seems fair to get these merged after 2 months of the PR being public.
> During the merge I can fix the trailing WS Claer has mentioned.
> So I vote for merge.
> Bryan, thanks for pushing this forward.
>
> M.
I agree, let's merge it.
T.
···
On 09/15/2015 11:42 AM, Martin Bačovský wrote:
> On 09/11/2015 09:27 PM, Bryan Kearney wrote:
On 07/22/2015 12:17 PM, Claer wrote:
On Wed, Jul 22 2015 at 58:06, bk wrote:
On Tuesday, July 21, 2015 at 9:30:14 PM UTC-4, bk wrote:
Lets treat this like a canary pull request to test the process. I
decided to start with hammer-cli since it is small, uses the new
gettext
correctly, and upstream translations in Transifex have not been
touched
since 3 July.
The pull request [1] has two commits. The first pulls in the latest
strings from transifex. The second puts the upstream translations
on top
of it.
There is a report at [2] which provides a better way (I hope) to
review
the translations. We branched downstream off of 0.1.4, and upstream is
now at 0.2.0. It categorizes the changes as
New String: A translation did not exist in 0.2.0, and is being
added.
Change: A translation existed in 0.2.0, unchanged or non existant in
0.1.4 with a new change from Downstream (D.S.)
Change to Modified String: A translation existed in 0.2.0, which was
modified since 0.1.4, with a new change from Downstream
My goal is to do the following:
Get this merge request approved
Once approved, create a edit.po file for each .po file and load the
strings back into transifex. Assuming no changes, this should not
impact
translations.
Comments are welcome on how I can improve the process and the reports.
Dominic suggested that I reach out to the translators. I sent PM’s on
transifex to all active translators. I also posted this message at
[3]. Any
other suggestions? Should I cross post to foreman-users?
I checked the file and indeed, this is a good test. In the french
translation,
there are only 2 strings that are updated. I agree on the last one
but not on
the first one. The translation for the 1st one is good if the string
is taken
out of context. But inside the context of “hammer --help”, the string is
wrongly translated. That also highlight other strings, that are not
capitalized
correctly.
The example being very good, my question is how do you want to
proceed from now?
If the number of strings is big as in foreman core, I suggest to
delay my
modification to the other strings after you merge your accepted
changes as it
can conflict with something.
The rejection of strings is the easiest to handle, just not use the new
translation strings. I suggest to notify those in the github web
site, is that
ok with other translators?
Anyway, it is a good idea to improve translations by sharing what you
guys do
at Red Hat and our work.
Thanks. So, this is how I think we will need to proceed. I dont know who
has permissions to push to transifex, but I think we would need to do
the following (which I am happy to help script up):
Merge the PR
For each file in locale/*/hammer-cli.po
Create locale/*/hammer-cli.edit.po
tx push -f
At this point, Transifex will reflect the latest verison of what is in
the PO files.
– bk
···
On 09/15/2015 08:57 AM, Tomas Strachota wrote:
> On 09/15/2015 11:42 AM, Martin Bačovský wrote:
>> On 09/11/2015 09:27 PM, Bryan Kearney wrote:
>>> Ok.. I dont think there is a great way to get review of patches from
>>> folks who have put translations into transifex. Let me throw this out
>>> there, Red Hat had professional translators do the work, so can we
>>> move to a model where no comments after X days means we push the
>>> translations in? I believe the benefits of all the changes outweigh
>>> the risks of a few poor translations.
>>>
>>> I have two pull requets out now for hammer-cli. One [1] is for all
>>> dwonstream changes and additions. The second is for new strings only
>>> [3]. Summary reports are listed in the commit messages. [1] has the
>>> comment from Clear.
>>>
>>> Can folks give a quick vote on this, and then Tomas would you be
>>> willing to merge one of these and then push the translations into
>>> transifex? I would like to get these done before the 1.10 branching so
>>> that the strings make it into that release.
>>>
>>> -- bk
>>>
>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>> [3] https://github.com/theforeman/hammer-cli/pull/181
>>>
>> It seems fair to get these merged after 2 months of the PR being public.
>> During the merge I can fix the trailing WS Claer has mentioned.
>> So I vote for merge.
>> Bryan, thanks for pushing this forward.
>>
>> M.
>
> I agree, let's merge it.
>
I have the perms. How do I produce the *.edit.po files?
M.
···
On 09/15/2015 04:35 PM, Bryan Kearney wrote:
>
>
> On 09/15/2015 08:57 AM, Tomas Strachota wrote:
>> On 09/15/2015 11:42 AM, Martin Bačovský wrote:
>>> On 09/11/2015 09:27 PM, Bryan Kearney wrote:
>>>> Ok.. I dont think there is a great way to get review of patches from
>>>> folks who have put translations into transifex. Let me throw this out
>>>> there, Red Hat had professional translators do the work, so can we
>>>> move to a model where no comments after X days means we push the
>>>> translations in? I believe the benefits of all the changes outweigh
>>>> the risks of a few poor translations.
>>>>
>>>> I have two pull requets out now for hammer-cli. One [1] is for all
>>>> dwonstream changes and additions. The second is for new strings only
>>>> [3]. Summary reports are listed in the commit messages. [1] has the
>>>> comment from Clear.
>>>>
>>>> Can folks give a quick vote on this, and then Tomas would you be
>>>> willing to merge one of these and then push the translations into
>>>> transifex? I would like to get these done before the 1.10 branching so
>>>> that the strings make it into that release.
>>>>
>>>> -- bk
>>>>
>>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>>> [3] https://github.com/theforeman/hammer-cli/pull/181
>>>>
>>> It seems fair to get these merged after 2 months of the PR being
>>> public.
>>> During the merge I can fix the trailing WS Claer has mentioned.
>>> So I vote for merge.
>>> Bryan, thanks for pushing this forward.
>>>
>>> M.
>>
>> I agree, let's merge it.
>>
>
> Thanks. So, this is how I think we will need to proceed. I dont know
> who has permissions to push to transifex, but I think we would need to
> do the following (which I am happy to help script up):
>
> * Merge the PR
> * For each file in locale/*/hammer-cli.po
> * Create locale/*/hammer-cli.edit.po
> * tx push -f
>
> At this point, Transifex will reflect the latest verison of what is in
> the PO files.
>
> -- bk
>
>
···
On 09/15/2015 11:42 AM, Martin Bačovský wrote:
> On 09/15/2015 04:35 PM, Bryan Kearney wrote:
>>
>>
>> On 09/15/2015 08:57 AM, Tomas Strachota wrote:
>>> On 09/15/2015 11:42 AM, Martin Bačovský wrote:
>>>> On 09/11/2015 09:27 PM, Bryan Kearney wrote:
>>>>> Ok.. I dont think there is a great way to get review of patches from
>>>>> folks who have put translations into transifex. Let me throw this out
>>>>> there, Red Hat had professional translators do the work, so can we
>>>>> move to a model where no comments after X days means we push the
>>>>> translations in? I believe the benefits of all the changes outweigh
>>>>> the risks of a few poor translations.
>>>>>
>>>>> I have two pull requets out now for hammer-cli. One [1] is for all
>>>>> dwonstream changes and additions. The second is for new strings only
>>>>> [3]. Summary reports are listed in the commit messages. [1] has the
>>>>> comment from Clear.
>>>>>
>>>>> Can folks give a quick vote on this, and then Tomas would you be
>>>>> willing to merge one of these and then push the translations into
>>>>> transifex? I would like to get these done before the 1.10 branching so
>>>>> that the strings make it into that release.
>>>>>
>>>>> -- bk
>>>>>
>>>>> [1] https://github.com/theforeman/hammer-cli/pull/175
>>>>> [3] https://github.com/theforeman/hammer-cli/pull/181
>>>>>
>>>> It seems fair to get these merged after 2 months of the PR being
>>>> public.
>>>> During the merge I can fix the trailing WS Claer has mentioned.
>>>> So I vote for merge.
>>>> Bryan, thanks for pushing this forward.
>>>>
>>>> M.
>>>
>>> I agree, let's merge it.
>>>
>>
>> Thanks. So, this is how I think we will need to proceed. I dont know
>> who has permissions to push to transifex, but I think we would need to
>> do the following (which I am happy to help script up):
>>
>> * Merge the PR
>> * For each file in locale/*/hammer-cli.po
>> * Create locale/*/hammer-cli.edit.po
>> * tx push -f
>>
>> At this point, Transifex will reflect the latest verison of what is in
>> the PO files.
>>
>> -- bk
>>
>>
> I have the perms. How do I produce the *.edit.po files?
> M.
>
