[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to update a po file collection when upstream also change them



On Wed, Aug 24, 2005 at 10:36:41AM +0200, Javier Fernández-Sanguino Peña wrote:
> On Wed, Aug 24, 2005 at 01:43:37AM +0200, Martin Quinson wrote:
> > Hello,
> > 
> > a while ago, someone (Denis?) raised a major issue in my designs and dreams
> > of a central po files collection in debian.
> > 
> > Let's imagine that upstream distribute a fr.po file, but it's suboptimal. It
> > gets fixed (or completed) internally in debian, and everything is great and
> > such.
> > 
> > But how to deal with a new upstream release? Dropping the upstream po file
> > is very impolite with upstream translators. Moreover, they may have improved
> > in the meanwhile. Dropping the debian translation is a bit suicidal. 
> 
> From my POV, and my experience working upstream, people that want to
> translate po files from upstream should work with upstream directly.

Yeah right. But I wasn't saying that this is a good idea. I was just trying
to solve an issue which *will* happen. If you prefer, let's change a bit the
POV:

Suppose there is a central po database, in which established translation
teams store their work. They for example store all po-debconf templates in
it, and it's an hard job to get the maintainer integrate their work so it
happen to be out of sync sometimes.

Imagine now that for a reason X or Y, a new version of the package comes out
with an updated translation in language xx. Unfortunately, the xx team also
had a translation in the DB, much improved of course.

How should the scripts feeding the DB from material extracted from the
packages react to this case? Drop the maintainer approved translation? Mmm.
You seem to like -devel flames, don't you? Drop translation from the
official translation team? Don't you know that developpers cannot deal with
l10n properly (if they could, l10n teams --we-- would be useless ;)?

No, the script needs to pinpoint the parts on which there is really a
conflict, an warn the translator about it so that a human can deal with the
problem without having to check everything manually. Exactly what the
proposed algorithm tries to do. I guess I should have given some more
context from the begining on, sorry.


Bye, Mt.

Attachment: signature.asc
Description: Digital signature


Reply to: