Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

locale settings ignored #278

Closed
Phundrak opened this issue Mar 19, 2021 · 14 comments · Fixed by #517
Closed

locale settings ignored #278

Phundrak opened this issue Mar 19, 2021 · 14 comments · Fixed by #517
Labels
bug This issue or pull request discusses a bug needs review This issue or pull request must be confirmed/reviewed

Comments

@Phundrak
Copy link

Phundrak commented Mar 19, 2021

When I launch any session from ly (tested in my case with a shell session and Awesome), the locale set in /etc/locale.conf is not respected and all locales are set to en_US.UTF-8.

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

However, if I manually create a new session from any available TTY (such as TTY1), I get the correct output as set in my locale configuration, be it in the TTY console or in a graphical session started with startx.

$ locale
LANG=en_DK.UTF-8
LC_CTYPE="en_DK.UTF-8"
LC_NUMERIC=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LC_COLLATE=C
LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES="en_DK.UTF-8"
LC_PAPER=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_ALL=

For the record, here is my /etc/locale.conf file:

LANG=en_DK.UTF-8
LC_COLLATE=C
LC_NAME=fr_FR.UTF-8
LC_NUMERIC=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_PAPER=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8

I am currently running an up-to-date Arch Linux system with the package ly 0.5.2-2, and the output of ly --version is Ly version v0.5.2.r0.g1523d08.

I tested if a workaround was possible with a per-user locale config in $XDG_CONFIG_HOME/locale.conf (in my case $HOME/.config/locale.conf) as instructed on the Arch Wiki, but to no avail, I still get the same output when running locale.

@Phundrak Phundrak changed the title locale settings ignored by ly locale settings ignored Mar 19, 2021
@negativeExponent
Copy link

i wonder if this is whats causing your issue:
https://github.com/Phundrak/dotfiles/blob/master/.etc/ly/config.ini#L38

try changing lang = en to lang = fr from your /etc/ly/config.ini (assuming you are using the config from your dotfile)

@Phundrak
Copy link
Author

My ly config from my dotfiles is not up to date with my actual ly config. The only meaningful line I have in my /etc/ly/config.ini is

blank_password = true

The rest is either comments or blank lines. So that is unfortunately not the source of this issue.

@negativeExponent
Copy link

negativeExponent commented Mar 20, 2021

apparently, "lang" in config only affects language on ly's UI.

somewhat semi-related:
i too have issue with ly when LANG is null causing login to fail. Im not entirely sure systemd sources /etc/locale.conf before the shell starts but on the distro i use, /etc/locale is not source untill my shell starts (meaning after ly's login)

#216 (comment)

you can for the mean time source out the /etc/locale.conf as what the wiki already showed you to override whatever locale is being set.

ok, just installed vanilla arch, and indeed, LANG is never set until successful login, hence /etc/profile.d/locale.sh will be able to source /etc/locale.conf correctly.

LY on the other hand, somehows sets LANG to en_US.UTF-8, so when /etc/profile.d/locale.sh is called, it skips sourcing /etc/locale.conf due to LANG already set. Maybe one of the modules used in ly is setting it, because does not directly sets LANG variable.

@robertjk
Copy link

robertjk commented May 1, 2021

I have similar problem on Arch Linux. This is my /etc/locale.conf:

LANG=pl_PL.UTF-8
LC_MESSAGES=en_US.UTF-8

When I log into my system using ly I have the following:

$ locale
LANG=pl_PL.UTF-8
LC_CTYPE="pl_PL.UTF-8"
LC_NUMERIC="pl_PL.UTF-8"
LC_TIME="pl_PL.UTF-8"
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY="pl_PL.UTF-8"
LC_MESSAGES="pl_PL.UTF-8"
LC_PAPER="pl_PL.UTF-8"
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT="pl_PL.UTF-8"
LC_IDENTIFICATION="pl_PL.UTF-8"
LC_ALL=

So LC_MESSAGES value is set to pl_PL.UTF-8, even though it should be en_US.UTF-8.

LY on the other hand, somehows sets LANG to en_US.UTF-8, so when /etc/profile.d/locale.sh is called, it skips sourcing /etc/locale.conf due to LANG already set. Maybe one of the modules used in ly is setting it, because does not directly sets LANG variable.

Exactly - seems the problem is caused by ly setting LANG environment variable by itself, instead of waiting for it to be set later by /etc/profile.d/locale.sh.

Is that a bug to fix, or does that simply result from Arch doing things differently to other distributions?

@nullgemm nullgemm added bug This issue or pull request discusses a bug needs review This issue or pull request must be confirmed/reviewed labels Apr 25, 2022
@valentino-sm
Copy link

valentino-sm commented May 15, 2022

I ran into the same problem

However I commented that line and everything works.

ly/src/login.c

Line 223 in 78e2fd1

setenv("LANG", lang ? lang : "C", 1);

It remains to find out where LANG variable comes from.

@negativeExponent
Copy link

This should not have been merged because doing so will ignore system-configured /etc/profile locale as I've already stated above. Any system not using en_EN as.local will have some issues.

@Cavernosa
Copy link
Contributor

I'm having the same issue on Artix openrc. The only file defining LANG env vars is /etc/profile.d/locale.sh which runs after login.
It might be possible to mimick this file's behaviour (like sddm did)

@MaximMaximS
Copy link

Does any1 have a temporary fix? This is the only thing that's preventing me from using ly...

@Cavernosa
Copy link
Contributor

Cavernosa commented Jul 17, 2022

Does any1 have a temporary fix? This is the only thing that's preventing me from using ly...

valentino-sm commented on May 15
I ran into the same problem
However I commented that line and everything works.

ly/src/login.c

Line 223 in 78e2fd1

setenv("LANG", lang ? lang : "C", 1);

valentino-sm's fix worked for me as well.

@valentino-sm
Copy link

@negativeExponent if the issue is arch-specific there could be the workaround in AUR package like:
sed -i "/setenv(\"LANG\"/s/^/\/\//" src/login.c

@hnorkowski
Copy link

This issue is still a thing. I am having it on arch with Ly version v0.6.0.r0.g1c2be47.

@yCocoJamboo
Copy link

Unfortunately, the problem is current.

Name            : ly
Version         : 0.6.0-1.1

@cameloper
Copy link

Since this issue still persists I thought I'd explain how to apply @valentino-sm solution easily on arch in case anyone needs it:

  1. Clone the package repo from Arch using the pkgctl tool
pkgctl repo clone --protocol=https ly
cd ly
  1. Change the build() method (line 41) as follows:
build() {
    sed -i "/setenv(\"LANG\"/s/^/\/\//" $srcdir/ly/src/login.c
    make -C "$pkgname"
}

so basically add the sed line

  1. Build and install the package using makepkg
makepkg -si

Of course one could write a patch for this or automate it in some other way but it doesn't look like ly receives updates that often so it souldn't be too much work.

P.S. I didn't explain much about the steps but I think becoming familiar with arch build/packaging system is pretty important anyway so I'd suggest taking a look at the links if you don't know what the commands do

@sluedecke
Copy link

sluedecke commented Mar 18, 2024

Since this issue still persists I thought I'd explain how to apply @valentino-sm solution easily on arch in case anyone needs it:

Thanks @cameloper and @valentino-sm, this solution works for me just fine.

Arch Linux

@AnErrupTion AnErrupTion linked a pull request Apr 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue or pull request discusses a bug needs review This issue or pull request must be confirmed/reviewed
Projects
None yet
Development

Successfully merging a pull request may close this issue.