> > 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. > > You can arg the same in the other way: an L-speaking user don't need > all the text translations for programs that they'll never installed.
Unless you make "localisation packages" work differently: when you install them, only the stuff relevant to the (ordinary) packages that are already installed is extracted. (I had imagined them working like this, somehow - mechanism to be defined later!) > I don't think we can find a general solutions for everything. I prefer > to see all localisations for a package in the same package until it > get too big. After that, the maintainer can decided to subdivide the > package, just like the package-doc.deb scheme. That sounds like a pragmatic, short-term solution, but I want to have a better idea of what the best way of doing things is, long-term, so that I can give myself a sense of direction. So I hope that people will criticise my ideas in principle rather than just reject them as not practicable in the short term ... I think that a system of "localisation packages" might encourage people to produce localisations and encourage package developers to internationalise the packages. People are discouraged from produceing localisations by the overheads involved (understanding how to do it in a package-by-package way) and the delay (if you get a localisation into an upstream source it takes a long time for it to be available to ordinary users who buy a distribution - a localisation package could reach users much quicker). Edmund
