Since you see value in a delta update mechanism for translation updates. Currently I'm working on a test project "presto" to add such capability. <a href="https://hosted.fedoraproject.org/projects/presto/wiki/WikiStart"> https://hosted.fedoraproject.org/projects/presto/wiki/WikiStart</a> The work is far from complete, but I thought I'd drop a line <div>On 12/1/06, Keld Jørn Simonsen <<a href="mailto:keld@dkuug.dk">keld@dkuug.dk</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would like a better way to distribute corrections to translations, after the release date. Many times the translations did not make it in time, for the relaese. This can be both for fedora/red hat programs, but also for other programs like kde, gnome and what-have-you. I note that, as Linux becomes more and more popular, end users are much less likely to understand English, and the translations are then mandatory for the programs to be usable. Could this be done as separate packages, or reissues of packages with more complete translations? and do we need some delta mechanisms for rpm packages to avoid waisting bnetwork bandwidth on small translations updates. Or is there a need to have several levels of updating, incliding translation updates, security updates, fixes, and facility updates, or should people just always be current? Do we have the necessary tools to make such things? best regards keld On Thu, Nov 30, 2006 at 08:41:37PM -0500, Bill Nottingham wrote: > Dimitris Glezos ( <a href="mailto:dimitris@glezos.com">dimitris@glezos.com</a>) said: > > * Integrate better the handling of translation during a "local" package's > > lifecycle. Have a flag raised for a package update that introduces new strings > > so that translators can translate the new strings before the > > repackaging/updating. Include in the schedule for each release a "string freeze > > date" and a week later a "translation freeze date" and have all our packages > > rebuilt after the latter and before the actual release. > > String freezes are easy to do, it's just a matter of discipline > in sticking to them. > > > * Move po files on their own cvsroot on <a href="http://cvs.fedoraproject.org">cvs.fedoraproject.org</a> to reduce > > complexity and maintenance and to increase security (with a new group). > > >From a maintainer standpoint, the translations *need* to > be in the same SCM system as the code. Without that, you lose features > like branching, easy spinning of tarballs, etc. Moving just the > po files is not the answer. > > > * Start working with the complex and tricky path to upstream translations that > > no distribution has tackled yet in a successful way. Bring our translators > > closer to the upstream projects. > > Well, the simple answer is if you want to translate upstream, > go upstream. For desktop environments, such as GNOME or KDE, > this is fairly easy. For other projects, it is more complicated. > > Bill > > -- > Fedora-trans-list mailing list > <a href="mailto:Fedora-trans-list@redhat.com">Fedora-trans-list@redhat.com </a> > <a href="https://www.redhat.com/mailman/listinfo/fedora-trans-list">https://www.redhat.com/mailman/listinfo/fedora-trans-list</a> _______________________________________________ Fedora-infrastructure-list mailing list <a href="mailto:Fedora-infrastructure-list@redhat.com">Fedora-infrastructure-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list">https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list </a> </blockquote></div>