Diskussion:Wehre

AEO, MQ, ÜA, usw.

Der mies formate Text ließ viele Fragen offen. Zählen die letzten Angaben von Einzugsgebiet und Pegel Niddawitzhausen zu Wehre oder zur Sontra. Was heißt AEO und MQ? --Uwe G. ¿Θ? 15:07, 24. Jul 2005 (CEST)

• Einzugsgebiet: Die 451,70 km² Fläche beziehen sich auf die Wehre inklusive aller Zuflüsse
• Weil sich Eschwege-Niddawitzhausen einiges unterhalb der Einmündung der Sontra in die Wehre und damit an der Wehre befindet, zählen die Angaben zum (gesamten) Fluss-System der Wehre!
• AEO = oberirdisches Einzugsgebiet bis zur Meßstelle
• MQ = mittlerer Abflussmenge
• ÜA = Überarbeiten !?! (Ich habe den Überarbeiten-LINK aus dem Artikel entfernt, weil ich denke, dass mit meiner heutigen Überarbeitung des Artikels und meinen Infos in dieser Diskussion die diesbezüglichen Fragen geklärt sind!)
  --84.138.87.220 18:40, 2. Okt 2005 (CEST)

Rettelbach

Im Absatz Einzugsgebiet und Zuflüsse habe ich den „Rettelbach“, der zwischen Waldkappel und Bischhausen in die Wehre münden soll, ausgeblendet, weil ich ihn nicht auf genannten Einzelnachweisen „BfN-Karten“ und „HE-WRRL“ und auch nicht auf eigenen Kartenmaterialien finden kann. Gibt es mehr Infos hierzu?
MfG --TOMM 13:42, 11. Jul. 2011 (CEST)

Ich komme aus dieser Gegend und kenne diesen Bach aus eigener Anschauung. --Lothar Brill 14:10, 11. Jul. 2011 (CEST)

Dass Dein Rettelbach-Einfügen auf „Ortskenntnis“ basiert, hast Du bereits in „Versionen/Autoren“ erwähnt. Ich aber fragte nach mehr Infos (z. B. wo entspringt dieser Bach und wie verläuft er?)! Kannst Du zudem passendes Kartenmaterial als Quelle angeben?
MfG --TOMM 15:09, 11. Jul. 2011 (CEST)

Das dürfte dann doch einer sein, der im Kartendienst WRRL anders heißt. Bei km 15,2 ist zwar keiner, aber bei 15,3 der Pfontalbach.

Des Klammerlemmas Rettelbach (Wehre) bedürfte es auf jeden Fall nur, wenn es unter Rettelbach noch was gäbe. --Elop 17:46, 11. Jul. 2011 (CEST)

Die Lage vom Pfontalbach ist auf vorgenannten Einzelnachweisen nachvollziehbar – korrekt. Aber den angeblich 4 km langen (rechtsseitigen) Rettelbach kann ich auch nach nochmaligem Blick auf diese Kartenmaterialien nicht zurordnen und plädiere daher für dessen Löschung, sofern sich kein Nachweis dafür findet.
MfG --TOMM 19:29, 11. Jul. 2011 (CEST)

Hier wurde er aber als linksseitig eingetragen. --Elop 20:07, 11. Jul. 2011 (CEST)

Einen Tag später wurde er aber vom selben Wikipedianer hier auf rechts geändert (und ohne Angabe von Quellen mit 4 km Länge versehen)!
MfG --TOMM 20:25, 11. Jul. 2011 (CEST)

Das war ich, der Rettelbach fließt von rechts in die Wehre, etwa 500 bis 1000 Metern hinter dem Pfontalbach (auch Fohntalbach geschrieben), der von links in die Wehre fließt. Der Pfontalbach unterquert die ehemalige Kanonenbahn, der Rettelbach entspringt am Wehrberg und ist einige Kilometer lang. Habe zwar Kartenmaterial, komme aber gerade nicht dran. --Lothar Brill 10:23, 12. Jul. 2011 (CEST)

Ein Tal wäre an der Südflanke des Wehrbergs schon vorhanden, allerdings nur maximal 2 km. Eine Quelle ist dort aber nur 250 m vom rechten Wehre-Nebenarm entfernt eingezeichnet, darüber hinaus gehend nirgends auf Karten was eingezeichnet.

Nehmen wir mal an, bei Schneeschmelze flösse dort ein richtiger Bach. Warum muß der unbedingt in die Liste der wichtigsten Nebenbäche, wo weitaus größere bislang nicht drin stehen? --Elop 11:32, 12. Jul. 2011 (CEST)

Das Wasser dieser Quelle fließt nach einigen Metern in den besagten Rettelbach. (Vielleicht sollte ich einige Bilder machen und diese Bilder hochladen ;-)) --Lothar Brill 13:21, 12. Jul. 2011 (CEST)

Abflussdiskrepanzen

Nach Eintragen der Pegelwerte fällt mir auf, daß die HLUG-Berechnung etwas sehr hoch erscheint. Demnach nähme der MQ Wehre auf den letzten, eher flachwelligeren 21,7 km² um 0.597 m³/s zu, entsprechend einer Abflussspende (Mq) von 27,5 l/s km² - das ist ein Wert, der wohl im ganzen Fulda-Werra-bergland höchstens in Karstgebieten (Ifta-Quelle) anzutreffen wäre, obwohl außer dem linksseitigen Schweinsbach nix mehr kommt.

Hätte da jemand eine Erklärung? Gibt es womöglich einen die Wehre speisenden Nebenarm der Werra bzw. fließt die Alte Wehre (417992) womöglich "rückwärts" von Jestädt nach Niederhone? --Elop 19:37, 30. Sep. 2012 (CEST)

Wo kommt eigentlich die extrapolierten Werte der PEGEL2-Angabe her? Auf die würde ich gerne verzichten, damit die Abflusswerte (wie und von wem auch immer die berechnet wurden) in den PEGEL3 überführt werden können.--SteveK ?! 15:30, 21. Okt. 2015 (CEST)

An diesem Tag wurden die Werte der PEGEL2-Angabe eingefügt.

@Elop: Woher stammen sie?
--TOMM (Diskussion) 15:45, 21. Okt. 2015 (CEST)

Ist doch referenziert (und sogar im Eröffner dieses Abschnitts erwähnt) - die Werte sind von HLUG (namtlich von Gerhard Brahmer) extrapoliert, im Hinweislink steht mehr dazu.

Im jetzigen WRRL-Dienst stehen viele Werte nicht mehr - wohl auch deshalb, weil bald aktuellere kommen sollen:

>>HLUG plant eine Aktualisierung der Regionalisierung von MQ und ggf. MNQ (war ursprünglich geplant für das Jahr 2013) für den 30-jährigen Bezugszeitraum von „1981 bis 2010“ anzugeben. (Quelle: Dr. Gerhard Brahmer HLUG) <<

War m. E. nicht soo schwer zu finden. Warum mache ich mir eigentlich die Mühe, Quellensammlung und Vorlage ständig zu erweitern und aktualisieren? --Elop 17:15, 21. Okt. 2015 (CEST)

Erster Teil meiner Frage beantwortet. Gibt aber dennoch nur ein "AUSREICHEND", weil der zweite Teil eben nicht beantwortet wurde ;-).

Die Zahlen für den Gesamtabfluß halte ich auch für deutlich zu hoch, wobei die sich auf einen anderen Zeitraum beziehen. --SteveK ?! 09:32, 22. Okt. 2015 (CEST)

Nachtrag: Du pflegst die Quellensammlung, damit du uns immer wieder darauf stoßen kannst. Und die Pflege machst du ja ganz toll. --SteveK ?! 09:38, 22. Okt. 2015 (CEST)

Wenn ich mal einen bekannteren Hautarzt zitieren darf: „Psychologie ist eine Unverschämtheit.“ --Silvicola ^Disk 09:56, 22. Okt. 2015 (CEST)

‎Einzelnachweise – Referenzfehler

Dieser Diskussionsabschnitt enthält Informationen zu:
Referenzfehler: Ungültiges <ref>-Tag … unterschiedlicher Inhalt

@Elop: Kannst Du bitte mal im Abschnitt Einzelnachweise den Referenzfehler zu DE-NI_GKJB-08 korrigieren!
Ich weiß nicht, wo da der Fehler liegt.
--TOMM (Diskussion) 22:46, 19. Okt. 2015 (CEST)

Ich verstehe es gerade seber nich ...--Elop 22:53, 19. Okt. 2015 (CEST)

Hmh, @Silvicola: Kennst Du die Lösung?
--TOMM (Diskussion) 23:03, 19. Okt. 2015 (CEST)

Getan.

Erklärung:

Jede Vorlage:GeoQuelle-Einbindung erzeugt unter der Hand und automatisch eine benannte ref mit Namen (glaube ich) ARG1_ARG2. Vom möglichen PRÄFIX und SUFFIX-Parameter hängt dieser Name also gar nicht ab, was misslich ist, denn so wird unten im references-Block überhaupt nur eine der Einbindung zu gleichem ARG1-ARG2-Paar angezeigt und die anderen) verweisen, trotz eigentlich unterschiedlichen Textes, dann doch auf diese eine. It's not a feature, it's a bug!

Ich bin schon vor Langem mal draufgestoßen, als ich „semantisch modifizierte“ Standardbelege mit PRÄFIX/SUFFIX-Parametern benutzen wollte, in dem Stile hier (bitte auch im Quelltext betrachten):

• Dingsdabach, 2,5 km
• Bumsdabach, 4,5 km

…

UND DAS WIRD DARAUS:

Länge nach: Daten- und Kartendienst der Landesanstalt für Umwelt Baden-Württemberg (LUBW) (Hinweise)

Meine Lösung ist, wie eben hier im Artikel die GeoQuelle-Einbindung mit zusätzlichem Parameter ref=nein in eine eigene ref-Definition zu packen, bei der ich selbst das name-Attribut definieren kann, und darin den PRÄFIX-SUFFIX-Kontext selbst zu Fuß zu definieren. Da weiß man, was man hat, und zudem kann man auch noch ein group-Attribut vergeben, der bei dem GeoQuelle-Namensautomatismus schon gar nicht vorgesehen ist.

Was hier nun genau schiefging, weiß ich nicht recht. Ich vermute nach dem roten Fehlertext fast, dass nunmehr der pro Einbindung entstehende, bei mehreren Einbindungen mit gleichem definiertem name entstehende ref-Konflikt gerade wegen des gleichen names neuerdings vom Wikiparser bemäkelt wird. Das wäre ein Fortschritt, weil so das obige Problem mit dem Konflikt überhaupt erst ans Tageslicht käme. Bisher zumindest konnte man problemlos mehrere gleich-nameige definierende refs in den Text setzen, die wurden stillschweigend im references-Block vereint – wenn sie doch inhaltlich anders definiert waren, Pech gehabt, einer verdeckt alle anderen. Oben mit den PRÄFIX-/SUFFIX-gespeisten Textkontextelementen ja ganz analog.

Weitere Forschung nach dem Prinzip „Schauen wir mal, wie die ref-Funktionalität genau spezifiziert ist, indem wir durch Versuch und Irrtum herauspusseln, wie sie realisiert ist“ (Specification by implementation) versage ich mir inzwischen nämlich regelmäßig. Wenn man dann nämlich einen Bug wie oben findet und anmeldet, wie hierbei auch geschehen, ändert doch ohnehin keine Sau in Jahren etwas daran. Wenn man dagegen die vermeidende Eigen-ref-Konstruktion wie oben benutzt und die GeoQuelle-Pfleger machten die später durch unüberlegte Änderung selbst dann auch noch unbenutzbar, dann kann man sagen: Nun schaut mal schön, wie ihr es hinbekommt, dass die Vorkommnisse im Bestand wieder funktionieren, denn ich habe keine Lust dazu, etwas nachzukorrigieren, was auch bei der vermutlich und sinnvollerweise intendierten, aber durch falsche Implementation vermurksten Realisierung funktionieren müsste und jetzt offenbar noch schlimmer vermurkst wurde.

Hugh. Kropf geleert.

Wenn wirklich der Parser geändert wurde, dann macht Euch mal schön auf ein Rotes Meer solcher nunmehr falscher Doppeleinbindungen via GeoQuelle gefasst. Überall nämlich, wo nun etwa mit dem so einfach aus dem Ärmel zu schüttelnden {{GeoQuelle|ARG1|ARG2}}-Konstrukt zweimal zum selben ARG1-ARG2-Parametersatz eingebunden wurde, steht dann nämlich eine fette, rote Lache im Fußnotenblock. Benutzerin:Lómelinde und anderer Warter werden sich gewaltig freuen!

Notabene: Diese Änderung ist notwendig, sie wurde nur zu lange verschleppt.

--Silvicola ^Disk 01:08, 20. Okt. 2015 (CEST)

Hallo

Ihr wendet dann die Vorlage falsch an. Mit der Verwendung des Parameters "REF-NAME" geht es. Die Default-Namen dienen dazu, dass die Referenzen zusammen bleiben (Feature), sollen von einer Quelle unterschiedliche Referenzen erzeugt werden, so muss man einen alternativen Namen vergeben.

--SteveK ?! 10:25, 20. Okt. 2015 (CEST)

Hmh,

@ Silvicola, ich habe Deine ausführlichen Informationen ein paar Mal gelesen, damit ich verstehe, worum es etwa geht.

Gelernt habe ich dabei, dass bezüglich Parser-Änderung wohl wieder mal verschlimmbessert wurde, weil künftig wohl zumindest hunderttausendfach (eigentlich unnötige) Änderungen als Notlösungs-Änderung vorzunehmen sind.

Nur ein Beispiel:
Die Vorlage {{GeoQuelle|DE|BFN-Karten}} ist in Wikipedia-Artikeln wohl hunderttausendfach eingebunden, so dass dann künftig wohl korrigiert werden muss.

Bisher funktionierte alles bestens. Daher frage ich (mich): Wozu nutzen wir solche Vorlagen, wenn wir sie künftig über Notlösungen einbinden müssen? Das kann doch nicht im Sinn der Erfinder/Macher von WikiProjekt Geographie/Quellensammlung liegen!

Und die Beobachtungslisten werden dann z. B. wegen dieser Liste massiv wie nie zuvor überlaufen; seufz! :-(

Beispiel aus dieser Liste: Konrad-Adenauer-Bach [ :-) ]

Und: Das kann doch auch nicht im Sinn der Parser-Software-Verschlimmbesserung liegen!

Danke für Deine Notlösungs-Änderung, mit der wohl auch Du – wegen „Kropf geleert“ – nicht glücklich bist, weil es tatsächlich keine Korrektur sondern eine Notlösungs-Änderung ist. Eine solche hätten Elop und ich wohl auch hinbekommen. :-)

Auch mein Kropf schwillt aktuell an, denn Lust dazu, etwas nachzukorrigieren, wozu wohl mehrere Benutzer vermutlich mehrere Monate brauchen, habe (auch) ich nicht.

@ Silvicola, Du hast oben ARG1 und ARG2 erwähnt; diese Abkürzungen stehen wohl für Argument…. ?!?

@ Steve, mit dem Parameter REF-NAME habe ich es gestern versucht; funktionierte aber nicht; eben habe ich es (ohne zu speichern) nochmal ausprobiert; es funktioniert nun; aber auch dies ist nur eine Notlösungs-Änderung.

Bleibt nur noch eine Frage offen:

Wo zum Geier fließen der ARD-Dingsdabach und der Horizontal-Gewerbe-Bumsdabach? :-)

Vorschlag (wegen unpassender Diskussionsstelle):

Dieses Diskussionsthema an passende Stelle …
     … (z. B. Hilfe Diskussion:Einzelnachweise als Thema Referenzfehler: Ungültiges <ref>-Tag … unterschiedlicher Inhalt) …
… auslagern, und (dann erst) dort weiterdiskutieren!
--TOMM (Diskussion) 10:35, 20. Okt. 2015 (CEST) bis --TOMM (Diskussion) 10:49, 20. Okt. 2015 (CEST)

Das Phänomen kommt aus der bei der GeoQuelle verwendeten Vorlage:Internetquelle die wohl einen kryptischen, bei gleichen Aufruf unterschiedlichen Text liefert (warum auch immer). Hier im Artikel wurde zweimal {{GeoQuelle|DE-NI|GKJB-08}} hintereinander verwendet, was eigentlich identische Ergebnisse liefern müsste. Ich habe für ein paar Referenzen die Verwendung der Vorlage entfernt, dann geht es korrekt.--SteveK ?! 11:08, 20. Okt. 2015 (CEST)

Nachtrag: die nicht umgestellten Referenzen können weiterhin des Fehler produzieren. Ergo: Die Verwendung der Vorlage:Internetquelle sollte eliminiert werden. --SteveK ?! 11:10, 20. Okt. 2015 (CEST)

@ Steve, Du hast geschrieben:
Ich habe für ein paar Referenzen die Verwendung der Vorlage entfernt.

Du hast das aber nur für Dich testweise gemacht; oder wie meinst Du das?

Denn die Vorlage {{GeoQuelle|DE-NI|GKJB-08}} ist/war doch nur 2mal im Artikel verwendet.

Dies ist aber wohl auch nur eine Notlösungs-Änderung, die auch nicht im Sinn der oben von mir genannten Erfinder/Macher liegt.

Die Vorlage:Internetquelle mag auch ich nicht. :-)
--TOMM (Diskussion) 11:49, 20. Okt. 2015 (CEST)

Ich habe bei Referenzen die Verwendung der Vorlage Internetquelle entfernt. Die Referenzen sind weiter vorhanden. Ich hatte nicht die Zeit, alle Vorlagenanwendungen umzusetzen, zudem sind die älteren Jahrbuchreferenzen gut geeignet zu demonstrieren, wo der Unterschied ist. Das Problem ist, das durch die Vorlage Internetquelle beim zweiten Aufruf von {{GeoQuelle|DE-NI|GKJB-08}} etwas anderes als beim ersten Aufruf zurückgegeben wird, was dann zu dem Referenzfehler führt. Dieses habe ich aber nicht weiter ergründet. Ziel und im Sinne des Erfinders von Vorlage GeoQuelle ist es, für die gleiche Angabe auch den gleichen Text zu bekommen, damit die Angabe der Nachweise vereinfacht wird. --SteveK ?! 13:24, 20. Okt. 2015 (CEST)

@ Steve:

Du hast geschrieben: Ich habe bei Referenzen die Verwendung der Vorlage Internetquelle entfernt.

Wo hast Du die Verwendung der Vorlage Internetquelle entfernt?

Ich verstehe es leider nicht.
Bis später --TOMM (Diskussion) 13:53, 20. Okt. 2015 (CEST) und --TOMM (Diskussion) 13:54, 20. Okt. 2015 (CEST)

@REF-NAME: Klar, damit geht es. Nur ist dann die Refnamensvergabe ziemlich verkappt und implizit. Ich befürchte aber, selbst viele der gewässerfremden Querschnitt-Warter vom Schlage Lomelindes wissen gar nicht, dass durch diesen Parameter ein ref-Name deklariert wird. (Es gibt ja keinerlei übergreifende Festlegung in WP-Vorlagen, wie man Parameter benennt, aus denen ref-Attributen werden sollen.) Da habe ich es lieber, dass der Name „wiki-explizit“ in einem <ref name="Soundso">-Konstrukt auftritt, noch dazu vorne in der Zeile und in einer Spalte untereinander zusammen, indem ich inzwischen möglichst alle Referenzen in einem references-Block benannt anlege und im Artikeltext nur diese benannten Verweis-Refs. So ist alles auch weniger mit der Vorlage und ihren Mucken Vertrauten ganz durchsichtig.

Hinzu kommt noch ein Manko bei PRÄFIX/SUFFIX im Zusammenhang mit Weißraum. Vorlagen-Parameter werden vom Parser immer um Leerzeichen usw. am Anfang und Ende verkürzt, ehe sie in den Vorlagen-Substitutionsmechanismus eingespeist werden. Deshalb wird in Vorlagen gerne dort ein Leerzeichen ergänzt, wo es vom Vorlagenschreiber billig erwartet wird, um die ungeeignete Parser-Verkürzung wiedergutzumachen und es dem Vorlagenbenutzer einfacher zu machen. Aber manchmal sollte halt doch keines stehen. Das Problem kommt tief aus den Wiki-Eingeweiden, da wurde aus vermeintlicher Zuvorkommenheit (nämlich um der durchaus wünschenswerten Lesbarkeit der Parameter in der Vorlageneinbindung willen, vgl. die übliche Zeilenstruktur von Vorlage:Infobox Fluss) Murks gemacht, der dann an tausend Stellen geflickt wird, nur nicht da bereinigt, wo der Murks angerichtet wurde. Irgendjemand (doch vermutlich ein Informatiker!) hat halt irgendwie mit dieser Wikisyntax angefangen und kaum einen Gedanken auf das Problem von Metazeichen und ähnlichem verschwendet, und jetzt ist das durch fleißigen Gebrauch geheiligt und unabänderlich. Das alles ging also keineswegs gegen Dich, SteveK!

Auch das ein Grund, wieso ich PRÄFIX/SUFFIX in der Regel nicht mehr nutze. Wenn ich selbst etwas bastle, kann ich freier arbeiten und genauere Ergebnisse erzielen, sonst aber – wer weiß!--Silvicola ^Disk 15:41, 20. Okt. 2015 (CEST)

Hallo TOMM:

Tut mir leid wenn wir irgendwie aneinander vorbeigeredet haben. Im Artikel wurden zwei Nachweise mit {{GeoQuelle|DE-NI|GKJB-08}} angegeben. Die Vorlage:GeoQuelle macht daraus einen Link auf die entsprechende Seite im Internet, das geschieht in der Vorlage:GeoQuelle/Lang. Darin wurde die Vorlage:Internetquelle für die Formatierung verwendet. Durch meine Änderung in Vorlage:GeoQuelle/Lang (noch nicht alle Referenzen) habe ich Verwendung der Vorlage:Internetquelle durch direkten Quelltext ersetzt. Ist das was ich gemacht habe jetzt klarer?

--SteveK ?! 14:24, 20. Okt. 2015 (CEST)

Meine Rede: Was man selber händisch macht – hier Du in der Vorlage – kann man nämlich besser hinbekommen. Bei Abhängigkeit von Zwischenschichten dagegen – Einschränkungen und Wartungslawine bei Änderung dort. --Silvicola ^Disk 15:41, 20. Okt. 2015 (CEST)

@ Silvicola,

einiges von dem, was Du zu REF-NAME geschrieben hast, muss ich aufgrund von fehlenden Programmierkenntnissen wohl noch mehrmals lesen, um durchzusteigen. :-)

@ Steve,

das, was Du nun zu Vorlage:Internetquelle geschrieben hast, ist jetzt klarer, und ich habe es verstanden! Danke!
--TOMM (Diskussion) 16:11, 20. Okt. 2015 (CEST)

Entschuldige bitte, ich versuche es klarer auszudrücken.

Wenn Du Dir die üblichen Einbindungen der Flussinfobox anschaust, dann bekommt dort jedes Parameter-Wer-Paar eine eigene Zeile, es können hinten und vorne und auch vor und nach dem trennenden Gleichheitszeichen beliebig Leerzeichen und sonstiger Leerraum eingefüpgt werden weil das sonst ein unlesbarer Wust werden müsste:

{{Infobox Fluss|NAME=Wehre|ALTERNATIVNAME=Wohra<small>(im Oberlauf)</small>|SORTNAME=Wehre|LAGE=[[Werra-Meißner-Kreis]], [[Hessen]], [[Deutschland]]|GKZ=DE/418|FLUSSSYSTEM=Weser| ABFLUSSWEG=Werra//Weser//Nordsee|EINZUGSGEBIET=451.703|NACHWEIS-EINZUGSGEBIET= {{GeoQuelle|DE-HE|WRRL}}|LÄNGE= 36.4 … (genügt jetzt wohl) … |BILDBESCHREIBUNG=}}.

Diese Freiheit, mit Weißraum aufzufüttern, um auch nur annähernd so wie etwa in Programmiersprachen für den Quelltext eine leidlich freie Gliederung durch Weißraum zu erlauben, mit der allein so etwas lesbar wird, hat aber einen Preis: Die sozusagen „nur zum Auseinanderziehen“ eingefügten Leerzeichen und Zeilenumbrüche müssen vor der Verwendung der Parameterwerte wieder getilgt werden. Das macht der Parser, indem er schlankweg jeweils das längstmögliche Weißraumzeichen-Anfangsstück und -endstück wegschneidet vom „naiv“ genommenen Parameterwert – also etwa dem von ALTERNATIVNAME von hinter dem "=" bis zum nächsten "|". Dafür gibt es in wohl jeder Programmierbibliothek eine Funktion für Zeichenkettenargument, die meist trim genannt ist.

Im Unterschied zu Programmiersprachen aber, wo viele Werte Zahlen sind, deren „Gültigkeitsbreite“ am Ziffernaufbau leicht zu erkennen ist und worin andererseits die als Werte auftretende Zeichenfolgen für gewöhnlich quotiert sind, hat man es bei diesem Wikizeug mit unquotiertem Text zu tun, der für sich selbst stehen soll. Woher also soll man wissen, welche Leerzeichen etwa nur dastehen, um den Salat zu gliedern, und welche andererseits sozusagen „in echt gemeint“ sind?

In Programmiersprachen benutzt man für eine solche semantische Trennung von Funktionszeichen und gewöhnlichen Zeichen, die für sich selber stehen, sogenannte Metazeichen. Zum Beispiel kann man in einer Zeichenfolge auch das für die Quotierung in der Programmiersprache verwendete Quotierungszeichen, etwa „"“, stehen haben wollen. Die Fehlinterpretation vermeidet man etwa, indem man ein besonderes Escape-Zeichen definiert, das die Funktionsbedeutung aufhebt, oft „\“. Dann steht „"Das Zeichen \" wird zur Quotierung benutzt."“ für die Zeichenkette, die von nach dem ersten bis vor dem dritten „"“ reicht und die folgendes meint:

Das Zeichen " wird zur Quotierung benutzt.

und nicht etwa unmittelbar vor dem zweiten „"“ schon endet.

Das Problem, dass man unbedingt eine syntaktisch völlig klare, algorithmisch einfache Unterscheidungsmöglichkeit braucht, wann ein Zeichen für sich selbst stehen soll und wann in seiner Funktionsbedeutung (hier etwa bei „"“: begrenzt Zeichenketten), darauf stößt jeder, der zu programmieren beginnt, schon am ersten Tag oder in der ersten Woche.

Hier bei diesem Wikimurks fehlt etwa eine Möglichkeit zu sagen, „aber dieses Leerzeichen ist in echt gemeint“, damit es nicht vom Parameterwert-Parser weggeworfen wird. Die wurde aber glatt vergessen. (Es gibt auch andere technische Lösungsmöglichkeiten für das Problem, aber die muss man sich halt, weil es so tief unten steckt, von vorne herein gut überlegen.)

Die Folge ist dann, dass die Vorlagenprogrammierer an vielen Stellen zuvorkommend und standardmäßig wieder Leerzeichen einbauen. Zum Beispiel ist es die typische Verwendung von LÄNGE-PRÄFIX, ein „ca.“ oder ähnliches vor den Zahlwert zu pappen. Aber eben nicht zu dicht, also mit Leerzeichen dazwischen. Das deshalb in der Vorlageneinbindung, im Falle der LÄNGE-PRÄFIX-Parameter denn belegt wird, automatisch hinzugefügt wird. Aber manchmal, siehe das Deppen-Leerzeichen bei obigem Fußnotenbeispiel, ist das dann halt zuviel. Der Vorlagenbenutzer kann leider selber nicht steuern, ob da was kommen soll oder nicht. Man könnte zwar als Wert für das LÄNGE-PRÄFIX eben „ca. “ einzugeben versuchen – aber das Leerzeichen putzt ja der Parser schon weg, also keine Möglichkeit, da gezielt etwas einzuspeisen.

Diese Wikisprache ist wie die englische: Am Anfang ganz zugänglich und einfach und später ein wilder Verhau, durch den man nicht mehr durchschaut, weil keine Regeln mehr gelten, sondern alles ein übles Flickwerk vpn Konventionen und Üblichkeiten ist. Vor allem im Vorlagen-Bereich, siehe Hilfe:Vorlagen/Programmierung. Meine „liebste“ Konvention aber ist hier: Hilfe:Vorlagen/Programmierung#Bedingtes Einbinden von Quelltextblöcken aufgeführt. Wer zwei tags in ähnlichem Themenbereich, aber mit ganz anderer Funktion einmal onlyinclude und includeonly nennt, der muss doch mit dem Klammerbeutel gepudert gewesen sein, oder nicht? Jedenfalls ein großer Freund der mnemotechnischen Erleichterung …

--Silvicola ^Disk 17:33, 20. Okt. 2015 (CEST)

@ Silvicola,

Deine heutige Änderung im bereits oben von mir erwähnten Adenauer Bach kann ich bezüglich Steve's obiger Änderung in Vorlage:GeoQuelle/Lang bezüglich Verwendung der Vorlage:Internetquelle nicht nachvollziehen, auch wenn er noch nicht alle Referenzen geändert hat.
--TOMM (Diskussion) 17:24, 20. Okt. 2015 (CEST) bis --TOMM (Diskussion) 17:28, 20. Okt. 2015 (CEST)

Bei dem Beispiel oben mit der LUBW-Referenz doch ganz dasselbe. Vermutlich keine doppelte Einbindung zum selben Parametersatz mehr ohne rote Lache.--Silvicola ^Disk 17:33, 20. Okt. 2015 (CEST)

@ Silvicola,

Danke für die vielen Infos, die Du (auch etwas weiter oben; ab Entschuldige bitte, ich versuche es klarer auszudrücken) geschrieben hast. Das werde ich wohl Morgen mal in Ruhe studieren; denn für heute gilt: Referenz-Diskussions-Genug!
--TOMM (Diskussion) 19:09, 20. Okt. 2015 (CEST)

Das was Silvicola da anschneidet ist soweit alles richtig. Bei der Vorlagenprogrammierung wird es dann auch noch ganz unübersichtlich, denn es werden zahlreiche geschweifte Klammern "{}" verwendet um die Konstrukte zu bilden. Das führt dann zu einen sehr unübersichtlichen Code, weil man nicht wirklich weiß, ob ein Zeilenumbruch durch den Parser im Ausgabetext verwendet wird oder eben nicht. Genauso ist es auch mit den Leerstellen. Im Grunde zeigt das Beispiel (Referenz "³" unten), eine Problematik auf, die aber unabhängig von der Problematik immer auftritt: Ein Anwender kann die Dinge anders verwenden wie vorgesehen (zur Not schlage ich auch einen Nagel mit der Rohrzange in die Wand). Vorgesehen war es, dass das SUFFIX als Text angehängt wird ohne dass der Vortext abzuschließen ist, weshalb bei der Verwendung ein " " eingefügt wird, was ja wegen dem Parser auch so nicht übergeben werden kann. Der Fehler liegt hier im fehlenden Abschluss der Referenz als Vortext. Und hier habe ich nun ein Problem: Wenn ich einen "." dort einfüge, dann stehen dort "…(Hinweise). . Hier soll…". Bei einer Änderung müsste man also die entsprechende Referenz prüfen, wo sie verwendet wird und entsprechend korrigieren. Dazu habe ich aber keine Lösung. --SteveK ?! 10:13, 21. Okt. 2015 (CEST)

Ich war oben selbst versucht, das Thema geschweifte Klammern auch noch zu erwähnen, habe es aber gelassen, weil mir dabei wohl doch noch die Galle hochgekommen wäre. Doppelte Klammern für Vorlageneeinbindungen, dann noch dreifache für Parameter-/Variablenreferenzen, dann noch weitere Klammern, um noch ein paar zunächst wohl übersehene, aber zuweilen in Wikitext verwendete Sonderzeichen benutzen zu können, darunter so entsetzlich seltene wie | in Tabellensyntax. Und das alles typischerweise in Verwendungen, wo diese Klammern dann aneinanderstoßen – Himmel hilf und schenke uns Wiki-Spezialbrillen! --Silvicola ^Disk 14:05, 21. Okt. 2015 (CEST)

Ich habe es, wie oben angekündigt, jetzt studiert.

Viel weiter gebracht hat es mich zwar nicht (und das muss es auch nicht), weil mich zu wenig mit der „Referenzierung-Und-Parser GmbH & Co. KG“ beschäftigt habe. Ich habe tatsächlich auch nicht vor, solches zu tun.

Aber: Danke für Eure Infos!
--TOMM (Diskussion) 15:05, 21. Okt. 2015 (CEST)

Wir sollten die Diskussion hier dann auch beenden, denn mit dem Artikel hat sie nicht wirklich mehr etwas zu tun. Und für die Verschlimmbesserung der Vorlagen gibt es andere Diskussionsseiten, die geeigneter sind. --SteveK ?! 15:19, 21. Okt. 2015 (CEST)

Ja, das hatte ich am gestrigen Vormittag mit obigem auslagern bereits vorgeschlagen! :-)

Daher: Ende! --TOMM (Diskussion) 15:30, 21. Okt. 2015 (CEST)

Einzelnachweise (zum Diskussionsthema ‎Einzelnachweise – Referenzfehler)

Einzugsgebiet

Danke, Silvicola, für diese Änderung.
Seltsam: Es geistern komischerweise immer noch alte EZG-Varianten in der Wikipedia herum, obwohl wir im Sommer 2015 gruppendynamisch von Einzugsgebiet (Hydrologie) auf Einzugsgebiet (usw.) umgelinkt haben.
Ein paar solcher Nachträglich-Zu-Ändern-Fälle habe (wohl u. a.) auch ich bereits korrigiert.
Ist hierfür eine Serverträgheit verantwortlich?
--TOMM (Diskussion) 10:35, 20. Okt. 2015 (CEST)

Also die verlinkte Änderung von mir geschah wohl durchaus im Rahmen der Aktion, nämlich Ende Juli/Anfang August.

An Geister bin ich bisher noch nicht geraten. Aber es könnte natürlich sein, dass Schreiber noch eigene Privatvorlagen außerhalb der WP halten und für Neuartikel benutzen. Benutzung überalterter Vorlage stellt man oft fest und ist mir auch schon unterlaufen. Vielleicht sollte man den Bearbeitungkommentar bei jeder Änderung von Vorlage:Infobox Fluss, die den Parametersatz ändert, mit !*@*! HAB IHR'S AUCH ALLE GESEHEN? PARAMETERÄNDERUNG !*@*! einleiten … oder so. Die „Schläfer“, die nicht wenigstens wöchentlich hier hereinschauen, erreicht man aber auch so nicht. Man sollte sie ggf. persönlich ansprechen, wenn man eine alte Verwendung sieht. --Silvicola ^Disk 16:02, 20. Okt. 2015 (CEST)

Huch,

im hiesigen/obigen Referenzfehler-Trubel habe ich nicht gesehen, dass Deine EZG-Änderung bereits am 1. August 2015‎ stattgefunden hat; ich dachte das war auch gestern, direkt vor Deiner Referenz-Änderung.

Trotzdem Danke! :-)

Ja, ein Parameteränderungshinweis kann bedingt sinnvoll sein, denn viele Schläfer (wie Du sie oben genannt hast), die also nur hin und wieder editieren, wissen wohl nicht, was ein Parameter ist.

Daher habe ich bei EZG-Link-Fix/en immer geschrieben: Link-Fix/e "Einzugsgebiet", nachdem dieses Lemma statt "Einzugsgebiet (Hydrologie)" zur Hauptbedeutung wurde! Meines Erachtens ist das ausreichend.

Wer es dann noch nicht verstanden hat, dem ist wohl (vorerst) nicht zu helfen. :-)

Es geht bei meinen oben erwähnten herumgeisternden EZG-Varianten auch eher um EZG-Altlasten:

Es waren wohl 2 oder 3 Fälle, die ich nach Ende unserer EZG-Link-Fix-Aktion (Finale am 3. August 2015) noch geändert habe (im Rahmen anderer Bearbeitungen)! Ich bin gespannt ob noch weitere Fälle auftauchen!
--TOMM (Diskussion) 16:47, 20. Okt. 2015 (CEST)

Ach, nett was ihr hier Diskutiert. Wenn man im Template-Tiger die verwendeten Parameter anschaut (leider nicht immer aktuell), dann sieht man auch, dass es einiges an Schreibfehlern zu korrigieren gilt. So tauchen immer wieder auch Parameter auf, die es nicht gibt. Das ist aber kein Problem dieses Artikels. --SteveK ?! 11:25, 21. Okt. 2015 (CEST)

Hihihi,

ja auf Schreibfehler innerhalb der Wörter Einzelnachweise und Hydrologie sind z. B. Silvicola und ich bei unserer gruppendynamischen Umlinkungs-Aktion im vergangenen Sommer mehrmals gestoßen.

Derartige fallen/fielen dann leider aus den Umlinkungs-Mustern.
--TOMM (Diskussion) 15:05, 21. Okt. 2015 (CEST)