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`.
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.
Hi Dmitry,
That you say the translationproject's approach of providing
downloadable .po files seems like the worst approach makes me think
you don't understand how it works.
Here's what I do in upstream coreutils:
The build-from-source procedure involves running a script
named bootstrap which downloads any new or updated .po files
for the project. For coreutils, I choose not to version-control
the .po files, since they are tracked externally (
tp.org), but
that is a personal choice. I could have chosen to VC them.
Albeit at the cost of a lot of churn, since they change frequently,
and in small, insignificant ways that would end up polluting my VC
history and making it harder for me to manage code-related searches
through the history (there would be many false-positives).
Once the .po files are downloaded, the usual tools (msgmerge, xgettext)
update them with respect to any changed or removed messages.
When I make a release, I send the TP coordinator a pointer to the
tarball, and they take care of updating their official copy of
the .POT file, which then sends a signal to translation teams that
there are (usually) new messages to translate.
The bottom line is that I have no trouble with .po-file merges, *ever*.
In fact, I tend to forget about translations, and that is as it should
be. It's only when I run ./bootstrap that occasionally I see a new
cs.po, fr.po, etc. file is being (quickly!) rsync'd from the
tp.org server.
hth
Jim