Vorlage Diskussion:Infobox Fluss/Archiv/4

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Vorlage Diskussion:Infobox Fluss/Archiv/4#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Vorlage_Diskussion:Infobox_Fluss/Archiv/4#Thema_1

Großstädte, Mittelstädte, Kleinstädte, Gemeinden zu Orte am Lauf zusammenfassen

Die Aufschlüsselung der Anliegergemeinden in die verschiedenen Gemeindeklassen erscheint mir unsinnig. Kleinere Gewässer verlaufen oft vollständig innerhalb so einer Einheit, es wäre dann eine Auflistung der durchflossenen Teilorte sinnvoller. Bei längeren wird man, wenn man nicht die Tabelle sprengen will, gewöhnlich ohnehin nur die höheren Gemeindeklassenparameter befüllen, mit nur seltenen Ausnahmen, wenn etwa ein kleinerer Ort durch Sonderumstände für den Fluss wichtig ist. Vielleicht also bei der Donau allenfalls auch Donaueschingen neben den größeren Städten Ulm, Regensburg, Passau oder sogar Wien, Budapest usw.

Im Grunde kann es doch bei einem Gewässer nur darum gehen, ein halbes bis allenfalls ein Dutzend für das spezifische Gewässer wichtige Orte und Siedlungsplätze zu nennen, und die dann bitte schön auch konsequent talabwärts; die Teilsortierung in die Gemeindeklassen zerstört leider diese für Verständnis hilfreiche Ordnung. Mancher ist dann sogar versucht, in den Teilparametern dummerweise alphabetisch zu sortieren, was nun gar nichts bringt. Ein eigener Artikelabschnitt zu den Orten am Lauf ist zwar wünschenswert und wäre ohnehin die beste Lösung, wird aber wohl lange für viele Artikel ein bloßer Wunsch bleiben, zumal im Artikeltext oft nur Quell- und Mündungsort genannt werden. Desto wichtiger, dass die oder der in der Box benutzte Parameter für Gemeinden/Orte nicht falsch interpretiert werden, auf die sich der Leser dann behelfsweise allein stützen kann.

Schon dass die derzeit vier Parameternamen missbräuchlich Gemeindenklassennamen tragen, also die Namen administrativer/raumplanerischer Gliederungseinheiten, führt auf Abwege – wer liest schon die Dokumentation, wo das zwar steht, womit man aber sozusagen trotzdem gegen die etablierte Bedeutung uminterpretiert: „Gemeint ist die Ortschaft, nicht die Gemarkung.“ Wieso keine ehrlichen Parameternamen? Anliegergemeinden können nämlich auch angrenzen oder durchflossen werden, ohne irgend einen Ort am Lauf zu haben. Trotzdem werden sie dann oft – vermutlich mechanisch wegen dieser falschen Semantik der Parameternamen – aufgeführt, was dann das Missverständnis bei Lesern befördert, der namengebende Hauptort selbst läge (auch) am Lauf.

Ich schlage deshalb vor, statt der bisher vier Parameter GROSSSTÄDTE, MITTELSTÄDTE, KLEINSTÄDTE und GEMEINDEN einen einzigen Parameter ORTE-AM-LAUF einzuführen, der dann auch gleich jedem Beiträger völlig klarmacht, dass es hier nicht um bloße Gebiets-Anliegerschaft geht, sondern nur Orte am Lauf hinein sollen. Die Altparameter sollte man in der Infobox-Dokumentation deutlich als veraltend auszeichnen, entsprechende Name-Wert-Paare sollten im Zuge sonstiger Nachbesserungen nach und nach auf den Neuparameter talwärts sortiert zusammengefasst und danach gelöscht werden. Sicher ein Projekt auf Jahre, aber wenn in Neuartikeln das schon mal richtig gemacht wird, ist schon viel gewonnen. Dass die Zahl der Box-Parameter dadurch auch einmal wieder kleiner wird, ist sicher kein Nachteil.

Übrigens, wer unbedingt das Größenklassenannoncement für die Gemeinden, zu denen die Anliegerorte gehören, in der Box halten will, kann das mit Fußnoten annotieren oder – mit übersichtlicherem Bezug – per Nah-Fußnote (Vorlage:FN), grob unter Missbrauch der GEMEINDEN etwa so:

Dingsdafluss
Daten
Gemeinden	A-heimdgS, B-ingenwgS, C-stattm, D-dorfk, E-bachzmF, … dgS Dorf der Großstadt Stuttgart wgS Weiler von Stuttgart m Mittelstadt k Kleinstadt zmF Zinken der Mittelstadt Freudenstadt

oder (wahrscheinlicher) weniger aufgebrezelt. Wer aber schon so genau wie hier aufschlüsseln will, wird ohnehin in der Regel einen eigenen Abschnitt zu den Anliegerorten schreiben oder die Orte passend im Verlauf einflechten. --Silvicola ^Disk 04:42, 30. Mär. 2016 (CEST)

Wie oft habe ich dergleichen eigentlich schon vorgeschlagen?

Hauptargument ist, daß wir nur so die Reihenfolge darstellen. Bei Fulda (Fluss) weiß man überhaupt nicht, ob Kassel früh oder spät durchflossen wird - denkbar wäre theoretisch sogar vor Gersfeld.

Daß da auch noch ein Intelligenzbolzen die "Mittelstädte" alphabetisch sortiert hat, sodaß man meint, der Fluß fließe erst von Hersfeld nach Fulda und dann von dort nach Hann. Münden, lasse ich mal außen vor.

Wir brauchen aber unbedingt ein Feld "Kriterium". Da stünde dann u. U. "ab 10.000 EW" oder "Orte mit Stadtrecht". Haben wir das nicht, dann trägt ständig irgendein Pfosten sein Heimatdorf am Rhein ein.

Übrinx ist D-Dorf keine Kleinstadt, sondern eine Halbmillionenstadt! Kann jemand aus dem Süden natürlich nicht wissen ... Aber diese Fußnoten waren ja wohl eh als Scherz gedacht. --Elop 12:14, 30. Mär. 2016 (CEST)

Die Unterteilung nach Größe habe ich nie verstanden, zumal diese Begriffe in Österreich wenig verwendet werden und "Mittelstadt" völlig ungebräuchlich ist. Ich gebe aber zu, dass ich bei "Gemeinden" wider besseres Wissen tatsächlich die Gemeinde hineinschreibe (sonst müsste es ja "Ort" o.ä. heißen), das halte ich für eine wichtige Information. Der Großteil der Fließgewässer im alpinen Raum berührt weit und breit keine Ansiedlung, schon gar nicht eine mit Stadtrecht oder mehr als 10.000 Einwohnern. Ein festes Kriterium für alle Gewässer, vom Gebirgsbach bis zum Strom kann nicht funktionieren. Fußnoten halte ich für überflüssig, die Orte sollten ja verlinkt sein, so dass man bei Bedarf mehr erfahren kann. --Luftschiffhafen (Diskussion) 12:26, 30. Mär. 2016 (CEST)

Natürlich kann ein festes Kriterium nicht funzen. Deshalb soll ja ein Feld rein, das das "individuelle" Kriterium des Gewässers benennt, sodaß man unter einem Dutzend bleibt. Beim Rhein eher nicht alle Orte ab 10.000, bei kleineren Bächen aber u. U. jeder Weiler. --Elop 12:35, 30. Mär. 2016 (CEST)

Oder sogar nur die drei Mühlen ohne Ortsteilstatus, die allein am Lauf liegen. --Silvicola ^Disk 12:45, 30. Mär. 2016 (CEST)

„Ein festes Kriterium für alle Gewässer, vom Gebirgsbach bis zum Strom kann nicht funktionieren.“ – Stimmt, umso befremdlicher ist es, eines eingebaut vorzufinden, dass sich am ziemlich gewässerfremden Administrativzuschnitt orientiert – zwar leicht eruierbar, aber gar nicht einschlägig. --Silvicola ^Disk 12:42, 30. Mär. 2016 (CEST)

„Wir brauchen aber unbedingt ein Feld "Kriterium".“ – Dessen Inhalt dann in die Titelspalte geschrieben wird, ähnlich wie derzeit bei BEZEICHNUNG-QUELLE, BEZEICHNUNG-MÜNDUNG. Wenn nicht definiert, steht doch nur „Orte am Lauf“. Lokalpatrioten den zu unbeherrschten Willen zu nehmen ist sinnvoll. --Silvicola ^Disk 12:42, 30. Mär. 2016 (CEST)

Typographie

In dieser Untervorlage sollte die Typographie angepaßt werden. ² und ³ sehen nicht nur häßlich aus, sondern sind auch typographisch falsch, bitte durch ² und ³ (² und ³) ersetzen. --Matthiasb – ^{(CallMyCenter)} 12:53, 10. Feb. 2016 (CET)

Über schön oder hässlich kann man sicher streiten – doch wo ist die behauptete typographische Regel nachzulesen? Ggf. sollte man das auch unter Wikipedia:Typografie vorfinden, wo ich aber nichts dazu gefunden habe. --Silvicola ^Disk 05:01, 30. Mär. 2016 (CEST)

Die sup-Form soll für Zehnerpotenzen angewandt werden, denn da ist sie die wichtigere Zahl (und da ist die Verwendung der kleineren Hochziffern falsch). Bei Flächen und Volumen ist die größere Darstellung aber unüblich. Also:

• 10.546 km²
• 6,023·10²³

--Elop 12:03, 30. Mär. 2016 (CEST)

Das war soviel ich noch weiß eine Frage des Zeilenabstandes, was es heute nicht mehr ist. Es gibt aber mMn keinen Grund für eine Änderung (siehe Elop).--SteveK ?! 15:55, 30. Mär. 2016 (CEST)

Flussverläufe integrieren

Ich habe das schon in der Vorlagen/Werkstatt eingebracht, aber vielleicht ist hier eine Diskussion besser aufgehoben. Nun zur Sache: Ich habe vor Kurzem einen Artikel über den Rottenbach geschrieben und würde nun gerne den Verlauf angemessen darstellen. Wäre es möglich die Vorlage:Infobox Fluss um eine Flussverlaufstabelle zu erweitern? Also wie die BS-Tabelle in der Vorlage:Infobox Schifffahrtskanal. Für Flussverläufe steht Vorlage:Fluss-Header etc. ja schon zur Verfügung. Wäre schön, wenn diese in der Vorlage: Infobox Fluss integriert werden könnte, damit das nicht so aussehen muss wie im Artikel Aare. --Infokoordinator (Diskussion) 23:19, 29. Mär. 2016 (CEST)

Ich wurde mit diesen Tabellen nie warm. Wenn sie erschöpfend sind, brauchen sie sehr viel Platz. Die Einträge sind mal kurz, mal lang benannt, entsprechend gibt es eng beschriebene und leere Partien darin. Alles in allem kann man mit freierem Text besser darstellen, ohne den künstlichen Zwang, mit gelegentlich auch einmal besonders langen Einträgen dann doch ja nicht die Tabellenstuktur zu sprengen. --Silvicola ^Disk 00:54, 30. Mär. 2016 (CEST)

Diese Form der detailierten Darstellung von Flussläufen ist in der englischen Wiki verbreitet, dort ersetzt sie aber Dinge, die wir in unserer IB haben, nämlich die Angaben für Nebenflüsse und die Ortschaften am Fluss. Was wäre also der Mehrwert einer solchen Tabelle? Man könnte noch die Straßen oder Eisenbahnlinien auflisten, die kreuzen. Eine vollständig ausgeführte Liste kann sehr lang werden und dann stellt sich die Frage nach der Verhältnismäßigkeit von Text und Tabelle bzw. was muss ich denn noch schreiben, wenn ich alles in die Tabelle packe. Ich finde einen gut und gerne auch detaillierten Text zum Verlauf besser als eine bunte Tabelle, vor allem, weil ein Fluss kein Kanal ist, der oft nur in gerader Linie verläuft und wo man entsprechend wenig über den Verlauf sagen kann oder muss. Mehr "Landkarten" (siehe z.B. Themse) wären da hingegen eine wirkliche Hilfe für den Leser.--Drgkl (Diskussion) 02:28, 30. Mär. 2016 (CEST)

+1. Anders als bei Straßen, Bahnstrecken oder Kanälen kann ich mich mit einer geraden Linie für einen (oftmals gewundenen) Flusslauf einfach nicht anfreunden. Ich sehe auch keinen Mehrwert, stattdessen die Frage, was dargestellt werden soll. Ohnehin nimmt die Beschreibung des Verlaufs (den man ja einer Karte entnehmen kann) für meinen Geschmack in vielen Fließgewässerartikeln gegenüber anderen Aspekten wie Hydrologie, Ökologie, Etymologie etc. bereits einen recht großen Raum ein. Eine Karte des Verlaufs, oder besser, des gesamten Einzugsgebiets ist hingegen in der Tat ein echter Mehrwert. Die Themse scheint mir da allerdings nicht das beste Beispiel zu sein, eher Inn, Lech oder Donau. --Luftschiffhafen (Diskussion) 12:36, 30. Mär. 2016 (CEST)

Wie Silvicola bin ich mit den Tabellen nicht warm geworden. Die Flussverläufe wurden von einem Projekt initiiert und für ihren Bereich in Flussartikel eingebaut. Wie das bei längeren Flüssen aussehen tut konnte man am Beispiel Wupper ansehen. In der aktuellen Version wurde die Tabelle aber mittlerweile entfernt. Das jetzt auch noch in die IB zu integrieren lehne ich ab. --SteveK ?! 16:05, 30. Mär. 2016 (CEST)

Automatische Kategorisierung, wieder

@Herzi Pinki: Jetzt ist genau das passiert, worauf ich vor einigen Wochen (auf PD:Frankreich) als unerwünscht hingewiesen habe, daß nämlich Massenkategorisierer Kategorie:Fluss in England unterteilt haben nach Grafschaften (etwa Kategorie:Fluss in Cumbria) und darin sogar nach Distrikten. Bitte sei so nett, und modifiziere die automatische Kategorisierung so, daß nur noch nach Staaten und der 1. Ebene in einem Staat kategorisiert wird. Das betrifft übrigens alle Infoboxen für geographische Objekte, nicht nur die zuFlüssen. --Matthiasb – ^{(CallMyCenter)} 10:26, 5. Aug. 2016 (CEST)

@Matthiasb: Es ist die Existenz der Kategorie. Kategorie da, Flüssen werden gemäß ISO-Code hineinkategorisiert, Kategorie existiert nicht, Flüsse werden in die hierarchisch nächste Kat hineinkategorisiert. Wenn man eine Kategorie Kategorie:Fluss in Cumbria nicht will, dann muss man sie löschen lassen. lg --Herzi Pinki (Diskussion) 11:36, 5. Aug. 2016 (CEST)

Ja, das ist mir bekannt. Kann man das nicht so umbauen, daß die 2. Ebene gar nicht berücksichtigt wird? Die Ortsinfoboxen haben doch nach Ländern individuelle Infoboxen; da wird doch die Kategorisierung individuell geregelt. --Matthiasb – ^{(CallMyCenter)} 12:21, 5. Aug. 2016 (CEST)

Man könnte. Aber man würde den Kontrakt brechen. Allg. Geo-Objekte wie Flüsse, Berge etc. haben keine nach Ländern individuelle Regelung der Kategorien, außer über die Existenz (du musst mich da überzeugen, dass das nicht elegant ist!). Wenn es eine Kategorie Kategorie:Fluss in Cumbria gibt, dann gehören wohl alle Flüsse in Cumbria da hinein, egal ob nur lokal oder die ganze Insel von N nach S durchziehend. Der Unterschied ergibt sich wohl aus der Tatsache, dass in UK der ISO-Code dreistufig ist (wie auch in CZ), in AT, DE, CH nur zweistufig. Wenn man jetzt sagt, bei Flüssen ist bei Ebene 1 Schluss mit lustiger Autokategorisierung (so würde ich das machen), d.h. country & adm1st, dann sollte es Kategorien auf Stufe 2 nicht geben, da damit Doppelkategorien eingeführt werden würden. Man müsste also auch in diesem Fall die Kategorien der Stufe 2 löschen, da ansonsten Durcheinander entsteht. Der Vorteil der einheitlichen Kategorisierung wäre weg. In dieser Kombination (autokat bis Stufe 1, keine Kat nach Stufe 2) wäre das wieder einheitlich, aber wohl noch durchzusetzen.

Ich gebe allerdings zu, dass bei langen Objekten wie Flüssen die Autokategorisierung vielleicht nicht der Weisheit letzter Schluss ist, da bloß Anfangs- und Endpunkt entsprechend behandelt werden. lg --Herzi Pinki (Diskussion) 22:02, 5. Aug. 2016 (CEST)

Kopiervorlage und anderes

Sie sollte nicht verhackstückt werden, sondern mit einer Selektion anwählbar sein. Sonst unnötige Mühe für die Kopierenden. Der Beschreibungstext, der derzeit zwischengeschoben ist, sollte wohl eher in die Parameterbeschreibungen eingehen.

Und der Beschreibungstext sollte nicht so quietschbunt ausfallen wie derzeit. Das ist sonst nirgends üblich. --Silvicola ^Disk 21:04, 3. Jan. 2017 (CET)

Da hast du wohl Recht. Wenn du dir meine Disk anschaust, dann wirst du lesen können was der Benutzer noch so für Wünsche äußert. Ich habe derzeit nicht wirklich Interesse daran, Änderungen hier einzupflegen. --SteveK ?! 11:49, 4. Jan. 2017 (CET)

Es ginge da wohl manchmal eher ums Auspflegen …

Welcher Fluss wohl mehr als 10 GKZs braucht? – Ach natürlich, vielleicht (irgendwann mal) die Donau oder vielleicht auch etwa die Tauber, nämlich unter Berücksichtigung aller reichsritterschaftlichen und hohenlohisch-teilherrschaftlichen Sonder-GKZs für den dringlichen historischen Ausbau des Systems und dazu bitte unbedingt auch noch mit purpurnen Lettern für die kirchlichen Herrschaften, kardinalsroten für die päpstlichen (Tiber an der Engelsburg, Rhône durch Avignon!), grünen für die Mauren und schwarzen bitte nur für den Aztekenstaat. (Wer dächte hierbei nicht an Obsidianmesser?). Dafür sollte man wirklich zeitig Sorge tragen … Und dann: Once programmed, twice used. --Silvicola ^Disk 21:07, 4. Jan. 2017 (CET)

Gewässerkennzahl für UK

Bitte auch für UK die Gewässerkennzahl implementieren. Begründung: siehe Baldon Brook und Quellensammlung.--Anarabert (Diskussion) 16:19, 26. Jan. 2017 (CET)

erledigtErledigt--Anarabert (Diskussion) 13:38, 29. Jan. 2017 (CET)

Veraltete Parameter

Die obige Frage beantworte ich mal hier. Es gibt eine Spezialseite, die IB-Einbindungen mit veralteten Parametern listet:

https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/Vorlage:Infobox_Fluss/Veraltet&limit=5000&from=0

Stand ist >5000 Einbindungen. Wobei da auch andere Parameter mit drin sind. --SteveK ?! 19:14, 9. Feb. 2017 (CET)

@Ulamm: Siehst Du Ulamm, das Auspflegen des veralteten Paramatersatzes wurde vor vielleicht einem Jahr angeleiert und ist erst so weit gediehen. Wenn man in zu dichter Folge Änderungen folgen lässt, kommt man gar nicht mehr nach mit dem aktualisieren. Das ist der Effekt einer Springflut, in welcher man bekanntlich leicht ersäuft. --Silvicola ^Disk 21:40, 9. Feb. 2017 (CET)

Mehrere Quell- und Mündungsstellen

Es fehlt noch die Möglichkeit, mehrere Quellen (und evt. deren Zusammenfluss) und mehrere Mündungen zu berücksichtigen.

Da die Anzeige mehrerer Höhendifferenzen samt deren Spezifikation die Tabelle aufblähen würde, ist zu überlegen, ob man dann die Höhendifferenz ganz weglässt, oder ob man bei der Eingabe die Quelle und die Mündung zu markieren hat, die für die Berechnung der Differenz herangezogen werden sollen.

Automatisch die erste Quelle und die letzt Mündung halte ich nicht für sinnvoll. Ob man beispielsweise die hydrografisch definierte Hauptquelle oder die touristisch aufgemotzte Quelle oder einen Zusammenfluss berücksichtigen sollte, mag von Fall zu Fall verschieden sein. Sofern es auch nennenswert verschiedene Mündungshöhen gibt, sollte der Artikelautor die Möglichkeit haben, die Reihenfolge nach der Geografie zu wählen (erst der kürzere, dann der längere Mündungsarm), die Berücksichtigung für die Höhendifferenz aber nach anderen Gesichtspunkten.

Im Zweifel die Höhendifferenz ganz weglassen. Für die Gestalt von 95 % des Flusslaufs ist zumeist nicht die Quellhöhe relevant, sondern die Höhe nach den ersten 5 %, die sehr viel niedriger sein kann als die Quellhöhe.--Ulamm (Diskussion) 11:25, 9. Feb. 2017 (CET)

Die Idee einen geordneten Weg für die Problematik von mehren Quellen und Mündungen zu finden ist richtig.

Es müßte nur ein Weg gefunden werden, dies ohne technische Kunststücke ala

''<br />..................................................<br />Hamelquelle in [[Hamelspringe]]: <br /><small>{{Coordinate|NS=52.19549120|EW=9.408110970|type=waterbody|region=DE-NI|text= 52° 11′ 43,77″ N, 9° 24′ 29,2″ O|name=Hamelquelle im Dorf}}</small><br />170 m ü. NHN''

zu erreichen. Solche Kunststücke waren auch bisher schon möglich.--Anarabert (Diskussion) 13:07, 9. Feb. 2017 (CET)

Meine Ansicht ist es schon lange, dass QUELLE, QUELLHÖHE, QUELLE_LAT_GRAD et tutti quanti zu einer Untervorlage zusammengebündelt sein sollten, von denen man dann (im Prinzip, bitte aber nicht aus Prinzip) viele in einem schieren Wiederholungsfeld hintereinander platzieren können sollte. Ich stoße auf das Problem immer wieder, typischerweise bei den Gewässern mit andersnamigem Oberlauf, der landesamtlich schlankweg zum mit dem Namen des Unterlaufs bezeichneten Strang geschlagen ist. Man sollte in solchem Fall das Bild nach den üblichen Namensabschnitten wiedergeben, damit der Leser sich anhand der vertrauten Bezeichnungen zurechtfindet, für das in höherer Perspektive wichtigere Strangbild ist aber nicht der Ursprung des Unterlaufabschnitts, sondern die höchste Quelle repräsentativer.
Mit einer solchen Umbündelung ersparte man sich die fürchterliche Layoutbastelei wie derzeit im Mehrquellenfall. Analog für Mündungen, wobei das dort wohl viel seltener genutzt werden dürfte. Die derzeitige Methode erfordert, für genau eine Quelle die Bestimmungsstücke in Parameterwerte direkt der Vorlage:Infobox Fluss auseinanderzureißen und die der anderen, selbst (u.a. mithilfe der Untervorlage zur Höhe) zusammenzubasteln. Das ist begrifflich reichlich verquer, wie man bemerkt, wenn man einmal die bisherige vorrangige Quelle nachrangig und die bisherige nachrangige vorrangig machen will.

Entsprechende Varianten zur Länge mindestens zu Namenslauf/Gesamtstranglauf entsprechend.

Für die Notwendigkeit beider Perspektiven (Namenslaufbild + Strangbild) siehe etwa den Laxbach (Neckar).

Nachteile einer Änderung:

1. Die Höhendifferenz wäre nicht mehr automatisch errechenbar, da seine zwei Bestimmungsstücke nicht mehr aus einem Parameter der Vorlage selbst zu greifen ist. Eine Differenz zu errechnen traue ich mir allerdings zu. Wie hier das allgemeine Bild ist, kann ich nicht beurteilen. Ich vermute, der derzeitig Automatismus wurde mit starkem Motiv eingeführt.

2. Eine weitere Untervorlage muss natürlich vom Bearbeiter erst einmal verstanden werden, und Vertrautheit stellt sich auch danach nicht gleich ein.

3. Was geschieht dabei mit dem Altbestand? Die Aussicht, in über 10.000 Boxen manuell warten zu müssen, ist reichlich erschreckend. Deshalb wollte ich die von mir als prinzipiell sinnvoll angesehene Änderung auch nicht forciert befürworten wollen. Illustrierende Frage an @SteveK:: wieviele Altparameter aus der Zeit vor PEGEL1/PEGEL1-REIHE/NACHWEIS-PEGEL1 liegen wohl jetzt noch noch im Bestand? Ich ersetze immer wieder en passant welche, ohne dabei den Eindruck zu haben, die würden wirklich etwas weniger. Zum Glück meisten unbenutzte, denn das Umbasteln der Befüllten ist fehlerträchtig und kostet deshalb viele Achtsamkeit. Das wäre hier genauso.

@Ulamm: Wenn Du nicht auf Anhieb verstehst, wovon die Ausführungen zu PEGEL1 eben handeln, dann sollte Dir das zeigen, dass Du in dieser Sache ein zu geringes Problembewusstsein hast. Mache bitte den Transfer!

@Ulamm: Wenn Du unbedingt eine horizontale Trennlinie in einem Vorlagenfeld brauchst, schau Dir im Parameter LAGE des Artikels Bühler (Fluss) an, wie das mit Wiki-Bordmitteln geht. Händisches Gebastel ist jedenfalls nicht gut. Hier geht es natürlich weniger um diesen eher technischen Punkt. Aber wenn es da schon hakt, dann sollte man die eigenen selbstgewissen missionarischen Bestrebungen doch vielleicht etwas zügeln, und jedenfalls nicht oktroyieren, was einem gerade in Ansehung nur eines Aspektes sinnvoll scheint.

--Silvicola ^Disk 15:21, 9. Feb. 2017 (CET)

Wenn mehrere Quellorte eingetragen werden, braucht man am wenigsten erklärenden Text (der die Infobox unnötig aufbläht), wenn die Höhe einer jeden Quelle ohne Trennlinie unter ihren Koordinaten steht, aber die Quellorte durch Trennlinien voneinander geschieden werden.

Am händischen Gebastel hast du dich bei der Ourthe auch selber beteiligt.

Mit ordentlicher Eingabemöglichkeit für mehrere Quellorte hatte meine Beta-Versoin noch einen Bug. darum sind jetzt die beiden Quellorte improvisiert eingegben und nur die beiden Mündungsstelle professionell.

Nicht meine Erstellung einer Beta-Version der Infobox ist ein Aufoktroyieren, sondern Eure Versuche sie zu beseitgen.--Ulamm (Diskussion) 15:47, 9. Feb. 2017 (CET)

VOR- oder NACHRANGIGKEIT von QUELLEN:

Allgemein: Die hydrografische Erfassung des Gewässernetzes ist notwenigerweise das Werk vieler Mitarbeiter von mindestens 15 verschiedenen Behörden. Da ist es normal, dass nicht bei allen Gewässern gleichartig entschieden wurde.

Speziell: Im Fall der Hamel ist es nach Vergleich verschiedener Karten und Orthofotos ist es möglich, dass die nominelle Hamelquelle gar keine echte Quelle im Sinne von Austrittsstelle ist, sondern nur ein Auffangbecken kurz nach dem Zusammenfluss der Sickerhamel und des (möglicherweise nur kurz nach Niederschlägen wasserführenden) Wasserlaufs aus dem Bärengrund.--Ulamm (Diskussion) 15:57, 9. Feb. 2017 (CET)

@Ourthe. Erster Edit von mir erst gerade, um einen potthässlichen Umbruch in einer Koordinatenangabe zu beseitigen. Dort gäbe es übrigens noch mehr zu verbessern: Alternative Quellhöhen sowie die dargestellte Addition bei der Länge ließen sich mit Untervorlagen den Flussbox viel eleganter darstellen.

@Vor- und Nachrangigkeit: Ich meinte nichts Offizielles, sondern die implizite Vor- und Nachrangigkeit hier bei uns dadurch, dass die Höhe der einen, in der Infobox per Teilparameter „auseinandergezogenen“ Quelle für die Höhendifferenz herangezogen wird.

@„Wahre Quelle der Hamel“: Du beschreibst ein Datenerwerbsproblem, das hat mit der hier diskutieretn Frage überhaupt nichts zu tun. --Silvicola ^Disk 16:34, 9. Feb. 2017 (CET)

Um gewaltigen Wartungsaufwand zu vermeiden, müßte eine Änderung erfolgen, welche bei dem Normalfalle keine Nachbearbeitung nötig machen würde, sondern Änderungen nur bei den Fällen erforderlich wären, welche mehrere Quellen (und Mündungen) besitzen und z.Z nur mittels Tricks gestaltet werden können.

@Ulamm, bitte diskutiere zur Sache

--Anarabert (Diskussion) 16:00, 9. Feb. 2017 (CET)

Ich sehe leider keinen einfachen Weg. Deshalb auch mein nur zurückhaltendes Anraten. --Silvicola ^Disk 16:34, 9. Feb. 2017 (CET)

ALTBESTAND UND NEUEINTRÄGE:

Nach dem, was ich bisher leider nur mit Teilerfolg versucht habe, ist es technisch kein Problem, eine Infobox zu programmieren, die aus dem Altbestand an Einträgen weiterhin eine verständliche Darstellung macht (möglichst dieselbe oder fast dieselbe wie bisher) und gleichzeitig besser für Spezialfälle geeignet ist. Allerdings sollte die Gliederung des Eingabeformulars in der Weise verbessert werden, dass die Daten etwa in der Reihenfolge einzugeben sind, in der sie dann auch in der Box erscheinen sollen.

Die Erweiterung der Eingabemöglchkeiten zwingt niemanden, alte Einträge anzupassen.

Du musst lernen, zwischen Möglichkeit und Zwang zu unterscheiden.--Ulamm (Diskussion) 16:09, 9. Feb. 2017 (CET)

Die Box muss auch gepflegt werden. Wenn man immer nur dazupappt, wird sie unübersichtlich und irgendwann tut sich das keiner mehr an. Denke an Deine Unwilligkeit, auch nur eklatante Layoutfehler zu beseitigen, und Du wirst das realistischer sehen. --Silvicola ^Disk 16:34, 9. Feb. 2017 (CET)

Um keinen weitern Aufwand entstehen zu lassen, müßten die bisherigen Parameter, so bleiben wie sind und für die zusätzlichen Quellen (Mündungen) ein Neuanfang (gern mit Vorlage) unter dem Titel zusätzliche Quellen (Mündungen) gestartet werden. Es beträfe dann nur die Artikel bei denen gebastelt wurde.--Anarabert (Diskussion) 16:57, 9. Feb. 2017 (CET)

@Ulamm: nicht Deine Vorlage wird hier diskutiert, sondern diese. Halte Dich also bitte daran.--Anarabert (Diskussion) 16:57, 9. Feb. 2017 (CET)

Wie war das vor der automatischen Höhendifferenzbildung? Oft Unstimmigkeiten bei den drei einschlägigen Werten oder selten? --Silvicola ^Disk 17:08, 9. Feb. 2017 (CET)

Weiß nicht, als ich anfing (2008), gab es die, so weit ich mich erinnern kann, schon.--Anarabert (Diskussion) 17:38, 9. Feb. 2017 (CET)

Ich denke da an eine Lösung, daß man zwischen der Zeile Quellhöhe und Mündung, einen Bereich weitere Quellen völlig neu ansetzt. Damit blieb der Altbestand völlig unberührt und Änderungsarbeit entstände nur bei den Flüssen mit mehreren Quellen, wo bisher gebastelt wurde.--Anarabert (Diskussion) 17:59, 9. Feb. 2017 (CET) Und selbst dort wäre dann kein akuter Änderungsbedarf, sondern dies könnte allmählich geschehen.--Anarabert (Diskussion) 18:15, 9. Feb. 2017 (CET)

Man darf aber meine Beta-Version als Vorschlag betrachten, wie die Stammversion aussehen könnte. Die Eingaben für die erste Quelle und die erste Mündung sind die seit jeher in der Box vorgesehenen:

Hamel
Die historische Mündung im Norden Hamelns transportiert nur noch einen geringen Teil des Wassers.
Daten
Gewässerkennzahl	DE: 4572
Lage	Niedersachsen, Deutschland
Flusssystem	Weser
Abfluss über	Weser → Nordsee
Quelle	Alte Sickerhamel am Süntel 52° 11′ 0″ N, 9° 23′ 53″ O52.183439.398074350
(Höhe)	350 m ü. NHN
Weitere Quelle	„Hamelquelle“ in Hamelspringe 52° 11′ 44″ N, 9° 24′ 29″ O52.19549129.40811097(350)
(Höhe)	170 m ü. NHN
Dritte Quelle	Quelle Drei mit viel Bla Bla zum Testen wie es aussieht wenn der Text etwas länger ist 52° 18′ 1″ N, 9° 36′ 6″ O52.30016339.60169273(350)
(Höhe)	150 m ü. NHN
Mündungen	In Hameln in die Weser: Fluthamel:52.10919.349861.1 52° 6′ 33″ N, 9° 20′ 59″ O52.10919.349861.1 Stadthamel: 52° 11′ 0″ N, 9° 23′ 53″ O52.18341199.3981170661.1
Mündungshöhe	ca. 61,1 m ü. NN
Höhenunterschied	ca. 288,9 m
Länge	26,6 km Alte Sickerhamel–Fluthamel
Einzugsgebiet	207,59 km²
Mittelstädte	Hameln

--Ulamm (Diskussion) 18:59, 9. Feb. 2017 (CET)

@Ulamm: Ich habe mal die Referenzen aus der IB hier rausgenommen, die brauchen wir hier nicht wirklich. --SteveK ?! 19:17, 9. Feb. 2017 (CET)

Es gibt keinen Grund bei den Quellen und den Mündungen unterschiedlich zu verfahren. Ist eine akzeptable Lösung bei den Quellen gefunden, dann auch für die Mündungen .--Anarabert (Diskussion) 19:27, 9. Feb. 2017 (CET)

Auch bei den Mündungen können die Höhen unterschiedlich sein.--Anarabert (Diskussion) 19:37, 9. Feb. 2017 (CET)

Ich finde die Diskussion nach einem anstrengenden Arbeitstag ziemlich unübersichtlich und schwer zu verstehen. Gut finde ich, dass wir endlich am richtigen Ort diskutieren. Was ich nicht so gut finde ist, dass immer wieder über Dinge geredet wird, die mit dem Punkt der Überschrift nichts zu tun haben.

Wir hatten für die Längenangabe die Lösung mit der Untervorlage Vorlage:Infobox Fluss/LÄNGE gemacht, um verschiedene Längenangaben zu formatieren. Das gleiche haben wir mit Vorlage:Infobox Fluss/HÖHE gemacht. Das mal zur vorhandenen Technik für Mehrfachangaben.

Was mit an der Einführung von mehreren Quellen stört ist, dass man je Quelle 10 Parameter einführen muss, wenn man es richtig macht. Die gleiche Anzahl ist für die Mündung fällig. Da streuben sich mir die Nackenhaare, das kann man nicht mehr warten.

In einigen Artikeln werden für sowas die Box mehrfach eingebunden. Das wäre meiner Meinung nach eine Alternative, die noch gar nicht in Erwägung gezogen wurde.

@Ulamm: Bei deiner Box gefällt mir das Design nicht wirklich gut, besonders die Angabe "(Höhe)" würde ich so nicht machen wollen. Das steht so verloren in der Landschaft.

Soweit mal meine erste Stellungnahme. --SteveK ?! 19:45, 9. Feb. 2017 (CET)

Der Quellenbereich sollte optisch eine Einheit bilden also als Trennlinie entweder eine gestrichelte Linie("border-style:dashed") oder aber eine gepunktete Linie ("border-style:dotted") Zu den Höhen wie SteveK. --Anarabert (Diskussion) 20:10, 9. Feb. 2017 (CET)

@SteveK: Schlaf Dich ruhig erst mal richtig aus. Hier wird nichts mehr übers Knie gebrochen, nicht wahr?!

Gegen eine endlose Parametervermehrung habe ich dieselben Einwände wie SteveK. Mit der Parametervermehrung per Namenssuffix 1/2/3/ usw. für ganze Parameterblöcke entsteht aber so eine „Parameter-Dampfnudel“. Überschaubar würde die Erweiterung wohl nur durch Abstraktion (Untervorlage) und Replikation in einem Feld, wie oben beschrieben; das führt dann aber zum Bruch etwa mit der automatischen Höhendifferenz. Irgendwann stößt man übrigens mit der Vorlageneinbindung auch an technische Grenzen (Laufzeit-, Rekursionsschranken usw.), aber da weiß ich nicht Bescheid.

Den Zusatz (Höhe) vorn finde ich auch schlecht. Das macht das Ganze unnötig unübersichlich und ist wäre daneben auch inkonsequent, denn wieso dann nicht ebenso (Quellort) / (Quellkoordinate)? Und wieso überhaupt diese Schüchternheits-Klammer? Mündungsort, -koordinate und -Höhe sind in so einem Block schon selbsterklärend genug durch die verschiedenen Datendarstellungsformate.

--Silvicola ^Disk 21:33, 9. Feb. 2017 (CET)

Danke für das Mitgefühl, aber wenn ich nicht zeitnah lese komme ich nicht mehr hinterher.

Ich würde übrigens die Höhe über die Koordinaten hieven, die Bezeichnung könnte man ja in der rechten Spalte unterbringen, wenn es überhaupt sein muss.

Die automatische Berechnung des Höhenunterschiedes wurde übrigens eingeführt, weil oft genug falsche Differenzen drin standen. Das kommt immer dann zustande, wenn die Quellhöhe oder Mündungshöhe angepasst wurde, die Höhendifferenz aber eben nicht angepasst wurde. Ob der Höhenunterschied gewünscht ist, kann ich nicht sagen. Das der größte Höhenunterschied im oberen Drittel eines Flusses zu verzeichnen ist wie Ulamm mehrfach betont hat, ist durchaus in diesem Kreis bekannt.

Um die Programmierung übersichtlicher zu gestalten, sollte man die komische Programmiersprache LUA für die Umsetzung einsetzen.

Soweit für heute. --SteveK ?! 23:02, 9. Feb. 2017 (CET)

@LUA: Das schein mir auch so. Hab das LUW-Packet allerdings nicht per Paketmanager bekommen können, und nach dem händischen Runterziehen fresh from Rio haben prompt irgendwelche Bibliotheken gefehlt oder die Buildertools haben nicht funktioniert, weiß nicht mehr genau, ist schon wieder gut ein Jahr her. In solches Hacker-Gewurstel wollte ich dann doch nicht einsteigen.

Meine Hoffnung war, dass man darin eine Objektstruktur aufbauen kann (geht ja mit den dort notorischen assoziativen Arrays notfalls von Hand). Dann könnten – jeweils mit der nomenklatorischen Entsprechung in unserer Sprechweise hier bezeichnet – das Infobox Fluss-Objekt über sein Array-Feld sagen wir mal QUELLEN dessen erstes Infobox Fluss/QUELLE-Objekt nach dessen Höhe fragen und daraus die Eingabe für die Höhendifferenzrechnung beziehen sowie vielleicht noch Ähnliches mehr. Man käme damit um die ärgerlichen Beschränkungen dieses Textersatz-Modells hier herum; erst mal würde mit evtl. programmatischem Hin-und-her die Objektstruktur generiert, und erst wenn die steht, wird sie unter der im hiesigen Einbindungsmodell vorgesehenen Lebenszeitmethode sozusagen in einem Wikicodestream persistiert. Dann hätten die Teilobjekte vorher lange Gelegenheit zum Handshake, während man im Vorlagenprogrammier-Modell hier herinnen i.W. nur unstrukturierte Textbrocken zusammenpappen kann. Was langfristig wohl ohnehin eine Sackgasse ist. LUA soll angeblich auch schnell sein. Na, wer weiß. --Silvicola ^Disk 23:37, 9. Feb. 2017 (CET)

Ich habe mich noch nicht wirklich mit LUA beschäftigt. Wie gut das geht weiß ich nicht, aber die Möglichkeiten sind wohl deutlich besser als mit den Bordmitteln der Vorlagenprogrammierung alleine. --SteveK ?! 21:51, 10. Feb. 2017 (CET)

Nur wer macht das, hätte Wikipedia eine Schnittstelle zu einer gescheiten objektorientierten Sprache, dann könnten dies wohl viele tun, aber sich dafür extra in LUA einarbeiten?--Anarabert (Diskussion) 17:24, 11. Feb. 2017 (CET)

LUA hat den enormen Nachteil, daß sich in DE:WP ungefähr zweieinhalb Benutzer damit auskennen, und die sind a) stets überlastet, b.) arrogant bis zum Gehtnichtmehr ("Not-invented-here-Syndrom") und c.) fällt unter KPA. --Matthiasb – ^{(CallMyCenter)} 10:17, 12. Feb. 2017 (CET)

<quetsch>Mit LUA kennt sich Benutzer:Firefligher meines Wissens ziemlich gut aus und er ist von Benutzer:Matthiasb sicherlich nicht gemeint. Ob er sich das angesichts dieses Grabenkriegs antun möchte, weiß ich allerdings nicht. Gruß -- faltenwolf · diskussion 22:33, 12. Feb. 2017 (CET)

Obiges Beispiel ist übrigens schlecht bzw. falsch. Die Alte Sickerhamel braucht jedenfalls eine eigene Infobox (die angegebenen Koordinaten sind übrigens 200 m off), und selbiges gilt für die einzelnen Mündungsarme. Das von Ulamm geschilderte Problem ist also keins, sondern lediglich Symptom der falschen Anwendung. --Matthiasb – ^{(CallMyCenter)} 10:38, 12. Feb. 2017 (CET)

Ich habe das Buch von Ierusalimschy vor vielleicht zwei Jahren gelesen, darin zumindest erschien die Sprache nicht wirklich schwierig. Syntac i.W. wie C. Ein paar Absonderlichkeiten sind drin. (1-basiert, Arrays werden mit assoziativen Arrays realisiert, ohne Prüfung, ob nicht vielleicht zwischen konsekutive Elemente ein Loch gerissen wird; keinerlei Integertyp, nur Floating point numbers.) Wo ich (ohne je getestet zu haben) am meisten Bedenken habe: Die Sprache hat keinen Datentyp für 16-Bit-chars (Unicode „untenrum“) das riecht dann nach Gebastel, es gibt aber wohl Zusatzbibliotheken; sie scheint nicht konzeptuell entworfen zu sein, sondern gewachsen, das riecht nach PHP & Konsorten.

Wieso gerade die Sprache gewählt wurde? Angeblich ist das Laufzeitsystem schnell. --Silvicola ^Disk 22:34, 12. Feb. 2017 (CET)

Erstes Zwischenfazit:

• Ich will mal versuchen die obige Diskussion kurz zusammen zufassen: Alle sehen die Problematik, das die Infobox nur die Möglichkeit bietet die Werte für eine Quelle einzugeben, obwohl das betreffende Fließgewässer mehrere Quellen (rechter und linker Quellstrang) und dazu noch den namentlichen Ursprungspunkt (Zusammenfluss) besitzt. Hier wird in die Box, je nach Autor willkürlich mal dieser, mal jener Wert eingetragen.
• Auch der Zustand, daß die SUFFIX-Parameter als Notlösung zweckentfremdet werden, wird als nicht befriedigend wahrgenommen.
• Aber so richtig weiß keiner, außer Ulamm, wie eine befriedigende Lösung aussehen sollte.
• Ich denke, daß die Anzahl der Fälle, bei denen bei Flussgewässer mehrere Quellen vorkommen, größer ist, als oftmals angenommen, weil neben den Quellen von rechtem und linkem Quellfluss/bach und dem Zusammenflusspunkt, auch noch die Quelle des Hauptstranges nach MQ durchaus erwähnenswert sein sollte.
• Was also tun?
• PS: Bei den Längen tritt ein ähnliches Problem auf, das mal der Wert des Strangs nach Namen und eine andersmal die Gesamtlänge eingetragen wird oder das zusätzlich noch die SUFFIX-Parameter für die Werte des zweiten, nicht beim Längen-Parameter eingetragenen Wert plus mittels <br /> noch dem Wert des Längsten Stranges, mißbraucht werden. Auf den Laxbach wurde oben schon hingewiesen
• Man schaue sich mal an, wie unterschiedlich dies bei den verschiedene Artikeln gehandhabt wird. Bei Auswertung von dritter Seite werden dann die Werte maschinell aus den Infoboxen eingelesen und bei der Veröffentlichung, wird dann Wikipedia, als Quelle benannt, mit den vielen dadurch entstehenden fehlerhaften Werten, weil die im SUFFIX-Bereich versteckten Werte natürlich dabei wegfallen und/oder die eingelesenen Werte im Längen-Parameter falsch interpretiert werden. Das heißt, in einem Bereich, in welchen Wikipedia eigentlich vorbildliche Arbeit leistet, wie oft schon wurden Einträge von anderen Lexika in diesem Bereich als fehlerhaft erkannt, wird sie dadurch in ein schlechteres Licht gerückt, als sie es verdient.--Anarabert (Diskussion) 09:45, 15. Feb. 2017 (CET)

Gute Zusammenfassung. Ich hatte ja schon angedeutet, dass wir für die Lösung wohl LUA einsetzen sollten / müssten. Mir schwebt eine Lösung analog zu dem Abflussweg / Gewässernummern vor. Also die heutigen Parameter verwenden und ein Trennzeichen definieren (z.b. "\") um die Angaben zu trennen. Dann sollten die Quellen untereinander stehen. Die heutige Trennung der Höhenangaben sollte integriert werden. Das dann sowohl für die Quell- als auch Mündungsangaben. Ungeklärt ist für mich noch, was aus dem berechneten Höhenunterschied werden soll.

LUA

@Silvicola: Sollten wir gemeinsam versuchen ein Modul zu entwickeln? Erste Frage wäre da, was braucht es zur Entwicklung?--SteveK ?! 10:14, 15. Feb. 2017 (CET)

@SteveK: Es empfiehlt sich, erst einmal ein lauffähiges Lua auf den eigenen Rechner zu bekommen, um spielen zu können. „Zu Hause“ sind die Dinge meist unkomplizierter als hier. Bei mir läuft leider nur eine Lua-Altversion, weil neuere nicht kompilieren.

Downloadseite für LUA: http://www.lua.org/download.html

Runterladen, auspacken, unterm Readme steht, wie man kompiliert. Klappt wie gesagt bei mir nicht, weil der C-Compiler vorgeblich auf einer Programmzeile von lua.c scheitert, deren Kontext ich in der Datei dann gar nicht finde. Kommt möglicherweise durch eine include-Expasion oder dergleichen zustande; aber da steige ich nicht noch ein.

Für hier gibt es: Hilfe:Lua, von dort noch weitere Seiten, die eine vorzüglich, da knappe und stichpunktartige Beschreibung für alle bieten, die eigentlich schon wissen, wie es geht (wie üblich), und mit seltsamer Auffassung etwa davon, was der Konjunktiv eigentlich im Deutschen bedeutet. Déformation professionelle …

Entwickeln sollte man wohl zuerst im eigenen Namensraum. Wohl weil Lua-Module evtl. wiederum andere Lua-Module benutzen und eine bestimmte Vorstellung davon haben, was in einem Lua-Modulnamen stehen darf (insbesondere kein ":"), soll man die Vorlagenspielwiese (Hilfe:Vorlagenspielwiese) benutzen, um die auf benutzereigenen Seitenabgelegten Module sozusagen namentlich um einen auf der zugehörigen Hilfs-Aufrufseite einstellbaren Benutzerseitenpräfix zu kürzen.

Der für mich dringlichste Punkt wäre es, erst einmal zu finden, was aus der Aufrufumgebung wie im Lua-Code im Zugriff ist. Ich vermute nach dem Beispiel Modul:Hello, dass das exklusiv über den dortigen Parameter frame kommt. Frame steht dabei wohl für den Aufrufrahmen, d.h. den Satz der Parameter, der über {{#invoke: …}} übergeben wird. Aber so ein Lua-Modul kann ja viele Funktionen enthalten, welche bekommt es also? Zweitwichtigstes ist dann, wie man die vom Wikiparser erkannten Namen-Wert-Paare für die Parameter generisch in so ein invoke hineinbekommt. Denn im Artielnamensraum darf kein invoke genutzt werden, das muss indirekt über eine Vorlage gehen.

Im (de:wp-)allgemeinen Namensraum Modul ist noch nicht allzuviel da, vgl. die Liste, und bei dem halben Dutzend Modulen darunter, die ich mir grob angeschaut habe, geht es anscheinend vor allem um die Bereitstellung technischer Hilfsfunktionen.

Ich bleibe dran. --Silvicola ^Disk 16:40, 15. Feb. 2017 (CET)

Invoke sieht so aus: {{#invoke: Modul-Titel | Funktionsname | Wert1 | Wert2 | NameX=Wert ... }}. Die zu einem Aufrufframe gepackten Parameter bekommt deshalb wohl die im zweiten Parameter Funktionsname benannte Funktion des gerufenen Moduls. Wegen „anders herum“ werde ich mal in der Lua-Werkstatt anfragen. --Silvicola ^Disk

Ich habe mir jetzt mehrere Module angeschaut. Eigentlich ist das Modul "Hello" typisch, keinerlei Kommentare.

Kann man im BNR LUA-Module anlegen? ich dachte das geht nur im Modul-Bereich. Aufrufen, klar das geht aus dem BNR.

Im Modul "Hello" ist wohl frame ein Array mit den übergebenen Parametern des Invoke-Aufrufes. --SteveK ?! 20:57, 15. Feb. 2017 (CET)

Anlegen geht jedenfalls, siehe Benutzer:Silvicola/modules/testHello, Benutzer:Silvicola/modules/Modul:Hello

Und die Aufrufparameter bekommt man nur indirekt aus dem frame. Rufe dazu

Spezial:Vorlagenspielwiese

auf, trage ins erste Eingabefeld „Spielwiesenpräfix“;

Benutzer:Silvicola/modules/

ein und im zweiten Feld „Seite rendern“

Benutzer:Silvicola/modules/testHello,

in der Datei steht genau:

{{#invoke:Hello|hello|A|B|C|D|E|F|G|H|I|J|K|L|M|N}}

Ergebnis unterm Rahmen.

Es ist offenbar unzumutbar, auf einer Hilfeseite wie Hilfe:Lua so ein Trivialität zu nennen. Stattdessen muss jeder, der anfängt, das selber anhand der Fehlermeldungen herauskitzeln.

Zum Syntaxelement „:“ (vgl. den Code von Benutzer:Silvicola/modules/Modul:Hello) finde ich übrigens nichts im Index des Lua-Buchs.--Silvicola ^Disk 00:18, 16. Feb. 2017 (CET)

Das Syntaxelement „:“ erlaubt einen Aufruf „mit offengelegtem self pointer“ zu vermeiden. (Die Methode, wie früher der C++-Präprozessor C++-Methoden zu C-Methoden transformiert hat.) Siehe [[1]], Abschnitt 3.4.11 – Function Definitions. --Silvicola ^Disk 00:59, 16. Feb. 2017 (CET)

Ich habe mal den Rotlink korrigiert. Ich glaube ich sollte mal spielen.--SteveK ?! 20:06, 16. Feb. 2017 (CET)

Auf der oben verlinkten Lua-Werkstatt hat sich auch Neues ergeben. Siehe insbesondere Help:Lua/*. --Silvicola ^Disk 21:48, 16. Feb. 2017 (CET)

Frage zum "FLUSSSYSTEM"

Mir ist aufgefallen, dass bei der Angabe des Parameters "FLUSSSYSTEM" im Falle einer Link-Umleitung ein Unterschied gemacht wird, je nachdem ob der zu verlinkende Fluss existiert (also das Lemma) oder nicht. Ich wollte in Glass River die Konstruktion "River Douglas (Irische See)/River Douglas" einsetzen, die wird so wie eingegeben angezeigt (das Lemma River Douglas (Irische See) existiert noch nicht). Nehme ich statt dessen z.B. "Po (Fluss)/River Douglas", dann wird es ordentlich angezeigt und zu Po (Fluss) verlinkt. Wie kann man das fixen? -- Jesi (Diskussion) 16:35, 7. Mär. 2017 (CET)

Zusatz: Beim ABFLUSSWEG klappt die Konstruktion. -- Jesi (Diskussion) 16:38, 7. Mär. 2017 (CET)

Ich glaube, da hast du einen Fehler gefunden. Auf die Schnelle habe ich es jetzt nicht gefunden.--SteveK ?! 20:02, 7. Mär. 2017 (CET)

@Jesi:Ich habe das Problem untersucht. Wenn die Prüfung auf Vorhandensein den Flusssystemartikels zeigt, dass der Artikel nicht existiert, dann wird angenommen, dass es sich um Freitext handelt (beispielsweise wie bei Themse). In dem Fall wird der Text einfach ausgegeben. Das hat den Effekt den du beschrieben hast. Ich habe im Artikel Glass River mal eine mögliche Lösung aufgezeigt.

@all: In wieweit brauchen wir Freitext im Flusssystem? Es gibt eine Wartungsseite, die Links auf Artikel mit solcher Anwendung listet. Ich würde befürworten, die Freitextmöglichkeit im Parameter FLUSSSYSTEM abzuschaffen und ggf. einen neuen Parameter FLUSSSYSTEM_FREITEXT einzuführen. Meinungen?--SteveK ?! 22:00, 7. Mär. 2017 (CET)

Ich danke dir. Auf den möglichen Fix hätte ich eigentlich auch selbst kommen können, ich war aber so mit allen möglichen Varianten der A/B-Version beschäftigt, dass ich gar nicht weiter gedacht habe. Was die allgemeine Frage angeht, kann ich sachlich nichts beitragen. Bis zu einer Klärung wäre es aber sicher hilfreich, das Problem und die mögliche Lösung in der Parameterbeschreibung anzugeben. Noch einmal Dank und Gruß -- Jesi (Diskussion) 13:27, 8. Mär. 2017 (CET)

Bilderwunsch-Koordinaten

Hallo zusammen, mir ist es jetzt schon mehrfach passiert, dass mein Navi mit Bilderwünschen mich zu einer Flussmündung geschickt hat, die eher unspektakulär war. Was haltet ihr von einem optionalen Satz Bilderwunsch-Koordinaten in der Infobox? Damit könnte man Bilderwünsche für Flüsse konkretisieren und würde mich immer zur Mündung geschickt. Gruß, --Flominator 17:44, 25. Aug. 2017 (CEST)

Du merkst an der Reaktion der Mitlesenden, dass das nicht wirklich ein Thema ist. Aussagefähige Flussbilder sind schwer, nicht überall steht ein markantes Bauwerk am Fluss, hat der Fluss eine markante Stelle, dass der Wiedererkennungseffekt gegeben ist. Viele Bilder von Flüssen sind austauschbar. Für mich stellt die Mündung daher ein der markantesten Stellen dar. Eine Möglichkeit wäre es, den Bildwunsch abschaltbar zu machen.--SteveK ?! 10:27, 9. Okt. 2017 (CEST)

ungenau – ungenau = genau

Beispiel: Söllbach (Ohrn)

Der Artikel hat eine Flussbox-Einbindung mit eingefülltem Präfix zu sowohl der Quellhöhe wie der Mündungshöhe. Trotzdem steht im generierten Feld mit der Höhendifferenz kein Präfix wie ca., ungefähr o. ä., was doch zu viel an ungerechtfertigter Genauigkeit suggeriert. Ich beobachte dieses Verhalten zum ersten Male, früher wurde wohl automatisch der Differenzwert durch ein eigenes Präfix „vagisiert“. --Silvicola ^Disk 09:45, 9. Okt. 2017 (CEST)

Das ist kein Problem der IB, die reagiert nur auf "ca.", "etwa", "rund" als Prefix. Ich habe die IB im Artikel geändert und schon ist auf die Höhendifferenz ungenau. (MMn ist "Um" sprachlich auch nicht ganz korrekt.)--SteveK ?! 10:01, 9. Okt. 2017 (CEST)

Danke! erledigtErledigt --Silvicola ^Disk 10:03, 9. Okt. 2017 (CEST)

Autokat auf ISO-Ebene 1 beschränken

Hallo, ich habe {{ISO Kat}} auf Anregung von Matthiasb so angepasst, dass eine maximale Kategorietiefe (maxlevel) einstellbar ist. Mit

{{ISO Kat|Region-ISO=|Kat-Root=Fluss|Kat-Schema=in|Kat-Kontinent=ja|maxlevel=1}}

würde vermieden werden, dass die Anlage von Kategorie:Fluss im Département Ardennes‎ zu einer automatischen Tieferkategorisierung führen würde.

• Fluss in Frankreich (FR)
  • Fluss in Grand Est (FR-GES)
    • Fluss im Département Ardennes‎ (FR-08)

Ohne die obige Änderung führt die versehentliche oder bewusste Anlage der Kategorie auf ISO Ebene 2 zur automatischen Befüllung - wie wir es schon einmal hatten. Wenn es keine nicht-auflösbaren Widerstände gibt, würde ich das so einbauen. lg --Herzi Pinki (Diskussion) 00:36, 13. Mär. 2018 (CET)

Ich war hier immer der Ansicht, dass wir es so haben wollen, dass bei Anlage von Kategorie:Fluss im Département Ardennes die Flüsse auf untere Ebene umkategorisiert werden. Wenn jetzt eine Umstellung auf maxtiefe=1 erfolgt, dann würden alle Artikel von "Kategorie:Fluss in <Bundesland>" nach Kategorie:Fluss in Deutschland umziehen, was definitiv nicht gewünscht ist.--SteveK ?! 09:32, 13. Mär. 2018 (CET)

@SteveK:, falsch verstanden. In Deutschland gibt es keine definierten ISO codes der Ebene 2. D.h. natürlich bleibt Kategorie:Fluss in Niedersachsen, und drunter gibt es nix (Automatisches). Gleiches gilt für AT und CH. 2. Ebene gibt es in FR, GB, CZ, IT, ES, UG (ohne sichere Vollständigkeit). Für Slowenien würde ich auf maxlevel=0 einschränken, da gibt es zwischen national und Gemeinde nix brauchbares. Soweit ich das überblicke, würde sich im Moment wenig ändern, aber ein automatische Umkategorisierung in der Zukunft verhindert werden. Die Unterkategorien von Kategorie:Fluss in Schottland würden sich leeren, ebenso die Unterkategorien von Kategorie:Fluss in Trentino-Südtirol (was vielleicht ein bisschen blöd ist). lg --Herzi Pinki (Diskussion) 10:58, 13. Mär. 2018 (CET)

Das ist doch genau das, was ich verstanden habe, auch wenn das Beispiel falsch war. Wenn Unterkateorien existieren, dann sollen die auch befüllt werden. Wenn mach diese Art der Kategorierung für längere Flüsse einschränken möchte, dann müsste das durch einen Parameter der IB gesteuert werden.

Die Zählung der ISO-Ebenen ist etwas blöd, wenn die 1. Ebene bereit die Sub-Ebene ist. Ohne nachlesen war ich der Ansicht, dass die 1. Ebene die Staaten-Ebene wäre.

Gruß --SteveK ?! 13:20, 13. Mär. 2018 (CET)

Linksbündig mit doppelter Mündungskoordinate

@SteveK, Herzi Pinki, Ulamm: Hilfe! Heute erscheint die Box plötzlich linksbündig mit doppelter Mündungskoordinate und OpenStreetMap-Link bei der Mündungskoordinate – dabei wurde an der Vorlage einen Monat lang nichts geändert. Wie kommt das bloß?! -- Olaf Studt (Diskussion) 22:21, 26. Apr. 2018 (CEST)

Jetz isses wieder normal. -- Olaf Studt (Diskussion) 22:23, 26. Apr. 2018 (CEST)

Sohlgefälle

Hallo, was haltet ihr davon das Sohlgefälle ausrechnen zu lassen? Die Daten währen ja vorhanden. Gruß Michael Hoefler50 Diskussion Beiträge 07:26, 13. Mai 2018 (CEST)

Falls ich es selbst einprogrammieren würde: gibt es Vetos? Gruß Michael Hoefler50 Diskussion Beiträge 17:52, 16. Mai 2018 (CEST)

Von mir allenfalls dann, wenn Du nicht ausreichend rundest. Außerdem würde ich vorschlagen, einheitlich in Promille anzugeben, und dann bitte nicht dreistellig oder mehr. Das ist allermeist eine illusionäre Genauigkeit.

Vielleicht wäres es am sinnvollsten, dabei eine Untervorlage zu bauen, vgl. die zur LÄNGE usw. die man dann auch außerhalb der Box verwenden könnte, wenn man etwa für Teilabschnitte das Sohlgefälle nennen wollte. Zwei Parameter, Länge und Höhendifferenz, und diese Vorlage erzeugt daraus mit passender Rundung den ‰ -Wert. Oder braucht man etwa auch noch einen Beleg-Parameter?

Danke übrigens für das Sohlgefälle. Ich hatte dieselben, mit Google aufgestöberten Belege schon länger bei mir herumliegen, habe aber noch auf Besseres gehofft. --Silvicola ^Disk 18:47, 16. Mai 2018 (CEST)

Bei längeren Flüssen macht die Angabe keinen Sinn. Ich weiß zwar jetzt automatisch, dass der Rhein 1,9 ‰ durchschnittliches Gefälle hat, die Angabe ist aber nicht wirklich sinnvoll. --SteveK ?! 16:48, 18. Mai 2018 (CEST)

Gegenüber der Donau, der Rhone, der Elbe, der Weser schon: Donau etwa nur 0,4 ‰. Was aber in der Hauptsache am Verlust der alten Oberläufe aus den Alpen liegt – der aber natürlich auch von der stärkeren rheinischen Erosion herrührt.

Man könnte aber ggf. noch einen Sohlgefälle-Ausschalter einbauen. --Silvicola ^Disk 17:35, 18. Mai 2018 (CEST)

Ich empfinde das neue Feature der Box nach dem bisher Gesehenen als gut.

Mängel sieht man an diesem Beispiel: Ramsbach (Bühler), ein Bach nit 666 m Länge und 134 Höhenmetern absolutem Gefälle, das ergibt in der Box derzeit ein SOhlgefälle von 201,2 ‰. Doch die Höhendifferenz ist allenfalls auf einen Meter genau, die Länge sicher um mehr als ±1 m ungenau. Das heißt, der angegebene Steigungswert kann allenfalls auf rund ein Prozent genau sein, in Ziffern: 201,2 ‰ ± 2,012 ‰, Man sollte also auf 200 ‰ runden, , entsprechend etwa auf 202 ‰, wenn der berechnete Steigungswär 203,2 ‰ wäre. Rundung also nucht auf eine feste Nachkommazahl, sondern auf zwei gültige Stellen, also EXAKTER_WERT ± 0,01 * EXAKTER_WERT, oder allenfalls EXAKTER_WERT ± 0,005 * EXAKTER_WERT. Das heißt dann umgekehrt, dass die Donau mit ihren derzeit 0,4 ‰ durchaus eine Nachkommastelle mehr bekommen müsste, genauer gesamt im Intervall EXAKTER_WERT ± 0,04 ‰ oder allenfalls EXAKTER_WERT ± 0,02 ‰ auf den für das Intervall repräsentativen „runden Wert“ gerundet werden müsste. --Silvicola ^Disk 18:36, 18. Mai 2018 (CEST)

Also zwei Nachkommastellen? Danke. Einfach bei Round die nach komma stellen angeben? Gruß Michael Hoefler50 Diskussion Beiträge 20:20, 18. Mai 2018 (CEST)

Nein, nicht zwei Nachlkommastellen absolut, sondern zwei gültige Stellen, also von der ersten nicht verschwindeten Ziffer des Divisionsergebnisses q an nur zwei weitere Stellen zulassen, hinter diesen kappen und die letzte belassene Stelle evt. um 1 größer machen, wenn der dazu abgeschnittene Teil mit Ziffer 5 oder größerer beginnt. GGf. durch Nullen hinten auffüllen, bis der Stellenwert wieder stimmt:

10583 ‰ → 10600 ‰

5483 ‰ → 5480 ‰

273 ‰ → 273 ‰

25,982 ‰ → 26,0 ‰

9,876 ‰ → 9,88 ‰

0,7385 ‰ → 0,739 ‰

usw. Das geht technisch etwa so: Zehnerlogarithmis von q ermitteln. Diesen Wert auf die nächstkleinere ganze Zahl abrunden, sagen wir diese Zahl ist n. Dann ist q eine Tahl a,xxx * 10′b mit einstelligem a. Die absolute Dezimalstelle, auf die gerundet werden muss, ist dann

Wenn n-2 >= 0 ist: die n-2-te Stelle vom Komma nach links gerechnet, o ist dabei die letzte Vorkommaposition

Wenn n-2 < ist: die abs(n-2) Nachkommastelle

Das Ergebnis der Rundung sollte bis zwei Stellen hinter der ersten nichtverschwindenden Ziffer (von vorne an gerechnet) dargestellt werden, wenn diese Stelle noch (mehr als eine Stelle) vor dem Komma liegt, muss hinten mit Nullen bis zum Komma aufgefüllt werden, dieses sollte dann aber nicht mehr geschrieben werden. --Silvicola ^Disk 00:19, 19. Mai 2018 (CEST)

Darüber schlaf ich mal mindesters eine Nacht. ;-) Gruß Michael Hoefler50 Diskussion Beiträge 00:29, 19. Mai 2018 (CEST)

Idee von mir wäre bei Werten über 0,01 würde ich auf Prozent ohne Nachkomma runden. Beim Rest bei Werten über 0,001 auf Promille ohne nachkomma und beim Rest auf Promille mit einem Nachkommazahl. Gruß Michael Hoefler50 Diskussion Beiträge 06:46, 19. Mai 2018 (CEST)

@Hoefler50: ist zwar engagiert, aber sehr einseitig übermotiviert. du musst noch unbedingt auswerten, ob eine der beiden nöhenangaben nicht mit "ca." oder so steht, dann kann bei kurzen bächen selbst eine kommastelle absurd präzise werden: auf 1 km machen ein paar meter naturgemäß schon an die 1 % aus, und bäche von wenigen km haben wir etliche. also musst du in diesem fall viel heftiger runden, nämlich auf %. ausserdem gibt es, was dir vielleicht nicht bewusst ist, gebirgsbäche, die auf wenigen km viele hundert Hm überwinden, da wirken sich (oft willkürlich) angenommene höhenangaben im bereich der quellkare enorm aus. probier doch mal einen bergflanken-sturzbach mit 2000 m auf 1 km distanz, und variier über ein paar wasserfälle, also selbe distanz, aber etlich Hm weniger (extrembereich-analyse ist nicht deins, oder?). oder gib uns zumindest die möglichkeit, bei als TF anmutenden werte das ganze schlicht auszublenden: aus dem grund haben wir nämlich viele solche wertberechnungen bald wieder aus den IBs entfernt. --W!B: (Diskussion) 20:24, 25. Mai 2018 (CEST)

1: Der Parameter SOHLGEFÄLLE schaltet die Anzeige ab. 2: Für mich sind es 200 Prozent. Meiner Meinung nach ist der Wert trotzdem interesant. Da hat nichts mit Analyse zu tun. Aber mit irgendwelchen Zahlen muss ich rechnen. Um welchen Artikel geht es dir? Gruß Michael Hoefler50 Diskussion Beiträge 20:31, 25. Mai 2018 (CEST)

Kategorie:Fluss in den Alpen (haben wir obskurerweise noch nicht ;). und verzeihung, ich hab das in der doku übersehen. und nein, du musst nicht "mit irgendwelchen Zahlen rechnen", du musst gar nicht rechnen, eckdaten werden bequellt: sowas ist eben immer kritisch (wie bevölkerungsdichte = EW/fläche braucht nachweislich exakt den selben bezugsrahmen, den man oft nicht hat, daher nur in IB:Gemeinde, nicht aber bei orten allgemein; anstieg und steigung bei IB:Pass braucht verbindliche talorte, sonst ist es blabla, ..). daher dreh es vielleicht lieber um, SOHLGEFÄLLE=ja schaltet ein ("irgendein Text, etwa ja" "Schaltet die Zeile Sohlgefälle ab" ist sowieso recht unplausibel ;). --W!B: (Diskussion) 20:55, 25. Mai 2018 (CEST)

Wer sich etwas auskennt mit Höhen- und Längenangaben, weiß dass diese oft fehlerbehaftet sind; wieviel im Einzelfall, kann man aber oft gar nicht genau in Erfahrung bringen. Der nun in der Box gelieferte Wert fürs Sohlgefälle ist jedenfalls schon mal ein Orientierungswert, besser als gar nichts, und kann ja ggf. abgeschaltet werde, wenn man weiß, dass er zu ungenau würde. Zu erwarten ist, dass Länge und Höhenbelegt sind, daraus ergibt sich der Wert. Sind sie es nicht, weiß auch jeder Kundige, dass auf ihn wenig Verlass ist. --Silvicola ^Disk 21:31, 25. Mai 2018 (CEST)

dann muss das modul aber zumindest (zusätzlich zu "ca."-angaben) auch noch auswerten, ob sowohl länge wie auch höhe wirklich belegt sind, und wenn nicht, automatisch abschalten. und nein, irreführende "orientierungswerte" sind nicht besser als nichts: besser nix als falsches: lückenhaftigkeit ist für uns nie peinlich, gefühlte wahrheiten schon: genau so entstehen fake facts: der leser verifiziert das nämlich nicht, er schreibt einfach ab. und erfahrungsgemäß läufts so: der nächste legt aufgrund unserer daten ein ranking "flüsse in hintertupfing nach sohlgefälle" an, und das ist dann eben schlicht stuß (weil, selbst wenn alles halbwegs korrekt ausgerechnet ist, die daten nicht vergleichbar sind, wenn nicht alle exakt dieselbe vermessungssgrundlage verwenden. hatten wir eben bei "pässen nach steilheit" schon, soweit ich mich errinern kann. --W!B: (Diskussion) 11:06, 26. Mai 2018 (CEST)

Jetzt sind die circa Angaben auch beim Sohlgefälle. Könnte mir mal eine den Namen von einem Gebirgsbach mit einem hohen Sohlgefälle sagen? Mann könnte die Rundung noch höhermachen. Man könnte den Wert ausblenden. Ich persönlich halte den Wert aber weiterhin für sinnvoll. Gruß Michael Hoefler50 Diskussion Beiträge 14:30, 26. Mai 2018 (CEST)

Die Partnach ist vielleicht noch nicht steil genug? Dann suche beispielsweise mal hier: Kategorie:Klamm nach zugehörigen Bachartikeln, die auch mit Länge + Höhen bestückt sind. --Silvicola ^Disk 15:55, 26. Mai 2018 (CEST)

Ehrlich gesagt nein. Weil diese immmer noch zweistellig ist. Von den Flüssen, die die verloren sind drei oder vier mit klamm im Namen. Diese sind auch alle zweistellig. Also nichts wo es übermässig viele Zahlenstellen gibt. Im Moment würd ich jetzt nicht ändern. Gruß Michael Hoefler50 Diskussion Beiträge 16:53, 26. Mai 2018 (CEST)

@Hoefler50: Im Artikel Regen (Fluss) in der Nebenbox zum Schwarzen Regen geht offenbar etwas ziemlich schief bei der Angabe des Sohlgefälles.

Überschlagen: 172 m / 60,1 km < 3 ‰

Aber angezeigt: 61 ‰

Warum? --Silvicola ^Disk 11:44, 27. Mai 2018 (CEST)

Nachtrag: Offenbar kann der angesetzte Algorithmus nicht damit umgehen, dass in der Länge nicht nur eine Zahl, sondern auch eine Rechnung stehen kann. Herauspräpariert hier: Benutzer:Silvicola/Testarea. Wie aus

1000 m / (1000 km + 1000 km)

ein Sohlgefälle-Wert von

200 %

werden kann, ist nicht einmal durch Verzicht auf Punkt vor Strich erklärbar:

1000 / 1000 + 1000 = 1001 >> 200 %

--Silvicola ^Disk 12:03, 27. Mai 2018 (CEST)

Bin jetzt auch drauf gekommen. Ich würde jetzt in der Vorlage Klammern setzen. Beim Regen habe ich es jetzt händisch gerechnet. Gruß Michael Hoefler50 Diskussion Beiträge 12:13, 27. Mai 2018 (CEST)

Offenbar ergibt eine Länge von ( 1000 km + x km ) bei einer Höhe von 1000 m ein Sohlgefälle von 2 * (x/1000) ‰. Das riecht irgendwie nach Textersatz-Rechnung mit zweimaligem Einsetzen des Längenterms. Ist vermutlich zu heilen, indem man um den übernommenen Längen-Term noch Klammern setzt; denn wenn ich den Wert des Längen-Parameters 1000 + 1000 selbst klammere, kommt korrekt 1000 / (1000k + 1000k) = 0,5 ‰ heraus.

Das mit den Rechnen hast aber du erst eingefügt. Mit Klammern funktioniert es jetzt. Gruß Michael Hoefler50 Diskussion Beiträge 12:23, 27. Mai 2018 (CEST)

@SteveK: Geht in die Berechnung der Flächenspende nach altem Parametersatz ABFLUSS* unter Umständen der Parameter Einzugsgebiet der Infobox Fluss ein? Dann könnte, im Fall in dem Parameter eine Rechnung steht und der Längen-Term vor Übernahme für diese Rechnung nicht sicherheitshalber geklammert wird, hierbei eine analoge Fehlrechnung wie hier stattfinden. --Silvicola ^Disk 12:32, 27. Mai 2018 (CEST)

Die Berechnung steckt in der Untervorlage /PEGEL und ist meiner Ansicht nach kjorrekt geklammert: #expr: ({{{MQ|}}}/{{{EZG|}}}) round 4}})

--SteveK ?! 18:30, 27. Mai 2018 (CEST)

@Hoefler50, SteveK: Jetzt erscheint bei nicht ausgefülltem Parameter LÄNGE die Zeile „Länge“ trotzdem, und zwar mit der Fehlermeldung „Längenangabe ist keine Zahl“! -- Olaf Studt (Diskussion) 15:29, 27. Mai 2018 (CEST)

@Olaf Studt: Bei welchen Artikel? Regen (Fluss) ist okay. Gruß Michael Hoefler50 Diskussion Beiträge 17:55, 27. Mai 2018 (CEST)

Blum Creek. -- Olaf Studt (Diskussion) 18:20, 27. Mai 2018 (CEST)

Den Fehler habe ich jetzt behoben. Das Problem lag an der Leerangabe der Länge. --SteveK ?! 18:39, 27. Mai 2018 (CEST)

Ich habe auch was an der Vorlage geändert. Schau mal ob es das nächste Mal wieder wie vorher ist. Gruß Michael Hoefler50 Diskussion Beiträge 18:48, 27. Mai 2018 (CEST)

Die Ursache des Fehler geht auf deine Kappe. In der Untervorlage ist der Wert "()" eben nicht leer, wenn der Parameter Länge nicht angegeben wurde oder leer ist. Ich empfehle dir, vor der Änderung der IB Änderungen immer gesondert zu testen. Ich habe das jedenfalls meistens so gehalten.--SteveK ?! 22:21, 27. Mai 2018 (CEST)

hast du dir die Änderung angeschaut. Das waren nur 10 Klammern. Ansonsten gilt: wer arbeitet macht Fehler. Gruß Michael Hoefler50 Diskussion Beiträge 12:15, 28. Mai 2018 (CEST)

@Hoefler50, Silvicola, SteveK: Siehe Sohlgefälle im Artikel Kropfbach (Haslochbach). Der Fehler liegt am „manuell“ befüllten Parameter Höhenunterschied. Wie kann man das lösen, ohne dass Informationen verloren gehen. Gruß --Freak-Line-Community (Diskussion I Beiträge) 21:45, 11. Jun. 2018 (CEST)

Man müsste den Teilcode für einen neuen Optional-Parameter SOHLGEFÄLLE so ändern, dass ein manuell dafür gesetzter Wert, ähnlich wie bei HÖHENUNTERSCHIED selbst, einfach so, wie er dasteht, übernommen wird. Dann könnte man den Wert bzw. im Beispiel die zwei Werte ggf. manuell einsetzen. Das ist aber derzeit nicht der Fall. Testvektoren auskommentiert im Bachartikel hinterlegt. (Übrigens: Das Textersatz-Programmiermodell in WP, dazu noch die beknackte, die KLammergebirgend anscheinend absichtlich noch steigernde Syntax, macht den Käse für mich schon aus visuellen Gründen leider unlesbar.) --Silvicola ^Disk 02:02, 12. Jun. 2018 (CEST)

Das Problem ist das die Rechnung (noch) nicht kann mit dem text umzu gehen. Den Höhenunterschied rechnet er automatisch aus. Die Bedeutung von Sohlgefälle möchte ich nicht ändern, nicht das es schon verwendet wird. Gruß Michael Hoefler50 Diskussion Beiträge 12:52, 12. Jun. 2018 (CEST)

Ich glaube ehrlich gesagt nicht das in vielen Artikeln der Parameter Höhenunterschied verwendet wird. wenn man den Parameter löscht passt die Seite. Gruß Michael Hoefler50 Diskussion Beiträge 15:31, 12. Jun. 2018 (CEST)

@Hoefler50, Silvicola, SteveK, Freak-Line-Community: Jetzt erscheint eine leere Zeile „Sohlgefälle“, wenn Quell- und Mündungskoordinaten angegeben sind und die Felder QUELLHÖHE und MÜNDUNGSHÖHE unausgefüllt dastehen, siehe Possendorfer Bach. Dort habe ich die Kopiervorlage frisch von der Vorlagendoku verwendet. -- Olaf Studt (Diskussion) 22:48, 15. Jun. 2018 (CEST)

Hallo Olaf, ich habe das nicht zu verantworten. Ich persönlich habe und halte das Sohlgefälle in der IB für verzichtbar. Sonst hätte ich das ja schon vor Jahren implementiert. Ich halte mich aber aus der Diskussion weitgehend raus. Gruß --SteveK ?! 09:19, 16. Jun. 2018 (CEST)

Hallo, da ich bringe es auch nicht in Ordnung und habe es in der Hoffnung auf Hilfe in der Vorlagenwerkstatt eingestellt. Gruß Michael Hoefler50 Diskussion Beiträge 21:08, 16. Jun. 2018 (CEST)

Grossstadt/Mittelstadt/Kleinstadt

Ich bin gerade bei Artikel für Schweizer Flüsse auf diese Unterteilung gestossen.

• Was hat das für einen Sinn, bei nichtdeutschen Flüssen die deutsche Unterteilung zu übernehmen (siehe die Definition zu Kleinstadt)?
• Warum werden nicht einfach die für den Flussverlauf bedeutenden Orte nacheinander aufgelistet, was m.E. logischer wäre. Man kann wegen dieser Aufteilung den Flussverlauf gar nicht folgen. --Gr1 (Diskussion) 16:00, 14. Mai 2018 (CEST)

Siehe Archiv! Ist mein Reden seit Jahren - auch für D-Flüsse! --Elop 16:29, 14. Mai 2018 (CEST)

Ebenso meines, und zwar für überall, wo solche Angaben überhaupt sinnvoll sind. Um das Argument nochmals vorzutragen:

Interessant sind die für das jeweilige Gewässer wichtigen Orte und Siedlungsplätze am Lauf, deren absolute Größenklasse ist dagegen völlig gleichgültig. Mit der Zerreißung der Liste in Gemeinden/Kleinstädte/Mittelstädte/Großstädte, bei der dann sogar die Orte ganz fehlen, vergibt man zudem die Chance, die meist sinnvoll angebbare Reihenfolge darzustellen. Ich meide deshalb inzwischen völlig, diese Rubriken der Infobox überhaupt zu befüllen und gebe stattdessen lieber im Parameter LAGE eine grobe hierarchische Gliederung der berührten Gebietskörperschaften (nicht zu viele, also angemessen hoch) und im Artikeltext eine detaillierte Reihenfolge der Orte am Lauf. (Wenn in der Verlaufsbeschreibung schon klar genug erkennbar dargestellt, ist die natürlich ggf. gar hnicht mehr separat nötig.) Vgl. etwa Mittlere Aurach oder Rott (Inn, Neuhaus am Inn). Siehe im letzten Fall auch die Naturraumgliederung „überm Strich“.

Solange die Box noch nicht sinnvoll umgestaltet ist (und das dürfte vor allem am abschreckend großen Artikelbestand liegen, der bei Änderung natürlich gewartet werden müsste) behelfe ich mich eben so; jedenfalls vermehre ich damit diesen aus meiner Sicht falsch organisierten Artikelbestand nicht noch weiter.

Dn Widerspruch im Betrachtungsabspekt kann man schon in der Boxartikelparameter-Kommentierung erkennen. Zu GROSSSTÄDTE steht da etwa: „Städte über 100.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.“  – Man meint eigentlich die Ortschaft, aber der Parameter ist nach etwas ganz anderem (Verwaltungseinheit) benannt. Eine Benennung, die zuverlässig Verwirrung über die Intention und entsprechend Fehlanleitung der Artikelbeschreiber garantiert: „Gib mir mal den Hammer. – Nein, nicht den, wen ich Hammer sage, meine ich natürlich den Schraubenzieher!“

Übrigens könnte man gerade wegen der Fehlbenennung die Umstellung der Box relativ bruchlos herbeiführen, indem man einen neuen, nunmehr richtig benannten Parameter ORT-AM-GEWÄSSER o.ä. einführt, die alten Parameter GEMEINDE/KLEINSTADT/MITTELSTADT/GROSSSTADT im Parameter-Kommentar zugleich als veraltet und für Neuanlagen nicht mehr zu gebrauchen erklärt und den Bestand en passant nach und nach umstellt, bis man irgendwann die alten Parameter hoffentlich völlig verödet hat und beseitigen kann.

--Silvicola ^Disk 04:02, 15. Mai 2018 (CEST)

+1 zu einem neuen Parameter ORT-AM-GEWÄSSER. Die alten Parameter könnte man dann umseitig, für VE und sonstige Template-Helferlein als "deprecated" (Link eher irreführend) kennzeichnen. --Gr1 (Diskussion) 11:38, 16. Mai 2018 (CEST)

Hier übrinx ältere Fäden zum Thema:

• März 2016
• August 2014
• August 2013

... usw ... --Elop 12:05, 16. Mai 2018 (CEST)

Zusammenfassend also:

* Mai 2018: Zustimmung

* März 2016: Zustimmung

* August 2014: War nicht Hauptthema, wurde aber auch nebenbei vorgeschlagen

* August 2013: Einzig SteveK hatte gewisse Vorbehalte, doch diese sind m.E. vernachlässigbar (stichhaltig wären seine Argumente dann gewesen, wenn der enzyklopädische Nutzen eher klein ist).

D.h. man kann das im Prinzip so umsetzen. Oder? Wenn ja, so ist der Parametername gut zu überlegen; ORT-AM-GEWÄSSER gefällt mir irgendwie nicht (Ort soll aber natürlich massgebend sein, nicht Gemeinde oder Gemarkung). --Gr1 (Diskussion) 15:39, 16. Mai 2018 (CEST)

In der Tat, man wird lange damit leben müssen, deshalb hinsichtlich der Parameteramenswahl und auch prinzipiell: Quidquid agis, prudenter agas et respice finem. Deshalb würde ich gerne mehr Stimmen hören und insbesondere auch SteveKs eventuelle Einwände. --Silvicola ^Disk 16:57, 16. Mai 2018 (CEST)

Ich würde vorschlagen, den neuen Parameter "ORTSCHAFTEN" zu nennen. Und ich möchte nicht, dass die alten Parameter noch ewig in der Box bleiben, die hat eh schon zu viele Parameter. Für den Übergang könnte man eine Wartungsseite einrichten und die alten Parameter unter Ortschaften ausgeben. Soweit mal mein Senf. --SteveK ?! 17:00, 16. Mai 2018 (CEST)

Nachtrag: 2013 war ich schon der Meinung, die Parameter würden in der IB keinen Sinn machen. Das ist auch heute noch so. Bei längeren Listen wird die IB gesprengt. Eigentlich sollte man so was als Siedlungsgeographie am Fluss in einem eigenen Kapitel abhandeln statt die IB damit zu überfrachten.--SteveK ?! 17:08, 16. Mai 2018 (CEST)

Das finde ich bedenkenswert. Im Grunde sind wohl die jetzigen 4 Boxparameter – bzw. wird auch der neue es sein – eine Hudellösung für die sich solche Ausführungen sparen, aber eben doch irgend etwas bieten wollen. Wenn es nicht anders als spärlich ausfallen kann, so dass man keinen eigenen Abschnitt im Artikel zu eröffnen wagt, dann kann man es auch unter Verlauf oder unter einem noch allgemeineren einzigen Textabschnitt mit erledigen.

In meinem Mittelgebirgs-Beritt gibt es ordentlich Dörfer und Weiler, in der norddeutschen Einzelhofflur ist wohl ohnehin fraglich, ob man explizit Hofnamen nennen soll, die oft ja nur verpackte Familiennamen sind. Wie sieht es hinscihtlich der Siedlungsgeographie im Hochgebirge aus, wie weltweit? Ich habe da wenig bis keine Erfahrung. --Silvicola ^Disk 17:33, 16. Mai 2018 (CEST)

"Ortschaften" finde ich nicht optimal, da das in Österreich eine bestimmte statistische Einheit bezeichnet (Ortschaft#Österreich). Was spricht gegen "Ort"? --Luftschiffhafen (Diskussion) 22:32, 17. Mai 2018 (CEST)

Ich habe auch etwas gegen Ortschaft. In DE-BW und anderwo sind das Einheiten für die Wahl semipolitischer Mitwirkungsgremien auf Gemeindeebene (Ortschaftsrat), welche de facto meist den Altgemeinden vor der großen Fusionswelle entsprechen. Überhaupt ist diese politische Gliederungsstruktur von etwas höhere Perspektive als dem Kirchturm gesehen ein Chaos, von dem man sich begrifflich tunlichst fernhält. --Silvicola ^Disk 23:54, 17. Mai 2018 (CEST)

ORT finde ich wiederum zu unspezifisch, da das lediglich einen Punkt auf der Landkarte sein kann. ORTSCHAFT als Parameterbezeichnung hat ja nix mit der politischen Verwendung des Begriffs zu tun. Die Bedeutung sollte hier auf "zusammenhängendes Siedlungsgebiet" wie im Wiktionary angegeben liegen. Die Diskussion würde sich ja erübrigen, wenn die´Parameter entfallen. --SteveK ?! 10:00, 18. Mai 2018 (CEST)

Kommune oder Gemeinde scheint mir auch hinreichend neutral zu sein. Benutzerkennung: 43067 11:37, 18. Mai 2018 (CEST)

Das soll es ja gerade nicht sein - sonst läge Eisenach und nicht Hörschel an der Werra. --Elop 13:39, 18. Mai 2018 (CEST)

Eben. Oder, um andere Beispiele zu geben: Viele der Gemeinden und Städte am Haardtrand haben eine isolierte Waldexklave westlich drinnen im Pfälzerwald. Der Helmbach (Speyerbach) fließt am Forsthaus Frechenthal vorbei, das am Rande so einer Exklave der Gemeinde Rhodt unter Rietburg liegt, fast 12 km nordwestlich des Hauptorts. Fließt der Helmbach also an Rhodt unter Rietburg vorbei? Das zu sagen gäbe einen völlig falschen Eindruck. Unabhängig davon hat das zentrale Gemeindegebiet von Rhodt auch noch einen langen Westkeil in den Pfälzer Wald hinein und berührt mit diesem im Pfälzerwald kurz siedlungsfrei den Modenbach, der sich danach immer fernhält vom Gemeindegebiet. Schon zu sagen, dass Rhodt deshalb am Modenbach läge, wäre deshalb absurd. Siehe Ausschnittkarte LANDIS].

Noch ein weniger sspektakuläres Beuspiel, Öhringen; leider kann ich derzeit keinen Link bieten, da LUBW gerade wieder einmal Wochenendwartung betreibt. Vielleicht genügt Dir aber auch die Karte der administrativen Gliederung des Landkreises im Gemeindeartikel. Die Stadt selbst liegt im dickeren mittleren Teil der verknüllten Spindel. Nahe der nordwestlichen Spitze der Spindel durchquert der Kocher das Stadtgebiet beim Stadtteil Ohrnberg, der also wirklich am Kocher liegt, die Stadt selbst aber keineswegs. Am anderen, südöstlichen Ende der Spindel liegt der Stadtteil Michelbach am Wald, das am Michelbach (Ohrn) liegt, welcher noch vor dem zentralen Stadtgebiet in die Ohrn mündet. Öhringen selbst dagegen liegt nur an der Ohrn. Es einen Ort am Kocher oder einen Ort am Michelbach zu nennen, würde täuschen.

Unser Problem hier ist natürlich verschränkt mit der Tatsache, dass es meist keine separaten Artikel für die Gemeinde/Stadt als bloße administrative Einheit und für den Zentralort gibt, der ihr den Namen leiht. Dem entspricht aber exakt dieselbe Ungenauigkeit im täglichen Sprachgebrauch, dessen Fallstricke man deshalb meiden sollte, weil sonst ein falscher Eindruck über Ortslagen entsteht. Dann gibt es noch die großen Reformgemeinden aus den 70ern, die kompromisshalber nach keiner der fusionierten und heute noch räumlich getrennten Gemeindeorte benannt sind, vielmehr einen neu erfundenen Namen tragen, und die über sieben Täler hinwegreichen. Diese Gemeinden „liegen“ aus meiner Sicht an gar keinem Gewässer. --Silvicola ^Disk 14:55, 18. Mai 2018 (CEST)

--Silvicola ^Disk 14:55, 18. Mai 2018 (CEST)

(ausgerückt): diesbezüglich kann man sich problemlos an die Kategorie:Ort halten: für interna prägen wir uns unsere worte selbst, und "Ort" heisst "wohnstelle/ortslage", von der megacity bis zum einzelgebäude (soferne es einen eigenen örtlichkeitsnamen hat). und kein mensch zählt alle ortslagen am fluss in der IB auf, also kann man annehmen, dass alle einträge sowieso derselben admin-/größenklassen-kategorie angehören: beim yangtse nur millionenstädte, beim durchschnitts-30-km-fluss nur die gemeinden (unhabhängig von den EW), beim 1,5-km-brunzbach nur gehöfte: augenmass beim ausfüllen setzen wir immer voraus. gilt ja auch für die nebenflüsse u.ä. --W!B: (Diskussion) 20:38, 25. Mai 2018 (CEST)

Bitte keine Beleidigungen gegen Bäche mit besonderem onomastischen Schonbedarf! Nur wenn wir allen wie auch immer gearteten und benannten Wasserläufen mit dem gebührenden Respekt begegnen, geht gerade auch in dieser unserer Zeit alles ordentlich den Bach runter. Der, den Du meinst, heißt übrigens in Wirklichkeit seit geraumer Zeit Rosenabschlagswasser und hat auch das Recht darauf, von allen so angesprochen zu werden, sonst wird seine selbstkonstruierte Identität verletzt. Da muss man sich dann nicht wundern, wenn soviele Gewässer in letzter Zeit über die Ufer treten. Schuld daran sind nur die ungewaschenen Zungen. --Silvicola ^Disk 16:10, 26. Mai 2018 (CEST)

 ;) ja stimmt, danke fürs ins gewissen reden. gerade die kleinen verdienen unserer unterstützung. auch wenn sie die große mehrheit sind, die schweigende masse der hydrographischen plutokratie. was übrigens für die kleinorte (ich vermeide tunlichst jede assoziation zu brunz wie zu kaff) auch gilt. ich hab nichts gegen die, wenn sie bleiben, wo sie hingehören: nämlich bei den bächen ihrer größenordnung. der geographische plebs möge sich unter seinesgleichen tummeln. --W!B: (Diskussion) 12:52, 15. Jun. 2018 (CEST)

Dann sollte der nur eine (!) Parameter aber auch ORT oder meintewegen SIEDLUNGSPLATZ oder wie auch immer heißen und nicht künstlich in Teile gesplittet sein, die in einer ganz anderen, nämlich politisch-administrativen Kategorie liegen und die aus Gewässersicht völlig irrelevant sind. Falsche Bezeichnungen erwecken falsche Einträge. --Silvicola ^Disk 12:47, 15. Jul. 2018 (CEST)

Ich hielte es für sinnvoll, einen zusätzlichen Parameter "Kriterien" einzuführen, der einen Ref hinter "Orte" erzeugte. Da könnte bei größeren Fließgewässern dann "Großstädte", "Landeshauptstädte", "Städte über 20.000 EW" oder was auch immer stehen.

Wenn ich bei der Fulda liste "Fulda, Bad Hersfeld, Kassel, Hann. Münden", kommt doch sofort ein Rotenburger und will seinen Ort eintragen - da hülfe eine Deklarierung "Städte über 20.000". Und wenn man, wie bisher, alle Orte mit Stadtrecht listen würde (wäre mit 9 noch tragbar), wäre ebenfalls ein entsprechender Hinweis sinnvoll.

Beim Elnhauser Wasser natürlich auch kleinere Ortschaften (irgendein Pfosten hat da 2008 die "Mittelstadt" Marburg (auch: Marburg am Elnhauser Wasser) in die Box geschmissen). --Elop 13:14, 15. Jul. 2018 (CEST)

Stimmt, man muss hierherinnen immer auch an die Narren- und Lokalpatriotensicherung denken. Man könnte aber henausogut die Einschränkung auch in kleinerer Schrift vorstellen:

Nur Orte mit über 20.000 Einwohnern: Fulda, Bad Hersfeld, Kassel, Hann. Münden

oder:

Nur Orte mit über 20.000 Einwohnern:
Fulda, Bad Hersfeld, Kassel, Hann. Münden

Ockham oder ein Verwandter von ihm zöge wohl die Lösung vor. --Silvicola ^Disk 13:49, 15. Jul. 2018 (CEST)

Abflusspegel

Wenn man derzeit ein LoM von 0 angibt, was ja unzweifelhaft die Mündung meint, dann bekommt man so ein unschönes Textgebilde in der Titelspalte:

XXXbach
Daten
Abfluss an der Mündung	MQ	1000 m³/s

Könnte man nicht stattdessen im 0-Fall das natürlicher lautende

Abfluss an der Mündung

anzeigen? --Silvicola ^Disk 12:37, 15. Jul. 2018 (CEST)

Sollte Passen Gruß Michael Hoefler50 Diskussion Beiträge 15:22, 15. Jul. 2018 (CEST)

Danke. Damit werde ich unbekümmerter einige alte ABFLUSS*-Parametersätze durch Verlagerung der Werte in PEGEL* los. Wegen des „schrägen“ Textes habe ich mich nämlich bisher nie getraut. --Silvicola ^Disk 19:42, 15. Jul. 2018 (CEST)

Höhenunterschied

macht neuerdings eine unnütz große zelle für sich. irgendwelche versteckten umbrüche zu viel. --W!B: (Diskussion) 12:52, 15. Jun. 2018 (CEST)

Ich bekomme es nicht hin. Gruß Michael Hoefler50 Diskussion Beiträge 15:22, 15. Jul. 2018 (CEST)

Hallo, ich sehe keine übergroße Zelle dort. Gibt es ein Beispiel, in dem das zu sehen ist? Oder meint ihr das Sohlgefälle? --Wiegels „…“ 23:11, 15. Jul. 2018 (CEST)

Ich persönlich hätte auch eher die Zeile Sohlgefälle als zu groß bezeichnet. Schwarzach_(Altmühl) wäre ein Beispiel. Was bedeutet eigentlich ? Gruß Michael Hoefler50 Diskussion Beiträge 07:47, 16. Jul. 2018 (CEST)

Das ist ein HTML-kodiertes Leerzeichen, in der umseitigen Vorlage ein erzwungenes, weil normale Leerzeichen an diesen Stellen eliminiert werden. --Wiegels „…“ 21:28, 16. Jul. 2018 (CEST)

. Nun gut, aber wieso dann noch die nowiki-Klammerung um die numerische Entity herum? --Silvicola ^Disk 22:09, 16. Jul. 2018 (CEST)

Vielleicht war das ein misslungenes  . --Wiegels „…“ 22:33, 16. Jul. 2018 (CEST)

Was soll

das?

@Hoefler50:

• Die Tabelle zur Parameterneschreibung vor jede Einleitung für die Vorlage zu setzen, ist mit Grund ziemlich unüblich.
• Der neue, vorgestellte Teil dupliziert im Wesentlichen die Tabelle, die weiter unten steht.
• Nicht mehr erwünschte Parameter (mindestens BEKANNTE BRÜCKEN (ohne Bindestrich!)) werden ohne Kommentar mit aufgeführt; das führt dazu, dass sie erneut verwendet werden.
• In der Spalte Beschreibung werden Links usw. als Wikiquelltext dargestellt.

Offenbar „keine Verbesserung“. --Silvicola ^Disk 13:24, 22. Jul. 2018 (CEST)

Es wäre vermutlich besser, Lómelinde zu beschreiben, was geändert werden soll, und ihr eine allgemeine Überarbeitung der Doku-Seite vertrauensvoll zu überlassen. Sie wünscht sich hin und wieder Abwechslung und geistige Herausforderungen. VG --PerfektesChaos 13:29, 22. Jul. 2018 (CEST)

Ziel war es, dass bei Vorlageneinfügung die Parameter automatisch auftauchen. Gruß Michael Hoefler50 Diskussion Beiträge 13:57, 22. Jul. 2018 (CEST)

Es steht aber schon auf der Doku-Seite ein TemplateData-Abschnitt, bloß ganz hinten versteckt, nicht mal einer Abschnittsüberschrift gewürdigt, und mit Redundanz zur anderen (älteren) Tabelle.

Die Doku-Seite entspricht nicht mehr zeitgemäßer Praxis, eine andere komplexe Vorlage wäre hingegen Vorlage:Literatur.

VG --PerfektesChaos 14:07, 22. Jul. 2018 (CEST)

Heftige Kritik an vermutlich der Quellcodeform

im Zusammenhang mit HTML-Fehlern in anderen Infoboxen steht hier:

Wikipedia:WikiProjekt Vorlagen/Werkstatt#Linterfehler durch Pseudofehlerwartungsanalyse?

Ich berichte nur weiter. --Silvicola ^Disk 14:42, 27. Jul. 2018 (CEST)

Also ich würde nichts machen, da ich die entsprechenden Zeilen nicht verstehe. Die Seiten die in den Zeilen aufgerufen werden sind gelöscht worden. Da müsste mal jemand ran, der sich mit den Konzept der Wartungsseiten auskennt. Ich habe das Gefühl, dass seitdem die Seiten gelöscht wurden, die Wartung nicht mehr richtig funktioniert. Danke dafür im voraus. Gruß Michael Hoefler50 Diskussion Beiträge 22:15, 27. Jul. 2018 (CEST)

PEGEL1 restriktiver als vormals ABFLUSS-PEGEL

Im ersten Feld von PEGEL1 kann man, anders als beim korrespondierenden alten Parameter ABFLUSS-PEGEL,

• keinen Link einbetten
• keinen Schrägstrich „/“ einstellen (natürlich, weil dieser als Feldtrenner fungiert), aber leider auch nicht ersatzweise die numerische Entity für den Schrägstrich, also/.

Eben bemerkt bei dieser Bearbeitung, bei der deshalb der Pegelname gegenüber dem amtlichen verkürzt und auf den Ortslink verzichtet werden musste. --Silvicola ^Disk 06:02, 28. Sep. 2018 (CEST)

Dokumentation

Bis zum 3. Januar 2019 war eine Tabelle mit den Parametern in der Doku vorhanden. Diese Tabelle fehlt jetzt. Vielleicht sollte die Tabelle ja wieder hergestellt werden. --SteveK ?! 15:17, 28. Jan. 2019 (CET)

Das war eine Aktion von Benutzerin:Lómelinde:

• Diff Vorlage:Infobox Fluss/Doku, 3.1.2019 10:00 Uhr
• Diff Vorlage:Infobox Fluss, 3.1.2019 10:01 Uhr

Eine Riesenchose, deren Konsequenzen ich offen gesagt anhand der Diffs nicht leicht überblicke. Wurde da nur Redundanz beseitigt oder vielleicht auch Inhalt? Wenn denn wirklich die Parameterbeschreibung doppelt drin war, war sie das in exakter Kopie oder hätte Lómelinde durchaus wertvolle Erläuterungen hie und da im verbleibenden Teil zuvor noch zusammenstricken müssen? (Wenn schon länger zweimal anfangs dasselbe vorhanden war, kann es sich schon auseinanderentwickelt haben. Hat sie in diesem Falle zusammengestrickt?) – Ich sehe es nicht recht, die Diffs

• bei Vorlage:Infobox Fluss nur ein großer gelöschter Block
• bei Vorlage:Infobox Fluss/Doku mehrere teils große Blöcke gelöscht/verschoben/eingefügt

erschlagen mich geradezu. Man sollte die Diffs ihrerseits gegeneinander diffen können.

Wahrscheinlich hat man das Verständnisproblem bei der Übertragung von Inhalten zwischen Seite und darin eingebetteter Seite immer. Wer sieht da schon beispielweise, ob auf Y exakt eingefügt wurde, was bei X gelöscht wurde?

--Silvicola ^Disk 16:18, 28. Jan. 2019 (CET)

Nachtrag: Grundsätzlich gefällt mit nicht, dass die Parameterbeschreibung in einem rollbaren Unterfenster untergebracht ist (und schon zuvor war). Diese sollte nicht „eingesperrt“ sein. Dasselbe Doppelrollgefrickle beim Seitenbearbeitungsfenster ist schon des Ärgers genug. --Silvicola ^Disk 16:29, 28. Jan. 2019 (CET)

Das kann ich anpassen, ich dachte es ist so gewünscht. Ich habe soweit ich mich erinnere wirklich nur redundantes entfernt, da das den Wartungsaufwand verringert. Man muss dann nicht zwei Tabellen aktuell halten. --Liebe Grüße, Lómelinde Diskussion 17:27, 28. Jan. 2019 (CET)

Danke für die Änderung. Ich hatte beim Drüberschauen gedacht, da fehlt was. Jetzt ist das für mich okay.--SteveK ?! 20:15, 28. Jan. 2019 (CET)

Danke güt Aislinft und Verbesserung. --Silvicola ^Disk 23:02, 28. Jan. 2019 (CET)

Einträge modellierter (errechneter) Werte in den Parameter PEGEL1 der Infobox Fluss

Die Diskussion dazu wird, da es sich nicht nur um eine Infobox spezifische Fragen handelt, auf der Portalseite Gewässer geführt.--Anarabert (Diskussion) 22:34, 7. Jan. 2019 (CET)

Veraltete Parameter

Eigentlich sollt die Wartungsseite leer sein. Sie hat aber mehr als 500 Einträge da die Parameter für den Abfluss noch verwendet werden. Es gibt für mich folgende Möglichkeiten

1: Alles händisch abändern.

2: Einen BOT damit beauftragen um es zu ändern.

2a: Jemand der sich Auskennt könnte es mit WikiBrowser versuchen.

3: Die Vorlage ändern

Die Frage will man den Wert behalten, zu einem Pegel umfunktionieren oder Löschen. Den Wert als fehlerhaft zu bezeichnen und nicht zu ändern halte ich für unschön. Was ist euere Meinung?Theater88 (Diskussion) 16:33, 28. Jan. 2019 (CET)

Nur 500? Das kommt mir zu niedrig vor. Ich werde alle paar Tage en passant den Parametersatz ABFLUSS* aus einer Inforbox, insgesamt bestimmt um die hundert Mal pro Jahr oder öfter. Und das fast exklusiv in DE-BW und DE-BY. Sind bei den 500 die leeren Parametervorkommnisse wirklich auch mitgezählt oder nur die befüllten?

Als wir vor vor ein oder zwei Jahren mit der Austauchaktion ABFLUSS → PEGEL1 begonnen haben, war noch die Rede von einigen Tausenden von Vorkommnissen. Und so arg viele Flusspferde sind wir denn doch nicht.

Insgesamt veraltete Einbindungen gibt es noch zwischen 6000 und 9000. --Silvicola ^Disk 18:01, 28. Jan. 2019 (CET)

Kannst du doch suchen. ABFLUSS allein oder 7.111 × ABFLUSS- Leere Parameter könnte wohl auch ein Bot löschen. --Liebe Grüße, Lómelinde Diskussion 18:54, 28. Jan. 2019 (CET)

Wenn ein Bot die leeren veralteten entfernen würde, an hätten wir einen besseren Überblick. Die Donau z. B. wäre dann immmer noch fehlerhaft. Wäre es okay wenn ich den Abfluss als Pegel neuen Pegel defineren würde? Theater88 (Diskussion) 19:15, 28. Jan. 2019 (CET)

Also es gibt drei Pegelsätze, bei der Ems hatte ich die mal alle befüllt und schon gab es Ärger. Die Umwandlung (wie auch immer du das anstellen willst) ist nur dann erforderlich, wenn alle Pegel bereits belegt sind. Ansonten kann man ja die Werte des Abflusses auch in die Pegelparameter schreiben. --SteveK ?! 20:21, 28. Jan. 2019 (CET)

Das hätte ich auch so vorgehabt. Sie unter den anderen einzusortieren. Sollte es dann vier Pegel sein: Keine Ahnung Theater88 (Diskussion) 20:30, 28. Jan. 2019 (CET)

Ich habe bei WP:BA eine Anfrage gestellt. Theater88 (Diskussion) 19:46, 3. Feb. 2019 (CET)

Die leeren Parameter sind jetzt dank Benutzer:Hgzh entfernt. Ich hätte die Pegel jetzt in bestehenden Pegel 1, 2 oder 3 umbenannt. Was soll gemacht werden wenn alle drei Pegel schon befüllt sind? Den Pegel Abfluss entfernen. Den mit geringsten Informationen entfernen oder einen Pegel 4 einbauen? Theater88 (Diskussion) 18:40, 19. Feb. 2019 (CET)

Es ist immer eine gute Regel in der Informatik, möglichst keine Größenrestriktionen außer durch den verfügbaren Speicherplatz zu verfügen. Gegen Missbrauch kann man persönlich einschreiten. Deshalb bin ich auch dafür, möglichst viele Pegel zu erlauben. Schreiben wir die Knappheitsforderung nicht in den Vorlagen-Code, sondern in die Vorlagenbeschreibung, dann hat man auch einen Schild gegen uneinsichtige Widersetzlichkeit der Pedanten des „Ich habe aber noch einen Wert, Herr Lehrer!“.

Ein Abflusspegel, selbst wenn er nur den MQ-Wert umfasste, ist allemal charakteristischer für ein Gewässeer als ein Pegel am hohen Oberlauf. Gegenüber einem umfangreichen (Meß-)Pegel am Unterlauf, der fast das ganze EZG umfasst (≥ 95 %), ist wiederum ein Abfluss-„Pegel“ m. A. . verzichtbar, umso mehr, wenn die Werte gar nicht gemesen sind, sondern nur aus einem Modell hervorgehen.

--Silvicola ^Disk 23:12, 19. Feb. 2019 (CET)

@ Silvicola: Weißt du eigentlich warum der Abfluss als veraltet markiert wurde?

Ich bin auch kein Fan vom löschen, da ja ein Parameter nichts frisst. Die Frage was gemacht werden soll: Einen Pegel 4 einführen und diesen mit den Werten aus dem Abfluss befüllen. Theater88 (Diskussion) 20:48, 20. Feb. 2019 (CET)

Warum veraltet? Siehe u.a. Vorlage Diskussion:Infobox Fluss/Archiv/3#Abflussparameter.

Wenn ich mich recht erinnere, geht es i. W. darum, die Zweigleisigkeit in der Box zu beseitigen. Ein Abflusspegel ist nach der Menge seiner Attribute auch nur ein Pegel wie jeder andere, wieso ihn also in Parametern anders realisieren? Wenn endlich alle Boxen mit Parametersatz ABFLUSS* ausgeputzt sind, wird dann auch der Code der Infobox einfacher; die Code-Blöcke für PEGEL1, PEGEL2 und PEGEL3 im Code unterscheiden sich nur im „Index“ i=1/2/3 der verwerteten Parameter PEGELi. Den Block ABFLUSS kann man nach Akrualisierung des Bestandes dann löschen. In der bestehenden Formatvorlage sind die alten ABFLUSS*-Parameter schon beseitigt, wenn also (hoffentlich) niemand mehr mit veralteter alter privater Box-Formatvorlage arbeitet, kommt auch nichts Neues mehr dazu und das Ende von ABFLUSS ist absehbar, zumindest wenn hier nun entschieden ist, was wir in den Fällen tun, wo PEGEL1, PEGEL2 und PEGEL3 schon alle besetzt sind, aber zudem auch noch ABFLUSS verwendet wird. --Silvicola ^Disk 21:46, 20. Feb. 2019 (CET)

Fehlende MHQ- und HHQ-Werte in DE-BW

In der amtlichen Quelle

Hochwasservorhersagezentrale, Landesanstalt für Umwelt Baden-Württemberg

findet man die Niedrigwasserwerte, aber nicht die beiden Hochwasserwerte, stattdessen (modellierte) Hochwasserwerte mit verschiedenen Jährlichkeiten. (Reichlich merkwürdig ist das übrigens, denn zumindest bei den nicht schiffbaren und nicht für Kraftwerkskühlung benutzten Flüssen scheinen mir die Niedrigwerte unwichtiger zu sein als die gefährdenden Hochwerte.) Bisher habe ich dort deshalb die (Positions-)Parameter in PEGEL1 usw. für MHQ, HHQ und HHQ-Datum immer leer gelassen. Sollte man stattdessen zumindest für HHQ den Wert für das 100-jährliche (bzw. maximal-jährliche) Hochwasser einsetzen und unter NACHWEIS-PEGELXX in kleiner Schrift und neuer Zeile am Ende auf den „Missbrauch“ das Parameters für HQ100/HQSoundso hinweisen? --Silvicola ^Disk 09:34, 21. Feb. 2019 (CET)

Wenn Du auf das Datenblatt Deutsches Gewässerkundliches Jahrbuch gehts, bekommmst Du alle Daten.--Anarabert (Diskussion) 10:20, 21. Feb. 2019 (CET)

PS: Klick auf DGJ-Seite (Q) für Pegel Wiesloch / Leimbach → Pegel Wiesloch--Anarabert (Diskussion) 10:24, 21. Feb. 2019 (CET)

Oder nimm diese Karte--Anarabert (Diskussion) 10:32, 21. Feb. 2019 (CET)

Diese Karte hat auch schöne Höhenlinien---Anarabert (Diskussion) 10:38, 21. Feb. 2019 (CET)

Einen Klickbutton zur Hinführung auf die passende Seite des DGJ habe ich bei HVZ nicht gesehen. Oder muss man über {{GeoQuelle|DE-BW|GKJB-09|}} usw. einsteigen und darin erst mal die Stecknadel suchen? --Silvicola ^Disk 15:57, 21. Feb. 2019 (CET)

Es zeigt sich, dass nur einige Pegel diese Option anbieten.--Anarabert (Diskussion) 16:06, 21. Feb. 2019 (CET)

Nur diese Pegel verfügen über Jahrbucheinträge.--Anarabert (Diskussion) 16:40, 21. Feb. 2019 (CET)

Hier noch ein allgemeiner Überblick über Pegelwerte, auch im benachbarten Ausland (einfach auf das jeweilige Land klicken) --Anarabert (Diskussion) 17:03, 21. Feb. 2019 (CET)

Veraltet

Hallo

In der Liste [2]. Nur der Wachwitzbach ist noch in der Liste könnte einer von euch mal drüberschauen was noch nicht passt?

Zweiter Punkt wäre ob man die Veralteten Parameter gelöscht werden sollen? 05:56, 23. Mär. 2019 (CET) (incognito signierter Beitrag von Theater88 (Diskussion | Beiträge) )

Hallo,

Beim letzten Bach waren es die "BEKANNTEN BRÜCKEN". Habe ich entfernt und die Wartungsseite ist leer.

Gruß --SteveK ?! 19:36, 23. Mär. 2019 (CET)

Na dann so schnell wie möglich raus mit den veralteten Parametern! Wenn möglich auch noch so einrichten, dass die Nutzer veralteter orivater Formatvorlagen von der Vorschau einen knallroten Nasenstüber bei der Nutzung der Parameter bekommen. --Silvicola ^Disk 23:23, 23. Mär. 2019 (CET)

Durch Theaters derzeitige Hyperaktivität im Boxenupdate merkt man erstmal, wie viele Flüsse man auf der Beo hat ... --Elop 07:12, 24. Mär. 2019 (CET)

Und dass die gewöhnlich still sind wie der Don.

Übrigens würde ich vorschlagen, anders als Theaters jüngste Aktivitäten es anzeigen, die HTML-Kommentare für die zehn Segmente von PEGEL1 usw. in den Vorlageneinbindungen stehen zu lassen. Ich zumindest kann mir nicht merken, welches Datum da in welches Element gehört; entsprechend gebremst ist, wohl nicht nur bei mir, der Eifer für die Kontrolle. Ich müsste ohne diese Hilfe und Gedächtnisstütze stets die Parameterbeschreibung der Infobox oder meine private Fluss-Artikelvorlage daneben öffnen, um erst einmal von Position in Bedeutung zu übersetzen. --Silvicola ^Disk 08:01, 24. Mär. 2019 (CET)

Seh ich auch so!

Bin übrinx gespannt, ob nach Portaldisk der andere Beofluter nun die neuen Kats wieder entfernt oder auch in andere Regionen der Beo transferiert. --Elop 09:14, 24. Mär. 2019 (CET)

Ihr beiden seid aber soweit ich das sehe auch diejenigen, die die meisten Flüsse bearbeitet haben. Der Stubser ist auch drin. Theater88 (Diskussion) 18:08, 26. Mär. 2019 (CET)

Danke für den Stubser. Bei manchen Dingen hilft nur Vergatterung, und je automatisch-unpersönlicher, desto besser.

Ein Vorzug, wenn man noch nie eine brauchbare Hessenkarte hatte: Kannitverstan, was ihr mit der zweiten BEO-Flutung meinen könntet.

Ich mache meine NR-Flutung (NR-Gliederung in Infobox-LAGE, teils auch in Abschnitt zum EZG) schön tröpfchenweise, immer auf den Spuren von derzeit auch nicht unfleißigen Gemeinden-Unterkategorisierern. Bald wird wohl in BW jede GEMEINDE eine Subkategorie Geographie (GEMEINDE) haben. Das hätte man, weniger Rigidität beim Subkategorisierungsquorum vorausgesetzt, schon länger und damit ohne die vielen inzwischen dazu fälligen Änderungen haben können. Aber die Heiligen Regeln!

--Silvicola ^Disk 02:02, 27. Mär. 2019 (CET)

Die zweite Beo-Flutung betraf die Naturraumkategorien - die ja momentan erst einmal nicht weiter angelegt, sondern diskutiert werden (die werden auf Deiner Beo weniger aufgetaucht sein, da der Zweitfluter zunächst weiter nördlich unterwegs war). Es gab Tage, da fingen 90 % der auf meiner Beo auftauchenden Bearbeiter mit "A" oder "T" an. --Elop 07:39, 27. Mär. 2019 (CET)

Ja, bis zur Diskussion wurde fleißig "geflutet", sogar bei Bergen.--Anarabert (Diskussion) 09:28, 27. Mär. 2019 (CET)

Nicht gesehen, nicht gewusst, aber mir doch gedacht, nachdem mir die eifrige Kategoriendiskussion durchaus nicht entgangen war. Der Name Kannitverstan ist so ein bisschen ironisch. --Silvicola ^Disk 12:02, 27. Mär. 2019 (CET)

Die Geschichte hatten wir durchaus bei Fräulein Dr. Junges in Deutsch gehabt. --Elop 12:19, 27. Mär. 2019 (CET)

Immer fleißig der Altvorderen gedenken, denn

Die haben alles hinter sich

Und sind, gottlob, recht tugendlich

ganz anders als die Gören. „Ihr seid alle Verbrecher!“ brach es einmal aus einem Fuchtelinhaber an meiner Schule heraus. Er hatte nicht ganz Recht damit, aber doch ziemlich. --Silvicola ^Disk

Früher war eh alles besser Theater88 (Diskussion) 21:39, 3. Apr. 2019 (CEST)

La vie de St- Alexis, XI. Jahrhundert

Bons fut li siecles al tens ancienor,
Quer feit i ert e justise et amor,
Si ert credance, dont or n’i at nul prot ;
Toz est mudez, perdude at sa color :
Ja mais n’iert tels com fut als ancessors.
 
[…]

――――――――――――――――

Gut war die Welt in älterer Zeit,
Denn Treue gab's und Gerechtigkeit und Liebe,
Ja, damals gab's Glauben, an den sich heute keiner mehr tapfer hält;
Alles ist verändert und hat seine Farbe verloren:
Niemals mehr war es so, wie es bei den Ahnen war.
 
[…]

――――――――――――――――

--Silvicola ^Disk 04:45, 4. Apr. 2019 (CEST)

Wie wahr, wie wahr.

Schönes Gedicht. Theater88 (Diskussion) 17:07, 4. Apr. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Theater88 (Diskussion) 17:07, 4. Apr. 2019 (CEST)

Fehler bei Pegelname: automatische Verlinkung

Siehe: Pfinz.

Komplexe Verlinkung des Pegelnamens (Feld 1 von PEGEL1 usw.) ist offenbar bei Links mit Linktext nicht zulässig, versucht man es, wird der ganze Pegelsatz nicht angezeigt. Wohl wegen des Sonderzeichens Pipe. Schön – oder vielmehr nicht schön) – aber gut.

Wieso wird aber dort nun, obwohl nur der Text

Berghausen

eingetragen ist und nicht etwa das wünschenswerte (und störende)

[[Berghausen (Pfinztal)|Berghausen]]

ungefragt der verlinkte Texteintrag analog

[[Berghausen]]

dargestellt? --Silvicola ^Disk 16:57, 2. Apr. 2019 (CEST)

Jetzt sollte es wieder wie vorher sein.

(nicht signierter Beitrag von Theater88 (Diskussion | Beiträge) 2. Apr. 2019‎, 17:34 Uhr)

Danke! --Silvicola ^Disk 00:59, 3. Apr. 2019 (CEST)

Man könnte als 10 Punkt das Linkziel des Pegels einbauen. Wenn nichts angegeben könnte man es unverlinkt lassen. Theater88 (Diskussion) 21:39, 3. Apr. 2019 (CEST)

Bild fehlt

Weshalb ignoriert denn die Infobox in Luma (Drin) mein BILD1 und BILD2?

Danke, --Lars (User:Albinfo) 18:27, 18. Mär. 2019 (CET)

Hat sich das Problem bereits erledigt? Wenn nicht müssten wir mal bei Vorlagenprogrammierern nachfragen. Theater88 (Diskussion) 21:39, 3. Apr. 2019 (CEST)

NordNordWest scheint eine Lösung gefunden zu haben: [3] --Lars (User:Albinfo) 20:25, 10. Apr. 2019 (CEST)

Schrift zu klein

Die Schrift der Infobox ist zu klein. Die Schrift ist deutlich kleiner als der Fließtext des Artikels. Das ist mühsam zu lesen. Ich habe auf meinem Rechner (Apple Mac) keine Änderungen hinsichtlich der Schriftdarstellung vorgenommen und unter diesen default-Einstellungen sieht es einfach zu klein aus. Die Überschrift müsste auch etwas größer sein als der eigentliche Text der Infobox. --Furfur ^{⁂ Diskussion} 14:16, 5. Nov. 2019 (CET)

Die kleine Schrift wurde durch die letzte Änderung im Mai eingeführt, wohl ohne Abstimmung hier. Gleichzeitig wurde die Box 10% schmaler gemacht. Ich habe das jetzt zurückgesetzt. --SteveK ?! 15:25, 5. Nov. 2019 (CET)

Vielen Dank. Ich finde, dass die reguläre Schrift einer Infobox nicht kleiner sein sollte als 95 % (von Bildunterschriften, Fußnoten. etc. einmal abgesehen). Man sollte die Schrift nicht einfach verkleinern, nur weil man eine bestimmte Breite der Infobox erzielen will. In solchen Fällen muss man sich eine andere Lösung einfallen lassen. Ich habe auch den Eindruck, dass auf dem Mac alles etwas kleiner ausfällt, als auf Windows-Rechnern. Das müsste man auch berücksichtigen. Grüße --Furfur ^{⁂ Diskussion} 19:01, 5. Nov. 2019 (CET)

Prinzipiell kann man natürlich auch im Browser zoomen und damit die Schrift größer machen. Das man an Infoboxen Formatänderungen macht ohne die vorher zu diskutieren, dass ist eigentlich ein Unding. Mir ist das aber auch erst nach deinem Posting hier aufgefallen. Gruß --SteveK ?! 19:27, 5. Nov. 2019 (CET)

Die Schrift kann man natürlich in den Voreinstellungen vergrößern, das ist klar. Aber ich denke, die Schriftgröße, Bildgröße, u.ä. müssten so gewählt sein, dass es mit den default-Browser- und Benutzer-Einstellungen akzeptabel ist. Wenn ich erst die Browsereinstellung ändern muss um Wikipedia-Seiten akzeptabel darzustellen, wird es anstrengend. Das muss man bei anderen Webseiten ja auch nicht tun. Gruß --Furfur ^{⁂ Diskussion} 20:34, 5. Nov. 2019 (CET)

Groß- oder Kleinschreibung

Im Beispiel wird alles in der Infobox mit einem Großbuchstaben begonnen, außer bei "Schiffbar" (nur zur Regenzeit). Gibt es dazu eine Regel. Bei anderen Infoboxen wird häufig alles klein geschrieben, z. B. bei Fluggesellschaften und deren Zielen "national" anstatt "National". Danke --Chtrede (Diskussion) 17:40, 27. Nov. 2019 (CET)

Ich verstehe nicht ganz, worum es geht.

• Wenn die Formatvorlage auf der umseitigen Vorlage nicht täuscht, dann wird SCHIFFBAR genauso geschrieben wie alle anderen Parameternamen, nämlich nur in Majuskeln.
• Eine generelle Umstellung auf Parameternamen nur in Kleinbuchstaben, wenn denn darauf das Ansinnen ginge, wäre sehr mühselig und ist sinnlos, weil es nie eine generelle Einigung auf Regeln für die Wortwahl und die Schreibweise von Parameternamen über den gesamten Vorlagen-Namensraum hinweg gegeben hat und angesichts des obwaltenden Konservatismus deshalb wohl auch nie mehr geben wird. Bitte nicht die schlafenden Hunde eines Regelpedantismusses zu wecken.
• Die Großschreibung des Zeilenkopfes Schiffbar, onwohl das Wort ein Adjektiv ist, scheint mir durch Schreibkonformität zwischen allen Spaltenköpfen völlig legitimiert.'

--Silvicola ^Disk 18:52, 27. Nov. 2019 (CET)

Es geht natürlich um die einzutragenden Werte! Schaut Euch einfach das Beispiel an, dann versteht ihr was ich meine :-) --Chtrede (Diskussion) 19:57, 27. Nov. 2019 (CET)

Ich würde, außer wo der Anfang des Eintrags, ob nun Satz oder bloßes Syntagma, aus schieren grammatischen Gründen (Eigenname, sonstiges Substantiv, Satzanfang usw.) groß zu schreiben geboten ist, immer mit Minuskel beginnen. Weshalb ich zum Beispiel recht häufig bei Einträgen für den Mündungsort ein vorgefundenes Bei Xdorf […] in bei Xdorf […] ändere. Was dann aber zeigt, weil ich das nämlich recht oft mache, dass dazu andere anderer Ansicht sind. (Es wird aber gegen meine Änderung fast nie protestiert.) Meine Regel hierbei ist: „In der Box möglichst telegraphischen Stil benutzen, aber dabei doch stets das Wesentliche sagen.“ Satzwertige Einträge setze ich übrigens allenfalls in extremen Einzelfällen ein. --Silvicola ^Disk 21:49, 27. Nov. 2019 (CET)

Danke, das entspricht auch meiner Meinung, d. h. "bei XYZ" und nicht "Bei xyz". Aber es scheint dazu, anders als in anderen Fachbereichen, keine klare Regelung zu geben. --Chtrede (Diskussion) 05:27, 28. Nov. 2019 (CET)

Font-size: 95%

Schriftbeispiele

Hallo zusammen. Nachdem ich die Änderung auf Font-size: 100% von Antonsusi mit der Bemerkung das erst hier anzusprechen revertiert hatte, postete er auf meiner Disk folgenden Text:

=== Übertragung ===

Hallo. Hier meine Gründe gegen eine Skalierung auf 95 %:

• In einer Infobox befinden sich fast immer so kurze und so geartete Zeichenketten, dass sie entweder in eine Zeile passen oder sowieso einen gezielten Zeilenumbruch an festgelegter Stelle benötigen. Das bedeutet, dass man mit 95 Prozent so gut wie nie einen Zeilenumbruch vermeiden und damit die Länge der Infobox wesentlich verringen kann.
• Des weiteren ist die allgemein empfohlene Standardgröße für eine Schrift im Browser 16 Pixel. Bei dieser Schriftgröße wird ein Großbuchstabe mit einer Höhe von 12 Pixeln dargestellt. Verringert man die Größe auf 95 %, so wird er im Browser nur noch 11 Pixel hoch dargestellt. Damit ist er aber auch mit Graustufen-Interpolation nicht mehr so genau darstellbar wie mit 12 Pixel, denn die "Bildauflösung" ist 1/12 schlechter. Bei Kleinbuchstaben sind es sogar ca. 15 %. Das bedeutet: Dem Vorteil, nur einen oder selten zwei Pixel an Boxenlänge pro Infoboxzeile einzusparen, steht eine drastische Verschlechterung der Lesbarkeit der Schriftzeichen entgegen, was insbesondere für ältere Leser ein großer Nachteil ist. Dieser wird noch dadurch verschärft, dass es kein Fließtext mit Wörtern sondern Wertangaben wie Ziffern sind. Fazit: 95 % sind eine nicht zu empfehlende Unsitte in unseren Infoboxen. Gruß von ÅñŧóñŜûŝî (Ð) 22:59, 27. Nov. 2019 (CET)

=== Übertragung Ende ===

Ich bin der Ansicht, dass solche Änderungen hier vorher besprochen werden sollten. --SteveK ?! 11:46, 28. Nov. 2019 (CET)

Deine Rechnung Antonsusi ist eine Milchmädchenrechnung. Ich habe mir gerade beide Schriften per Screenshot angeschaut. Entgegen meiner Erwartung waren beide Schriften nicht rein Schwarz oder Weiß sondern etwa gleich bunt. Selbst bei einer Größe von 150% ist die Schrift nicht ganz klar. Eine drastische Verschlechterung von 100% zu 95% ist nach meiner Ansicht nicht gegeben. Um die Lesbarkeit zu erhöhen werden auch ältere Personen als ich einfach den Browserzoom verwenden. Damit ist für mich der zweite Punkt abgehakt.

Der ersten Punkt ist eher gestalterischer Natur. Bisher ist bei der Größe von 95% keine Beschwerde zur Lesbarkeit gekommen, bei 90% jedoch schon. Die heutige Breite der Box und auch die Schriftgröße ist historisch gewachsen als die Bildschirmauflösung noch eine Bildbreite von 1024 Pixeln hatte. Das spielt heute auf Bildschirmen keine Rolle mehr, auf den kleinen Helferlein jedoch schon. Änderungen sollten da schon etwas besser durchdacht werden. --SteveK ?! 14:23, 28. Nov. 2019 (CET)

@Antonsusi: Nachtrag: Ich habe jetzt zwei Scrrenshots gemacht, in Photoshop zusammengesetzt und vergrößert. Beide Schriften sind ziemlich bunt wie man jetzt sieht. --SteveK ?! 20:38, 28. Nov. 2019 (CET)

Warum sind die bei dir so bunt? Ich habe bei einem Screenshot - ich habe reines Schwarz auf Weiß als Fließtext - naheliegend nur Graustufen, wenn ich abgemeldet bin und meine Styles nicht wirken. Melde dich mal ab und probiere es nochmal. ÅñŧóñŜûŝî (Ð) 21:08, 28. Nov. 2019 (CET)

Ich habe das im ausgelockten Zustand überprüft, da kommt das gleiche Ergebnis. Vermutlich ist das Verhalten abhängig vom Betriebssystem und/oder Browser (bei mir Windows und Firefox). Warum das so ist, kann ich nicht sagen. Letztich ist das auch egal, denn beide Schriftgrößen müssen Abstufungen für Bögen und Schrägen verwenden. Die Qualitätseinbuße zwischen beiden ist marginal. Aus meiner Sicht spricht nix gegen 95% und für 100%.--SteveK ?! 11:18, 29. Nov. 2019 (CET)

Ich habe mir den Unterschied bei der Infobox für die Rhone angeschaut: es sind 53 Pixel Längendifferenz. (von 1194 auf 1247) ÅñŧóñŜûŝî (Ð) 21:20, 28. Nov. 2019 (CET)

Umstrittene Parameter auf „optional“ setzen

Wenn jemand im VisualEditor einen Parameter der Infobox ändert, werden dabei alle in Vorlage:Infobox Fluss/Doku als „vorgeschlagen“ eingetragenen Parameter ergänzt (siehe etwa Spezial:Diff/194478581). Dazu gehören derzeit u.a. LINKE NEBENFLÜSSE, RECHTE NEBENFLÜSSE, GROSSSTÄDTE, MITTELSTÄDTE, KLEINSTÄDTE und GEMEINDEN. Ich schlage vor, die genannten wie auch SEEN, STAUSEEN, EINWOHNER IM EINZUGSGEBIET, HÄFEN und SCHIFFBAR auf „optional“ zu setzen. Sie werden dann allerdings auch bei einer im VisualEditor neu eingefügten Infobox nicht angezeigt. -- Olaf Studt (Diskussion) 17:22, 29. Nov. 2019 (CET)

Kein Einwand gegen den Vorschlag. --Silvicola ^Disk 03:08, 18. Dez. 2019 (CET)

Einheitenwechsel beim Sohlgefälle

Ich finde es nicht gut, als „Einheit“ des Sohlgefälles manchmal ‰, manchmal % zu generieren. Ich schlage vor, einheitlich ‰ zu nehmen, das ergäbe für die vermutlich meisten Gewässer eine Darstellung mit 1 VKs + Komma + NKS. Keiner käme auf die Idee, analog im Wechsel mal Liter, mal Deziliter für Volumenangaben zu nehmen. Unterschied in beiden Fällen nur eine Zehnerpotenz. was zu wenig ist –Liter neben Kubikmeter geht dagegen an – auch angesichts der leicht möglichen Verwirrung, da sich die beiden Symbole auch nur durch ein kleines Nüllchen unterscheiden.

Die Zahl würde nach diesem Vorschlag dann bei steilen Gewässern recht breit? – Umso besser, dann fällt es auch auf!

Als kleiner Bonus wird auch noch eine Fallunterscheidung im Code verzichtbar. --Silvicola ^Disk 03:23, 18. Dez. 2019 (CET)

Da hat sich wieder einer viel Mühle gemacht, die mMn nicht notwendig ist. Da gibt es Formtierungen mit 3, 2, 1, 0 Nachkommastellen. Was soll der Unfug. Einfach in ‰ mit 1 Nachkommastelle gut gut ist es. --SteveK ?! 08:09, 18. Dez. 2019 (CET)

Na ja, bei etwa in ‰ dargestellt drei Vorkommastellen (kommt bei meinen frischrheinischen Klingenbächen und sicher auch bei Gletscherbächen in den Alpen vor) sollte jedenfalls gar keine Nachkommastelle mehr kommen und vielleicht sogar die letzte Vorkommastelle durch Auf- oder Abrunden auf 0 gebracht werden. --Silvicola ^Disk 10:23, 18. Dez. 2019 (CET)

Bezeichnung Mündung

Würde es Sinn machen wenn der Wert bei BEZEICHNUNG-MÜNDUNG (falls eingegeben) direkt in das Anzeigefeld - Abfluss - Lage oberhalb der "Mündung" - Übernommen würde? Es hat ja nicht jedes Fließgewässer (zB. Okavango) eine Mündung. Gruß --Peter in s (Diskussion) 12:58, 28. Feb. 2020 (CET)

Ich glaube das macht nicht viel Sinn, da dann beim Okavango "Lage oberhalb des Delta" steht und der Bezugspunkt nicht genau ist. Der anzugebende Wert soll eine genaue Lokalisierung des Messpunktes ermöglichen, da würde nur eine Kilometerangabe mit exaktem Referenzpunkt / bzw. eine Koordinatenangabe weiterhelfen. Bei der Implementierung haben wir mehr an die Normalfälle gedacht, die Sonderfälle sind immer extrem schwer umzusetzen. --SteveK ?! 13:54, 28. Feb. 2020 (CET)

Karten bzw. Hochkant-Bilder

Die derzeitige Begrenzung der Kartendimensionen in der Infobox scheint mir nicht sinnvoll. Karten, die etwas höher sind, werden "zurechtgestutzt", so dass rechts und links davon ein unschöner freier Rand entsteht. Die Kartendimensionen soll man doch besser den individuellen Artikelautoren überlassen, anstelle dass man das zentralistisch regelt. Die maximale Kartenbreite soll natürlich konstant und nicht veränderbar sein, aber das derzeitige Prokrustes-Verfahren ergibt zum Teil unschöne Ergebnisse. Die Kartenbeschriftungen sind ja auch je nach Karte ganz unterscheidlich. Derzeit kann man teilweise in der Vorschau kaum etwas erkennen. --Furfur ^{⁂ Diskussion} 12:09, 5. Jul. 2020 (CEST)

Hallo Furfur, etwa drei Beispiele wären hilfreich ;-) . --Telford (Diskussion) 14:16, 5. Jul. 2020 (CEST)

Hallo Telford, es fiel mir z. B. auf bei der Karte im Artikel zum Nil in seiner alten Version. Hier sind die Ränder rechts und links praktisch genauso groß wie die eigentlich Karte. Das sieht wirklich sehr unschön aus. Mittlerweile habe ich die Karte überarbeitet, ins Deutsche übersetzt und bewusst verbreitert, damit sie nicht so hoch und schmal ist, aber auch in dieser neuen Version gefällt es mir nicht richtig. Immer noch sind Ränder da.
Grundsätzlich gefällt mir auch die Einstellung nicht so ganz, dass man die Karten der Infobox in ein so festes Korsett presst. Wir sind uns sicher alle einig, dass manche Karten einfach zu hoch und zu schmal sind, als dass man sie in ihrer ganzen Höhe in die Infobox in voller Größe übernehmen könnte. Diese Karten könnten dann verkleinert werden, oder (auch diese Mögichkeit sollte man nicht übersehen) ganz in der Infobox weggelassen werden. Manchmal ist vielleicht das verfügbare Kartenmaterial nicht für eine Infobox geeignet. Es ist sicher sinnvoll, dass die Infobox eine feste Breite hat, die nicht überschritten werden soll, damit die Infoboxen einheitlich aussehen. Aber ob eine Karte zu hoch ist für eine Infobox, oder verkleinert werden muss, dieses Urteil sollte doch den Artikelautoren überlassen sein. Das sollte nicht für viele Tausende Karten zentral festgelegt sein. Wenn man die Bildbreite zentral reguliert, erreicht man gerade eben das Gegenteil von dem was man wahrscheinlich anstrebt: die Bilder sehen ganz unterschiedlich groß aus und zerstören die Einheitlichkeit der Optik. Ich hoffe, es ist klar geworden, was ich meine. Grüße --Furfur ^{⁂ Diskussion} 15:08, 5. Jul. 2020 (CEST)

Tja, ich hatte da eine Idee, die aber nicht funktioniert hat. Mehr fällt mir im Moment auch nicht ein. --Telford (Diskussion) 20:46, 5. Jul. 2020 (CEST)

Ich unterstütze das absolut!

Derzeit ist es genau so, daß der Nil völlig unnötigerweise zu klein dargestellt wird, nur weil man den Amazonas eh in der Box nicht hinreichend darstellen kann.

Wer läßt sich sowas einfallen? --Elop 23:22, 5. Jul. 2020 (CEST)

Habe ich etwas verpasst? Lest euch bitte mal die Parameterbeschreibung zum Parameter "KARTE-BREITE" durch. Da habe ich wohl richtig gedacht das man neben einer Standardeinstellung auch eine Alternative anbietet. --SteveK ?! 00:31, 6. Jul. 2020 (CEST)

Wenn ich Furfur richtig verstehe geht es ihm darum, dass Karten im Regelfalle so breit werden wie die Box, was auch mir sinnvoll erscheint. Bei besonders hohen und schmalen Bildern müsste man dann fallweise abweichen. Im übrigen ist da noch irgendwo ein Wurm drin: derzeit sind im Artikel "Nil" 326 px als Breite explizit angegeben und die Karte erscheint breit; ohne diese Angabe erscheint sie schmaler, obwohl 326 px lt. Dokumentation angeblich Standardbreite ist. Ich hatte vermutet, dass die Angabe "326x326p" in der Vorlage Auslöser dieses Problems sei, aber das scheint nicht der Fall zu sein, oder ich habe beim Testen Fehler gemacht. Allerdings finde ich beim Abmessen von Screenshots sowieso andere Maße; könnte hier ein responsives Design zuschlagen? --Telford (Diskussion) 06:36, 6. Jul. 2020 (CEST)

Der Parameter "326x326px" soll vor allem bei Bildern erreichen, dass hochkantige Bilder etwa gleich groß dargestellt werden wie querformatige Bilder. Der Parameter begrenzt also in beiden Dimensionen. Will man ein Bild auf die volle Boxenbreite formatieren, dann muss man 326px angeben, bei sehr schmalen Bildern werden diese dann sehr lang. Ich hatte das beim Nil in der Nacht umgestellt, da war vorher die Karte in einem Bildparameter. Das hat auch dazu geführt, dass deine Änderung an der Box im Artikel keine Wirkung zeigte. Im Artikel ist in der aktuellen Version die Karte wie gewünscht in Boxenbreite.--SteveK ?! 14:46, 6. Jul. 2020 (CEST)

"[...] da war vorher die Karte in einem Bildparameter. Das hat auch dazu geführt, dass deine Änderung an der Box im Artikel keine Wirkung zeigte." Und ich dachte schon, ich sei zu blöd für die Vorlagenprogrammierung; naja, war ich vielleicht auch, wer lesen kann ist klar im Vorteil. Bleibt die Frage, ob bei "leichtem Hochkant" (also nicht so extrem wie beim Satellitenbild des Nils) die Karte nicht automatisch in Boxenbreite erscheinen sollte; das wäre dann z.B. 326x434 px oder 326x488 px als Voreinstellung in der Infobox. --Telford (Diskussion) 15:57, 6. Jul. 2020 (CEST)

Es wird bei der Voreinstellung irgendwo mal ein abweichender Wunsch geäußert werden. Wer will kann das ja umsetzen, dazu muss er einen zusätzlichen Parameter verwenden. Oben war ja behauptet worden, dass die Breite nicht zu manipulieren sei, dem ist aber nicht so. Zu beachten ist, dass sämtliche Änderungen an den Bild/Karte-Einstellungen auch teilweise massive Layoutänderungen zur Folge haben. Deswegen wäre ich gegen eine Änderung, zumal das Beispiel Nil eben gelöst ist. --SteveK ?! 16:08, 6. Jul. 2020 (CEST)

Vielen Dank, die Nil-Karte in der Infobox kommt jetzt meiner Ansicht nach optimal zur Geltung. Habe ich es richtig verstanden, dass die Karte durch den Artikelautor mittels des Parameters KARTE-BREITE auf eine Breite von 326px eingestellt werden kann, unabhängig davon, wie hoch das Bild ist, bzw. wie die Bildabmesssungen insgesamt sind? Grüße --Furfur ^{⁂ Diskussion} 18:41, 6. Jul. 2020 (CEST)

Ja, bei der Karte ist der Parameter KARTE-BREITE mit dem Defaultwert "326x326px" vorbelegt, du kannst jeden anderen Wert dort eintragen, der die Breite bestimmt. Sollte nur nicht über die Boxbreite von 326px gehen. Die horizontale Position ist fix auf "center" eingestellt. Gleiches gilt analog auch für die Bilder.--SteveK ?! 20:19, 6. Jul. 2020 (CEST)

Bitte

Omatako (Fluss) wird nicht gemäß ISO für die Mündung der Region Kategorie:Fluss in der Region Kavango-Ost zugeordnet, sondern der übergeordneten Kategorie:Fluss in Namibia. Irgendwie scheint NA-KE nicht erkannt zu werden? Wer Kann helfen? --Chtrede (Diskussion) 17:26, 30. Jul. 2020 (CEST)

Gleiches Problem zeigt sich z. B. auch in Owambo (Fluss) mit einer anderen Region (NA-OT). --Chtrede (Diskussion) 10:14, 18. Aug. 2020 (CEST)

Ich habe mir die Vorlage:Info_ISO-3166-2:NA-OT angeschaut, danach müsste die Flusskat. Kategorie:Fluss in Oshikoto heißen, damit es klappt. Oder man müsste den "in"-Parmeter ändern. Bei NA-KE steht da ›in Kavango-Ost‹ drin. Wenn man das ändern will, dann muss man acht geben, dass alle Kategorien die automatisch befüllt werden betroffen und entsprechend geändert werden müssen. Es gibt nicht nur Flüsse die das nutzen. --SteveK ?! 16:50, 18. Aug. 2020 (CEST)

Nachtrag: Ich habe den fehlenden IN-Parameter in den ISO-Vorlagen eingetragen und die Kategorisierung geprüft. --SteveK ?! 16:59, 18. Aug. 2020 (CEST)

Millionenstädte ...

... könnte man vielliecht noch oberhalb von Großstädte anbieten.--Katakana-Peter (Diskussion) 09:26, 16. Sep. 2020 (CEST)

Oder man könnte endlich den ganzen Scheiß durch "Orte am Fluß" nebst "Kriterium" (ohne ein solches trägt jeder genau sein Heimatdorf ein) ersetzen, sodaß man endlich flußabwärts listen könnte. In Fulda (Fluss) hat man der Box nach keine Ahnung, wann Kassel kommt. Und besonders bescheuert ist die Liste der "Kleinstädte", die größere Städte dazwischen wegläßt. Ich komme also von Gersfeld nach Melsungen, indem ich über Schlitz, Bebra und Rotenburg fahre. Ist ungefähr so sinnvoll wie eine Liste der "kleinen" Nebenbäche oder "Kleinstädte an der A 2". --Elop 10:08, 17. Sep. 2020 (CEST)

Stimmt. Wäre das "Kriterium" dann die Einwohnerzahl? Könnte man das bei jedem Fluss anders festlegen (z. B. bei Flüssen in Asien nur Millionenstädte)? Wenn die Einteilung so bleibt wie sie ist: Kriegen es die Datenklempner vielleicht hin, dass eine Stadt automatisch ins richtige Kästchen springt, wenn sie eine bestimmte Einwohnerzahl über oder unterschreitet?--Katakana-Peter (Diskussion) 06:24, 18. Sep. 2020 (CEST)

Kriterium wäre immer so festzulegen, daß eine sinnvolle Anzahl (z. B. 5 bis 12) rauskäme. Einwohnerzahl oder auch Stadtrechte (ist glaubich bei der Fulda de facto Kriterium) wären gut denkbar.

Für Wolga oder Janktsekiang würde sich nichts ändern, da dort eh keine "Mittelstädte" in die Boxen kämen. Ob man da "Millionenstädte" nähme, wäre je flußindividuell zu entscheiden. Es gibt auch Flüsse, die von einem Ballungsgebiet in die Wallachei fließen. Da könnte man auch sicherstellen, daß man min. alle 50 km einen Ort angibt (z. B. im Mittelllauf ab 100.000 und im Unterlauf ab 20.000).

Bei der Ruhr z. B. würde man eine Kleinstadt im Ruhrgebiet (gibt es aber nicht) eher nicht mitnehmen, Olsberg aber sicher (und Winterberg ist eigentlich nicht ganz korrekt). --Elop 10:45, 18. Sep. 2020 (CEST)

Ach so, nochne Meinung:

Daß in vielen Artikelintros "Ickshausen ist eine Mittelstadt" steht, ist eh Humbug. Der Begriff ist völlig unüblich (und statusfrei - anders als "Große kreisabhängige Stadt") und "Stadt mit 42.000 EW" sagt deutlich mehr und eindeutiger aus.

Der Begriff wurde vor 150 Jahren von den Preußen erfunden und bezog sich explizit auf Städte im landläufigen Sinne und nicht auf Großgemeinden mit Stadtrecht.

"Großstädte" waren damals ca. die heutigen Halbmillionenstädte, aber der Begriff wurde halt nicht angepaßt und hat zumindest überlebt.

Salzgitter war aber sicher nicht gemeint. Damals wäre vermutlich Lebenstedt per Entwicklung zur Mittelstadt erklärt worden. --Elop 10:55, 18. Sep. 2020 (CEST)

"Orte am Fluß" fände ich gut, Kriterium solle nicht absolut sein, sondern z.B. die 3-7 größten. --bjs 19:34, 17. Okt. 2020 (CEST)

Kategorisierung

Die Infobox wird auch für Kanäle angewendet. Dort erscheinen dann automatisch mehrere "Fluss in ..."-Kategorien. Ist das erwünscht? Kanäle werden normalerweise als Gewässer und Bauwerk kategorisiert, aber nicht als Fluss. Soltee die Box raus aus Kanälen? kann man das hier übert einen Parameter einstellen? --bjs 19:34, 17. Okt. 2020 (CEST)

Kommt darauf an, welche Art von Kanal beschrieben wird. Für Schifffahrtskanäle gibt es die Infobox Schifffahrtskanal. --Skipper69 (Diskussion) 10:42, 18. Okt. 2020 (CEST)

Umbenennung auf Infobox Fließgewässer

Ich würde eine Umbenennung vorschlagen mit Weiterleitungen von Infobox Fluss und Infobox Bach. De facto wird diese Vorlage für Fließgewässer aller Art benutzt bzw. kann dafür benutzt werden, daher Definition falsch.--Nexo20, Sichter (Diskussion, Projekte) 20:03, 8. Nov. 2020 (CET)

Bitte schnellbeenden. Es ist ja echt toll, daß Nexo Sichter geworden ist (superherzlichen Glückwunsch dazu), aber damit iss auch gut. --Elop 00:14, 9. Nov. 2020 (CET) --Elop 00:14, 9. Nov. 2020 (CET)

„Da Wikipedia ein Projekt sein sollte, wo nicht der Einzelne, sondern die Arbeit der Gemeinschaft zählt, ...“ Jetzt hab ich doch tatsächlich vergessen, woher dieses Zitat stammt ... hm. In der Guten Alten Zeit galt jedenfalls noch die Regel, dass wir nicht ad personam, sondern ad rem argumentieren.--Katakana-Peter (Diskussion) 05:10, 9. Nov. 2020 (CET)

Zu meinem Bedauern verstehe ich euch nicht...könntet ihr bitte ausführen?--Nexo20 (Diskussion) 17:36, 9. Nov. 2020 (CET)

Info: Spezial:Gewünschte Seiten zeigt Rotlinks der Vorlage

Moin Moin zusammen, auf der o.g. Spezialseite, werden viele Rotlinks der Vorlage aufgezeigt. (KARTE fehlt, usw.) Das wird ja heute eher über Wartungskategorien gemacht. Könnte das jemand umbauen? mfg --Crazy1880 18:10, 3. Nov. 2020 (CET)

Anzeige von FLUSSSYSTEM bei fehlendem Hauptfluss-Artikel

@SteveK: In Adschiszqali und Bschuschi wird der Parameter FLUSSSYSTEM unschön angezeigt. Ich habe so was schon mal erlebt, aber nicht weiter verfolgt – vielleicht war das immer so und fiel nie auf, weil der Hauptfluss-Artikel selten fehlt und wenn, dann meist keinen Klammerzusatz hat. -- Olaf Studt (Diskussion) 22:22, 21. Jan. 2021 (CET)

Ich habe jetzt festgestellt, dass der Artikel Natanebi (Fluss) und Natanebi fehlt. Wenn kein Artikel vorhanden, dann wird der Text durchgereicht. Isi die Frage, ob das Verhalten geändert werden soll? --SteveK ?! 09:15, 22. Jan. 2021 (CET)

Automatische Vergabe von Kategorien

Gibt es Schwierigkeiten mit der automatische Vergabe von Kategorien, wenn die Kategorie:Flusssystem Landquart (Fluss) in Kategorie:Flusssystem Landquart umbenannt wird (siehe hier)? --Anarabert (Diskussion) 15:22, 19. Dez. 2020 (CET)

Für Flüsse standardmäßig "All Coordinates"-Einstellung verwenden, zumindest wenn mehr als eine Koord. vorliegt

Hallo, was mich an der Infobox Fluss schon seit langem stört, ist, dass es eine Koordinate rechts oben gibt, mit der man in einen Kartendienst kommt, obwohl ein Fluss i.d.R. mindestens zwei Koordinaten hat (Mündung und Quelle) und man den gesamten Flusslauf im Kartenausschnitt sehen möchte. Es gibt nun offenbar einen Workaround mit Nebenbox=ja, all coordinates-Zeile und manueller Angaber der Flusssystem-Kategorie. Das ist aber umständlich und nicht wirklich konsistent.--Slimguy (Diskussion) 08:49, 24. Apr. 2021 (CEST)

Hallo Hast du ein Beispiel? Muss nicht zwingend ein Fluss sein. --Gruß Michael Hoefler50 Diskussion Beiträge 09:16, 24. Apr. 2021 (CEST)

Den Workaround kannte ich bis vor ein paar Tagen nicht. Schaue Dir doch den Artikel "Rio Taquari (Río Paraguay)" oder "Rio Jacuí" an. Da gibt es 3 oder mehr Koordinaten-Links.--Slimguy (Diskussion) 18:16, 24. Apr. 2021 (CEST)

Hallo zusammen, das mit der Nebenbox halte ich für den falschen Weg. Ich kann mir hier verschiedene Lösungen vorstellen:

1. Werden beide Koordinaten angegeben, dann wird statt der Mündungskoordinate als die Vorlage:All Coordinates gesetzt. Nachteil dieser Variante ist, dass bei nur einer Koordinatenangabe in der IB die Artikelkoordinate gesetzt würde, auch wenn weitere Koordinaten im Fließtext stehen. Vorteil ist, wir kommen ohne neuen Parameter aus.
2. Wird eine der beiden Koordinaten angegeben, dann wird gleich Vorlage:All Coordinates gesetzt. Nachteil ist hier, dass bei nur einer Koordinate keine Artikelkoordinate erscheint. Vorteil ist, wir kommen ebenfalls ohne neuen Parameter aus.
3. Wir steuern das mit einem neuen Parameter. Nachteil wäre der neue Parameter. Vorteil ist, dass man das wahlweise setzen kann, ohne die automatische Kategorisierung abzuschalten.

Nachteil der Verwendung von Vorlage:All Coordinates ist, dass in der dabei geöffneten Karte der Flusslauf nicht hervorgehoben wird (Beispiel für Flusslaufdarstellung: Hillbringse). Das sollte genau überlegt werden. --SteveK ?! 20:03, 24. Apr. 2021 (CEST)

Hallo, wieviele Fluss-Artikel mit Flusslaufdarstellung gibt es überhaupt? Man erkennt an dem Link nicht, dass sich dahinter eine Flusslaufdarstellung verbirgt. Bei All Coordinates: In der Regel erkennt man auf der Karte den Flusslauf zwischen den Quell- und Mündungskoordinaten bzw. der Lage der weiteren Koordinaten, die i.d.R. entlang dem Flusslauf liegen. Man müsste sich nicht für alle möglichen Flüsse die Mühe machen, eine Flusslaufdarstellung zu erstellen.--Slimguy (Diskussion) 19:37, 25. Apr. 2021 (CEST)

Die Flusslaufdarstellungen wie meinen Beispiel kann man über OSM erreichen, man muss dort nur die entsprechende Relation mit dem WP-Artikel verknüpfen. Der Rest passiert meines Wissens automatisch. Wieviele Artikel so was zulassen kann ich nicht sagen. --SteveK ?! 15:47, 26. Apr. 2021 (CEST)

Statt WP-Artikel (=Lemma), also wikipedia=de:Lemma wäre wikidata=Q123456 in OSM universeller.
NMUM könnte doch in die Vorlage ‚All Coordinates‘ fest eingebaut werden, dann auch NEBENBOX=1 (oder ja, oui, yes, da) sonst wird es hässlich. Steht im Artikel (noch) ‚All Coordinates‘, wird es nur einmal ausgewertet, beißt sich also nicht. -- →^KP_G← 17:13, 26. Apr. 2021 (CEST)

Ob die Flussverläufe auch dargestellt werden, wenn in der OSM-Relation nur das Wikidata-Objekt angegeben wird, dass weiß ich nicht. Mit der Angabe des Artikels wird das jedenfalls umgesetzt. Hat aber auch den Nachteil, dass Artikelverschiebungen der WP auch in OSM berücksichtigt werden sollten, was bei Wikidata nicht nötig ist, da der Identifier dort von Verschiebungen in der WP nicht geändert wird.

Deine Aussage zu NMUM verstehe ich nicht. Schaltet man damit die Verlaufsdarstellung ein? --SteveK ?! 10:07, 27. Apr. 2021 (CEST)

NMUM = Nach meiner unmaßgeblichen Meinung. -- →^KP_G← 11:05, 27. Apr. 2021 (CEST)

Das entspricht dem Lösungsvorschlag 2. Und das ist meiner Meinung nach die Lösung, die am schlechtesten ist, da die Flussverläufe nicht angezeigt werden. Und die werden auch breiter unterstützt, wenn man sich umschaut (Beispiele: Rhein, Ruhr, Mosel, Snake River).--SteveK ?! 10:13, 28. Apr. 2021 (CEST)

Fehlendes Leerzeichen

„Abflussan der Mündung“ statt „Abfluss an der Mündung“: Fätschbach, Glatt (Thur), Havel, Lech, Wissbach (Glatt). Diese Änderung hat leider keine Abhilfe geschaffen. --Seth Cohen 19:00, 26. Mai 2021 (CEST)

Längen

Ich wäre inzwischen dafür, die Längen in der Box mit drei Nachkommastellen anzuzeigen. Ist natürlich eine Scheingenauigkeit, aber die Flüsse sind ja stationiert. Im Intro kann man dann sinnvoll runden, aber man hat den exakten Wert, ohne in den Quelltext schauen zu müssen. Genauigkeit 10 m würde zwar auch helfen und entspräche eher der Genauigkeit, aber diese Einheit ist unüblich.

Flächen würde ich übrigens immer in km² ausgeben - eine Hektarangabe wie in Wäschbach (Asdorf) verwirrt die Leser doch tendenziell! Frach mal auf der Straße jemanden, wie viele km² 82,6 ha sind ... Was ein Hektar ist, wissen heute doch nur Bauern und Förster ... Und Flächenumrechnungen sind ein heikles Feld.

Ach so: Sagte ich schon mal, daß die Felder Gemeinde/Kleinstadt/Mittelstadt Quark sind und durch "Orte am Fluß" und "Kriterium" (z. B. nur Städte, Siedlungen über 1000 EW etc.) ersetzt werden sollten? --Elop 12:14, 7. Dez. 2021 (CET)

Groß-, Mittel-, Kleinstädte

Sie beziehen sich auf deutsche Verhältnisse. In Brasilien haben wir eine andere Nomenklatur, da sind Kleinstädte mit bis zu 50.000 Einwohnern definiert, nicht wie bei uns mit 20.000. Nur zur Info, weshalb ich die Anrainerorte nicht erfassen kann. --Emeritus (Diskussion) 22:15, 22. Mär. 2022 (CET)

Das ist ja auch eh Quark. Da gehört "Orte am Fluß" hin, am besten noch "Kriterium". Und eben dadurch auch geordnet.

Ist ja toll für Kassel, sich Großstadt nennen zu können und bei Fulda eben "Mittelstadt", aber der Leser möchte unter Umständen sofort sehen können, in welcher Reighenfolge die Fulda die vielen Kleinstädte und halt die beiden zui sehen bekommt. --Elop 09:22, 23. Mär. 2022 (CET)

Ich muss mal sehen, ob ich mit dem Parameter |GEMEINDEN auskommen kann. --Emeritus (Diskussion) 12:39, 23. Mär. 2022 (CET)

Das ist natürlich die "unbürokratische" Ersatzlösung.

Davon ab: Ungeachtet der Frage ob definiert oder nicht:

Den Begriff "Mittelstadt" gibt es m. W. im Alltagsgebrauch nicht. Man redet von "Stadt" - und von "Kleinstadt", wenn sie auffallend klein ist.

"Landstadt" ist noch weniger gebräuchlich, aber das ist halt eine Stadt vom Phänotyp Dorf ... --Elop 21:59, 23. Mär. 2022 (CET)

Einbindung von Wikidata-Koordinaten

@SteveK, M2k~dewiki: Heute habe ich beim Artikel Schneidwasser zum ersten Mal die Vorlage:Einbindung von Wikidata-Koordinate vorgefunden. Da sie nur eine Artikelkoordinate ausgibt, ist sie in der Vorlage:Infobox Fluss nicht verwendbar, weshalb ich provisorisch NEBENBOX=ja gesetzt habe (⇒ Infobox erzeugt keine Artikelkoordinate und auch keinen Lagewunsch an der Stelle). Um sie in der Infobox einsetzen zu können, müsste die neue Vorlage so parameterierbar sein, dass sie auch nur Länge oder nur Breite im Textformat ausgeben kann, oder man bohrt die Infobox-Vorlage so auf, dass statt der Parameter MÜNDUNG_LAT_GRAD, MÜNDUNG_LONG_GRAD und MÜNDUNG_REGION alternativ die Vorlage eingesetzt werden kann (d:Q61754875 enthält nur Mündungskoordinaten und irgendewelche In-der-Mitte-Koordinaten) und bei den Quellkoordinaten entsprechend. -- Olaf Studt (Diskussion) 22:46, 30. Aug. 2021 (CEST)

P.S. Soll ich jetzt die Koordinaten aus Wikidata für die Infobox abschreiben? -- Olaf Studt (Diskussion) 22:52, 30. Aug. 2021 (CEST)

P.P.S. Wenn man NEBENBOX=ja setzt, wird auch Vorlage:Infobox Fluss #Automatische Kategorisierung deaktiviert. -- Olaf Studt (Diskussion) 21:55, 31. Aug. 2021 (CEST)

Hallo Olaf, ich lese das gerade erst, war 3 Wochen nicht da. Muss mich da erst rein finden. Ich würde mal auf die Schnelle annehmen, dass man die Wikidata-Eigenschaften direkt in der IB abholt und darstellt, wenn verfügbar. Aber das wird jetzt etwas dauern. Gruß --SteveK ?! 19:42, 11. Sep. 2021 (CEST)

Hallo Olaf Studt, das geht, ist aber etwas tricksig, weil es zwei verschiedene Georefenzen (Quelle/Mündung) gibt und wir die geographische Länge bzw. Breite einzeln brauchen; das sind also 4 Wikidata-Abfragen. Schau mal in den Quelltext des Artikels, dann siehst Du, wie ich es gemacht habe. (In Wikidata habe ich die Koordinaten bei der Aussage "mündet in" entfernt, weil die dort nicht hingehören.) --Telford (Diskussion) 12:57, 21. Mai 2022 (CEST)

Formatierungsproblem bei Pegel

Siehe Argen. Beim Mündungspegel entsteht ein Link mit dem Linktext „Abflussan“. --11:32, 19. Mai 2022 (CEST) (unvollständig signierter Beitrag von Silvicola (Diskussion | Beiträge) )

@Silvicola: Ich habe das gefixt. Das kommt durch das Fehlen der Pegelangabe zustande. --SteveK ?! 11:47, 19. Mai 2022 (CEST)

Danke! --Silvicola ^Disk 12:05, 19. Mai 2022 (CEST)

Bitte

Könnte jemand mal schauen warum in Ekuma (Fluss) (anders als Kunene (Fluss)) nicht automatisch durch die Infobox-Einträge dems Flusssystem Kunen als Kategorie zugeordnet wird? Zudem wird auch die Mündungsregion NA-ON nicht als Kategorie automatisch angelegt. Danke --Chtrede (Diskussion) 09:19, 2. Jun. 2022 (CEST) P.S. Statt in die Regionalkategorie wird automatisch in die Oberkategorie Kategorie:Fluss in Namibia einsortiert. Die Infobox kennt also augenscheinlich den ISO-Regionalcode NA-ON nicht. --Chtrede (Diskussion) 11:58, 2. Jun. 2022 (CEST) Vielleicht kannst Du, @SteveK: helfen? Danke --Chtrede (Diskussion) 09:32, 3. Jun. 2022 (CEST)

Niemand? --Chtrede (Diskussion) 12:05, 6. Jun. 2022 (CEST)

Du könntest einmal den Parameter NOAUTOKAT=JA einfügen und die passenden Kategorisierungen händisch erstellen... --Skipper69 (Diskussion) 13:30, 6. Jun. 2022 (CEST)