Sprachversions-Datumsformat entspricht nicht Landesgepflogenheit: wie anpassen?

K

Kukkatto

Erfahrenes Mitglied
40
Problem/Situation: jedes Land hat sein eigenes Datumsformat bzgl. Reihenfolge von Tag, Monat und Jahr wie auch des Trennzeichens. Im Deutschsprachigen Raum ist es die Reihenfolge Tag/Monat/Jahr und das Trennzeichen der Punkt – aber auch in der französischsprachigen und italienischsprachigen Schweiz wird dieses Format genutzt, auch wenn in Frankreich und Italien ein anderes Format genutzt wird (Schrägstriche, in Frankreich auch Bindestriche statt Punkte).

In der Folge sollte man erwarten, daß beim Datumsformat jeweils folgendes herauskommt,wenn man die entsprechende Spracheinstellung wählt:

Deutsch (Deutschland): TT.MM.JJJJ
Deutsch (Schweiz): TT.MM.JJJJ
Französisch (Frankreich): TT-MM-JJJJ
Französsich (Schweiz): TT.MM.JJJJ
Italienisch (Italien): TT/MM/JJJJ
Italienisch (Schweiz): TT.MM.JJJJ
Englisch (Indien): TT-MM-JJJJ
Englisch (Deutschland): TT.MM.JJJJ
Englisch (Frankreich): TT-MM-JJJJ
Englisch (Italien): TT/MM/JJJJ
Englisch (Schweiz): TT.MM.JJJJ
usw. usf.

Das ist das, wie es sein sollte.

Nun ist es aber anders! Stellt man z.B. Deutsch (Schweiz) ein, so kommt korrekterweise TT.MM.JJJJ; stellt man aber Französisch (Schweiz), Italienisch (Schweiz) oder Englisch (Schweiz) ein, so erscheint die Form TT/MM/YYYY ...

Die Reihenfolge kann jeweils auf alle drei gebräuchlichen Varianten gestellt werden (TMJ, MTJ, JMT) – als Trennzeichen steht aber nicht das korrekte zur Verfügung.

Nun die springende Frage: wer hat gepatzt? Google, die das nicht korrekt zusammengestellt haben? Oder der Gerätehersteller, der nur teilweise oder nicht vorhandene Felder auffüllt? Oder gar der Branding-Provider, der allfällige Fehler ausbügeln müßte?

Bei der Frage geht es nicht darum, wer anzuschwärzen wäre, sondern bei wem man nachzuhaken hat, um einen allfälligen Bugfix zu verlangen.

Eine weitere Frage ist natürlich auch: wie kann man (als Nutzer) das korrigieren (daß man z.B. das Gerät auf Englisch (Deutschland) stellt und dann die korrekte Reihenfolge und das korrekte Trennzeichen erhält, wenn das nicht mit einem Firmware-Update bereinigt wird. Was bräuchte es da für Aufwand?

Eine bisherige Herstellerantwort war, daß das so (falsch) programmiert sei und nicht geändert werden könne ... So eine Antwort ist natürlich nicht wirklich brauchbar.
 
Zuletzt bearbeitet:
Darf ich höflich fragen, was die Intention dieses Posts ist, eine Feststellung, eine Fragestellung ans Forum mit der Bitte zur Umprogrammierung des Datumformats? Zum Teil werden die Fragen durch Dich schon selbst beantwortet und somit drehen wir uns gerade ein wenig im Kreis.

Mfg, ST
 
Zuletzt bearbeitet:
1. Ich will wissen, wer anzusprechen und bei wem Stunk zu machen ist (den Branding-Provider, den Geräte-Hersteller (der die Android-Version gerätespezifisch anpaßt) oder Google (als Android-Plattform-zur-Verfügung-Steller), daß die bitte gefälligst das Datum auch korrekt und länderspezifisch implementieren, wenn sie schon eine länderspezifische Spracheinsellung anbieten!

Dabei will ich vermeiden, von Pontius zu Pilatus geschickt zu werden, wenn ich das Problem einmal nach oben trage. Die o.g. Herstellerantwort sagt nämlich nichts darüber aus, ob dieser schon falsche Vorgaben von oben erhalten hat, oder ob er selbst nicht das passende Format der entsprechenden Sprache zugeordnet hatte.

2. Sollte das Android-System so flexibel sein, daß man das mit einfachen Mitteln selbst ändern könnte (und die entsprechenden spracheintellungsspezifischen Datumsformatfestlegungen selbst editieren können sollte), wäre ich natürlich auf Hinweise aus, wie das zu bewerkstelligen wäre.
 
Geht es dir um das Prinzip oder bist du von diesem Bug unmittelbar betroffen? Wohnst also in der englischsprechenden Schweiz und das Datum wird falsch angezeigt.
 
Es gibt hier drei Möglichkeiten:

1. Du setzt dich mit dem Hersteller und deren Entwicklungsabteilung in Verbindung und fragst nach, ob man das Datumsformat speziell an Deine Bedürfnisse anpassen kann.

2. Du lernst einen Satz Programmiersprachen (Java, smali/backsmali, C) und änderst das selber um. Natürlich kannst Du auch dein System ganz umschreiben und es neu benennen. ;)

3. Du kaufst Dir ein Iphone, WinPhone oder eines, welches noch unter Symbian läuft. Vielleicht findest Du da entsprechende Formatlösungen.

Halten wir fest, dass eine Änderung eines Systems schon einiger Schritte bedarf, die wohl überlegt sein wollen. Dass die Sprache geändert werden kann, sollte Dir aber nicht entgangen sein und somit auch das Format. Probier es einfach aus und berichte. (am Beispiel Samsung: Einstellungen -> Sprache und Eingabe -> Sprache; Datum und Uhrzeit -> Datumsformat auswählen (hier 3 Möglichkeiten))
 
LouCipher schrieb:
Geht es dir um das Prinzip oder bist du von diesem Bug unmittelbar betroffen? Wohnst also in der englischsprechenden Schweiz und das Datum wird falsch angezeigt.
Es geht um Evaluation und Bereitstellung von Geräten, die dann u.a. in den Sprachen Deutsch, Französisch, Italienisch und Englisch genutzt werden und in allen Sprachen das korrekte Datumsformat (mit Punkten) anzeigen müssen. Da die Geräte über eine Längere Zeit im Einsatz stehen werden und Nachlieferungen mit einer neueren Firmware genauso die Vorgaben erfüllen müssen, stellt sich die Frage, ob die Korrektur einer falschen Vorgabe des Herstellers mit einfachen Mitteln zu bewerkstelligen wäre – oder ob infolge von Unflexibilität die Finger von Android gelassen und stattdessen einem anderen System (iPhone, Windows-Phone oder was auch immer) der Vorzug gegeben werden sollte.

Der ursprüngliche Beitrag von 11:11 Uhr wurde um 11:23 Uhr ergänzt:

SavanTorian schrieb:
Dass die Sprache geändert werden kann, sollte Dir aber nicht entgangen sein und somit auch das Format.
Dir aber wohl schon ... v.a. auch, daß das Format nicht den enstprechenden Gepflogenheiten entspricht.

SavanTorian schrieb:
Probier es einfach aus und berichte. (am Beispiel Samsung: Einstellungen -> Sprache und Eingabe -> Sprache; Datum und Uhrzeit -> Datumsformat auswählen (hier 3 Möglichkeiten))
Wer lesen und verstehen kann, ist klar im Vorteil – Du offenbar nicht, zumindest nicht einmal den Eingangsthread; dort ist nämlich alles aufgeführt.
 
Zuletzt bearbeitet:
Kukkatto schrieb:
die dann u.a. in den Sprachen Deutsch, Französisch, Italienisch und Englisch genutzt werden und in allen Sprachen das korrekte Datumsformat (mit Punkten) anzeigen müssen.
Müssen sie das? Gibt es dazu etwa schon eine EU Vorschrift?
Mal ehrlich, ob Punkt oder slash, das ist doch mal sowas von egal.
Prinzipienreiterei, nichts weiter. Sorry.
 
  • Danke
Reaktionen: Peter B.
xminister schrieb:
Prinzipienreiterei, nichts weiter. Sorry.

Naja, ist schon peinlich das 2013 i18n immer noch so ein Problem ist. Bei mir wird die Postleitzahl hinter dem Ort angezeigt. Sowas darf heutzutage einfach nicht mehr vorkommen.

@Kukkatto: Es wird dir sehr viel Arbeit machen die notwendigen Infos zu erhalten. Du musst erstmal rausfinden in welcher Datei diese Definitionen stecken. Dann ob sie zum Linux System oder zum Android System gehört.
Also erstmal in den Android GITs wühlen. Hier ist wohl RTFS angesagt.
Und am Ende bringt es nix weil Hersteller wegen sowas kein Update rausbringen.

cu
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Kukkatto
xminister schrieb:
Ja, müssen sie; denn nicht nur Eingabemasken verlangen i.d.R. explizit das jeweils landesspezifische Trennzeichen, ansonsten die Angabe als ungültig verworfen wird! Und im deutschsprachigen Raum (incl. der gesamten Schweiz, auch der nichtdeutschsprachigen) ist das Trennzeichen der Punkt und weder der Schrägstrich, noch der Bindestrich!

xminister schrieb:
Gibt es dazu etwa schon eine EU Vorschrift?
1. ist die Schweiz nicht in der EU und müßte sich nicht um eine allfällige EU-Vorschrift kümmern – und 2. hat so gut wie jeder Staat gesetzliche Vorschriften, in welcher Form Datumsangaben zu machen sind, damit sie als gültig anerkannt und korrekt verstanden werden.

xminister schrieb:
Mal ehrlich, ob Punkt oder slash, das ist doch mal sowas von egal.
Nein, ist es nicht – s.o.!

xminister schrieb:
Prinzipienreiterei, nichts weiter. Sorry.
Nein – sondern genau dort fängt das Problem des Turmbaus zu Babel an; das ist eine Konvention, an die sich die Nutzer zu halten haben – und zwar aus dem einfachen Grund, damit das dann auch richtig verstanden wird.

Auf das Problem der Reihenfolge MTJ muß ich wohl nun nicht zu sprechen kommen – oder welcher Tag ist mit dem 01.02.03 gemeint??? Eben!

rihntrha schrieb:
Naja, ist schon peinlich das 2013 i18n immer noch so ein Problem ist.
Nicht nur das; noch viel peinlicher ist, daß diese eigentlich einfache Vorgabe der verschiedenen Varianten nicht genügend flexibel implementiert ist. Könnte nämlich das Trennzeichen separat gewählt werden, würde sich das Problem nicht mehr wirklich stellen.

rihntrha schrieb:
Bei mir wird die Postleitzahl hinter dem Ort angezeigt. Sowas darf heutzutage einfach nicht mehr vorkommen.
Völlig untauglich ...

rihntrha schrieb:
@Kukkatto: Es wird dir sehr viel Arbeit machen die notwendigen Infos zu erhalten. Du musst erstmal rausfinden in welcher Datei diese Definitionen stecken. Dann ob sie zum Linux System oder zum Android System gehört.
Ich hoffte, daß zumindest letzteres schon irgendwer rausgefunden haben könnte; offenbar leider doch nicht ... Ich könnte mir aber vorstellen, daß der enstprechende Austausch der zugehörigen Dateien gegen die mit dem korrekten Format dann nicht mehr soo eine Hexerei bedeuten dürfte. Ich kenne das Android-System aber noch nicht wirklich. Aber danke für den Hinweis ...
 
Zuletzt bearbeitet:
Hi, könnt ihr mich mal aufklären, ich versteh die ganze Aufregung hier nicht. Bei meinem Handy mit 4.1.2 wird der Monat in der Statusbar und auch auf dem Lockscreen ausgeschrieben in jedem Format, da ist das doch völlig Wurst, welches Format, oder?
 
Hallo Kakkutto,

Die Anpassung an französisch-schweizerisch, italienisch-schweizerisch wäre für den Programmierer des Herstellers kein größeres Problem.

Die Basis-Dateien werden zwar von google bereitgestellt, aber vom Hersteller und dessen Developern an das jeweilige Android-Gerät angepasst.

Handelt es sich um ein gebrandetes Gerät, dann berücksichtigt der Hersteller eventuell noch die Wünsche des Providers.

Legt der Hersteller des Gerätes fest, das dieses Gerät auch schweizerisches-Französisch sein soll, wird wenn der Hersteller sehr sauber arbeitet ein Schweizer Developer mit der Implementierung der notwendigen Änderungen beauftragt.

Da manche Hersteller das aus Kostengründen jedoch nicht machen, kann es sein das einfach die französischen Dateien genommen werden, und in schweizerisch-Französisch durch umbenennen eines Ordners in den entsprechenden Ländercode umgelabelt wird.

Den herstellereigenen Developern sind die Eigenheiten der jweiligen Landessprache sowie deren Zeit- und Datumsformate in der Regel unbekannt. Für eine chinesischsprachigen Developer ist französisch und schweizerisches französisch dasselbe da ihm der Bezug zu dieser Sprache fehlt.

Bekommt der Developer die Information das die deutschsprachigen Datum- und Zeitfiles mit den sonstigen französischen Files zu mischen sind um schweizerisch-französisch zu erhalten wird er es umsetzen.

Bekommt er die Info nicht oder wird die Umsetzung der schweizerisch-französischen Sprachunterstützung als unwichtig erachtet (wo wem auch immer), dann bleibt der Fehler auch bei bei regelmäßigen System-Updates durch den Hersteller erhalten.

Um die Änderungen auf scheizer-französisch durchzuführen, müsste in z.B. in der Framework-res.apk ein Ordner angelegt im Verzeichnis res/values-de/ (de habe ich ich als Beispiel genommen) in die entsprechenden xml-Dateien arrays.xml, plurals.xml und strings.xml abgelegt werden.
Wobei die plurals.xml und arrays.xml französisch sein müsste, die strings.xml müsste eine Mischung zwischen deutsch (Zeit-, und Datumsformat) und französisch (Wochentagsbezeichnung und sonstigem Texten) sein.

Dies ist bei allen relevanten Dateien des Betriebssystem zu wiederholen.
 
  • Danke
Reaktionen: Kukkatto
@HirogenX: Es geht u.a. auch um das Darstellungsformat, das in Dateimanagern wie Total-Commander bei jeder Datei und bei jedem Verzeichniseintrag angezeigt wird. Es geht somit um die systemweite Darstellung des Datums. Es geht aber – wie schon angetönt – auch um Eingabemasken, die ein Kalenderdatum verlangen und das dann in der korrekten Schreibweise (incl. den korrekten Trennzeichen) einzugeben ist. Und es ist eben nicht korrekt, wenn das länderspezifisch genutzte Zeichen der Punkt ist, in der Eingabemaske dann aber ein Schrägstrich oder Bindestrich verlangt wird und bei Eingabe eines Punktes die Eingabe als ungültig verworfen wird. Das hat zur Folge, daß die Leute, die das dann nutzen müssen, nicht wissen, weshalb ihr korrekt (nach Landesvorgabe) eingegebenes Datum vom Format TT.MM.JJJJ als ungültig abgelehnt wird und die gesamte Eingabeprozedur nicht durchgeführt werden kann. Die kommen nicht nur nicht auf die Idee, daß eben als Datumsformat etwas völlig unübliches (wie Schrägstriche oder Bindestriche) einzugeben sind – von denen kann das auch überhaupt nicht verlangt werden, wissen zu müssen, daß da eben falsche Zeichen verlangt werden. Und wenn eine Sprache mit dem Land bezeichnet ist, dann hat bei der Einstellung auch das entsprechende Format zur Geltung zu kommen.
 
Zuletzt bearbeitet:
Ah/ so/ jetzt/ ich/ verstanden
 
rihntrha schrieb:
Und am Ende bringt es nix weil Hersteller wegen sowas kein Update rausbringen.
Klar bringen die deswegen nicht gleich eine neue Firmware raus; aber bei (resp ab) der nächsten, die ohnehin ansteht, könn(t)en sie das dann gleich mit berücksichtigen.
 
Um der Sache jetzt mal Aufklärung zu bringen:

Es war ein Aufwand von weniger als 5 Minuten, rauszufinden, wo das Datum-Format festgelegt wird:

Es kommt aus den AOSP-Sourcen (Google's Android-OpenSource-Project, der Basis für Android). Es ist in einer (Sprache und Region abhängigen) xml-Datei abgelegt, das für Deutsch-Deutschland zuständige Datums-Format wird in dieser XML-Code-Zeile beschrieben:

<string name="numeric_date_format">dd.MM.yyyy</string>

Diese Datei liegt in einem Bereich von AOSP, der vom Geräte-Hersteller überschrieben werden könnte, das halte ich aber eher für unwahrscheinlich.

Insofern würde ich empfehlen, die entsprechende Datei (für die Sprache/Länder Kombination wo Handlungsbedarf gesehen wird) aus den AOSP-Sourcen zu fixen und bei AOSP als Bug-Fix Vorschlag einzureichen, dann wird der Fehler für alle Geräte in Zukunft gefixt sein.

MfG Uwe
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: Kukkatto
BTW, es wäre natürlich schön, wenn sich im EDV-Zeitalter auch endlich mal alle an die ISO 8601 hielten. Dann wäre es nämlich vollkommen unerheblich wer welches Gerät mit welcher Software gerade wo in welcher Sprache bedient. Denn genau dazu wurde das Zeug nämlich schon um 1970, also eh erst vor mehr als 40 Jahren, genormt! Aber wieso einfach, wenn's auch blöde geht?
 
Warum? Intern wird es eh sprachneutral gespeichert. Zur Eingabe/Anzeige wird das (im System eingestellte) landesübliche Format verwendet.

Ist eine Ausgabe in xxxy-mm-tt notwendig, z.B. für die Ausgabe in Textdateien und einfaches sortieren) kann die Software es ja tun.

Das sich jetzt alle eine bestimmte Schreibweise angewöhnen nur damit es Software einfacher hat ist ne seltsame Idee. Genauso könnte man ja fordern Umlaute abzuschaffen weil Ami Software gerne mal zu blöd dafür ist ;)

cu
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: jna
email.filtering schrieb:
BTW, es wäre natürlich schön, wenn sich im EDV-Zeitalter auch endlich mal alle an die ISO 8601 hielten.
Das haut nicht hin, weil sich an der Oberfläche niemand daran halten würde. Für die interne Abspeicherung wäre das aber vertretbar; da wird aber ohnehin sowas gemacht.
email.filtering schrieb:
Dann wäre es nämlich vollkommen unerheblich, wer welches Gerät mit welcher Software gerade wo in welcher Sprache bedient. Denn genau dazu wurde das Zeug nämlich schon um 1970, also eh erst vor mehr als 40 Jahren, genormt! Aber wieso einfach, wenn's auch blöde geht?
Ja, und seit 40 Jahren ist das ganze fast toter Buchstabe und wird nur in speziellen Anwendungen umgesetzt – und auch nur dann, wenn das technikaffine Leute in den Fingern haben.

rihntrha schrieb:
Warum? Intern wird es eh sprachneutral gespeichert. Zur Eingabe/Anzeige wird das (im System eingestellte) landesübliche Format verwendet.
Richtig – nur (und genau das ist ja das Thema hier) muß dann das als das "landesüblich" deklarierte Format auch wirklich das landesübliche Format sein ...

rihntrha schrieb:
Ist eine Ausgabe in xxxy-mm-tt notwendig, z.B. für die Ausgabe in Textdateien und einfaches sortieren) kann die Software es ja tun.
I.d.R. sind die vorgegebenen Optionen sogar so, daß man alle drei üblichen Reihenfolgen (TMJ, JMT und MTJ) einstellen kann; das ist schon etwas – aber das Trennzeichen stimmt nicht mit dem landesüblichen überein.

rihntrha schrieb:
Das sich jetzt alle eine bestimmte Schreibweise angewöhnen, nur damit es Software einfacher hat, ist ne seltsame Idee.
Das war aber auch mit Motivation von ISO 8601; damit wollte man vermeiden, daß sich nicht nur Programmierer fehlerafälligen Verrenkungen hingeben müssen, sondern auch ohne Umarbeitung die Sortierung automatisch chronologisch erfolgen kann.

NB: die meisten Leute wissen gar nicht, daß überhaupt so ein offizielles Format existiert.

rihntrha schrieb:
Genauso könnte man ja fordern Umlaute abzuschaffen weil Ami Software gerne mal zu blöd dafür ist ;)

cu
Soche Tendenzen gab's durchaus – bis weit in die 1980er-Jahre gab's ja keine Umlaute auf vielen EDV-Anlagen und man mußte alles mit ae/oe/ue schreiben ... und da die Computerei per se für "fortschrttlich" deklariert wurde, wurde eben auch schreiben ohne Umlaute für erstrebenswert deklariert ... :bored:
 
Im Prinzip ist die ganze 'Internationalisierung' unnötig, und macht die Software unnötig fett und fehleranfällig.

Wer die Funktion der Bedienelemente nicht kapiert, wenn sie englisch benannt sind, kapiert bei Deutsch benannten Bedienelementen auch nicht viel mehr.

Datum und Zeit sind in den meisten Länder ohnehin unlogisch strukturiert:

Es müsste vom Großen zum Kleinen also 'YYYYMMDD HHmmss' notiert werden, denn bei jeder Zahl stehen die Hochwertigen Stellen und nicht hinten.

Grüße Uwe
 
Kukkatto schrieb:
@HirogenX: Es geht u.a. auch um das Darstellungsformat, das in Dateimanagern wie Total-Commander bei jeder Datei und bei jedem Verzeichniseintrag angezeigt wird.
Wenn es eher um die Praxis als ums Prinzip geht, ist die Frage sinnvoll, um welche Anwendungssituationen es geht, mit denen die 2 oder 10 oder 100 (?) Leute klarkommen müssen und vor falschen Daten beschützt werden müssen.

Schließlich kann man in nicht wenigen Apps das Datumsformat benutzerdefiniert einstellen, eben zum Beispiel auch bei Dateimanagern.
 

Ähnliche Themen

cehuisken
Antworten
1
Aufrufe
683
Andy
Andy
J
Antworten
1
Aufrufe
1.126
mblaster4711
mblaster4711
Foh
Antworten
8
Aufrufe
1.705
Foh
Foh
Zurück
Oben Unten