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

Re: Translations copyrights/licences

On Sun, 23 May 2010 07:53:14 +0200
Julien Valroff <julien@kirya.net> wrote:

> The sources contain gettext translations, the copyrights and licences
> of which are sometimes unclearly stated, eg:

Nearly all packages with translations have "problems" like this. It
isn't actually a problem, there's nothing realistic that can be done
about it and nearly all packages with translations would have the same
"problem". If we accept that this is an issue, we'll have 14,000 RC
bugs overnight and we'll never release again.

Translators are often transient - a translation can turn up in a
package even with a Last-Translator but no further translations may
ever appear with no replies from the supplied address. Eventually
someone else might take over but a lot of packages have abandoned
translations and no usable details of Last-Translator.

I see no reason to specify these in debian/copyright.

Translator details can change more frequently than the wind and are
distributed under the same license as the package. To me, that's an end
to it.

> Sometimes, the name of the last translator isn't even stated.

s/Sometimes/Frequently/. Even when stated, the given name isn't
contactable anymore, so the prospect of getting anything in the
headers updated is zero. It's hard enough getting the translations
themselves updated.

With po files in top level po/ directories, there may be a
"translator-credits" msgid where the msgstr has a name but there's no
guarantee that this / these names are up to date.

Those details do appear in the UI of such programs, generally, so the
translators have some motivation to put their own names in that list,
so those can be a bit better but still not 100% up to date.

> I will obviously contact upstream so that they contact the translators
> and ask them to fix this, but I guess this will take some time and I
> would like to be able to get pino uploaded soon.

It isn't even possible in most cases. Only a minority of translators
would be able to respond. I don't think you should even contact
upstream - there's likely to be nothing upstream can do about it.



If you contacted *me* as upstream, I would refuse. Simple. It isn't
going to happen. You can threaten to remove the package from Debian,
you can threaten to remove all incomplete translations, it won't matter
- there is nothing that can be done because the people are either not
known or not contactable.

> How to deal with such unclear/incomplete headers?

As Debian Maintainer, you don't. Simple.

It's quite enough of a headache for upstream.
> In the case the copyright is "given" to the pino developers, wouldn't
> it be good to state the name of the last translator(s) in the
> copyright file? If so, is an X-Last-Translator field appropriate in
> the machine readable copyright format [2]?


Very, very, few translations are actively "maintained", despite the
best efforts of upstreams to hold string freezes and contact
translators to request updates. If a package has ~40 translations, only
a handful will be at 100% at any one release. Many translations are
effectively abandoned. Many translators do not complete the headers at
all, most do not keep the headers consistently updated.

It's not just the top level po/ files either, packages have help/po,
doc/po and debian/po and some have po/ as well as po-lib/ or po-bin/
and other subdirectories - expecting all of those to be constantly
updated in debian/copyright is insane!

(Not to mention the packages which have translations that don't use
gettext formats where there might be no declaration of the
translator's details whatsoever.)

Have you any idea how much work this would be for a package like
drivel, gnucash or gedit???

The only "solution" for this "problem" is for every package to drop
90% of translations. Should make the archive a whole lot smaller and
would be really helpful to our users, not.

It is not a problem, forget it and please, do some real work that makes
a release more likely, not less. (If you've got time to waste on this,
you certainly have time to fix some existing RC bugs to help out those
who want to but don't have time to do so.)


Neil Williams

Attachment: pgpEMp86Te6De.pgp
Description: PGP signature

Reply to: