I wasn't suggesting to include the localized docs in the
base packages. Only the C locale.
In JDS land, we package the l10n content separately in
SUNWgnome-foo-l10n packages and hand these over to l10n.
These are the community localizations and the l10n guys
work with the community to make sure they are good quality.
Then the l10n guys create[1] SUNWgnome-l10nmessages-<locale>
and SUNWgnome-l10ndocuments-<locale> packages that
include the l10n content for one locale from all GNOME
packages. So these are basically language packs.
Of course they have the same problem as SUNWsfman
in terms of having docs installed for programs/libs
that may not be installed.
I agree this is something to discuss with the l10n team.
Laca
[1] in practice, this is all happening in one step, in the
JDS builds.
On Thu, 2006-12-14 at 11:49 -0800, Danek Duvall wrote:
> On Thu, Dec 14, 2006 at 01:47:00PM -0500, Laszlo (Laca) Peter wrote:
>
> > > SUNWsfman (unchanged) Committed
> > > SUNWsfinf (unchanged) Committed
> >
> > Again, I know this has been like that since the dawn of SFW, and it
> > was obviously modeled from SUNWman. But I would argue that
> > if we create separate Solaris packages for each GNU package, then the
> > place of the manual pages is in those packages, together with the
> > artifacts that they describe. Same goes for info docs.
>
> That'd be nice and simple for some folks. The reason for the split is to
> ease localization. SUNWman gets sent to the L10N teams, who do their
> magic, and integrate SUNW<locale>man to the Solaris WOS. It reduces the
> amount of non-localizable stuff that's available in each package they have
> to deal with, and gives them fewer packages.
>
> Now, I don't know how they do their work. Perhaps sending them
> SUNWcoreutils (or whatever) is okay, but we should probably find out. I
> don't know whether their output from that would be a SUNW<locale>coreutils
> which would contain *just* the localized files, or whether it'd be
> everything (which would be bad if you wanted more than one locale on the
> machine).
>
> Perhaps we don't want Sun L10N teams to do the L10N work, which would
> sidestep the problem, but it'd be nice not to preclude that.
>
> Also, for anyone considering stuffing all the locales (as delivered by the
> component itself) into one package along with the non-localizable bits,
> this turns out to be bad idea. Bug 6384280 is one example (implicating
> problems with upgrade). Mary's talked to me a bit about this in the past,
> but I'm unable to find any mail beyond one talking about this bug. I can
> talk to Mary again. Mike S. may remember more, too.
>
> Danek
