Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454263 - Allow transifex to handle the translations
Summary: Allow transifex to handle the translations
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-p2v
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
Depends On:
Blocks: 436824
TreeView+ depends on / blocked
Reported: 2008-07-07 10:51 UTC by Fabian Affolter
Modified: 2010-03-16 17:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-28 12:36:02 UTC

Attachments (Terms of Use)

Description Fabian Affolter 2008-07-07 10:51:34 UTC
Maybe using Transifex for translations of virt-p2v would be a good idea. 

Please see

Comment 1 Richard W.M. Jones 2008-09-15 12:19:01 UTC
I'm looking into this.  It requires some cooperation from the
people who run our Mercurial repo to create the special account.

Comment 2 Ankit Patel 2008-10-03 07:43:28 UTC
Fedora 10 translations deadline is 21st October 2008. Could this issue be resolved before due date?

Thanks for looking into the issue!

Comment 3 Asgeir Frimannsson 2008-10-03 08:01:54 UTC
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.

Comment 4 Richard W.M. Jones 2008-10-06 08:54:51 UTC
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" 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?

Comment 5 Daniel Berrange 2008-10-06 10:14:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.