This isn't working, how can we make it better?

Dimitris Glezos dimitris at
Mon Oct 5 10:14:07 UTC 2009

On Mon, Oct 5, 2009 at 1:00 PM, Richard W.M. Jones <rjones at> wrote:
> As some translators on this list are aware, I've got a few packages
> with unmerged translation bugs going back a long way.
> I'd really like translators to be able to contribute translations
> directly into my projects, as outlined here:
> and from what I hear from another project where this is done[0] it
> seems to work really well.
> _However_ neither of the methods described above is suitable for me.
> I don't want to change the project hosting to use Fedorahosted, and I
> cannot allow ssh access to the hosting machines from anywhere in the
> world.
> What would really work much better is if transifex could publish a
> git[1] repository with a rebasable branch containing the translations
> that I could pull.  I could track this branch automatically, and merge
> the contents in just before a release (resolving any conflicts
> myself).

This is something that we can't support for a few reasons:

 1. Publishing VCSs requires a lot of work (considering the security
work and all the VCS needed to be exposes). It also doesn't work for
centralized VCSs.

 2. Automatic rebase is something we can't do in Tx either. Conflicts
will show up which Tx can't handle automatically.

Distributed VCSs allow having branches anywhere, so one could use an
intermediate branch on eg. github or fedorahosted instead of a
Transifex-hosted one. In addition, this allows you to completely
delete it if you want, do rebasing as you like, and just ask Transifex
to 'pull a new copy'. I understand this is definitely not the same as
having one rebasable pullable branch published by Tx, but it's a very
good compromise offering all the benefits which at the moment are

Hence, I can see two choices:

 1. Migrate all your code somewhere where both Tx and community
developers can have access to, and have Tx eg. push to a non-master

 2. Host a branch somewhere where Tx can have access to (mentioned
above) and every now and then do an automatic `git pull`.

Hosting on sounds like a strategic non-reversible
decision, so I guess the best choice is #2.

> An alternative would be to allow me to rsync the po/ directory (as is
> done by[2]).

This sounds like the worse choice, especially when one considers that
you are already using a dVCS.


> [0] virt-v2v
> [1] Some of the projects are using Mercurial, but we'll be switching
> these over to git real soon.
> [2]
> --
> Richard Jones, Emerging Technologies, Red Hat
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> --
> Fedora-trans-list mailing list
> Fedora-trans-list at

Dimitris Glezos

Transifex: The Multilingual Publishing Revolution --

More information about the Fedora-trans-list mailing list