Trial: Weblate für ioBroker Übersetzungen

[Garfonso]

@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).

[arteck]

ich würd mal den zigbee nehmen

[AlCalzone]

@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

[UncleSam]

@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.

[AlCalzone]

@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

[UncleSam]

@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):

1. automatisches Generieren von Übersetzungen komplett weglassen
2. ein Adapter muss zwingend auf Deutsch und Englisch übersetzt sein, damit er aufgenommen wird (respektive eine neue Version akzeptiert wird)
3. words.js wird durch die i18n-Dateien ersetzt - damit können wir dann Gulp komplett weglassen (muss nicht sofort geschehen)
4. Als "Keys" in den Übersetzungen verwenden wir Kurzwörter, nicht Englischen Text (geschweige denn formatiertes HTML!)
5. Admin 5 erhält die Möglichkeit, die Sprache on-the-fly zu ändern - Fallback ist für jede Sprache ist Englisch
6. Wir verwenden Weblate um die Übersetzungen der Adapter zu pflegen
7. Weblate ist für Adapter nicht zwingend, wird aber sehr empfohlen
8. 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)
9. 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

[Asgothian]

@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"

[UncleSam]

@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

[Jey Cee]

@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.

[UncleSam]

@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.

[Jey Cee]

@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.

[Homoran]

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.

[AlCalzone]

@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>

[Jey Cee]

@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.

[AlCalzone]

@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.

[Jey Cee]

@AlCalzone

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.

[Fenian]

@Fenian Danke für dein wertvolles Feedback!

Dafür nicht Mir ist da einfach mal der Kragen geplatzt.
Vor allem wegen der automatischen Übersetzungen, aber eben auch weil das passiert ist, was passieren musste, wenn Entwickler unter sich sind
Es wird alles haarklein diskutiert, aber leider ohne die Seite zu hören, die hinterher übersetzen soll.

Und wenn ich jetzt hier so lese wird es eher noch schlimmer.

@Jey-Cee sagte in Trial: Weblate für ioBroker Übersetzungen:

@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.

Ich habe da jetzt nicht nach gesucht, aber irgendwelche Posts im Forum sind da IMHO nicht hilfreich. Das setzt nämlich auch voraus, dass die Leute auch hier im Forum regelmäßig lesen.
Nutzt doch das, was jeder regelmäßig nutzt: Das Backend.
Kurzer Hinweis oben in der Adapter-Übersicht, optimaler Weise in der Benutzersprache und bei den Adaptern noch einen knappen Hinweis auf den jeweiligen Status der Übersetzung inkl. Link auf Weblate oder was auch immer

• 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.

Ich stimme dir größtenteils zu. Viele Dinge kann man global zur Verfügung stellen.
Aber wozu eine Buchstaben-Zahlenkombination die Einzigartig ioBroker weit ist?

Ich finde das eher hinderlich für beide Seiten.
Woher sollen die IDs kommen und wie verträgt sich das mit der Wiederverwendung?
Das Attribut ID ist eben eindeutig, wie du selber sagst.

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.

Irgenwelche IDs ohne Aussagekraft wären für mich als Übersetzer ein guter Grund nichts zu übersetzen

@Mic smartcontrol.zip
Das sind nur die geänderten Dateien (genauer gesagt: Ich habe nur die .html geändert)
Verwendet werden:
i18next
i18next-wc für Datum, Zeit,Nummer
loc-i18next um mit html-Selektoren zu arbeiten
i18next-parser für Gulp-Task
Schau dir die geänderte index_m.html an dann wird dir auch schnell klar, wie es funktioniert.

[Jey Cee]

@Fenian sagte in Trial: Weblate für ioBroker Übersetzungen:

Nutzt doch das, was jeder regelmäßig nutzt: Das Backend.

Die Idee hatte ich schon früher geäußert.
Klar wäre das eine Super Lösung, aber das ist nicht so einfach. Das muss sich so in den Admin integrieren das man es einfach Finden kann und andererseits sollte der Admin nicht Unübersichtlicher werden*.
Und spätestens hier wären wir wieder bei einer Einzigartigen ID um das dann Tracken zu können. Zumindest hätte der Enduser dann keinen Berührungspunkt mehr damit und es spielt keine Rolle.

@Fenian sagte in Trial: Weblate für ioBroker Übersetzungen:

Aber wozu eine Buchstaben-Zahlenkombination die Einzigartig ioBroker weit ist?

Als eindeutiges Identifikationsmerkmal der Übersetzung, Einzigartige ID.

@Fenian sagte in Trial: Weblate für ioBroker Übersetzungen:

Das Attribut ID ist eben eindeutig, wie du selber sagst.

Eine id eines HTML Elements kann nur einmal auf einer Seite existieren aber sehr wohl öfter in einem Projekt verwendet werden, die eigenen sich also nicht für diesen Verwendungszweck.
Daher erübrigt sich auch die davor gestellte Frage im Bezug auf das Attribute id.
Die Einzigartige ID müsste von der Übersetzungsverwaltung (Weblate oder was auch immer) erzeugt werden. Hier kann auch geprüft werden ob schon eine Übersetzung zu dem Gewünschten Text vorhanden ist, wenn ja muss man nur die ID verwenden und das wars.

Insgesamt hätte das auch den Vorteil das die Übersetzungen unabhängig von Adapter Versionen wären, weil man sie bei jedem Aufruf des Admin von der Übersetzungsverwaltung laden könnte. Hier muss man sich Gedanken machen wie man es am Intelligentesten Umsetzt damit nicht jedesmal der Server angefragt werden muss. (Manuelles Update über einen Button?)

@Fenian sagte in Trial: Weblate für ioBroker Übersetzungen:

Irgenwelche IDs ohne Aussagekraft wären für mich als Übersetzer ein guter Grund nichts zu übersetzen

Versteh ich nicht. Du hast ein Tool dort gibst du deinen Text ein oder die ID das wird gesucht und dann kannst du den Text bearbeiten. Viel einfacher wäre nur die Bearbeitung im Admin direkt.

*Übrerlegung: Rechts Klick -> Menü -> Übersetzung bearbeiten

[AlCalzone]

@Jey-Cee sagte in Trial: Weblate für ioBroker Übersetzungen:

Das muss sich so in den Admin integrieren das man es einfach Finden kann und andererseits sollte der Admin nicht Unübersichtlicher werden*.

Können wir nicht mit dem Info-Adapter einmalig ne Meldung bringen?

[UncleSam]

@Jey-Cee sagte in Trial: Weblate für ioBroker Übersetzungen:

Das hat bisher leider nie geklappt, da hatten wir schon 2 oder 3 Anläufe gemacht. Die Beteiligung war gering bis gar nicht.

Ich helfe gerne mit bei:

• Englisch
• Deutsch
• Französisch

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)

Sehr gute Idee. Würde meines Erachtens schon heute mit "OK" und anderen Texten funktionieren (hab ich aber nicht getestet).

• Häufig verwendete Begriffe/Sätze in globaler Übersetzungsdatei halten, die durch Adapter bei Installation erweitert wird

Weblate bietet ein manuell geführtes Glossar, das kann bei der einheitlichen Übersetzung (insbesondere von Sätzen) sehr helfen. Zudem hat es ein automatisches Translation Memory um gleiche (oder ähnliche?) Texte als Vorschläge anzuzeigen.

• 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.

Weblate stellt diese Keys nur "nebenbei" dar (Ausnahme: Englisch), daher ist es aus dieser Sicht irrelevant. Weblate zeigt in erster Linie Englisch und die zu übersetzende Sprache an. Ich würde allerdings eher vorschlagen:
<adapter>.<key> also z.B. global.password oder i2c.bus-number. Die wären etwas sprechend für den Entwickler und doch kurz aber eindeutig.

• tool (falls mit weblate nicht möglich) das Entwickler dabei Unterstützt vorhandene Übersetzungen zu verwenden statt neue an zu legen.

Ich bin mir nicht sicher, ob es einfacher ist, wenn der Entwickler vorhandene Übersetzungen suchen muss (mit einem Tool) oder Vorschläge in Weblate mit dem Translation Memory gemacht werden. Ich würde wohl einfach eine Liste der global verfügbaren Strings veröffentlichen (resp. dem Entwickler sagen, wo er die findet) und den Rest im Adapter belassen.