kitFramework i18nEditor

[ralf]

Das kitFramework stellt dutzende Erweiterungen für die unterschiedlichsten Einsatzzwecke zur Verfügung und bringt hierfür hunderte Dialoge mit, über die Besucher der Website informiert werden oder die zu einer Interaktion auffordern.

Das Aussehen der Dialoge an das Layout der Website anzupassen ist kein Problem, es können eigene Templates erstellt werden und mit Twig steht eine mächtige Template Engine zur Verfügung.

Schwieriger wird es, wenn der Kunde oder Webseitenbetreiber Änderungen an den Dialogen selbst wünscht. Wenn zum Beispiel aus einer "Veranstaltung" eine "Mitmachaktion" werden soll oder eine Anmeldung auch in kyrillischer Sprache möglich sein soll oder statt Euro € besser Schweizer Franken sFr. verwendet werden sollen.

Bislang waren diese Anpassungen immer eine ziemlich Quälerei. Wo steht der zu übersetzende Text überhaupt? In irgendeiner PHP Datei oder in einem Template? Wo steht die Übersetzung dazu? Wie kann ich verhindern, dass beim nächsten Update alles wieder weg ist?

Kurz: ziemlich viel Frust ...

Damit ist jetzt Schluß. Der i18nEditor ermöglicht fast spielerisch das Übersetzen und Anpassen von Sprachdateien und liefert nebenbei eine Menge Informationen:

https://kit2.phpmanufaktur.de/de/conten ... d-anpassen

Der Artikel beschreibt die ersten Schritte mit den i18nEditor für die Anwender.

Wer noch eine große Schippe drauflegen will, schaltet den i18nEditor in den Entwickler Modus um. Dazu die

Code: Alles auswählen

/Basic/config.i18n.editor.json

mit dem Konfigurationseditor öffnen (in den Admin-Tools zu finden) und developer > enabled auf true setzen und speichern, anschließend wieder zum i18nEditor wechseln und staunen ...

Gruß
Ralf

[shadowcat]

Anmerkung hierzu: Wir hatten sowas auch schon mal für BC in Arbeit, sind aber wegen des enormen Aufwands erst mal davon abgekommen. Zudem prüft Ralfs Tool auch auf Dopplungen, was nur funktioniert, wenn man die Sprachstrings "extern" - also z.B. in einer Datenbanktabelle - abspeichert. Das wiederum zieht einen Rattenschwanz an konzeptionellen Änderungen nach sich.

Kurzum, wir hätten sowas auch sehr gern für BC, werden das von Seiten des Kernteams aber in absehbarer Zeit aus Zeitmangel nicht liefern können. Wer sich da austoben möchte, kann gerne die alten Quellen übernehmen und auf deren Basis weiter machen - so muß man wenigstens nicht bei Null anfangen.

[ralf]

Anmerkung hierzu: Wir hatten sowas auch schon mal für BC in Arbeit, sind aber wegen des enormen Aufwands erst mal davon abgekommen. Zudem prüft Ralfs Tool auch auf Dopplungen, was nur funktioniert, wenn man die Sprachstrings "extern" - also z.B. in einer Datenbanktabelle - abspeichert. Das wiederum zieht einen Rattenschwanz an konzeptionellen Änderungen nach sich.

Das stimmt nicht ganz. Das kitFramework verwendet - genau wie BC - Sprachdateien, genauer: PHP Arrays und hält die Sprachstrings _nicht_ in einer Datenbanktabelle. Der einzige Unterschied sind die /custom Sprachdateien. Aber das dürfte sehr einfach in BC zu implementieren sein.

Der i18nEditor benötigt ein Packen Datenbanktabellen um den Informationshaufen zu verwalten - schreibt aber wieder Sprachdateien ...

[shadowcat]

Ich meinte auch nicht ersatzweise, sondern zusätzlich. Der BC-Spracheditor in der derzeitigen Version betrachtet dagegen immer genau _eine_ Sprachdatei (Core oder Modul) und pflegt diese. Es gibt keinen Abgleich mit Sprachdateien anderer Module oder Modul gegen Core. Das ginge nur, wenn man alles, was man jemals gefunden hat, in einer DB speichert.

[ralf]

Ich meinte auch nicht ersatzweise, sondern zusätzlich. Der BC-Spracheditor in der derzeitigen Version betrachtet dagegen immer genau _eine_ Sprachdatei (Core oder Modul) und pflegt diese. Es gibt keinen Abgleich mit Sprachdateien anderer Module oder Modul gegen Core. Das ginge nur, wenn man alles, was man jemals gefunden hat, in einer DB speichert.

Stimmt. Da hatte ich dich falsch verstanden. Und ja: der i18nEditor sammelt restlos alles, auch neu hinzkommende Templates, eigene Sprachstrings, die zusätzlich zu den Extensions hinzugefügt werden (die dann auch übersetzt werden können und dem Pool hinzugefügt werden). Aber wenn man erst mal alles in der DB hat ist's kein Problem mehr auf Duplikate zu prüfen, kollidierende Übersetzungen festzustellen oder auch verwaiste Einträge zu finden - dadurch wird's dann richtig chic ...

[shadowcat]

Jepp. Wenn ich mir aber vorstelle, sämtliche Sprachstrings sämtlicher Module sämtlicher Sprachen in der DB zu haben und _dann_ soll ein Admin entscheiden, welche von 5 Übersetzungen denn jetzt die one-and-only ist... Nee.

Edit: Was nicht heißt, daß ein potentieller Admin-Tool-Autor das nicht so machen kann.

[ralf]

Jepp. Wenn ich mir aber vorstelle, sämtliche Sprachstrings sämtlicher Module sämtlicher Sprachen in der DB zu haben und _dann_ soll ein Admin entscheiden, welche von 5 Übersetzungen denn jetzt die one-and-only ist... Nee.
Edit: Was nicht heißt, daß ein potentieller Admin-Tool-Autor das nicht so machen kann.

Das ist nur die eine Seite der Medaille. Du kannst dir nicht vorstellen wie viele widersprüchliche und vor allem wie viele verwaiste Sprachstrings ich gefunden habe. Ganz zu schweigen von unterschiedlichen Quelltexten, die sich problemlos zusammenfassen lassen - z.B. lässt sich 'contact', 'CONTACT' und 'Contact' problemlos z.B. zu 'Contact' zusammenfassen und so zwei Übersetzungen einsparen. Auf diese Weise lassen sich eine Unmenge Bereinigungen durchführen. Ich hatte beim ersten Durchlauf auf meinem Entwicklungsserver mit dem i18nEditor etwa 2.000 Übersetzungen erfasst, am Schluß waren es noch knapp 1.600. Wirklich erstaunt hat mich die ernorme Anzahl von verwaisten Übersetzungen die ich gefunden habe.

Bisher musste ich immer daran denken Quelltexte zeitnah zu übersetzen damit ich sie nicht vergesse, das brauche ich jetzt nicht mehr, der Editor ist während der Entwicklung eine willkommene Unterstützung.