Output in non-configured language when calling lxc on localized system

(I’m running Gentoo Linux with kernel 5.4.179 and glibc 2.34.)

Following a recent system update (which included updates to glibc) I have been observing very strange localization behaviour when executing lxc.

I have a system with a German locale:

$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

But when using lxc, I get French output:

$ lxc list
+---------------+---------+----------------------+-----------------------------------------------+-----------+-------------+
|      NOM      |  ÉTAT   |         IPV4         |                     IPV6                      |   TYPE    | INSTANTANÉS |
+---------------+---------+----------------------+-----------------------------------------------+-----------+-------------+

And occasionally even mixed language output:

$ lxc launch ubuntu:focal ubuntu-1
Erstelle ubuntu-1
Démarrage de ubuntu-1

What could be causing this?

That’s indeed pretty odd. I just looked at the de.po file that makes the German translation and it’s correct. STATE isn’t translated so should cause a fallback to STATE whereas your system seems to fallback to the fr.po value.

I don’t see anything on our side which would cause this on our end so it’s most likely some issue with libc (which provides the gettext functions) or with the way the Gentoo package ships the .mo for LXD.

You may want to poke at the .mo on your system and grep for the french strings in the German file, just to make sure they didn’t get merged in there at package build time or something.

The .mo looks clean (if incompletely translated):

$ strings /usr/share/locale/de/LC_MESSAGES/lxd.mo
%s (%d more)
%s is not a directory
%v (interrupt two more times to force)
(none)
ALIAS
ALIASES
ARCHITECTURE
Accept certificate
Action (defaults to GET)
Add new remote servers
Alias name missing
Auto update: %s
Bytes received
Bytes sent
CREATED AT
Columns
Copy aliases from source
Could not create server cert dir
Created: %s
Creating %s
DESCRIPTION
EXPIRY DATE
FINGERPRINT
Invalid source %s
Invalid target %s
Make image public
More than one file to download, but target is not a directory
Remote admin password
Server certificate NACKed by user
Set the file's gid on push
Set the file's perms on push
Set the file's uid on push
Project-Id-Version: LXD
Report-Msgid-Bugs-To: lxc-devel@lists.linuxcontainers.org
PO-Revision-Date: 2019-12-12 14:53+0000
Last-Translator: St
phane Graber <stgraber@stgraber.org>
Language-Team: German <https://hosted.weblate.org/projects/linux-containers/lxd/de/>
Language: de
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Plural-Forms: nplurals=2; plural=n != 1;
X-Generator: Weblate 3.10-dev
%s (%d mehr)
%s ist kein Verzeichnis
%v (zwei weitere Male unterbrechen, um zu erzwingen)
(kein Wert)
ALIAS
ALIASES
ARCHITEKTUR
Akzeptiere Zertifikat
Aktion (Standard: GET)
Neue entfernte Server hinzuf
Aliasname fehlt
automatisches Update: %s
Bytes empfangen
Bytes gesendet
ERSTELLT AM
Spalten
Kopiere Aliasse von der Quelle
Kann Verzeichnis f
r Zertifikate auf dem Server nicht erstellen
Erstellt: %s
Erstelle %s
BESCHREIBUNG
ABLAUFDATUM
FINGERABDRUCK
ltige Quelle %s
ltiges Ziel %s
ffentliche Abbild
Mehr als eine Datei herunterzuladen, aber das Ziel ist kein Verzeichnis
Entferntes Administrator Passwort
Server Zertifikat vom Benutzer nicht akzeptiert
Setzt die gid der Datei beim 
bertragen
Setzt die Dateiberechtigungen beim 
bertragen
Setzt die uid der Datei beim 
bertragen

I should mention that I do build the system with French support. But the locale settings are correct, so this still shouldn’t be happening.

It probably has something to do with glibc. This isn’t the only issue I’ve had with the new one.

Might be interesting to run an affected command under strace -f to see what translation files it’s opening and in what order.

Normally with LANG set to de_DE, it should really only open that one but I don’t know if the C library is looking for other configs or something. Looking at everything that’s open through strace may help track that too.

1 Like

Okay, I’ve figured out what was causing this.

I’m using KDE Plasma, and it recently started setting the gettext LANGUAGE variable based on the KDE localization settings. (See GNU gettext utilities: The LANGUAGE variable)

My LANGUAGE variable was set to de:fr:en_US:es in ~/.config/plasma-localerc.

I’ve changed this to de:en_US now, and the language mixing problem is now resolved.

Ah good, that makes sense!

1 Like