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

Re: RFD: translated description with dpkg



(I'm not sure why this needs to be discussed on two lists, but
whatever...)

On 29-Aug-01, 10:28 (CDT), Steve Langasek <vorlon@netexpress.net> 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.



Reply to: