On 01-09-06 Nick Phillips wrote:
> On Thu, Sep 06, 2001 at 07:47:26PM +0200, Christian Kurz wrote:
> > > > upstream packages because they are not part of a package? The
> > > > translation of the error messages and other messages of a program belong
> > > > to the package of it.
> > > That depends on whether you're distributing one package or thousands.
> > Why do make this dependant on the number of packages? I think that using
> > some count like you do, is a bad thing.
> Because if you're only distributing one package or small group of packages
> (say, KDE), then your focus is making the translations available for all the
So you want to compare packages from an upstream with packages created
by either someone or a team for a distribution?
> people who use that package, whether or not the particular distribution
> they got it from has infrastructure to support translations. Hence it makes
> sense to put the translations in the package in that case.
> If on the other hand you are one of those distributions, distributing
> all sorts of packages, some of which have upstream translations, some of
> which don't, some of whose maintainers are able and willing to spend time
> on translations, some of whose maintainers aren't, then it doesn't make
> sense to set yourselves up in such a way (translations always living in
> packages) that translations will only be available when the maintainer
> does work on them.
Which creates the situation, that packages in debian will on the one
hand be different then the one you can get from the upstream and on the
other hand it's a violation of our social-contract:
| software will be widely distributed and used. We will feed back
| bug-fixes, improvements, user requests, etc. to the "upstream" authors
| of software included in our system.
So if we correct wrong translation or create a new translation, then we
shall send it to the upstream and inform them. With your suggestion
above, this will only happen, if either the translator is doing this
task also or if the maintainer is taking care of the translation. In all
other cases, where the maintainer is not taking care of the translation,
we'll have a nice violation of that statement. And since the maintainer
is the contact to the upstream and responsible for the debian package,
he shall be involved in the translation.
Splitting translation out of upstream packages is in my opinion a bad
thing and should never be done.
> > > But if we want to be, and are, able to easily add extra translations, or
> > > override poor-quality upstream translations (all without causing hassles for
> > > maintainers), then why not?
> > Because for example I would prefer to be informed if any of my packages
> > has a bad upstream translation and some has better one for me. Then I
> > can forward and discuss it with the upstream and he can include it maybe
> > in the official upstream sources. That way we wouldn't only improve the
> > translation for people using debian, but also for people who are using
> > some other free operating system and the upstream package.
> Fine, no-one is saying that you shouldn't be able to arrange to be notified
> when a particular package has a translation made available.
And how do you propose to integration this notifications? According to
your statement, everyone can update the translation without having to
hassle with me and that's the point which makes me sad.
Christian
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Attachment:
pgphlvF6awmCO.pgp
Description: PGP signature