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
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.
-
@UncleSam sagte in Trial: Weblate für ioBroker Übersetzungen:
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.
Das hat bisher leider nie geklappt, da hatten wir schon 2 oder 3 Anläufe gemacht. Die Beteiligung war gering bis gar nicht.
Auch wenn das immer auf die Komplzierte Technik geschoben wurde bin ich mir ziemlich sicher das es damit wenig zu tun hatte. Wahrscheinlicher ist das es unter 10.000 nur einen gibt der das machen möchte. Das heist 4 Leute auf ioBroker und 300+ Adapter.Also bleibt das am Ende doch am Entwickler hängen. Aber selbst hier kann man schon viel verbessern wenn nicht jede Übersetzung für Buttons oder Beschriftungen die immer wieder gleich sind in jedem Adapter gemacht werden.
Verbesserungsvorschläge:
- Wiederkehrende Elemente im Backend (Admin/Config) global zur Verfügung stellen = einheitliche Übersetzungen und Natürlich Optik (mit Admin 5 sollte das kein Problem sein)
- Häufig verwendete Begriffe/Sätze in globaler Übersetzungsdatei halten, die durch Adapter bei Installation erweitert wird
- keine Worte als Keys sondern eine definierte Buchstaben-Zahlenkombination die Einzigartig ioBroker weit ist. Das Lässt sich leicht Automatisch prüfen und in einem Zentralen tool verwalten, dadurch wird das Pflegen der Übersetzungen nochmal vereinfacht.
- tool (falls mit weblate nicht möglich) das Entwickler dabei Unterstützt vorhandene Übersetzungen zu verwenden statt neue an zu legen.
-
Habe jetzt nicht den ganzen Thread verfolgt.
Ist es vorgesehen, das AutoTranslate auszusetzen, wenn es eine manuell Übersetzung in einer Sprache gibt?
Und klar: Worte die in allen Sprachen nicht übersetzt werden, wie Fachbegriffe oder Namen, sollen müssen irgendwie markiert werden. In der Autoübersetzung der Doku, die Bluefox mit gulp (??) programmiert hat, müssen solche Worte in einfache Hochkommata gesetzt werden.
-
@Jey-Cee sagte in Trial: Weblate für ioBroker Übersetzungen:
keine Worte als Keys sondern eine definierte Buchstaben-Zahlenkombination die Einzigartig ioBroker weit ist
Ich verstehe den Grund hierfür, habe aber die Befürchtung, dass es dann für den Entwickler sehr unübersichtlich wird, wenn die Admin-Seite z.B. so aussieht:
<div class="translate">c0738a93-ea2d-4f43-babb-5e1ca9ed15a2</div> <div class="translate">19ad0c44-0c32-49bc-a573-3c2faa0ad2eb</div> <div class="translate">e22035f2-052c-4ca9-a65c-44a40c516f0b</div> -
@AlCalzone mag sein das man dann nicht sofort sieht welcher Text da rein kommt, sieht man ja aber mit Kurzwörtern auch nicht. In deinem Beispiel fehlt eigentlich ein sehr Wesentlicher bestand teil, das Attribute id. Damit gewinnt man generell mehr Übersicht.
Btw. ist das schon extrem lang als Key ich Dachte da eher so an 8 Stellen.
-
@Jey-Cee wofür ist die ID nötig?
Alternativ vielleicht eher so?<div class="translate" data-key="abcdefg012345">Platzhaltertext</div>Der Platzhaltertext könnte dann z.B. wie bisher häufig der Fall mit dem englischen Originaltext übereinstimmen, damit man zumindest eine Orientierung hat.
-
The HTML id attribute is used to specify a unique id for an HTML element.
You cannot have more than one element with the same id in an HTML document.
Ich dachte Anfangs auch eher an so eine Lösung über ein data Attribute. Dann wäre auch der Platzhalter Text möglich. Ist halt nur die Frage geht das jetzt schon oder muss das gebaut werden.
