Red Hat Bugzilla – Bug 454263
Allow transifex to handle the translations
Last modified: 2010-03-16 13:14:03 EDT
Maybe using Transifex for translations of virt-p2v would be a good idea.
I'm looking into this. It requires some cooperation from the
people who run our Mercurial repo to create the special account.
Fedora 10 translations deadline is 21st October 2008. Could this issue be resolved before due date?
Thanks for looking into the issue!
Just a tip:
A quick fix for hg/git repos that you don't want a wacky system like transifex to push to (due to e.g. security restrictions on internal repos), is to have transifex push to an external clone of the repo somewhere, then you can pull translations from there before you package.
Dan, maybe you can comment on this one.
The problem is that transifex needs to have a special commit-level account
An alternative suggested above was to have a separate repo "outside"
hg.et.redhat.com where transifex can commit and we can pull the changes
from. However this seems to just move the problem somewhere else.
Alternatively, we could move the whole hosting for virt-p2v (and virt-top,
virt-df, etc.) somewhere else such as fedorahosted.
Do any of our other projects use transifex, such as virt-manager?
The requirement for transiflex to have write access to a repository is just wrong. Making "upstream" provide a 2nd mirrored repo which transiflex can write to isn't really helping things, because you're burdening the maintainers with the jobs of syncing the two.
With a distributed SCM, transiflex itself must already have a local copy of the repo that it is working against, from which it would ordinarily push changes back upstream.
Thus, the correct solution is for transiflex's local copy of the master upstream repo to be made available on a public URL.
- Transiflex can pull from upstream with read-only access.
- Translations can be committed to its local repo
- Upstream developers can periodically pull from transiflex's local repo into master repo
This avoids any requirement that transiflex have write access, and avoids the need for upstream to maintain multiple copies of their repo just from transiflex.