Locales (LC_MESSAGES) aren't working for certain packages

[rypervenche]

Describe the bug

When using the Finnish locale, certain packages seem to not respect the LC_MESSAGES for that language. I haven't tested many other locales yet or a lot of different packages, but I did notice a few that this seems to be the case with. I'm also not sure if this is an issue with how some packages were built or with something in the NixOS environment. These translations work on my Gentoo machines with the same package versions. I'm also very new to NixOS, so please forgive me if I've missed anything important.

Steps To Reproduce

Steps to reproduce the behavior:

1. Set locale to Finnish in configuration.nix: i18n.defaultLocale = "fi_FI.UTF-8";
2. As a non-root user type su -. Instead of saying "Salasana: ", it says "Password: ". I've tested this with "fr_FR.UTF-8" as well and verified that the source code does indeed have translations for these two languages.
3. A GUI package that I also noticed this with is blueman-applet from the blueman package. The tray menu should be completely translated, but is completely in English for me.

Expected behavior

Text should be translated into the locale that I am using.

Additional context

I can see that the LC_MESSAGES files for these two programs exist and contain the translations in the .mo files.

rypervenche@jodi:/nix/store$ fd blueman | rg 'fi/LC_MESSAGES'
zfmrng2pwdxqzs3cx5vi9qwcyy25i3zy-blueman-2.3.5/share/locale/fi/LC_MESSAGES/blueman.mo
lwmgh1f947ammhmslmys3qxx1qm11yd9-blueman-2.3.5/share/locale/fi/LC_MESSAGES/blueman.mo

rypervenche@jodi:/nix/store$ fd util-linux | rg 'fi/LC_MESSAGES'
v54ban0gh2iv2giy9kbl7mkckp56mldy-util-linux-2.39-lib/share/locale/fi/LC_MESSAGES/util-linux.mo
c67kb57rfi56aibv5xdb34wgbndb6sdl-util-linux-2.38.1-lib/share/locale/fi/LC_MESSAGES/util-linux.mo

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.45, NixOS, 23.05 (Stoat), 23.05.2753.3fe694c4156b`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.5`
 - channels(root): `"nixos-23.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[rypervenche]

It looks like this may be an issue with programs that use gettext with po/mo files?

[trofi]

I think for su it happens because shadow has different code paths for pam-style and non-pam authentication:

$ nix build --impure --expr 'with import <nixpkgs> {}; shadow.su'; LANG=fi_FI.UTF-8 LANGUAGE=fi ./result-su/bin/su
Password:
su: Authentication failure

$ nix build --impure --expr 'with import <nixpkgs> {}; shadow.su.overrideAttrs (oa: { configureFlags = oa.configureFlags ++ ["--without-libpam"]; })'; LANG=fi_FI.UTF-8 LANGUAGE=fi ./result-su/bin/su
Salasana:
su: Authentication failure

In case of PAM I think it's up to libpam modules to localize the messages. And it gets loaded from the wrong location:

$ LANG=fi_FI.UTF-8 LANGUAGE=fi strace -y -f -olog su
Password:
su: Authentication failure

$ fgrep Linux-PAM log
1180126 openat(AT_FDCWD</tmp>, "/nix/store/ibp4camsx1mlllwzh32yyqcq2r2xsy1a-glibc-2.37-8/share/locale/fi/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

[trofi]

I think normally the locale directory is passed to gettext calls via bindtextdomain(): https://github.com/shadow-maint/shadow/blob/master/src/su.c#L1008

    (void) bindtextdomain (PACKAGE, LOCALEDIR);

I see one for su, but not for linux-pam (but maybe it's well-hidden). I would guess that for Gentoo everything is stored in /usr/share/locale/fi/LC_MESSAGES/*.mo and is always visible.

[trofi]

As a random example of a library that does call bindtextdomain() at init is gnutls: https://github.com/gnutls/gnutls/blob/master/lib/global.c#L269

#ifdef HAVE_DCGETTEXT
    bindtextdomain(PACKAGE, LOCALEDIR);
#endif

I think linux-pam should adapt the same approach.

[trofi]

Asked linux-pam maintainers in https://github.com/linux-pam/linux-pam/issues/602 if they are open to add a form of lookup path.

[trofi]

Proposed pam change against nixpkgs as: https://github.com/NixOS/nixpkgs/pull/249487

[rypervenche]

This has been resolved with #249487. Thank you.