[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/doc/<lang> != wg15-locale



 Fabrizio Polacco wrote:
 > Firstly a premise:
 > ===
 > All this locale stuff will be activated in a user-oriented way by the
 > environment variable LANG, which interacts with a large variety of
 > programs, so we must be carefull not to break something deciding to put
 > "fr" in it rather than "fr_FR" or "fr_FR.88591". A different thing are
 > web exported documents in which a browser option should be set (although
 > I think that most browsers simply asks the server for "en" documents).
 > ===
 > 
 > We need a way to tell the system (dpkg?) that one (or more) particular
 > locale is installed, and thus all documentations, manpages, message
 > catalogs embedded in "normal" packages are to be installed in their
 > proper places.

I think that in a standard unix system, nearly all the locales description files
are installed (it's not so huge indeed...).
Each process in a system can run with a different $LANG value...
Their is no way to set a particular locale for a system (you can only set
a default $LANG value in /etc/profile).

 > The mandb upstream package (our man package) comes with messages in two
 > locales: de_DE *and* en_GB (I am actually trying to make them work :-)
 > as well as de_DE.88591 manpages.
 > 
 > An empty package or a basic one could be a good starting point. Packages
 > related to a single locale (like manpages.fr or linuxdoc-fr) should
 > depend on it, while other packages (like man, I mean the package, not
 > the program) could detect its presence to decide if the french stuff is
 > to be installed toghether with the english one.

There is absolutely no _need_ to have french locale description files
to read french html documentation like linux-doc-fr (HOWTO etc...).
There is no need to man package to detect if a "wg15-locale-fr-FR" has
been installed because everythings works automatically if you set $LANG.

 > Such a base package (named lang-fr or locale-fr) could be responsible
 > for installing all the various directories required for this locale
 > (like /usr/man/fr, /usr/doc/fr, /usr/lib/locale/fr, etc.) and the
 > symlinks that can be needed  (but no documents except its own).

dpkg already create/delete necessary directory when you install/uninstall a package... 
And do you really want to have plenty of very small locale-xx packages (28Ko for french
locale description files...)

 > I remember someone complaining because he had to install ALL the locales
 > to have the one he wanted.

Yes, but you can manually erase unused locale description files...

 > Thus I propose to put in each of these lang-base packages the part of
 > wg15-locale that belongs to that language (and the part common to all
 > languages in a general package) and to make this package a requisite for
 > installing things in that language.
 >
 > This will be easy to do for packages completely related to that
 > language, but not so easy for packages that has multi language documents
 > embedded in them.
 > This latter problem needs to be discussed deeply and maybe solved inside
 > dpkg.
 >
 > I know that it is easier to consider the system "english" based, but
 > considering "en" as any other locale (although the default one) imposes
 > only a small overload to the system, but will work without changes in a
 > localized system.

Yes, we may think about this general idea...
but... i think there is no direct relation between
locale description files stuff and specific langage documentation standard!

 > (I may be wrong on this point, because I didn't yet succeed in having
 > the locale work :-(   )

Just set LANG=<language>[_<territory>][.<character-set>][,<version>]

--
Christophe Le Bars - Email : clebars@teaser.fr, clebars@debian.org
011010ESPERANTO00  http://www.teaser.fr/~clebars  001ML01111100101
110DEBIAN011LINUX1111  Utilisez Linux Debian!  10010101001100GNU10




--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: