Re: Package Descrption I18N Proposal

[Edmund GRIMLEY EVANS <edmundo@rano.demon.co.uk>]

I suppose a basic question is whether you want

(a) to put all the localisations for a given package into that package,
or,

(b) to make a "localisation package" that localises a whole set of
packages.

Debian is unlikely to ever need a localisation for more than a small
proportion of the several thousand human languages known to science,
but even if only a hundred languages are involved, method (b) seems a
lot less frightening than method (a).

So, I'm trying to argue that, ideally, language-specific stuff (and
that ought to include English-specific stuff) shouldn't go into a
package called prog_1.2.3.deb, say, at all. An <L>-speaking user should
install prog_1.2.3.deb and <L>_X.Y.Z.deb to get an <L>-speaking prog.

There's the problem of what to do if the localisation package is older
than one of the packages that it applies to. A solution would be for
the package to contain symbolic identifiers that it spits out instead
of the localised text when the localised text is not available. These
symbolic identifiers could be the English text - as in GNU's gettext -
but I would argue that it would be better, at least in many cases, for
them to be short and fixed, like variable names, because that way you
save disc space for people who don't need English, and it allows a
maintainer to improve the wording of an English message without
breaking all 99 other localisations.

If you treat package descriptions this way, then they don't belong in
packages at all. The package should only contain a version number for
the package description that enables apt's successor to look up whether
it has an up-to-date text in the user's preferred language.

Does what I'm saying sound right, in principle?

Edmund