Bug 454263

Summary:	Allow transifex to handle the translations
Product:	[Community] Virtualization Tools	Reporter:	Fabian Affolter <mail>
Component:	virt-p2v	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	ankit, asgeirf, berrange, noriko, piotrdrag
Target Milestone:	---	Keywords:	Translation
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-07-28 12:36:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	436824

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
http://fedoraproject.org/wiki/L10N/Tools/Website#add-transifex

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!
Ankit

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
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 Berrangé 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.