[Freeipa-devel] [PATCH] 0066 Arrange stripping .po files

[John Dennis]

On 07/24/2012 06:39 AM, Petr Viktorin wrote:
> On 07/24/2012 01:12 AM, John Dennis wrote:
>> On 07/23/2012 06:27 AM, Petr Viktorin wrote:
>>> As a translator (for another project), I don't like Transifex and prefer
>>> to send good old Git pull requests. I understand a "traditional"
>>> workflow is hard to coordinate with others that use Transifex, but still
>>> I'd hate it if we became dependent on Tx.
>>
>> For better or worse we are dependent on TX (Transifex). Fedora has
>> adopted TX as it's translation tool, RHEL's translation tools integrate
>> with TX (as well as other translation portals). And SSSD and IPA have
>> made a a commitment to TX based on the direction of Fedora and RHEL.
>>
>> Given that we've adopted TX I don't see the value in maintaining tools
>> that support both TX and non-TX workflows. I'd rather see us delete the
>> non-TX elements. If we have just one workflow it's easier to understand
>> and maintain the code. If we ever decide we need to go back to a non-TX
>> workflow we can always retrieve the deleted code from git.
>>
>
> This means you have to be a member of a Fedora translation team to
> translate.

Actually we're not using the Fedora TX instance, rather the 
transifex.net instance so I don't think we're limited to translators who 
are members of a Fedora translation team.

 > It makes it harder for people to fork the project. A workflow
> with a mandatory central repository makes it impossible to experiment
> locally.
> I'm all for having a standard way to receive contributions, but limiting
> how people can create those contributions isn't good.
>
> I'm all for deleting unused code, but here I think it would be a bad move.


Actually I don't have strong feelings about this one way or the other. 
My primary concern with two different workflows was that we have to test 
and maintain both and one of them is currently unused. My other concern 
is the added complexity, most developers and release engineers don't 
understand this stuff so keeping is simple to accommodate those less 
familiar with the process seemed like a win.

But you have a valid point about being flexible, so it's fine with me to 
keep the old code. We probably need better documentation.

John



-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/