"Kenneth Nielsen" <[email protected]>, 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 _______________________________________________ gnome-i18n mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-i18n
