Branching - Fedora packages!
asgeirf at gmail.com
Thu Jan 15 07:44:45 UTC 2009
On Thu, Jan 15, 2009 at 1:08 AM, Miloslav Trmač <mitr at volny.cz> wrote:
> Ankitkumar Rameshchandra Patel píše v St 14. 01. 2009 v 20:16 +0530:
> > I am using Fedora 9 system on my personal machine and do not want to
> > upgrade to Fedora 10 or rawhide. Recently, I found some translation
> > mistakes for some Fedora packages, and want to update the translation
> > for those packages packages for Fedora 9 and make it upstream.
> That rarely works.
> Most packages have upstream either a simple release sequence with no
> branches, or they have branches that depend on the release cycle of the
> package. The upstream release cycles are very rarely synchronized with
> any distribution (GNOME in Fedora is a sort-of-but-not-really exception)
> - and there are many distributions to synchronize with :)
> In other words, if you want to update translations of a 1 year old
> package, upstream is not very likely to be interested in branching the
> package for your distribution version and creating new releases specific
> for your distribution.
> Maintaining the older versions of a package and backporting any code
> fixes is the distribution's job. The package maintainer of a
> distribution may collaborate with upstream on the fix (e.g. submit it to
> the upstream "head" version as well), but to fix a package on an older
> release of the distribution, the fix is committed on the distribution's
> branch of the package, not on upstream branch (there usually isn't any
> upstream branch).
> I can't see why the same mechanism shouldn't work for translations as
> well: Just create an updated .po file (or a patch that only changes a
> few specific messages), file a bug at bugzilla.redhat.com asking for a
> package update that uses that .po file. 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
> guess most translators can find a lot of work that needs doing on the
> main branch.)
Perhaps a case for linking the Translation Infrastructure directly with the
package build system?
For instance, if the package NetworkManager 0.7 had a translation error, the
translator could log in to the web-based translation system and locate
NetworkManager 0.7 and change the string there. The translation system would
have already imported the latest details from the package-system, including
the PO file in the NetworkManager sources. When the translation is approved,
the translation system would automatically submit a bug report against the
package in bugzilla, requesting a package-update with the patch to the PO
file. At the same time, if the string is still in HEAD, the translation
system would automatically update the translation there (ensuring that
translations are committed upstream).
Just a thought.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the trans