Beim letz­ten Server-​Update ist es mir wie­der pas­siert. perl: warning: Fal­ling back to the stan­dard loca­le (“C”) stand da zu lesen. Die Feh­ler­mel­dung kann­te ich schon. Und ich erin­ner­te mich auch gut, wie lan­ge ich das letz­te Mal für die Lösung des Pro­blems benö­tig­te hat­te. Das war aus­rei­chend Moti­va­ti­on, mich der Ange­le­gen­heit ein­mal genau­er zu wid­men und einen Arti­kel dar­über zu schrei­ben. Die Pro­ble­ma­tik könn­te übri­gens auch für jeman­den von Inter­es­se sein, der z.B. über PHP ein Datum in einer defi­nier­ten Spra­che aus­ge­ben möch­te.

Hin­ter dem Begriff “loca­le” ver­ber­gen sich in Linux-​Distributionen die sys­tem­wei­ten Sprach­ein­stel­lun­gen. Die Doku­men­ta­ti­on der Linux-​Distribution Ubun­tu [1] erwähnt, dass in Büchern sowie selbst im Inter­net nur bits and pie­ces of infor­ma­ti­on zu erhal­ten sind, in Foren fin­det man mehr Fra­gen als Ant­wor­ten. Das ist erstaun­lich, denn die Sprach­ein­stel­lung eines Betriebs­sys­tems ist nicht gera­de neben­säch­lich. Dabei geht es nicht nur dar­um, in wel­cher Spra­che mein Ser­ver mit mir kom­mu­ni­ziert, son­dern auch, in wel­cher Spra­che er auf Skriptan­fra­gen reagiert. Hier­zu ein Bei­spiel mit einer Datums­an­fra­ge in PHP: Die Aus­ga­be eines für eine deut­sche Web­sei­te abge­setz­ten Befehls…

echo strftime("%A", mktime(0, 0, 0, 4, 2, 2012));

… die ein…

Monday

… lie­fert lässt ver­mu­ten, dass der Ser­ver in der für uns fal­schen Spra­che kon­fi­gu­riert ist. Wenn dann aber ein…

setlocale(LC_ALL, 'de_DE');
echo strftime("%A", mktime(0, 0, 0, 4, 2, 2012));

… kei­ne Ände­rung bewirkt, ist die Sor­ge, dass das gera­de in Ent­wick­lung ste­hen­de Pro­jekt wie­der ein­mal län­ger als geplant dau­ern wird, berech­tigt. Das Pro­blem ent­steht, wenn Skrip­te Über­set­zun­gen vom Betriebs­sys­tem anfor­dern, die dort nicht instal­liert sind. Und damit haben wir es auch schon halb gelöst. Für den Rest benö­ti­gen wir direk­ten Zugriff auf den Ser­ver.

Zuerst soll­ten wir uns davon über­zeu­gen, wel­che Spra­chen über­haupt instal­liert sind. In einer Linux-​Standard-​Installation wird das Eng­lisch sein:

$ locale -a

Die Shell lis­tet dar­auf­hin alle instal­lier­ten Spra­chen auf:

C
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
POSIX

“C” und “POSIX” sind eine ASCII Alter­na­ti­ve, falls mit den ande­ren Kodie­run­gen etwas schief­geht. Das erklärt jetzt auch die Aus­ga­be

perl: warning: Falling back to the standard locale ("C")...

…, ein Feh­ler, den man etwa beim Aktua­li­sie­ren des Sys­tems oft zu sehen bekommt. Die ande­ren Ein­trä­ge beschrei­ben über einen Code [2] die instal­lier­ten Spra­chen. Wenn wir uns also an die Pro­ble­ma­tik erin­nern, dass sich die Datums­aus­ga­be nicht von Mon­day auf Mon­tag umstel­len hat las­sen, dann ist jetzt klar, dass ein­fach nur die gefor­der­te Spra­che instal­liert wer­den muss.

Eine höchst inter­es­san­te Aus­ga­be bie­tet übri­gens loca­le mit dem zusätz­li­chen Argu­ment -v

$ locale -av

locale: de_AT.utf8
archive: /usr/lib/locale/locale-archive
--------------------------------------
    title | German locale for Austria
   source | O:sterreiches Normungsinstitut
  address | Postfach 130, A-1021 Wien
  contact | Gerhard Budin
    email | bug-glibc-locales@gnu.org
 language | German
territory | Austria
 revision | 1.0
     date | 2000-06-28
  codeset | UTF-8
...

Auf der Kon­so­le bedeu­tet instal­liert aber nicht, dass das Sys­tem die­se Spra­chen auch ver­wen­det. Auf wel­cher Spra­che (kön­nen auch meh­re­re unter­schied­li­che sein) das Sys­tem gera­de läuft ver­rät der Befehl

$ locale

Die Aus­ga­be sieht im Gegen­satz zu loca­le -a ein wenig anders aus:

LANG=de_AT.UTF-8
LANGUAGE=de_AT
LC_CTYPE="de_AT.UTF-8"
LC_NUMERIC="de_AT.UTF-8"
LC_TIME="de_AT.UTF-8"
...

Ich gön­ne mir also auf mei­nem Ser­ver ein Öster­rei­chi­sches Deutsch. Dadurch wird zum Bei­spiel ein Janu­ar zu einem Jän­ner. Oder ein gucken zu einem schau­en (just kid­ding). Neu­gie­rig wie wir sind wol­len wir natür­lich wis­sen, wel­che Ein­stel­lung dafür ver­ant­wort­lich ist und vor allem wie wir sie ver­än­dern kön­nen. Das hängt (lei­der) von der ver­wen­de­ten Ver­si­on ab. In Ubuntu-​Versionen vor Lucid Lynx [3] fin­det man die Ein­stel­lung in der Datei envi­ron­ment

$ vim /etc/environment

In spä­te­ren, jün­ge­ren Ver­sio­nen befin­den sich die Para­me­ter im File /​etc/​default/​locale

$ vim /etc/default/locale

Die aktu­ell ver­wen­de­te Spra­che ist dort wie folgt ein­ge­tra­gen:

LANG="de_AT.UTF-8"
LANGUAGE="de_AT"

Die­se Ein­trä­ge dür­fen (als root) gleich vor Ort ver­än­dert wer­den (aller­dings wer­den sie erst nach einem erneu­ten Log­in oder even­tu­ell erst nach einem Neu­start aktiv), oder man bedient sich des Befehls

$ update-locale LANG=de_AT.UTF-8 LANGUAGE=de_AT

Hin­weis: Ver­ur­sacht der Para­me­ter UTF-​8 Schwie­rig­kei­ten, soll­te man eine Ver­si­on ohne Bin­de­strich, also utf8 aus­pro­bie­ren [4].

Bleibt noch zu klä­ren, wie man nun neue Sprach­un­ter­stüt­zun­gen instal­liert, pas­send zu unse­rem PHP-​Beispiel, bei dem ja der Ser­ver auf die ange­for­der­te Über­set­zung eines Wochen­ta­ges nicht wie gewünscht reagiert hat. Hier­zu führt man fol­gen­den Befehl aus, wobei natür­lich die Sprach-​Codes den Bedürf­nis­sen anzu­pas­sen sind:

$ sudo locale-gen de_AT.UTF-8

Die ver­füg­ba­ren Kür­zel kann man übri­gens aus dem Sys­tem sel­ber aus­le­sen. Sie sind in fol­gen­dem File abge­legt:

$ vim /usr/share/i18n/SUPPORTED

 

Wenn Fehler auftreten

Manch­mal kann es pas­sie­ren, dass es zu Inkom­pa­ti­bi­li­tä­ten zwi­schen den ein­zel­nen Spra­chen kommt. Infor­ma­tio­nen dar­über, war­um so etwas pas­siert, oder wie man es löst, sind noch schwe­rer zu fin­den. Eine sol­che Feh­ler­mel­dung könn­te wie folgt aus­se­hen:

sudo locale-gen
en_HK.UTF-8... hash collision (1688509771) en_HK.utf8, de_CH.utf8 failed

Dazu wech­selt man in das unten ange­ge­be­ne Ver­zeich­nis und öff­net jene Datei, deren zuge­hö­ri­ge Spra­che gelöscht wer­den soll:

cd /var/lib/locales/supported.d
sudo vim en

Dort löscht man nun ein­fach jenen Ein­trag, der den Kon­flikt aus­ge­löst hat (in die­sem Fall wäre es en_​HK. Um de_​CH zu löschen, müss­te man also in die Datei de). Anschlie­ßend soll­te ein

sudo locale-gen

anstands­los durch­lau­fen.

 

Zusammenfassung

Instal­lier­te Spra­chen abfra­gen

$ locale -a

Aktu­ell gül­ti­ge Spra­che abfra­gen

$ locale

Aktu­ell gül­ti­ge Spra­che ändern (Bei­spiel)

$ update-locale LANG=de_AT.UTF-8 LANGUAGE=de_AT

Neue Spra­che instal­lie­ren (Bei­spiel)

$ sudo locale-gen de_AT.UTF-8

 

Fußnoten

[1] Ubun­tu Docu­men­ta­ti­on, “Loca­le”
[2] ISO 639-​1 Code
[3] Linux Relea­ses
[4] PHP set­lo­ca­le()