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

Jim Meyering jim at
Mon Oct 5 10:42:11 UTC 2009

Dimitris Glezos wrote:
> On Mon, Oct 5, 2009 at 1:00 PM, Richard W.M. Jones <rjones at> 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[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 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[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 (, 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 server.



More information about the Fedora-trans-list mailing list