pchllck at nexgo.de
Sun Jul 20 09:02:57 PDT 2003
[20.07.2003] Sam Halliday <-- :
> surely there should be NO localised .mo files in /usr/lib/locale, but only in
> /usr/share/locale. that is where all my locales are kept (for programs as well
> as glibc).
Translations are not "locales", they are translations.
> in fact /usr/lib/locale does not even exist unless you make it yourself or ask
> glibc to regenerate all the locales, which you can achive yourself by typing
> something like:
> mkdir /usr/lib/locale
> localedef -i en_GB -f ISO-8859-1 en_GB
> which will create the file /usr/lib/locale/locale-archive AND NOTHING ELSE
wrong, this only affects glibc version from and with 2.3.1, versions
before that are keeping locales in lang_TERR.charset directories with
each category being a file on its own. And newer ones can easily be
forced to do the old style.
> containing all your localised glibc stuff (individual files, i understand read
> the .mo files directly from /usr/share/locale).
no, /usr/share/locale is translation and those files are read when
translation is requested. Individual files are now simply all put into
one big archive file, that's all.
> i always delete anything else lurky in /usr/lib/locale
> i test my en_GB setup by first typing `ls' and seeing if CAPITALS affect the
> sorting order,
For en_GB it might not matter but a correct ls output needs LC_COLLATE
set to the locale, sorting does not only mean *if* but *how* capitals
> and then i check the messages by `ls --vert` (which does not
> exist) to see if "unrecognised" is spelt the british or american way.
For difference between US/EN the quickest way, for other languages just
`ls nothing`, provided you did not by chance have a "nothing" there ;)
Erika ...---...: pacholleck at nexgo dot de
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support