Weiterentwicklung commandref, war: Deutsche commandref-Sektion für 99_SUNRISE_EL.pm

[nils_]

Leider waere das eine manuelle Arbeit.

ich hab da nochmal was versucht
weil manuell mag ich nicht 

zur Info:
dabei wird jetzt nach <a  name="..."> gesucht, und dann nach der nächsten Überschrift <h3> ein Link auf die andere(n) Sprache(n) erzeugt.
(nicht für den Teil der aus den Modulen kommt. sprich die Änderung vom letzten Mal...)
Hoffe das passt so erstmal an den Stellen...


/edit:
und ich glaube die abfrage für die Device modules passte nicht (bitte nochmal anschauen, evtl. hab ich da auch was falsch verstanden)

[rudolfkoenig]

ich hab da nochmal was versucht

Habe das Ergebnis angeschaut, und ich bin nicht begeistert: es sind sehr viele kurze Abschnitte, und da stoert das "penetrante" "EN DE" Text. Wenn wir das dezenter hinkriegen, dann vielleicht. Wirklich noetig finde ich es nicht.

und ich glaube die abfrage für die Device modules passte nicht (bitte nochmal anschauen, evtl. hab ich da auch was falsch verstanden)

Danke, habs gefixt.

Fuer zukuenftige Patches:
- bitte Patch mit "diff -u" (oder Vergleichbares) bauen.
- bitte darauf achten, dass keine unmotivierte Leerzeichen am Ende der Zeile auftauchen
- bitte keine Zeilen mit Dos-Line-Ending einschmuggeln.
- bitte auf 80 Zeichen/Zeile achten.

[nils_]

Habe das Ergebnis angeschaut, und ich bin nicht begeistert: es sind sehr viele kurze Abschnitte, und da stoert das "penetrante" "EN DE" Text. Wenn wir das dezenter hinkriegen, dann vielleicht. Wirklich noetig finde ich es nicht.

das seh ich allerdings genauso... für ein "dezenter" fehlt mir momentan die idee.... (zeilen zwischen den <h3>-Tags zählen, und wenn größer als X dann wieder ein link.... irgendwie auch unschön  )
kleinere schriftart wäre noch eine idee.
oder aber den "EN DE" Text in die selbe Zeile wie die Überschrift. (dafür müsste der zeilenumbruch durch <h3> umgangen werden?)

Danke, habs gefixt.

gerne.

Fuer zukuenftige Patches:
- bitte Patch mit "diff -u" (oder Vergleichbares) bauen.
- bitte darauf achten, dass keine unmotivierte Leerzeichen am Ende der Zeile auftauchen
- bitte keine Zeilen mit Dos-Line-Ending einschmuggeln.
- bitte auf 80 Zeichen/Zeile achten.

ok, werd ich versuchen.
leider kämpfe ich hier an dem rechner etwas mit der infrastruktur. ich hab leider keinen zugriff von hier auf das fhem-svn.
ich habe mir die dateien einzeln runtergeladen (runterladen müssen). die dann lokal bei mir in git "eingecheckt", und daraus dann die diff erzeugt.
vermutlich kommen da die Formatierungsprobleme her. (notepadd++ müsste ich auch nochmal die einstellungen durchgucken -.- )

[rudolfkoenig]

ich habe mir die dateien einzeln runtergeladen (runterladen müssen).

Was spricht gegen das FHEM update?

[nils_]

Was spricht gegen das FHEM update?

gar nix
ich hab nur hier kein fhem laufen und hocke hinter firewalls und proxys. das schränkt die möglichkeiten etwas ein

[rudolfkoenig]

Update kennt seit ein paar Monaten Proxy..

[nils_]

Update kennt seit ein paar Monaten Proxy..

i know, i know



hab gerade nochmal ein bisschen mit der schriftgröße gespielt...
ich erstelle mal 2 varianten, einmal mit links in der gleichen zeile wie die überschrift und einmal in der nächsten, nur etwas kleiner.


//edit:
anderer rechner, anderer weg ins inet. und schon komme ich zumindest an das svn

[nils_]

hab gerade nochmal ein bisschen mit der schriftgröße gespielt...
ich erstelle mal 2 varianten, einmal mit links in der gleichen zeile wie die überschrift und einmal in der nächsten, nur etwas kleiner.

beides im anhang zu finden....
die links sind nicht mehr so prominent, die Anzahl der Stellen an denen sie auftauchen ist natürlich identisch zur vorherigen variante.

dazu musste ich auch in einer css-datei was ändern. (<h3>-Tag ohne Zeilenumbrüche)
ob das die richtige stelle ist, weiß ich nicht, kenne mich mit css überhaupt nicht aus.

anderer rechner, anderer weg ins inet. und schon komme ich zumindest an das svn

ich hoffe die von dir erwähnten Dinge passen jetzt.

[nils_]

so ich glaube das ist die schönere variante....

musste auch noch etwas umbauen, da für einige module der regex nicht geklappt hat.
- hinter <a name="..." ging es noch weiter
- der modulname ist nicht immer im format <h3>xyz</h3> gewesen (mehrzeilig)
- das zusätzliche <p> nach =end html hab ich als workaround reingebaut, da ja <h3> keinen umbruch mehr macht, und daduch manche überschriften ans Ende des vorherigen Moduls gewandert ist


aufgefallen ist mir auch noch bei einigen modulen, das nach =begin html_DE  nicht das korrekte =end html_DE kommt. einfach mit der Browsersuche mal nach =end html in der commandref suchen.

ich lasse die anderen beiden dateien aus dem post vorher auch noch drin. (auch wenn sie im Grunde nutzlos sind )

[Prof. Dr. Peter Henning]

Der bessere Weg wäre:

- Saubere XML Tags aus einem etablierten Dokumentationsformat verwenden, z.B. aus docbook
- Je nach gewünschtem Anwendungszweck per XSLT/docbook Prozessor daraus entweder eine große HTML-Datei, oder eine PDF-Datei, oder viele kleine HTML-Dateien oder, oder oder erstellen.


LG

pah

[Christoph Morrison]

- Saubere XML Tags aus einem etablierten Dokumentationsformat verwenden, z.B. aus docbook
- Je nach gewünschtem Anwendungszweck per XSLT/docbook Prozessor daraus entweder eine große HTML-Datei, oder eine PDF-Datei, oder viele kleine HTML-Dateien oder, oder oder erstellen.

Full ack. Es gibt bessere Lösungen für das Thema als manuell alle möglichen Elemente auszuzeichnen und eine Krücke an die nächste zu bauen. Es gibt mit Pod::DocBook auch einen etablierten Legacy-Konnektor für die POD.

Aber hier sind wir damit ziemlich off topic - es ging nur um die Doku des 99_SUNRISE_EL.pm.

[Prof. Dr. Peter Henning]

Nein, eigentlich nicht. Es geht schon auch um die generelle Frage, denn die Dokumentation wird immer umfangreicher. Und manche Module liefern so viel Daten für die Commandref, dass das kaum noch beherrschbar ist (z.B. DOIF).

LG

pah

[Christoph Morrison]

Nein, eigentlich nicht.

Doch.

In diesem Thread werden nun mindestens drei Themen behandelt und zwei davon wären in einem eigenen Thread sinnvoller, u.a. die Frage wie man allgemein künftig mit der Generierung der Commandref umgehen möchte. Das ist ein so wichtiges Thema, dass es nicht hier unter falscher Flagge segeln sollte. Nicht jeder, u.a. ich, liest jeden Beitrag, aber es betrifft hier so ziemlich jeden.

Deswegen würde es mich glücklich machen, wenn ein Mod diesen Thread auftrennen und alles was allgemein zum Thema CommandRef geschrieben wurde, in einen eigenen Thread forkt in dem wir gerne weiter brainstormen können. Hier finden das aber zu wenig Leute.

Es geht schon auch um die generelle Frage, denn die Dokumentation wird immer umfangreicher. Und manche Module liefern so viel Daten für die Commandref, dass das kaum noch beherrschbar ist (z.B. DOIF).

Wir müssen uns z.B. mal Gedanken darüber machen, wo die Grenze zwischen Wiki-Beiträgen und CommandRef liegt. DOIF ist ein gutes Beispiel, wo ich finde, dass die ganzen Beispiele besser im Wiki aufgehoben sind und die CommandRef lediglich als Befehlsreferenz mit wenigen Beispielen und dafür gerne einem Link aufs Wiki dienen sollte. Ich finde die Anzahl der Beispiele bei SUNRISE_EL z.B. im Gegensatz wieder zu wenige, da durch das Design des Moduls (und die aktuell noch mangelhafte englische Doku) die Syntax deutlich besser erklärt werden kann als durch eine reine Beschreibung.

[Prof. Dr. Peter Henning]

Ich bleibe bei Nein.

pah

[nils_]

aufgefallen ist mir auch noch bei einigen modulen, das nach =begin html_DE  nicht das korrekte =end html_DE kommt. einfach mit der Browsersuche mal nach =end html in der commandref suchen.

ich liste die module mal hier auf

Code Auswählen Erweitern


44_S7_AWrite.pm
=end html_DE in neue Zeile

45_Plugwise.pm
46_PW_Circle.pm
46_PW_Scan.pm
46_PW_Sense.pm
46_PW_Switch.pm
52_I2C_HDC1008.pm
=end html muss in =end html_DE geändert werden


bei

Code Auswählen Erweitern

57_Calendar.pm
Calender -> Calendar (Zeile 3183, Titel...)
ist es nur ein Schreibfehler CalendAr != Calender (ist mir nur aufgefallen, weil bei den ersten varianten der Anchor-Name zur Überschrift passen musste)

im Grunde ist das alles nur kosmetischer Natur, weil die "=end html" Tags in der cref auftauchen, deshalb wollte ich jetzt nicht direkt die Maintainer kontaktieren.


btw. Maintainer für 52_I2C_HDC1008.pm steht keiner in der Maintainer.txt ?!