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

[Dimitris Glezos]

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:
>
> https://fedoraproject.org/wiki/L10N/FAQ#How_do_I_add_a_module_to_Transifex.3F_.28.23add-transifex.29
>
> 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
blockers.

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
branch.

 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[2]).

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

-d



> [0] virt-v2v
>
> [1] Some of the projects are using Mercurial, but we'll be switching
> these over to git real soon.
>
> [2] 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.
> http://et.redhat.com/~rjones/virt-df/
>
> --
> Fedora-trans-list mailing list
> Fedora-trans-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-trans-list
>



-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/