Beschriftung von englisch "Tue" und "Dec" auf deutsch "Die" und "Dez" umstellen

[meldelinie]

Hallo,

In der Beschriftung der Plots stehen die englischen Tage z.B. "Tuesday/Tue" statt den deutschen "Dienstag/Die" und die englischen Monate "December/Dec" statt "Dezember/Dez".

ich habe u.a im Wiki nachgesehen und folgende Einstellungen gesetzt:

fhem.cfg

Code Auswählen Erweitern


attr global language DE


System ist Raspbian Buster auf aktuellem Stand, ich habe in raspi-config Zeitzone und Datumsformat auf Europe, Berlin und Locale auf DE gesetzt, in der Konsole sieht das so aus:

Code Auswählen Erweitern


root@fhem:/home/pi# localectl
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: n/a
      X11 Layout: de
       X11 Model: pc105


In der Konsole mal Tage und Monate anzeigen lassen, das klappt es mit Donnerstag und Dezember:

Code Auswählen Erweitern


date
Do 16. Apr 14:40:13 CEST 2020

ls -l Temp_Garage-2019-12.log
-rw-r--r-- 1 fhem dialout 96764 Dez 31 22:02 Temp_Garage-2019-12.log


Was muss ich ändern damit ich deutsche Tage und Monate angezeigt bekomme ?

schon mal danke für Tips ...

[rudolfkoenig]

In den Plots stehen die englischen Tage z.B. "Tuesday/Tue" statt den deutschen "Dienstag/Die"

Was genau muss ich dafuer einstellen? Ich wuesste nicht, wo Tage im SVG anzeigt werden.

und die englischen Monate "December/Dec" statt "Dezember/Dez".

Das kann ich so bestaetigen.
"attr global language" aendert ausschliesslich die angezeigte Hilfe.

[meldelinie]

Danke für den Input,

ich habe meine Frage jetzt umformuliert - ich meine die Beschriftung der Plots am unteren Rand - siehe die angehängte Grafik - da steht aktuell in den beiden Roten Kreisen "Dec" für December in englisch, ich hätte aber gerne das deutsche "Dez" für Dezember angezeigt.

Ist mein Problem jetzt verständlich formuliert ?

mit danke im voraus ...

[Beta-User]

"attr global language" aendert ausschliesslich die angezeigte Hilfe.

Nicht (mehr) ganz richtig: Der WeekdayTimer nimmt seit einiger Zeit daraus auch die Vorgabe, ob deutsche oder englische Wochentagsbezeichnungen verwendet werden sollen .

[rudolfkoenig]

Code Auswählen Erweitern

Ist mein Problem jetzt verständlich formuliert ?
Mit dem aktuellen Code ist es nicht moeglich, Dez statt Dec anzuzeigen.
Ist meine Antwort jetzt verstaendlich formuiert?

Meines Wissens gibt es in FHEM ausser der Hilfe keine "Lokalisierung" (bis auf wenige Ausnahmen, siehe Beta-Users Antwort).

[Christoph Morrison]

Nicht (mehr) ganz richtig: Der WeekdayTimer nimmt seit einiger Zeit daraus auch die Vorgabe, ob deutsche oder englische Wochentagsbezeichnungen verwendet werden sollen .

Daytime und Buienradar richten ihre Ausgaben auch nach der eingestellten Sprache, ich glaub Daytime unterstützt sogar ein gutes dutzend Sprachen.

[meldelinie]

Hallo Rudolf,

Mit dem aktuellen Code ist es nicht moeglich, Dez statt Dec anzuzeigen.
Ist meine Antwort jetzt verstaendlich formuiert?

Ihr wollt mich doch auf den Arm nehmen, oder ?

Ihr macht hier soviele geniale Sachen und es hat bisher noch niemand gestört, das SVG keine deutschen Wochentage und Monatsnamen anzeigt ? 

Also hier mein Patch für automatisch korrekte Lokalisierung von SVG mit Wochentagen und Monatsnamen in deutsch, englisch, Französisch, ...

Die UTF-8 Kodierung für dem Umlaut im März und dem französichen Akzent akute ist auch mit drin.

[CoolTux]

Nicht getestet aber wenn das funktioniert.

RESPEKT

So stellen wir uns das hin und wieder vor. Nicht kleckern sondern klotzen. Vielen lieben Dank!!!

[rudolfkoenig]

Ich habe es getestet, der Patch ist elegant, und es funktioniert.
Mir ist noch nicht klar, in welchem Fall encode notwendig ist, bei mir scheint es auch ohne perfekt zu funktionieren.

ABER: der Ausloeser ist die LANG (bzw. LC_TIME) Umgebungsvariable (attr global language ist wirkungslos), d.h. nach dem update wird die Darstellung bei etlichen Anwender sich aendern, und ein Benutzer mit wenig Unix-Erfahrung wird seine Schwierigkeiten haben, es zu fixen.

Deswegen bin ich unsicher, ob ich es einbauen soll. Meinungen?

[CoolTux]

Es geht ja nur rein um die Darstellung, und diese wird sich wenn dann doch nur in die eingestellte Landessprache ändern. Im schlimmsten Fall bekommt ein Deutscher es also deutsch als Beispiel. Ich sehe das jetzt nicht als schlimm an.


Grüße

[rudolfkoenig]

Mir ist noch nicht klar, in welchem Fall encode notwendig ist, bei mir scheint es auch ohne perfekt zu funktionieren.

encode wird benoetigt bei "LC_TIME de_DE.iso8859-1", macht die Darstellung aber fuer "LC_TIME de_DE.utf-8" kaputt, da braucht man kein encode.
=> Falls ich den patch anwende (egal ob mit oder ohne encode), wird es Benutzer geben, bei denen die Darstellung ploetzlch kaputt ist.

Bin nicht sicher, ob ich immer richtig rauskriege ob ich encode verwenden soll oder nicht.
Vorschlaege?

[CoolTux]

encode wird benoetigt bei "LC_TIME de_DE.iso8859-1", macht die Darstellung aber fuer "LC_TIME de_DE.utf-8" kaputt, da braucht man kein encode.
=> Falls ich den patch anwende (egal ob mit oder ohne encode), wird es Benutzer geben, bei denen die Darstellung ploetzlch kaputt ist.

Bin nicht sicher, ob ich immer richtig rauskriege ob ich encode verwenden soll oder nicht.
Vorschlaege?

Eine andere Art Lösung? Zum Beispiel über ein Mapping und dann schauen welche Sprache in global aktiv ist?

[frank]

wäre es nicht flexibler, wenn man eine language einstellung im web device ansiedeln würde, um auch mehrsprachige haushalte unterstützen zu können?

bei allen, die das neue attribut nicht haben, bleibt alles wie bisher.

[CoolTux]

wäre es nicht flexibler, wenn man eine language einstellung im web device ansiedeln würde, um auch mehrsprachige haushalte unterstützen zu können?

bei allen, die das neue attribut nicht haben, bleibt alles wie bisher.

Ich bin der Meinung das die Sprache nach global gehört und nicht noch eine weitere Einstellung dafür her sollte.

[Christoph Morrison]

wäre es nicht flexibler, wenn man eine language einstellung im web device ansiedeln würde, um auch mehrsprachige haushalte unterstützen zu können?

Eine sehr gute Idee.

[rudolfkoenig]

Jungs, gute Ideen habe ich auch viele, ich muss aber leider auch an die Umsetzung denken, und die Folgen ausbaden, siehe oben.

Zum Beispiel über ein Mapping und dann schauen welche Sprache in global aktiv ist?

Mit Mapping in SVG Modul nach dem Motto "Mar=>Mär, "Dec"=>"Dez", etc fange ich nicht an.

Ich habe nichts gegen die Einfuehrung einer FHEM-Lokalisierung, aber dann mit mit FrameWork und globalen Uebersetzungsdateien.
ABER: ich weiss aus Erfahrung, was das bedeutet, und ich werde nicht die treibende Kraft dahinter sein, noch werde ich fuer Uebersetzungen sorgen. Hoechstens bei exotischen Sprachen
Und ich freue mich schon auf Meldungen ala "Notify funktioniert nicht: keine Zuendhoelzer"

[meldelinie]

Hallo,

Darf ich kurz zusammenfassen ?

Problem 1: Umlaute ohne Codierung in UTF-8

Das Problem ist bei mir z.B. der März mit dem A-Umlaut. Wenn ich einen Plot mit März drin habe und nicht nach UTF-8 wandle, bekomme ich in Chrome auf dem Windows PC und mit der FullyBrowser App auf meinem Android 6 Tablet einen Fehler im Browser angezeigt "This page contains the following errors: error on line 270 at column 38: Encoding error. Below is a rendering of the page up to the first error.". Ich habe noch Firefox ausprobiert, da sieht man ohne UTF-8 im März ein komischen Sonderzeichen.

Vorschlag:

Im Deutschen bei ist Wochentagen und Monaten einzig der März ein Problem.
Also kein Stress machen und böses non ASCII Binäerzeugs was strftime rausspukt rausfltern. Safety first 
Das einzige was bei DE passiert, ist das der dritte Monat dann ein "Mrz" ist. Das ist sogar DIN konform ! Kein UTF-8 nötig, ASCII geht immer.

Problem 2: Lokaliserung des Hosts wird zur Sprachauswahl benutzt

Ich habe einfach die eingestellte Lokalisierung benutzt. Ein Server mit Lokalisierung DE schiebt also deutsche Monate an die Webclients. Wenn keine Lokalisierung eingestellt ist, bleibt es bei englisch. Das Umstellen im Betriebssystem ist fuer Laien nicht simpel und vielleicht will der deutsche Nutzer mit Startrek Theme auf jeden Fall englisch  - ungefragt was ändern ist nicht nett.

Vorschlag:

Ich habe gerade mal gespickt wie die anderen Module es mit deutschen Wochentagen machen - das wird das Attribut "language" im Modul abgefragt, wenn DE dann Lokalisierung auf DE ansonsten auf EN. Die Formatierung des Wochentages erledigt wie bei meinem Patch einfach strftime aus der Lokaliserung des OS per "%a". Und am Ende wird es wieder brav auf die ursprüngliche Einstellung zurückgestellt.

Könnte man dann mit mehreren Rückfallebenen machen: Prüfen ob "language" im Modul gesetzt ist (hier SVG), wenn nicht beim parent (hier FHEMWEB) gucken, wenn auch da nichts steht bei global nachsehen ?
Die ganzen Abfragen passieren jeweils nur einmal bei der Initiliasierung - also keine Prozessorbremse.

Bei allen Vorschlägen würde nur DE unterstützt - ansonsten gibt es wie vorher EN.

Kleine Ziele setzen, die ereichbar sind 

Wären die Lösungsvorschläge akzeptabel zur offiziellen Aufnahme in FHEM ?

[meldelinie]

Ich wollte das Thema nochmal aus der Versenkung holen ...

Rudolf, wäre der Lösungansatz akzeptabel - Ich wuerde mich dann an einem besseren Patch versuchen ?

[rudolfkoenig]

Rudolf, wäre der Lösungansatz akzeptabel - Ich wuerde mich dann an einem besseren Patch versuchen ?

Es geht nicht um den Patch: die LANG/LC_TIME Loesung ist kaputt in manchen Konfigurationen, und ich wollte nicht mit einer Modul-Eigenen Uebersetzungstabelle anfangen, aus Prinzip.

Da ihr aber so hartnaeckig seid beim ignorieren meines Prinzips, habe ich es aufgegeben, und eine Modul-Eigene Monat-Uebersetzung eingebaut.
Wird bei "attr global language DE" aktiviert.

[krikan]

Ich habe nichts gegen die Einfuehrung einer FHEM-Lokalisierung, aber dann mit mit FrameWork und globalen Uebersetzungsdateien.

Ganz gefährliches Glatteis , aber:
Gibt es so etwas in der Art nicht schon? Zumindest ist https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/UConv.pm in FHEM enthalten und dort ist für diverse Sprachen auch eine Übersetzung für Wochentage enthalten.

Gruß, Christian

[rudolfkoenig]

Gibt es so etwas in der Art nicht schon?

Scheint so, aber:
- mAn sollte eine Einheitenkonvertierung sich nicht auch mit Uebersetzung beschaeftigen
- wenn man sich um Uebersetzung kuemmert, dann sollte der Text in einem Fromat gepflegt sein, was ein Uebersetzungsbuero annimt (xliff, etc)
- ich habe nicht rausgekriegt, wie ich mit "vernuenftigen" Aufwand an die benoetigten Uebersetzungen komme.

Will sagen, UConv ist fuer mich keine sinnvolle Alternative.
Vielleicht haette ich damit gar nicht anfangen sollen, jetzt meinen bestimmt alle, so gehoert sich das.
=> Nein.