Transifex (was: Re: Working with branches after 4.6)

[Dimitris Glezos]

On Sun, Feb 22, 2009 at 7:44 AM, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> On Sat, 21 Feb 2009 16:18:31 +0200 Dimitris Glezos wrote:
>
>> On Sat, Feb 21, 2009 at 2:46 PM, Stavros Giannouris
>> <stavrosg at hellug.gr> wrote:
>> > On Fri, 20 Feb 2009 15:03:01 -0800
>> > "Brian J. Tarricone" <bjt23 at cornell.edu> wrote:
>> >
>> >> Stavros Giannouris wrote:
>> >>
>> >> > How about using transifex[1] for this, which is made to solve
>> >> > this exact problem?
>> >>
>> >> Actually, looking at it, transifex doesn't seem to solve this
>> >> particular problem.  It still appears to require that all the
>> >> individual translator contributors have login credentials to the
>> >> source repository, which means we'd still have to set up
>> >> fine-grained permissions for the git repos.  Not saying transifex
>> >> isn't a good idea, but it doesn't solve any new problems with the
>> >> git transition.
>> >
>> > No, the individual translators need login credentials for the
>> > transifex interface only. The source repo needs to have only one
>> > account for transifex, or that's my understanding of it.
>>
>> This is correct, Transifex only needs one SSH key to commit.
>
> That's kinda worse, IMO.  Now we have every single person's commits
> going through one committer account.  I guess with git that's not so
> bad, since git has a notion of splitting the committer and patch
> author, so they can be two separate people.

Right. We can use the translator's info in the 'author' field and
Transifex's ones in 'committer'. We can even use the translator's info
in both:

  http://cgit.freedesktop.org/packagekit/commit/?id=50d39435a110685b41b811d871992e7b915c96e6

>> All file
>> submissions are committed using this SSH key. There is also the choice
>> to use different SSH keys for different repository domains.
>
> We tend not to give ssh access out to everyone; all translators have
> https access to the server with no shell account.

Authentication can happen against the https password. After that
point, more fine-grained permissions could be assigned through Tx. A
group of people could be able to commit, another group will just be
able to upload the files to be submitted by the first group (not yet
implemented, on the roadmap).

> How can we be sure
> that this account won't get hijacked?  Sure, we can set the account's
> shell to /bin/nologin (or can we?), but... I still don't like the
> requirement of a 'real' account.

It's definitely a valid concern.

Fedora is mitigating this by having an admin run ssh-agent manually
before running Tx on top of it, so the SSH key password is written by
a person before Tx runs.

Alternatively, since git also supports pushing over http/s we could
add support for this as well. No SSH account would be needed in this
case.

Another alternative for dVCSs is to have Tx push patches to a
different branch or another server completely (eg. gitorious/github).
A committer (either a person or a service being run on your servers)
can pull the changesets into the main tree.

> (Of course, I'm being a bit hypocritical here, seeing as I set up
> gitosis on our server, which requires a ssh account...)
>
>> I'll be happy to answer any other questions raised -- Stavros, thanks
>> for CCing.
>
> Thanks!  I'm very interested in making our i18n process easier, both on
> our translators, and on our infrastructure.

And, to make things even tougher, also easier for our developers. =)

It's certain that Transifex doesn't solve _all_ problems right now.
The key point to keep, IMO, is "pushing translations upstream,
following the usual workflows" (eg. push on a source server of our own
using git patches). Having these two, we can find ways to overcome
shortcomings more easily.

-d


-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--