Potpourri aus „Januar“ und „Jänner“

Hi,
ich bin etwas ratlos, weil ich offenbar nicht die richtigen -lang-Pakete oder Einstellungen finde, um das Problem selbst zu beheben. In Österreich sagt man „Jänner“ statt „Januar“ und das würde ich auch gerne auf meinem Tumbleweed-System überall haben. Ich erinnere mich vage daran, dass zumindest SDDM letztes Jahr „Jänner“ angezeigt hat.

Jedenfalls konnte ich in den KDE-Systemeinstellungen unter „Region & Sprache“ zwar unter „Zeit“ den Eintrag „Österreichisches Deutsch (Österreich)“ (sic!) auswählen: Die Vorschau unter diesem Eintrag zeigt auch das Datum als „Donnerstag, 1. Jänner 2026“ an und tatsächliche Zeitangaben (z.B. Erstellungsdaten in Dolphin oder der Sperrbildschirm) verwenden auch „Jänner“. Doch das Kalender-Widget von Plasma (und auch der Kalender, der in die digitale Uhr integriert ist) sagt weiterhin hartnäckig „Januar“. Auch SDDM, doch das wird mit den KDE-Einstellungen wohl eher nichts zu tun haben.

In den KDE-Systemeinstellungen kann ich unter „Region & Sprache“ unter „Sprache“ allerdings nur „Deutsch“ auswählen und nicht „Österreichisches Deutsch“ oder „Deutsch (Österreich)“, was mich dazu bringt, dass ich derzeit die folgenden relevanten Umgebungsvariablen gesetzt zu haben scheine:

LANG=de_DE.UTF-8
LANGUAGE=
LC_TIME=de_AT.UTF-8

(Ich selbst habe nirgends LANG gesetzt. Ist das ein Nebeneffekt der fehlenden Auswahlmöglichkeit in den KDE-Systemeinstellungen, oder schreibt das YaST, siehe unten?)

Im YaST habe ich gerade versucht, die Sprache umzustellen. Unter „Primäre Sprache“ im Modul „Sprache“ kann ich ebenfalls bloß „Deutsch“ auswählen. Klicke ich auf „Details“ kann ich zwar de_AT unter „detaillierte Locale-Einstellung“ auswählen, bekomme dann aber die Fehlermeldung „ Sprache ‘de_AT’ wurde in der Liste der im Verzeichnis /usr/share/YaST2/data/languages verfügbaren unterstützten Sprachen nicht gefunden. Fallback-Sprache en_US wird verwendet.“ Ich möchte nicht wirklich ausprobieren, ob es dann trotzdem klappt, weil ich keine Lust habe, Firefox und Konsorten wieder Deutsch beizubringen, die sich in der Vergangenheit bei Sprachen unter openSUSE als widerspenstig erwiesen haben.

Folgende relevanten YaST-Pakete habe ich alle installiert: yast2-country, yast2-country-data und yast2-trans-de.

Wie bekomme ich es hin, dass (zumindest) SDDM und alle KDE-Komponenten einheitlich vom „Jänner“ statt vom „Januar“ sprechen?

Über jeden Hinweis bin ich dankbar, wahrscheinlich habe ich eh an den falschen Ecken gesucht.

Dieser Überzeugung bin ich auch: Leap / Plasma Locales Configuration

karl@5700g:~> LANG=de_AT.UTF-8 date
Do 01 Jän 2026 16:59:20 CET
karl@5700g:~> 

OK, danke für den Überblick über die entsprechenden Konfigurationen!

Mit localectl habe ich jetzt die System-Locale gesetzt,

# localectl set-locale LANG=de_AT.UTF-8
# localectl
System Locale: LANG=de_AT.UTF-8
    VC Keymap: de-nodeadkeys
   X11 Layout: de
    X11 Model: microsoftpro
  X11 Variant: nodeadkeys
  X11 Options: terminate:ctrl_alt_bksp

und das hat dazu geführt, dass zumindest SDDM jetzt „Jänner“ sagt.

Ich habe weiters in der ~.config/plasma-localerc jetzt LANG=de_AT.UTF-8 gesetzt, was dazu geführt hat, dass die Systemeinstellungen unter „Region & Sprache“ jetzt „Sprache: Österreichisches Deutsch“ anzeigen (unter „Ändern…“ kann ich das aber natürlich immer noch nicht auswählen). Wohlgemerkt habe ich den Eintrag LANGUAGE=de unter [Translations] nicht geändert.

Leider hatte das keine Auswirkungen auf das Kalender-Applet. Das sagt immer noch „Januar“. Wie kriege ich das auch noch gebändigt?

Einige Systemdialoge (z.B. das KWallet-Passwortprompt oder der KDESU-Dialog) sprechen jetzt allerdings Englisch. Ich bin mir ziemlich sicher, dass die vorher auf Deutsch waren.

Noch etwas Anderes: Wenn ich mit localectl erfolgreich die Locale setzen konnte, was hatte dann die YaST-Fehlermeldung zu bedeuten? Und warum schreiben die Plasma-Systemeinstellungen standardmäßig de_DE, wenn nur die generische Sprache „Deutsch“ ausgewählt ist?

Übrigens hat date bei mir auch schon mit LANG=de_DE.UTF-8 und LC_TIME=de_AT.UTF-8 (so wie in meinem ursprünglichen Beitrag) „Jän“ ausgegeben.

Ich muss mich korrigieren, die angesprochenen Systemdialoge dürften vorher auch schon Englisch gewesen sein. Ein Rückgängigmachen der Änderungen hat daran nämlich nichts geändert.

Bleibt trotzdem noch das Kalender-Applet…

Ich habe die Benutzer Locales konsistent geändert:

karl@5700g:~> grep ^export .profile
export LANG=de_AT.UTF-8
karl@5700g:~> 

Normalerweise habe ich lieber Texte in Englisch. Jetzt ist das auskommentiert.

karl@5700g:~> cat ~/.config/plasma-localerc
[Formats]
LANG=de_AT.UTF-8

[Translations]
#LANGUAGE=en_GB:de
karl@5700g:~> 

Ein neuer grafischer Login verwendet jetzt konsistent Österreichisch.

Spannend. Mein .profile setzt LANG nicht und durch das Setzen mit localectl sollte das ja ohnehin jetzt global geschehen.

Ein Ändern von LANGUAGE unter [Translations] von de zu de_AT hat dazu geführt, dass das Kalender-Applet jetzt auch spurt. (Nebenbei bemerkt zeigen die KDE-Systemeinstellungen jetzt „Sprache: Österreichisches Deutsch“ an, auch unter „Ändern…“, nur ein Auswählen davon unter „Ändern…“ → „Österreichisches Deutsch“ → „Sprache ändern“ ist immer noch nicht möglich. Außerdem ist der Knopf „Weitere hinzufügen“ jetzt ausgegraut.)

Danke für die Hilfe/Hinweise jedenfalls! Meiner Meinung nach sollte das aber alles über die GUIs konfigurierbar sein. Ist das was für den KDE-Bugzilla? (Die YaST-Fehlermeldung ignoriere ich jetzt mal, YaST ist eh bald Geschichte.)

Das ist genau das, was in dem Ordner nicht zu finden ist, keine language_de_AT.ycp.

Will sagen, die Datei /usr/share/YaST2/data/languages/language_de_AT.ycp wäre das Einzige, das nötig wäre, um de_AT als System Locale via YaST zu setzen?

Für X11 so weit ich das sehe und dann nicht für den User.
Das funktioniert immer noch unter der grafischen Oberfläche.

Die Antwort verstehe ich leider nicht.

Diese Datei mag zwar vielleicht die Konfiguration per YaST erlauben, aber in den KDE-Systemeinstellungen fehlen ja trotzdem weiterhin die Auswahlmöglichkeiten.

Außerdem bin ich seit Wayland auf Tumbleweed Standard ist, in einer Wayland-Session (wobei ich mir nicht sicher bin, was das damit zu tun hätte).

Einige Kleinigkeiten sind immer zu beachten: https://share.google/aimode/tAkaSh35wsJD5LFSp

Zwischen „sollte” und „ist” gibt es immer wieder Diskrepanzen. Bei KDE hat man zunehmend erkannt, dass es nicht ausreicht, gute Ideen zu haben. Die Leute bemühen sich, konsistent und kohärent zu sein, und haben dabei einige Fortschritte gemacht. Bei der Dokumentation sind sie jedoch noch nicht so konsequent, wie es wünschenswert wäre. Die künstliche Intelligenz hilft jedoch oft über dieses Manko hinweg.

Ja klar. Daher auch meine Frage, ob das etwas für den KDE-Bugzilla wäre.

Und das machen sie auch sehr gut; ich bin sehr zufrieden, wie reibungslos alles seit Plasma 6 läuft.

Es ist aber weder konsistent noch kohärent, zwar zwischen „American English“ und „British English“ oder zwischen „Português europeu“ und „Português (Brasilien)“ wählen zu können, aber nicht zwischen „Deutsch“ (oder von mir aus „Deutsch (Deutschland)“), „Deutsch (Österreich)“ und „Deutsch (Schweiz)“:

Außerdem ist es auch nicht kohärent, das Modul „Region & Sprache“ zu nennen, wenn die Region für alle zufriedenstellend bei allen anderen Einstellungen als der Grundsprache eingestellt werden kann (dort kann man sämtliche vorhandenen Locales im GUI wählen, bei der Sprache nicht).

Zumal die nötigen Übersetzungen offensichtlich vorhanden sind. Man kann sie über KDE-Tools bloß nicht auswählen.

Ich habe jetzt auch noch gesehen, dass zumindest die Vorschau für das Währungsformat für de_AT in den KDE-Systemeinstellungen nicht stimmt; dort steht „€ 24,00“ während für alle anderen deutschen Locales „24,00 €“ angezeigt wird. So wird das auch in Österreich gemacht.


Ich habe jetzt versuchsweise meine .config/plasma-localerc gelöscht. Beim nächsten Start hat Plasma sie neu geschrieben und sie beinhaltet jetzt bloß das (wohl weil ich die Locale per localectl gesetzt habe):

[Formats]
LANG=de_AT.UTF-8

und funktioniert wie gewollt.

KDE Plasma verwendet jetzt konsistent und kohärent die GNU C Library Locales. Die grafische Konfiguration könnte noch etwas verbessert werden. Wer dort sein Locale nicht findet editiert die oben erwähnten Konfigurationsfiles.

1 Like