L10N migration to transifex.net

Thu Feb 24 04:03:46 UTC 2011

On 02/21/2011 04:10 PM, Ricky Zhou wrote:
> On 2011-02-21 03:25:23 PM, Ruediger Landmann wrote:
>> As I see it, you answer your own question further down your post. We
>> lose control of the instance. Whether or not the Fedora project ever
>> exercises that control is a different matter.
>>
>> Some people might see this as a purely theoretical distinction, but it's
>> a distinction that exists at the very heart of Free software. With the
>> exception of packages that I'm involved in maintaining, I have very
>> rarely delved into the code or modified the code of the Free software
>> that I use every day. However, by choosing Free software, I retain the
>> ability to do these things if and when I choose to do so.
> transifex.net runs on the same open source software that we run (albeit
> a much newer version).  If we ever have the need to exercise control
> over the instance that transifex.net won't allow us, then we are always
> free to move back to running our own instance (the migration would work
> exactly like the one that's currently ongoing).

I'm sorry -- I didn't express myself clearly enough here, since both you 
and Jared have both understood something a little different from what I 
meant.

I know that Transifex is indeed Free software, and I certainly didn't 
mean to imply anything different. The parallel I'm drawing is this:

* Free software on my PC means that I can inspect or modify that 
software, whether or not I ever exercise that power.

* The Fedora Project's control of its own translation infrastructure 
means that we can inspect or modify that infrastructure, whether or not 
we ever exercise that power.

That's why I said the situation is analogous -- it's certainly not 
identical.

>> More pragmatically, needing to move translation files between
>> transifex.net and our repos seems to me like an unfortunate hurdle to
>> translations in Fedora. This is probably not a substantial disadvantage
>> to relatively stable software packages where there is little change from
>> version to version, but would be felt more in documentation where string
>> changes are more frequent.
> As we discussed in the other sub-thread, this change happens regardless
> of whether we run 1.1 in Fedora or on transifex.net.

I  stand corrected on this point; but see below. Please take everything 
I say in the friendly and collegiate spirit in which it's intended. 
Line-by-line rebuttals inevitably come across as sounding quarrelsome, 
and that's not my intention at all. I've tried to keep that tone out of 
my responses, but if any has inadvertently slipped through, please 
forgive me :)

> I consider this to
> be a huge improvement for the following reasons:
>
> Sysadmin:
>   - Don't have to manage shared storage when scaling transifex to run on
>     multiple servers.  In Fedora Infrastructure, this is one of the
>     things we've been looking forward to the most with moving off of
>     Transifex 0.x.
>   - Don't have to worry about maintaining and securing private SSH keys
>     with access to a bunch of upstream projects.  Right now, we have to
>     enter passphrases every time we restart a server with Transifex (and
>     whenever we forget, the site is just broken for translators), and we
>     also have to worry about securing a bunch of SSH keys to things that
>     we'd rather just not have access to.

I have not been involved in maintaining the Transifex instance, so I'm 
not in a position to dispute these points.
> Developer:
>   - I don't have to give Transifex or translators write access to my
>     repo.  Sure, access can be restricted with commit hooks or a file
>     whitelist in Transifex, but those are a pain to maintain.

It's also a pain to have to remember to pull files manually and to have 
to maintain a configuration file. With the previous system, you set up 
the pseudo-user once and never had to think about it ever again. This 
made Transifex awesome :)

>   - I get to control exactly when POT file changes are pushed and when PO
>     file updates are pulled.

Under what circumstances do you envisage maintainers might want to ship 
obsolete or less complete translations? Conversely, if your POT files 
aren't ready for translation, why are you pushing them into the repo?

And of course, you could do that with the previous Transifex as well.

>   - Developers can use whatever VCS they want without needing to worry
>     about Transifex support.  Back in the early days, Toshio had to spend
>     time writing a Bazaar plugin in order to get Transifex support for
>     his projects.  Other developers use Monotone, Darcs, or maybe they
>     don't use a VCS at all.  The new model allows all of these people to
>     use Transifex without issue.

All true; of course, once a plugin exists, everybody benefits. It's also 
a pity that it was either/or and that Transifex didn't have a fallback 
mechanism for the less widely used VCSes or projects without a VCS. What 
proportion of projects are we really talking about anyway?

> Translator:
>   - Common strings between projects can be shared.

Does this happen? How much does it happen? In any case, I'm sceptical of 
the utility of matching strings taken from completely different 
contexts, but perhaps translators feel this isn't an issue?

>   - Better failure handling.  If the project's repo is down or
>     unreachable for any reason, translations don't get denied - instead,
>     they get saved, and the developer will still be able to pull and use
>     them later (this kind of falls under sysadmin and developer too).

I concur that this is a very real benefit. It's a shame that Transifex 
can't do both -- in other words, if it can't reach the project repo, 
that it stores the translation and alerts the maintainer and translator 
that there's been a problem but that the translation is safely stored 
for now.

>> I am really very sorry that Red Hat has not stepped into the gap earlier
>> to offer support for this part of the infrastructure and that the
>> situation had to reach this crisis point. Nevertheless, the offer is out
>> there now. If the L10N team accepts our help, we will of course need to
>> put a plan in place to ensure that we provide some ongoing support (as
>> we do with Bugzilla) -- at least until if and when somebody else in the
>> community develops an interest in maintaining the instance.
> I appreciate your work to find resources to maintain a Transifex
> instance, although the timing is pretty late, yes.  I'm still not clear
> on exactly what freedoms we're losing out on, for the reasons I gave
> above.
>
> Also note that even if we have some people dedicated to running
> Transifex for Fedora, the cost of maintaining it doesn't go away
> entirely.  We still have to dedicate server resources, get woken up by
> alerts when it goes down, get the new sysadmins onto the team and
> trained on how we do things, and so on.

Acknowledged.

>> Thanks again for the vote of confidence; it means a lot to me. I'm not
>> deluded enough to imagine that this will be an easy task! :)
> Sorry to say this, but it's not quite a vote of confidence yet :-)  I'm
> still trying to get more of a understanding on the reasons that some
> people don't want to move to transifex.net.

The most fundamental reason is giving up control of a large and 
important piece of Fedora infrastructure to an outside entity. That's 
seriously unpalatable to a lot of people -- any understanding of why 
people don't want to move to transifex.net pretty much relies on 
acknowledging that, even if you don't feel the same way personally.

We obviously agree that having transifex.net host the instance results 
in less work for infra, but beyond that I'm not convinced that the move 
to transifex.net is better for developers or translators for any reason 
other than the reliability of maintenance (which is more-or-less the 
same point as it being less work for infra).

Thanks for the detailed reply and sorry that my response has taken so 
long -- I wanted to get it right. I'm taking particular notice of the 
advantages that you perceive in the move to transifex.net -- they 
provide very useful insight even where I do not necessarily agree.

Cheers
Rudi