(I'm not sure why this needs to be discussed on two lists, but whatever...)
On 29-Aug-01, 10:28 (CDT), Steve Langasek <[EMAIL PROTECTED]> wrote: > 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. Quite bluntly, from my point of view, the best way to ensure high quality translations for my packages is to keep me out of the loop. I know enough Spanish, Italian, and French to get by in a restaurant, but I don't think that's going to help me evaluate package description translations. If someone submits a bug report about the quality or content of a translation, I have absolutely no way to judge it. If I change a description, am I supposed to wait until all the translations have been updated? Who do I go to for each one? If I don't wait, then the translations are wrong. Also, I've very little interest in uploading a new version just because a particular translation has been updated. As a user, I'm going to extremely pissed if gcc or emacs or tex is updated just to get a new long description translation. > > 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. Sure, notify away. I can always procmail them to /dev/null (not because I object to translation, but because I *cannot* provide any useful judgement or critique of them.) I *really* don't think the translations belong in the debs. I think the current technique of generating alternative package files solves the problem, and minimizes the download and space occupations. Mirrors and CD makers can choose which versions (e.g. languages) they want to keep. Translations can be stored in a central location, and updated as needed. Yes, it would be a good thing if they were accessible to the package maintainers so that those maintainers who could provide useful input could, in fact, do so. I also think the standalone .deb argument is pretty bogus. Setting up an apt-able Packages file is easy. If someone cares enough about their "local" packages to create/maintain translations, then the additional effort is pretty small. Also note that the minimal case (just the local langauge) can be supported *now* simply by using that language in the control file. Steve in "Ugly American" mode.
