Meeting für ioBroker Core/Dev/Admin 14.07.20 20:30

[carsten04]

@ldittmar Wird der Link denn hier im Threads bekanntgegeben, oder wo find ich den?

[arteck]

@carsten04 das ist streng geheim

[Dutchman]

Meeting details fuer heute Abend !

Da Cisco leider die “unlimited” action beendet hat und die maximale Dauer eines meetings nur noch 50min ist stelle ich euch aus der Arbeit Microsoft Teams zur verfuegung.

Wer microsoft Teams hat kan diese benutzen, alle anderen bitte teilnehmen über chrome webbrowser damit sind alle functionalitaeten verfügbar.
Man kan sich auch per Telefon Einwahlen, hier sind leider wohl kosten dran verbunden

Da es ein Geschäfts account ist, muss ich alle Gäste Manuel freischalten. Solltet ihr in der lobby hangen bleiben bitte kurz per telegram anpingen !

Meeting Link :
https://teams.microsoft.com/dl/launcher/launcher.html?url=%2F_%23%2Fl%2Fmeetup-join%2F19%3Ameeting_Yjk4ZDgzYjktZTdlMS00MDk1LWIyODgtMTMwNGQzYmY3ZWE0%40thread.v2%2F0%3Fcontext%3D%7b%22Tid%22%3a%22587b6ea1-3db9-4fe1-a9d7-85d4c64ce5cc%22%2c%22Oid%22%3a%229a1cbbd0-95f5-4561-b060-627385272da6%22%7d%26anon%3Dtrue&type=meetup-join&deeplinkId=e2a02d01-7a15-4615-8ecc-589889d542b3&directDl=true&msLaunch=true&enableMobilePage=true&suppressPrompt=true

Dial in :
+49 69 710414584
Meeting-id: 376 122 678#

—

Bis heute Abend freunde !

[AlCalzone]

@ldittmar sagte in Online Meeting für ioBroker Core/Dev/Admin 14.07.2020 20:30:

Doku Texte werden automatisch übersetzt aber nicht zurück übersetzt, also nur originale Anpassen

War gestern nicht mehr dabei als das besprochen wurde - ist das sinnvoll? Auto-Translate spuckt ja manchmal ganz schönen Unsinn aus, den man ab und an per Hand korrigieren müsste.

[ldittmar]

@AlCalzone Damit sind solche Seiten gemeint... https://www.iobroker.net/#en/documentation/logic/examples.md , aber klar wird das nie und nimmer richtig sein, aber wir haben nunmal nicht die Kapazitäten um das auch noch zu machen.

[AlCalzone]

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

[ldittmar]

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

[Jey Cee]

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

[e-s]

@ldittmar
Würde mich wieder eine Zusammenfassung des Gesprächs freuen um zu wissen was uns als User so erwartet. Ist das möglich?

[Garfonso]

@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

nicht erwünscht oder geht das?

[AlCalzone]

@Garfonso

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.

[braindead]

@e-s Die Zusammenfassung findest Du im ersten Beitrag dieses Threads. Also einfach mal nach ganz oben scrollen.

[braindead]

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

[apollon77]

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

[braindead]

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

1. "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.

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

[paul53]

@braindead sagte:

warum nur ein State einen Wert haben darf.

Das ist die Definition eines ioBroker-Datenpunktes.

[paul53]

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

[apollon77]

@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

[BoehserWolf]

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.

[Mic]

@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.html Texte 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 der admin/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