Automatisierte Pflege der locales für neue Images

[Mr.Servo]

Am 25.7.2020 um 16:06 schrieb SnowHead:

Für Sprachbegabte gabe es auch eine Möglichkeit der Mitwirkung zum Beispiel bei den locales, also den Dateien, welche für die Umschaltung der Sprache benötigt werden. Die müssen für fast jedes neue Image angepaßt werden...

Bin zwar selbst kein "Sprachenkönig", kann mir das aber mal ansehen und mir dabei helfen lassen (FR/IT/ENG). Wo finde ich die bestehenden Dateien, damit ich mir das mal ansehen kann? Letzlich muß das ja nur organisiert & umgesetzt werden...

Gruß......Mr.Servo

[SnowHead]

@Mr.Servo

Die locales liegen auf der Box in "/share/tuxbox/neutrino/locale". Benannt sind sie nach der jeweils enthaltenen Sprache. Dieser Name taucht dann auch im Sprachenauswahlmenü der Einstellungen auf.

Der Aufbau ist einfach. Jede Zeile enthält einen symbolischen Namen, welcher von der Texterzeugung im Neutrino sprachneutral verwendet und bei der Ausgabe durch den hinter dem symbolischen Namen stehenden Text ersetzt wird. Somit ist eine Sprachumschaltung leicht, da sich die jeweiligen symbolischen Namen in allen Sprachdateien wiederfinden.

Diese Dateien sind allerdings für jedes Image und jede Imageversion fest angepaßt und nicht untereinander austauschbar, da Neutrino leider beim Ersetzen nicht nach dem symbolischen Namen in der Datei selbst sucht sondern nur die Zeile der Datei verwendet, an deren Position dieser Name in einer internen Liste steht. Das heißt Reihenfolge und Position der einzelnen Zeilen sind vom jeweiligen Image her fest vorgegeben und dürfen nicht geändert werden, sonst wird bei der Textausgabe Müll erzeugt.

Die locale (deutsch oder englisch) des jeweils in Arbeit befindlichen Images wird Dir Markham sichern gern kurz vor der Fertigstellung des Images zusenden.

[Mr.Servo]

Glaube zu verstehen!

Dann ist es nicht relevant, ob der Eintrag beispielsweise zapit.scantype heißt (mit Inhalt "Service-Auswahl"), sondern daß der Eintrag zapit.scantype vom Image #1 in Zeile 2926 erwartet wird. Das Image #2 erwartet den Eintrag zapit.scantype dann beispielsweise in Zeile 3010. Ist das so in etwa richtig?

Wieviele "jeweilige Images" gibt es denn zu bedienen?

Gruß.....Mr.Servo

[SnowHead]

@Mr.Servo

 

Ist im Prinzip richtig. Um aber einen Eintrag für eine Änderung schnell wiederzufinden (auch der Neutrinobauer muß ja wissen, wie die symbolische Konstante heißt) sollte der erste Teil der Zeile schon besser mit der Symbolliste in den Quellen übereinstimmen.

Da Markham die Images für die verschiedenen Boxen aus den gleichen Quellen baut, wird in der Regel eine Version der locales je Imagerelease gebraucht.

Da die Sprachen aber auch nachträglich online nachrüstbar sind, könnte man z.B. auch schon mit dem aktuellen Image anfangen. ;-)

[Mr.Servo]

Also ginge es darum eine "Mastertabelle" anzusetzen, sämtliche vorhandene Einträge Konstante und deren Übersetzungen dort aufzulisten, dann hinter jedem Eintrag die entsprechende Zeile für Image #1 und für Image #2, etc. zu setzen (wie eine Matrix) und dann sollte bestenfalls ein Script die einzelnen sprache.locale erzeugen. Sehe ich das richtig?

a) Was ist denn heute schon da?

    und

b) Von wieviel Images sprechen wir denn?

Gruß......Mr.Servo

[Markham]

Als Referenz würde ich immer die deutsch.locale nehmen. Die ist für jedes Imageversion einmalig, da du davon ausgehen musst, das bei jedem offizellen commit, neue oder

geänderte Menüpunkte dazukommen können. Fehlende oder überflüssige Locale werden aber von Neutrino im Log ausgegeben, sofern du Neutrino über die Konsole startest

und beim Übersetzen plötzlich etwas fehlt oder dazukommt.

 

Lange wurde keine Übersetzung mehr für die Keywelt Locales von Usern angeboten und offiziell wird im Git nur deutsch und englisch gepflegt.

Das hieße für dich doppelte Arbeit. Die normale Übersetzung anpassen (mega viele Änderungen) und zusätzlich für das KW Image alle "kw.*" Einträge.

 

Da wir hier aus dem offiziellen Tuxbox Git bauen, findest du die deutsch und english locale hier. Die sind dort Tagesaktuell. Wenn ich also am Montag ein Image baue, können die am Dienstag schon anders sein. Die beiden anderen werden schon länger nicht mehr updated. Alle anderen findest du unter unmaintained.

 

Wie gesagt, wenn du mit so einer harten Aufgabe anfangen möchtest, nimm die deutsch.locale oder english.locale aus dem letzten Image.

 

 

[Mr.Servo]

@Markham

Nur zum Mitmeißeln: Die deutsch.locale oder english.locale aus dem GIT sind tagesaktuell aber OK so wie sie sind? Jetzt müssen diese nur noch um die KW-Menüeinträge ergänzt werden, korrekt? Tödlich wird es erst dann, wenn man eine Drittsprache (z.B. Französisch) hinzufügt, korrekt?

Konstant sind in jedem Fall die Konstanennamen (egal ob sie im Image #X nicht mehr erscheinen weil auch der Menüpunkt fehlt), nur die Position (=Zeilennummer) ändert sich von Image zu Image.

Ich überlege, wie man das mit einem Script abfangen könnte (zuerst alle sammeln und dann nach Image wieder verteilen)?

Gruß.....Mr.Servo

 

[Don de Deckelwech]

Hi,

ich glaube, die sind einfach strikt alphabetisch sortiert.

 

Ciao,

DdD.

 

PS: für zB Französisch musst du eine neue  francais.locale-Datei anlegen, als Grundstock die aus unmaintained als Vorlage nehmen, die ist aber wie du siehst hoffnungslos veraltet.

[Markham]

vor einer Stunde schrieb Mr.Servo:

@Markham

Nur zum Mitmeißeln: Die deutsch.locale oder english.locale aus dem GIT sind tagesaktuell aber OK so wie sie sind? Jetzt müssen diese nur noch um die KW-Menüeinträge ergänzt werden, korrekt? Tödlich wird es erst dann, wenn man eine Drittsprache (z.B. Französisch) hinzufügt, korrekt?

Konstant sind in jedem Fall die Konstanennamen (egal ob sie im Image #X nicht mehr erscheinen weil auch der Menüpunkt fehlt), nur die Position (=Zeilennummer) ändert sich von Image zu Image.

Ich überlege, wie man das mit einem Script abfangen könnte (zuerst alle sammeln und dann nach Image wieder verteilen)?

Gruß.....Mr.Servo

 

Tagesaktuell heißt, sie passen nicht mehr zu einen z.B. 3 Tage alten KW-Image. Deswegen die aus dem Image nehmen, wenn du eine neue Sprache dafür aktualisieren möchtest. Die kw.* werden nur eingefügt.

[Mr.Servo]

vor 4 Stunden schrieb Markham:

Das hieße für dich doppelte Arbeit. Die normale Übersetzung anpassen (mega viele Änderungen) und zusätzlich für das KW Image alle "kw.*" Einträge. [...] Wie gesagt, wenn du mit so einer harten Aufgabe anfangen möchtest, nimm die deutsch.locale oder english.locale aus dem letzten Image.

Danke für Deine Offenheit!!!

Was bleibt ist eine unangenehme Aufgabe, wie ich rauslese. Das irgendwie händig abzufummeln, ist maximale Strafarbeit! Also muß irgendein Algoritmus her, der das Ganze irgendwie erträglich und tagesaktuell erledigt. Allerdings muß ich erst die Spielregeln lernen bevor ich anfangen kann zu spielen (und dann als Player, nicht als Gambler!). Ich nehme an, Du hast auch Word/Excel am Laufen, denn im Zweifel schreibe ich das Script in der mir vertrauteren Sprache VBA-Script (incl. CURL & Co.). Hauptsache der Krams läuft am Ende aller Tage und das lästige Zeuxx ist aus dem Kreuz...

Ich sehe schon folgende Spezifikationen aus der readme.txt:

1. Files must be strictly alphabetically ordered, and must not contain any empty lines.

2. Master file: english.locale is considered the master file.

Ich bin zuversichtlich: da findet sich eine Lösung (wahrscheinlich braucht ich hier und da noch ein wenig "Hilfe zur Selbsthilfe"...

Gruß.....Mr.Servo

[Don de Deckelwech]

Hi,

sei doch beim KW-Image froh, das kommt ja nur alle halbe Jahr oder so, ok, die Betas mal häufiger. Jetzt denk aber mal an die NI-Nightlies... Das muss dann einfach der Dev mitmachen, sonst gehts nicht bzw schlecht.

 

Aber ich glaube, mit automatisieren, was du dir da denkst, das geht einfach nicht. Das geht wohl nur zu Fuss: gucken, was an neuen Menupunkten dazugekommen ist , oder was weggefallen ist, wie oben schon gesagt wurde, sieht man sowas im Bootlog, Neutrino beschwert sich da ja brav (missing/superflous).

Oder aber was zB an bisherigen Hints fehlte (die Hints, das sind die Erklärungen unter dem Menu, die kann man aber abschalten, vllt sind dir die noch nie aufgefallen, kA). Ich glaub, da fehlen auch noch ein paar...

 

Naja, schau dir das mal in Ruhe an...

 

Ciao,

DdD.

 

edit: Bootlog ist halt quasi immer das A und O, hast du für deine HD51 eigentlich schon den passenden Pegelwandler etc? Wenn nicht, dann mal langsam bestellen, die Chinesen brauchen ja immer so ein paar Wochen...

 

 

bearbeitet 26. Juli 2020 von Don de Deckelwech

[Mr.Servo]

@Don de Deckelwech

Bootlog kann ich mir ja noch vorstellen, irgendeine programmtechnische Erweiterung, korrekt? Aber Pegelwandler in diesem Zusammenhang?

Nee, da muß ich voll passen, keinen Plan.  Magst Du es bitte erklären?

 

vor 7 Stunden schrieb Don de Deckelwech:

Das geht wohl nur zu Fuss: gucken, was an neuen Menupunkten dazugekommen ist , oder was weggefallen ist, wie oben schon gesagt wurde, sieht man sowas im Bootlog, Neutrino beschwert sich da ja brav (missing/superflous).

Das klingt danach, daß erst beim Booten des neuen Images die Wahrheit (was fehlt / was ist überflüssig und stört) ans Tageslicht kommt, vorher nicht?

Noch bin ich der Hoffnung schwanger, daß man diese "Handauslese" einem Script überlassen können dürfte... Man wird sehen.

Gruß......Mr.Servo

[Don de Deckelwech]

Hi,

mit Bootlog meine ich das gute alte serielle Log mittels Nullmodemkabel. Der Trick mit Telnet und setconsole funktioniert zwar meistens auch, aber dafür muss ja schon ein Grossteil des Linux-Systems laufen, damit man sich da überhaupt einloggen kann. Deshalb sieht man halt nicht alles von Anfang. Den Neutrinostart kann man evtl noch mitkriegen, wenn man schnell ist, aber probiert habe ich das nie.

Die HD51 hat aber keine serielle Schnittstelle an der Geräterückseite, sondern nur intern ein paar Pfostenstecker, an die man zudem noch einen Pegelwandler zwischenschalten muss, weil die mit geringerer Spannung läuft, als eine normale serielle Schnittstelle.

 

Keine Ahnung, ob es hier eine Anleitung dafür gibt, im NI-Forum im HowTo-Bereich für die HD51 findest du aber eine...

 

Ciao,

DdD.

[Mr.Servo]

Irgendwie mit Kanonen auf Spatzen geschossen...

Aber sag mal: Was kann der Bootloader beim Start mehr als eine separates Skript, welches die Situation exakt genauso auswertet (also mit "missing" und "superflous")? Was ist so besonders am Bootloader?

Gruß.....Mr.Servo

[SnowHead]

Hier liegt ein Mißverständnis vor. Mit dem "Bootloader" hat das gar nichts zu tun. Der ist ein extra geschützer Bereich im Flash, aus welchem beim Start die Routinen aufgerufen werden, welche die erste Hardwareinitialisierung vornehmen und dann das eigentliche Betriebsystem laden. Um auch beim Flashen nicht kaputtgemacht zu werden und so immer eine Möglichkeit zu bieten, auch bei kaputtem Betriebssystem zumindest wieder ein neues Flashen zu können, ist der besonders schreibgeschützt.

 

Wovon hier die Rede war, ist das "Bootlog". Das ist die Ausgabe von Debuginformationen beim Systemstart und -betrieb über die serielle Schnittstelle. Die ist bei den meisten Boxen nicht mehr direkt herausgeführt, sodaß man meist über einen USB<->TTL-Umsetzer von einem internen Stecker in der Box auf den PC verbinden muß, um dieses Log in einem Terrminal auf dem PC anschauen zu können. Mit diesem Log kann man Fehler und Probleme beim Starten gut identifizieren.

 

Um aber mal zu schauen, welche locales Neutrino anmeckert, ist aber nicht mal solch ein Umsetzer nötig. Hier genügt Telnet. Gibt man (nachdem Neutrino auf der Box gestertet ist) in der dann zu öffnenden Telnet-Verbindung vom PC "setconsole" ein, bewirkt dieser nette Befehl, daß die Daten, die bisher auf der seriellen Schnittstelle ausgegeben wurden, nun auf die Telnet-Sitzung umgeleitet werden. Startet man nämlich Neutrino nach "setconsole" über das Service-Menü neu, kann man alle von Neutrino beim Start ausgegebenen Debugmeldungen (einschließlich des eventuellen Gemeckers über nicht passende locale) nun im Telnet verfolgen.

 

Um herauszufinden, was sich von der vorigen zur aktuellen locale geändert hat, kann man beide Dateien mit der Diff-Funktion verschiedenster Editoren

 oder auch gleich mit dem diff der Box untersuchen. Hier mal testhalber der Vergleich mit dem Diff der Box via Telnet zwischen zwei locales, bei welchem bei der neuen zwei Zeilen hinzugekommen sind (die sind am Anfang mit einem "+" gekennzeichnet:

# diff -aBt /tmp/deutsch_alt.locale /share/tuxbox/neutrino/locale/deutsch.locale
--- /tmp/deutsch_alt.locale
+++ /share/tuxbox/neutrino/locale/deutsch.locale
@@ -943,6 +943,7 @@
 kw.camd_upd_menu Camd/Cardserver-Update Men
 kw.cardserver_menu Cardserver Men
 kw.cardserver_reset Cardserver Reset
+kw.channellist_spec Nachfolgesendung (fest)
 kw.flash_reboot rebooting ...
 kw.flash_save_settings Aktuelle Settings   bernehmen ?
 kw.flash_saving   bernehme Settings
@@ -964,6 +965,7 @@
 kw.infobar_camd_show Camd-Status anzeigen
 kw.infobar_ci_show CI-Modul-Status anzeigen
 kw.infobar_cs_show Cardslot-Status anzeigen
+kw.infobar_cw_show CW-Quelle anzeigen
 kw.infobar_ip_show Sharing-IP anzeigen
 kw.infobar_mails_show Info   ber neue Mails
 kw.infobar_res_got empfangen

[Mr.Servo]

@SnowHead

Achso sorry, "Bootlog" - "Bootloader"... Aber das Nullmodemkabel hat mich aufs Thema Booten gezogen...

 

Jetzt kommen wir der Sache langsam näher. Sehe ich das richtig? Ich erstelle eine mehrsprachige MaximalListe in folgener Form (notfalls außerhalb vom GIT).

KONSTANTE		DEUTSCH				ENGLISCH
AUDIOSelectMenue.head	Tonoptionen			Audio Options
EPGMenu.epgplus		EPG-Zeitlinien (EPG-Plus)	EPG-Timelines (EPG-Plus)
EPGMenu.eventinfo	Info zur Sendung		Details current program
EPGMenu.eventlist	Vorschau aktuelles Programm	Eventlist current programm
EPGMenu.head		EPG - Programminformation	EPG - Program information
EPGMenu.streaminfo	Technische Informationen	Technical informations

Und je nach Image werden nur...

a) die noch fehlenden KONSTANTEN in der MaximalListe aufgezeigt, damit man diese zuerst nachtragen kann, danach erneuter Konvertierungslauf

b) die KONSTANTEN herausgezogen, die fürs jeweilige Image benötigt werden und die deutsch.locale und english.locale erzeugt

 

So in etwa stelle ich mir das vor (mit MaximalListe). Ist meine Sichtweise korrekt / zielführend oder zu kurz geschossen?

Gruß......Mr.Servo

[SnowHead]

@Mr.Servo

 

Ich verstehe den Begriff "Maximalliste" nicht. Übersetzungen für alles denkbare und eine Liste mit allen vorstellbaren symbolischen Bezeichnern kann kann es ja noch nicht geben.

Im Prinzip ist die z.B. deutsch.locale der jeweils aktuellen Imageversion ja so eine Maximalliste. Die deutsch.locale der gerade in Arbeit befindlichen Imageversion wird ja in der Regel vom Imagebauer erstellt, da nur er weiß, welche symbolischen Konstanten er einfügen oder löschen will.

Wenn Du diese neueste locale vom Imagebauer bekommst, kannst Du die mit "diff" gegen die vorherige vergleichen und bekommst sofort angezeigt, welche Zeilen hinzugekommen, weggefallen oder verändert wurden. Nur diese Differenzen müßten dann (natürlich nach Übersetzung der neuen Klartextstrings) in die bestehenden ausländischen locale übernommen werden um sie auf den aktuellen Stand zu bringen. Das würde in meinen Augen den geringsten Aufwand bedeuten.

Wenn Du das automatisieren willst, kannst Du ja die Ausgabe von diff per Script analysieren und daraus die Handlungsanweisungen für die anderen locales erzeugen.

[Mr.Servo]

@SnowHead

Danke für Deine Geduld!!! Ja genau darum geht es mir: Automatisieren! Irgend ein Weg wird sich finden und wenn nicht, dann habe ich es zumindest versucht. "Bis dahin iss ja auch nix schlimmes bassierd"

 

vor 3 Stunden schrieb SnowHead:

Ich verstehe den Begriff "Maximalliste" nicht.

Den Begriff kenne ich von SAP Produkt-Variantenstücklisten, also die "Produkt-Maximalstückliste" aus der sich dann über Konfigurationsdateien die jeweile Auftragsstückliste rekrutiert. Daher der Name. Das entspricht in der GIT-Readme sinngemäß dem "master file", aber zusätzlich mit allen unterstützten Sprachen wie in meinem letzten Beitrag mal exemplarisch / tabellarisch dargestellt in Deutsch/Englisch, was ich dann als "Maximalliste" bezeichnet habe. Dort sieht man dann auch schon mal die Lücken der einzelnen Übersetzungen. Wichtig ist bei der "Maximalliste": Mehr Einträge als hier gibt es nirgends. Dann wird das Notwendige für das jeweilige Image rausgefiltert und angepaßte deutsch.locale und english.locale werden erzeugt.

 

Kurzform:

1. Die deutsch.locale wird frisch aus dem GIT gecurlt und gibt als "master file" die maximale Anzahl der Einträge vor (Konstanten) und liefert schon mal die deutschen Texte mit. Diese wandert als Basis in die "Maximalliste". Hier bereits können deutsche Leerfelder entdeckt werden.

2. Danach werden die einzelnen Fremdsprache.locales aus dem GIT gecurlt und in diese in die "Maximalliste" integriert. Auch hier bereits können fremdspachliche Übersetzungslücken entdeckt werden.

3. Wenn diese Übersetzungslücken (manuell im GIT) behoben sind, wird neu gestartet, irgendwie (mir derzeit noch unklar) der Bedarf des jeweiligen Images ermittelt und dann die neuen .locales für das neue Image-Built erzeugt.

--> So in etwa stelle ich mir das vor. Hoffentlich habe ich dabei keinen Denkfehler (aus Unwissenheit zum Beispiel).

 

vor 3 Stunden schrieb SnowHead:

Im Prinzip ist die z.B. deutsch.locale der jeweils aktuellen Imageversion ja so eine Maximalliste.

In der Readme im GIT steht: "Master file: english.locale is considered the master file."

   versus

Du sagst (und die Anzahl der Einträge geben Dir Recht): die "deutsch.locale" ist das master file (deutsch: 2848 Einträge / englisch: nur 2791 Einträge).

 

Könnt ihr das bestätigen? Entgegen der GIT- Readme ist die deutsch.locale das "master file"

 

Ich glaube wir kommen da schon auf einen gemeinsamen Nenner, ich programmiere mal was in VBA und wenn es unbrauchtbar wäre, dann ist ja nix weiter passiert. Falls es brauchbar wäre, wären wir schon einen Schritt im automatisieren weiter. Ich klopp mal einen zusammen...

 

Das Thematik driftet vom eigentlichen Thread-Thema "LUA-Plugins entwickeln / Testumgebung" ab. Sollten wir nicht besser ein eigenen neuen Thread "Menütexte & deren Übersetzungen" (oder so) eröffnen, beginnend mit meinem Beitrag nach dem 13.07.2020? Wer könnte das hier im Forum verschieben?

Gruß.....Mr.Servo

 

 

bearbeitet 27. Juli 2020 von Mr.Servo

[SnowHead]

@Mr.Servo

 

Ich habe die locale-Beiträge mal in einem neuen Thema zusammengefaßt.

 

Wenn sich, wie Du schreibst englische und deutsche locale in der Zeilanzahl unterscheiden, stimmt irgendwas nicht. Entsprechend dem Verarbeitungsprinzip der locales in den Images müßten die exakt gleich viel Einträge haben.

Als Basis für die Ableitung der locales für andere Sprachen ist nach wie vor die deutsch.locale vom Imagebauer vorzuziehen. Die enthält genau die Anzahl Einträge, die das neue Image benötigt. Nicht mehr und nicht weniger. Ausßer den zusätzlichen KW-spezifischen Einträgen muß sie nicht unbedingt mit der im git verfügbaren übereinstimmen, da die sich ja im Vergleich zum Stand des Images beim Auschecken durch den Imagebauer inzwischen ja schon wieder geändert haben kann (und damit nicht mehr zum mit dem Checkout gebauten Image passen würde).

Die locales für andere Sprachen (außer englisch, die Markham in der Regel auch schon selbst mit baut (aber sicher auch gern abgeben würde) müßten beim ersten Mal komplett neu aufgebaut werden inklusive der Übersetzungen- Dazu könnten aber als Hilfsmittel die locale anderer Sprachen herangezogen werden, um dort die zu den symbolischen Konstanten gehörenden Übersetzungen herauszuholen und in die eigenen locales einzufügen. Die KW-spezifischen Symbole müßten natürlich mit eigenen Übersetzungen versehen werden.

Für spätere Imageversionen müßten dann nur die, wie schon empfohlen, mit Diff gefundenen Änderungen in die bisherigen locales eingepflegt werden.

[Mr.Servo]

vor 2 Stunden schrieb SnowHead:

Die locales für andere Sprachen (außer englisch, die Markham in der Regel auch schon selbst mit baut (aber sicher auch gern abgeben würde) müßten beim ersten Mal komplett neu aufgebaut werden inklusive der Übersetzungen- Dazu könnten aber als Hilfsmittel die locale anderer Sprachen herangezogen werden, um dort die zu den symbolischen Konstanten gehörenden Übersetzungen herauszuholen und in die eigenen locales einzufügen.

Ja so habe ich es auch verstanden. Wir machen eines. Ich programmiere mal was, damit man einen minutenaktuellen Überblick kriegt (Übersetzungslücken, usw.). Dafür werde ich auch geeigente Logs programmieren. Das Ganze wird aber ein bißchen Zeit brauchen, denn es ist recht komplex und es ist sehr viel zu tun. Dann werde dann mal das Ergbnis posten und dann sehen wir mehr. Und wenn das nichts bringen würde, dann habe ja nur ich Aufwand gehabt. Glaub ich aber nicht.

Frage: Liegen die KW-spezifischen Texte auch im GIT (wo?) oder werden die nichtöffentlich aufbewahrt?

Gruß.....Mr.Servo

[SnowHead]

@Mr.Servo

 

Mach es nicht zu kompliziert. Nicht daß Du mehr Aufwand in die Sache steckst, als eine manuelle Anpassung der paar Textdateien machen würde.

Die Quellen des KW-Images sind selbstverständlich nicht öffentlich zugänglich. Wenn Du Dich mit Markham abstimmst, schickt er Dir kurz vor Fertigstellung der nächsten Imageversion sicher gern die deutsch.locale des KW-Images zur Erzeugung der restlichen Sprachdateien. Inzwischen kannst Du ja mit den aktuellen üben und zum Test mal eine italienische oder französische locale erstellen.

[Mr.Servo]

@SnowHead

Danke für den Hinweis, nicht zuviel Aufwand reinzustecken. Es ist ja meine Zeit, die ich "verpulver" Das Programmieren macht mir momentan etwas Freude, deswegen sollte ich den Schwung ausnutzen.

@Markham

Kannst Du mir vielleicht mal die KW-Locales geZIPped per PN zukommen lassen...?

Gruß.....Mr.Servo

bearbeitet 29. Juli 2020 von Mr.Servo

[thomasrichter]

mal 1 Hinweiss 

im Neutrino ist englisch.locale die hauptdatei 

 

wenn du nun eine deutsche locale in den ordner legst und dort stehen 3 zeilen drin - dann siehst du englisch alles im menü und die 3 zeilen (1 zeile = 1 übersetung) siehst du in deutsch

ob da zeilen fehlen ist egal die werden eben immer aus der englischen benutzt

-------

sollte deutsche als hauptlocale eingestellt sein  dann wird diese immer benutzt -z.b. haust ne france rein in ordner mit 100 zeilen drin - siehst du wenn du sprache auf französisch einstellst 100 französiche wörter und alles andere bleibt deutsch

 

ich hab so geschätzt 6 oder 7 Sprachen beim mir drin russki, italy, cssr, türkey, arabic und noch paar 

 

und immer 1 Sprache ) 1 local datei 

 

nicht 3 sprachen in eine datei -das funktioniert nicht

bearbeitet 30. Juli 2020 von thomasrichter

[Mr.Servo]

@thomasrichter

Danke für den wertvollen Hinweis mit dem "Wenn die Übersetzung fehlt, dann wird der Text des Master files genommen." Das wußte ich so nicht, aber es macht ja auch nur mehr als Sinn.

 

Mir ist klar, daß es weder im GIT noch auf der Box eine führende Datei mit drei (oder mehr) Sprachen geben kann, das von mir angesprochene "Maximalliste" sollte der eigenen Übersicht dienen.

 

Ich sehe folgende Spezifikationen aus der readme.txt:

1. Files must be strictly alphabetically ordered, and must not contain any empty lines.

2. Master file: english.locale is considered the master file.

 

De Facto wird Punkt 2 aber nicht gelebt, was man schon an der Anzahl der Einträge sieht.

deutsch.locale 2848 lines (2848 sloc)
english.locale: 2791 lines (2791 sloc), da fehlen also 57 Einträge (so sieht ein "Master" aber nicht aus )

 

Ist denn im KW-Image das "Master file" die deutsch.locale oder wie im GIT beschrieben die english.locale?

 

Gruß.....Mr.Servo

bearbeitet 30. Juli 2020 von Mr.Servo

[thomasrichter]

vom git selber wird englisch als master aktiv sein -nurch campatch wird deutsche locale grösser 

der campatch kann meist auf englische auch angewendet werden dann sind sie wieder beide gleich groß 

bei cam wie an aus et versteht man in englisch auch