Miloslav Trmač wrote:
That's because we don't have such process or may be tools in place.
Ankitkumar Rameshchandra Patel píše v Čt 15. 01. 2009 v 14:28 +0530:
I think I didn't make it very clear. The context here is for core
Fedora packages only, which are maintained on the fedorahosted
No matter. Most packages don't have branches for code now, and if the
package is ever updated in Fedora 9, it is usually either a quite small
patch (not a new tarball from any VCS), or a full rebase to the most
recent upstream release. In _neither_ case will the developer want to
use the code on a "Fedora 9" branch" of the package, so they will not
pull in any translations from such a branch.
We maintain any given release X until one month after the release of
Fedora maintainers are not
expected to create branches for every release and maintain them
individually, Fedora does quite frequent releases and all features are
expected to get in Fedora "in the next release"; the same should apply
to translations IMHO. (There are a few exceptions that have branches
like anaconda, but specifically anaconda is a special case because full
rebases of the installation program are very risky).
Try to provide the feature which can help them update previous
I can't see why the same mechanism shouldn't work for translations
well: Just create an updated .po file (or a patch that only changes
few specific messages), file a bug at bugzilla.redhat.com asking for
package update that uses that .po file.
We have 80+ languages in FLP. and a number of packages.
How many of those are _actually_ likely to be updated in Fedora post
Alright, so will you accept Punjabi translation for your package if I
translate & attach it in the bug?
Translators are not the techies. They can download translation file =>
translate it => submit it. Doing patches, VCS checkouts, commits tend
to reduce their interest.
Right, getting a .pot file to translate against for an older Fedora
release might really be difficult (but comparatively easy to solve -
just copy them all from transifex to a directory available over HTTP at
release time). But there's no need for any commits - just submit the
full .po file to bugzilla.
That sounds better actually, since it gives complete control over to
the translators over the translations they are doing. They don't need
to wait for anyone to make their translations live.
This doesn't let you use
transifex's statistics or submission interface - but (at least in
Fedora), translations are very rarely updated for older versions.
I don't see transifex provides the facility to submit translation of
packages which are not branched for Fedora 10 or 9 or earlier release.
Submitting a translation to a branch _doesn't solve your problem_. On
HEAD, the simple act of submitting a translation via Transifex ensures
that it will be (eventually) included in a released package. On a
branch, it doesn't: you must let the package maintainer know that there
is a new translation available and the package maintainer must manually
create a new package.
If you are already dead set on updating amount of translations (say more
than one translation update per package a month) after the release, you
need to argue for separating the translations from the packages they
translate, and to get someone to develop a completely automated
mechanism for shipping the translation updates to final users. Until
that is done, the system - with package maintainers manually building
updates that can contain new translations - can not handle 20
translation teams that decide to translate Fedora 9 a month after its
Now, this makes me nervous again. :(
We also really can't migrate to such a mechanism for Fedora
10, and probably not even for Fedora 11.
Launchpad has it's own set of issues that I don't want to get into.
_And even if you do this_ and decouple translation updates from
"software" updates, "upstream" for most packages (on fedorahosted.org or
not) still won't be interested in the translation! You'll need to do
what Launchpad does, and store the translations in a Fedora-specific
storage, away from any upstream repository.
Well, I am fine with any of these options as long as they solve the
issue. But, anything we come to the conclusion should be best for
Fedora (Users, Community, Project, Developers, Localizers, everyone who
To sum up: Either the volume of translation updates is small enough that
the complete process can be done manually, or you need to persuade
Fedora to make a major change to the way packages are delivered - in
that case branching anything in fedorahosted or Transifex is far from
the first step.