Re: Some details of what happened (was: Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.)

[Petr Kovar <pmkovar gnome org>]

"Kenneth Nielsen" <k nielsen81 gmail com>, Sat, 17 Jan 2009 20:47:02 +0100:

> >  * in some cases upstream did not set the c-format flag correctly
> 
> No but that is a development issue right? According to the gettext
> manual[1] we shuldn't ever touch any other than the fuzzy flag, so for
> the modules where that is the problem you can have anybody forward the
> bug report upstream, that does not have to be done by translators.
> 
> Second, I must admit that, despite of your explanations, I don't at
> all understand how a po-file that doesn't pass the necessary checks,
> can ever end up being shipped and used.
> 
> Regards Kenneth Nielsen
> 
> [1] http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
> 
> >
> > To catch all possible erroneous translations we enforced the c-format
> > flag on all messages when doing our analysis. The outcome (
> > http://people.ubuntu.com/~arne/langpack_errors/ ) has therefor some
> > false positives.
> >
> > [Quote from Danilo to illustrate the problem]
> > Indeed.  c-format and no-c-format flags come from packaged templates, so
> > it's up to them to decide on the proper usage (i.e. Launchpad doesn't
> > have enough knowledge to insert them properly).  Note that any approach
> > to find every _potential_ problem would give us a lot of
> > false-positives.
> >
> > I.e. "Insert % sign" is treated as space-padded "%s" modifier if marked
> > as c-format string, but is definitely not one.  To properly decide if
> > any one case is a genuine problem or not, one would have to dive into
> > the code that uses the string itself.
> > [/Quote]
> >
> >> Anyway, I think I'd express quite accurately the feeling of many l10n
> >> teams members if I say we're somewhat tired of those problems. Rosetta
> >> has allowed people to fork upstream translations when we should only
> >> have changed Ubuntu-specific strings. This leads to a terrible mess
> >> where small teams have to manage a dramatically large textual domain
> >> that they can't really master. Upstream translators work far better
> >> than we can do on their projects, and avoid the kind of trouble we're
> >> now facing: downstream-modified strings that don't get fixed when
> >> upstream updates them. We really need a solution here, like locking
> >> translations for packages that belong to upstream.
> >
> > Wouldn't have helped in this case. The buggy translations came from
> > upstream. I agree that in some cases some locking would be useful. But
> > on the other hand, if upstream translations have problems, they can be
> > fixed faster for our users by using Launchpad (especially for stable
> > releases, which don't receive upstream updates anymore except for
> > regression and security fixes).

Slightly off-topic here, but anyway, the Launchpad topic has already landed
so... I thought or was under impression that Launchpad changed in some way
the policy regarding the upstream translation preference over downstream.
Was I wrong, or is it (still) planned?

Cheers,
Petr Kovar