On Mon, Oct 05, 2009 at 01:14:07PM +0300, Dimitris Glezos wrote:
On Mon, Oct 5, 2009 at 1:00 PM, Richard W.M. Jones
<rjones(a)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_Transife...
>
> 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`.
What I've done is to update the documentation here:
https://fedoraproject.org/wiki/L10N/FAQ#Step_1:_Enable_access_to_your_module
so that this third option is documented.
I'll try it and see how it goes.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat
http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top