On Sun, 23 May 2010 07:53:14 +0200 Julien Valroff <jul...@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. http://www.linux.codehelp.co.uk/?q=node/32 http://www.linux.codehelp.co.uk/?q=node/25 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]? NO! 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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpaCuNqcNBY3.pgp
Description: PGP signature
