Bug 454263 - Allow transifex to handle the translations
Allow transifex to handle the translations
Product: Virtualization Tools
Classification: Community
Component: virt-p2v (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Richard W.M. Jones
: Translation
Depends On:
Blocks: 436824
  Show dependency treegraph
Reported: 2008-07-07 06:51 EDT by Fabian Affolter
Modified: 2010-03-16 13:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-28 08:36:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Fabian Affolter 2008-07-07 06:51:34 EDT
Maybe using Transifex for translations of virt-p2v would be a good idea. 

Please see
Comment 1 Richard W.M. Jones 2008-09-15 08:19:01 EDT
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 03:43:28 EDT
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 04:01:54 EDT
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 04:54:51 EDT
Dan, maybe you can comment on this one.

The problem is that transifex needs to have a special commit-level account
on hg.et.redhat.com.

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