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
