On Wed, 29 Aug 2001, Michael Bramer wrote: > - No package maintainer can't speaking all languages. He can't > check the translation, he can't improve the translation, he only > add blindly the translation in the package source. This is > unneeded work for the maintainer.
I don't think this is a good reason for keeping maintainers out of the loop. I'm wary of the attitude that "the maintainer can't help us, he doesn't speak our language and doesn't care about translations". Most developers are interested in making their packages as good as possible, and making sure that they serve the needs of their users, and I think it's important that translators recognize this and take advantage of the very people who can be the best advocates for the individual packages. Also, many maintainers may not speak a language well enough to do their own translations, but they may recognize when a translator has misunderstood and be able to help the translator in this way. I would like to see a solution where this sort of collaboration is encouraged. I'm not suggesting that all translations must be approved by maintainers, and that maintainers must take action before the translation is available; this can definitely lead to delays. I agree it may be a better technical solution to use detached translations, but I think whatever solution is found should at least include notifications to the package maintainer. Personally, I wonder if the /best/ solution would be similar to what we have in the archive now for overrides file: create a central repository with all of the translations, used by the archive, so that there are no delays in making the translations available; but submit the translations to the maintainer, so that they can also be included in the .deb. > - The deb package is growing with the number of translations > added. The extra translations are going to take up space /somewhere/ in the archive. Are you concerned about this specifically because of download times? Because it takes up space on CDs, meaning resellers have to either put fewer packages on a disk or rebuild the packages themselves, taking out the translations? This latter point seems persuasive to me, although I wonder how much space these descriptions will really occupy in each package. We do have debconf translations in the packages already, after all. How many packages would be pushed off of CD1 if we made space for (highly compressible) translations? One? Two? Or would the translations fit in the spaces between? > - unneeded translation on the system. > Normal a system have only one (or maybe some) system admins (aka > root's). The all speach the same languages (or only some). A > german root user don't need japanese package description. He > only need the german and (as fallback) the english description. I don't see where having the translated descriptions within the .deb file means they must also take up space on the end-user's system. If they're in the .deb, they take up space in the archive, and they take up bandwidth when downloading; but when the package is installed, there's no reason to keep descriptions other than the ones the administrator has asked to keep... > - if you put all translations in the same file, you'll have > encoding problems But this is a problem that must be solved anyway, because we currently do this with debconf templates! > But you don't believe, that the dpkg source code changes are small? > Show the attachment. Martin Quinson <[EMAIL PROTECTED]> have > patch the dpkg source code and now we have a dpkg with translated > description support. This is only a -9/+30 patch! you see the patch is > pretty small. I must say that I'm pleased and impressed by this. > If the translated descriptions are store in > /usr/share/locale/<lang>/LC_MESSAGES/dpkg-desc.mo and you have patch all > outputs in dpkg and dpkg. > Maybe somebody will now say: "But some users don't get all packages > from debian project, there are some privat deb archives, Progreny, > ..." > This is not a real problem. We can collect more po files in one dir > (maybe /var/lib/dpkg/dpkg-desc/<lang>/) and generate one dpkg-desc.mo > file from this *po-files. Ah. Until I read this last part, I was going to argue for a name such as 'debian-desc' instead of 'dpkg-desc', but this makes perfect sense to me. :) Cheers, Steve Langasek postmodern programmer
