Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!

Begonnen von krikan, 06 Juni 2017, 12:05:45

Vorheriges Thema - Nächstes Thema

krikan

Hallo!

Hat jemand Zeit und Lust mich bei der Übernahme und Aktualisierung von https://fhem.de/HOWTO_DE.html bzw. https://fhem.de/HOWTO.html in unser Wiki zu unterstützen?
Insbesondere (aber nicht nur) bei der Aktualisierung des Abschnitts https://fhem.de/HOWTO.html#security könnte ich Hilfe gebrauchen (siehe auch https://forum.fhem.de/index.php/topic,72629.0/all.html).

Gruß, Christian

aruttkamp

ICh würde mich grundsätzlich gerne beteiligen , zumal ich auf der ein oder anderen Seite ein Beispiel vermisse ;-)

Otto123

Hallo Christian,

ich bin auch bereit. Ich verstehe noch nicht genau was zu tun ist, aber wenn ich helfen kann.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

krikan

ZitatIch verstehe noch nicht genau was zu tun ist, aber wenn ich helfen kann.
Hallo Otto, aruttkamp und @all!

Die Seiten https://fhem.de/HOWTO_DE.html und https://fhem.de/HOWTO.html sollen von fhem.de ins Wiki verlagert werden. fhem.de soll anschließend nur noch auf die entsprechenden Wiki-Seiten verlinken.
Ziel ist im Endeffekt fhem.de als Landing-Page mit Verlinkungen ins Wiki zu nutzen. Bei HOWTO_Windows und anderen fhem.de Unterseiten habe ich damit schon angefangen bzw. bin durch.

Mit den beiden hier angesprochenen Seiten habe ich noch nicht begonnen, da sich meine FHEM-Prios momentan ein wenig verschoben haben und die Seiten umfangreicherer Überarbeitung bedürfen.

Wer mag, kann gerne mit eigenen Ideen loslegen.  :)

Btw. Für die Übersetzung von Erste Schritte in FHEM ins Englische https://wiki.fhem.de/wiki/First_steps_in_FHEM brauchen wir auch noch dringend Hilfe.

Gruß, Christian

Beta-User

Da das Thema nach wie vor aktuell ist, und sich anscheinend niemand so recht berufen fühlt, mal meine Gedanken zum Thema.

"An sich" war ich grade dabei, mir das HOWTO_DE mal anzusehen, ob und wie man das überarbeiten kann. Zu einem richtigen Ergebnis bin ich nicht gekommen, will aber mal folgende Punkte und Anknüpfungspunkte an bestehende Elemente der Doku zur Diskussion stellen:

1. Das "Erste Schritte" im Wiki ist ziemlich gut und greift ganz viele Teile aus dem Howto auf, nicht enthalten sind folgende Themen:

a) USB-Devices (automatische Erkennung, die man m.E. nach dem ersten erfolgreichen Durchlauf abschalten sollte).
b) autocreate von "echten" physischen Devices, wenn diese über ein definiertes IO reinkommen
c) Loggen, plotten, structure und Watchdog
d) Sicherheit
e) FHEMWEB

2. Gar nicht (im Howto) enthalten sind Hinweise auf die Bedeutung von perl, regex &Co.. Da würde sich m.E. ein Link auf die entsprechenden Abschnitte in der commandref und http://regex101.com/ anbieten, zur Frage wo s.u..

3. In den "Ersten Schritten" etwas "kurz" kommt m.E. der Hinweis, dass die Geräte des Typs "dummy" hier vorrangig deswegen verwendet werden, weil man ja gerade keine Hardware hat. Für echte Hardware ist an der Stelle ein deutlicher Hinweis (Kasten?) zu empfehlen, die entsprechenden Attribute direkt bei den Hardware-Devices zu setzen, wobei ich da gleich auf die Option hinweisen würde, weitere Attribute mit "userattr" zu definieren, in denen dann benutzerdefinierte Angaben gespeichert werden können. M.E. ist der vorrangige Zweck von "Dummy" in einem "echten" FHEM, allgemeine, nicht auf einzelne Geräte bezogene Informationen zu speichern (das mag aber darin begründet liegen, dass ich kein anderes Frontend nutze).

4. Outdates im Howto:
a) Da ist ziemlich viel von Fritzbox die Rede - m.E. ist das mittlerweile überholt und kann/sollte raus.
b) FS20 ist auch nicht mehr taufrisch => auf die Darstellung eines konkreten HW-Systems ganz verzichten?

5. Vorschlag für eine neue Struktur bzw. Änderungen:
a) Howto: nur noch eine erste Anlaufstelle (als eine Art Linksammlung) mit folgenden Themen (*=(ggf neuer) separater Artikel, @=Link):
-- Installation (Linux: @Debian-way bzw. mit *make, @Windows, *MacOS (?))
-- @"Erste Schritte"
-- *Security (update auf "allowed", vpn + reverseProxy (kein Portforwarding!))
-- *Automatisches Einbinden von USB-Interfaces und autocreate darüber hereinkommender Devices (mit Verweis auf die entsprechenden Hardwaresysteme und die Darstellung dort - ggf. wäre hier exemplarisch auf HM (BidCoS), Z-Wave und FS20 einzugehen bzw. auf die dortigen "Einstiegsseiten" (sofern vorhanden?) zu verlinken.
-- *Perl und Regex
-- Link auf "Einsteiger-pdf" (in dem sind obige Themen angerissen, es kommen aber auch Loggen, plotten, structure und Watchdog vor (ungeprüft). Das das m.E. eigentlich völlig ausreichend, man könnte das aber auch im Rahmen einer
-- Linkliste mit nützlichen Basis-Modulen machen. (Was im pdf drin ist, ggf. noch Threshold?) Diese könnte man erweitern mit Wiki-Artikeln, die man kennen sollte (Event-Monitor!)
-- GUI ist was, was viele vielleicht an der Stelle noch interessiert (incl. Floorplan usw.). M.E. ist es ausreichend, nur auf eine allg. Wikidarstellung der unterschiedlichen Angebote zu verweisen (?)

b) Einsteiger-pdf:
Ist ja eigentlich super, und kann/sollte auch weiterhin eine zentrale Rolle spielen. Aber die dortige Darstellung des Editierens der .cfg und #include sind in jedem Fal überholt, ob man Floorplan an der Stelle schon braucht, darüber kann man vermutlich lange diskutieren.
Nicht mehr so prickelnd finde ich FS20 als Beispielsystem, und die Darstellung von HM ist zwar auch super und hat mir viel geholfen, aber das würde ich dennoch mittlerweile (wieder?) als getrenntes Dokument sehen für Leute, die damit einsteigen wollen.
Rein sollte dafür die Option mit dem raw-Import von mehreren Codezeilen (ich bin nicht der einzige, der telnet noch nie benutzt hat...).

c) Erste Schritte:
Funktion von Dummy klarstellen (s.o.).

Das war's für's erste. Ich übernehme da gerne den einen oder anderen Teil, aber einiges weiß ich nicht bzw. kann nicht beurteilen, ob die Vorschläge in die falsche Richtung gehen.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Hi,

mir geht es da ähnlich wie Beta-User, ich nehme immer mal wieder Anlauf, stelle fest es wird zu groß und mache dann für mich sowas weil ich es gerade brauche und endlich mal verstehen will. Dann denke ich schon beim Schreiben dran, das muss eigentlich an entsprechende Stelle ins Wiki oder ins HowTo. Aber dann steht da wieder die große ungelöste Struktur im Raum ...

Ich unterstütze den Vorschlag, das HowTo ziemlich einfach (und Hardware unspezifisch) zu lassen. Es wird relativ statisch sein, also muss da bloß die Orientierung rein.

Soll man jetzt dazu einfach mal ein HTML als Vorschlag verfassen?

Zum Punkt 1 a) von Beta-User ich meine man muss es vorm ersten Lauf abschalten sonst ist es zu spät und FHEM klemmt. Ist mittlerweile beim nackten Raspberry mit einem BT Stick dran so. (Probing CUL device /dev/ttyAMA0 ein paar Einträge und Perl bei 100%)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

krikan

ZitatSoll man jetzt dazu einfach mal ein HTML als Vorschlag verfassen?
Die HOWTO-HTML-Seiten auf fhem.de sollen komplett verschwinden und durch einen Link auf entsprechende Wiki-Seite(n) ersetzt werden, damit Änderungen schneller, einfacher und durch mehr Personen vorgenommen werden können als auf der HTML-fhem.de Seite.

Wer mag kann gerne Vorschläge im Wiki abliefern. Vorgaben oder DEN richtigen Weg gibt es mMn nicht.

Zitat
1. Das "Erste Schritte" im Wiki ist ziemlich gut und greift ganz viele Teile aus dem Howto auf, nicht enthalten sind folgende Themen:
Erste Schritte soll(te?) nur einen ersten Einstieg und Überblick ohne Hardwareanforderungen liefern; quasi, ob FHEM etwas für einen persönlich ist. Darum sind auch viele Dinge nicht enthalten. Es soll nur einen Überblick verschaffen.
Nächster Schritt wäre das Einsteiger-PDF.

Zitat2. Gar nicht (im Howto) enthalten sind Hinweise auf die Bedeutung von perl, regex &Co.. Da würde sich m.E. ein Link auf die entsprechenden Abschnitte in der commandref und http://regex101.com/ anbieten, zur Frage wo s.u..
Das Thema Perl- und RegEx-Kenntnisse kommt aus meiner Sicht (mittlerweile) zu kurz. Hatte deshalb in Erste Schritte vor kurzem einen Hinweis zu Perl aufgenommen..
Das HOWTO ist schon relativ alt. Stammt von Rudi aus der Zeit, als es noch kein Einsteiger-PDF gab und ich habe es nicht wirklich weitergepflegt.
"Damals" wurde in der Google-Goup ganz oft auf die Bedeutung von Perl hingewiesen.

zu 3. habe ich keine Probleme mit vorsichtigen Ergänzungen in Absprache mit Uli. Aber bitte nicht zu sehr aufbohren. Mir ist dort mittlerweile schon wieder zu viel drin. Dort wird versucht Readings/Internals/Attribute zu erklären und die Namensgebung bei Modulen zu erläutern.

zu 4. Fritzbox raus und FS20 raus. Hardwareunabhängig ist grundsätzlich nicht schlecht, aber wie erklärt man loggen, plotten usw. sinnvoll?

zu 5.) "Daumen hoch."

zu 5b) Uli als Einsteiger-PDF Autor ansprechen.

Danke für den Einsatz!

Btw: Irgendwie sollten wir das neben deutsch auch auf englisch hinbekommen, damit wir nicht alle Fremdsprachler abhängen. Bei "Erste Schritte" und FHEM Installation" habe u.a. ich mich mit Englisch versucht, wobei Versuch ernst zu nehmen ist.

Gruß, Christian

Otto123

Hallo Christian,

Du bist doch bestimmt von uns der fitteste im Wiki, ich tue mich immer schwer mit Formatierung, Struktur, Links, Autor Box usw.
Vorschlag: nimm doch
Zitatzu 5.) "Daumen hoch."
und lege das genau so als Hülle mal an? Dann können wir das Seite für Seite mit Texten/Vorschlägen füllen?!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

OK, dann haben wir zumindest mal einen Fahrplan. Den Ansatz, sich mal auf den Weg zu machen, finde ich ok, da ja scheinbar Einigkeit über die "grobe Richtung" (Punkt 5) besteht (?). Vorschläge sind aber willkommen und sicher findet sich beim Erstellen noch der eine oder andere Punkt, der so noch nicht hinhaut.

Vorab: Die Liste sollte eher eine Bestandsaufnahme sein, das "enthält - enthält nicht" war nicht an sich als Kritik gedacht.

Zu den "Ersten Schritten": Das ursprüngliche Ziel war klar, und es hat vermutlich einigen Leuten sehr geholfen, das mal praktisch auszuprobieren. [OT]Ob man damit feststellen kann, ob FHEM was für einen persönlich ist, wage ich zu bezweifeln, weil einem größeren Teil der Neu-User nicht klar zu sein scheint, dass man FHEM "pflegen" muß und sich bei jedem neuen Modul bzw. jeder neuen Hardware überlegen, was man sich damit "einbrockt" - aber das ist wieder ein anderes Thema, irgendwo angesiedelt zwischen "Erwartungen", "Planung" und "Betrieb" ;) .[/OT]

Einig sind wir darin, dass es auch auf mittlere Sicht ein "Arbeitsdokument" zum ersten Erproben ohne Hardware sein soll - ich würde es im Hinterkopf ergänzen um "ohne vertiefende Einblicke". Von daher würde ich perl und regex (bzw. devspec lt. commandref) in einem logisch anschließenden 2. Teil (oder weiteren Teil bzw. dann der Linkliste im Sinne von: "was man sinnvollerweise gelesen haben sollte") sehen und dahin ggf. auch structure etc. packen. Damit wäre der derzeitige Artikel also quasi wieder zu reduzieren auf eine Art "blink" (so war das ursprünglich, wenn ich das noch recht in Erinnerung habe. (Btw. zu regex&co: die Commandref enthält mit der "Einleitung" auch eine Art allgemeiner Einführung, in dem vieles kurz und knackig erläutert ist).

Der Hinweiskasten zu Dummy wartet in der deutschen Fassung auf Rückmeldung: Wenn das in Text und in der Sache ok ist, kann ich gerne noch versuchen, das zu übersetzen - verbessern kann es dann ja jemand, der (noch ;D ) besser Englisch kann ;) .

UliM habe ich wegen des pdf per pm kontaktiert und warte mal auf seine Reaktion.

Was den Rest angeht: Ich mache mich (voraussichtlich aber erst übernächste Woche) gerne mal dran, da einen ersten Vorschlag (in einer deutschen Fassung) zu machen - und das dann als "Roh-Übersetzung" nachzuziehen, wenn das in der deutschen Fassung einen "mature" status hat. Allerdings: bei der Erstellung der letzten Seiten (ThinClient und Dokumentenstruktur in FHEM) hatte ich den Eindruck, dass es eventuell besser wäre, jemand würde die grundsätzliche Struktur (leer) angelegt (Danke @Otto, war fast fertig mit Tippen...) - vor allem dann, wenn es im Hintergrund bei entsprechender Vorgehensweise möglich sein sollte (?), dass der User eine für ihn passende Sprachfassung ausgeliefert bekommt...
Oder kann man das auch leicht im Hintergrund nachziehen? (ich vermute es fast, das Thema wäre dann nur das Nachziehen von Links - nach ggf. erfolgtem Umbenennen.)

@Andis & ggf. andere stille Mitleser:
Jetzt wäre die Gelegenheit, sich einzubringen und ggf. einen Teil der Arbeit zu machen (Otto ist ja schon an Bord, vorab schon mal Danke! ;) )...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Wenn wir grade dabei sind eine Rohfassung für eine englische Übersetzung der Dokumentstruktur:

ZitatDocumentation about FHEM is spread among several sources.

Short overview as a first orientation:

=[http://www.fhem.de FHEM]=
Some basic infos about FHEM and installation instructions.
={{Link2CmdRef}}=
If you run into trouble when using and configuring FHEM it is strictly recommended to have a look into '''CommandRef'''. There you find detailed info about usage and options for all official modules and FHEM-commands. Also this is the place where new functionality will be first documented directly by module's autors. Commandref shall provide the necessary info about how to use
* FHEM commands and options;
* Device Modules wrt. definition, configuration and usage. Device Module typically means modules to integrate a piece of hardware;
* Helper Modules.
For all people contributing software to be officially distributed with FHEM (aka Module author) there is just one strict rule: They have to provide a commandref (in english) for the module and support it for the first tree months. So commandref is the most important source for information about each module.

'''TIPP:''' A lot of the Module Authors are not fluent in english, so in case you see room for improvement of the english version just provide a better version and contact the respective[https://www.fhem.de/MAINTAINER.txt maintainer] - he/she most likely will be happy.

=FHEMWiki=
The page you are currently reading is part of the FHEMWiki. The link at the top left leads you to the main page. This is a good place to start. We appologise about most articles are in german, feel free to add or translate content also in english for others! Many articles you find in the FHEMWiki are directly maintained by Module's authors, a lot of them have just been written by other users. So accuracy and actuality of the articles may vary.

'''TIPP:''' There's a special [https://forum.fhem.de/index.php/board,80.0.html section in our forum] for proposals for improvement on the FHEMWiki.

=[http://forum.fhem.de/ Forum]=
Some Module Authors - especially of Modules not (yet) distributed as part of FHEM - prefer to provide further info about the usage of these modules in the forum. Helpfull info about the forum itself is provided in the [https://forum.fhem.de/index.php/board,18.0.html pinned Threads in Anfängerbereich], we appologize about them beeing mostly in german. Feel free to ask any question also in english - either in the english part of the forum or also in the regular section you find suitable for your specific interest. If you are able to read german, you may find a lot of usefull info by using the hints for doing forum searches in the mentionned pinned threads.

'''TIPP:''' We like to challenge people about first having used the searching possibilities before asking, as most problems have been discussed before - there are about 20.000 users in the forum - so there waits (at least one) solution on most topics to be discovered! But we understand it's not easy to even know the right keywords for searching if you are not speaking german.

=Internet, Blogs usw.=
Information provided in other sources - especially blogs - you have to challenge yourself whether this is at the right level of actuality and quality. Keep in mind: Most of the respective bloggers aso. may follow their own agenda. This may be different to the FHEM community's.

'''TIPP:''' So it's highly recommended to first doublecheck that sort of information against the one provided by the community before asking questions on info sourced "elsewhere" in the forum.

[[Kategorie:Dokumentation]]
Kann gerne nach Durchsicht dann in's Wiki. Oder sollte man da eine neue, separate Seite erfassen (gefällt mir nicht so...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Otto123 am 09 Februar 2018, 15:14:07
nimm doch und lege das genau so als Hülle mal an? Dann können wir das Seite für Seite mit Texten/Vorschlägen füllen?!
Kann ich machen, zunächst möchte ich aber endlich mal die "short description" in der commandref überall nachpflegen. Also wird nicht sofort etwas. Wenn ihr ungeduldig werdet, dann bitte selbst loslegen.

Zitat(Btw. zu regex&co: die Commandref enthält mit der "Einleitung" auch eine Art allgemeiner Einführung, in dem vieles kurz und knackig erläutert ist).
Ja, stimmt. Sollten wir ebenso wie https://fhem.de/commandref.html#perl als "Pflicht"lektüre anführen. Kommt momentan zu kurz.

ZitatDer Hinweiskasten zu Dummy wartet in der deutschen Fassung auf Rückmeldung:
Gerade gesehen:  Im 2. Absatz von https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Device_anlegen_-_define hatte Andies das Thema dummy schon angeführt. Ist jetzt irgendwie doppelt.

Zitatvor allem dann, wenn es im Hintergrund bei entsprechender Vorgehensweise möglich sein sollte (?), dass der User eine für ihn passende Sprachfassung ausgeliefert bekommt...
Gibt keine Hintergundautomatik. Man muss die passende Seite aufrufen. Von fhem.de würde ich auf die passende Sprachversion verlinken.
Die Sprachversion kann man durch ein angehängtes Kürzel am Artikelnamen wie hier unterscheiden:
deutsch: https://wiki.fhem.de/wiki/FHEM_Installation_Windows
englisch: https://wiki.fhem.de/wiki/FHEM_Installation_Windows/en

Hier
https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM
https://wiki.fhem.de/wiki/First_steps_in_FHEM
habe ich aber unterschiedliche Seitennamen verwendet, weil es ansonsten wenig Sinn machte.
Am Ende von https://wiki.fhem.de/wiki/First_steps_in_FHEM#What.27s_next.3F ist ein Hinweis, welche Sprachversion aktueller ist.
Es bleibt aber manuelle Übersetzungsarbeit.
Ich würde erst die deutsche Fassung machen und dann den Inhalt auf eine englische Seite mit Links und Co kopieren. Bei Erste Schritte und Installation Windows haben wir das so durchgeführt.

ZitatOder sollte man da eine neue, separate Seite erfassen (gefällt mir nicht so...)
Finde separate Seiten für jede Sprache wegen Übersichtlichkeit besser. Vielleicht kommen auch die französischen Wiki-Schreiber/User wieder und dann würde es in einer Seite gänzlich unübersichtlich.
Lasse mich aber auch vom Gegenteil überzeugen.

Ansonsten freut mich Deine prompte Übersetzungsarbeit. Du kannst so etwas auch gerne direkt ins Wiki packen.

Eine formale Anmerkung  ;) : 1. Überschriften bitte auf 2. Gliederungsebene packen (bspw: ==[http://www.fhem.de FHEM]==).

Gruß, Christian

Beta-User

Zitat von: krikan am 09 Februar 2018, 20:30:26
Die Sprachversion kann man durch ein angehängtes Kürzel am Artikelnamen wie hier unterscheiden:

Finde separate Seiten für jede Sprache wegen Übersichtlichkeit besser. Vielleicht kommen auch die französischen Wiki-Schreiber/User wieder und dann würde es in einer Seite gänzlich unübersichtlich.
Lasse mich aber auch vom Gegenteil überzeugen.

Ansonsten freut mich Deine prompte Übersetzungsarbeit. Du kannst so etwas auch gerne direkt ins Wiki packen.
Gerne geschehen, die englische Fassung ist entsprechend der bisherigen Gepflogenheiten online: https://wiki.fhem.de/wiki/Dokumentationssstruktur/en.
Das mit den "==" hat es wohl beim parsen beim reinkopieren hier im Forum zerhauen, ich hatte ja nur die Ausgangsstruktur verwendet, hätte eigentlich passen sollen ??? .

Was die Frage der Sprachfassungen angeht, finde ich das nicht sooo klasse. Mir hatte eher was vorgeschwebt wie im Mediawiki: Da kommen oben im Kopf eines Artikels die verfügbaren Sprachfassungen. Sowas läd ggf. auch mal jemanden ein, der einfach nur etwas FHEM kann, dafür aber ggf. noch besser Englisch oder Französisch (bei mir würde das dann zwar irgendwie so aussehen als ob es französisch wäre, aber einladend wäre das eher nicht...). Allerdings habe ich keinen Plan, wie das im Hintergrund verwaltet wird (Wiki-extension?). Und klar: Es bleibt "manuelle" Arbeit :) .

Zu dem doppelten Dummy-Hinweis: Ist irgendwie richtig, aber wir sollten irgend eine Zwischenlösung finden - nach meinen Eindruck kommen die "vielen Dummys" eventuell auch daher, dass sie an der prominenten Stelle so "beworben" werden, ohne von einer unnötig exzessiven Verwendung abzuraten.

Wenn es wegen der Sprachfassungen keinen zusätzlichen nachträglichen Aufwand generiert, können wir (Otto, ich und wer sich noch berufen fühlt) die Artikel auch einfach anlegen, mir ging es nur darum, dass das eben ggf. zusätzlichen Aufwand nach sich zieht, weil zumindest mir nicht so richtig klar ist, welche administrativen "Drumrums" einzuhalten sind, um den Artikeln eine vernünftige Struktur im Sinne der Wiki-Einbindung zu geben.
Das eilt auch nicht sooo sehr, ich bin jetzt eh' erst mal ziemlich offline.

Bis dahin erst mal Grüße,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Danke!

Wir hatten die Diskussion zur Mehrsprachigkeit hier https://forum.fhem.de/index.php/topic,65790.0.html schon einmal. Neuer Stand ist mir nicht bekannt.
Von meiner Seite wollte ich Mehrsprachigkeit nur bei den von fhem.de ins Wiki verlagerten Seiten (HOWTO, Installation, Erste Schritte (neu)).
Dokumentationsstruktur hatte ich nicht auf dem Schirm schadet aber nicht.
Ansonsten würde ich mich weiterhin auf deutsch beschraenken.

Zitat
Wenn es wegen der Sprachfassungen keinen zusätzlichen nachträglichen Aufwand generiert, können wir (Otto, ich und wer sich noch berufen fühlt) die Artikel auch einfach anlegen, mir ging es nur darum, dass das eben ggf. zusätzlichen Aufwand nach sich zieht, weil zumindest mir nicht so richtig klar ist, welche administrativen "Drumrums" einzuhalten sind, um den Artikeln eine vernünftige Struktur im Sinne der Wiki-Einbindung zu geben.
Das ehrt Dich/Euch und weil ihr Euch die Gedanken macht, war mein Ansatz: Macht ruhig. Artikel kann man immer noch umbenennen und anders kategorisieren. Letzteres mit keinen Nebenwirkungen.

Gruß, Christian

Beta-User

Ah, den Mehrsprachigkeitsartikel hatte ich nicht wahrgenommen (und jetzt auch nicht vertieft gelesen), da ich einfach von folgenden Annahmen ausgegangen bin:
- Wiki-SW unterstützt grundsätzlich Mehrsprachigkeit (ggf. nach Aktivierung)
- Grundlegende Infos, die man als interessierter Mensch _braucht_, sollten/müssen auch mind. auf englisch verfügbar sein (mehr ist "nice to have"). Also eigentlich reicht für alle die commandref ;) :( ;D 8) .

Aber klar, weniger ist manchmal mehr, vor allem, wenn es um Aktualität geht. Andererseits: wenn man nicht auf die Schnelle erfassen kann, wo "eigentlich" noch was zu tun wäre (mehrere Sprachfassungen), ist es noch eine Stufe schwieriger, Aktualität zu gewährleisten, und bei den beiden geläufigsten Sprachen sollte das noch gehen...

Aber darauf können wir dann zu gegebener Zeit nochmal (in dem anderen Thread) zurückkommen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, anbei füge ich mal eine erste Rohfassung bei, damit es hier weitergeht.

Es sind bewußt erst mal nicht zu tiefgreifende Eingriffe in den Ausgangstext erfolgt. Da manches noch aktualisiert werden sollte und auch einige Anmerkungen zu diskutieren sind, vor einer Veröffentlichung erst mal auf diesem Weg.

Rückmeldungen sind wie immer willkommen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files