This isn't working, how can we make it better?
Richard W.M. Jones
rjones at redhat.com
Mon Oct 5 11:03:44 UTC 2009
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 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`.
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
More information about the Fedora-trans-list
mailing list