No, it doesn't consider them as equivalent, they just have the same primary weight. So that, in first approximation, they sort the same.
If you look at /usr/share/i18n/locales/iso14651_t1_common (as used as basis for most locales) on a GNU system (here with glibc 2.27), you'll see:
<U0065> <e>;<BAS>;<MIN>;IGNORE # 259 e
2.3e-12 would be understood as 2 in a locale where the decimal radix character is , (as it is in most of the non-English speaking world including your de_DE.utf8) where the number would need to be written 2,3e-12.
You could do:
LC_ALL=C sort -grk2 < your-file
To force numbers being interpreted in the English style.
In the C locale (the only one you ...
The character ɛ is not equal to e, but some locales can gather these signs close together upon collation. The reason for this is language specific, but also some historical or even political background. For example most people probably expect that €uro currency comes close to Europe in dictionary.
Anyway to see what collation you are currently using run ...
If that's a zsh shell script, you can use the $langinfo special associative array in the zsh/langinfo module:
(that maps to the standard nl_langinfo(RADIXCHAR), see man nl_langinfo on your system for details; $langinfo[THOUSEP] for the thousand separator).
In a bash script (would also work in zsh), you ...
For any program that simply needs to read the environment variable settings, /etc/locale.conf and /etc/environment are basically the same; in a very simplified embedded system, you could omit /etc/locale.conf and place any required locale variables to /etc/environment instead.
The difference is mainly in how to deal with updating the files.
PuTTY ignores the VT100 line-drawing controls when it handles UTF-8. ncurses can be told that by setting the NCURSES_NO_UTF8_ACS environment variable (or using the corrected putty terminal description).
Setting TERM to "xterm" never did work with PuTTY; for a longer answer see this
Ok, I have found the answer to my question, I believe that it can be applied to other languages than Portuguese.
The LightDM keyboard layout to Portuguese is done with this command:
localectl set-x11-keymap pt
I did this as root, and I think it is the right way, but you can do it has a normal user too, I believe.
I've found this on Fedora forum.
One possible explanation is that that en_US.utf8 locale is not available on your system.
You can use locale -a to get the list of available locales, locale -a | grep en_US for the list of US English ones.
If that locale was installed, LC_ALL=en_US.utf8 locale -k LC_NUMERIC would output something like:
I'll be using Western examples as to avoid Chinese politics and to avoid my lack of knowledge of Chinese language 🙂.
I'll be using some characters that may not be correctly rendered in your computer if you lack a font that covers them. It is not a limitation of the Unicode or of this site HTML, but a limitation of your computer's fonts [a] (look at the end ...
I managed to reproduce this problem on Ubuntu 17.10 (glibc 2.26) and on Ubuntu 18.04 (glibc 2.27), but it seems to be fixed on Ubuntu 18.10 (glibc 2.28)
The problem is with the localedata, more specifically the LC_COLLATE data for en_US.utf8 (actually, that collation data comes from an ISO 14651 file which is included in most locales, so it probably affects ...
If your regex engine supports them, you can essentially just replace the character e by its equivalence class [[=e=]]
$ grep -m 10 '[[=e=]].*t.*[[=e=]].*t.*[[=e=]]' /usr/share/dict/french
See Collating Sequences and Character ...
You're missing a step. You need to set a Compose key first. For example, to set the right Alt key as the Compose key:
setxkbmap -layout us -option compose:ralt
Press Compose (on my keyboard it's labelled Alt Gr) and release it.
Press the sequence of keys that correspond to the letter/diacritic you want. These are sometimes intuitive, sometimes not. ...
You need to set your locale to the british one for the time display LC_TIME="en_GB.UTF-8" to get your calendar to start on monday.
You can see the configuration in that post here
Set it in the /etc/default/locale depending on your system. /ect/locale.conf
Use ncal -M (the -M option is only available for ncal):
Mo 7 14 21 28
Tu 1 8 15 22 29
We 2 9 16 23 30
Th 3 10 17 24 31
Fr 4 11 18 25
Sa 5 12 19 26
Su 6 13 20 27
The man ncal:
-M Weeks start on Monday.
Using cal command , you need to change the line under:
That most likely refers to locales having uppercase and lowercase characters ordered in alternation, instead of first one, then the other:
$ echo "$LANG"
$ touch a A z Z
A Z a z
$ bash -c 'echo [a-z]'
a A z
However, the appropriate character class works:
$ bash -c 'echo [[:lower:]]'
But might also match more than just a to z:
You're right that assigning the LC_* shell variables does cause bash to call POSIX setlocale() for the corresponding category with the value of the variable whether they're exported or not. For LANG, it calls setlocale(LC_ALL, thevalue) followed setlocale(LC_*) again for all the LC_* variable. For LANGUAGE, it doesn't do anything.
Now, bash is the shell of ...
As suggested by jamespharvey20 on IRC, I just changed LC_TIME to another locale. I set it in /etc/locale.conf:
$ cat /etc/locale.conf
I also exported this value of LC_TIME in my shell profile, to avoid having to restart (I couldn't figure out how to get Systemd to reread the locale.conf). This seems a bit hacky but I think it'...
What that locale: Cannot set LC_ALL to default locale: No such file or directory message tells you is that one of the locales you're trying to use doesn't exist. It's not about the $LC_ALL environment variable, locale is just reporting an error when the setlocale(LC_ALL, "") call it does to initialise localisation based on environment variables returns NULL ...
Changing users’ language in .bashrc only influences their shells, as you’ll see in a terminal session. To change their desktop environment’s language, you need to configure the desktop environment for each user. In some cases, that can be done from the login screen (see below). In other cases, language configuration is done in the desktop preferences.
If you choose the expert installer you can add one or more additional locales and then choose the default locale, but you need to change your LC_XXX variables manually as described by Stephen Kitt.
Regarding the locale settings this is the same as using the default installation method and running sudo dpkg-reconfigure locales afterwards.
The selections ...
locale-gen does not take any command-line arguments. Instead, it reads /etc/locale.gen for a list of locales to generate.
Edit /etc/locale.gen to uncomment the locales you want, and then run locale-gen again.
Or if there are no commented-out lines in /etc/locale.gen, find a list of supported locales and copy from there; in Debian (and probably related ...
The solution was to change the incorrect locale settings. Initially when I did set up my locales I enteret the same locale name that was found in /etc/locale.gen, which was sv_SE.UTF-8.
When you uncomment the locale of your choice in /etc/locale.gen you have to run locale-gen which is a program that reads locale.gen and generates localisation files. The ...
Short version: After setting the locale in KDE's settings you have to manually double-check whether the set locale actually exists.
As it turns out KDE doesn't care what locales are actually installed on your system. It lets you use non-existing locales without any warning, which was exactly the case here. The locale en_DE.UTF-8 didn't exist. This can be ...
Programs have to be written to respect the locale. For example if I write
and I run it with a french locale, I do not expect it to output bonjour
The timezone has nothing to do with the locale setting, English is spoken all over the world, but not all the world has the same time as London. Set the TZ variable to specify the timezone,...
According to your question, you are looking for /etc/local.conf, however, the configuration is within /etc/locale.conf with a final "e". If it not exist you and you have writing permission on /etc/, then you can just:
echo LANG=en_US.UTF-8 > /etc/locale.conf
and that would do it, of course this is an example just with language, you can do what ever ...
The Linux kernel tracks seconds past 1/1/1970 00:00:00 UTC, commonly called "epoch time". There's some kludges around leap seconds, but that's about it.
There's a second kludge for how this time value gets initialised from the hardware real-time clock (RTC) at boot time because the RTC may not be set to UTC. (Thanks, Microsoft).
Timezones, locales and ...
Get the 13-CURRENT base.txz on your system, extract it to where convenient.
Copy ./usr/share/locale/C.UTF-8 to the root system's /usr/share/locale using cp -R command.
In sh execute export LC_ALL=C.UTF-8, and you'll be able to use the C.UTF-8 locale.
Note: Setting locale like this did not cause the SSH to be closed as described in the linked question, so ...