woher liest STRFTIME(3) die locale ?

pit234a

Well-Known Member
oder anders gefragt, wieso zeigt:
Code:
pit@eee ~:-> date -j "+ %A"
 Sunday
anstatt Sunday nicht Sonntag?

Code:
pit@eee ~:-> env | grep LC
LC_CTYPE=de_DE.ISO8859-1
LC_MONETARY=de_DE.ISO8859-1
LC_NUMERIC=de_DE.ISO8859-1
LC_TIME=de_DE.ISO8859-1
LC_ALL=de_DE.ISO8859-15

pit@eee ~:-> env | grep LAN
LANG=de_DE.ISO8859-15
Also, LC_ALL hatte nicht die gewünschte Wirkung und deshalb probierte ich es auch mit der LC_TIME und -1 statt -15, aber irgendwas muss ich wohl falsch machen oder verstehen, denn die Ausgabe der Zeit bleibt mir immer auf Englisch erhalten.
Das gilt auch für CAL(1).
Unterschiedliche Versionen für LANG habe ich auch durchprobiert. Vielleicht einfach noch nicht die passende gefunden?

Soweit ich es bisher überblicke, funktioniert die Lokalisierung aber für andere Programme. Ich sehe alle Menüs in Deutsch.
 
Hallo,

ich fand mal diesen Thread:
http://www.bsdforen.de/showthread.php?t=23049
Da kristallisierte sich heraus, dass die Login Class nicht ausgelesen wird, wenn etwa KDM über /etc/ttys gestartet wird.
Schlesi hat dazu das hier gepostet:
http://www.bsdforen.de/showpost.php?p=198861&postcount=8

Bei mir tut es:
Code:
date -j "+ %A"

 Sonntag

Code:
env | grep LC                                                                                        

LC_ALL=de_DE.ISO8859-15

In meiner /etc/login.conf habe ich:
Code:
#---------------------------------------------------------------------
# German Users Accounts
#---------------------------------------------------------------------
german|German Users Accounts:\
:charset=ISO-8859-15:\
:lang=de_DE.ISO8859-15:\
:tc=default:\
:setenv=MOZ_DISABLE_PANGO=1:
Das MOZ_DISABLE_PANGO=1 ist noch so ein altes Überbleibsel. Bisher hat es nicht gestört. Da war mal was beim Firefox, wenn ich mich richtig erinnere.

In meiner /etc/profile:
Code:
LANG=de_DE; export LANG
LC_CTYPE="de_DE.ISO8859-15"; export LC_CTYPE
LC_COLLATE="POSIX"; export LC_COLLATE
 
auf meinem FreeBSD, wo ich gerade sitze, ist:
Code:
pit@syo ~:-> env | grep LC
LC_ALL=de_DE.UTF-8

pit@syo ~:-> env | grep LAN
LANG=de_DE.UTF-8
ADOBE_LANG=DEU

pit@syo ~:-> date "+ %A"
 Sonntag
pit@syo ~:-> cal
    Februar 2012
So Mo Di Mi Do Fr Sa
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29
also in Ordnung. Da habe ich auch eine Gruppe der german:users in der /etc/loginconf angelegt. Das habe ich bisher bei OpenBSD nicht gemacht. Ich dachte auch, dass es nicht nötig ist, weil alle Variablen ja in den diversen profile und csh.cshrc und ~/.xyz inklusive .login_conf und .login_conf gesetzt werden.
Mit $LANG bin ich immer unsicher, wie hier aber zu sehen ist, scheint es bei mir mit de_DE+code zu gehen. Eigentlich würde ich eher denken, es müsste wie bei dir sein und nur de_DE da stehen. Bei OpenBSD hatte ich das aber auch erfolglos probiert.
Eigentlich kann ich mir kaum vorstellen, dass ich eine login-Gruppe german users anlegen muss. Ich würde erwarten, dass die gesetzten Variablen aus dem Environment genommen werden. Aber was hat das schon für eine Bedeutung, was ich so von einem OS erwarte!

edit: /CODE Inhalt korrigiert
 
Oha, OpenBSD, da hatte ich nicht drauf geachtet. :ugly:
Also einfach ignorieren, was ich gepostet habe, das war auf FreeBSD bezogen.
 
Ich glaube, das geht gar nicht :(

Code:
pit@eee ~:-> ls /usr/share/locale/de_DE.ISO8859-1
LC_CTYPE
Wenn ich da in meinem FreeBSD nachsehe, gibt es dort nicht nur LC_CTYPE.
Ich habe das, was es da gibt, einfach mal nach OpenBSD kopiert und deshalb:
Code:
pit@eee ~:-> ls /usr/share/locale/de_DE.ISO8859-15
LC_COLLATE   LC_CTYPE     LC_MESSAGES  LC_MONETARY  LC_NUMERIC   LC_TIME
Nur leider ist es nicht sooo einfach. Zwar sind einige Dateien, etwa LC_TIME, einfache Textdateien, doch so geht es denn doch nicht, dass man die einfach an die passende Stelle kopiert und sie schon genutzt werden.

Wie man OpenBSD evtl dazu bringen könnte, doch nach diesen Dateien zu sehen (die Rechte und Besitzer hatte ich identisch zur vorhandenen LC_CTYPE gesetzt), weiß ich jedenfalls nicht.
 
Hallo pit234,

auch wenn ich nicht im OpenBSD-Lager daheim bin, dürfte(!) es sich nach meiner Interpretation(!) möglicher Weise um einen Bug handeln. Wenn man sich den Quelltext von date(8) ansieht, dann steht am Anfang von main()
Code:
setlocale(LC_ALL, "");
Laut setlocale(3) bedeutet dies: "native environment". Meiner Meinung nach wird das aber in strftime(3) vorgegeben:
Code:
static const struct lc_time_T	C_time_locale = {
	{
		"Jan", "Feb", "Mar", "Apr", "May", "Jun",
		"Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
	}, {
		"January", "February", "March", "April", "May", "June",
		"July", "August", "September", "October", "November", "December"
	}, {
		"Sun", "Mon", "Tue", "Wed",
		"Thu", "Fri", "Sat"
	}, {
		"Sunday", "Monday", "Tuesday", "Wednesday",
		"Thursday", "Friday", "Saturday"
	},
[...]

Laut setlocale(3) müsste der Aufruf so lauten:
Code:
setlocale(LC_ALL, NULL);
damit die Einstellungen der Umgebungsvariablen gelesen werden.

Aber wie geschrieben, ich bin kein OpenBSDler, daher nur Vermutungen.

JueDan
 
@juedan, danke.
Mal sehen, ob ich das richtig verstehe.
Code:
     Only three locales are defined by default, the empty string "" which
     denotes the native environment, and the "C" and "POSIX" locales, which
     denote the C language environment.  A locale argument of NULL causes
     setlocale() to return the current locale.
Dies ist aus der man 3 setlocale auf meinem FreeBSD. Den OpenBSD müsste ich mir später nochmal ansehen.
setlocale wird nicht manuell aufgerufen, um die Localen zu setzen, sondern definiert die Variablen im Quellcode der betreffenden Anwendungen und da ist möglicherweise ein Fehler drin, denn durch "", the empty string, wird das native environment gesetzt, während es NULL heißen müsste, um die derzeitig zugewiesene Locale anzunehmen.

Das bedeutet, ich könnte entweder die Quellen von date, cal etc nachsehen und gegebenfalls abändern oder die Quellen zu strftime direkt ändern und die dort hinterlegten Englischen Ausdrücke ersetzen.
Zumindest zu einem Test, das erscheint mir durchaus sinnvoll.
Allerdings habe ich nur binaries installiert und wollte auf dem kleinen Asus ohne Quellen auskommen, davon abgesehen, dass ich mich selbst dazu als zu unkundig einschätze, in Quellcodes etwas zu ändern.

Habe ich das so richtig verstanden?
Und bedeutet das, dass ich so keine Chance habe, etwas daran zu ändern, etwa durch einen manuellen Aufruf von setlocale (wenn ich die man richtig deute, hätte das keinen Sinn)?
 
Hallo pit234,

@juedan, danke.
Mal sehen, ob ich das richtig verstehe.
Code:
     Only three locales are defined by default, the empty string "" which
     denotes the native environment, and the "C" and "POSIX" locales, which
     denote the C language environment.  A locale argument of NULL causes
     setlocale() to return the current locale.
Dies ist aus der man 3 setlocale auf meinem FreeBSD. Den OpenBSD müsste ich mir später nochmal ansehen.
setlocale wird nicht manuell aufgerufen, um die Localen zu setzen, sondern definiert die Variablen im Quellcode der betreffenden Anwendungen und da ist möglicherweise ein Fehler drin, denn durch "", the empty string, wird das native environment gesetzt, während es NULL heißen müsste, um die derzeitig zugewiesene Locale anzunehmen.

Das bedeutet, ich könnte entweder die Quellen von date, cal etc nachsehen und gegebenfalls abändern oder die Quellen zu strftime direkt ändern und die dort hinterlegten Englischen Ausdrücke ersetzen.
Zumindest zu einem Test, das erscheint mir durchaus sinnvoll.
Allerdings habe ich nur binaries installiert und wollte auf dem kleinen Asus ohne Quellen auskommen, davon abgesehen, dass ich mich selbst dazu als zu unkundig einschätze, in Quellcodes etwas zu ändern.

Habe ich das so richtig verstanden?
Und bedeutet das, dass ich so keine Chance habe, etwas daran zu ändern, etwa durch einen manuellen Aufruf von setlocale (wenn ich die man richtig deute, hätte das keinen Sinn)?

Ja, so hast Du es richtig verstanden.
Ich will aber den Quelltext nochmal genauer ansehen, da ich ein paar Unterschiede zu FreeBSD gesehen habe. Unter FreeBSD funktioniert es nämlich so wie es soll.

JueDan
 
Back
Top