This isn't working, how can we make it better?
dimitris at glezos.com
Mon Oct 5 10:14:07 UTC 2009
On Mon, Oct 5, 2009 at 1:00 PM, Richard W.M. Jones <rjones at redhat.com> 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 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
> What would really work much better is if transifex could publish a
> git 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
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
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 et.redhat.com 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 translationproject.org).
This sounds like the worse choice, especially when one considers that
you are already using a dVCS.
>  virt-v2v
>  Some of the projects are using Mercurial, but we'll be switching
> these over to git real soon.
>  http://translationproject.org/html/maintainers.html
> Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
> 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 redhat.com
Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/
More information about the Fedora-trans-list