Trying to eliminate the initializing screen error that the “lf” file manager throws up I tried the suggestion on the Archwiki page about Locales and unset the LANG variable having created a locale.conf file in my .config directory and then reinitilalized with this command:
source /et/c/profile.d/locale.sh
Now “lf” starts with no complaints as I used the “en_GB.UTF-8” code instead of the “en_GB.UTF-8.UTF-8” code which for some unknown reason my installation started with. But on logging out I lose this reset.
I tried using the “localectl” command to reset my locales permanently, but it didn’t seem to work. I am reluctant to try too many other options I’ve seen as I used btrfs for the first time with encryption and using a special character for my password not in the same place on a default US keyboard I had an initial problem of decrypting until I tried the US keyboard for this one character. Somehow subsequent reboots seem to have fixed this as I can use my GB kdb layout to decrypt correctly now.
Perhaps I’m over-cautious as these locale variables may not affect default keyboard settings. But if someone could point me in the right direction, I’d feel safer modifying things.
the right place would be /etc/locale.conf for systemwide permanent setting …
and indeed adding the wanted locale with locale-gen after editing /etc/locale.gen …
if ISO … not ISO but calamares could do some unwanted locale stuff … i know it does so in some cases…
it would be in /etc/locale.conf and/or /etc/locale.gen …
Calamares adds the locales to /etc/locale.gen simply echoes it at the end of the file…
So, is it so difficult to insert them at the top of the file, or replace/enable the existing entries? …
It seems OP’s issue is coming from LF and nothing to do with proper system/user LANG setting.
I read some upstream LF issues and it looks like sourcing dot files is just non-existent, or problematic.
But let’s hear OP for more…
I do never tinker how calamares is doing this… but i see also no problem on adding it at the end… as it is more easy to find and will not change the rest…
I had a similar issue a while ago. I realized that on my install (sway edition, with ly display manager), it was /etc/profile.d/locale.sh preventing ~/.config/locale.conf from being sourced:
if [ -z "$LANG" ]; then
if [ -n "$XDG_CONFIG_HOME" ] && [ -r "$XDG_CONFIG_HOME/locale.conf" ]; then
. "$XDG_CONFIG_HOME/locale.conf"
elif [ -n "$HOME" ] && [ -r "$HOME/.config/locale.conf" ]; then
. "$HOME/.config/locale.conf"
elif [ -r /etc/locale.conf ]; then
. /etc/locale.conf
fi
fi
The outermost if makes it so locale.conf is only sourced if $LANG is unset - presumably it gets set somewhere earlier, but we don’t care about that if we have locale.conf. Commenting it out fixed the problem.
the same file is parsed from system, I guess, because the system has a LANG as well Maybe, the best would be to check for existing/non-empty value after checking for some locale.conf to source. Like this
Not necessary
if [ -n "$XDG_CONFIG_HOME" ] && [ -r "$XDG_CONFIG_HOME/locale.conf" ]; then
. "$XDG_CONFIG_HOME/locale.conf"
elif [ -n "$HOME" ] && [ -r "$HOME/.config/locale.conf" ]; then
. "$HOME/.config/locale.conf"
elif [ -r /etc/locale.conf ]; then
. /etc/locale.conf
fi
if [ -z "$LANG" ]; then
LANG="en_US.UTF-8" # or other value (C ?) as default
fi
Edited:
The file already has a fallback, so it is like @h4n1 said. The if-check could just be removed.
I hope this could be sent upstream in some way…
Absent yesterday, I was surprised by the discussion my query seems to have created. This really is a newbie-friendly forum and I thank all those for showing their interest. To be honest I ought to have put my query to the bbs.archlinux.org forum as I used the latest barebones Arch Linux installer to just have a base installation and then see by a sort of self-learning route if I could get to where my EndeavourOS install is on my other Thinkpad. As a relatively recent adopter of E-OS I ħave fallen under its charm because of its speed and general efficiency. So my strange initial setting of locales may have come from this.
In fact, my problem seems to have sorted itself somehow as “lf” has decided it now likes my character settings and works with no problem.
Just to answer @joekamprad here is my present output of locale -a:
C
C.UTF-8
en_GB
en_GB.iso88591
en_GB.utf8
en-GB.utf8utf8
en_US.utf8
My ouput of cat /etc/locale.conf
LANG=en_GB.UTF-8
My ouput uncommented at end of /etc/locale.gen
en_US-UTF-8 UTF-8
en_GB.UTF-8.UTF-8 UTF-8
I am still perplexed as to why the double “utf8utf8” line should still be there, but as the previous single utf8 line is correct so I think this is why “lf” now works. This is what gokecehan[https://github.com/gokcehan/lf/issues/578] stated when my issue was raised by someone else.
Perhaps I should add that I have now put a “locale.conf” file in my home ~/.config with the single line LANG=en_GB.UTF-8
One last question before I mark this thread as solved: Should I remove the line with the double UTF-8 mention from /etc/locale.gen?
…
the same file is parsed from system, I guess, because the system has a LANG as well 