Trial: Weblate für ioBroker Übersetzungen
-
Im Meeting gestern (war super, danke allen!) wurde entschieden, dass wir mal einige GitHub Projekte zusammenstellen, die wir in einem ersten Trial in Weblate übersetzen wollen.
Mehr zu Weblate haben wir schon an folgenden Stellen diskutiert:
https://forum.iobroker.net/post/220793
https://forum.iobroker.net/post/470110Ich bitte euch hier Adapter oder andere ioBroker GitHub Projekte vorzuschlagen. Bei jedem Vorschlag wäre ich froh, zu wissen, wie der Übersetzungsprozess heute funktioniert (welche Datei(en) sind der Ursprung, was wird generiert, ...).
Ich werde mir dann einige Projekte raussuchen und damit den Trial starten.
Die Projekte werden dann Besuch bekommen von meinem Freund https://github.com/ioBrokerTranslator
-
Ich beginne gleich mal mit dem ersten Vorschlag:
Als ganz einfachen Adapter nominiere ich https://github.com/UncleSamSwiss/ioBroker.loxone
Hier werden alle Übersetzungen noch manuell in admin/words.js gepflegt, aktuell sind nur Deutsch, Englisch und Russisch vorhanden. -
Admin / Info / BackitUp wegen der hohen Anzahl an Installationen und potentiellen Helfern und gleichzeitig komplexerer UI mit vielen Übersetzungen.
-
@AlCalzone Kannst du bitte noch erläutern, wie der Übersetzungsprozess heute in diesen drei Projekten funktioniert?
-
@UncleSam Ich glaube (ohne alle drei im Detail angeschaut zu haben) wie folgt: https://forum.iobroker.net/topic/19047/gulp-ist-kein-hexenwerk-auto-translation
-
Ich hätte da 2 die for einer stable release stehen und nicht al zu gross/komplex sind mit words :
- https://github.com/iobroker-community-adapters/ioBroker.tado
- https://github.com/iobroker-community-adapters/ioBroker.sourceanalytix
Diese adapter verwenden das gulp translate und alle Resultate stehen in der words.js
-
@Dutchman sagte in Trial: Weblate für ioBroker Übersetzungen:
- https://github.com/iobroker-community-adapters/ioBroker.tado
- https://github.com/iobroker-community-adapters/ioBroker.sourceanalytix
Diese adapter verwenden das gulp translate und alle Resultate stehen in der words.js
Jetzt bin ich verwirrt: du schreibst, die Adapter verwenden gulp translate, aber
- ich finde die JSON Dateien in tado nicht: https://github.com/iobroker-community-adapters/ioBroker.tado/tree/master/admin
in beiden Repos ist words.js eingecheckt, was ja dann bei gulp translate nicht mehr sein sollte, oder?- bei sourceanalytix stimmen words.js und die JSON-Dateien nicht überein - und gewisse Wörter sind nicht einmal auf Englisch übersetzt, geschweige denn all die anderen Sprachen
-
Das sind eigentlich die wichtigsten...
Admin: https://github.com/ioBroker/ioBroker.admin/tree/master/admin/i18n , https://github.com/ioBroker/ioBroker.admin/tree/master/src/i18n , https://github.com/ioBroker/ioBroker.admin/tree/master/src-rx/src/i18n und https://github.com/ioBroker/ioBroker.admin/tree/master/docs
Backitup: https://github.com/simatec/ioBroker.backitup/tree/master/admin/i18n
Info: https://github.com/iobroker-community-adapters/ioBroker.info/tree/master/admin/i18n und https://github.com/iobroker-community-adapters/ioBroker.info/tree/master/docsNormalerweise sollten die words.js immer aus den json automatisch generiert werden. Ich glaube die meisten Adaptern funktionieren heute so. Bei kleinere Übersetzungen werden aber die json weg gelassen und direkt in die words.js rein geschrieben.
javascript: https://github.com/ioBroker/ioBroker.javascript/tree/master/admin/google-blockly/msg/js , https://github.com/ioBroker/ioBroker.javascript/tree/master/admin/google-blockly/own/msg , https://github.com/ioBroker/ioBroker.javascript/tree/master/admin-config/i18n , https://github.com/ioBroker/ioBroker.javascript/tree/master/src/src/i18n und https://github.com/ioBroker/ioBroker.javascript/tree/master/docs
-
@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
@Dutchman sagte in Trial: Weblate für ioBroker Übersetzungen:
- https://github.com/iobroker-community-adapters/ioBroker.tado
- https://github.com/iobroker-community-adapters/ioBroker.sourceanalytix
Diese adapter verwenden das gulp translate und alle Resultate stehen in der words.js
Jetzt bin ich verwirrt: du schreibst, die Adapter verwenden gulp translate, aber
- ich finde die JSON Dateien in tado nicht: https://github.com/iobroker-community-adapters/ioBroker.tado/tree/master/admin
da hat der Entwickler verpeilt die JSON Dateien hinzuzufügen
- bei sourceanalytix stimmen words.js und die JSON-Dateien nicht überein - und gewisse Wörter sind nicht einmal auf Englisch übersetzt, geschweige denn all die anderen Sprachen
Da hat der Entwickler verpeilt die JSON Dateien in words.js zu konvertieren.
-
Ganze Websiten / Markdown Dokumente werde ich in einem ersten Schritt nicht unterstützen. Hauptgrund dafür ist, dass wir einen guten Workflow haben müssen. Wir sollten Dokumentation nicht "ein bisschen" übersetzen sondern immer sicher stellen, dass alles sauber übersetzt ist. Das ist ein komplett separates Thema, das ich nicht mit dem Übersetzen von Adaptern vermischen möchte.
Ein Beispiel, wie es gemacht werden kann: https://f-droid.org/docs/Translation_and_Localization/#f-droidorg-website
Zudem unterstützt Weblate aktuell noch kein Markdown https://github.com/WeblateOrg/weblate/issues/3106closed Markdown files support #3106
-
@UncleSam said in Trial: Weblate für ioBroker Übersetzungen:
in beiden Repos ist words.js eingecheckt, was ja dann bei gulp translate nicht mehr sein sollte, oder?
ich würde auch bei automatisch erstellter words.js diese mit einchecken. Das ist in der ioBroker Welt bei (fast) allem automatisch generierten so und erlaubt es die Adapter auch aus github zu installieren (ohne, dass der User alle devDependencies braucht um nochwas im postinstall step zu bauen).
-
ich würd mal den zigbee nehmen
-
@Garfonso sagte in Trial: Weblate für ioBroker Übersetzungen:
ich würde auch bei automatisch erstellter words.js diese mit einchecken.
Definitiv. Alles auf Github, aber nur das nötigste (inklusive words.js) bei npm releasen
-
@AlCalzone sagte in Trial: Weblate für ioBroker Übersetzungen:
Definitiv. Alles auf Github, aber nur das nötigste (inklusive words.js) bei npm releasen
Da bin ich jetzt selber rein gefallen... klar! Es gibt aber leider gewisse Adapter, die dies nicht machen. Vielleicht sollten wir den Adapter Checker irgendwann mal um Tests erweitern, dass ein Adapter von GitHub installiert werden kann.
-
@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
Tests erweitern, dass ein Adapter von GitHub installiert werden kann.
Oder dass andernfalls das Flag noGit in der io-package.json gesetzt ist -
@Fenian sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Ich habe das hier vor geraumer Zeit gelesen, wollte es eigentlich ignorieren aber es hat mich die ganze Zeit beschäftigt und teilweise auch aufgeregt.
Daher mal gebe ich doch noch mal meinen Senf dazu.@Fenian Danke für dein wertvolles Feedback!
Ich teste gerade die Weblate Integration in den Prozess und muss dir vor allem in einem Punkt recht geben:
Automatische Übersetzungen sind die Hölle und sinnlos! Gewisse (deutschsprachige!) Entwickler (ich will hier keine Namen nennen) schreiben knapp brauchbares Englisch, das dann in unbrauchbares Deutsch umgewandelt wird. Oder mein Liebling von gestern: "ZigBee-Hirten-Debug-Info"
Ich würde einige Änderungen vorschlagen (durchnummeriert, damit man sich darauf beziehen kann):
- automatisches Generieren von Übersetzungen komplett weglassen
- ein Adapter muss zwingend auf Deutsch und Englisch übersetzt sein, damit er aufgenommen wird (respektive eine neue Version akzeptiert wird)
words.jswird durch die i18n-Dateien ersetzt - damit können wir dann Gulp komplett weglassen (muss nicht sofort geschehen)- Als "Keys" in den Übersetzungen verwenden wir Kurzwörter, nicht Englischen Text (geschweige denn formatiertes HTML!)
- Admin 5 erhält die Möglichkeit, die Sprache on-the-fly zu ändern - Fallback ist für jede Sprache ist Englisch
- Wir verwenden Weblate um die Übersetzungen der Adapter zu pflegen
- Weblate ist für Adapter nicht zwingend, wird aber sehr empfohlen
- Wir erarbeiten einen Vorschlag, wie längere Texte in Adaptern dargestellt und übersetzt werden können (Vorschlag von @Mic in https://forum.iobroker.net/post/488807)
- Wir planen, wie wir die Dokumentation (von ioBroker, nicht von einzelnen Adaptern) einheitlicher machen können; denn erst danach macht es auch Sinn, an Übersetzungen zu denken.
Weitere Ergänzungen und vor allem Kommentare sind willkommen
-
@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
Oder mein Liebling von gestern: "ZigBee-Hirten-Debug-Info"
Ohne das ich Deine Aussage zur Qualität der englischen Doku bei Adapter-Entwicklern in Frage stellen mag ist genau dieses Beispiel nicht ganz passend.
Die vom Adapter benutzte Bibliothek heisst Zigbee-Herdsman, wörtlich übersetzt Zigbee-Hirte. Die muss man da sauber benennen. Es fehlt also die Kennzeichnung als "Dieses Wort darf NIE übersetzt werden"
-
@Asgothian sagte in Trial: Weblate für ioBroker Übersetzungen:
Es fehlt also die Kennzeichnung als "Dieses Wort darf NIE übersetzt werden"
Und genau das ist das Problem, es wurde in der aktuellen Version auf Deutsch übersetzt: https://github.com/ioBroker/ioBroker.zigbee/blob/89f34c8b0d45beb9b959500a29e89ac9052f01ff/admin/i18n/de/translations.json#L80
-
@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
ein Adapter muss zwingend auf Deutsch und Englisch übersetzt sein,
Geht auf gar keinen Fall, es gibt Russische Entwickler die Definitv kein Deutsch Sprechen, bestenfalls Englisch. Das würde auch jedes Internationale Wachstum unmöglich machen.
Wenn dann nur Englisch und jede weitere Sprache ist Optional.@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
Als "Keys" in den Übersetzungen verwenden wir Kurzwörter, nicht Englischen Text (geschweige denn formatiertes HTML!)
Wenn ich mich richtig erinnere gab es mal "data-translate" oder so ähnlich als Attribut, keine Ahnung ob die Spracheinstellung in ioBroker das Berücksichtigt.
-
@Jey-Cee sagte in Trial: Weblate für ioBroker Übersetzungen:
Geht auf gar keinen Fall, es gibt Russische Entwickler die Definitv kein Deutsch Sprechen, bestenfalls Englisch. Das würde auch jedes Internationale Wachstum unmöglich machen.
Ich gebe dir recht, dass es Entwickler gibt, die kein Deutsch können - genau so wie es Entwickler geben wird, die nicht (genügend) gut Englisch können. Dafür ist aber die Community da.
Damit will ich (zumindest im Moment) verhindern, dass deutschsprachige Anwender (die doch ganz klar die Mehrheit bilden) mit schlechten Englisch-Kenntnissen nicht vor den Kopf gestossen werden und aufgeben, weil sie die Beschreibung zum Adapter nicht verstehen - und dann auch keine Fragen stellen können, da sie ja auch kein Englisch schreiben können.
Mein Vorschlag ist, dass man sich an die Community wendet und diese sicher stellt, dass der Adapter in die zwei Sprachen übersetzt ist, bevor er als "stable" raus geht.
Bei den meisten Adaptern ist die Übersetzung in ein paar Minuten erledigt. Ich habe vorhin zum Test die Englische Übersetzung von backitup überarbeitet - in weniger als 15 Minuten.
