Autor Thema: [geklärt] Eventhandler und Timehandler - "allgemein", "speziell" u.a.  (Gelesen 984 mal)

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #15 am: 03 August 2018, 10:47:10 »
Und wenn ihr schon mit der "Dokumentationsstruktur" rumargumentiert: das hat auch nur "jemand" mal geschrieben, weil es nirgends dokumentiert war, aber als notwendig erachtet wurde, verbunden mit dem Versuch, die bereits vorhandenen Infos einigermaßen sinnvoll mit einzubinden.

Da mag es durchaus Verbesserungspotential geben, zumal auch dort im wesentlichen "nur" der Ist-Zustand wiedergegeben war/ist - einschließlich der Nachlässigkeiten einiger weniger Modulautoren beim Thema englische commandref. Das jetzt als "Entschuldigung" dafür zu nehmen, dass es ja von den Projektverantwortlichen (zu denen ich als "Urautor" des bezogenen Artikels nicht gehöre) alles nicht so erst gemeint war, ist fast schon nicht mehr lustig >:( .

Klar ist jedenfalls, dass "Wunschsprache" was anderes ist als die "Pflichtsprache" (Englisch).

(Muß mir das mal ansehen, es gab und gibt _zwei_ Vorgaben: Englische Commandref + 3 Monate Support im Forum)
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #16 am: 03 August 2018, 14:47:19 »
Das Modul wird in der bestehenden Form nicht abgewiesen, daraus schliesse ich, dass alle zwingenden Vorgaben ausreichend erfüllt sind.

Alle weitergehenden, hier vorgetragenen Forderungen und Bedenken sind persönlicher Natur und daher irrelevant hinsichtlich der Entscheidung, ob Wikibeiträge erscheinen dürfen oder nicht. Alles andere ist Zensur.

Gefällt mir Gefällt mir x 1 Liste anzeigen

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #17 am: 03 August 2018, 15:04:53 »
Ziemlich digitale Denke, oder nicht? Dazu noch sehr formalistisch.
Das Modul wird in der bestehenden Form nicht abgewiesen, daraus schliesse ich, dass alle zwingenden Vorgaben ausreichend erfüllt sind.
_Das_ wäre Zensur, oder etwa nicht? (Also das Zurückweisen eines Moduls wegen einer als schlecht empfundenen englischen commandref).

Übrigens wäre mir nicht bekannt, dass es jemanden gäbe, der eine qualitative Beurteilung vornehmen würde, ob die commandref oder das Modul an sich irgendwelchen Vorgaben entspricht. Es gab nach meiner Erinnerung, die aber nicht in der Bronzezeit anfängt, auch nur einen oder zwei Fälle, in denen Nachbesserung verlangt wurde; da hatte der jeweilige Autor gemeint, eine Kopie der deutschen Commandref mit Englischen =pod würde den Anforderungen auch genügen (oder ein Link auf die deutsche CR, irgend so eine offensichtliche Mogelei halt) .
Das ist hoffentlich nicht das Niveau der Diskussion, die wir gemeinschaftlich anstreben sollten. Aber die Commandref zu DOIF+Tools geht im Englischen auf 2-3 A4-Blätter, im Deutschen ist sie gefühlt genauso umfangreich wie die commandref im Übrigen.
Da stimmt doch was grundlegend nicht, oder?

Nicht mal das berühmte "?" ist erläutert...

Zitat
Alle weitergehenden, hier vorgetragenen Forderungen und Bedenken sind persönlicher Natur und daher irrelevant hinsichtlich der Entscheidung, ob Wikibeiträge erscheinen dürfen oder nicht. Alles andere ist Zensur.
Wieder sehr digital, und nach meinem _Empfinden_ insbesondere auch nicht den umfangreichen und sachlichen Stellungnahmen von krikan angemessen (der im Übrigen auch andere Leute schubst, wenn was nicht korrekt ist)...
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #18 am: 03 August 2018, 18:28:52 »
Ja, "das Zurückweisen eines Moduls wegen einer als schlecht empfundenen englischen commandref" wäre Zensur, daher wird es nicht gemacht.

Wo der Modulautor seinen Schwerpunkt setzt, bleibt ihm überlassen und das ist auch gut so.

Ich habe für DOIFtools in der deutschen Befehlsreferenz englischsprachige Beispiele, angegeben, die sehe ich für einen englischlesenden Benutzer als ausreichend an.

In DOIF sieht es ähnlich aus, aber da bin ich der falsche Addressat.

Das Fragezeichen ist übrigens erklärt, es gibt sogar einen Eintrag im Inhaltsverzeichnis https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger und eine Erwähnung in der Kurzreferenz unter "Trigger verhindern"

Bei einer potentiellen Leserschaft von 0,4% müssen sich die Leser anstrengen, wenn der Anteil der nicht deutschsprechenden englischsprachigen Nutzer einen ernstzunehmenden Anteil darstellt, wird ein Modulautor den Schwerpunkt verschieben müssen, wenn die Akzeptanz des Moduls weiterhin gewährleistet sein soll.
Der Schwerpunkt ist eine Abwägung von Aufwand und Nutzen.

13 Jahre englischsprachige Befehlsreferenz haben zu keiner nennenswerten Verbreitung über den deutschsprachigen Raum hinaus geführt.
4 Jahre deutschsprachiger Schwerpunkt in der DOIF-Befehlsreferenz führt dazu, dass in mehr als 50% der FHEM-Installationen DOIF verwendet wird. Und das, obwohl DOIF in den allgemeinen Einsteigerdokumenten nicht oder unangemessen untergeordnet Erwähnung findet.

Ich habe den englischen Quickstart eigentlich nur der Vollständigkeit halber angepasst, bei 0,4% potentieller Leserschaft ärgere ich mich schon fast des Aufwandes wegen.
Von mir aus können die, nach krikans Meinung störenden Verweise, nicht die Texte aus dem englischsprachigen Quickstart entfernt werden, ich hänge nicht daran.

Mein theoretischer Leser wird durch die Eigenschaftenliste neugierig und übersetzt sich die deutschsprachige Befehlsreferenz und stellt sie ins Wiki, er ist allerdings Chinese  ;)


Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #19 am: 03 August 2018, 19:11:45 »
Und wenn es 0,0001% wären, die gerne eine vernünftige englische commandref hätten: DAS ist die (fast einzige) verpflichtende Vorgabe... Darüber zu diskutieren ist hier nicht der richtige Ort, diese Frage ist m.E. eindeutig geklärt.

Und wenn "alles da" ist, ist es auch ein leichtes, das mit ein paar netten englichen Sätzen drumrum zu garnieren für eine zulässige Commandref. Jedenfalls macht die ständige Wiederholung, dass es ja eine deutsche commandref gibt (in der das "?" natürlich ausgiebigst erläutert ist), macht den Hinweis nicht falsch, dass die Vorgabe NICHT EINGEHALTEN ist.
Aber wie gesagt: Diese Diskussion ist mindestens unter deinem intellektuellen Niveau.

Vielleicht findet sich ja jemand, der das Problem lösen möchte (gerne dein fiktiver Leser mit chinesischen Sprachkenntnissen).... Das wäre eine Chance, auch die Doku ggf. zu straffen, damit 100% der FHEM-User (oder zumindest 100%-1 Person) glückliche DOIF-User werden können und verstehen, was sie da eigentlich tun...
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #20 am: 03 August 2018, 21:58:29 »
Wir hatten unser Thema bereits geklärt.

Das Thema Befehlsreferenz ist OFF-TOPIC, aber es füllt das Sommerloch, insofern muss ich richtig stellen:

Ein offizielles Modul erfüllt alle notwendigen Vorgaben, sonst wäre es kein offizielles Modul geworden.

Daher ist die Aussage falsch "dass die Vorgabe NICHT EINGEHALTEN ist".

Aber nicht jeder ist bereit der Argumentation zu folgen - weil sie keinen Spielraum bietet.