Locales should be specified in uppercase with canonical dashes

[dbn.lists@…]

It is not entirely clear on the Bash Shell Startup files page [1] that you really want to specify the charset of your locale in uppercase with the canonical dashes. Alexander explained that some programs such as Xorg [2] expect this format. Right now the page just says that some applications like Xlib won't recognize your locale if you don't follow the instructions. It really needs one more sentence that the uppercase/canonical dash format is important.

[1] ​http://www.linuxfromscratch.org/lfs/view/development/chapter07/profile.html [2] ​http://linuxfromscratch.org/pipermail/lfs-dev/2006-June/057532.html

[bdubbs@…]

Fixed at revision 7654.

[alexander@…]

Reopening: the wording is wrong.

It is not correct that "Xlib expects that the character map will be listed in uppercase notation with canonical dashes". Xlib expects the whole locale name to match (case-sensitively) one of the lines in its data files. These data files either don't have the charmap part at all in the locale name, or have it in uppercase and with dashes in the proper places.

It is the first case (no dashes at all) that is attempted to be addressed by removing the charmap part, rather han the second one (uppercase and with dashes in the proper places).

[dnicholson@…]

Yes, these are two cases and that sentence is probably wrong. However, it is Beyond LFS to start discussing what's in locale.alias files installed by Xlib. I'll try to think of wording that makes this paragraph appropriate. Don't hesitate if you think of anything.

[bdubbs@…]

Reworded the explanation of the Xlib locale/charmap issue.

Fixed at revision 7667.

If there are additional issues with this wording, don't just say that it is wrong. Give what you think is the correct wording.

[alexander@…]

Maybe "It is also possible" should be replaced with "In other cases, it is possible" (but I don't insist). Also please remove "character map" from "does not exactly match one of the character map names".

However, my overall impression is that the new text is neither better nor worse than the original that existed before opening this bug (thus it is either "not fixed" or "invalid", depending on your agreement or disagreement with the original, rather subjective, description). It may be a good idea to generalize the example, as follows (the text is intended to go instead of the current text from "Replace <ll> below"):

---

Locale names have the following form: ll_CC.charmap@modifiers, where ll is the country name abbreviation (in lower case) and CC denotes the language. The charmap specification and modifiers (such as @euro) may or may not be present. <!-- don't say "are optional", because this can be misinterpreted as "en_GB and en_GB.UTF-8 are the same thing" -->

The list of all locales supported by Glibc can be obtained by running the following command:

locale -a

Some packages beyond LFS attempt to parse the locale name according to their own ad-hoc rules, or compare it against a fixed list of strings. Such packages may not recognize the locale name (and thus misbehave, silently or not) even if Glibc understands it properly. One example is the X library (part of the X Window System), which outputs the following error message if the locale does not exactly match one of the names in its internal files:

Warning: locale not supported by Xlib, locale set to C

The intention of the instructions below is to normalize the locale name that you got from the "locale -a" command output, in order to minimize the chances of applications not recognizing it, while still preserving the idea Glibc has about your locale. They work in most cases, but should nevertheless be treated as a "rule of thumb". In the case of doubt, find out how other Linux distributions spell the locale name, and copy that instead of following the instructions below.

It has been found that the charmap part of the locale, if present, should be in upper case, and with dashes in proper places. To find the canonical form of the charmap, run the following command:

LC_ALL=your_locale locale charmap

E.g, for the “de_DE.iso885915@euro” locale, the above command will print:

ISO-8859-15

Thus, it is safer to write the name of this locale as de_DE.ISO-8859-15@euro. It is even better to drop the charmap sprcification completely if this doesn't change Glibc's idea about the charmap. Indeed, the "LC_ALL=de_DE@euro" command still prints "ISO-8859-15", thus it is the safest to write the locale name as "de_DE@euro".

It is important that the locale found using the heuristic above or from another Linux distribution is tested prior to it being added to the Bash startup files:

LC_ALL=<locale name> locale language LC_ALL=<locale name> locale charmap LC_ALL=<locale name> locale int_curr_symbol LC_ALL=<locale name> locale int_prefix

The above commands should print the language names, the character encoding used by the locale, the local currency and the prefix to dial before the telephone number in order to get into the country. If any of the commands above fail with a message similar to the one shown below, this means that your locale was either not installed in Chapter 6 or is not supported by the default installation of Glibc.

locale: Cannot set LC_* to default locale: No such file or directory

However, if you followed the instructions above instead of copying the locale name from another distribution, this cannot happen. If this does happen, you should either install the desired locale using the localedef command, or consider choosing a different locale.

Once the proper locale settings have been determined, create the /etc/profile file:

---

So you now have three texts to choose from: the text that existed before taking actions against this bug, the current text, and the text above.

[alexander@…]

whoops, ll denotes the language and CC denotes the country