Re: Package Descrption I18N Proposal
> > 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
Reply to: