Hauptmenü öffnen
Abkürzung: WP:VWS
Vorlagenwerkstatt Willkommen in der Vorlagenwerkstatt.
Hier kannst du Fragen zu bestimmten Vorlagen stellen, dir Tipps zur Bearbeitung und Erzeugung von Vorlagen einholen oder Kommentare zu Fragen anderer abgeben.

Inhaltliche Fragen und diskussionswürdige Wünsche zu Vorlagen sollten zunächst auf der betreffenden Diskussionsseite der Vorlage oder einem fachlich zugehörigen Portal besprochen werden. Um die technische Umsetzung kümmern sich die Mitarbeiter dieses Vorlagenprojekts anschließend gerne. Da häufig Rückfragen auftreten, beobachte bitte die Seite oder besuche sie regelmäßig, damit du schnell antworten kannst. Weitere Tipps unter WP:Werkstätten.

Um eine möglichst rasche und detaillierte Antwort zu erhalten, ist es von Vorteil, möglichst viele der W-Fragen möglichst genau und detailliert bereits in der Anfrage zu berücksichtigen:

Bei Neuentwicklungen oder Erweiterungen Bei Fehlern
  • Was – soll das Gewünschte tun?
  • Wie – soll das Gewünschte aussehen?
  • Warum – ist es hilfreich, so etwas zu haben?
  • Wer – wünscht die Umsetzung?
  • Wo – soll das umgesetzt werden?
  • Wo – findet sich ein Beispiel oder ähnlich Geartetes?
  • Browser-Cache geleert? Nein: → Hilfe:Purge
  • Wo – tritt das auf? (Link!)
  • Wo – findet sich ein Beispiel?
  • Wie – soll es tatsächlich aussehen?
  • Wie – sieht es fehlerbehaftet aus?
  • Was – wurde schon unternommen, um den Fehler zu beheben?

Kennst du schon unsere Anleitung für Infoboxen?


Abschnitte auf dieser Seite werden archiviert, wenn sie mindestens 90 Tage alt sind oder 45 Tage alt sind und mehr als einen Beitrag haben oder wenn sie mit der Vorlage Erledigt {{Erledigt|1=~~~~}} versehen und älter als drei Tage sind.

Archive
2006 2007
2008/1 2008/2 2008/3 2008/4
2009/1 2009/2 2009/3 2009/4
2010/1 2010/2 2010/3 2010/4
2011/1 2011/2 2011/3 2011/4
2012/1 2012/2 2012/3 2012/4
2013/1 2013/2 2013/3 2013/4
2014/1 2014/2 2014/3 2014/4
2015/1 2015/2 2015/3 2015/4
2016/1 2016/2 2016/3 2016/4
2017/1 2017/2 2017/3 2017/4
2018/1 2018/2 2018/3 2018/4
2019/1 2019/2 2019/3 2019/4


Fehler in der Vorlage:%Bearbeiten

  {{%}} erzeugt bei einem bestimmten Verhältnis eine fehlerhafte Anzeige mit fehlender Nachkommastelle:

  • {{% |214 |2149 |1 |prec}} = 10, %

mit der Zahl "2140":

  • {{% |214 |2140 |1 |prec}} = 10,0 %

mit 2 Nachkommastellen

  • {{% |214 |2149 |2 |prec}} = 9,96 %

Weil die Seite „Vorlage Diskussion:%“ rot ist, frage ich hier nach, wo das Problem liegt… Gruß --Chiananda (Diskussion) 04:11, 19. Sep. 2019 (CEST)

Weiß ich auch nicht, liegt wohl am prec wozu auch immer du das haben möchtest.
runde 214 von 2149 213 von 2149 212 von 2149
auf 0 10 % 10 % 10 %
auf 1 10 % 9,9 % 9,9 %
auf 2 9,96 % 9,91 % 9,87 %
Wie soll denn bitte so ein Wert wie ,96 in einer einzelnen Stelle {{% |214 |2149 |1 |prec}} angezeigt werden, das ist schlicht unmöglich. Da müsste man dann wiederum eine Rundungsfunktion einbauen, um aus dem Rest 0,96 eine 1,0 zu machen. Anders verhält es sich bei 214/2140, denn da ist der Rest eben schon Null. --Liebe Grüße, Lómelinde Diskussion 11:43, 19. Sep. 2019 (CEST)
Ló, deine Antwort befriedigt nicht :(
Der 4. Paramter prec (precision) steht für „Bei Dezimalstellendarstellung Endnullen nicht wegrunden“. Genau dafür setze ich die Vorlage ja ein: damit alle Zahlen die gewünschte Nachkommastelle anzeigen, auch wenn’s eine „0“ ist. Das wird bei Tabellen benötigt, wo alle %-Werte vergleichbar sein sollen (auch optisch). Funktioniert bei mir in vielen Tabellen mit allen möglichen Zahlen problemlos – außer bisher bei exakt den folgenden Werten: 214 geteilt durch 2141 … 2150:
  • {{% |214 |2140 |1 |prec}} = 10,0 % = 2140 ok
  • {{% |214 |2141 |1 |prec}} = 10, %
  • {{% |214 |2142 |1 |prec}} = 10, %
  • {{% |214 |2143 |1 |prec}} = 10, %
  • {{% |214 |2144 |1 |prec}} = 10, %
  • {{% |214 |2145 |1 |prec}} = 10, %
  • {{% |214 |2146 |1 |prec}} = 10, %
  • {{% |214 |2147 |1 |prec}} = 10, %
  • {{% |214 |2148 |1 |prec}} = 10, %
  • {{% |214 |2149 |1 |prec}} = 10, %
  • {{% |214 |2150 |1 |prec}} = 10, %
  • {{% |214 |2151 |1 |prec}} = 9,9 % = 2151 ok
Vermutlich erkennt jemand mit mathematischer Begabung das Prinzip dieser Fehlfunktion, denn die Tatsache, dass hinter der "10" ein Komma folgt, deutet ja an, dass die Vorlage etwas schreiben will, die eigene Rundung aber nicht hinbekommt… und ich will nicht noch eine 2. Vorlage drumherumstülpen müssen, um eine vernünftige Anzeige hinzubekommen.
  Verbessern: Ich sehe eine Notwendigkeit, die Fehlfunktion zu beheben. --Chiananda (Diskussion) 23:22, 20. Sep. 2019 (CEST)
@Chiananda: Auf den ersten Blick sieht es für mich so aus, dass dies mit dem og. Problem Signifikante Stellen (bei „deutschem“ Zahlenformat) zusammenhängt. In der Implemetierung der Vorlage:% wird auch mehrfach per {{#expr: ... round ...}} gerundet... --rolf_acker (DiskussionBeiträgeLogbücher) 13:21, 28. Sep. 2019 (CEST)

Ich habe den Link zur NICHT erledigten "round"-Problematik aktualisiert (Archiv).
Gerade stoße ich auf einen weiteren Fall, wo die "round"-Funktion (innerhalb der Vorlage:%) nicht funktioniert, hier bei der Einstellung "5 Nachkommastellen":

  •  1,0619 % = 4 Nachkommastellen (mit der Angabe prec = „bei Dezimalstellendarstellung Endnullen nicht wegrunden“)
  • -1,0681 %
  •  1,06188 % = 5
  • -1,0681 %
  •  1,061884 % = 6
  • -1,068099 %

Hier werden auch keine "glatten" Zahlen berechnet, sondern sehr viele Nachkommastellen. Also entfernt die "round"-Funktion bei Aufrundung eine nachfolgende 0 und widerspricht damit der Funktionalität von "prec".
Sollte da nicht nachgebessert werden? Gruß --Chiananda (Diskussion) 17:00, 22. Okt. 2019 (CEST)

Vorlage für Denkmalliste SaarlandBearbeiten

Hallo miteinander,

Ich bin mir nicht ganz sicher, ob ich hier mit diesem Anliegen ganz richtig bin, aber ich probier es mal. Ich würde gerne für die Denkmallisten im Saarland eine Vorlage erstellen, wie es die für andere Bundesländer zB BaWü schon gibt. Und dann eben auch gerne nach und nach die Denkmallisten im Saarland so umarbeiten, dass sie diese Vorlage benutzen. Momentan benutzen die Denkmallisten vom Saarland tables ohne Vorlage (siehe die Denkmalliste von Bous als Beispiel). Das macht es aber find ich etwas lästig, Informationen wie Commonscats zu ergänzen. Jetzt weiß ich aber natürlich nicht, ob das gewollt ist, dass ich mit dieser Unternehmung anfangen würde. Vor allem, da ich ja doch noch ein Neuling hier bin und ich jetzt auch niemanden auf die Füße treten will. Da wäre also meine Frage, ob ich damit anfangen sollte oder auch nicht? Oder an wen ich mich vielleicht sonst wenden könnte.

LG, --DavidJRasp (Diskussion) 13:10, 2. Okt. 2019 (CEST)

WD-basierte Infoboxen für Artikel zu Bibliotheken, Archiven und MuseenBearbeiten

Hallo allerseits,

Es laufen derzeit auf internationaler Ebene zwei Projekte, welche zum Ziel haben, die auf Wikidata enthaltenen Informationen zu Gedächtnisinstitutionen systematisch zu ergänzen und zu verbessern. Eines der Projekte ("Sum of All GLAMs") strebt darüber hinaus auch an, die Verwendung dieser Daten innerhalb der Wikipedias im Rahmen von Infobox-Templates zu fördern, um so den Feedback-Loop zwischen Datenbereitstellung und Datennutzung zu schliessen. Weitere Informationen zum Projekt sind diesem Artikel und dieser Projektseite auf Wikidata zu entnehmen.

Inzwischen ist das "Sum of All GLAMs"-Projekt auch in der deutschsprachigen Wikipedia angekommen - und hat hier erste Reaktionen ausgelöst. Könnte sich jemand unter den hiesigen Infobox-Wizards behilflich zeigen und uns bezüglich des Vorgehens aufklären, das innerhalb der deutschsprachigen Wikipedia am besten verfolgt wird, um die betreffenden Infoboxen auf Wikidata-basierte Infoboxen "umzurüsten". Falls sich jemand der Sache gleich selber annehmen und die entsprechenden Infoboxen anlegen möchte, würden wir das natürlich ebenfalls begrüssen.

--Beat Estermann (Diskussion) 21:55, 15. Okt. 2019 (CEST)

Nun, das ist eine Initiative von Wikidata, die beabsichtigt, eine Wikidata-Struktur in unser Proket zu injizieren.
Also von außen.
Der naturgemäße Weg wäre es, dass unsere Autoren um Hilfe von außen anfragen, weil sie mit irgendwas nicht mehr klarkämen, und Unterstützung benötigen.
Wie bereits deutlich wurde, haben wir die fraglichen drei Infoboxen seit vielen Jahren, und mutmaßlich alle relevanten Artikel sind bereits seit vielen Jahren damit ausgestattet. Zunächst mal gibt es nicht die allergeringste Notwendigkeit, unsere Infoboxen zu entfernen und durch fremdbestimmte zu ersetzen.
Unsere Autoren sind mit den von ihnen selbst erstellten Infoboxen vertraut, und können mit ihnen umgehen. Unklar ist, warum sie umgeschult werden müssen, um jetzt mit fremden Vorlagen umzugehen.
Nach oberflächlicher Durchsicht der fraglichen Programmierungen wird offenbar von sämtlichen dieser Vorlagen gefordert, dass die Parameternamen in englischer Sprache und momentan noch nicht überschaubaren Datenformaten zu verwenden sind. Das ist kaum zu vermitteln.
Unsere Vorlagen enthalten seit vielen Jahren die von uns für relevant gehaltenen Informationen. Die weitaus überwiegende Menge der Informationen scheint mir statischer Natur zu sein, also Gründer, Gründungsjahr, Standort usw. Vielleicht gibt es irgendeine nachrangige veränderliche Information wie die Zahl der Besucher im letzten Jahr oder die Namen von Direktoren; das mag als Veränderliche ergänzt werden.
Zu beachten ist, dass dieses Wiki hier mit Sichtung arbeitet; das bedeutet, dass jegliche Information, die Unbekannte oder wenig aktive Benutzer an unseren Artikeln verändern, erst durch unsere Sichter gegenzuprüfen ist; etwa durch das Einfordern von Belegen. Dadurch wird Vandalismus wirksam verhindert. Wikidata hingegen ist bekanntlich die Datenbank, die jeder Internetbenutzer auf dem Planeten verändern darf – ohne dass irgendeine Kontrolle oder fachliche Prüfung erfolgt. Das bedeutet, dass jede vandalierte Information sofort in unserem Artikel sichtbar wird, ohne dass wir davon etwas bemerken.
Fassen wir dies also zusammen: Es gibt in unseren vorhandenen Infoboxen statische Informationen, etwa Gründungsjahr oder was auch immer, die wir durch unsere Sichter überwachen und vor Vandalismus schützen können. Diese sollen wir eintauschen gegen englischsprachig benannte Felder, die ihren Wert von uns unbemerkt verändern können?
Sollte sich an quasi-statischen Informationen, also etwa der Ortschaft, in der sich die Einrichtung befindet, irgendetwas ändern, dann hilft es uns nichts, wenn die Infobox durch eine globale Änderung durch uns unbemerkt von A-Stadt nach B-Stadt umzieht – wir müssen auch den sonstigen Text des enzyklopädischen Artikels ändern und von diesem Umzug in der Geschichte der Einrichtung berichten.
Eine Initiative, die wesentlich die Gestaltung und Inhalte unserer Artikel beeinflusst, geht von der hiesigen Community aus. Was irgendwer von außen global bestimmt und an Projekten aufzieht ist für unsere Artikel irrelevant. Insofern gibt es auch keinen Mechanismus, wie Außenstehende in die Inhalte unserer Artikel eingreifen können – der Vorgang ist beispiellos und geht ja offenkundig von Wikidata aus, wo man daran interessiert ist, deren Informationen in unsere Artikel zu injizieren.
Was möglich wäre, ist auf Basis unserer langjährig bestehender Vorlagenprogrammierungen bei dynamischen Parameterwerten wie Besucherzahl oder Namen von Führungspersonen die aktuellen Werte aus Wikidata zu übernehmen. Was außerdem immer möglich ist, wäre der reine Vergleich der bei uns hinterlegten statischen oder quasi-statischen Information mit dem korrespondierenden Wert bei Wikidata und Auslösung einschlägiger Mechanismen (Wartungskategorien) bei Feststellung von Abweichungen; anschließend ist die belegbasierte Ermittlung des Grundes und tatsächlichen Wertes durch unsere Fachleute erforderlich.
Im Übrigen ist hier grundsätzlich Wikipedia:Meinungsbilder/Nutzung von Daten aus Wikidata im ANR zu beachten.
@Kolja21: FYI
VG --PerfektesChaos 00:30, 16. Okt. 2019 (CEST)
Als abschreckendes Beispiel kann im Übrigen Vorlage:Cycling race/infobox dienen, was jetzt schon ewig parallel zu Vorlage:Infobox Radrennen existiert und vom Portal absurderweise auch so hingenommen (oder sogar befürwortet) wird. Sowas finde ich absolut unsinnig (LA wurde aber leider schon abgelehnt). 2003:C9:6F22:A300:858:966A:559F:2150 12:05, 16. Okt. 2019 (CEST)
Es ist nicht unsere Absicht, bestehende Daten in den Infoboxen systematisch durch Daten aus Wikidata zu ersetzen. Insbesondere bei statischen Daten ist ein Ersetzen der Daten sicherlich nicht nötig. Allerdings können bei neu zu erfassenden Daten über die verschiedenen Wikipedia-Projekte hinweg Effizienzgewinne erzielt werden, wenn Daten künftig nur noch an einem Ort gepflegt werden. Aus demselben Grund werden wir künftig auch unsere Anstrengungen, Gedächtnisinstitutionen dazu zu bewegen, die sie betreffenden Daten regelmässig zu prüfen und bei Bedarf zu korrigieren, nicht primär auf Wikipedia, sondern auf Wikidata ausrichten. Es versteht sich, dass wir daran interessiert sind, die Infoboxen so zu programmieren, dass die entsprechenden Korrekturen dann auch gleich direkt in den verschiedenen Wikipedias angezeigt werden. - Gerade in der Schweiz kommt es recht häufig vor, dass Wikipedia-Artikel zu Gedächtnisinstitutionen in mehreren Sprachen vorliegen und gepflegt werden.
In der Versionsgeschichte und in den Beobachtungslisten werden die Wikidata-bezogenen Änderungen angezeigt, so dass sie von Wikipedia-Autoren relativ bequem nachverfolgt werden können. - Oder gibt es diesbezüglich weitere Verbesserungswünsche? - Was die Sichtung der Seiten anbelangt, so wurde per Meinungsbild beschlossen, im Zusammenhang mit der Sichtung von Daten für die Einbindung von Daten aus Wikidata keine weiteren Auflagen zu machen.
Die Art und Weise, wie Daten aus Wikidata in Infoboxen eingebunden werden, sollte in der Tat den Gepflogenheiten in der jeweiligen Wikipedia entsprechen. Diese variieren zwischen den einzelnen Wikipedias recht stark. Entschuldigt bitte, dass meine Kollegin vorgeprescht ist und einen ersten Prototypen implementiert hat, bevor hier nachzufragen bzw. Recherchen zu den bestehenden Infoboxes anzustellen. Konkret würde uns interessieren, ob sich bezüglich des Einbindens von Daten aus Wikidata auf der deutschsprachigen Wikipedia bereits eine gängige Praxis herausgebildet hat oder diese erst noch im Entstehen ist. Auf der englischsprachigen Wikipedia, beispielsweise, wird typischerweise für jede Infobox eine zweite Infobox erstellt, welche die Daten möglichst vollständig aus Wikidata bezieht. In der italienischsprachigen Wikipedia haben wir beobachtet, dass Infobox-Vorlagen nach und nach "umgerüstet" werden, d.h. in bestehenden Vorlagen werden einzelne Felder so implementiert, dass sie die Daten standardmässig aus Wikidata beziehen, sofern keine lokalen Daten vorhanden sind. Das scheint auch der Weg zu sein, der bei den uns interessierenden Infoboxen eingeschlagen wurde:
Gibt es einen Konsens, auf der deutschsprachigen Wikipedia diesen Ansatz zu verfolgen? Wurde das irgendwo mal diskutiert?
Als thematisch relevante WPde-Wikiprojekte haben wir Wikipedia:GLAM und Wikipedia:GLAM/Schweiz identifiziert. Sollen wir da explizit nachfragen, wie die weitere Anreicherung der obengenannten Infoboxen mit Wikidata-Calls gesehen wird? Gibt es weitere relevante Wiki-Projekte, die einbezogen werden sollten? Oder reicht es, die beabsichtigten Änderungen kurz auf der Diskussionsseite der jeweiligen Infobox anzukündigen?
--Beat Estermann (Diskussion) 20:51, 28. Okt. 2019 (CET)
Die Vorgehensweise zwischen den Wikipedien ist stark unterschiedlich.
  • Diese hier ist ein Projekt unter Sichtung; das heißt jeder Veränderungsversuch an einschlägigen Seiten durch Fremde muss erst einmal durch Sichter mit uns besser bekannter Vorgeschichte gegengecheckt und bestätigt werden. Dadurch haben wir hier eine sehr hohe Datenqualität.
  • In der englischsprachigen Wikipedia gibt es dieses Konzept nicht. Dort kann jeder sofort wirksam überall alles ändern. Angeblich würde es dort Künstliche Intelligenz geben, mit der verfälschende Bearbeitungen ausfindig gemacht werden würden. Ansonsten muss man dort darauf hoffen, dass es Beobachter gibt, die eine verfälschende Bearbeitung zufällig sehen und dann Zeit und Gelegenheit haben, um ihr sofort nachzugehen, bevor schon die nächste Aktivität erforderlich würde.
  • Das Vorgenannte gilt nebenbei bemerkt auch für Wikidata.
„in den Beobachtungslisten werden die Wikidata-bezogenen Änderungen angezeigt, so dass sie von Wikipedia-Autoren relativ bequem nachverfolgt werden können“
  • Das ist theoretisch richtig.
  • Allerdings würden bei mir und vielen anderen beobachtenden Benutzern unsere Beobachtungslisten binnen weniger Stunden mit Hunderten und Tausenden von Meldungen geflutet werden, dass irgendjemand in Wikidata ein Projekt zu einem Item hinzugefügt habe, die arabische oder ukrainische oder kasachische Beschreibung eines Items verändert habe, das Ranking zu einer Aussage verändert habe, eine Fundstelle zu einer Aussage verändert habe.
  • Heißt: Es laufen pro Stunde so viele völlig irrelevante Benachrichtigungen von Wikidata auf, falls diese Option eingeschaltet würde, dass eine wirklich wichtige Veränderung im Rauschen unterginge. Und es sind so viele Benachrichtigungen von Wikidata, dass hier kein Bearbeiter noch irgendetwas Sinnvolles tun könnte als die in den letzten 24 Stunden aufgelaufenen Meldungen von Wikidata durchzusehen, und damit wäre die tägliche Wiki-Zeit erschöpft, und sonst nichts getan.
  • Nebenbei bemerkt würde das ohnehin nur die von einem selbst beobachteten Artikel betreffen. Alle Veränderungen an von einem selbst nicht beobachteten Artikel blieben dabei noch unbemerkt. Bei uns hingegen bleiben in der Sichtungswarteschlange alle Veränderungen so lange stehen, bis sie von einem Sichter bestätigt wurden. Egal wer den Artikel beobachtet, was durchaus null aktive Benutzer sein können.
  • Bedeutet: Dieses Wikidata-Feature ist ein nettes Alibi, aber für eine wirkliche Überwachung der inhaltlichen Veränderungen auf Wikidata völlig untauglich.
Zwei Infoboxen im selben Artikel, eine von uns, eine von Wikidata-GLAM
  • Das mag ja gern die englischsprachige Wikipedia so handhaben, was ich gern erstmal mit eigenen Augen sehen möchte.
  • Darauf wird sich hier bei uns aber niemand einlassen, weil es unsere Leser verwirrt.
Statische Angaben:
  • Einen konstanten oder quasikonstanten Wert möchten wir hier gern in unserem eigenen Quelltext hinterlegt haben.
  • Eine ISIL-Nummer wäre sowas. Eigentlich kann sich die niemals mehr ändern; falls doch, ist vielleicht die Institution umstrukturiert oder aufgelöst worden, und dann darf das nicht einfach unbemerkt nur in der Infobox passieren, sondern dann müssten wir den Artikel entsprechend umschreiben.
  • Der Ort, wo sich die Einrichtung befindet desgleichen. Eigentlich kann sich der nicht mehr ändern. Sollte die Einrichtung jedoch einmal umziehen, dann ist es nicht damit getan, dass in der Infobox plötzlich eine andere Stadt oder Ortsteil genannt wird, sondern wir müssten auch den Rest des Artikels umschreiben und erwähnen, dass sich die Einrichtung bis 2019 in A-Stadt befunden hatte und 2020 in einem neuen Gebäude in B-Stadt wiedereröffnet wurde. Davon dass automatisch die Infobox umswitcht und wir das nicht bemerken können und es nun zu einem Widerspruch käme hat niemand etwas. Der Aufwand, den genauen Sachverhalt zu recherchieren und den eigentlichen Artikel zu aktualisieren ist sehr viel größer als zum Schluss noch neue Koordinaten einzukopieren und eine neue Anschrift per C&P irgendwo reinplumpsen zu lassen.
Vorlage:Infobox Archiv (Die ISIL-Nummer wird von Wikidata eingebunden)“
  • Das ist nur halb richtig, oder zu 20 % 32 % die Wahrheit.
  • Bei 109 Einbindungen ist die ISIL in unserem Artikelquelltext hinterlegt.
  • Bei 29 Einbindungen fehlt sie bei uns und wird momentan aus Wikidata bezogen, falls dort vorhanden.
  • Wünschenswert wäre, dass jemand diese 29 Fälle durchginge, die Richtigkeit der Angabe checkt und den Wert bei uns einträgt.
Datenabgleich
  • Sehr gern vergleichen wir die bei uns statisch hinterlegten Informationen mit denen auf Wikidata.
  • Sollten Differenzen auftreten, würden wir den Artikel in eine Wartungskategorie einordnen und darauf hoffen, dass dies in den nächsten Wochen Fachautoren abarbeiten und die Ursache ermitteln.
  • Die Einrichtung könnte von A-Stadt nach B-Stadt verlegt worden sein; dann müssen wir unseren Artikeltext entsprechend ergänzen und das neue Gebäude beschreiben.
  • Unseren Sichtern könnte Vandalismus durchgeschlüpft sein und wurde irrtümlich abgehakt.
  • Wikidata könnte vandaliert worden sein; es ist die Datenbank, die jeder Internetbenutzer auf dem Planeten jederzeit verändern darf.
Dynamische Informationen
  • Sich ständig ändernde Informationen, etwa die Zahl der Besucher oder Benutzer im letzten Kalenderjahr oder die Namen der Direktoren oder die Zahl von Büchern oder Depotstücken können wir aus Kapazitätsgründen ohnehin nicht ständig nachführen.
  • Falls da jemand einen Direktor Alfred E. Neumann über Wikidata sichtbar macht und das niemand merkt, tja, in den folgenden Jahren erscheint dann hoffentlich auch mal wieder der richtige Name, oder Mitarbeiter der Einrichtung schauen sich „ihren“ Wikipedia-Artikel an und melden uns Auffälligkeiten.
VG --PerfektesChaos 21:58, 28. Okt. 2019 (CET)
Ich habe jetzt noch mal tiefer in Infobox Archiv reingeschaut:
  • Ich korrigiere: Es sind 50 Einbindungen ohne ISIL-Wert bei uns; 109 mit ISIL. Es sind 29 mit leerer Wertzuweisung und 21 mit völlig fehlendem Parameternamen, was bei unseren Infoboxen eher unüblich ist.
  • Bei unseren Artikeln ohne ISIL scheint es sich um historische oder international unbeachtete Einrichtungen zu handeln, zu denen wohl überhaupt keine ISIL vergeben wurde und nie vergeben werden wird.
  • Solche internationalen Codes werden typischerweise den ab der Einführung des Systems existierenden zugeordnet, aber nicht mehr nachträglich. Die (erste) Bibliothek von Alexandria bekäme entsprechend wohl kein ISIL mehr und hätte auch bei der Registrierung ihrer Website ein Problem.
  • Beispielfälle ohne ISIL bei uns und auch nicht bei Wikidata:
  • Ich sehe bei den über ISIL Registrierten vorwiegend Einrichtungen von nationaler Bedeutung, öffentliche und staatsnahe Institutionen und Teilnehmer an Kooperationen wie Fernleihe. Dass es daneben individuelle Organisationen ohne ISIL gäbe scheint mir plausibel. Wenn das Heimatmuseum Dingenskirchen auf den Aufwand mit einer Registrierungsagentur erstmal verzichten möchte ist das ja nachvollziehbar.
  • Eine Wikidata-Kooperation könnte optimal so aussehen, dass wir unseren Wert mit dem bei Wikidata vergleichen.
    • Sollte es einen Unterschied geben, was den Fall einschließt, dass wir noch keine ISIL kennen, dann sollte eine allgemeine Wartungskategorie, etwa zu GLAM-Infos, ausgelöst werden und ein Autor kommt gelegentlich, prüft ob es kein Fake ist, trägt die neue ISIL ein und allen ist geholfen. Veränderungen von uns bekannten ISIL wären kritisch zu analysieren.
    • „Feedback-Loop zwischen Datenbereitstellung und Datennutzung zu schliessen“ (Eingangs-Statemnt): Genau das wäre eine Loop; wir werden über ISIL informiert, wo wir noch keine kennen, sollten inhaltlich mal draufgucken, und können Vandalismus hier wie dort identifizieren.
VG --PerfektesChaos 14:19, 29. Okt. 2019 (CET)
Danke für deine Ausführungen. Nachstehend meine Reaktionen zu den wichtigsten Punkten:
Beobachtungslisten mit Wikidata-bezogenen Änderungen.
  • Das Problem mit der "Flutung" durch irrelevante Edits sollte mittlerweile behoben sein; gemäss meinem Wissensstand sollten nur noch jene Änderungen angezeigt werden, die tatsächlich auch auf der entsprechenden Seite eingebunden sind. - Ist dem nicht so? Ich wäre interessiert an Feedback, falls es diesbezüglich nach wie vor Verbesserungsbedarf gibt.
  • Zudem gibt es die Möglichkeit, ein ganzes Set von Daten parallel mittels des Listeria-Tools (Vorlage:Wikidata list) im Auge zu behalten; Änderungen in dem durch eine Query definierten Datenraum erscheinen in der Versionsgeschichte der entsprechenden Seite. Eventuell würde es Sinn machen, für jeden Infobox-Typen eine entsprechende Liste zu erstellen. Allerdings darf die Query nicht zu "breit" sein; wenn sie zu einer zu grossen Zahl von Ergebnissen führt, wird das Update der Liste nicht gemacht; momentan scheint das Tool bei 8000 Items "gedeckelt" zu sein. Möglicherweise wäre das verhandelbar, falls es einen entsprechenden Bedarf gibt.
Zwei Infoboxen im selben Artikel
  • Nein, so habe ich das nicht gemeint. In der englischsprachigen Wikipedia gibt es typischerweise eine Infobox mit Einbindung von Daten aus Wikidata und eine analog ohne Einbindung von Daten aus Wikidata. So können die Artikel-Autoren selbst wählen, welche sie einbinden möchten. - Ich finde diese Verdoppelung von Infoboxes nicht sonderlich glücklich; allerdings scheinen sie damit das Problem von "Turf-Wars" zu umgehen, wenn einzelne Autoren "ihre" Artikel mit Klauen und Zähnen gegen die Einbindung von Daten aus Wikidata verteidigen.
  • Über die Einbindung von zwei Infoboxen könnte man sich allenfalls unterhalten, wenn der Artikel sich auf mehrere Dinge bezieht, wie z.B. ein Museum als Organisation (Infobox Museum) und das dazugehörige Gebäude (Infobox Gebäude). Die Abdeckung mehrerer Dinge in einem Wikipedia-Artikel ist Gang und Gäbe; in Wikidata geht die Tendenz dahin, die Dinge, die unterschiedlichen Klassen angehören, klar zu trennen und mehrere Items anzulegen. Das muss man meines Erachtens in der Enzyklopädie nicht systematisch nachvollziehen; es stellt sich aber die Frage, ob man in diesem Fall zwei Infoboxen einbinden würde.
Datenabgleich
  • Der Schliessung des Feedback-Loops zwischen Wikidata und Wikipedia unter Beibehaltung des Sichtungs-Prinzips stehe ich positiv gegenüber. Ich denke, das sollten wir weiterverfolgen. Wie funktioniert das in der Praxis? Gibt es bereits entsprechende Wartungslisten?
  • Könnten wir mal mit der ISIL-Nummer anfangen und denselben Ansatz anschliessend auf weitere Felder ausdehnen?
Dynamische Informationen
  • Das Aktualisieren von dynamischen Informationen in der Wikipedia ist ein echtes Problem. Da greift das Sichtungs-Prinzip nicht; veraltete Informationen werden nicht identifiziert. Dieses Problem könnten wir teilweise in den Griff kriegen, indem wir offizielle Datenbanken direkt an Wikidata anbinden und Aktualisierungen automatisch einspielen. Die Schweizer Behörden führen dazu gerade eine Konsultation durch, bei der es darum geht, die nützlichsten Basisregister zu identifizieren, die dringend als Linked Open Data publiziert werden sollten: tinyurl.com/basereg (die Befragung läuft noch bis Anfang der nächsten Woche).
  • Dort wo der Bezug der Daten aus einer zentralen Datenbank nicht möglich ist, möchten wir das Problem über einen Crowdsourcing-Ansatz lösen, der sowohl auf die betroffenen Organisationen als auch auf die Wikipedia-Community abzielt (z.B. regelmässiges Anschreiben der Gedächtnisinstitutionen, um die sie betreffenden Angaben zu überprüfen und bei Bedarf zu aktualisieren) - dabei ist die Wikipedia ein wichtiger, aber nicht der einzige Anwendungsfall; die Daten aus Wikidata werden nämlich vermehrt auch in anderen Nutzungskontexten genutzt; d.h. wir können uns hier Synergie-Effekte zunutze machen.
Konzernarchiv Georg Fischer
  • Die ISIL-Nummer ist in der Infobox lokal vorhanden, es gibt aber ein Darstellungsproblem. Ich konnte nicht eruieren, woran es liegt; könntest du dir das kurz ansehen?
  • In der Wikidata habe ich die ISIL-Nummer nun auch eingetragen.
-- Mit besten Grüssen, Beat Estermann (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Beat Estermann (Diskussion | Beiträge)) 22:08, 29. Okt. 2019 (CET)

Vorlage Infobox SportveranstaltungBearbeiten

Hallo, ich suche eine einfache Vorlage für einen jährlichen Mannschaftssportwettbewerb, bei dem die Saison (Jahr) angezeigt wird, ein Logo, ein Button für vor-, einer für zurückblättern, und natürlich die Sieger, gern auch die Platzierten, aber für Frauen und Herren, wenn/da beide in einem Artikel behandelt werden.

Es gibt die einfache Vorlage:Navigationsbox Eishockeyturnier
Beispiel Eishockey-Weltmeisterschaft:

  Eishockey-Weltmeisterschaft
◄ vorherige 1990 nächste ►
Sieger: Sowjetunion  UdSSR

Leider passen da einige der gewünschten Angaben nicht hinein. Dann gibt es noch die Vorlage:Infobox Sportwettbewerb, Beispiel: Leichtathletik-Disziplin:

Leichtathletik-Weltmeisterschaften 2009
Disziplin 100-Meter-Lauf
Geschlecht Männer
Teilnehmer 91 Athleten aus 69 Ländern
Austragungsort Deutschland  Berlin
Wettkampfort Olympiastadion Berlin
Wettkampfphase 6. August (Finale)
Medaillengewinner
  Usain Bolt (Jamaika  JAM)
  Tyson Gay (Vereinigte Staaten  USA)
  Asafa Powell (Jamaika  JAM)

Dort sieht man gut die Medaillengewinner.

Nun suche ich eine kleine, feine Vorlage, die die gewünschten Angaben enthält. Finde ich nur keine? Läßt sich eine vorhandene Vorlage als Vorlage:Faustballsaison verwenden und anpassen? Die Medaillengewinner der Männer und Frauen müssen hinein, Austragungsort und- datum der Finalturniere (Final Four) oder Rundenturnier sollten ebenso hinein.

Wer kann helfen, wer hat Hinweise? Ach so, Verwendung soll die Infobox zumindest in allen Artikeln zu DDR-Faustball-Meisterschaften, ggf. auch in zukünftig zu erstellende Saison-Artikel der deutschen Faustball-Liga finden. --Tommes  11:32, 20. Okt. 2019 (CEST)

Das können wir hier nicht klären.
Es müsste in Portal/Redaktion für alle Sportarten und Wettbewerbe eine Lösung gefunden werden, die noch keine eigene Infobox haben (wie Fußball, Olympia und so.).
  • Welche Parameter das haben sollte und wieviele unterschiedliche Infoboxen es braucht (Mannschaften, einfache Turniere, national, international oder wie immer).
Vorlage:Infobox Sportwettbewerb geht wohl bereits in genau diese Richtung.
Ein schlauer Plan wäre es, eine übergeordnete Universalvorlage zu bauen ähnlich Vorlage:Infobox und diese dann für den Einzelfall mit einer bestimmten Sportart und einem bestimmten Wettbewerb mit den aktuellen Parametern zu bestücken, wodurch die spezielle Programmierung der speziellen Infobox sehr simpel ausfallen würde.
VG --PerfektesChaos 15:28, 20. Okt. 2019 (CEST)
Du hast recht, PerfektesChaos, aber der Punkt einer allgemeingültigen Vorlage mit Parametern je nach Sportart ist wohl schon überschritten. Keiner legt diese mehr an. Die Vorlage:Infobox Sportwettbewerb ist schon nah dran, ist 217 mal eingebunden, allein bei Leichtathletik-Disziplinen. Jede Sportart macht ihr eigenes Ding. Wer kennt auch alle Eigenheiten aller Sportarten? Ich habe da keine Illusionen.
Die Fußballer haben sogar zwei Vorlagen, Vorlage:Infobox Fußballwettbewerb und Vorlage:Infobox Fußballturnier. Letztere ist über 500mal eingebunden...
Ich brauche also keinen Plan, WP:Sport betreffend, sondern eine kleine Vorlage für meine Zwecke. Es wird ja Winter, vielleicht versuche ich es dann selbst wieder. --Tommes  19:35, 20. Okt. 2019 (CEST)
@Tommes: Hast du dich schon dran versucht? Sonst würde ich mal was zusammenbasteln, so schwer ist das nicht (die Vorlage:Infobox Sportwettbewerb stammt z. B. von mir). 188.98.177.102 09:34, 30. Okt. 2019 (CET)
@188.98.177.102: Bitte gern. Ich habe gerade weder Zeit noch Elan dafür. Es reicht eine einfache Variante von Navigationsbox Eishockeyturnier für Frauen 1., 2., 3., Männer 1., 2., 3., dazu Saison vor/zurück. Vielleicht noch Ort und Datum der Finalrunde, aber ist kein Muß. Es ist ja für Artikel wie DDR-Meisterschaften im Feldfaustball 1980. --Tommes  22:30, 30. Okt. 2019 (CET)
@Tommes: Ich habe Vorlage:Infobox Sportsaison erstellt und in DDR-Meisterschaften im Feldfaustball 1980 eingebunden. Passt das so, hast du Verbesserungswünsche? 188.98.177.102 23:54, 30. Okt. 2019 (CET)
Es ist ein sehr guter Anfang. ;) Schau bitte auf die Infobox in Eishockey-Bundesliga 1990/91. Dort siehst Du verschiedene Grautöne für bestimmte Felder. Das wäre schön. Auch ein Logo muß möglich sein. Es sollten alle Felder als Option zu verwenden sein. Siehst Du auch die Möglichkeit, andere, also höhere und niedrigere Ligen anzugeben: So eine allgemeine Box kann ja auch Verwendung in Artikeln nur zu einer Liga, also einer höchsten oder vielleicht einer zweiten Liga finden. Im DDR-Faustball werden derzeit ja alle Ligen einer Saison in einem einzigen Artikel - daher "Meisterschaft" behandelt. Eins noch: Wenn die Box in einem Artikel zu einer Frauenmeisterschaft Verwendung findet, ist es besser, kann man die Männerplatzierungen weglassen, aber die Überschrift zu den Platzierungen hieße immer noch "Platzierungen Frauen". Außerdem ist ein kleiner Fehler drin: Es muß möglich sein, nur die Gewinner anzugeben. Derzeit tauchen die Platzierungen nur auf, wenn alle drei ersten Plätze angegeben sind. Das Bildchen für die Medaille könnte man auch den Nutzer angeben lassen, wenn er ein anderes als ein standardisiertes möchte. Zudem hast Du derzeit die Olympiamedaille verwendet. Ich weiß, das ist viel Ningelningel, aber Du kriegst das hin ;) Danke! --Tommes  10:37, 31. Okt. 2019 (CET)
Felderschattierung, optionale Parameter (bis auf Titel und Saison), und höhere/niedrigere Ligen hab ich eingebaut. Logo, Entfernung der Überschrift zu den Platzierungen und Medaillenbilder sind etwas schwieriger, mal schauen ob ich das hinkriege. Bzgl. den Medaillenbildern hast du natürlich recht, dass die olympischen Medaillen fehl am Platz sind, aber warum sollte man individuelle Medaillen angeben können, generische würden doch auch reichen? 147.142.70.70 10:52, 31. Okt. 2019 (CET)
So, Logo ist drin, Möglichkeit nur den Sieger anzugeben ist drin (allerdings in dem Fall ohne Medaillenbildchen, da imho in dem Fall unnötig), Überschriftenzusätze "Männer" und "Frauen" erfolgen nur, wenn beide Geschlechter angegeben sind. Bei Medaillenbildern möchte ich noch etwas abwarten. Hast du weitere Wünsche? :) 147.142.70.70 11:24, 31. Okt. 2019 (CET)
Ich persönlich brauche keine nichtgenerischen Medaillenbildchen, aber die Möglichkeit, zum Beispiel einen Lorbeerkranz oder wasweißich - die goldene Wurst anzugeben, erhöht die Verwendungsbreite. Kannst Du das mit Logo so anordnen wie bei Navigationsbox Eishockeyliga? Vielen Dank! --Tommes  14:23, 31. Okt. 2019 (CET)
Logo-Platzierung ist jetzt wie in der Basketball-Box, Größe lässt sich individuell einstellen. 147.142.70.70 15:11, 31. Okt. 2019 (CET)

@Tommes: Kann der Abschnitt hier auf erledigt gesetzt werden? 178.10.52.216 23:19, 4. Nov. 2019 (CET)

Wenn es sein soll. Ich hege im Moment gerade nicht die Bestrebung, die Box auszutesten. Wie soll ich mit dem Ersteller, einer IP anders kommunizieren? --Tommes  23:23, 4. Nov. 2019 (CET)
Wir können hier oder auf deiner Disk reden. 178.10.52.216 23:25, 4. Nov. 2019 (CET)

Vorlage:IGEOEBearbeiten

Die in vielen Artikeln über portugisische Gemeinden eingebundene Weblink-Vorlage Vorlage:IGEOE funktioniert nicht mehr. Über die Homepage des IGEOE komme ich nur auf eine Seite, wo ich aber nur eine Aufforderung bekomme Adobe Flash zu installieren. Weiß da jemand ob und wenn ja wie man die Vorlage wieder funktionsfähig bekommt? --Wickie37 13:31, 24. Okt. 2019 (CEST)

Infobox Friedland (Mecklenburg)Bearbeiten

In der Infobox wird für den 31.12.2018 eine Einwohnerzahl von 6472 angezeigt. In der dazugehörigen Quelle (siehe Einzelnachweis) sind es aber 6354. Die Angaben werden automatisch aktualisiert. Wo liegt der Fehler? --85178abc (Diskussion) 13:17, 25. Okt. 2019 (CEST)

Erledigt. Vielleicht wurde die Quelldatei nachträglich geändert? Stichprobenhaft überprüfte Werte anderer Städte waren nämlich ok. --Magnus (Diskussion) 13:24, 25. Okt. 2019 (CEST)
falsch, Eingemeindung vom 26.05.2019 erhöht die EWZ. mfg --Thomas021071 (Diskussion) 16:28, 25. Okt. 2019 (CEST)
Dein Einwand und die Zurücksetzung sind nicht hilfreich, da der Stand von 12/2018 angegeben ist. --Magnus (Diskussion) 17:23, 25. Okt. 2019 (CEST)
Wo hast du deine Daten her? nicht vom Statistisches Amt M-V – Bevölkerungsstand der Kreise, Ämter und Gemeinden 2018 (XLS-Datei) (Einwohnerzahlen in Fortschreibung des Zensus 2011) (Hilfe dazu). Da steht die Zahl drin, dann kommt noch die Eingemeindung dazu. das wird in der IB angezeigt. Die IB soll tagesaktuell gehalten werden. mfg --Thomas021071 (Diskussion) 18:02, 25. Okt. 2019 (CEST)

Nein, die Infobox soll nicht tagesaktuell gehalten, sondern einmal jährlich aktualisiert werden (siehe Wikipedia:WikiProjekt Kommunen und Landkreise in Deutschland/Einwohnerzahlen). --85178abc (Diskussion) 18:31, 25. Okt. 2019 (CEST)

schon wieder falsch, sie wird automatisch jährlich aktualisiert und ist Tagesaktuell. mfg --Thomas021071 (Diskussion) 18:37, 25. Okt. 2019 (CEST)

Durch Deine Rücksetzungen steht in der Infobox für den 31.12.2018 wieder eine falsche Zahl. --85178abc (Diskussion) 18:53, 25. Okt. 2019 (CEST)

Du must lernen wie das hier abgeht, IB tagesaktuell! ich kann dir Die IB auch zerschießen dann suche mal! viel Glück. mfg --Thomas021071 (Diskussion) 18:58, 25. Okt. 2019 (CEST)

Die Angabe in der Infobox für den 31.12.2018 (6472) entspricht aber nicht der Quelle [1] (6354). Was nun? --85178abc (Diskussion) 19:22, 25. Okt. 2019 (CEST)

kann sie auch nicht. Wie groß ist Friedland in der Fläche und wieviel Ortsteile hatte Friedland 2018? Wann war die letzte Eingemeindung? Wo ist der heutige Wert? Artikel lesen bitte. mfg--Thomas021071 (Diskussion) 19:37, 25. Okt. 2019 (CEST)
Der Wert kann nicht tagesaktuell gehalten werden, da gar keine tagesaktuellen Daten veröffentlicht werden. Zum 31.12.2018 hatte die Gemeinde nunmal nur 6354 Einwohner, da würde ich niemals auf die Idee kommen, dass da jemand eine spätere Eingemeindung bereits miteingerechnet hat, wenn da das Datum dransteht. Ich gehe davon aus, dass es den meisten Lesern so geht. Daher werde ich das wieder zurücksetzen. --Wickie37 20:41, 28. Okt. 2019 (CET)
Und dass jetzt die Bevölkerungsdichte Unsinn ist, ist dir egal? Tut mir leid, aber so geht das nicht. Wir haben jahrelangen Konsens, wie das geregelt wird, und das wird sicherlich nicht in der Vorlagenwerkstatt geändert. NNW 17:26, 29. Okt. 2019 (CET)
Wenn euch egal ist, dass die Einwohnerzahl Unsinn ist, darf es mir ja wohl auch egal sein, wenn die bevölkerungsdichte Unsinn ist. Zumal ich ja nun nichts dafür kann, dass die Vorlage so unsinnig programmiert ist, dass da keine korrekte Darstellung möglich ist. --Wickie37 17:45, 29. Okt. 2019 (CET)
Die Einwohnerzahl ist nicht Unsinn. Ihr behauptet, der Punkt „Einwohner“ in der Infobox bedeute „Einwohner der Gemeinde“. Tut es aber nicht. Er bedeutet „Einwohner des aktuellen Gemeindegebietes“ und deshalb ist die Zahl auch richtig. Deine Änderung hat nicht nur für eine falsche Bevölkerungsdichte geführt, sondern auch auf Landkreis Mecklenburgische Seenplatte dazu, dass 8406 = 866 + 6354 + 1068 ist. Dass da 118 Leute fehlen, scheißegal, was? NNW 17:57, 29. Okt. 2019 (CET)
Das steht da aber nicht so, und das Datum impliziert nunmal, dass es um den Zustand zu diesem Datum geht. Wenn ihr das unbedingt so haben wollt, sollte das Datum da entfernt werden, an der Quelle ist dann ja immer noch erkennbar auf welchem Stand die Zahl basiert. Und wie macht ihr das eigentlich, wenn es gar keine Daten für das neue Gebiet gibt, weil nur Teile einer Gemeinde eingegliedert wurden? --Wickie37 18:40, 29. Okt. 2019 (CET)
Es steht da weder das eine noch das andere, deshalb ist es sinnlos zu behaupten, es wäre auf jeden Fall falsch. Auch für Teileingemeindungen gibt es vorher Gesetze, die erläutern, was wohin kommt. Ich kann mich an keinen Fall erinnern, bei dem vorher keine Zahl bekannt war. Teileingemeindungen kommen aber auch nur sehr selten vor. NNW 18:44, 29. Okt. 2019 (CET)
"weder das eine noch das andere" meinetwegen, aber nutzlos ist die zahl dann ja auch, wenn unklar ist worauf sich die bezieht. Und zumindest bei der großen Gebietsreform in NRW 1975 gab es Dutzende Teileingemeindungen und Grenzneudefinitionen zwischen Gemeinden. Da hättet ihr ganz sicher keine vollständigen Daten gehabt. --Wickie37 19:01, 29. Okt. 2019 (CET)
Hätte, hätte. Wir hätten auch kein Internet gehabt. Alle Jubeljahre kommt vielleicht einer, der die Zahlen hinterfragt. Der ganze Rest hat offensichtlich kein Problem damit. NNW 19:04, 29. Okt. 2019 (CET)
...weil sie uns vertrauen und das gar nicht überprüfen. Das macht die Sache doch nicht besser. --Wickie37 19:10, 29. Okt. 2019 (CET)
Das das Datum da steht sagt nur die amtlichkeit, Wenn man den Artikrl liest sieht es anders aus. Verfolge mal den Kreis Höxter in der Infobox zwischen 7. und 8.11. ,dort wirst du die nächste Veränderung sehen. mfg --Thomas021071 (Diskussion) 19:12, 29. Okt. 2019 (CET)
Und die Änderung wird dann auch mit einem Datum versehen? Wahrscheinlich nicht, obwohl das da sogar eine tatsächliche Zusatzinformation wäre... --Wickie37 19:23, 29. Okt. 2019 (CET)
Alle doof außer Mutti? Glaube ich nicht. NNW 19:13, 29. Okt. 2019 (CET)
Aber ich, NNW du bekommst Arbeit mal wieder mfg --Thomas021071 (Diskussion) 19:20, 29. Okt. 2019 (CET)
Die Einwohnerzahl in der Infobox soll also bedeuten: „Einwohner des aktuellen Gemeindegebietes“ und nicht „Einwohner der Gemeinde“. Woher soll der Leser das wissen? Die jetzige Zahl heißt: Wenn Genzkow schon 2018 eingemeindet worden wäre, hätte die Stadt am 31.12.2018 6472 Einwohner gehabt. Wurde es aber nicht. Und eine solche verquere Logik verteidigt Ihr mit Hinweisen auf die Bevölkerungsdichte und auf Daten von Landkreisen. Ist das wirklich Euer Ernst? --85178abc (Diskussion) 20:20, 29. Okt. 2019 (CET)
Die Probleme der Infobox habe ich dir nun wirklich ausführlich erläutert. Du hast bislang kein Konzept vorgelegt, wie das sinnvoll und pragmatisch umgesetzt werden kann, aber stattdessen eine (!) Zahl verändert und dadurch sowohl im Gemeindeartikel als auch in anderen Artikeln Unsinn erzeugt. Hier beklagst du einen Fehler; dass du mit deiner Änderung viel mehr Fehler erzeugst: scheißegal. Da stellt sich mir die Frage: Ist das dein Ernst?
Nochmal: Die Infobox stellt die aktuellen Werte zusammen, Bürgermeister, Anschrift, Autokennzeichen, Ortsteile, Wappen, Lagekarte, Fläche und notgedrungen auch Einwohner. Es geht nicht, dass Fläche und Einwohnerzahl unterschiedliche Zeitstände haben. Das Ganze beginnt sich im Kreis zu drehen. NNW 10:34, 30. Okt. 2019 (CET)
Ist es denn nicht möglich wenigstens eine Fußnote dazu direkt über die Vorlage:Metadaten Einwohnerzahl einzufügen? Da würde die dann auch nicht bei der nächsten Aktualisierung übersehen. --Wickie37 10:41, 30. Okt. 2019 (CET)
Es hat wohl wenig Sinn, hier weiterzudiskutieren. Vorschläge wie u. a. die Fußnote werden als "arbeitsaufwändig, leserunfreundlich, nicht pragmatisch" abgebürstet (siehe Diskussion:Friedland (Mecklenburg)), auf Gegenargumente wird nicht eingegangen und das bisherige Vorgehen verteidigt, denn Änderungen wären "gegen die bisherige Praxis gestrickt". Auf Kompromissfähigkeit darf man hier anscheinend nicht hoffen. --85178abc (Diskussion) 11:45, 30. Okt. 2019 (CET)
Stimmt, selbst mein obiger noch einfacherer Kompromissvorschlag, nämlich einfach das Datum da wegzumachen, wurde ignoriert. --Wickie37 12:16, 30. Okt. 2019 (CET)
Der wurde ignoriert, da er nichts bringt. Es käme nämlich der nächste und würde fragen, warum das Datum nicht angegeben wäre wie sonst immer, und letztlich landete man doch wieder bei 31. Dezember 2018. Das Datum verschwindet nicht, nur weil man es nicht angibt.
Dass ich nicht auf Gegenargumente eingegangen sei, ist schon eine ziemliche Frechheit. Ich habe dir genau erläutert, warum das so gehandhabt wird und nicht anders. Und ja, dein Vorschlag der Fußnoten betrifft immer noch eine dreistellige Anzahl von Artikeln allein in diesem Jahr (denn es geht nach wie vor nicht allein um Friedland), und das allein wären schon deutlich mehr Bearbeitungen als Benutzer:85178abc in seiner gesamten WP-Karriere bislang gemacht hat. Allein dass die Diskussion hier stattfindet und nicht auf der Infobox-Disk und dass Änderungen immer nur am Wert von Friedland gemacht werden, zeigt deutlich, dass ihr das Problem in seiner kompletten Breite nicht erfasst habt. Und jetzt könnt ihr gerne weiterschmollen, für mich ist das jetzt hier beendet. NNW 12:34, 30. Okt. 2019 (CET)
Bei der Bevölkerungsdichte ist auch kein Datum angegeben, hat sich da jemals jemand drüber beschwert?. Das soll doch auch gar nicht ganz verschwinden, sondern nur aus der Box, weil es da suggeriert, dass diese Angabe anders wäre als der Rest der Box.
Und die Diskussion findet hier statt, weil sie hier gestartet wurde. Als alter Wikihase solltest du doch den Grundsatz kennen, dass man Diskussionen nicht unnötig auf mehrere Orte verteilen sollte. --Wickie37 13:56, 30. Okt. 2019 (CET)
Und ich denke mal wir schließen das hier ab, Denn die Disskusionen fangen immer Ende des Jahres an, weil jeder etwas im Fliestext eintragen möchte ohne den Artikel zulesen. Dann sieht dieser eine Quelle und vergleicht (habe ich auch gemacht und geändert) und ich wurde angeriffen. Und ? ich habe mich damit befasst. Ich habe Gemeinden gesehen die aufgelöst wurden, da wird die IB entfernt, obwohl Daten nachgehalten werden könnten. aber das war mal. mfg --Thomas021071 (Diskussion) 00:42, 31. Okt. 2019 (CET)
@NNW: Ja, Du hast mir etwas erläutert, nämlich, dass Deine Auffassung natürlich richtig wäre. Für den gleichen Zeitpunkt zwei verschiedene Einwohnerzahlen innerhalb eines Artikels, dies wäre eben "notgedrungen" ein Kollateralschaden Eurer Methode. Wicki37 und ich hatten vorgeschlagen, dies in einer Fußnote zu erklären. Sich vielleicht einmal Gedanken zu machen, dem Leser diese verwirrende Information wenigstens plausibel zu machen - Fehlanzeige. Dass Du dann persönlich wirst und mir süffisant meine noch geringe Zahl an Edits vorrechnest, sollte für einen Administrator eigentlich ein No-Go sein. --85178abc (Diskussion) 10:26, 31. Okt. 2019 (CET)

"Template:Refn" der :en:Wiki in die :de:Wiki importierenBearbeiten

Hallo zusammmen,

wäre es machbar das en:Template:Refn der :en:Wiki auch hier in die :de:Wiki zu importieren? Das wäre ungemein praktisch, da man etwa die Begriffsdefinition / Einleitung ja nicht durch Dutzende von Einzelnachweisen überfrachten will, aber dennoch irgendwie strittige Dinge mit einem Beleg versehen muss. Gruß --Tilon3 (Diskussion) 01:17, 26. Okt. 2019 (CEST)

Es gibt Vorlage:FN, mit den dort beschriebenen Nutzungseinschränkungen. -- hgzh 12:49, 26. Okt. 2019 (CEST)
@hgzh OK. Heißt das jetzt, dass das Gruppieren von Belegen im normalen Fließtext des Artikels in der :de:Wiki grundsätzlich unerwünscht ist oder hat die Einschränkung technische Gründe? --Tilon3 (Diskussion) 01:37, 27. Okt. 2019 (CEST)
Du kannst <ref>s gruppieren: <references group="A" />, Beispiel „Volksstamm #Einzelnachweise“. Gruß --Chiananda (Diskussion) 02:50, 27. Okt. 2019 (CEST)

Hier gehen zwei Bedeutungen von „Gruppieren“ durcheinander:

  1. „Gruppieren“ im Sinne einer Gruppe in einem eigenen <ref>-Block, wie es zutreffend von Chiananda beschrieben wurde.
  2. Ein <ref>, der als Einzelstück oben im Text erscheint und sich dann wie ein Feuerwerk unten in viele <ref> zerlegt.

Das erstere ist hierzuwiki völlig okay. Das zweite, das Template:Refn macht, ist hierzuwiki strikt unerwünscht.

  • Wir wollen eine einfache und klare Zuordnung von ref-Nummern und zugehörigen Texten.
  • Das dient sowohl den Lesern wie auch den nachfolgenden Autoren.
  • Ein zweites ref-System, nur damit im Einleitungsabschnitt oder sonstwo nicht so viele ref-Nummern sichtbar würden, ist verwirrend und schwer nachzuvollziehen.
  • Du kannst ja innerhalb eines ref-Elements mehrere Bücher erwähnen oder Grabsteinfotos oder sonstwas; es muss nicht jedes Buch ein ref für sich allein bekommen.
  • Nur wenn derselbe <ref>-Text mehrfach genutzt werden soll, wäre ein eigenes <ref> nur dafür erforderlich. Das ist aber bei der Erörterung der Lebensdaten nicht übermäßig wahrscheinlich; und falls dann doch mal auf ein Standardwerk vielfach verwiesen werden soll, dann stehen halt mal drei oder auch fünf ref-Anmerkungen hintereinander an derselben Stelle. Das ist aber immer noch besser als das Misthaufenspiel mit einem ref, der in einen anderen ref führt, wie es die enWP betreibt.
  • Aus einem ref heraus sind bei uns keine anderen ref mehr zulässig; Stichwort Misthaufenspiel, denn von dort kann wieder in einen anderen ref gesprungen werden ad infinitum. Die innerhalb der Vorlage verwendete Konstruktion, mit der die eigentlich unmögliche Konstruktion <ref>-in-<ref> dann doch möglich würde, ist bei uns wegen Unkontrollierbarkeit und potenzieller zukünftiger Risiken nicht zulässig.
  • Das von hgzh genannte FN-System wäre davon unabhängig; aber eine solch komplizierte Anmerkung, die in sich wiederum mehrere Anmerkungen bräuchte, wäre bei uns sehr unüblich und das würden wir lieber als normalen Artikeltext sehen wollen. Als <ref> verwenden wir kurze Belege, bei denen ein oder mehrere Bücher, Websites, Zeitschriften genannt werden, aber keine eigenständigen komplizierten Abhandlungen.

VG --PerfektesChaos 19:31, 27. Okt. 2019 (CET)

Ohje. Diese Sache so darzustellen, wie es Template:Refn macht, z.B. im ersten Beleg von en:Socialism, ist sowohl übersichtlich, als auch absolut unmissverständlich hinsichtlich der Zuordnung. Dieser institutionelle Unwillen von de.wiki einfachste Neuerungen einzuführen, die sich anderswo bereits bewährt haben, wird langsam wirklich zum Problem. Und wenn sich dann irgendwann die WMF zum Eingreifen genötigt sieht, ist das Gejammer wieder groß. Nichts für ungut und danke für die Auskunft. Gruß --Tilon3 (Diskussion) 21:48, 28. Okt. 2019 (CET)
Die Programmierung von <ref> verbietet es ausdrücklich, dass in ein <ref> ein anderes <ref> eingebunden wird.
Nur mit einem Trick wird in der enWP diese Sperre unterlaufen und die verbotene Nutzung <ref> in <ref> umgangen.
Jederzeit kann ohne Ankündigung die Sperre in der Programmierung von <ref> auch auf diese Fälle wirksam werden, und dann säßen wir auf einem Haufen Fehlermeldungen und müssten in wildfremden Artikeln irgendwie auseinanderdröseln, was die mal gemeint hatten.
Es ist auch nicht im geringsten Leser- oder Bearbeiterfreundlich, wenn der Beleg zu [4] durch [14] und [15] belegt wird, wobei [14] dann wieder durch [12] belegt wird, welcher wiederum ein <ref> auf [7] enthält, und dieser womöglich den Kreis schließt und sich durch [4] belegt.
Eine Belegnummer ist ein einzelner Nachweis, der aus einer oder mehreren Publikationen besteht, und damit Ende. Übersichtlicher und verständlicher geht es nicht. Ich kann mir merken, was der Beleg [4] ist, insbesondere wenn diese Nummer mehrfach auftritt. Mich dann aber zwischen Dutzenden von Belegen kreuz und quer durch immer wieder neue Belegverweise zu scheuchen ist gaga.
VG --PerfektesChaos 22:16, 28. Okt. 2019 (CET)

Vorlage:Infobox Gemeinde in DeutschlandBearbeiten

Ist es möglich, die Vorlage so zu programmieren, dass unter der Zeile "Einwohner" die Bemerkung steht: (aktuelles Gemeindegebiet)? Das Problem wird oben unter Infobox Friedland (Mecklenburg) diskutiert, um Missverständnisse bei Eingemeindungen zu vermeiden. --85178abc (Diskussion) 09:03, 2. Nov. 2019 (CET)

Infobox Gemeinde in NamibiaBearbeiten

Die Infobox Gemeinde in Namibia zeigt eine Karte mit der zum Ort gehörenden Region, statt eine Positionskarte des Ortes. Siehe zum Beispiel Gochas. Kann jemand die Vorlage so abändern, dass in der Infobox eine Karte wie zB auf der englischen Wikipedia Seite en:Gochas erscheint? --Hp.Baumeler (Diskussion) 12:57, 5. Nov. 2019 (CET)

Vorlage:Zeitleiste_Universal_Automatic_CalculatorBearbeiten

Kennt sich jemand mit "timeline" aus? Ganz unten ist da blauer und grauer Text übereinander und damit unleserlich. --Wurgl (Diskussion) 23:05, 6. Nov. 2019 (CET)

Das ist ein Fehler in der Timeline-Extension, siehe Hilfe:Zeitleisten#Eingebettete Links. Was scheinbar nicht mehr geht: unverlinkter Text vor dem Link und Interwikilink zu Beginn des Textes. Was noch geht: unverlinkter Text hinter dem Link. Die Fehlermeldung schlägt dann aber an einer ganz anderen Stelle auf. Alles bisschen konfus. Ähnliches Problem wurde bereits hier (2005!) beschrieben. Gruß, -- hgzh 01:26, 7. Nov. 2019 (CET)
Motivierend sind solche methusaliösen Bugmeldungen nicht gerade :-( Irgendwas hat sich aber in den 13 Jahren (bzw. 8 seit der letzten Änderung der Vorlage) doch geändert. Wenn man etwas klitzekleines ändert (aus einer Leerzeile zwei macht oder ein Zeichen in einen anzuzeigenden Text einfügt) dann gibts eine Fehlermeldung:
EasyTimeline 1.90

Timeline generation failed: 1 error found
Line 14: ScaleMajor = unit:year increment:5 start:1950 gridcolor:grid1

- Scale attribute 'grid' invalid. Unknown color ''.

 Specify command 'Color' before this command.
Ich würde rotzfrech ja den Text unten entsprechend anpassen, aber solange Fehlermeldungen zu einem unveränderten Teil kommen lass ich die Finger davon. --Wurgl (Diskussion) 09:16, 7. Nov. 2019 (CET)
  pos:(30,2)  text:"Erzeugt mit"
  pos:(90,2)  text:"[[meta:Extension:EasyTimeline|EasyTimeline]]"
  pos:(550,2) text:"Quelle"
  pos:(600,2) text:"[[en:Template:Timeline History of Computing|En-Wikipedia]]"
meta:Extension:EasyTimeline 

Was allerdings nicht funktioniert ist der Interwikilink →En-Wikipedia meta: wird erkannt en: mag es aber nicht ein Weblink ginge dann aber dann nur mit sichtbarer url. Meta müsste auch umgebogen werden, wie ich es hier im Beispiel gemacht habe denn der Link landet im Nirgendwo. --Liebe Grüße, Lómelinde Diskussion 12:43, 7. Nov. 2019 (CET)

Ja, so in der Art hab ich mir das auch vorgestellt. Aber probier mal in der Vorschau mit einer kleinen anderen Änderung. "Erteugt" statt "Erzeugt" oder sowas. Da kommt manchmal ein Fehler, manchmal aber nicht. Irgendwie je nachdem welchen Server man gerade erwischt oder so. Wenn mal ein Fehler da war, dann ist der wohl im Cache und kommt immer wieder, ist kein Fehler, dann ist das wohl auch gecacht und es bleibt bei "kein Fehler." Solange das so instabil ist, lang ich da ganz sicher nicht hin. --Wurgl (Diskussion) 12:59, 7. Nov. 2019 (CET)
Der Zustand der Grafikenunterstützung in MediaWiki ist recht trostlos. Um EasyTimeline kümmert sich niemand mehr und der designierte Nachfolger, die Graph-Erweiterung, kann diese nicht ersetzen, ist inzwischen ebenfalls ohne festen Betreuer und wurde mE von Anfang an eher stiefmütterlich behandelt. Stattdessen ein Haufen Arbeit für irgendeine unnütze Vandalismuserkennungs-„KI“, weil jede hippe Internetbude jetzt sowas haben muss. -- hgzh 15:11, 7. Nov. 2019 (CET)

Vorlage:KlappboxBearbeiten

Es ist mir nicht gelungen, eine Tabelle in einer Klappbox unterzubringen. Oder ist dies gar nicht möglich? Vielen Dank! Gruß --Mathemix (Diskussion) 14:14, 7. Nov. 2019 (CET)

Vorlage:WappenbeschreibungBearbeiten

Ich habe bei der Vorlage:Wappenbeschreibung vor kurzem eine Diskussion geöffnet, bei der mir niemand weiterhelfen konnte, siehe dieser Diskussionsabschnitt (Problem bei mobiler Wikipedia). Vielleicht kann ja hier jemand weiterhelfen. --FrühlingsSonnenBad (Diskussion) 00:34, 9. Nov. 2019 (CET)

Vorlage:CSS-Bildausschnitt könnte benutzerfreundlicher seinBearbeiten

In obige Vorlage setzt man eine Bilddatei als Quelle ein und gibt dann unter dem Parameter bSize laut Dokumentation die "Größe (Breite) des Originalbildes" ein. Anschließend wählt man noch Höhe und Breite des gewählten Ausschnitts sowie den Abstand zu linkem und oberen Bildrand aus. Das ist eigentlich einfach und logisch, aber: Der Ausschnitt wird dann wirklich so breit und hoch, wie man mit cWidth und cHeight angegeben hat. Das ist ein bisschen unpraktisch, denn um Bilder schließlich in die für sonstige Bild-Einbettungen üblichen Breiten wie mini zu bekommen, muss man zu dem Trick greifen, das Bild mit einer Angabe unter bSize als "kleiner" auszuweisen als die tatsächliche Originaldatei, und dafür dann noch entsprechend die weiteren Parameter ebenfalls so abändern, dass sie sich auf diese "kleinere" Größe beziehen. Das ist nicht unmöglich, aber relativ viel Fummelei.

Vorschlag: Das ließe sich in der Vorlage besser lösen, indem z.B. als zusätzlicher Parameter die Breite der Ausgabe (nicht des Ausschnitts!) angegeben werden könnte (falls kein Wert angegeben wird, sollte natürlich - auch im Interesse der Kompatibilität zu bisherigen Einbindungen der Vorlage - eben weiterhin der Wert unter cWidth hergenommen werden). Also, ginge das? -- КГФ, Обсудить! 01:49, 11. Nov. 2019 (CET)

Ich kenne diese Vorlage nicht, aber tut sie nicht im Grunde etwas ähnliches wie Vorlage:Annotiertes Bild?
Wieso haben wir denn da zwei solche Vorlagen?
Zu deiner Frage da es sich ja um eine Abhängigkeit handelt die von all diesen Parametern erzeugt wird, müsste man ja nach deinem Vorschlag eine Formel haben die das automatisch berechnet.
Man müsste also quasi erst einmal eine Basisgröße vorgeben und dann, wenn kleiner oder größer dynamisch die Abstände anpassen. Die Bildgröße (bSize; image-width) dient ja eher der Vergrößerung. Danach wird ein Teil der großen Datei ausgeschnitten und nur dieser Ausschnitt wird angezeigt. Dann müsste man also wenn 1000px = 100 % sind die anderen Werte berechnen. Sagen wir 750px, müsste rechnerisch also die Abstandswerte auf 75 % setzen, und die Größe des Ausschnittes ebenso?
50 %

 

CSS-Bildaus-schnitt
Ausschnitt Annotiertes Bild
75 %

 

CSS-Bildausschnitt
Ausschnitt Annotiertes Bild
100 %

 

CSS-Bildausschnitt
Ausschnitt Annotiertes Bild
175 %

 

CSS-Bildausschnitt
Das wäre wohl in etwa das, was du meinst, denke ich. Ich kann aber leider gerade nur mit der Vorlage:Annotiertes Bild in der mobilen Ansicht überhaupt ein Bild sehen, wenn man das über eine Berechnung lösen würde. Ich werde daher auch keine dieser Vorlagen anfassen. --Liebe Grüße, Lómelinde Diskussion 12:15, 11. Nov. 2019 (CET)
Das ist ein uralter Hack aus dem Jahre 2008.
Kopiert aus der enWP; dahin müsstest du dich mit deinen Anregungen wenden.
Sie arbeitet mit position:relative und nahezu alles was damit rumfummelt macht früher oder später den Altmaier und schießt sich selbst oder andere Elemente auf der Seite ab.
Deshalb steht da auch ein großer roter Kasten drüber, und die beste Benutzerfreundlichkeit bekommst du, wenn du die Finger davon lässt.
An der Grundproblematik hat sich auch niemals etwas geändert.
Diese Vorlage kann prinzipiell nicht zu robusten Ergebnissen führen, wie sie für unseren ANR erforderlich sind. Völlig wurscht wie oft andere Wikis dieses Etwas benutzen.
Nebenbei bemerkt verhindert das Dings die Verwendung der Miniaturbild-Eigenschaft und zwingt Lesern, die das nicht haben wollen, vielleicht wegen langsamem oder teurem Internet, immer ein Bild fester Größe auf, mit dem Gesamtbild in starrer Auflösung.
Ich habe jetzt mal diverse der Vorlageneinbindungen im ANR durchgeklickt und musste feststellen, dass die Vorlagenverwendung oft völlig sinnlos und absolut bescheuert war: Es wurden nur winzige Streifen an den Rändern weggeschnitten, während das Originalbild bereits den richtigen Ausschnitt zeigte. Hätte man es bei der Minibild-Funktion belassen, dann hätten die, die große Bilder sehen möchten, große bekommen und die, welche kleine Bilder brauchen, kleine. Auf Mobilgeräten wäre dynamische Anpassung möglich. Jetzt haben alle ein Bild fest vorgegebener Einheitsgröße mit nahezu dem gleichen Bildausschnitt wie ohne Vorlage. Wenn Schwachköpfe mit Hacks rumpfuschen, muss Scheiße bei rauskommen.
Dein Ziel, mini zu erreichen, wird ohnehin nicht funktionieren. Das ist eine Eigenschaft, die von den Wunscheinstellungen des momentanen angemeldeten Benutzers oder einer Vorgabe für unangemeldete Leser abhängt, und im Prinzip auch abhängig von der Art des aktuellen Gerätes nachjustiert werden kann. Die Vorlage setzt jedoch einen statischen Wert.
Ergo: Weiterhin keine Freigabe für den ANR, Benutzung auf eigenen Benutzerseiten auf eigene Gefahr.
VG --PerfektesChaos 12:29, 11. Nov. 2019 (CET)
Ah, danke für die Hinweise. Vorlage:Annotiertes Bild war mir bislang unbekannt. Wahrscheinlich wäre ein Hinweis darauf bei der anderen Vorlage sinnvoll, wenn das eh nur gefährliches Flickwerk sein soll. Andererseits bin ich auf Vorlage:CSS-Bildausschnitt im ANR gestoßen, und zwar im Artikel Karlstad, und da zeigt sich mal wieder: Viele Dinge macht man hier auf eine bestimmte Weise, weil man sie irgendwo in Artikeln sieht und dann nachahmt... -- КГФ, Обсудить! 19:25, 11. Nov. 2019 (CET)

Vorlage:Infobox Gemeindeverband in DeutschlandBearbeiten

Vor drei Wochen hab ich in Vorlage Diskussion:Infobox Gemeindeverband in Deutschland#Parameter "Gegründet" nachgefragt, warum der Parameter "Gegründet" nur angezeigt wird, wenn auch der Parameter "Aufgelöst" belegt ist. Gab nicht so arg toll viele Reaktionen, vielleicht hier? (nicht signierter Beitrag von Wurgl (Diskussion | Beiträge)) 11:16, 11. Nov. 2019 (CET)

Scheint mir willkürlich zu sein. Die Funktionalität kommt aus der Vorlage:Infobox Verwaltungseinheit in Deutschland:
{{#if: {{{Aufgelöst|}}} | {{#if: {{{Gegründet|}}} | {{!}} Bestandszeitraum: {{!}} {{#iferror: {{#ifexpr: {{{Gegründet}}} - {{{Gegründet}}} = 0 | {{{Gegründet}}} | {{#time:Y|{{{Gegründet}}}}} }} | <span class="error">Gegründet im Format JJJJ-MM-TT</span> }}–{{#ifexpr: {{{Aufgelöst}}} - {{{Aufgelöst}}} = 0 | {{{Aufgelöst}}} | {{#time:Y|{{{Aufgelöst}}}}} }} }} }}
M.E. fehlt hier nur der "else-Zweig", d.h. welche Ausgabe soll erfolgen, wenn Aufgelöst nicht gesetzt ist, aber Gegründet schon. --Magnus (Diskussion) 12:27, 11. Nov. 2019 (CET)
Dann existiert dieses Konstrukt noch (oder es fehlen Daten), also dann nur Gegründet 1999. Und so nebenbei wird da ein Fehler ausgegeben wenn das gegründet-Datum nicht passt, beim Aufgelöst-Datum kann man aber irgendwas reinschreiben, da wird nix geprüft. --Wurgl (Diskussion) 12:47, 11. Nov. 2019 (CET)

Warum zwangsweise "w= ..." und "&lrm;"?Bearbeiten

  1. Bei dem überwiegenden Teil der Vorlagen zu Asiatischen R2L-Schriften ist das w= entbehrlich und wird sogar meistens als unbekannter Parameter reklamiert. Vorgegeben ist es nur bei Vorlage:ArS und Vorlage:OtaS, bei otaS' ist es aber entbehrlich, es funktioniert da auch ohne w=, nur mit dem Wort (vermutlich wegen |3={{{2|{{{w|}}}}}}. Warum gerade hier die zwingende „Extrawurst“ bei arS? Wo liegt der Nutzen?
  2. Dass &lrm; Sinn bringt, ist unbestritten. Unsinnig ist, dass man es immer extra eingeben muss! Warum wird es in der Vorlage nicht fest eingebaut? Mit einer winzigen Änderung klappt es: Statt ...t|{{{1|}}}|ar}}{{#if:{{{w|}}}| '... kommt ...t|{{{1|}}}|ar}}&lrm;{{#if:{{{w|}}}| '... und schon klappt es! Bei den anderen Vorlagen kann es ähnlich ablaufen und noch geschickter wäre eine Anpassung der Vorlage:lang bzw. Modul:Vorlage:lang.
    Dabei müssten die unzähligen, bestehende Funktionsaufrufe, bei denen&lrm;bereits eingetragen ist, nicht unbedingt geändert werden, denn&lrm;&lrm;hat die gleiche Wirkung wie&lrm;. --Klaus-Peter 13:08, 11. Nov. 2019 (CET)
Zu 1. w=
  • Das ist ein Relikt aus der Kindergartenzeit.
  • Zunächst hatte sich jede Sprache ihre eigene Vorlage gebastelt und dabei eigene Parameternamen vergeben und den Parametern andere Bedeutungen für die jeweilige Sprache unterlegt.
  • Ich habe im Verlauf der letzten fünf Jahre für die allermeisten Sprachen eine Vereinheitlichung und Erweiterung der Parameternamen herbeigeführt.
  • w= im Sinne von „Wikipedia-Transkription“ heißt heute 2= für alle in nichtlatenischen Schriften geschriebenen Sprachen.
  • Nur ar und zh sind bislang nicht standardisiert worden; ota migriert gerade noch und versteht bis zum Abschluss der Migration beide Formen.
Zu 2. &lrm;
  • Dies dient ausschließlich zur Ausstattung im Quelltext des Artikels.
  • Die Gründe stehen bei H:RTL.
  • Es würde in bestimmten Situationen die schließenden Klammern in der Darstellung des Quelltextes nach vorn umklappen, und je nachdem was für Zeichen sich anschließen dann auch diese von „dahinter“ nach „davor“ gespiegelt zeigen.
  • Im weiteren Verlauf der Vorlagen- bzw. Lua-Programmierung werden diese und auch weitere Steuerzeichen jedoch eliminiert. Der eigentliche Schutz des Textfragments vor Fehlinterpretation durch den Unicode-Bidi-Algorithmus im Browser des Lesers erfolgt durch spezielle HTML-Elemente und Attribute. Im nach außen gelangenden HTML-Dokument kommen diese Steuerzeichen überhaupt nicht mehr vor und würden heutzutage eher stören.
  • Dein Vorschlag, diese Steuerzeichen in die Vorlagenprogrammierung zu verlegen und nicht mehr im Quelltext zu schreiben wäre sinnfrei: Die Vorlagenprogrammierung braucht die Steuerzeichen gar nicht, und würde sie ohnehin entfernen, weil der Unicode-Bidi-Algorithmus nicht auf die Textinhalte innerhalb der Lua-Programmierung wirkt und sie dort nicht stört. Der Quelltext würde hingegen ggf. zerschossen, weil du die &lrm; weglässt und der Browser des Bearbeiters den Unicode-Bidi-Algorithmus auf den Quelltext anwendet.
VG --PerfektesChaos 17:46, 11. Nov. 2019 (CET)
Danke für die flotte und ausführliche Reaktion.
Das eine Kita-Relikt könnte man ja vermutlich flott entfernen, bzw. auf "2" erweitern, sonst gibt es ja Stress bei bestehenden Aufrufen. Ich bin bei der Vorlage:lang leider noch nicht so fit. Vermutlich dürfte es sich bei der fortschreitenden Umstellung automatisch ergeben.
dient ausschließlich zur Ausstattung im Quelltext des Artikels. Ich bin darauf gestoßen, weil bei der Darstellung ohne &lrm; etwas nicht stimmte. Das Dschumhūriyyat Misr al-ʿarabiyya hinter dem «جمهوريّة مصر العربيّة» wurde ohne &lrm; einfach unterschlagen. Der Quelltext macht nur bei einigen Ostasiaten Stress, die Araber habe ich fest im Griff. Inzwischen habe ich das Problem in meinem Modul pauschal gelöst-- mit passend generiertem &lrm; »→ gypten  Ägypten (arabisch جمهوريّة مصر العربيّة Dschumhūriyyat Misr al-ʿarabiyya)
Schönen Abend --Klaus-Peter 19:37, 11. Nov. 2019 (CET)