Meeting für ioBroker Core/Dev/Admin 14.07.20 20:30
-
@ldittmar Das ist klar, aber dein Stichpunkt klingt so als würden beim Bearbeiten der originalen Sprache sämtliche manuellen Änderungen an der übersetzten Seite überschrieben. Das kann ja nicht zielführend sein, daher frage ich.
-
@AlCalzone Achso... Es ist so, dass wenn eine automatisch übersetzte Dokumentation überarbeitet wird, diese nicht mehr automatisch übersetzt wird. Es gibt dann halt die Gefahr, dass die Texte auseinander driften. (So habe ich es verstanden... es war auch schon ziemlich spät
) -
@ldittmar @AlCalzone richtig seiten die Manuell bearbeitet werden, werden nicht mir Automatisch übersetzt, dazu muss aber der Kopf mit dem Hinweis auf Automatische übersetzung entfernt werden.
-
@ldittmar
Würde mich wieder eine Zusammenfassung des Gesprächs freuen um zu wissen was uns als User so erwartet. Ist das möglich? -
@ldittmar said in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Bitte keine Daten in Channel, Device oder Folder Ebene angeben und States dürfen keine weitere States haben
Was ist mit "Daten" gemeint? Daten im Native-Teil der Channel / Device / Folder Objekte? Oder da States haben? Also wäre eine Struktur
- Device
- Channel
- State
- State
- Channel
nicht erwünscht oder geht das?
- Device
-
Nicht erlaubt:
- Objekt mit Typ Device, passend dazu ein State der gleichen ID
- Objekt mit Typ Folder, passend dazu ein State der gleichen ID
- Objekt mit Typ Channel, passend dazu ein State der gleichen ID
- Objektstrukturen "adapter.0.state.state.state", wobei "adapter.0.state", "adapter.0.state.state" und "adapter.0.state.state.state" alles States sind.
-
@e-s Die Zusammenfassung findest Du im ersten Beitrag dieses Threads. Also einfach mal nach ganz oben scrollen.
-
@AlCalzone Besteht die Möglichkeit solche Konstellationen zukünftig zu verhindern? Meiner Meinung nach sollten Dinge, die nicht erlaubt sind, auch nicht möglich sein. Woher soll der gemeine User (nicht Entwickler) das nämlich alles wissen, zumal es aus seiner Sicht ja Sinn machen könnte eine solche Struktur zu implementieren.
-
@braindead Ich könnte mir da einen "strict mode" für die objects/states DB" vorstellen in der wir ganz hart checken ... nix für Live systeme weil wird definitiv auf die Performance gehen ... Alternativ ein "checker script" was man auf die Daten einer Instanz loslassen kann und was dann sagt was alles falsch ist (vllt die bessere Idee)
-
@apollon77 Das "checker script" ist gut, damit User diese Probleme identifizieren können. Die bessere Lösung ist es aber nicht, weil es abhängig von den Usern ist.
"strict mode" halte ich für den falschen Ansatz/Begriff, weil entweder etwas ist verboten, weil es Probleme macht oder es sollte erlaubt sein. Warum sollte etwas verboten sein und im "nicht strict mode" trotzdem möglich sein?
Trotzdem könnte man zwei Dinge unterscheiden:
-
"adapter.0.state.state.state" muss beim Erzeugen von States verhindert werden. Das passiert in der Regel nicht andauernd und hier ist Performance nicht sooo wichtig.
-
Der "strict mode" geht auf die Performance, weil er bei jedem setzen eines States überprüfen muss, ob der zu setzende State ein State ist?
Aber wahrscheinlich habe ich einfach nicht verstanden, wo das tatsächliche Problem mit einer solchen Struktur ist bzw. warum nur ein State einen Wert haben darf.
-
-
@braindead sagte:
warum nur ein State einen Wert haben darf.
Das ist die Definition eines ioBroker-Datenpunktes.
-
@apollon77 sagte:
Alternativ ein "checker script"
Besser die Hauptquellen der Erzeugung von Datenpunkten durch den User um die Prüfung erweitern:
- createState(id) im Javascript-Adapter
- adminObjects.js im Admin-Adapter
Den js-controller als ioBroker kernel sollte man nicht zu sehr "aufblasen".
-
@paul53 Ehrlich: Es geht als erste Prio darum das Adapter keine busslshit dürfen ... Der JS ADapter ist da ne Sonderlocke den man ggf mit abfängt.
Aber bei den ganzen Aktionen immer "die Objekte drum herum" zu prüfen kostet einfach sehr viel Performance und das will auch keiner. Wir haben aktuell einen gewissen Datendurchsatz und der soll auch nicht weniger werden, sonst wird es wieder langsamer - vor allem dann auf schwächeren Systemen. Es muss also eine Balance gefunden werden.
Ein Skript mit denen die Entwickler (!!) (nur im Notfall die User) Ihre Adapter prüfen können und damit die Verantwortung übernehmen es korrekt zu liefern ist es. Und ja dann müsste man in den JS Adapter relevante checks einbauen
-
Bzgl. Doku:
Könnte man da nicht einen Mittelweg gehen aus @Mic Ansatz SmartControl-Adapter und github Doku? Also soviel wie möglich Hilfe in den jeweiligen Adapter in die Config Seite selbst legen (anstatt in der readme.md auf github), da dadurch das Öffnen der Hilfe auf einer externen Seite entfällt. Die Pflege der Hilfe aber trotzdem auf github belassen?
Das könnte bspw durch spezielle Tags in der readme.md erreicht werden, die der jeweilige Adapter in der Config referenziert und sich entsprechend verlinkt. Das hätte den Charme, dass beides vollständig ist und immer funktioniert. Hoffe ist verständlich was ich meine. -
@BoehserWolf sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Bzgl. Doku:
Könnte man da nicht einen Mittelweg gehen aus @Mic Ansatz SmartControl-Adapter und github Doku?Hi, ich konnte leider nicht bei dem Meeting teilnehmen, aber weil mich @BoehserWolf hier zur Doku zitiert
:
Coole Idee!
Doku und Übersetzungen sind für mich beim frischen SmartControl-Adapter und natürlich auch bei meinen anderen beiden Adaptern ein großes Thema. Übersetzung ist aus Adapter-Entwickler-Sicht trotz Gulp extrem zeitaufwändig, und wir entwickeln doch ja alle privat, ohne Einnahmen, dafür, usw. Dafür ist mir meine Zeit echt zu schade, um mich auch noch um Übersetzungen zu kümmern, mein "Job" ist es, zu entwickeln, neue Features der User einzubauen, und Bugs zu fixen! Da habe ich einfach keine Zeit mehr für den Übersetzungskram.Daher habe ich in SmartControl:
admin/index_m.htmlTexte vor ein paar Tagen auf Deutsch umgestellt und die komplette Adapter-Doku dort in der Konfig integriert, siehe gif. Aus Usability-Gründen ist dadurch die Info direkt für den Anwender verfügbar und es findet kein aufwändiger Medienbruch statt. Dies hat mich persönlich bislang immer ziemlich genervt, nicht gleich in Adapter-Konfig die Optionen erklärt zu bekommen, sondern man muss da immer ziemlich rum suchen, bis man hoffentlich weiterführende Erklärungen zu Adapter-Optionen findet. Aus Anwendersicht ziemlich uncool und zeitaufwändig...
Aus Entwicklersicht auch viel agiler und schneller: Neue Option oder was geändert in deradmin/index_m.html-> man passt sofort die Doku ein paar Zeilen drüber an. Dem User ist damit auch deutlich schneller geholfen.- In den Optionen prägnanten Link gesetzt:
Please click here führt zu https://github.com/Mic-M/ioBroker.smartcontrol/blob/master/docs/translations.md
Da stelle ich das Thema auch klar, und auch dass ich null Zeit noch übrig habe, mich um dem aufwändigen Übersetzungskram zu widmen. 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 war damals noch überhaupt nicht der Fall und die Übersetzungen waren teils mega schlecht. 2020er Beispiel: https://www.deepl.com/translator - die Übersetzungen sind wahnsinnig gut! Sachen wie "0_userdata.0.status.xyz" werden natürlich immer auch noch übersetzt, unschön, aber das könnte man sich noch näher ansehen, wie man das ausschließen kann. Als Beispiel: im Bereich SEO sind ja auch Tags für HTML-Websites implementiert für Suchmaschinen, um Teile der Website von der Indexierung auszuschließen. Warum soll das nicht hier auch gehen, um Satz-Teile von der Übersetzung auszuschließen?
Alles in allem aus meiner Sicht die Zukunft, die Übersetzungs-Pflicht an den Client zu übertragen, und nicht mehr vom "Server" managen zu lassen. Grad bei Open Source Projekten, die sich nicht eine Mannschaft für Übersetzungskram leisten können...Letztendlich:
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? Mir fällt da auch auf Github auf, dass man sich da gegenseitig einen abbricht, um sich in Englisch auszutauschen, obwohl die Muttersprache deutsch ist. Hab deswegen auch diesen Hinweis im SmartControl Adapter:
Mein Wunsch wäre außerdem noch eine einfache Möglichkeit für Adapter-Entwickler, mehrsprachige Log-Ausgaben zu bieten.
Danke, und ich hoffe meine Kritik kommt nicht zu heftig und wirklich konstruktiv als reiner Verbesserungsvorschlag an
-
@Mic sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
ioBroker ist zum allergrößten Teil einfach Deutsch.
91,81 %
Das sagt Alles. -
Hm ... @Mic muss ehrlich sagen das ich das einerseits verstehen kann, andererseits seehr shwierig finde.
Projektseitig haben wir die weiteren Sprachen (Sehr lange gab es deutsch,englisch und Russisch) nach Absprache mit (einer damals noch etwas kleineren) Entwicklergruppe und auch User-Gruppe eingeführt um genau ioBroker aus dem "nur Deutschland" rauszubringen und auch um besser andere Smart-Home Systeme angreifen zu können! Chinesisch kam dazu als es dort losging und sich eine eigene Community gebildet hat. So ein switch dauert aber Zeit! Und fehlende Übersetzungen schrecken dann neue User aus anderen Sprachregionen ganz einfach ab! Das ist die andere Seite der Medallie
Es gibt Tools um die Übersetzungen für die Entwickler zu erleichtern bzw zu automatisieren. @ldittmar hat gulp Skripte dazu gebaut die integriert sein sollten, es gibt https://translator.iobroker.in/ für manuellere Übersetzungen.
Die Realität ist das ein User das was Du beschreibst ggf nicht akzeptiert sondern einfach den Adapter nicht nutzt ...oder Ihn fluchend nutzt weil er anders tickt als die 352 anderen AdapterWas das Thema "usebility" und "Admin UIs besser machen" mit den Übersetzungen zu tun hat weiss ich nicht nicht, aber ja wenn es darum geht texte nicht auslagern zu müssen ... naja
Ich hatte auch vor einiger Zeit mal mit Optionen überlegt (Fragezeichen Icons mit mouse-over Erklärungen der Einstellungen), aber am Ende bin ich kein Web-Designer ... Womit wir am Ende wieder beim Adapter-Konfiguration Styleguide und so wärenGitHub ist in meinen Augen sprachlich ob Deutsch oder Englisch fast egal ... ich zwinge keinen dort englisch zu sprechen
Mehrsprachige Log Ausgaben finde ich persönlich wiederum überflüssig und sogar komplett nicht hilfreich - vor allem wenn die Logs zur Fehlersuche genutzt werden durch MICH dem Entwickler dann muss ich danach suchen können im Code ... und ich muss damit die Logik verstehen können. Mehrsprachigkeit hier hilft MIR nicht ... und da behaupte ich jetzt das 90% der User keine Logs lesen und daher
Fakt ist auch - und das macht die Thematik sehr grenzwertig - das der Adapter Checker im Repo die Übersetzungen prüft und mal mindestens neue Adapter die nicht wenigstens teilweise die Hauptsprachen unterstützen in jedem Fall nach den aktuellen Regeln nicht ins Repo kommen. Das würde auch auf Deinen Adapter zutreffen.
Bestandsadapter geniessen aktuell noch irgendwie so eine Art Vogelfreien Status, aber auch diese prüfen wir bei stable updates mit dem Repo-Checker ...
Du schaffst hier gerade einen Präzedenzfall ... und ich hätte es besser gefunden wenn Du solche Entscheidungen vorher vllt mal angesprochen hättest. Versteh mich bitte nicht falsch und ich will Dir garantiert keine Stöcke zwischen die Füsse werfen oder gar das du jetzt angepisst keine Adapter mehr baust ... aber irgendwie ist es halt ein miteinander und eine Balance ...
Ingo
-
@apollon77
Hi Ingo,Zunächst: Ich bin absolut dafür, dass wir Internationalisierung brauchen. Ich zitiere mich mal selbst vom August 2018:
Mich persönlich nervt noch, dass ioBroker viel zu wenig bekannt im englischsprachigen Raum ist, obwohl die Community alles dafür macht (englische Hilfe, englischsprachiges Forum, GitHub so weit es geht in Englisch, etc.). Bin mir da noch nicht sicher, wie wir das weiter unterstützen können…. :roll: Aber auch das wird noch kommen. Ein Blog hilft hier schon mal sehr um in den Fokus zu kommen, und ich bin gerne auch mal bei englischsprachigen Artikeln behilflich, falls das angedacht ist.
Hier mal ein einfaches Beispiel, was ich meine:
Ich füge eine neue Tabellenspalte in den Optionen in der
index_m.htmlein.<th style="width: 120px" class="header translate" data-name="offValue">'off' value</th>Diese neue Option beschreibe ich in der
index_m.htmlentsprechend:<td> State value, which is set in 'state for switching device off'. You can use <code>true</code>, <code>false</code>, numbers like <code>144</code>, or strings like <code>Turn Radio on</code>. Note: Any white spaces or quotation marks (like <code>"</code>) at the beginning or end will be disregarded. </td>Das dauert wohl so 2-3 Minuten als Entwickler.
Nun wäre ich eigentlich schon fertig.
Schritte die ich als Entwickler nun manuell durchführen muss:
admin/i18n/en/translations.json: Übersetzung für "'off' value" hinzufügen.- Das HTML in
index_m.htmlfür "State value, which is set ..." umformatieren, so dass es mir z.B.trueoderfalsenicht übersetzt, die zusätzlichen HTML-Tags "code" usw. beibehält, etc. Sehr mühsam und zeitaufwändig. Und passt auch nicht von der Reihenfolge her für die einzelnen Sprachen (Satzbau, Grammatik, Zeichensetzung, etc.):
<td> <span class="translate">State value, which is set in 'state for switching device off'. You can use </span><code>true</code>, <code>false</code>, <span class="translate">numbers like </span><code>144</code><span class="translate">, or strings like </span><code><span class="translate">Turn Radio on</span></code>. <span class="translate">Note: Any white spaces or quotation marks (like </span><code>"</code>)<span class="translate"> at the beginning or end will be disregarded.</span> </td>(hab das hier reingetippt jetzt, sicherlich noch Fehler im HTML, die ich jetzt noch debuggen müsste, prüfen wie es aussieht im Admin, ...)
admin/i18n/en/translations.json: Alle nun neuen Übersetzungen derindex_m.htmlwieder hier mühsam manuell per Copy & Paste einfügen- Gulp Übersetzung ausführen. Ggf. muss ich nach erfolglosem Google Translate (zu viel in kurzer Zeit übersetzt ) auf Yandex aufweichen (mit schlechterer Übersetzungsqualität und mehr Arbeit im Nachgang für mich)
- Deutsche Übersetzung korrigieren, weil oft schlecht übersetzt und manche Begriffe wie z.B. "State" irreführend für den Anwender übersetzt werden. Dabei muss ich mühsam die Quelle ansehen und vergleichen, auch weil Satzteile übersetzt wurden die so nicht zusammen passen, einzeln zusammen suchen, usw.
- Ggf. zurückgehen zu Punkt 2 (
index_m.html) und diese noch mal korrigieren und 3-5 erneut durchlaufen.
Der zusätzliche Aufwand für dieses Beispiel geschätzt: 30 Minuten. Das steht für mich in keinem Verhältnis zu den ursprünglich 2-3 Minuten.
Wenn man sich etwas umschaut, dann liest man z.B. Folgendes auf github.com/thomas-darling/gulp-translate:
In a traditional localization workflow, localizable content is assigned unique ids and stored in a separate file. Templates that need the content can then import it by referencing its id. While this approach can work in some apps, it has significant drawbacks that often make it annoying, inefficient and error prone in larger apps.
Scheint aber immer noch eher aufwändig, habe es mir noch nicht näher angesehen. Unique Ids ist jedenfalls wirklich nicht Entwickler-freundlich wie hier beschrieben:
In many solutions, all strings that need to be translated are stored in a separate string-file, and the templates then reference those strings by id, often using client-side data binding. While this approach does work, it has significant drawbacks that make it annoying, inefficient and error prone in larger apps.
@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Mehrsprachige Log Ausgaben finde ich persönlich wiederum überflüssig und sogar komplett nicht hilfreich - vor allem wenn die Logs zur Fehlersuche genutzt werden durch MICH dem Entwickler dann muss ich danach suchen können im Code ... und ich muss damit die Logik verstehen können. Mehrsprachigkeit hier hilft MIR nicht ... und da behaupte ich jetzt das 90% der User keine Logs lesen und daher
Sehr guter Punkt wegen Fehlersuche, du hast absolut recht, und da geht's mir genau so
Ich dachte da auch hauptsächlich an den Endanwender wegen Info-Log-Ausgaben. Aber das lässt sich wohl auch alternativ gut bzw. besser über Adapter-Konfig lösen, in der dann der User die Ino-Log-Texte für die einzelnen Szenarien selbst hinterlegen kann.@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Fakt ist auch - und das macht die Thematik sehr grenzwertig - das der Adapter Checker im Repo die Übersetzungen prüft und mal mindestens neue Adapter die nicht wenigstens teilweise die Hauptsprachen unterstützen in jedem Fall nach den aktuellen Regeln nicht ins Repo kommen. Das würde auch auf Deinen Adapter zutreffen.
Aktuell besteht der https://adapter-check.iobroker.in/ meine "Übersetzungen" von https://github.com/Mic-M/ioBroker.smartcontrol tatsächlich wunderbar
Die index_m.htmlwird wohl nicht näher gecheckt wird aufclass:translateversus vorhandener Ids inwords.jsund evtueller Diskrepanzen. Aber ich weiß, was du meinst, der Adapter entspricht so sicherlich nicht dem gewünschten "Standard". Ich bin sehr gerne regelkonform, die Gründe für die Abweichung beschreibe ich auch hier@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Du schaffst hier gerade einen Präzedenzfall ... und ich hätte es besser gefunden wenn Du solche Entscheidungen vorher vllt mal angesprochen hättest.
Ich bin absolut deiner Meinung, dass mein alternatives Vorgehen eine Abstimmung erfordert und das ganze ein Miteinander ist. Sorry für das vorpreschen. Aber für meine Alpha/Beta-Version des Adapters muss(te) ich jedoch priorisieren und zügig eine Entscheidung treffen, denn sonst würde sich das wohl wochen- bzw. monatelang ziehen und ich müsste zwischenzeitlich nach dem alten, gewohnten Schema vorgehen, wofür ich einfach keine Zeit habe (siehe oben das kleine Beispiel) und den Adapter damit komplett einstampfen mangels Zeit. Hab da auch einfach keine Lust zu, sorry.
Ich bin daher auch schmerzfrei, wenn der Adapter dadurch nicht ins Latest kommt, weil ich einfach nicht die Zeit für diese Zusatztätigkeiten habe und keine Lust auf eine Sehnenscheidenentzündung wegen dem vielen manuellen Copy/Paste etc.
Mein Ziel ist es, dem Anwender einen möglichst einfach zu konfigurierenden Adapter zu bieten, das muss ich als "Adapter-Schöpfer" einfach bieten. Da Smart Control komplex (im Vergleich zu einigen andern Adaptern) in den Einstellungen ist, ist es aus meiner Sicht aus User Acceptence Gründen umso wichtiger, dass Erklärungen zu den Optionen intuitiv und direkt ohne Medienbruch verfügbar sind. Kann doch nicht sein, dass in der Konfig gefühlt nur "Hieroglyphen" sind und man nicht weiter kommt. Da verliert man schnell die Lust als Anwender, und da spreche ich selbst aus Erfahrung, deswegen will ich das unbedingt selbst besser machen.@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:
Versteh mich bitte nicht falsch und ich will Dir garantiert keine Stöcke zwischen die Füsse werfen oder gar das du jetzt angepisst keine Adapter mehr baust ... aber irgendwie ist es halt ein miteinander und eine Balance ...
Keine Sorge, ich werfe nicht hin
Vielen Dank für deine konstruktive Antwort und Kritik. Ich bin absolut deiner Meinung, dass das ganze ein Miteinander und eine Balance ist und kann all deine Punkte sehr gut nachvollziehen.
Ich hoffe, ich konnte oben meine Beweggründe verständlicher darlegen.Zusammengefasst ist mein Haupt-Beweggrund: in begrenzter Zeit möglichst viel dem ioBroker-Anwender als Entwickler zu bieten, und Manuelles in der Entwicklung so weit es geht zu vermeiden. Im Quellcode verwendet man ja auch Klassen, Funktionen und Eigenschaften, in Verbindung mit Schleifen etc., um wiederkehrendes zu kapseln und den Code nur einmalig schreiben zu müssen. Analog dazu sollte das auch bei den Übersetzungen sein um uns als Entwicklern möglichst manuelle Arbeit zu vermeiden bei der Entwicklung und Pflege des Adapters...
-
Test. HTML scheint defekt im letzten Beitrag von mir
-
ja irgendwie hats das jetzt zerballert
Ich verstehe auch Deine Argumente und sind natürlich auch immer ein nerviges Thema als Entwickler, wie ich nur zu gut selbst kenne :-).
Das der Ansatz mit dem "eindeutigen IDs für lokalisierbare Inhalte" nicht perfekt ist ist denke überall bekannt ... aber eine echte Alternative gibts irgendwie auch nichtWäre damit nicht eine Idee ein "gulp" Dingens oder ein Skript zu schreiben was es erlaubt bestimmt "geschriebenes html" zu parsen und anzupassen?
Also sowas wie ein tag "translate" was als property die text-ID oder sowas hat und ggf. eine Notation "nicht zu übersetzende teile" zu markieren die dann auch behandelt werden. Dann kann man das initial einfach so schreiben und am Ende lässt man das Skript drüber rennen was diese Art von Sonder-Tags nimmt, in die transpation files einfügt und so ... Das text Polishing (De/en) ist denke immer mit dabei ... da kommt man nicht drum rum fürchte ich.Lasst uns doch mal Kreativ werden wie wir dieses nervige Problem so angehen können mit dem was wir können ... Coden
Vllt kriegen wir die 30 mins so auf 10 "am Ende einer Änderung" runter
Ingo
