L10N tools: Increase quality of translations

[Ahmed Kamal]

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.
https://hosted.fedoraproject.org/projects/presto/wiki/WikiStart
The work is far from complete, but I thought I'd drop a line

On 12/1/06, Keld Jørn Simonsen <keld at dkuug.dk> wrote:
>
> 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 (dimitris at glezos.com) 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 cvs.fedoraproject.org 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
> > Fedora-trans-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-trans-list
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-trans-list/attachments/20070209/e0ffda8f/attachment.htm>