Sprachversions-Datumsformat entspricht nicht Landesgepflogenheit: wie anpassen?

[rihntrha]

Im Prinzip ist die ganze 'Internationalisierung' unnötig, und macht die Software unnötig fett und fehleranfällig.

Ich hoffe du bist kein Programmierer? Ganz ehrlich, Software von Leuten die so denken macht nur Ärger weil sie in der Praxis nix taugt. Das habe ich schon oft genug durch und da fehlt mir mittlerweile die Toleranz.
Da werden dann Zeitpunkte in lokaler Formatierung und in Lokalzeit gespeichert und man muss als Anwender erstmal debuggen weil der ganze rotz in der Praxis versagt.

Gerade die Tatsache das du denkst, das sowas Software fehleranfällig macht fände ich (falls du Entwickler bist) sonst sehr befremdlich.

cu

 

[Kukkatto]

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

Wenn an der Quelle schon das richtige und gültige Format eingerichtet wird, ist das gar nicht mehr nötig; separate Einstellung von Datumsformat ist ohnehin a) kompliziert und verwirrend für nicht-technikaffine Nutzer, und b) immer eine potentielle Quelle von Fehlern und Missverständnissen, v.a. auch bei der Implementierung ...

 

[u.k-f]

Ich bin zwar Entwickler, aber auch Nutzer, und ich spreche aus Erfahrung mit der Software, die ich nutze.

Das Prinzip der 'Internationalisierung' ist das, dass zusätzlich zum dem Binary Dateien mit den Texten abgelegt werden, eine für jede Sprache. Somit muss diese Datei beim Starten gelesen werden, im Speicher gehalten werden usw.

Die Anzeige muss entweder die Texte abscheiden, wenn sie zu lang sind (ist doof), oder die GUI-Elemente müssen auf die Länge der 'Längsten Übersetzung' voreingestellt sein (aber die Länge jeder Übersetzung ist zum Entwicklungszeitpunkt unbekannt, die Übersetzungen macht ja nicht der Entwickler), oder dynamisch angepasst werden, was Dynamisches Layout erfordert, sieht meist auch doof aus.

Das erzeugt zusätzlichen Aufwand, Speicherbedarf und Rechenleistung.

Jeder zusätzliche Aufwand macht das System komplexer und ist eine potentielle Fehlerquelle.

Und das für einen Nutzen, den ich nicht sehe, will sagen, für unnötig halte.

Ich benutze meine Geräte mit englischem Betriebssystem, das läuft nach meiner Erfahrung problemfreier.

Mir sind Leute, die nach Übersetzungen schreien, suspekt.

Guck Dir doch mal CWM an, das ist ein Spitzen Tool und ohne Übersetzung. Wer das nicht in Englisch bedienen kann, sollte von den Dingen die das Tool macht, sowieso besser die Finger weg lassen.

MfG Uwe

 

[rihntrha]

Das Prinzip der 'Internationalisierung' ist das, dass zusätzlich zum dem Binary Dateien mit den Texten abgelegt werden, eine für jede Sprache. Somit muss diese Datei beim Starten gelesen werden, im Speicher gehalten werden usw.

Die Anzeige muss entweder die Texte abscheiden, wenn sie zu lang sind (ist doof), oder die GUI-Elemente müssen auf die Länge der 'Längsten Übersetzung' voreingestellt sein (aber die Länge jeder Übersetzung ist zum Entwicklungszeitpunkt unbekannt, die Übersetzungen macht ja nicht der Entwickler), oder dynamisch angepasst werden, was Dynamisches Layout erfordert, sieht meist auch doof aus.

Ich kenne Android nicht gut. Unter Windows ist es so (und war schon vor Ewigkeiten so) das Strings und Dialog Templates (Und auch Bilder und beliebige binäre Dateien) unter meheren Sprachen in der exe (ist ja im Prinzip auch nur nen Archiv mit Codes und Resourcen wie eine apk) abgelegt werden können.

Greift das Programm darauf zu dann wird die best passende (zur aktuellen Systemsprache) in den Speicher geladen (ja, erst dann) und verwendet.
Und hier spielen ja auch solche Dinge rein das im deutschen Dialogtemplate die PLZ vor der Adresse steht und im englischen dahinter. Also nicht nur die Grösse sondern auch die Anordnung der Elemente ist sprachabhängig.

Wenn Android noch nicht mal solch grundlegende Dinge (wie z.B. Dialogtemplates (keine Ahnung wie das bei Android richtig heisst) in verschiedenen Sprachvarianten) bietet, dann hat Android hier halt versagt. Und sowas darf man durchaus kritisieren, weil heutzutage kann man perfektes i18n erwarten. Speicherplatz und Rechenleitung (das steht heutzutage massig zur Verfügung) wird heutzutage von den Programmen wegen jeden Schwachsinn sinnlos verschwendet, da mussen noch die paar Bytes für i18n drin sein.

Ich benutze meine Geräte mit englischem Betriebssystem, das läuft nach meiner Erfahrung problemfreier.

Ja, weil vielen Developern KnowHow/Erfahrung/Interesse an i18n fehlt

Guck Dir doch mal CWM an, das ist ein Spitzen Tool und ohne Übersetzung. Wer das nicht in Englisch bedienen kann, sollte von den Dingen die das Tool macht, sowieso besser die Finger weg lassen.

Sowas darf durchaus Englisch sein.

Aber in der GUI erwarte ich eine einheitliche und korrekte Darstellung gemäss meiner Systemeinstellung. Ist die Darstellung irgendwo fehlerhaft dann ist das entweder nen ToDo in der entsprechenden App (muss halt noch erst jemand übersetzen) oder nen Bug.
Das sieht doch aus wie gewollt und nicht gekonnt wenn man auf nem System nen wilden Mischmasch hat.

cu

 

[u.k-f]

In Android gibt es xml-Dateinen mit Texten, eine für jede Sprache, die dann in das Apk-File mit eingebunden werden. Das Datumsformat kommt aus der System-Ebene und wird auch in einer xml-Datei das Frameworks beschrieben siehe hier:

https://www.android-hilfe.de/forum/...genheit-wie-anpassen.464566.html#post-6288098

Es ist auch nicht mangelnde Kenntnis/Know-How, sondern es ist eher so, dass ich dafür keine Notwendigkeit sehe. Ich wollte auch kein Auto, das 5% seines Kraftstoffs dafür verschwendet, dass das Abgas als rosa Herzchenwolken rauskommt, nur weil es als ästhetischer angesehen wird. Und den Aufwand, den das Betriebssystem und die Entwickler zu treiben haben, damit die User nicht Englisch lernen müssen, halte ich für zu hoch.

Das Prinzip unter Windows alles in die Exe einzukompilieren sehe ich durchaus noch unter dem Prinzip 'Datei nebendrann zu legen, den im Code greift man auf die 'Einkompilierten Dateien so zu, fast als wären sie 'nebendran'.

Mf'G Uwe

 

[Kukkatto]

Wenn Android noch nicht mal solch grundlegende Dinge (wie z.B. Dialogtemplates (keine Ahnung wie das bei Android richtig heisst) in verschiedenen Sprachvarianten) bietet, dann hat Android hier halt versagt.

Es ist ja nicht mal so, daß es sie nicht bieten will – aber sie hauen dann nicht hin. Wenn nun ca. 240 englische Sprachvarianten angeboten werden (nicht nur für so gut wie alle UN-Länder, sondern auch für Südgeorgien, Macao, St. Helena – alles separat), so ist mindestens zu erwarten, daß die auch den entsprechenden lokalen Gepflogenheiten zu entsprechen haben – ansonsten sie eigentlich gar nicht separat aufzuführen wären. Ich will nun nicht dem Hersteller in die Schuhe schieben, gepatzt zu haben, wenn er die zwar vorhandenen, aber ungeprüften und wohl unangepaßten Länderfiles einfach übernommen hat; aber wenn er sie bringt, dann sollen sie auch stimmen.

Und sowas darf man durchaus kritisieren, weil heutzutage kann man perfektes i18n erwarten.

Richtig – schon gar bei (typographisch) ziemlich simplen Dingen wie dem Datumstrennzeichen (wo also die unterschiedlichen Sprachversionen nicht einmal groß unterschiedliche Zeichenlängen haben für dieselben Felder).

Speicherplatz und Rechenleitung (das steht heutzutage massig zur Verfügung) wird heutzutage von den Programmen wegen jeden Schwachsinn sinnlos verschwendet, da mussen noch die paar Bytes für i18n drin sein.

Wobei mir etwas mißfällt, das gegeneinander auszuspielen; i18n benötigt ja nur einmal etwas Festplattenplatz, Speicherplatz und minimale Rechenleistung; das sind ja nur simple Ersetzungen.

Ja, weil vielen Developern KnowHow/Erfahrung/Interesse an i18n fehlt

Wobei es nicht einmal nur das ist. Gerade bei so einem Beispiel zeigt sich, daß man sich zum einen nicht mal die Mühe macht, dem nachzugehen, wie das jeweils sein soll – und zum anderen es aber auch nicht ganz trivial ist, die ensprechene Stelle (in der staatlichen Verwaltung) zu finden, die dafür wirklich zuständig ist.

Aber eben: es hat einfach dazu zu gehören, daß man sich diese Mühe zu machen hat, wenn man etwas internationalisiert herausgeben will.

Sowas darf durchaus Englisch sein.

Jein; gewisse Leute haben einfach nicht nur keinen blassen Schimmer von der informationstechnischen Terminologie, sondern können sich auch nicht genügend zusammenreimen. Die haben einfach ungenügende fachspezifische (programmbedienungs- und steuerungsbezogene) Englischkenntnisse – und denen will man ja die Programme auch nicht vorenthalten.

Aber in der GUI erwarte ich eine einheitliche und korrekte Darstellung gemäss meiner Systemeinstellung. Ist die Darstellung irgendwo fehlerhaft dann ist das entweder nen ToDo in der entsprechenden App (muss halt noch erst jemand übersetzen) oder nen Bug.

Richtig – und der Hersteller hat sich die Mühe zu machen, das zu bereinigen. Kleinere Bugs kann's immer mal geben; aber grundlegend muß das schon hinhauen. Und wenn bei in klar definierten Sprache/Länder-Kombinationen danebengelangt wurde, dann ist etwas faul!

Das sieht doch aus wie gewollt und nicht gekonnt wenn man auf nem System nen wilden Mischmasch hat.

So wie die rätoromanische Spracheinstellung: da ist sogar in den Systemeinstellungen die hälfte noch auf englisch ...

---

In Android gibt es xml-Dateinen mit Texten, eine für jede Sprache, die dann in das Apk-File mit eingebunden werden. Das Datumsformat kommt aus der System-Ebene und wird auch in einer xml-Datei das Frameworks beschrieben siehe hier: https://www.android-hilfe.de/forum/...genheit-wie-anpassen.464566.html#post-6288098

Das heißt in der Quintessenz also: es wäre eigentlich ganz einfach, ein korrektes sprachen-/länderspezifisches File bereitzulegen.

Es ist auch nicht mangelnde Kenntnis/Know-How,

Da erhebe ich aber Einspruch: es ist v.a. mangelnder Wille desjenigen, der das eigentlich tun müßte, sich soweit mit dem Thema zu befassen, daß das dann auch richtig rauskommt. Das grundlegende Know-How wäre wohl schon vorhanden, aber aus Bequemlichkeit wird das einfach mal unter den Tisch gewischt – davon ausgehend, daß das wohl nicht notwendig sein wird.

sondern es ist eher so, dass ich dafür keine Notwendigkeit sehe.

Du nicht – aber die ist durchaus gegeben; und zwar nicht nur aus ästhetischen Gründen. Gerade beim Beispiel der Datumseingabe, die mit Punkten erwartet wird, aber das Programm es mit Schrägstrichen erwartet, ist eben die Notwendigkeit gegeben!

Ich wollte auch kein Auto, das 5% seines Kraftstoffs dafür verschwendet, dass das Abgas als rosa Herzchenwolken rauskommt, nur weil es als ästhetischer angesehen wird.

Nein – aber Du würdest Dich weigern, hier im deutschsprachigen Raum mit einem Auto herumzufahren, das ausschließlich Meilen auf dem Tacho hat (und nicht noch zusätzlich km) – denn dann würdest Du an jeder Ecke eine Buße einfangen, weil die Geschwindigkeit eben nicht mit einem Orientierungsstrich auf dem Tachometer abgeglichen werden könnte.

Genau darum geht es hier!

Und den Aufwand, den das Betriebssystem und die Entwickler zu treiben haben, damit die User nicht Englisch lernen müssen, halte ich für zu hoch.

Einspruch! Gerade, wenn i18n sauber implementiert wird und das "nur" mit Austauschfiles geschehen kann, ist der Aufwand i.d.R. durchaus überschaubar.

Und wenn der Anbieter schon eine (bestimmte) Sprach-/Länderkombination anbietet, dann hat die auch korrekt zu sein!

Das Prinzip unter Windows alles in die Exe einzukompilieren sehe ich durchaus noch unter dem Prinzip 'Datei nebendrann zu legen, den im Code greift man auf die 'Einkompilierten Dateien so zu, fast als wären sie 'nebendran'.

Wie die Ausführung auf ausführungtechnischer Ebene im Detail aussieht, ist für den Anwender völlig irrelevant; bei dem muß es nur korrekt (und seinen Gepflogenheiten entsprechend) aussehen resp. dargestellt werden. Mehr erwartet der nicht – aber das darf der berechtigterweise erwarten!

 

[u.k-f]

Das heißt in der Quintessenz also: es wäre eigentlich ganz einfach, ein korrektes sprachen-/länderspezifisches File bereitzulegen.

Genau dieses wollte ich in dem verlinkten Beitrag darlegen! Wenn jemand das entsprechende File korrigiert, und an das AOSP-Team übermittelt, würde das Problem damit für immer gelößt werden.

Ich weise jedoch darauf hin: Damit das so funktioniert, ist das ziemlich aufwendig implementierte Basis-Framework, das AOSP mitliefert, nötig!

Da erhebe ich aber Einspruch: es ist v.a. mangelnder Wille desjenigen, der das eigentlich tun müßte, sich soweit mit dem Thema zu befassen, daß das dann auch richtig rauskommt. Das grundlegende Know-How wäre wohl schon vorhanden, aber aus Bequemlichkeit wird das einfach mal unter den Tisch gewischt – davon ausgehend, daß das wohl nicht notwendig sein wird.

Es ist ja nicht eine Frage der Bequemlichkeit sondern der Effizienz. Wenn ich eine bestimmte Zeit damit verbringe Software zu entwickeln, dann kommt eine bestimmte Menge dabei raus, wenn ich 20% der Zeit mit sinnfreien Features verschwende, kommen 20% weniger sinnvolle Features raus. So einfach ist das

Un die Belastung des Systems darf man auch nicht außer Acht lassen. Allein der Speicherbedarf der Übersetzungsfiles ist nicht ohne!

Das negativ besetzte Wort Bequemlichkeit sehe ich eher auch der anderen Seite...

Du nicht – aber die ist durchaus gegeben; und zwar nicht nur aus ästhetischen Gründen. Gerade beim Beispiel der Datumseingabe, die mit Punkten erwartet wird, aber das Programm es mit Schrägstrichen erwartet, ist eben die Notwendigkeit gegeben!

Wer erwartet den Punkte?

Nein – aber Du würdest Dich weigern, hier im deutschsprachigen Raum mit einem Auto herumzufahren, das ausschließlich Meilen auf dem Tacho hat (und nicht noch zusätzlich km) – denn dann würdest Du an jeder Ecke eine Buße einfangen, weil die Geschwindigkeit eben nicht mit einem Orientierungsstrich auf dem Tachometer abgeglichen werden könnte.

Genau darum geht es hier!

Glaubst Du wirklich, ich wäre nicht in der Lage, 'On-The-Fly' MPH in KM/h umzurechnen? Man muss doch nur die Anzeige mal 1,6 nehmen, damit habe ich gewisslich keine Probleme.

Aber wo gerade an dem Thema sind, genau das ist doch ein weiteres Beispiel, wie sinnfrei es ist, dass nicht global einheitlich sondern Länderspezifisch implementiert wird.

Einspruch! Gerade, wenn i18n sauber implementiert wird und das "nur" mit Austauschfiles geschehen kann, ist der Aufwand i.d.R. durchaus überschaubar.

Wie kann jemand, der nicht weiß, wie etwas implementiert wird, Aussagen über den Aufwand machen?

Und wenn der Anbieter schon eine (bestimmte) Sprach-/Länderkombination anbietet, dann hat die auch korrekt zu sein!

Da sind wir wieder beim dem Punkt: Hätte man i18n weggelassen, gäbe es das Problem gar nicht...

Wie die Ausführung auf ausführungtechnischer Ebene im Detail aussieht, ist für den Anwender völlig irrelevant; bei dem muß es nur korrekt (und seinen Gepflogenheiten entsprechend) aussehen resp. dargestellt werden. Mehr erwartet der nicht – aber das darf der berechtigterweise erwarten!

Dieser Beitragsteil war nur zur Klärung an rihntrha gedacht, dass andere User das nicht interessiert, war klar...

 

[Kukkatto]

Wenn jemand das entsprechende File korrigiert, und an das AOSP-Team übermittelt, würde das Problem damit für immer gelöst werden.

Wie aufwendig wäre das? Die eigentliche Arbeit, die entsprechende(n) Datei(en) anzupassen wird wohl v.a. ein gehöriges Stück Fleißarbeit sein ... Was braucht es da aber für Installationen (auf dem eigenen Computer), damit man überhaut da rankommt, um das dann anzupassen?

Ich weise jedoch darauf hin: Damit das so funktioniert, ist das ziemlich aufwendig implementierte Basis-Framework, das AOSP mitliefert, nötig!

Dort in deren Forum eine entsprechende Diskussion zu eröffnen würde nicht den erwarteten Effekt haben?

Es ist ja nicht eine Frage der Bequemlichkeit sondern der Effizienz. Wenn ich eine bestimmte Zeit damit verbringe Software zu entwickeln, dann kommt eine bestimmte Menge dabei raus, wenn ich 20% der Zeit mit sinnfreien Features verschwende, kommen 20% weniger sinnvolle Features raus. So einfach ist das.

Daß Effizienz essentiell ist, streitet ja niemand ab. Daß aber korrekte Datums- und Zeitformate als "sinnfreies Feature" bezeichnet wird, kann ich schlicht nicht nachvollziehen!

Und die Belastung des Systems darf man auch nicht außer Acht lassen. Allein der Speicherbedarf der Übersetzungsfiles ist nicht ohne!

Das muß man einmal machen, dann ist es erledigt – bis sich dann in einzelnen Sprachen einmal Änderungen ergeben; die müßen aber dann ohnehin immer wieder mal ajourgebracht werden. Wenn das aber nur einzelne sind, hält sich das in Grenzen und kann entsprechend vor einem Release angegangen werden – oder sobald eine Meldung reinkommt, es hätte sich dies oder jenes geändert.

Das negativ besetzte Wort Bequemlichkeit sehe ich eher auch der anderen Seite ...

Wenn man das seriös angeht, gehört eben auch die Recherche dazu, wie es nun in welchen Ländern und Sprachen wirklich gehandhabt wird; und auch das ist nicht zu vernachläßigender Aufwand, um den sich wohl nicht besonders viele reißen werden.

Glaubst Du wirklich, ich wäre nicht in der Lage, 'On-The-Fly' MPH in KM/h umzurechnen? Man muss doch nur die Anzeige mal 1,6 nehmen, damit habe ich gewisslich keine Probleme.

Klar kann das eine zeitlang gut gehen – aber irgendwann hast Du auch noch anderes im Kopf, warst zuvor grad mit einem einheimischen Fahrzeug unterwegs, fährst auf einer Straße, auf der die Höhe der Höchstgeschwindigkeit nicht wirklich am sinnvollen Limit ist, siehst eine Tafel, schaust auf den Tacho, denkst Dir "stimmt doch" – und bist gleich gehörig darüber. Irgendwann wird dir das Spielchen mit der permanenten Umrechnung zu doof und Du sehnst Dich wieder nach "normaler Anzeige". Genau das ist es hier auch.

Aber wo gerade an dem Thema sind, genau das ist doch ein weiteres Beispiel, wie sinnfrei es ist, dass nicht global einheitlich sondern Länderspezifisch implementiert wird.

Ist aber historisch bedingt – und das ist nicht einfach so schnell-schnell wegzukriegen. Das braucht mehrere Generationen, bis ein System wirkich geändert werden kann und es dann auch allgemein angenommen wird.

 

[u.k-f]

Wie aufwendig wäre das? Die eigentliche Arbeit, die entsprechende(n) Datei(en) anzupassen wird wohl v.a. ein gehöriges Stück Fleißarbeit sein ... Was braucht es da aber für Installationen (auf dem eigenen Computer), damit man überhaut da rankommt, um das dann anzupassen?

Eigentlich nicht besonders viel: Einen Browser um die Datei runterzuladen, einen Texteditor, um sie zu ändern und ein Mail-Program um sie an das AOKP-Team zu schicken.

Ich weise jedoch darauf hin: Damit das so funktioniert, ist das ziemlich aufwendig implementierte Basis-Framework, das AOSP mitliefert, nötig!

Dort in deren Forum eine entsprechende Diskussion zu eröffnen würde nicht den erwarteten Effekt haben?

Da wäre keine Diskussion nötig, das angesprochene Framework ist ja schon vorhanden und wird bereits ausgeliefert. Ich wollte nur sagen, dass es zwar nur eine Textdatei zu korrigieren gäbe, aber dass es so funktioniert, liegt nicht allein an der einen Textdatei, sondern an einem ausgeklügelten Framework .

Um hier nicht zu sehr OT zu werden, lass ich mal die Stellungnahme zu den anderen Punkten weg, da es einfach die Sicht aus verschiedenen Seiten ist, die sich nicht unter einen Hut bringen lässt

Aber lass mich bitte nochmal den Mechanismus genauer erklären, damit klar ist, was getan werden müsste:

Zum Zweck der Internationalisierung gibt es im Android-Framework ein Verzeichnis frameworks/base/core/res/res/values, in dem stehen die 'Basis-Werte' drin, die verwendet werden (Beispielsweise der Format-String).

Wird eine bestimmte Sprache eingestellt, beispielsweise Französisch (Abkürzung fr), wird versucht, einen Wert nicht aus dem Basis-Verzeichnis zu nehmen, sondern aus frameworks/base/core/res/res/values-fr. Nur wenn der Wert dort nicht gefunden würde, würde er aus frameworks/base/core/res/res/values genommen werden.

Wird nun eine bestimmte Region eingestellt, beispielsweise Schweiz (Abkürzung rCH = Region CH), wird versucht, einen Wert nicht aus dem Basis-Verzeichnis zu nehmen, und auch nicht aus dem Sprache-Verzeichnis, sondern aus frameworks/base/core/res/res/values-fr-rCH. Nur wenn der Wert dort nicht gefunden würde, würde er aus frameworks/base/core/res/res/values-fr genommen werden, und wenn er da nicht gefunden wir, dann aus frameworks/base/core/res/res/values.

Der Wert für das das Datum-Format liegt in den o.a. Verzeichnissen in einer Datei namens 'donottranslate-cldr.xml'

(donottranslate mag hier verwirren, es geht darum, das Formatstrings die dd/MM/yyyy beinhalten, zwar Länderspezifisch angepasst werden sollen zu dd.MM.yyyy, aber nicht das %y übersetzt werden soll, da man beim Aufbauen des Datums nach yyyy sucht um es mit 2013 zu überschreiben. Würde das in der Deutschen Datei zu jjjj übersetzt sein, würde kein platz für das Datum gefunden werden, da die Software nach yyyy sucht und für die Anzeige mit 2013 überschreibt)

Da ja nun in der Schweiz ein anderes Datumsformat als dd/MM/yyyy verwendet werden soll, müsste im Verzeichnis frameworks/base/core/res/res/values-fr-rCH eine Datei 'donottranslate-cldr.xml' liegen, in der der Formatstring dd.MM.yyyy drin liegt. Diese Datei ist in dem Verzeichnis nicht drin, daher werden die Werte aus dem Verzeichnis frameworks/base/core/res/res/values-fr aus der Datei 'donottranslate-cldr.xml' genommen. Daher müsste man diese Datei, nehmen, korrigieren und ins Verzeichnis frameworks/base/core/res/res/values-fr-rCH reinlegen.

Diese Datei ist hier zu finden:

https://github.com/android/platform...ore/res/res/values-fr/donottranslate-cldr.xml

Man könnte (unter der Annahme, dass in der Schweiz die gleiche Datums-Formatierung wie in Deutschland üblich ist), auch die deutsche Format-Datei in das Verzeichnis für 'Sprache fr Region CH' packen. Diese findet man hier:

https://github.com/android/platform...ore/res/res/values-de/donottranslate-cldr.xml

Dann müsste man allerdings die Namen der Monate und Wochentage auf die französische Sprache anpassen!

Ich hoffe, auch wenn wir manchen Punkten unterschiedlicher Meinung sind, ich konnte etwas Licht in diese Sache bringen.

MfG Uwe

 

[Kukkatto]

Eigentlich nicht besonders viel: Einen Browser um die Datei runterzuladen, einen Texteditor, um sie zu ändern und ein Mail-Program um sie an das AOKP-Team zu schicken.

... ... und das Team dort bindet sie dann entsprechend in die System-"Vorlagen" ein; und nächstesmal, wenn aus den "Vorlagen" wieder ein "richtiges System" gebaut wird, werden die einfach mitgeschleppt und sind dann auch dabei ... ?

Da wäre keine Diskussion nötig, das angesprochene Framework ist ja schon vorhanden und wird bereits ausgeliefert. Ich wollte nur sagen, dass es zwar nur eine Textdatei zu korrigieren gäbe, aber dass es so funktioniert, liegt nicht allein an der einen Textdatei, sondern an einem ausgeklügelten Framework ...

... das erlaubt, daß einfach die entsprechenden Textdateien angefügt werden ... das Funktionsprinzip dürfte soweit nachzuvollziehen sein.

Um hier nicht zu sehr OT zu werden, lass ich mal die Stellungnahme zu den anderen Punkten weg, da es einfach die Sicht aus verschiedenen Seiten ist, die sich nicht unter einen Hut bringen lässt.

Na gut – das ist ein anderes Kapitel, über das sich lange streiten ließe ... ... hier geht es ja primär darum, wie falsche (resp. fehlende) Datumsformate nachgerüstet werden können.

Aber lass mich bitte nochmal den Mechanismus genauer erklären, damit klar ist, was getan werden müsste: ...

Danke – soweit in etwa, wie ich dasvom Prinzip er erwartet hatte – mal abgesehen von den automatischen Fallback-Ersetzungen ... und es auch entsprechend logisch erscheint: beim Format für "Englisch (Schweiz)" wird dann (mangels separatem vorhandensein) eben einfach auf "Englisch (ohne nähere Länderbezeichnung)" zurückgegriffen – was natürlich zu DD/MM/YYYY führt ... nachvollziehbar, auch wenn eigentlich nicht korrekt. Und wenn der Hersteller dann ca. 240 Englisch-Versionen (für jedes Land und Territorium separat) zur Verfügung stellt, greifen wohl so gut wie alle auf ein "Standard-Englisch" zurück ...

Diese Datei ist hier zu finden:

https://github.com/android/platform...ore/res/res/values-fr/donottranslate-cldr.xml

Man könnte (unter der Annahme, dass in der Schweiz die gleiche Datums-Formatierung wie in Deutschland üblich ist), auch die deutsche Format-Datei in das Verzeichnis für 'Sprache fr Region CH' packen. Diese findet man hier:

https://github.com/android/platform...ore/res/res/values-de/donottranslate-cldr.xml

Dann müsste man allerdings die Namen der Monate und Wochentage auf die französische Sprache anpassen!

Na gut, die kann man dann aus mehreren zusammenstellen (CH-fr mit Texten der Monate, Wochentage etc. aus FR-fr und Trennzeichen aus CH-de etc.)

Ich hoffe, auch wenn wir manchen Punkten unterschiedlicher Meinung sind, ich konnte etwas Licht in diese Sache bringen.

Auf jeden Fall! Danke!!

Was noch bleibt: können dann diese ergänzten (resp. angefügten) Dateien nur in ein Systeminstallationspaket reingepackt werden, das dann per Firmware wieder frisch installiert wird? Oder ließen sich auch bei einem schon bestehenden resp. laufenden System die einzelnen Dateien anfügen? Wie ist ins System zu gelangen, damit die angefügt werden könnten?

 

[u.k-f]

... ... und das Team dort bindet sie dann entsprechend in die System-"Vorlagen" ein; und nächstesmal, wenn aus den "Vorlagen" wieder ein "richtiges System" gebaut wird, werden die einfach mitgeschleppt und sind dann auch dabei ... ?

So sollte es sein, jedoch habe ich noch nie eine entsprechende Änderung eingereicht -> Ich habe keine Erfahrung, wer ein geeigneter Ansprech-Partner wäre, was es da für Prozesse gibt usw.

Was noch bleibt: können dann diese ergänzten (resp. angefügten) Dateien nur in ein Systeminstallationspaket reingepackt werden, das dann per Firmware wieder frisch installiert wird? Oder ließen sich auch bei einem schon bestehenden resp. laufenden System die einzelnen Dateien anfügen? Wie ist ins System zu gelangen, damit die angefügt werden könnten?

Im Prinzip könnte man es in ein 'existierendes System' reinstopfen.

Das müsste die angepasste xml-Datei in die Arrchiv-Datei (APK), die im Android unter /system/framework/framework-res.apk liegt, reingepackt werden.

Jetzt muss ich aber kurz Hintergrund-Infos geben: Es gibt zwei verschiedene Arten von Leuten, die CustomROMs anbieten: Die ROM-Köche und die ROM-Builder. Die ROM-Köche nehmen ein vorhandenes ROM und entpacken die APKs darin und modifizieren die, die ROM-Builder bauen es aus den Sourcen.

Ein ROM-Koch könnte Dir sagen, wie man das bewerkstelligt, aber ich bin kein ROM-Koch (ich zähle mich zu den den ROM-Buildern) und kenne die Tools, mit denen man existierende apk-File bearbeiten kann, nicht gut.

Das Stichwort, um so ein apk-File zu bearbeiten wäre ein Tool, das man 'ROM-Kitchen' nennt, daher auch der Ausdruck ROM-Koch.

Aber wie man damit umgeht, muss ein Anderer erklären, tut mir leid...

MfG Uwe

Der ursprüngliche Beitrag von 05:01 Uhr wurde um 05:21 Uhr ergänzt:

Noch ein ergänzender Hinweis:

Die Übersicht über alle 'value-xx' und 'value-xx-rYY' Verzeinisse (und auch einige andere Verzeichnisse, die hier aber keine Rolle spielen) findest Du hier:

https://github.com/android/platform_frameworks_base/tree/jb-release/core/res/res

In denen ist dan jeweils die Datei 'donottranslate-cldr.xml' die entsprechende Format-Datei.

In der Datei selbst ist wohl die Zeile:

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

die zuständige Einstellung.

MfG Uwe

 

[Kukkatto]

So sollte es sein, jedoch habe ich noch nie eine entsprechende Änderung eingereicht -> Ich habe keine Erfahrung, wer ein geeigneter Ansprech-Partner wäre, was es da für Prozesse gibt usw.

Na gut – gugge mer mol ... werd' ich schon noch herausfinden. Aber zumindest ist das Prozedere somit einigermaßen sichtbar ...

Im Prinzip könnte man es in ein 'existierendes System' reinstopfen.

Dann könnte man so auch weitere, "inoffizielle Sprachversionen" zusammenstellen, wie z.B. schon erwähnt natürlich "Englisch (Schweiz)" (oder "Englisch (DACH)"), oder z.B. auch "Albanisch (Schweiz)" oder "Tamil (Schweiz)" etc. ...

Exkurs: wenn im Android-System die Sprachverion eingestellt wird, stehen dann sämtliche regionalsprachspezifischen Details in jener "donottranslate-cldr.xml", wenn die Basissprache schon vorhanden ist (das wäre dann die "strings.xml"?

Für gewisse Regionalsprachversionen gibt's ja auch noch die "donottranslate-maps.xml", wo der Kartenkoordinatenanfangspunkt drinsteht (map_starting_lat_lng und map_starting_zoom); die müßte dann allenfalls auch ergänzt werden; sind aber nur ein paar Zahlen, die sich dann ändern. Das gehört ins Kapitel Kosmetik ...

Wenn dem so ist, hab' ich das System, wie das eingebunden wird, verstanden; und das ist also alles andere als eine Hexerei ...

Das müsste die angepasste xml-Datei in die Arrchiv-Datei (APK), die im Android unter /system/framework/framework-res.apk liegt, reingepackt werden.

Ähm ... "im Android" ... ? ... Ist das im System des installierten Android-Systems auf dem Gerät? Wie kommt man da ran?

Jetzt muss ich aber kurz Hintergrund-Infos geben: Es gibt zwei verschiedene Arten von Leuten, die CustomROMs anbieten: Die ROM-Köche und die ROM-Builder. Die ROM-Köche nehmen ein vorhandenes ROM und entpacken die APKs darin und modifizieren die, die ROM-Builder bauen es aus den Sourcen.

D.h. die ROM-Köche würden z.B. die Komplettfirmwaredatei (die beim Hersteller geholt werden kann) als Basis nehmen, auspacken, anpassen und wieder einpacken, die ROM-Builder den Source-Code (der ggf. auch beim Hersteller liegt) und entsprechend selbst compilieren?

Ein ROM-Koch könnte Dir sagen, wie man das bewerkstelligt, aber ich bin kein ROM-Koch (ich zähle mich zu den den ROM-Buildern) und kenne die Tools, mit denen man existierende apk-File bearbeiten kann, nicht gut.

Hmm ... die Firmware ist aber als "update.app" (und nicht als .apk) vorhanden ... wo ist mein Denkfehler?

Das Stichwort, um so ein apk-File zu bearbeiten wäre ein Tool, das man 'ROM-Kitchen' nennt, daher auch der Ausdruck ROM-Koch.

Danke – danach suchen bringt brauchbare Resultate ...

Aber wie man damit umgeht, muss ein Anderer erklären, tut mir leid...

Werd' ich schon rauskriegen ...

Noch ein ergänzender Hinweis ... Übersicht über alle 'value-xx' und 'value-xx-rYY' Verzeichnisse ...

Danke, hab' ich gefunden; muß ja nur oben einen höherliegenden Unterordner ansteuern ...

 

[u.k-f]

Dann könnte man so auch weitere, "inoffizielle Sprachversionen" zusammenstellen, wie z.B. schon erwähnt natürlich "Englisch (Schweiz)" (oder "Englisch (DACH)"), oder z.B. auch "Albanisch (Schweiz)" oder "Tamil (Schweiz)" etc. ...

Die List der der Auswählbarebaren Sprachen/Region wird aber nicht dadurch erstellt, dass geguckt wird, welche Verzeichnisse es gibt, sondern diese Liste ist eine seperate Liste (wahrscheinlich eine xml-Datei oder ein Teil in einer xml-Datei (Die ich selbst erst mal suchen/rausfinden/erforschen müsste...)

Exkurs: wenn im Android-System die Sprachverion eingestellt wird, stehen dann sämtliche regionalsprachspezifischen Details in jener "donottranslate-cldr.xml", wenn die Basissprache schon vorhanden ist (das wäre dann die "strings.xml"?

Nein, es ist immer eine Datei mit gleichen Namen (also in unserem Fall "donottranslate-cldr.xml", in dem 'weniger Spezifischen Verzeichnis'. In Strings.xml stehehen die die 'Anzeige-Texte' drin (die könnte man somit auch Regional-Spezifisch anpassen, Beispiel in Deutschland steht an Türen, die nach außen aufgehen, an der Innenseite 'Drücken', in der Schweiz würde man das mit 'Stossen' überlagern).

Ähm ... "im Android" ... ? ... Ist das im System des installierten Android-Systems auf dem Gerät? Wie kommt man da ran?

Dafür gibt es verschiendene Möglichkeiten:

• Ein Backuptool wie CWM-Recovery oder TWPR-Recovery kann als Backup ein Abbild des kompletten Systems ziehen
• Durch download eines System-Images vom Hersteller.
• Mt root-Rechten und einem Datei-Manager kann man geziehlt die Datei /system/framework/framework-res.apk auf die SD-Karte kopieren.
• Über die sogenannte adb (Android-Debug-Bridge) kann man vom PC (wenn das Gerät über USB mit dem PC verbunden ist) die Datei auf den PC kopieren mit dem Befehl 'adb pull /system/framework/framework-res.apk framework-res.apk' (den man auf dem PC in einem Kommando-Fenster eingibt, wenn auf dem PC die ADB-Tools installiert sind.
• Gerätespezifische Methoden, die ich nicht für jedes Gerät kennen kann...

D.h. die ROM-Köche würden z.B. die Komplettfirmwaredatei (die beim Hersteller geholt werden kann) als Basis nehmen, auspacken, anpassen und wieder einpacken, die ROM-Builder den Source-Code (der ggf. auch beim Hersteller liegt) und entsprechend selbst compilieren?

Ja! Nur leider geben die wenigsten Hersteller ihre Sourcen raus, oder die Hersteller sind noch auf älteren Android-Versionen, so dass es oft eben mit Entwicklungsarbeit verbunden ist, ein ROM mit einer neueren Android-Version herzustellen, als der Hersteller rausgibt. Aber genau darin liegt ja der Spaß, den der Entwickler empfindet, wenn er selbst ein ROM baut.

Hmm ... die Firmware ist aber als "update.app" (und nicht als .apk) vorhanden ... wo ist mein Denkfehler?

das update.xxx (kann verschiedene Endungen haben, je nach Hersteller) ist ein Archiv-Datei (wie ein zip) in dem viele Einzeldateien sind (z.B. xxx.jar, xxx.apk, xxx.so usw), die die in einer 'Baum-Struktur angeordnet sind, wie sie auf dem Android-Gerät dann auch angeordnet werden (Deswegen schreibe ich immer nicht framework-res.apk sondern /system/framework/framework-res.apk, um die Baumstruktur im Android-System mit abzubilden). Dabei sind .jar und .apk Dateien ihrerseits Archiv-Dateien, in denen 'Unterdateien' drin sind, wie im framework-res.apk eben die vielen xml-Dateien.)

Danke – danach suchen bringt brauchbare Resultate ...

Eines dieser Tools (gibt eigenlich mehrere veschiedene Versionen von Android-Kirchens oder ROM-Kitchens) sollte bestimmt auch in der Lage sein, das update.app zu entpacken, so dass man dann das darin befindliche framework-res.apk entpacken kann.

Welches Kitchen-Tool genau das beste für Dein Gerät ist (das Format der update.app ist Hersteller/Geräte-abhängig, das Format des apk ist Android-Standard), musst Du am bestem im entsprechenden Unterforum für Dein Gerät erfragen!

MfG Uwe

 

[Kukkatto]

Die Liste der der Auswählbarebaren Sprachen/Region wird aber nicht dadurch erstellt, dass geguckt wird, welche Verzeichnisse es gibt, sondern diese Liste ist eine seperate Liste (wahrscheinlich eine xml-Datei oder ein Teil in einer xml-Datei (Die ich selbst erst mal suchen/rausfinden/erforschen müsste...)

D.h. das System muß beim Booten auf eine Liste zurückgreifen können, in denen sämtliche vorhandenen Sprachversionen aufgelistet sind – jeweils mit Namensbezeichnung der Sprachversion und Unterordner, wo die jeweilge Sprachfiles abgelegt sind (diese Liste muß natürlich entsprechend gepflet werden); und wenn ein Regionalfile nicht vorhanden ist, wir auf das zugeordnete Sprachenfile zurückgegriffen?

... es ist immer eine Datei mit gleichen Namen (also in unserem Fall "donottranslate-cldr.xml", in dem 'weniger Spezifischen Verzeichnis'. In Strings.xml stehehen die die 'Anzeige-Texte' drin (die könnte man somit auch Regional-Spezifisch anpassen, Beispiel in Deutschland steht an Türen, die nach außen aufgehen, an der Innenseite 'Drücken', in der Schweiz würde man das mit 'Stossen' überlagern).

Klar könnte man die strings.xml auch noch regionalsprachlich anpassen; wäre aber nicht zwingend. Worauf ich natürlich hinaus will: besteht ein strings.xml-Sprachfile, so ist damit die Übersetzung getan, aber noch nicht Datumsformat; jenes ist dann in der donottranslate-cldr.xml (und der Kartenkoordinatenanfangspunkt wäre dann in der donottranslate-maps.xlm) etc.

D.h. in der Quintessenz aber auch: um eine weitere Sprache anzufügen, braucht's ein entsprechendes strings.xml; und für jede Sprache und auch jede Regionalsprache (die auf das entsprechende strings.xml zurückgreift), braucht's dann auch noch ein donottranslate-cldr.xml (mit Datum-/Uhrzeitformat etc. drin); und damit die dan eingebunden werden, muß ein entsprechender Eintrag in der Sprachenliste vorhanden sein.

... Nur leider geben die wenigsten Hersteller ihre Sourcen raus, oder die Hersteller sind noch auf älteren Android-Versionen, so dass es oft eben mit Entwicklungsarbeit verbunden ist, ein ROM mit einer neueren Android-Version herzustellen, als der Hersteller rausgibt. Aber genau darin liegt ja der Spaß, den der Entwickler empfindet, wenn er selbst ein ROM baut.

Huawei ist offenbar bei den kooperativeren, von denen das Kernel-File zu beziehen ist ... muß mich aber noch schlau machen, in welchem Format das ist; ein einfaches ins (gepackte) Archiv reinschauen zeigte hier erst mal nur eine einzelne Datei – erst noch ohne Endung ...

das update.xxx (kann verschiedene Endungen haben, je nach Hersteller) ist ein Archiv-Datei (wie ein zip) in dem viele Einzeldateien sind (z.B. xxx.jar, xxx.apk, xxx.so usw), die die in einer 'Baum-Struktur angeordnet sind, wie sie auf dem Android-Gerät dann auch angeordnet werden (Deswegen schreibe ich immer nicht framework-res.apk sondern /system/framework/framework-res.apk, um die Baumstruktur im Android-System mit abzubilden). Dabei sind .jar und .apk Dateien ihrerseits Archiv-Dateien, in denen 'Unterdateien' drin sind, wie im framework-res.apk eben die vielen xml-Dateien.)

OK, auch da muß ich mich mal schlaumachen, wie das hier konkret aussieht, wie auch, wie dann das update.app zu entpacken ist ... Mal etwas im Huawei-Unterbereich rumstöbern, ob das was empfehlenswertes zu finden ist; für das "unknown PW08" wird's wohl schwierig sein, überhaupt erst mal rauszufinden, was das für eines ist, bevor ich darangehen kann, wie dem auch beizukommen wäre ...

Ganz andere Frage noch: ist diese Struktur im Spracheinstellungsbereich (mit den .xml-Dateien) bei allen Android-Versionen gleich; oder wurde daran mal was angepaßt oder geändert?

 

[u.k-f]

D.h. das System muß beim Booten auf eine Liste zurückgreifen können, in denen sämtliche vorhandenen Sprachversionen aufgelistet sind – jeweils mit Namensbezeichnung der Sprachversion und Unterordner, wo die jeweilge Sprachfiles abgelegt sind (diese Liste muß natürlich entsprechend gepflet werden); und wenn ein Regionalfile nicht vorhanden ist, wir auf das zugeordnete Sprachenfile zurückgegriffen?

Ja. Wobei anzumerken ist, diese Liste gehört auch zum Auslieferungsumfang von Android. Die wird also vom AOSP-Team gepflegt.

Klar könnte man die strings.xml auch noch regionalsprachlich anpassen; wäre aber nicht zwingend. Worauf ich natürlich hinaus will: besteht ein strings.xml-Sprachfile, so ist damit die Übersetzung getan, aber noch nicht Datumsformat; jenes ist dann in der donottranslate-cldr.xml (und der Kartenkoordinatenanfangspunkt wäre dann in der donottranslate-maps.xlm) etc.

Ja.

D.h. in der Quintessenz aber auch: um eine weitere Sprache anzufügen, braucht's ein entsprechendes strings.xml; und für jede Sprache und auch jede Regionalsprache (die auf das entsprechende strings.xml zurückgreift), braucht's dann auch noch ein donottranslate-cldr.xml (mit Datum-/Uhrzeitformat etc. drin); und damit die dan eingebunden werden, muß ein entsprechender Eintrag in der Sprachenliste vorhanden sein.

Ja. Wenn das 'donottranslate-cldr.xml' fehlt, wird auf die unspezifischere Ersatz-Datei zugegriffen.

Huawei ist offenbar bei den kooperativeren, von denen das Kernel-File zu beziehen ist

Das es die Kernel-Sourcen gibt, ist keine Kooperation-Bereitschaft, sondern Pflicht, da die Kernel alle auf dem Linux-Kernel basieren, und somit der GPL unterliegen, in der ganz klar die Verpflichtung zum veröffentlichen der Kernel-Sourcen niedergeschrieben steht.

Nur helfen die Kernel-Sourcen allein nicht viel weiter, man benötigt auch die Kernel-Konfiguration (die schon nicht mehr jeder Hersteller anbietet), Firmware-Binaries für die Hardware-Komponenten des Gerätes, und Hardware-Spezifische Bibliotheken, die den Kernel mit der Hardware-Unabhängigen Schicht des Android-Systems verbinden (sogenannte Hardware-Abstraction-Layer). Und wenn man die Android-Version ändert (weil man eine neuere Android-Version als die des Herstellers für das Gerät bereitstellen will), passt u.U. der Kernel selbst auch nicht mehr zum System. Dann hat man eine spannende Aufgabe...

... muß mich aber noch schlau machen, in welchem Format das ist; ein einfaches ins (gepackte) Archiv reinschauen zeigte hier erst mal nur eine einzelne Datei – erst noch ohne Endung ...

Viele Zip-tools scheinen auf den ersten Blick ein APK öffnen zu können, aber zeigen dann nur Murks an. Mit einer ROM-Kitchen jedoch sollte ein APK zu öffnen möglich sein.

Ganz andere Frage noch: ist diese Struktur im Spracheinstellungsbereich (mit den .xml-Dateien) bei allen Android-Versionen gleich; oder wurde daran mal was angepasst oder geändert?

Das sollte (Konjunktiv! kann also abweichen!) auf allen Geräten identisch sein, jedoch kann der Umfang der Sprachen variieren. Außerdem kann niemand garantieren, dass ein Hersteller nicht doch sein eigenes Süppchen kocht!

 

[Optimolly]

Ich möchte auch meine unfachmännische Anschauung zum Besten geben.

Zum Einen habe ich ein paar flüchtige Einblicke beim Lesen der Problematik bekommen, wie verdammt kompliziert in Wirklichkeit dieses Thema ist.
Zum Anderen hat es mir Spaß gemacht, hier mitzulesen, zumal die Beteiligten alle wirklich bemüht waren / sind, dem Thema auf den Grund zu gehen und sich dabei trotzdem gegenseitig nicht zu
zerreissen. Dabei konnte sogar noch geschmunzelt werden.

Wobei mir nun richtig zum Lachen ist:

Ich fahre als Trucker zwischen Kanada und USA hin-und her.
Wenn dort irgend jemand so ein Häckmäck um die Schreibweise vom Datum und Postleitzahl veranstalten würden, wie hier meine deutschen Landsleute, dann würde gar nichts mehr klappen hier drüben.
Die sind hier mehr Lebensnahe in dieser Hinsicht. In Kanada und in den USA gibt es unterschiedliche Datumschreibweisen, ja sogar innerhalb des jeweiligen Landes. Derjenige, der dann mit dem Datum aus
einem anderen Gebiet konfrontiert wird, MUß eben mal flexibel sein und umdenken.
Und wenn es wirklich keiner versteht, wie z. B. beim 06/08 oder beim 08/06, der schreibt es vorsichtshalber so, das der Monat mit 3 Buchstaben angeschrieben wird...oder man fragt oder
denkt nochmal nach. Und in Formularen werden die Schreibkonventionen meistens sogar in einer Legende vorgegeben.

Das ist es, was mich so amüsiert hat, als ich das hier gelesen habe.
Mir fehlt manchmal auch meine gewohnt, Deutsche Schreibweise. Man hat gerne klare Regeln als Deutscher.
Das macht manchmal das Leben woanders schwieriger, aber auch interessanter.-

 

[Kukkatto]

Ja. Wobei anzumerken ist, diese Liste gehört auch zum Auslieferungsumfang von Android. Die wird also vom AOSP-Team gepflegt.

Wo ist diese Liste abgelegt? Müßte noch irgendwas beachtet werden bzgl. Listenlänge (i.S.v. daß nicht nur die Liste ergänzt werden müßte, sondern auch zusätzlich irgendwo eingetragen, daß die Liste ergänzt wurde)?

Wenn das 'donottranslate-cldr.xml' fehlt, wird auf die unspezifischere Ersatz-Datei zugegriffen.

Klar – d.h. in der Konsequenz aber auch, für jede Sprache könnten beliebig viele "Länderversionen" angefügt werden (wie z.B. schon erwähnt "Englisch (Schweiz)", "Tamil (Schweiz)", "Albanisch (Schweiz)", oder auch "Englisch (Deutschland)", "Russisch (Deutschland)", "Tamil (Kanada)" etc. – d.h.: auch Sprachen, die keinen offiziellen Status haben müssen, aber dennoch häufig gebraucht werden. Nur sollten diese Versionen dann natürlich auch nur dann erwähnt werden, wenn sie nicht auf ein Default-File zurückgreifen; sonst ist das ganze irgendwie witzlos (wie bei meinem Huawei: 240 Englisch-Versionen, die so gut wie alle dasselbe machen). Müßte da mal noch rausfinden, was die für eine Grundeinstellung haben resp. welche Englischversion da als Basis dient ...

Das es die Kernel-Sourcen gibt, ist keine Kooperation-Bereitschaft, sondern Pflicht, da die Kernel alle auf dem Linux-Kernel basieren, und somit der GPL unterliegen, in der ganz klar die Verpflichtung zum veröffentlichen der Kernel-Sourcen niedergeschrieben steht.

... oh ...

Nur helfen die Kernel-Sourcen allein nicht viel weiter, man benötigt auch
– die Kernel-Konfiguration (die schon nicht mehr jeder Hersteller anbietet), – Firmware-Binaries für die Hardware-Komponenten des Gerätes, und
– Hardware-Spezifische Bibliotheken, die den Kernel mit der Hardware-Unabhängigen Schicht des Android-Systems verbinden (sogenannte Hardware-Abstraction-Layer).
Und wenn man die Android-Version ändert (weil man eine neuere Android-Version als die des Herstellers für das Gerät bereitstellen will), passt u.U. der Kernel selbst auch nicht mehr zum System.

d.h. aus einem Kernel-File (z.B. von Huawei) ließe sich nicht ein vollständiges gerätespezifisches System compilieren? Oder ist da alles dabei? Wie erkennt man das?

Dann hat man eine spannende Aufgabe...

... ...

Viele Zip-tools scheinen auf den ersten Blick ein APK öffnen zu können, aber zeigen dann nur Murks an. Mit einer ROM-Kitchen jedoch sollte ein APK zu öffnen möglich sein.

Muß ich mich mal nicht nur schlaumachen, sondern wohl besser auch einen hier ohnehin noc rumstehenden PC dazu einrichten und ein Linux draufpappen; schon nur simple Textdateien macht Windows anders (CR-LF) ... NB: heute ist mir wiedermal ein PC-Netzteil hops gegangen (ist aber schon länger her seit dem letzten) ... :/

Das sollte (Konjunktiv! kann also abweichen!) auf allen Geräten identisch sein, jedoch kann der Umfang der Sprachen variieren. Außerdem kann niemand garantieren, dass ein Hersteller nicht doch sein eigenes Süppchen kocht!

Mir war die Frage danach, ob ein ergänztes donottranslate-cldr.xml dann nur für die aktuelle Android-Version brauchbar wäre, oder ob das auch auf früheren Versionen (2.3.x, 4.0.x etc.) funzen würde ...

Der ursprüngliche Beitrag von 01:30 Uhr wurde um 01:46 Uhr ergänzt:

Zum Einen habe ich ein paar flüchtige Einblicke beim Lesen der Problematik bekommen, wie verdammt kompliziert in Wirklichkeit dieses Thema ist.

Wobei das zwar keine Hexerei ist, aber dennoch alles andere als trivial. Ein Problem dabei ist eben nicht nur, daß die Handhabung handschriftlicht oftmals andersgemacht wird als mit "Schreibmaschine" resp. auf dem PC – und ein weiteres, daß vieles einfach nur Gewohnheit ist – sprich: gar nicht offiziell festgelegt. Und wenn man das dann mündlich ausspricht, ist es nochmals anders ...

Zum Anderen hat es mir Spaß gemacht, hier mitzulesen, zumal die Beteiligten alle wirklich bemüht waren / sind, dem Thema auf den Grund zu gehen und sich dabei trotzdem gegenseitig nicht zu zerreissen. Dabei konnte sogar noch geschmunzelt werden.

... ...

Ich fahre als Trucker zwischen Kanada und USA hin-und her.
Wenn dort irgend jemand so ein Häckmäck um die Schreibweise vom Datum und Postleitzahl veranstalten würden, wie hier meine deutschen Landsleute, dann würde gar nichts mehr klappen hier drüben.
Die sind hier mehr Lebensnahe in dieser Hinsicht.

Ist halt immer auch eine Frage, ob eine sture und unflexible Maschine das Zeugs verarbeiten soll; ohne gewisse Vorgaben, die dann auch einzuhalten sind, funzt das dann nur bedingt ...

In Kanada und in den USA gibt es unterschiedliche Datumschreibweisen, ja sogar innerhalb des jeweiligen Landes. Derjenige, der dann mit dem Datum aus einem anderen Gebiet konfrontiert wird, muß eben mal flexibel sein und umdenken.

Ich sag' mal: das ist dann weniger ein Problem, wenn bekannt ist, woher das Schriftstück kommt und wie dort die Handhabung ist ... Und wenn gewisse Konventionen bestehen, in welchen Situationen welches Format gebraucht wird – oder irgend ein aktueller Bezug zueinem aktuellen Anlaß bzgl. eines aktuellen Datums besteht, ist das Problem ja auch nicht wirklich eines ...

Und wenn es wirklich keiner versteht, wie z. B. beim 06/08 oder beim 08/06, der schreibt es vorsichtshalber so, das der Monat mit 3 Buchstaben angeschrieben wird...oder man fragt oder
denkt nochmal nach.

Da ist auch immer die Frage: wie spricht man das aus; und wenn dann Ordinalzahlen (der ...-te) mit reinspielen, wird das dann schon weniger verwirrend ...

Und in Formularen werden die Schreibkonventionen meistens sogar in einer Legende vorgegeben.

Da muß ohnehin vorgegeben werden, wie das sein muß – sonst läuft dann alles schief ...

Das ist es, was mich so amüsiert hat, als ich das hier gelesen habe.
Mir fehlt manchmal auch meine gewohnt, Deutsche Schreibweise. Man hat gerne klare Regeln als Deutscher.
Das macht manchmal das Leben woanders schwieriger, aber auch interessanter.-

... ...

 

[u.k-f]

Wo ist diese Liste abgelegt? Müßte noch irgendwas beachtet werden bzgl. Listenlänge (i.S.v. daß nicht nur die Liste ergänzt werden müßte, sondern auch zusätzlich irgendwo eingetragen, daß die Liste ergänzt wurde)?

Glaube nicht, dass es eine Beschränkung der Listen-Länge gibt. Aber die Liste selbst muss es ja allein schon wegen der 'Korrekten Sprach- und Regionen-Namen' geben. Wo das genau ist, muss ich zugeben, weiß ich auch nicht genau.

Klar – d.h. in der Konsequenz aber auch, für jede Sprache könnten beliebig viele "Länderversionen" angefügt werden (wie z.B. schon erwähnt "Englisch (Schweiz)", "Tamil (Schweiz)", "Albanisch (Schweiz)", oder auch "Englisch (Deutschland)", "Russisch (Deutschland)", "Tamil (Kanada)" etc. – d.h.: auch Sprachen, die keinen offiziellen Status haben müssen, aber dennoch häufig gebraucht werden. Nur sollten diese Versionen dann natürlich auch nur dann erwähnt werden, wenn sie nicht auf ein Default-File zurückgreifen; sonst ist das ganze irgendwie witzlos (wie bei meinem Huawei: 240 Englisch-Versionen, die so gut wie alle dasselbe machen). Müßte da mal noch rausfinden, was die für eine Grundeinstellung haben resp. welche Englischversion da als Basis dient ...

Das ist möglich, aber die Regionen müssen auch in der Liste eingetragen sein

... oh ...

d.h. aus einem Kernel-File (z.B. von Huawei) ließe sich nicht ein vollständiges gerätespezifisches System compilieren? Oder ist da alles dabei? Wie erkennt man das?

Da ist ganz bestimmt nicht alles dabei, denn 'alles' ist unglaublich umfangreich: 15 GB!

Muß ich mich mal nicht nur schlaumachen, sondern wohl besser auch einen hier ohnehin noc rumstehenden PC dazu einrichten und ein Linux draufpappen; schon nur simple Textdateien macht Windows anders (CR-LF) ... NB: heute ist mir wiedermal ein PC-Netzteil hops gegangen (ist aber schon länger her seit dem letzten) ... :/

In dem Beitrag https://www.android-hilfe.de/forum/...en-sourcen-aosp-cm-aokp-aospa-usw.443795.html steht beschrieben (oder verlinkt), wie man an die ganzen Sourcen von AOSP kommt.

Mir war die Frage danach, ob ein ergänztes donottranslate-cldr.xml dann nur für die aktuelle Android-Version brauchbar wäre, oder ob das auch auf früheren Versionen (2.3.x, 4.0.x etc.) funzen würde ...

Rückwärts (also eine neuere Datei mit einem älteren Android) könnte funktionieren, denn ein Eintrag zuviel im xml-File, den es in einer älteren Version noch nicht gab, sollte nichts machen, aber es könnte auch sein, dass ein Eintrag umbenannt wurde. Besser ist es, die Datei passend zur Android-Version zu verwenden. Die Sourcen sind in einem Versions-Verwaltungs-System namens GIT gespeichert, da kommt man auch an die alten Android-Versionen dran.

MfG Uwe

 

[Kukkatto]

... die Liste selbst muss es ja allein schon wegen der 'Korrekten Sprach- und Regionen-Namen' geben. ... die Regionen müssen auch in der Liste eingetragen sein.

OK, soweit klar ...

Wo das genau ist, muss ich zugeben, weiß ich auch nicht genau.

Irgendwo müssen ja auch die entsprechenen Namen (der Sprachversionen) abgelegt und aufgelistet sein (so, wie sie dann in der Liste auftauchen, aus der man auswählen kann) ...

Da ist ganz bestimmt nicht alles dabei, denn 'alles' ist unglaublich umfangreich: 15 GB!

Das könnte dann heißen, daß das ca. 100MB große Kernel-File die hardwarespezifischen Dinge wären, die mit dem Zeugs aus den 15GB dann zu einem System zusammengebaut werden?

In dem Beitrag https://www.android-hilfe.de/forum/...en-sourcen-aosp-cm-aokp-aospa-usw.443795.html steht beschrieben (oder verlinkt), wie man an die ganzen Sourcen von AOSP kommt.

Danke ... NB: soviel RAM hab' ich hier derzeit noch in keinem Rechner ... :/

Rückwärts (also eine neuere Datei mit einem älteren Android) könnte funktionieren, denn ein Eintrag zuviel im xml-File, den es in einer älteren Version noch nicht gab, sollte nichts machen, aber es könnte auch sein, dass ein Eintrag umbenannt wurde. Besser ist es, die Datei passend zur Android-Version zu verwenden. Die Sourcen sind in einem Versions-Verwaltungs-System namens GIT gespeichert, da kommt man auch an die alten Android-Versionen dran.

Da müßte dann eben noch geprüft werden, ob da bei den diversen Versionen Unterschiede bestehen; wenn ja, müßte das allenfalls versionsspezifisch separat eingepflegt werden. Eine Revision History wird's wohl auch noch irgendwo geben, wo Änderungen in dem Bereich erwähnt sein müßten ...

Wenn es insgesamt nur um diese .xml-Dateien geht, die angepaßt und angefügt werden müßten, dürfte das ganze gar nicht so ein Riesending sein ...

 

[u.k-f]

...Das könnte dann heißen, daß das ca. 100MB große Kernel-File die hardwarespezifischen Dinge wären, die mit dem Zeugs aus den 15GB dann zu einem System zusammengebaut werden?...

Ich will nicht sagen, dass das unrichtig wäre, aber irgendwie trifft es auch nicht ganz den Punkt.

Einerseits sind die 'Hardware-Treiber' zwar schon im Kernel, aber eigentlich sind alle Treiber in den Kernel-Sourcen mit drin, welche Treiber aber tatsächlich in den Kernel eingebaut werden, legt man dann mit der Kernel-Konfiguration fest.

Andererseits gibt es viele Hardware-Abhängigkeiten, die nicht im Kernel drin sind. Diese lieden in den AOSP-Sourcen (also in den 15 GB) in den Verzeichnissen device/<Hersteller-Name>/<Gerät-CodeName> und vendor/<Hersteller-Name>/<Gerät-CodeName> wobei <Hersteller-Name> im Falle von Acer eben durch acer ersetzt wird und <Gerät-CodeName> im Falle des Acer A210 (Codename picasso_e2) durch pcasso_e2 erstetzt wird, also, die Hardware-Abhängigkeiten des Acer A210 in device/acer/picasso_e2 und vendor/acer/picasso_e2 liegen.

MfG Uwe