Das locale Thema macht mich fertig unter FreeBSD

schorsch_76

schorsch_76

FreeBSD Fanboy
login_conf funktioniert nur auf der der tty* oder ssh. Warum funktioniert das nicht unter xorg? Ist es wirklich notwendig die ganzen

LC_*, LANG und MM_CHARSET in der

- /etc/profile
- ~./profile
- ~/login_conf
- /etc/login.conf
- ~/.bashrc/~/.zshrc/...
. ~/.xinitrc

da keines davon durchgängig funktioniert? Zudem muss unter KDE/Plasma und Firefox (welcher unter FreeBSD 11.2 gar nicht zu einer anderen Sprache als Englisch fähig ist) nochmal manuell Hand angelegt werden?

Warum empfiehlt dann das Handbuch die Login Klasse? Das hat bei mir nur unter tty* und ssh funktioniert? (ja, cap_mkdb /etc/login.conf ist mit reboot gelaufen).

Ja, das nervt mich :mad:

Das Handbuch schreibt: und ja, ich wollte die emfohlene Methode nutzen. login.conf


Einstellen der Locale für die Login-Shell
Die Einstellungen für Locale werden entweder in der ~/.login_conf des Benutzers, oder der Startdatei der Shell (~/.profile, ~/.bashrc oder ~/.cshrc) konfiguriert.

Zwei Umgebungsvariablen sollten konfiguriert werden:

  • LANG, das die Locale einstellt.
  • MM_CHARSET, das den MIME Zeichensatz für Anwendungen einstellt.
Neben der Shell-Konfiguration des Benutzers sollten diese Variablen auch für spezifische Anwendungen und Xorg-Konfigurationen eingestellt werden.

Es gibt zwei Methoden, die Locale zu setzen: die erste und empfohlene Methode ist, die Umgebungsvariablen in der Login-Klasse zu setzen, die zweite Methode ist, sie in den Startdateien der Shell zu setzen. In den nächsten Abschnitten werden beide Methoden vorgestellt.
 
schorsch_76 schrieb:
und Firefox (welcher unter FreeBSD 11.2 gar nicht zu einer anderen Sprache als Englisch fähig ist)
Zum Vergrößern anklicken....
war er bei mir schon, die Variable dazu hat sich nur geändert. Such hier mal nach einem Beitrag, den @ralli erstellt hatte. Glaube ich.
intl.locale.requested;de muss da nun gesetzt werden und natürlich das i18n installiert sein.

der Rest, den du beschreibst, kann ich in etwa bestätigen: das hatte mir seit Jahren immer schon zu schaffen gemacht, ist aber wohl nicht zu ändern, weil die Teile ja alle irgendwo anders her kommen und nicht nur zu FreeBSD gehören. Es gibt eben Programme, die schauen auf eine .login.conf und andere erben die Variablen aus dem Environment und so weiter.
 
Eigentlich ist es ganz einfacher. Oder war es zumindest mal, bevor - diplomatisch gesagt - nicht unbedingt erfahrene Entwickler am Desktop herumzuschrauben durften. Es muss halt jemand die Umgebungsvariable setzen. Klassisch gab es dafür zwei Wege:
  • Über die globale Login-Klasse oder über die ~/.login_conf. Das setzt allerdings voraus, dass login(1) ausgeführt wird. Was sich viele Display- und / oder Login-Manager sparen, sie arbeiten bestenfalls direkt gegen PAM.
  • Über das Login-Script der Login-Shell. Hier ist das Drama, dass Display- und Login-Manager sehr viel falsch machen können und oft auch tun. Sie starten gar keine Shell, haben eine Shell hart reingecodet, starten die Shell nicht als Login-Shell...
Problematisch sind natürlich auch Session-Handler und ähnliche Dinge, die meinen aus irgendwelchen Gründen die komplette Umgebung verwerfen zu müssen und neu anzufangen... Also kurz zusammengefasst: Beim Login über die Konsole, SSH und co. sollte es mit beiden Wegen klappen. Bei startx auch, wenn nicht verwirft ein nachgelagerter Session-Manager die Umgebung. Mit Display- und Login-Managern ist es sehr fummelig, da muss man sich an die jeweilige Konfiguration halten.
 
Moin !

Also mit das wichtigste für die lokalisierung ohne login-manger ist wohl vipw !

:1001:0:german:0:0:Frank XXX:

Der Eintrag " german" ist wichtig !

Gruss
 
bluescreen schrieb:
Moin !

Also mit das wichtigste für die lokalisierung ohne login-manger ist wohl vipw !

:1001:0:german:0:0:Frank XXX:

Der Eintrag " german" ist wichtig !

Gruss
Zum Vergrößern anklicken....
das stimmt, aber zielt ja nur auf das, was in der login.conf zu german gesetzt wird. Das ist deshalb mindestens ebenso wichtig.

PS: und natürlich, dass die Database dann auch neu angelegt wird. Das geht wohl inzwischen automatisch, ich würde aber immer den mk.db absetzen, um sicher zu sein.
 
Heute vormittag war ich da leicht ... angefressen. @pit234a Den Artikel von @ralli hab ich gefunden.

Letztens hatte ich ja das Thema mit dem Bugreport: Hier ist dann das Credo: Nein, kein Bug in libc++, das muss in boost::locale sein. Aber auch keine Beweise, nur reden. Der Hinweis, das es unter Windows (MSVC 2013+2017) und Linuc gcc8.2 nicht auftritt, half auch nichts. Er hat den Bug nicht mal nachvollzogen, da er kein Boost installiert hat. Offensichtlich ist für den FreeBSD committer ein "pkg install boost-all" zuviel verlangt mit einem Testcase. Deshalb vermute ich, das die Locale Thematik insgesamt einfach nicht angegangen werden will. Da bin ich ehrlich gesagt enttäuscht.
 
schorsch_76 schrieb:
Deshalb vermute ich, das die Locale Thematik insgesamt einfach nicht angegangen werden will.
Zum Vergrößern anklicken....
Da kann FreeBSD aber nichts für, wenn einige WM/DEs ihre eigene Suppe kochen. Letztendlich musst du nur dafür sorgen, dass die Umgebungsvariable gesetzt ist bevor die grafische Oberfläche gestartet wird. In der Regel sollte dies mit der ~/.xinitrc funktionieren.

Rob
 
Jetzt hab ich den Bug noch bei llvm und bei boost gemeldet. Boost hat ihn praktisch gleich zugemacht. mal sehen was LLVM/clang dazu sagt.
 
Hallo,

für deutsche Tastatur unter X habe ich eine /usr/local/etc/X11/xorg.conf.d/input.conf:
Code: 
Section "InputClass"
    Identifier      "Keyboard defaults"
    Driver          "keyboard"
    MatchIsKeyboard "on"
    Option          "XkbLayout" "de"
    Option          "XkbVariant" "nodeadkeys"
EndSection

Damit sddm deutsch lokalisiert startet und dann auch meine plasma5-Sitzung, habe ich in der /etc/profile ein
Code: 
export LANG=de_DE.UTF-8

Und meine ~.login_conf sieht wie folgt aus:
Code: 
# $FreeBSD: releng/12.0/share/skel/dot.login_conf 77995 2001-06-10 17:08:53Z ache $
#
# see login.conf(5)
#
me:\
        :charset=UTF-8:\
        :lang=de_DE.UTF-8:

Das sind drei Dateien :)

Mein Eindruck ist, dass es dieses Locale-Wirrwarr auch bei Linux gibt. Da werden nur einige Sachen seitens der Distruibutoren vorab "schön" konfiguriert. Zumindest bei OpenSUSE ist es mir zu meinen Linux-Zeiten passiert, dass ich beim Abweichen von den vorgegeben Standards (kein Login-Manager, X mit startx starten) plötzlich auch zu Phänomenen kam, dass manches dann auf Englisch war. Besonders gruselig (und eine openSUSE-Spezialität) war bei manchen Szenarien ein partiell deutsch, partiell englisches KDE4, und nein, das lag nicht an unvollständigen Übersetzungen.

Viele Grüße
Holger
 
Das ganze Thema ist ohnehin ein endloses Trauerspiel. Es raubt Energie und Zeit.
Als man vor über 150 Jahren den Morsecode festlegte, war man schon so klug die am häufigsten in der Sprache vorkommenden
Buchstaben die kürzesten Signale zuzuweisen ( z.B. e -> nur ein Punkt)
Heutzutage brauchen wir dann ( Negativbeispiel: deutsche Mac-Tastatur ) für sehr häufig benutzte Zeichen wie Slashes, Pipe usw.
Fingerakrobatik nur weil die deutschen Umlaute in die Tastatur reingequält werden.

Diese Thematik betrifft ja keineswegs nur die Unix/Linux-Welt!

Mir geht das alles so sehr auf den Zeiger - dass mein neues MacBook eine internationale US-Tastatur hat ...
wobei mit der US- Mac - Tastatur allerdings die deutschen Umlaute einfacher zu erzeugen sind, als auf PCStandardKeyb.

Der Rest bleibt dann halt auch auf Englisch - die man-pages übersetzt ja auch keiner in Deutsche.
Und wo die Vorteile eines deutschsprachigen Browsers oder GUI liegen sollen, verstehe ich auch nicht wirklich.
man muss ja nun nicht englisch lernen, um diese wenig englischen Begriffe die hier vorkommen, zu kennen.

In der Umgangssprache gibt es eine Inflation von Anglizismen mit denen den Gesprächspartnern oft ein Fachwissen, dass noch
nicht mal ansatzweise vorhanden ist, vorgegaukelt wird ... aber am PC muss mit einem Tastendruck das ß erscheinen ;-)

Dieser shit triggert mich real an ;-)
 
Vril schrieb:
Und wo die Vorteile eines deutschsprachigen Browsers oder GUI liegen sollen, verstehe ich auch nicht wirklich. man muss ja nun nicht englisch lernen, um diese wenig englischen Begriffe die hier vorkommen, zu kennen.
Zum Vergrößern anklicken....

Wie wäre es mit russisch, oder alternativ mit chinesisch? Glücklicherweise ist die Welt immer noch auf den Horizont des einen oder anderen Techies zusammen geschrumpft.

Das deutsche Keyboard Layout macht in der Tat immer wieder Probleme, insbesondere Shortcuts In einem englisch sprachigen Programm...
 
Was ich hier noch dokumentieren möchte:
Wenn unter den neuen Firefox + Thunderbird 62+ int.locale.requested nicht vorhanden ist, muss man das selbst hinzufügen. Es gibt einen unscheinbaren "+" Button.
 
holgerw schrieb:
Mein Eindruck ist, dass es dieses Locale-Wirrwarr auch bei Linux gibt.
Zum Vergrößern anklicken....

Die Zeiten sind vorbei. Selbst das inzwischen fast 5 Jahre alte CentOS/RHEL 7 kriegt es dank localectl samt locale.conf einwandfrei hin, weil nicht mehr jedes Programm sein eigenes Süppchen kochen muss. Zumindest mit KDE und GNOME klappt die Integration auch völlig nahtlos, inklusive Wechsel des Tastaturlayouts im laufenden Betrieb.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben