Meeting für ioBroker Core/Dev/Admin 14.07.20 20:30
-
@apollon77 said in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
<div translation_id="meinCoolerText">
Wofür brauchst du die id dann noch? Ich hatte den Ansatz von @Mic so verstanden, dass er ja gerade das mit den IDs nicht mehr will und das im Grunde alles automatisch generiert werden soll -> das könnte ja dann die IDs direkt mit generieren, damit man da nicht wieder in das Problem läuft, dass IDs nicht gepflegt werden (nicht eindeutig, ungenutzt, blah).
Oder hab ich da was falsch verstanden / übersehen?
-
@Garfonso Naja die Idee ist ja das Mapping zu Loca-IDs und damit das "auslagern in die words.js" zu automatisieren. ich kennen aktuell noch keinen sinnvollen Weg ohne dies. Bei einfachen texten geht es auch ihne indem der Text zum KEy wird, aber sobald das komplexer wird wird das ziemlich blöd finde ich ...
-
@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Bei einfachen texten geht es auch ihne indem der Text zum KEy wird, aber sobald das komplexer wird wird das ziemlich blöd finde ich ...
Die Fehlermeldungen vom TypeScript-Compiler werden beispielsweise genau so generiert.
-
Hi zusammen,
- Hier noch mal der initiale Beitrag von mir zu dieser Diskussion.
- Und hier der derzeitige Aufwand für Entwickler aus meiner Sichtweise.
@AlCalzone sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Bei einfachen texten geht es auch ihne indem der Text zum KEy wird, aber sobald das komplexer wird wird das ziemlich blöd finde ich ...
Die Fehlermeldungen vom TypeScript-Compiler werden beispielsweise genau so generiert.
Ich kenne jetzt die Übersetzungs-Funktionalität (Stichwort
word.js) noch nicht wirklich, aber ich denke, der dafür zuständige Code müsste auch angepasst werden.Wie auch immer:
So wie ich die JavaScript-Spezifikation verstehe, darf ein Objekt-Key (also derkeybei{'key':'val'}ein beliebiges String beinhalten. Somit sind also keine Grenzen gesetzt. Lasse mich da gerne korrigieren
Damit ist es also egal, wie komplex das String ist, (Browser-)Performance mal außen vor.Jetzt kann doch ein Script folgendes machen:
index_m.htmlper jQuery: alle Inhalte, dietranslateals Klassen-Zuweisung enthalten, per Loop durchlaufen:- Inhalte übersetzen und Ergebnis in Variable und dann Zieldatei.
- Für Übersetzung: vorher definierte Tags zur Übersetzung ignorieren (z.B.
<code>true</true>oderText <span="non-translate">ioBroker<span>und einzelne Teile separat übersetzen. - Nach Übersetzung: ignorierte Bestandteile wieder in HTML-Variable hinzufügen
- Für Übersetzung: vorher definierte Tags zur Übersetzung ignorieren (z.B.
- Ergebnis ab in die
words.js:- hier dann auch bereinigen zum Schluss, d.h. unbenutzte Einträge löschen. Geht natürlich nur, wenn global verfügbar, welche Keys gesetzt wurden.
Falls das on-the-fly nicht möglich oder aus Browser-Performance-Gründen nicht sinnvoll, könnte man auch entsprechend komplilieren und "_min.xxx" Dateien generieren lassen, wie z.B. "words_min.js"
-
@Mic Also ja natürlich kann man den beliebigen Text in die Words packen ... Dann bräuchte man beim zurückschreiben noch eine Erkennung das ein text schon übersetzt ist damit er nicht nochmal wird - und man muss sich selbst dran halten sowas nicht nochmal zu editieren sondern die words.js ab der initialen Übersetzung zu nutzen ... sonst landet der neue text beim nächsten "übersetzungslauf ausführen" unter dem neuen text nochmal drin und es entstehen doubletten und riiiesige words.js Files
Daher meine Idee es durch ne unique ID zu ersetzen ... dann sieht man das gleich. geht aber bestimt auch anders.Die Logik mit Übersetzung und so (geht ja nicht in words.js sondern in die translation files denke ich) ist glaube im gulp drin. Am Ende passt eine neue Logik denke da am besten hin. Also im gulp das html parsen, texte finden und "bearbeiten".
Ansonsten: einzelne Teile überstzen geht nicht wiel sonst der Satzaufbau komplett zerstört wird. Also man muss wirklich die nicht zu übersetzenden Teile rausholen und durch etwas ersetzen was er nicht übersetzt, und danach den ganzen Text mit den Platzhaltern übersetzen lassen und dann wieder die platzhalter zurück-einfügen
-
Ich werfe auch mal https://weblate.org/de/ in den Raum, UncleSam hat mich darauf aufmerksam gemacht
@UncleSam sagte in Gulp ist kein Hexenwerk - Auto translation:
Hallo ldittmar
Übersetzungen sind ein schwieriges Thema. Bis jetzt müssen wir Adapter Entwickler mit Google/Yandex übersetzen und dann "native speaker" im GIT Korrekturen per PR einbringen. Bei meinem aktuellen Arbeitgeber sind wir von einem teilweise manuellen Prozess (mit Excel-Listen!) auf https://weblate.org/en/ umgestiegen.
Die Installation und Konfiguration war innert wenigen Stunden erledigt und nun können wir alle Übersetzungen in einem Online Tool pflegen - wenn nötig auch mit externen Übersetzern. Wir sind schon nach wenigen Wochen begeistert - der Prozess benötigt keine manuellen Schritte mehr für die Entwickler!
Wäre das nicht ein interessantes Tool für all die Übersetzungen von Adaptern? Es liesse sich auch jeder Adapter mit seinem eigenen GitHub Repo einbinden (sofern die entsprechenden Autoren einverstanden sind).
Wenn das Interesse vorhanden ist, kann ich auch noch etwas detaillierter über das Tool berichten und euch bei der Inbetriebnahme / Integration helfen.
/UncleSam
@UncleSam sagte in Gulp ist kein Hexenwerk - Auto translation:
Es ist Open Source und wie gesagt innert kürzester Zeit eingerichtet. Ich gehe davon aus, dass ioBroker schon eine gewisse Server Infrastruktur (respektive Cloud Infrastruktur) hat, damit würde der Preis aus meiner Sicht 0 € betragen.
@UncleSam sagte in Gulp ist kein Hexenwerk - Auto translation:
Die Einrichtung ist keine grosse Sache; ein Aufwand besteht natürlich pro GIT Repo, das man anhängen will (für uns: pro Adapter).
Weblate nimmt die Übersetzungen direkt aus dem GIT und kann sie auch wieder ins GIT zurückspielen. Für GitHub gibt es die Möglichkeit über Pull Requests: https://docs.weblate.org/en/latest/vcs.html#github Damit muss Weblate nicht einmal spezielle Rechte für ein Repository haben.
Wie gesagt bin ich gerne bereit, bei der Umsetzung zu helfen und würde das auch einfach mal mit einem meiner Adapter testen, bevor wir das "ausrollen" würden. Ich will nur nicht für mich eine "Insellösung" erarbeiten, wenn wir gleich eine Lösung für (fast) alle bauen können.
Ich kenne Weblate null, aber das klingt wirklich hochinteressant!
der Prozess benötigt keine manuellen Schritte mehr für die Entwickler!
-
@Mic Danke für die zahlreichen Zitate
I18N (Internationalization) ist ein häufiges Problem und wir sind sicherlich nicht die ersten (und nicht die letzten), die sich dem annehmen müssen. Als Schweizer Softwareentwickler bin ich fast in jedem Projekt zweisprachig unterwegs (DE/FR); meist kommt noch Englisch dazu.
Die Problematik muss an zwei Stellen angegangen werden:
- Die Software muss übersetzbar sein
- Die Übersetzungen müssen einfach gepflegt werden können
Die Diskussion hier dreht sich vor allem um den ersten Punkt, mein Vorschlag für Weblate konzentriert sich auf den zweiten (nur damit wir hier nicht allzu wirr durcheinander reden).
Für 1. gibt es gute Frameworks und gute Beschreibungssprachen. Hier einige Beispiele: https://docs.weblate.org/en/latest/formats.html
Dabei ist wichtig, dass das Tool nicht nur einfache Texte übersetzen kann, sondern zum Beispiel auch mit Plural/Daten umgehen kann. ICU macht das sehr schön: http://userguide.icu-project.org/formatparse/messages :"{num_guests, plural, offset:1 " "=0 {{host} does not give a party.}" "=1 {{host} invites {guest} to her party.}" "=2 {{host} invites {guest} and one other person to her party.}" "other {{host} invites {guest} and # other people to her party.}}}"Ich denke wir müssen uns für beide Punkte auf etwas einigen und beides muss zusammen passen. Dabei würde ich versuchen, auf Standard-Tools zu setzen und nicht zu viel selber zu erfinden/entwickeln. Bis jetzt habe ich im Web-Bereich nur mit Angular I18N gearbeitet - und allein schon dort gibt es drei populäre Lösungen.
"Im Nachhinein Übersetzen" ist IMHO eine schlechte Strategie, sprich: Übersetzungen müssen von Anfang an in der Software vorgesehen sein. Irgendwie versuchen, Texte herauszusuchen und diese dann in eine Datei abzufüllen funktioniert sehr schlecht. Gerade auch Teilsätze (beim Einsetzen von Daten) können ein heilloses Durcheinander auslösen.
Automatische Übersetzungen sind ein guter erster Schritt, damit ioBroker internationaler wird, aber wer mag Software schlecht die Übersetzung sein or not all translated?
Teilweise ist schon Deutsch schwierig, beim Englisch holpert es dann doch öfters in ioBroker.Ich freue mich auf einen guten Austausch und bin gerne bereit in den nächsten Wochen Zeit in eine gute Lösung zu stecken.
-
Vielen Dank für deine Initiative, Super
Wie ist das denn mit Weblate hinsichtlich Dokumentation versus Applikation (Frontend) selbst:
Mein persönlicher Anstoß war, dass ich in
ioBroker.adapter-xyz/admin/index_m.htmlauch eine direkte Hilfe dem Anwender biete (https://github.com/Mic-M/ioBroker.smartcontrol).Dort habe ich etwa folgendes, also eine "Online-Hilfe/Dokumentation" für den Anwender:
Lässt sich denn so etwas, also der Text mit der Tabelle, auch einfach mit Weblate abbilden?
Quellcode:
Oder ist Weblate primär für die "eigentliche" Software gedacht, also Auswahlfelder, Feldbezeichnungen, usw.?
-
@UncleSam Weblate kostet aber, oder ?!
-
@apollon77 selfhosted ist kostenlos.
-
@Mic sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Lässt sich denn so etwas, also der Text mit der Tabelle, auch einfach mit Weblate abbilden?
Weblate übersetzt - nicht mehr und nicht weniger. Du hast ja bereits
class="translate"hinzugefügt, das muss dann ein Tool extrahieren (geht in deinem Fall sehr einfach) und Weblate bietet dann einfach alle Teil-Strings zur Übersetzung an.Ganze Seiten mit HTML Tags etc. würde ich nicht von Weblate übersetzen lassen (das bedingt, dass der Übersetzer HTML versteht), allerdings kann ich mir vorstellen, einfaches Markdown übersetzen zu lassen (z.B. für https://raw.githubusercontent.com/ioBroker/ioBroker.docs/master/docs/en/dev/adaptervis.md, aber eher nicht für grosse Dokumente wie https://raw.githubusercontent.com/ioBroker/ioBroker.docs/master/docs/en/dev/adapterdev.md).
Das mit dem Extrahieren ist ein wichtiger Punkt: der Entwickler muss natürlich zu übersetzenden Text irgendwie markieren, aber den markierten Text zu extrahieren sollte man unbedingt einem Tool überlassen. Sprich für ioBroker: words.js (oder was es dann auch immer sein wird) wird komplett von Weblate erzeugt, der Entwickler muss nur etwas (z.B.
class="translate"eventuell mitid="unique-id") zu jedem Tag hinzufügen, den er übersetzt haben will. -
@UncleSam Bevor wir noch einen Server aufsetzten, vielleicht können wir in die Richtung crowdin schauen?
Ich habe ein Beispielprojekt angelegt: https://crowdin.com/project/iobrokeradmin
Oder hier als Enterprise: https://iobroker.crowdin.com/
-
@Bluefox sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
vielleicht können wir in die Richtung crowdin schauen?
Crowdin sieht auch gut aus. Ich habe schon davon gehört, aber noch nie damit gearbeitet. Ich nehme an, die GitHub/PR Integration ist sicherlich gut gelöst. Wie sieht es mit mehreren Repos aus? Kann man alle Adapter Repos zusammenfassen oder muss das jeder Entwickler selber machen? Ich denke eine zentrale Lösung ist notwendig, sonst macht wieder jeder Entwickler etwas und Übersetzungen sind dann immer noch gleich schwierig zu behandeln.
-
@UncleSam Ich vermute, dass es keine Zentrale Lösung gibt.
-
@UncleSam Die Erfahrung zeigt das wir einheitliche Lösungen und "Best practices" anbieten können, es wird dennoch jedem Entwickler überlassen bleiben was er tut.
-
Ich weiß, das Thema ist schon etwas älter.
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.
Warum?
Ich würde mich zwar nicht als Entwickler bezeichnen, habe aber knapp 16 Jahre Erfahrung in einem relativ grossen Opensource-Projekt, davon ein großer Teil mit Übersetzungen.@UncleSam sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Die Problematik muss an zwei Stellen angegangen werden:
- Die Software muss übersetzbar sein
- Die Übersetzungen müssen einfach gepflegt werden können
Ja, Punkt 1 ist der wichtigste, für 2. finden sich Lösungen
Aber für mich betrifft I18N nicht nur die Software an sich, sondern auch das ganze Projekt. Also Webseite/Forum/Doku etc.
Und es nichts, was man mal "so eben" nebenher macht.
Selbst Englisch ist nicht immer Englisch. (z.B. Postleitzahl ->post code (GB) ->zip code (US) / Ferien, Urlaub ->holiday(GB) ->vacation(US)
BTW: Selbst Deepl bietet da jetzt britisch/amerikanisch an. Portugiesisch ist da jetzt auch getrennt.
Englisch ist da allerdings wahrscheinlich unproblematisch, aber wir hatten da mal einen Fall in Portugisisch die Übersetzung in Portugal war völlig ok, aber in Brasilien als ungemessen/beleidigend empfunden wurde.
Manchmal kann es auch politisch werden.
Katalinisch ist da ein gutes Beispiel: Wir hatten sehr viele Übersetzungen ca-AD (Andorra) und nicht ca-ES (Spanien), weil viele Katalanen sich nicht mit Spanien identifizieren wollten.
Für ioBroker sehe ich das nicht wirklich als Gefahr, aber wie man sieht, kann man sich da auch schnell in einem "Minenfeld" befinden.Das grösste Problem ist für mich extreme nennen wir es "Deutschlastigkeit".
Beispiel: Ich klicke als nicht deutschsprachiger Benutzer z.B auf "Announcements" und was sehe ich?
Jede Menge Einträge, aber alles Deutsch.
Wichtige Informationen sollten aber zumindest auch auf Englisch verfügbar sein.
Ob man es mag oder nicht Englisch ist nunmal der Schlüssel."Announcements" hört sich wichtig an, aber ich kann es nicht verstehen. Was dann?
Einer der Hauptgründe das ich hier schreibe ist allerdings die Äußerungen von @Mic
Das harmloseste was mir dazu einfiel ist "ignorant".Als Lösung schlage ich hier vor, einfach Google Translate zu nutzen, damit wird die Übersetzung >an die UI bzw. Client übertragen. Man müsste noch mal besser schauen, welche guten Browser->Plugins es da noch so gibt, um lokale Websites einfach zu übersetzen. Denn dann kann man sich den >Kram komplett sparen.
Man muss hier meiner Meinung nach auch berücksichtigen, wann das Konzept von ioBroker entstanden >ist, nämlich wohl in 2014. Mittlerweile haben wir - jetzt in Juli 2020 - sehr starke UI/Client->Übersetzungstools für "on the fly".Das ist keine Lösung, allenfalls eine Zumutung für die Benutzer.
Diese sehr starken UI/Client->Übersetzungstools für "on the fly" würde ich gerne mal sehen.
Und komm mir nicht mit Google/Yandex und was es da sonst noch gibt.
Deepl ist da sicher weiter und liefert teilweise wirklich brauchbare Ergebnisse, nur eben leider nicht "on the fly"ioBroker ist zum allergrößten Teil einfach Deutsch. Warum also die Entwickler quälen mit Übersetzung ins Chinesische oder warum müssen sie sich einen abbrechen, um >Ausgangstexte in Englisch zu haben? Nicht jeder spricht gut Englisch, btw.
Und warum die deutlich > 90 % deutschsprechenden End-Anwender "quälen" mit fehlender Usability?Quälen und fehlende Usability sind wohl eher so Dinge wie "Übersetzungstools für 'on the fly'"
ioBroker ist zu deutsch.
Ich behaupte mal, dass daher auch die >90% kommen.Auserdem geht doch nicht darum Entwickler zu quälen.
Zwangsweise Übersetzungen ins Chinesische oder sonst was halte ich auch nicht für besonders gut.
Aber bei dir denke ich, wäre Englisch nicht so das Problem.
Zusammen mit Deutsch sind das schon 2 Übersetzungen.
Im Besten Fall findet sich jemand der sich die englische Übersetzung ansieht und korrigiert.
Aber der Schlüssel ist nun mal Englisch, nicht Deutsch.
Du wirst sicherlich mehr Leute finden, die Englisch in Französich, Italienienisch, Chinesisch usw. übersetzen können als DeutschIch empfinde den bisherigen Prozess (sofern ich das beurteilen kann) auch sehr aufwendig.
Aber genau darum geht es doch: Den Prozess vereinfachen, für beide Seiten.Ich habe mir am Wochenende aus Neugier und Langeweile den Spass gemacht und mit ein paar mir bekannten Systemen herumprobiert um den Adapter von @Mic entsprechend anzupassen. (Ist nicht die aktuelle Version des Adapter)
Das Ergebnis ist sicher weit davon entfernt perfekt zu sein aber da steckt auch nur 1 Tag Arbeit drin.
Vorteil:
Keine Texte im Code
Namespaces (Ich habe mir erlaubt, für die Tabs jeweils einen eigenen Namespace anzulegen. Macht die Dateien übersichticher und sind besser zuzuordnen)
Ümschalten der Sprache 'on the fly'
Fallback auf jede gewünschte Sprache (zur Not auch 'de', falls nötig)
Plural, auch mit Gender, Datum und Uhrzeit, relative Datums/Zeitangeben, Internationale Nummerierung z.B. mit Maßangaben.Ich habe zuerst nur mir der HTML-Datei gearbeitet, also ohne ioBroker.
Das hat ganz gut funktioniert und deshalb habe ich das auf meiner Testinstanz mal in ioBroker integriert.
Zu meiner Überraschung lief auch das fast sofort ohne ProblemeZu guter Letzt gibt es noch einen Gulp-Task zu extrahieren der Strings und zu anlegen der etsprechenden Struktur/Dateien.
Hier mal als Beispiel die tabs.json für die Tabs
{ "home": "Start", "devices": "1. Target devices", "conditions": "2. Additional Conditions", "triggers": "3. Trigger", "zones": "4. Zones", "options": "Additional options", "locales": "I18 Demo" }Hier die tabmain.json mit nested und multiline strings
@Mic So oder so ähnlich könnten dann deine Tabellen aussehen{ "instructions": { "headline": "Instructions", "how_to": { "headline": "How to configure the adapter", "intro": "Simply go through the individual options pages (above tabs) as follows:", "tab": "Tab", "what_to_do": "What to do?", "devices": "Enter all your target devices to be switched, i.e. lamps, radio, etc.", "conditions": "<i>optional</i>: Enter your additional conditions that should (not) apply, e.g.: nobody present, holiday today, etc.", "triggers": "Enter all triggers here, i.e.: motion detectors, wall switches, etc., as well as time-dependent triggers.", "zones": "Define all \"zones\" (e.g. 1st floor bathroom, coffee corner, etc.) and assign triggers and target devices to be switched.", "text": "In the tab <span style=\"color: #0d47a1;\">ADDITIONAL OPTIONS</span> you can set further adapter options." }, "tester": { "headline": "For testers", "text": [ "This adapter provides test data points under <code>smartcontrol.x.Test</code>.", "These data points do not provide any functions or features and are only for ", "testing this adapter.", "After the first installation of an instance of this adapter, ", "the adapter options are preset with some of these data points. ", "Start testing, e.g. by activating a trigger data point, e.g. by ", "setting <code>smartcontrol.0.Test.trigger.Bathroom_motion</code> to <code>true</code> ", "Then you check if something is triggered (based on the settings in the table \"Execution\" etc.) ", "<br>The ioBroker Log (ioBroker Admin > Log) provides detailed information. ", "For debugging, please set the log level of the adapter instance to 'debug' ", "to get much more information in the log." ] }, "help": { "headline": "You need help? There's a problem? You have a suggestion for improvement?", "table": { "header_1": "Your topic", "header_2": "What you should do", "topic_1": "I have a question", "answer_1": [ "The best way to ask a question is in the ioBroker forum, ideally you reference <code>@Mic</code> so that I get a message as a developer.", "Current forum thread for this adapter is <a href=\"https://forum.iobroker.net/topic/35308/\" target=\"_blank\">Testen Adapter SmartControl 0.1.1-beta.x</a>.", "However, this link will change and new forum threads will follow, based on the progress of the adapter development." ], "topic_2": "I have an error/bug", "answer_2": [ "No worries :-) This adapter is in an early stage of development and bugs will probably still occur.", "First of all: Check the ioBroker log for any hints and follow them up accordingly.", "If you are not sure if you did everything right in the adapter settings, see above \"I have a question\".<br>", "If you really have a bug caused by this adapter, please go to <strong><a href=\"https://github.com/Mic-M/ioBroker.smartcontrol/issues\" target=\"_blank\">GitHub: Smart Control Issues</a></strong>", "and create a new issue. Please describe the issue in detail and describe exactly and step-by-step what you were doing when/before the bug occurred. Also set the log level of the adapter to \"Debug", "reproduce the error and put the log output in code tags (<code>```</code> insert log here...", "<code>```</code>) in the issue. ioBroker truncates log lines, so please go directly to Logfile (by clicking on \"Download Log\")." ], "topic_3": "I would like to suggest a new feature", "answer_3": "Please open a new Github issue here: <a href=\"https://github.com/Mic-M/ioBroker.smartcontrol/issues\" target=\"_blank\"><strong>GitHub: Smart Control Issues</strong></a>." } } } }Und damit man das auch mal sehen kann: Hier ein kurzes Video
Wie gesagt: Sicher weit weg von perfekt, eher ein Proof of ConceptUnd was die Plattform für Übersetzungen angeht:
Entwickler unter sich halt
Erst die Plattform und dann den Weg dahin entwickelnIch tendiere da eher zu Weblate.
Viele Möglichkeiten, selbst Deepl ist möglich, wenn auch nicht kostensfrei@UncleSam sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Weblate übersetzt - nicht mehr und nicht weniger.
Da muss ich widersprechen: Weblate übersetzt von Haus aus nichts.
Aber ansonsten bin ich deiner Meinung: Weblate ist wohl die beste PlattformCrowdin ist sicher nicht schlechter, kostenfrei, aber eben nicht Opensource.
Man muss nehmen, was man bekommt. Und wer sagt, dass es kostenfrei bleibt?
Wir hatten diese Probleme mit Transifex. War plötzlich auch kostenpflichtig.
Opensource kann man ggf. selbst anpassen. -
Hi @Fenian
Wow, vielen Dank, dass du dich so intensiv damit beschäftigt hast und auch deinen wertvollen "Senf"
Sehr interessant auch deine Erfahrungen hinsichtlich selber Sprache aber unterschiedlicher Regionen, kenne ich so auch und da muss man ziemlich aufpassen. Daher hasse ich eigentlich auch gerade automatische Übersetzungen, die man dann ohne korrekturgelesen zu haben einfach so im Netz publiziert.
Für ioBroker sehe ich das nicht wirklich als Gefahr, aber wie man sieht, kann man sich da auch schnell in einem "Minenfeld" befinden.
Sehe ich auch so.
Das harmloseste was mir dazu einfiel ist "ignorant".
Danke für deine Direktheit
Und ich gebe dir Recht mit "ignorant". Hatte es auch versucht zu erklären. Letztendlich hatte ich einfach die Schnauze voll und keinen Bock mehr, als Freizeit-Entwickler ohne Personal dahinter so viel Zeit wegen Übersetzungen zu verbraten. Dies als Hintergrund zu meiner durchaus emotionalen Reaktion darauf
Im Nachhinein bringt uns das aber auch nicht weiter, und die Primär-Sprache muss natürlich Englisch sein, keine Frage.Auserdem geht doch nicht darum Entwickler zu quälen.
Zwangsweise Übersetzungen ins Chinesische oder sonst was halte ich auch nicht für besonders gut.
Aber bei dir denke ich, wäre Englisch nicht so das Problem.
Zusammen mit Deutsch sind das schon 2 Übersetzungen.
Gutes bzw. schlechtes Timing übrigens von uns beiden, also totale Überschneidung
- ich möchte den smartcontrol-Adapter jetzt nach ziemlichen Umbauarbeiten ins Latest-Repository bringen, aber dazu muss der internationalisiert werden.
Daher hatte ich erst gestern Abend ein neues Konzept implementiert:
https://forum.iobroker.net/post/488807Zusammengefasst:
- Die Felder werden alle wie üblich in allen Adaptern in die ioBroker-Sprachen (de, en, ru, usw.) automatisiert übersetzt - noch nicht umgesetzt, geht dann per gulp, also mit den bestehenden Bord-Mitteln. Englisch/Deutsch dabei sauber korrekturgelesen.
- Die Dokumentation wird ausgelagert in markdown-Dateien, vorgehalten jeweils in Englisch und Deutsch (manuell übersetzt bzw. sauber korrekturgelesen). Dann eingebettet in die Adapter-Konfiguration je nach Sprache (Englisch/Deutsch), wobei Fallback immer Englisch ist (also für alle anderen Sprachen)
Ich habe mir am Wochenende aus Neugier und Langeweile den Spass gemacht und mit ein paar mir bekannten Systemen herumprobiert um den Adapter von @Mic entsprechend anzupassen. (Ist nicht die aktuelle Version des Adapter)
Das Ergebnis ist sicher weit davon entfernt perfekt zu sein aber da steckt auch nur 1 Tag Arbeit drin.Und damit man das auch mal sehen kann: Hier ein kurzes Video
Sehr, sehr cool
Hast du einen Github-Link für die Umsetzung deines Tests?
-
@Mic sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Hi @Fenian
Wow, vielen Dank, dass du dich so intensiv damit beschäftigt hast und auch deinen wertvollen "Senf"
Solange der Senf nicht zu scharf war
Danke für deine Direktheit
Und ich gebe dir Recht mit "ignorant". Hatte es auch versucht zu erklären. Letztendlich hatte ich einfach die Schnauze voll und keinen Bock mehr, als Freizeit-Entwickler ohne Personal dahinter so viel Zeit wegen Übersetzungen zu verbraten. Dies als Hintergrund zu meiner durchaus emotionalen Reaktion darauf
Im Nachhinein bringt uns das aber auch nicht weiter, und die Primär-Sprache muss natürlich Englisch sein, keine Frage.Ich kann dich durchaus verstehen
Der Entwickler sollte die Übersetzung ermöglichen,aber auch nicht mehrGutes bzw. schlechtes Timing übrigens von uns beiden, also totale Überschneidung
- ich möchte den smartcontrol-Adapter jetzt nach ziemlichen Umbauarbeiten ins Latest-Repository bringen, aber dazu muss der internationalisiert werden.Timing? Naja, ich wollte das erst ignorieren, aber es hat mich doch gestört.
Nun hat sich halt die Zeit zum Probieren ergeben.
Daher auch eine ältere Version deines Adapters.
Ich persönlich halte die Vorgaben für das Latest-Repository für übertrieben.
Übersetzbarkeit ja, Zwangsvorgaben bezüglich Sprachen: Nein
Die meisten kommen mit Englisch zurecht, jede weiter Übersetzung ist prima, sollte aber kein muss sein
Verfügbare Sprachen im Backend anzeigen, mit einer Aufforderung (und mit Link auf welches Tool auch immer) sich aktiv als Übersetzer für z.B Chinesisch einzubringen.Sehr, sehr cool
Hast du einen Github-Link für die Umsetzung deines Tests?Bisher nicht. War halt eher mehr nur mich gedacht. Aber Github sollte sich machen lassen.
-
@Fenian Danke für dein wertvolles Feedback!
Wie du eventuell gesehen hast, sind wir aktuell die ersten Tests am fahren: https://forum.iobroker.net/topic/36660
Ich habe mir erlaubt, die Diskussion dort weiter zu fahren (damit sich diese nicht allzu sehr verzettelt).
-
Aus Projektsicht ist es ein schwieriger Spagat einerseits die aktuelle (primär deutsche) User- und Entwickler-Basis zufriedenzustellen, aber gleichzeitig auch ioBroker interessant für Nutzer (und Entwickler) aus anderen Sprachen interessant zu machen.
@Apollon77 hat das weiter oben schon etwas beschrieben.Wir haben vor einiger Zeit in der Community entschieden die Sprachen anzubieten die wir aktuell haben - das jetzt wieder rückgängig zu machen ist denke ich nicht sonderlich sinnvoll. Und es gibt auch immer noch genügend User die Kein oder schlecht Englisch können, weil diese Sprache dort nicht so gebräuchlich ist.
Daher möchte ich gern an der aktuellen Liste der Sprachen festhalten, auch wenn diese im ersten Schritt automatisiert übersetzt werden (müssen) und vom Entwickler nicht geprüft werden können. Das müssen wir dann erst einmal akzeptieren.
"On the fly" Übersetzungsplugins in Browser sind für mich nicht sinnvoll, weil das am Ende wieder andere Probleme machen wird und weitere Voraussetzungen mit sich bringt.Die Idee hier mit Übersetzungstools wie Weblate einen einfachen Weg anzubieten auch für "nicht Entwickler" Korrekturen in Übersetzungen zu liefern ist genau der Schritt der uns bisher noch fehlte. Danke an alle die das getrieben haben. Da laufen gerade erste Tests.
Auch die weiteren Initiativen die aktuell diskutiert werden, z.B. wie man die Admin-Seiten mit mehr Erklärungen versehen kann (per weblate übersetzt natürlich) sind sehr interessant und können ioBroker weiter voran bringen.
Danke an alle die hier so aktiv mitdiskutieren und mitgestalten.
