Das allein kann es aber nicht sein, bzw. gewesen sein. Sinn dieses Schalters ist ja der: unter welcher Locale werden die Daemons (bzw. Init-Prozesse) gestartet - was dann (Boot)-Ausgabe und Logfile-Sprache betrifft.
Ich z.B. hasse die "eingedeutschten" Bootmeldungen, ebenso Deutsch in Logfiles. Deshalb steht diese Variable bei mir auf No.
Probleme nun:
Selbst mit No sind etliche Ausgaben noch "Deutsch" bzw. ebe Nicht-C(=Englisch). Ursache ist, das es mit der aktuellen glibc-Locale wohl nicht mehr reicht nur LANG zu setzen. Früher(tm) reichte es z.B. ein:
LANG=C pacman -Si glibc
zu machern um die Ausgaben in Englisch zu haben. Heute funktioniert/reicht das nicht mehr, da für Ausgaben (also welche lokalisierte .po Datei zu Rate gezogen wird) eben LC_MESSAGES ausgewertet wird.
LC_MESSAGES=C pacman -Si glibc
Um also in den erwarteten Nutzen der rc.conf->DAEMON_LOCALE zu kommen muß in den initscripts geändert werden:
/etc/rc.d/functions
--- /etc/rc.d/functions.org 2012-06-07 01:02:33.000000000 +0200
+++ /etc/rc.d/functions 2012-06-13 12:35:57.794085821 +0200
@@ -675,6 +675,8 @@
fi
else
export LANG=C
+ #export LC_MESSAGES=C
+ export LC_ALL=C
fi
# set colors
Zu LANG muß also zusätzlich mindest LC_MESSAGES exportiert werden, besser wäre wohl LC_ALL. Das bringt mir zumindest die gewünschte englische Sprache in Bootprozeß und Logfiles. (ich werde wohl einen Featurerequest/Bugreport schreiben).
Trotz No bei dieser Variable habe ich für alle User sowohl in den TTYs als auch X die gewünschte Locale de_DE.UTF-8. Der Grund wird IMHO aus der /etc/rc.d/functions ebenfalls deutlich:
if [[ $DAEMON_LOCALE = [yY][eE][sS] ]]; then
export LANG=${LOCALE:-C}
if [[ -r /etc/locale.conf ]]; then
parse_envfile /etc/locale.conf "${localevars[@]}"
fi
else
Es werden Einstellungen aus /etc/locale.conf - sofern vorhanden - genommen. locale.conf wurde irgendwann 2011 eingeführt, v.a. um DMs wie KDM und GDM ein lokales Profil zu starten zu geben. Diese locale.conf "überstimmt" sogar die Einstellung in rc.conf (v.a. da hier ebefalls nur LANG aus rc.conf->LOCALES gesetzt würde, u.U. gleiches Problem wie oben).
Wenn
@sanni nun Probleme mit der (Locale)-Ein-/Ausgabe von Tools hat bi ich der Meinung daß es sich nicht mit yes oder no für die DAEMONS-LOCALE "lösen" können dürfte. Da muß schon etwas anderes nicht ok sein (LC_* settings, bzw. Console-Font). Es ist Sache des Profile-Mechanismus der Shells eben solche Dinge korrekt zu setzen.
bernacher schrieb
Das ist jetzt notwendig, sonst benutzt Arch beim Booten die C-Standard-Locale. Und die ist nicht UTF-8
Muß sie auch nicht IMHO, da in en_US ("Englisch") keinerlei Umlaute z.B. ausgegeben würden(.po-Files) und nicht eingegeben werden müssen. Und bei UTF-8 fahigem Konsolen-Zeichensatz und Mapping sogar daß (selbst mit de_DE.UTF-8 kann ich z.B. kyrillische und arabische Zeichen sehen und auch eingeben). Das Setzen auf Yes ist also definitiv nicht notwendig (und darf es auch garnicht).
Hier meine /etc/locale.conf
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
Das beschert allen meinen Usern eine systemweite de_DE Ein-/Ausgabe ("Locale", geschieht über /etc/profile.d/locale.sh). Wenn ich für root nun abweichend C oder eine andere haben möchte, dann setze ich das in ~/.profile (ud/oder der Profile der genutzten Shell).