Diese Seite bietet eine Übersicht der archivierten Diskussionen der Vorlagenwerkstatt. Die Abschnitte der einzelnen Archive sollten nicht mehr verändert werden.
Hallo könnte bitte mir wer helfen? Bei der obigen Vorlage Linktitel automatisch beim Einfügen der Vorlage mit aufgeführt. Wenn er leer bleibt wird der Seitentitel nicht mehr übernommen. Was müsste man an der Vorlage ändern damit bei leerem Feld der Seitentitel übernommen wird. Theater88 (Diskussion) 21:25, 2. Okt. 2019 (CEST)
Mit der Vorlage:ETCS-Spezifikation soll ein zentraler Ort geschaffen werden, mit dem der sich regelmäßig ändernde Weblinks zur „ETCS-Spezifikation“ zentral aktualisiert werden kann. Als Vorlagen-Neuling treiben mich zwei Fragen um:
Welcher Kategorie sollte eine solche einfache Vorlage zugeordnet werden?
Wie lässt sich ein Zeilenumbruch vermeiden, sodass die Vorlage auch in den Fließtext oder einfache Einzelnachweise eingebunden werden könnte?
Erst einmal müsstest du erklären was genau du dort verlinken möchtest, ja vermutlich nicht diese Seite, die ja nicht das Ziel wäre, oder?
Es müsste also ermittelt werden welche Parameter benötigt würden, gibt es eine unveränderliche ID? Gibt es URL-spezifische Unterteilungen, beispielsweise für Dokumente, Personen, Datenbankangaben, was weiß ich.
Ich kann dir gern helfen, aber dafür müsste ich mehr Informationen haben.
Mich treibt momentan nur eine Frage um: Wer, wie oder was ist „ETCS“?
Das würdest du dem gesamten Vorlagen-Namensraum und dem Projekt in seiner Gesamtheit schon mitteilen müssen, und zwar am Namen der Vorlage ablesbar.
Wenn du uns dann noch eine URL als Beispiel lieferst, und Parameter, von denen die Generierung des Weblinks abhängen soll, dann bekommst du schon was serviert und kannst daran sehen, wie sich das alles so macht.
Momentan ist das ja eine konstante URL??? Das würde kaum eine Vorlage lohnen; sowas kann notfalls irgendwann ein Bot umstellen.
Es geht tatsächlich um einen statischen Weblink, ohne Parameter, der sich in den letzten Monaten immer wieder verändert hatte, sodass mit weiteren regelmäßigen Veränderungen zu rechnen wäre.
Dann sehe ich leider auch keinen Bedarf für eine Vorlage. Um die Ersetzung von Totlinks kümmern sich extra dafür konzipirte Bots. --Liebe Grüße, LómelindeDiskussion14:21, 3. Okt. 2019 (CEST)
Sieht für mich so aus, als sei das nicht vorgesehen. Da die Fahrernamen in der Vorlage hart codiert sind, müsste wohl ein zweiter Parameter her. --Magnus(Diskussion)12:49, 4. Okt. 2019 (CEST)
Hallo, ich möchte das Dictionary of Scientific Biography als automatisierte Literaturvorlage umsetzen, ähnlich wie beispielsweise bei Allgemeine Deutsche Biographie, sodaß etwa nur noch eine Angabe z. B. der Form {{ADB|7|140|142|Flurl, Mathias von|[[Wilhelm von Gümbel]]|ADB:Flurl, Mathias von}} gemacht werden muss.
Ich stelle mir das in etwa folgendermaßen vor: {{DictSciBiogr|BandNr|Anfangseite|Endseite|Beitragsautor|Kommentar}}
Als PDF-Auszug habe ich das schon mal bei Charles Augustin de Coulomb gesehen, das ist aber meineswissens eine Ausnahme. Biografische Details kann ich vielleicht direkt in den Artikel Dictionary of Scientific Biography schreiben. Ich hätte allerdings jetzt nur mal an die 16 Grund-Bände und die beiden Supplementbände (II) gedacht, alles weitere könnte man vielleicht als Kommentar hinzufügen.--Thmsfrst (Diskussion) 13:34, 5. Okt. 2019 (CEST)
Die 8 neuen Bände sind für Wissenschaftler ab Todesdatum 1950, dies sollten wiederrum also andere Personen sein. Ich hätte jetzt mal nur an die ersten 18 Bände gedacht.--Thmsfrst (Diskussion) 15:00, 5. Okt. 2019 (CEST)
Inhaltlich kann ich es nicht sagen, aber die haben ja die selben Namensbereiche eben immer nur als Doppelausgabe. Muss ich sehen, ob ich etwas finde. Sonst lasse ich lieber die ISBN weg. Das ist mir nicht eindeutig genug. --Liebe Grüße, LómelindeDiskussion15:03, 5. Okt. 2019 (CEST)
in der oben genannten Vorlage wird die Zeit zwischen Wulff und Gauck – insbesondere auch im Vergleich zu der Zeit zwischen Köhler und Wulff – falsch dargestellt, da ist keine Lücke. Wie man es korrigiert, weiß ich leider nicht. Wenn man
Nein weiß ich auch nicht, wo genau soll die Lücke sein? Es hängt dort vermutlich eher mit der kurzen Amtszeit zusammen, so dass die Schrift keinen ausreichenden Platz hat. Ich habe mal die Gesamthöhe der Grafik erhöht →siehe hier. Bei mir sieht es o.k. aus. Der Abstand richtet sich ja am Zeitraum aus. --Liebe Grüße, LómelindeDiskussion12:22, 6. Okt. 2019 (CEST)
Diese Vorlage pappt einfach Parameter ohne Abstand hintereinander und ruft mit der Textwurst die Vorlage:Literatur auf, im Quelltext sieht das zum Beispiel so aus: Sammelwerk={{{journal|}}}{{{booktitle|}}}{{{series|}}}, ist aber nicht nur bei diesen Parametern so. Das Ergebnis sieht man dann hier bei Einzelnachweis1: "TU WienInstitut". Wenn ich die Vorlagensyntax richtig verstehe, wäre Sammelwerk={{{#if|{{{journal|}}}|{{{journal}}} |}}}{{{#if|{{{booktitle|}}}|{{{booktitle}}} |}}}{{{#if|{{{series|}}}|{{{series|}}} |}}} besser, oder werden da die Leerzeichen auch verschluckt? Kann man das vielleicht ein wenig überarbeiten? --Wurgl (Diskussion) 11:31, 10. Okt. 2019 (CEST)
Ich check gerade nicht was du meinst, eigentlich verstehe ich es so, dass diese drei Parameter Sammelwerk={{{journal|}}}{{{booktitle|}}}{{{series|}}} „nicht gleichzeitig“ gesetzt werden sollten, also eher ein switch oder ein logisches oder, da kann dann auch kein Leerzeichenproblem erzeugt werden, wenn man immer nur eines zulässt entweder es ist ein Journal oder ein Buchtitel oder eine Reihe aber nicht alles zugleich. Ich sehe dort auch keine gleichzeitige Verwendung dieser Parameter.
{{BibTeX
| author = Christian Hellmich und Institut für Mechanik der Werkstoffe und Strukturen und weitere
| title = Skriptum zur Übung aus Festigkeitslehre
| institution = Institut der Mechanik für Werkstoffe und Strukturen, TU Wien; Wien
| year = 2018
| number = 202.665
| month = Jänner
| edition = 2017/18 (autumn term)
| howpublished = TUWEL
| organization = institut for mechanics of solids and structures
| publisher = TU Wien
| school = TU Wien
| series = Festigkeitslehreskriptum für Bauingenieure
| url = https://tuwel.tuwien.ac.at/course/view.php?id=11461
}}
Doppelt scheint hier eher Verlag={{{publisher|}}}{{{institution|}}}{{{organization|}}}{{{school|}}} und das würde ich schlicht als falsches Ausfüllen einer Vorlage ansehen. Das jetzt aufwendig durch Syntax zu ermöglichen scheint mir aber am eigentlichen Ziel dort nur eine dieser Angaben zu erwarten, vorbeizugehen. Ich fasse das Dingen auch nicht an, da haut mir jemand auf die Finger, wenn ich das tue. --Liebe Grüße, LómelindeDiskussion12:03, 10. Okt. 2019 (CEST)
Zweifelhaftes Privatprodukt eines Einzelautors, über das ich mich bereits beschwert hatte, mit ganzen sechs ANR-Einbindungen.
Im ANR überflüssige und verwirrende Konkurrenz zu richtigen Zitationen.
Ich hatte bereits mit Spezial:Diff/170572090/170818003 als substitutionspflichtig anempfohlen, aber der Vorlagenersteller hat selbst auch keinen Bock sich um sein Meisterwerk zu kümmern.
Das BibTeX-Format ist ein Nischenprodukt von einer Handvoll Experten. Kein Grund, unseren Artikelautoren auch noch die Befassung mit diesem Exoten aufzuzwingen.
Mag man als Importformat zur einmaligen Übersetzung BibTeX→dewiki ein Mal so machen, aber hat danach im ANR nix am suchen.
Der ANR-Einbinder ist auch der Vorlagenersteller ist auch der einzige Verwender.
Aber Ló kann sich ja auf BETA mal in der Konstruktion substituierbarer Vorlagen üben und den Horizont erweitern; neue Herausforderungen und so.
Könnte dann ggf. ein Komma einfügen, wenn mehrere dieser Institutionen gleichzeitig definiert sind; käme dann halt ein erschröcklicher Bandwurm bei raus – derzeit sind es Leerzeichen auf BETA. Nicht unser Problem, kann der Autor dann immer noch in der Einbindung im Artikel zusammenstreichen.
Lass mal. Ich hab im Artikel die Parameter ausgedünnt. Sind ja ohnehin redundant. Soll er sich doch aufregen und Vandalismus melden … --Wurgl (Diskussion) 14:56, 10. Okt. 2019 (CEST)
z. B. bei Uwe Seeler: {Rsssf.com|seeler|Linktext=Uwe Seelers Ligaspiele und -tore}} ergibt „Uwe Seelers Ligaspiele und -tore in der Datenbank von RSSSF (englisch)[[Kategorie:Wikipedia:Wikidata P verschieden (}}}| <sm)]][[Kategorie:Wikipedia:Wikidata P verschieden (}}}| <sm)]][[Kategorie:Wikipedia:Wikidata P verschieden (}}}| <sm)]][[Kategorie:Wikipedia:Wikidata P verschieden (1}}}| <sma)]]“ --Mmgst23 (Diskussion) 19:15, 10. Okt. 2019 (CEST)
Falls da noch Probleme auftauchen, also Namen nicht eindeutig weil mehrfach, muss eventuell noch ein weiterer Parameter ergänzt werden. --Liebe Grüße, LómelindeDiskussion08:26, 10. Okt. 2019 (CEST)
Es müssten dann nur so nebenbei die nicht mehr wirksamen Parameter 1 und 2 aus den Artikeln entfernt werden. Also, wo dir das bei der Bearbeitung begegnet, bitte rausnehmen. →49 Artikel --Liebe Grüße, LómelindeDiskussion09:06, 10. Okt. 2019 (CEST)
Du greifst in die anderthalb Jahrzehnte austarierten Pixel-Abmessungen ein. Bei einem realen Einsatz hätte das letztlich Auswirkungen für Hunderttausende von Artikeln mit Millionen von Einbindungen, die zurzeit mangels Informationen nicht abgeschätzt werden können.
Dein System der diversen Pixel-Hin-Her ist ohne erläuternde Grafiken völlig unverständlich. Du müsstest genaue Skizzen bereitstellen, die erläutern, was welcher neue Parameter wo an Extra-Pixeln hinzufügt, in welchen Fällen wann oder auch nicht.
Die Einbindung in Artikel konzentriert sich auf das Verlinkungsziel und den richtigen Code, der automatisch zur richtigen Darstellung führt. Kein Autor, der seine Fußball-Ergebnisse schnell und effizient dekorieren möchte, ist daran interessiert, für jedes Land an den Einbindungsparametern zu justieren.
Du unterschlägst freundlichst und ohne jeden Hinweis, dass deine Version und Grundidee auf meinem auf BETA bereitgestellten Konzept für Modul und Definitionsdaten beruhen.
Dein Lua-Code ist in seiner derzeitigen Form weder robust noch wartbar noch effizient.
@PerfektesChaos «Du unterschlägst freundlichst und ohne jeden Hinweis, dass deine Version und Grundidee auf meinem auf BETA bereitgestellten Konzept für Modul und Definitionsdaten beruhen.» Hmmm, was ist mit den angeblich abgekupferten BETAs los? Meine Browser haben Sicherheitsbedenken, das BETA-Schlachtfeld aufzurufen. Na ja,
wer die Sourcen vergleicht wird feststellen, das es ein total anderer Ansatz ist. Dass es Parallelen zu ISO-Codes, Bilddateien und Links gibt, ist kein Chaos, sondern an "hoherer Stelle" eingerichtet. Daran muss swogar ich mich halten und muss das nicht mal abkupfern. Zudem enthalten meine Listen Angaben, die Ihnen möglicherweise unbequem oder fremd sind.
Mein Ansatz bezieht sich primär um die korrekte Darstellung bzgl. aspect ratio und zwar bei jeglicher Größenänderung. Dass man es ggf. bei den bisherigen Vorlagen vom Typ {{ABC}} einsetzen kann(nicht muss!!!), ist ein Effekt, den ich beim Modul berücksichtigt habe. Ob er genutzt wird, werde ich weder entscheiden können noch dürfen oder wollen. Es bleibt also für Ihren austarierten BETA-Ansatz genügend Raum, ihn zu verwirklichen und den «Millionen von Einbindungen» gerecht zu werden, was diese sicherlich dankbar honorieren. Kritische Betrachtungen dazu erspare ich mir.
Ansonsten verweise ich auf die bereits im BNR realisierten und funktionierenden Muster bei Ländervorlagen mit Flagge(wohin ich das Thema auf ihre freundliche Empfehlung hin verschoben habe) bzw. Werkstatt:Flagicons
Derzeit ist die multilinguale Variante in der abschließenden Tastphase (zusammen mir den en:Freunden und ru:друзья) und die Aufteilung in verschiedene themenbezogenen, getrennten Listen ist nahezu im Kasten.
Es gibt die Vorlage Benutzer:Meinname/Spielwiese/Vorlage:FTest
Diese ruft mit {{#invoke:FtestM}} das Modul auf.
Es existiert ein „Modul“ Benutzer:Meinname/Spielwiese/Modul:FTestM
Bei der Anlage gemäß Beschreibung wird jedoch der normale Editor aufgerufen und nicht die LUA-Variante.[3]
Was mache ich falsch? Oder ist einfach die Anleitung falsch? Angeblich sollen ja die Vorlagen/Module in der Spielwiesen-Hierarchie aufgerufen werden (also Veränderung des Suchpfads)
Wird die Vorlage mit vollem Pfad ({{Benutzer:Meinname/Spielwiese/Vorlage:FTest}}) statt mit {{FTest}} aufgerufen, klappt es einwandfrei. Das kann aber nicht der Sinn der Spielwiese sein.
Wird das Modul als Modul:Benutzer:Meinname/Spielwiese/FTestM angelegt und mit vollem Pfad statt mit {{#invoke:FTestM}} aufgerufen, klappt es auch. Doch das geht auch ohne ‚Spielwiese‘.
Wie kann ich in meinem BNR eine Artikel-Vorlage-Modul-Funktion anlegen, die wie beschrieben funktioniert?
Ich bitte um konkrete Hinweise ohne WP-Entwicklungspolitik/-Filosofie/-Daseinskritik. Die Variante via β-Wiki fällt aus, da dort viele im Modul aufzurufende Artikel/Grafiken nicht vorhanden sind und somit ein sinnvolles Arbeiten nicht möglich ist.
↑Meinname ist natürlich durch einen echten Benutzernamen ersetzt
↑statt FTest wurden auch andere, auch unterschiedliche Namen benutzt. Lediglich bei ‚Test‘ kamen Fehlermeldungen
↑De facto entsteht nur ein normaler Artikel ohne LUA-Funktionen
Ich kann dein Problem nicht nachstellen. Bei mir funktioniert alles wie erwartet. Dass das Modul anders als im Modul-Namensraum angezeigt wird, liegt am davon verschiedenen Content Model der Benutzerunterseite. -- hgzh10:45, 7. Okt. 2019 (CEST)
Frage einen Admin beispielsweise Hgzh ob er dir das umschreibt das kann nur durch einen Admin geschehen, Normalos haben darauf keinen Zugriff. Du kannst aber auch auf der Seite Administratorenanfragen darum bitten. Und verwende bitte keine cite-Tags auf Funktionsseiten Hilfe:Tags#Formatierung Zitat: „Diese Tags sollen in Artikeln und Projektseiten nicht verwendet werden“. Es wäre schön, wenn du das berücksichtigen würdest. Zudem setzen wir Zitate nicht kursiv sondern in „Anführungszeichen“ siehe WP:Zitate#Layout für Kursivsetzung verwenden wir diese Wikisyntax''. Siehe auch Wikipedia:Technik/MediaWiki/Content Model --Liebe Grüße, LómelindeDiskussion08:32, 8. Okt. 2019 (CEST)
Auf welcher Funktionsseite habe ich <cite> verwendet? Wie cite dargestellt wird, liegt außerhalb meines Wirkungsbereichs.
„Normalos haben darauf keinen Zugriff.“ Normalos lesen aber die Anweisungen und vermissen darauf jeglichen Hinweis auf ein Content Model und dort vermisse ich auch jegliche Erwähnung von Vorlagen, Modulen, LUA etc. Wonach darf man sich nun richten? --Klaus-Peter09:00, 8. Okt. 2019 (CEST)
Antwort hier in diesem Abschnitt und das hier ist eine „Funktionsseite“, deshalb erwähnte ich das ja. Für den Inhalt der Hilfeseite bin ich nicht verantwortlich, ich kenne mich auch damit nicht aus, ich kann keine Module erstellen und habe das noch niemals verwendet, wenn es dort also Unklarheiten gibt benutze die →dortige Diskussionsseite für Nachfragen, gleiches gilt für das →Content Model. Ich kann nur das anbieten, was ich darüber weiß und nicht mehr. --Liebe Grüße, LómelindeDiskussion10:57, 8. Okt. 2019 (CEST)
Du bist ja lustig, die Diskussionsseiten existieren noch nicht da müsstest du erst mal einen Beitrag schreiben. Das streikt nicht dein Browser. Ich habe mir den Namen Funktionsseite ja auch nicht ausgedacht, sie werden hier halt so bezeichnet, dazu zählen insbesondere alle Seiten, die der Diskussion im Projekt dienen oder die Hilfeseiten. Also mein Browser hat kein Problem dabei eine nicht existierende Seite aufzurufen, sie ist nur halt ohne Inhalt. Das ist genauso als wenn du in deinem Benutzerbereich eine neue Seite erstellst. Scheinbar möchtest du mich hier aufs Glatteis führen. --Liebe Grüße, LómelindeDiskussion12:09, 8. Okt. 2019 (CEST)
@hgzh ref 11:13, 8. Okt. 2019 (MESZ)
Habe ganz meinen Dank vergessen, da ich wegen dem Folgebeitrag es übersah. OK, der Weg ist beschrieben, aber leider um Test größerer Projekte kaum praktikabel. Da habe ich mit dem Umweg über komplette Pfadnamen bequemeren Erfolg. Ich weiß nicht mehr wo, aber da habe ichn so etwas wie Modul:Benutzer:Icke/Spielwiese/Meinmodul abgeschrieben. Das klappt (allerdings mit vollem Pfadnamen) einwandfrei und selbst Unterseiten wie Duku werden dann korrekt angelegt.--Klaus-Peter14:20, 9. Okt. 2019 (CEST)
Hallo, mal wieder eine Frage zu einer altgedienten Vorlage. Ich würde diese gerne so nutzen können, dass ich den 2. Platz farblich ausblenden möchte, da ich gerde ein paar Artikel habe wo nicht grundsätzlich alle Zweitplatzierten weiterkommen. Verhält sich also reziprok zu Vorlage:Tabelle RoundRobin-3Spieler. Geht das? Dank im Voraus. Gruß RafaelNachricht08:28, 15. Okt. 2019 (CEST)
Hallo, Rafael, ich habe deinen Wunsch umgesetzt und mich dabei an der Änderung der anderen Vorlage orientiert. Die gleiche Angabe „|zwei“ als erster Parameter führt aber in diesem Fall dazu, dass der Platz nicht eingefärbt wird. Kannst du dich um die Dokumentation der Erweiterung selbst kümmern? --Wiegels„…“23:25, 23. Okt. 2019 (CEST)
Oh, das ging ja jetzt zügig und dazu noch so unaufwendig. Hatte mit mehr Progrmmieraufwand gerechnet. Vielen Dank. Doku angelegt. Gruß RafaelNachricht05:50, 24. Okt. 2019 (CEST)
Dafür müsste man den Parameter WappenLink= der Vorlage opfern. Der wird aber anscheinend nicht verwendet. -- hgzh10:50, 7. Okt. 2019 (CEST)
Klingt wie chinesisch für mich was Du schreibst. In jedem Fall ist es falsch, dass dort "Wappen" in der Infobox in den Artikeln steht. Enweder nix oder eben Wappen bzw. Logo. Gruß --Chtrede (Diskussion) 11:26, 7. Okt. 2019 (CEST)
Hallo Gemeinde, kann es sein, dass sich in den letzten 4 bis 6 Tagen irgendetwas in der Zitat-Vorlage verändert hat? Ich sehe es nur, weil meine BS anders (unschöner) aussieht als letzte Woche, und ich die gewünschte Zeilentrennung und den gewünschten Zeilenabstand (also "gewünscht" im Sinne von "gewohnt, wie bisher") nicht mehr hinbekomme. Viele Grüße --Maddl79orschwerbleede!23:22, 7. Okt. 2019 (CEST) PS: Meine "Tests", um das zu reparieren, habe ich nicht gespeichert, nur per Vorschau anzeigen lassen.
Es gab gestern eine Reihe Änderungen. Ist’s nun wieder besser? Sieht für mich jedenfalls in Ordnung aus. Gruß, -- hgzh11:22, 8. Okt. 2019 (CEST)
Ja, ging auf meine Kappe, und genau diese Anfrage gab mir den entscheidenden Hinweis, welche Situation das Problem auslöste.
Allerdings ist mit dem neuen, seit wenigen Jahren verstärkt eingesetzten Parser und/oder HTML-Postprocessor irgendwas irgendwie anders, was die Handhabung von Zeilenumbrüchen angeht. Das fällt auch auf, wenn in Tabellenzellen ein <br /> gefolgt von einem Zeilenumbruch vorkommt; dies löst jetzt einen paragraph<p> aus, was früher nicht der Fall war. Genau dies lag hier auch vor.
Hallo, die durch die VL bspw. in jenem Art. Anm. 1 angegebene PDF-Größe von 0,8 MiB wäre bitte in 7,6 MiB oder MB zu ändern.
Bitte gleich nach WP:LIT mit ändern: Český statistický úřad ist i.w.S. Autor resp. Herausgeber / Doppelpunkt / Die Einwohnerzahlen der tschechischen Gemeinden vom 1. Januar 2019 wäre als Titel zu kursivieren bzw. in Klammern nach Počet obyvatel v obcích. Population of Municipalities zu setzen.
NB: Die Datei hat oft Seiten-Ladefehler, Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG. Gibt es eine alternative Adresse?
Fixed. Das muss so sein, bei benannten Parametern wird "white space" vor und nach dem Text entfernt, eine Liste muss aber mit einer neuen Zeile anfangen und so ist dieser Zeilenumbruch mit drinnen. --Wurgl (Diskussion) 21:04, 12. Okt. 2019 (CEST)
Ich hoffe die Frage ist nicht allzu dumm, aber in unserer Uni-Arbeitsgruppe kam eine Idee auf, bei der wir Attribute von Milliardären erstellen, abgleichen und dann Abgleichungen vornehmen wollten...
Jetzt gibt es derzeit aber an die 2.000 Milliardäre weltweit... auf Wikipedia sind zwar sehr viele, aber nie alle in einer Liste, wenn dann aufteilt auf die Länder (10 reichsten oder so)... gibt es vielleicht eine Möglichkeit eine Liste von allen gelisteten Milliardären (reichen bestimmt auch 1.500) in ein Excel zu ziehen ohne jetzt die Landeslisten durchzugehen und 1.500 Namen oder so abzutippen...
Das ist eigentlich recht einfach, Du musst einfach die Landeslisten durchgehen, die Tabelle auswählen und kopieren. In einen Texteditor einfügen dann nochmal kopieren (um blöde Formatierungen zu entfernen) und in Libre Office Calc einfügen und als Zellentrenner den Tabulator wählen. Und schon haben wir die Liste für ein Land ohne viel abzutippen. Habitator terrae15:15, 16. Okt. 2019 (CEST)
Du musst dafür nur die Vorlage einbinden und dich, soweit ich mich erinnere, dafür auch in diese Opt-In-Liste eintragen. Der Bot legt[e] die entsprechende Unterseite dann an, siehe Spezial:Logbuch/HRoestBot.
Inzwischen hat der FNBot die Aktualisierung der Einträge übernommen, ich weiß allerdings nicht, ob er auch die Unterseiten erstellt, wie der vorherige es tat, notfalls müsstest du eine Unterseite Benutzer:Georg Hügler/Sichtertabelle selbst anlegen oder mal FNDE fragen. --Liebe Grüße, LómelindeDiskussion12:45, 23. Okt. 2019 (CEST)
Der Prozess ist in der Tat schwer zu verstehen – das sollten wir mal etwas vereinfachen in Zukunft. Wie Lomelinde richtig gesagt hat, momentan wird das von FNBot erledigt. Die Unterseite muesstest du bitte selbst anlegen :-) Viele Gruesse --FNDE12:54, 23. Okt. 2019 (CEST)
Nun die korrekte Vorlage einbauen oder dir selbst eine individuell anlegen, so wie ich es getan habe. Warte ich schaue es mir kurz an. --Liebe Grüße, LómelindeDiskussion14:05, 23. Okt. 2019 (CEST)
Ich habe noch etwas übersehen da gehört noch eine weitere Seite dazu. →Benutzer:Georg Hügler/Sichterbeiträge. Die muss auch vorhanden sein, danach dann so einbinden.
Wie gesagt habe ich da eine eigene Vorlage und muss erst nachschauen wie es bei anderen eingebaut ist. Mit meinen Daten würde es aber klappen. Ach du hast ja einen doppelnamen dann setze mal bitte ein Plus dazwischen Georg+Hügler --Liebe Grüße, LómelindeDiskussion14:48, 23. Okt. 2019 (CEST)
Parameter DOI in Vorlage:Literatur – seitengenaue Verlinkung gewünscht
Hallo, könnte bitte eine seitengenaue Verlinkung mit Parameter DOI in Vorlage:Literatur eingerichtet werden? Wenn ich richtig sehe, führen derzeit Seitenzusätze zum DOI zur Fehlermeldung, während solche Seitenzusätze in der Vorlage:DOI genau auf die gewünschte Seite führen.
Hier (gekürzte) Anwendungsfälle in einem Artikel wären:
in VL Lit. über Parameter Online (uni-heidelberg.de seitengenau) und DOI ohne Seitenzusatz (→ Titelaufnahme Band 27)
F. M. H.: Die Lehrer des Rubens. In: Jahrbuch … Band27, 1907, ISSN0075-2312, S.161–236 (ub.uni-heidelberg.de – Dissertation – DOI=10.11588/diglit.5947).
in VL Lit. über Param. DOI mit Seitenzusatz (→ Fehlermeldung)
F. M. H.: Die Lehrer des Rubens. In: Jahrbuch … Band27, 1907, ISSN0075-2312, S.161–236 (ub.uni-heidelberg.de – Dissertation – DOI=10.11588/diglit.5947#0169).
Die Vorlage {{DOI}} reagiert identisch, es liegt also nicht an der Vorlage an sich. Der einzige, der weiß wie die Vorlage Literatur im Detail und in Verbindung mit den zugehörigen Modulen funktioniert, ist PerfektesChaos. Ich denke er bat dich erst jüngst irgendwo weniger Stress bei den Vorlagen zu verursachen. Ich bin nicht einmal sicher, ob ich mir das wirklich wünsche. Die Vorlage hat ja explizit einen Parameter Online, der für den zielgenauen Link verwendet werden kann. Ob das mit den angehängten Seiten in einem DOI aber immer und überall gültig wäre, weiß ich nicht. Ich fasse da nichts an. --Liebe Grüße, LómelindeDiskussion13:24, 24. Okt. 2019 (CEST)
Fragmente in DOI sind grundsätzlich Unsinn, auch wenn sie im Browser formal-technisch konstruiert werden können.
Was ist ein DOI?
Ein DOI ist vorgesehen, um über Jahrzehnte und die Lebensdauer einer Domain hinaus und erst recht länger als die Existenz einer bestimmten Ressource hinaus die Erreichbarkeit zu ermöglichen.
Dabei ist völlig egal, wie in späteren Zeiten mal die Ressource organisiert ist, ob als PDF oder HTML oder TIFF oder aber eine Options-Übersichtsseite (wie PMID 1), auf der zwischen kostenpflichtiger Vollversion oder kostenlosem Abstract gewählt werden kann, und ob als PDF oder HTML oder eBook oder was auch immer, und vielleicht in verschiedenen Sprachen.
In der DOI bestückenden Datenbankstruktur wird zu jedem DOI eine Liste mit einer oder mehreren URL hinterlegt, die bei derselben Domain oder auf verschiedenen liegen können, und identische oder fundamental unterschiedliche Ressourcenformate zum Ziel haben können. Auf die erste URL der Liste wird im normalen Browser weitergeleitet.
Welche URL das sind, kann jederzeit ohne Ankündigung geändert werden, und auch die Art der Ressource auf dem Zielserver kann sich ständig ändern.
Wenn eine Original-URL nicht mehr gültig ist, weil beispielsweise ein Verlag insolvent wurde, dann kann vielleicht eine öffentliche Bibliothek oder eine Stiftung in den folgenden Jahrzehnten einen Ersatz anbieten. In welchem Format und mit welchen Fragmenten das passiert ist Sache des neuen Anbieters.
Wenn du auf ein bestimmtes Fragment verweisen willst, dann musst du auch die momentane URL verwenden, zu dessen Dokument das Fragment gehört. Wichtig dabei wäre, dass du im Klartext die Seitenzahl benennt, damit auch zukünftige Leser die Stelle auffinden können, auch wenn sich das Format geändert hat.
DOI heißt Document Identifier und identifiziert komplette Dokumente, keine einzelnen Seiten.
Vielen Dank für die Antwort(en [na ja]). Es war u. a. die seiten-suffigierte Angabe bei uni-heidelberg.de – DOI Seite: https://doi.org/10.11588/diglit.5947#0169 –, die mich fragen ließ; eine mögliche formal-technische Konstruktion, wie Du, PerfektesChaos, anschaulich erklärt hast. Danke, und für mich erledigt. Gruß, --Wi-luc-ky (Diskussion) 14:18, 24. Okt. 2019 (CEST)
Wie bekomme ich es hin bzw. was muss ich als y2- und y3-Wert eintragen, damit bei dem Jahr 1920 kein Wert erscheint, die Linien für Stadt und Land erst bei 1930 beginnen? Hintergrund: Die Werte für das Jahr 1920 bzw. auch 2019 sind nicht bekannt.
Ja, vielen Dank, genau so. Betraf übrigens den Ort Santo Antônio de Leverger, bei den brasilianischen Orten kann ich dann bei der Bevölkerungsentwicklung das Diagramm unter die Zahlentabelle setzen, man sollte dann die Landflucht auch optisch erkennen. --Emeritus (Diskussion) 12:44, 29. Okt. 2019 (CET)
Die Vorlage erzeugt am Ende des Textes automatisch immer einen Punkt, der dort aber nur hingehört, wenn ein Abrufdatum mit angegeben wird. Ich finde den Grund dafür nicht, vermute aber mal, dass es mit der Codezeile für's Abrufdatum zusammenhängt. Kann jemand von euch weiterhelfen und das beheben? -- Danke und Gruß Sir GawainDisk.17:05, 28. Okt. 2019 (CET)
Eigentlich hat die Vorlage mal super funktioniert. Der Kommentar kam zum Schluss, die Sprache stand in der Klammer und mit Abrufdatum (als EN) gab es einen Punkt. Inzwischen wird mir bei der Vorlage übel. --Bungert55 (Diskussion) 15:58, 29. Okt. 2019 (CET)
Super funktioniert? In deiner Version konnte man ohne den Parameter Zugriff gar keinen Kommentar anfügen, der kam nur mit Abrufdatum, sollte das so? Ich hatte daher vermutet, dass der Kommentar immer sichtbar sein sollte. Bei dir sah das dann im Weblinkbereich so aus, dass man zwar einen Kommentar schreiben, diesen aber ohne Abrufdatum niemals sehen kann.
{{#if:{{{zugriff|}}}{{{Zugriff|}}}|, abgerufen am <span style="white-space:nowrap;"><!--
-->{{FormatDate|{{{zugriff|}}}{{{Zugriff|}}}}}</span><!--
-->{{#if: {{{Kommentar|}}}| ({{{Kommentar|}}}).|.}} }}
Würde man diesen einfach nur sichtbar hinten anhängen, dann käme da ein (niederländisch) (Test) ans Ende, wenn kein Abrufdatum angegeben wurde. Das sieht auch nicht besser aus als meine Version, eher schlechter, weil man Klammern so nicht hintereinander schachteln sollte.
Wie sinnvoll sollte so etwas denn sein? Einen Parameter anbieten den man dann füllt aber nicht sichtbar ausgibt. Das versteht kein Mensch. --Liebe Grüße, LómelindeDiskussion17:02, 29. Okt. 2019 (CET)
Vorlagen für Spiele auf WD umstellen: Datenbank-IDs BGG und Luding
Moin,
in Artikeln zu Spielen sind als Standard Vorlagen zu den Datenbanden BoardGameGeek und Luding (Datenbank) eingebaut. Dabei handelt es sich um einfache ID-Einbindungen ähnlich der Vorlage Vorlage:IMDb. Wie diese halte ich es für sinnvoll, die Vorlagen so umzuschreiben, dass sie die Einbindung von ID-properties aus Wikidata ermöglicht.
Moin Achim, im Prinzip ist das keine große Sache. Wenn man schon mal dabei ist, wäre es meiner Meinung nach überlegenswert, die jeweils gleichartigen Vorlagen in eine gemeinsame Vorlage:BoardGameGeek bzw. Vorlage:Luding zusammenzufassen, um nicht drei Vorlagen für die gleiche Datenbank warten zu müssen. Als Bonus gäbe es dann noch TemplateData für den VE und evtl. Wartungskategorien für abweichende Wikidata-Werte dazu. Was sagst du? Gruß, -- hgzh12:43, 8. Okt. 2019 (CEST)
Hi, eine gemeinsame Vorlage hat sicher ein paar Vorteile. Wichtig wäre, dass es keine Übernahme aus WD gibt, wenn der Wert eingetragen ist - zugleich fände ich eine Wartungsliste für Abweichungen und fehlende WD-IDs sehr gut (gerade Luding ist bei WD noch nicht wirklich weit). TemplateData muss ich mir anschauen, wird aber wohl nicht verkehrt sein. -- Achim Raschka (Diskussion) 14:42, 8. Okt. 2019 (CEST)
Die Hinweise von hgzh begrüße ich aufs Schärfste, zumal ich noch nie was von einem „BGG“ gehört hatte; wer ein BoardGameGeek sein könnte, ist mir allerdings sofort verständlich und in gleichem Kontext kann ich mir seit Das Glasperlenspiel auch vorstellen, wer oder was Luding sein mag.
Vergleiche differierender Werte zu Wikidata und Analyse der Ursachen nehmen wir sehr gern vor.
Ich habe jetzt die Vorlage:BoardGameGeek als Universalvorlage angelegt. Alles Wichtige steht eigentlich auf der Dokumentationsseite. Bitte mal schauen, ob das so in Ordnung geht, dann würde ich als ersten Schritt von den Einzelvorlagen auf die neue durchschalten. -- hgzh14:21, 9. Okt. 2019 (CEST)
Wow, das ging schnell und sieht gut aus - gerade mal bei Ted Raicer mit und ohne WD-Ergänzung getestet und für funktionierend befunden. De fakto macht es ganau das, was ich haben möchte - DANKE -- Achim Raschka (Diskussion) 16:54, 9. Okt. 2019 (CEST)
Schön, dass es gefällt. Ich habe die Vorlage samt Wartungskats jetzt scharfgeschaltet. Die alten Vorlagen binden zunächst die neue ein. Die Wikidata-Einbindung funktioniert aber nur bei Verwendung der Zentralvorlage, damit die alten langsam verschwinden. Oder jemand lässt einen Bot laufen. -- hgzh12:24, 10. Okt. 2019 (CEST)
Danke - der Bestand bei den Spielen ist überschaubar und ich würde das peu á peu händisch machen, damit ich parallel auch die IDs in Wikidata nachtragen kann. Gruß, -- Achim Raschka (Diskussion) 22:22, 10. Okt. 2019 (CEST)
Da ist am Ende so eine Konstruktion zu finden:
{{#if:{{NAMESPACE}}{{{NoCat|}}}|<!-- nix -->|{{Infobox Katzenrasse/Kategorien
}}
Also wenn im ANR und wenn NoCat leer ist, dann ruf die Vorlage:Infobox Katzenrasse/Kategorien auf. Genau! Das ist ein Rotlink, seit 2010 steht das so drinnen. Birger Fricke scheint ja immer noch aktiv zu sein, vielleicht gibts ja ein wenig Gemurmel dazu.
So wie es jetzt ist, ist es eine Einladung zu Fehlern, denn einmal den Parameter NoCat vergessen und *zack* steht roter Text am Anfang des Artikels, wie im (inzwischen gefixten) Burmilla (Permalink). --Wurgl (Diskussion) 09:50, 26. Okt. 2019 (CEST)
Hab's jetzt einfach rausgeworfen. Hatte nie einen Effekt und wird es wahrscheinlich auch nicht mehr haben. Gruß, -- hgzh19:18, 29. Okt. 2019 (CET)
Die zugehörigen Zeilen von Gedicht und Übersetzung sind horizontal adjustiert (z.B. verursachen chinesische Zeichen einen größeren Zeilenabstand).
Bei schmalen Bildschirmen wie beispielsweise bei Smartphones sollte Gedicht und Übersetzung nicht nebeneinander, sondern untereinander stehen.
Nett wäre es, wenn auch drei Blöcke nebeneinander (z.B. Gedicht & Transliteration & Übersetzung) möglich wären.
Zusätzlich wäre es sehr nützlich, wenn es einen Befehl gäbe, etwas vertikalen Zwischenraum einzufügen (z.B. bloß eine halbe Zeile) – vielleicht gibt's den auch schon, und ich habe ihn bloß nicht gefunden...
--Lemzwerg (Diskussion) 19:41, 2. Nov. 2019 (CET)
Kompliziert ist das eigentlich nicht. Du könntest es für dich als Kopiervorlage irgendwo speichern und einfach die jeweiligen Texte einfügen. Tabellensyntax benötigt man auch nicht dafür. --Liebe Grüße, LómelindeDiskussion07:27, 3. Nov. 2019 (CET)
Vielen Dank. Ich habe wirklich lange herumgesucht und nichts gefunden, allerdings nur im Vorlagen-Bereich. Auf die Idee, »Hilfe:Gedichte« aufzurufen bin ich leider nicht gekommen... --Lemzwerg (Diskussion) 08:03, 3. Nov. 2019 (CET)
Zufällig hab ich bei en:Sylvain_Luc#External_links hinter dem Weblink dieses Stiftsymbol gesehen, bei Mouse-Over kommt "Edit this at Wikidata". Ich finde die Idee klasse und das könnte man doch bei einigen Einträgen, die sich Daten aus Wikidata holen, auch hier machen. --Wurgl (Diskussion) 06:42, 8. Okt. 2019 (CEST)
Es wäre auch schön, wenn es endlich mal eine Regel gäbe, ob Parameternamen komplett klein oder komplett groß oder klein mit erstem Buchstaben groß geschrieben werden. Teilweise ist das sogar innerhalb einer Vorlage nicht einheitlich. 94.218.178.12011:32, 6. Okt. 2019 (CEST)
Das wird nicht laufen.
Wir haben über 70.000 Vorlagen, davon vielleicht 50.000 mit Parametern.
„Jeder Depp darf neue Vorlagen erstellen, sie benennen nach Lust und Laune, und die Parameter sonstwie benamsen.“
Es gibt für Vorlagen keinerlei Regeln oder Richtlinien; jeder Wirrkopf darf sich erstmal alles erlauben.
Wir können noch nicht mal eine verständliche Namensgebung der gesamten Vorlage durchsetzen; an einzelne Parameter ist schon gleich gar nicht zu denken.
Vereinheitlichungsprozesse sind extrem aufwändig, bis Programmierung und Bestand umgestellt wurden.
Es gibt den langjährigen Trend, die Namen in normal vertrauter Schreibung anzugeben: Autor
Von-Hand-Tipper und die cite-internetquelle-Fraktion wollen alles in Kleinschreibung, damit sie die Umschalttaste nicht benutzen müssen: autor
Manche schwören aus alten Zeiten auf Nur-Großbuchstaben, damit sich das besser abheben solle: AUTOR
Wobei das in Infoboxen und Block-Anordnung aber nicht das Problem wäre, weil jeder Parametername vorn auf der Zeile steht und dort die brüllenden Nur-Großbuchstaben nerven.
VisualEdior-Benutzer bekommen überhaupt keine Parameternamen mehr zu sehen, weil sie im Formular nur die Label angezeigt bekommen.
Programmierer sehen die drei geschweiften Klammern davor und dahinter und hätten ganz andere Sorgen.
Wichtiger wäre es, von vielen unbenannten Parametern wegzukommen und unterschiedliche Bedeutungen explizit zu benennen, damit das nachvollziehbar und weniger fehleranfällig und zukunftsfähig wird.
Ansonsten liegt es an der Intelligenz der Vorlagenersteller und thematischer Bearbeiter, innerhalb derselben Vorlage eine gewisse Logik hinzubekommen. Können wir nix dran machen.
Da fällt mit ein … ich könnte mein Spielzeug um eine Seite mit seltenen Parametern aka. Vertippern erweitern, muss halt so Fälle mit dynamischen Parameternamen wie Vorlage:Sitzverteilung (und 3 weitere) rausnehmen. Die Query rödelt halt etwas länglich. --Wurgl (Diskussion) 16:36, 6. Okt. 2019 (CEST)
Auf die Aussage "Es wäre auch schön, wenn es endlich mal eine Regel gäbe, [...]" zu antworten "Es gibt für Vorlagen keinerlei Regeln oder Richtlinien" mutet etwas komisch an. Ich weiß, dass es diesbezüglich keine Regeln gibt, deshalb habe ich zum Ausdruck gebracht, dass man das mal bedenken könnte. Wenn sich das Vorlagenprojekt einig ist, dass beispielsweise nur noch kleingeschriebene Parameter erlaubt sein sollen, dann könnte man das schriftlich festhalten und bei neuen Vorlagen einfordern. Den Bestand kann man so lassen oder nach und nach umstellen, wie auch immer. 94.218.178.12016:54, 6. Okt. 2019 (CEST)
Komplette Kleinschreibung ist schlecht, weil dadurch das blinde, "gehirn-benutzungs-freie" Abkopieren aus En-WP gefördert wird. diese Vorlagensorte breitet sich wie ein Geschwür aus. Ergo besser erster Buchstabe groß und möglichst deutsche Worte, denn der Vorlagen-NR ist nicht der Modul-NR. Vorlagen müssen auch vom User mit En-Babel Null verstanden werden, Module nicht. ÅñŧóñŜûŝî(Ð)17:01, 6. Okt. 2019 (CEST)
Diese Werkstatt hat keinerlei Befugnis, irgendwelche Regeln und Richtlinien verbindlich vorzugeben. Wir können nur möglichst vorbildlich und koordiniert unsern Job machen. Wenn dann irgendwer partout die Welt genau so haben will wie sie 2005 mal war oder in der enWP ist, dann gibt es keinen Support von unserer Seite.
Ansonsten wird das als sinnvoll von den Anwendern eingeschätzt, was gerade in dieser Generation häufig zu sehen ist und woran sie gewöhnt sind. Heißt: Die ersten Gehversuche von 2005/2009 werden unseren Kindern und Enkeln irgendwann mal seltsam und absonderlich vorkommen.
@PerfektesChaos. Zahlen wie 70.000 und 50.000 ohne Quellenangabe oder Hinweis auf Überprüfungsmoglichkeit wirken unseriös. So etwas kann ‚jeder Depp‘ und ‚jeder Wirrkopf‘ behaupten und es hemmt eine sachliche Auseinandersetzung.
Unbenannte Parameter halte ich generell für problematisch, wenn es mehr als einen Parameter gibt. Schon bei {{Muster|A|1=B}} wird es knirschen. Auch jegliche Nummerierung {{Muster|1=A|2=B|3=C}} ist wenig intuitiv und fehleranfällig.
Die Vielzahl bestehender Vorlagen und Parameter zu ändern erscheint eher sinnlos. Bei neu zu erstellenden Vorlagen/Modulen könnte man Vorgaben definieren.
Eine Diskussionsseite ähnlich der Löschdiskussion wäre sinnvoll. Innerhalb der Frist sind Vorschläge zu verbessern und/oder abzuhaken.
Meine Bitte um Stellungnahme/Verbesserungsvorschläge zum Projekt 'Flagge' wurde bisher stramm ignoriert. Vermutlich geht der Zoff erst kurz nach Fertigstellung/Einführung los.
Gerade in der :de:WP kümmert man sich herzlich wenig darum, dass WP ein internationales Projekt ist. „Am deutschen Wesen mag die Welt genesen“ hatten wir schon und ist nicht immer der Renner gewesen. Kommt derzeit nur in alternativen Vogelschiss-Zirkeln gut an. Mich ärgert es bei Übersetzungen, dass nur wenige Vorlagen übernommen werden können. Schlimm, da WP nun mal immer noch en-dominierend ist. Bei der Anlage neuer Vorlagen sollte man bei den Parametern berücksichtigen, dass Andere es vielleicht übernehmen/übersetzen wollen.
Multilinguale Späßchen wie bei {{AUT|WIDTH=40|Ziel=Schmarrn|sortable=ja}} sind grenzwertig.
Im Prinzip sollte ein eindeutiger (führender) Buchstabe zwischen A und Z (= a-z) ausreichen, Groß-/Kleinschreibung ist irrelevant: {{AUT|w=40|z=Schmarrn|S=1}} oder {{AUT|Weite=40|Zuckerle=Schmarrn|sort=JAWOHL}} müssten auch funktionieren. Das so etwas zumindest via Modul realisierbar ist, kann ich beweisen.
Das eiNE Wilde bezeichnung möglich IST, impliziert nicht, dass es auch sinnvoll ist, denn es kann Bearbeiter und Übersetzer verwirren. Aber WIDTH=10 = Weite=10 = W=10 = w=10 ist doch eine brauchbare, internationale Eselsbrücke.
Wurgls Tool zählt Direkteinbindungen im ANR; außerdem gibt es noch Funktionseinbindungen, die nur innerhalb von Vorlagen auftreten und Vorlagen, die nie im ANR vorkämen wie Vorlage:Löschkandidaten/Erledigt – dazu noch die Überlegung, ob jede Unterseite im Vorlagen-Namensraum eine einbindungsfähige Funktionalität hatte, oder eher speziell wie Testseiten und Wartungslisten, und ob Doku-Unterseiten, die ihrer Natur nach zur Einbindung vorgesehen sind, zu den Vorlagen gezählt werden sollen.
Mit der Lua-Funktion mw.site.stats.pagesInNamespace(10) könntest du mit Leichtigkeit ermitteln, dass es zur Stunde 75698 Seiten im Vorlagen-Namensraum gibt, von denen ich jedoch gut 5.000 wegen anderer Verwendungen abgezogen habe. Mittels Cirrus kann jeder andere die gleichen Analysen anstellen; auch betreffend des Vorkommens der an ihren Dreifachklammern erkennbaren Parameterverwendungen. Im Übrigen ging es oben um die Größenordnung der Problematik.
Unterlasse also deine Vorwürfe, triviale und jederzeit einfach zu ermittelnde und nachzuprüfende Informationen wären ohne eine angeblich erforderliche „Quellenangabe“ erwähnt worden.
Insgesamt muss ich feststellen, dass dein Verhalten weder kollegial noch kooperativ noch kollaborativ ausgerichtet ist; der Subtext jedes deiner Beiträge ist ein Vorwurf an den bösen Rest der Welt. Es liegt womöglich nicht am Rest der Welt, wenn dich niemand liebhat und du dich außerdem regelmäßig der Beratung verschließt, du vielmehr vorher schon weißt, was dir bei einer Beratung gefälligst geantwortet zu werden habe.
Der übliche Tonfall! War wohl ein Eigentor. Zu oft wurde ich bei WP darauf aufmerksam gemacht, dass ALLE Angaben zu belegen sein. Gilt das nur für mich? Klar, jeder könnte jegliche Angabe ergoogeln. Warum dann überhaupt Quellenangaben? Hier ist das natürlich anders, denn JEDER hat ja die passenden WP-LUA-Funktionen parat und kennt Wurgl na ja, außeer ich natürlich. Schade, dass meine Allgemeinbildung nicht ausreicht. Sicher gibt es für Deppen und Wirrköpfe auch eine Funktion, die deren Status und Häufigkeit nachweist. Vielleicht so eine Art Trump-Tool?
Wer sich an einem Satz aufgeilt und sich bewusst dem überwiegenden Rest (>90%) des Beitrags verschließt, kann meinen Respekt nicht erwarten. Freuen Sie sich, dass Sie hier geliebt werden. In dieser Angelegenheit bevorzuge ich andere Kreise.--Klaus-Peter15:14, 8. Okt. 2019 (CEST)
Du kannst auch Quarry verwenden, oder den Dump saugen und dort zählen. Da kommen etwas andere Zahlen raus, es zählt eben ein jeder ein wenig anders. Mein Tool zählt Vorlagen, die im Artikel-Namensraum verwendet werden und jeder verwendete Name wird gezählt, somit auch Weiterleitungen. Außerdem werden im Artikel-Namensraum vereinzelt auch Untervorlagen verwendet. Aber es ist schnurzpiepegal ob es nun 50.000, 60.000 oder 70.000 Vorlagen sind, es sind einfach sehr, sehr viele. Im übrigen beende ich nun die Trollfütterung, das mach ich höchstwahrscheinlich mit diesen Sätzen. --Wurgl (Diskussion) 15:31, 8. Okt. 2019 (CEST)
Fehler in Vorlage:Infobox_Software
Was ist das Problem? -> Die aktuelle Version wird nicht korrekt aus WikiData gezogen.
Was ist falsch? -> 4.0 ist eine Beta und wird als aktuelle Version angezeigt.
Was wäre richtig? -> 3.10 ist die aktuelle Version.
Vermutlich muss ein Filter gebastelt werden der den type auf "stable version" prüft und dann nach dem letzten published date geht… abder da bin ich nicht der Experte.
Du hast im Wikidata-Objekt beim Eintrag 4.0-Beta-1 den Rang (die drei Kekse vor der Versionsnummer) auf "Preferred Rank". Klar holt sich das Modul genau diesen Eintrag. Wahrscheinlich reicht es, das zu setzen, aber um Editwar zu vermeiden den User AMDmi3 zuerst kontaktieren. --Wurgl (Diskussion) 17:37, 8. Okt. 2019 (CEST)
Servus – aber die Beta ist ja die "preferred" vorabversion – das gibt es in der InfoBox ja auch. Also sollte wohl die 4.0 Beta als Vorabversion und die 3.10 als aktuelle Version angezeigt werden. Mit einem entsprechenden Filter sollte das doch klappen? Zumindest war ich im WikiData Chat und das war die dort vorgeschlagene Lösung … 8^( Thomas Ganter (Diskussion) 18:15, 8. Okt. 2019 (CEST)
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.
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)
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?
Dass ‎ 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}}‎{{#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‎bereits eingetragen ist, nicht unbedingt geändert werden, denn‎‎hat die gleiche Wirkung wie‎. --Klaus-Peter13: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.
So hieß w= auch „Umschrift nach Wylie“ für Sprachen in tibetischer Schrift; heute WYLIE=.
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. ‎
Dies dient ausschließlich zur Ausstattung im Quelltext des Artikels.
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 ‎ weglässt und der Browser des Bearbeiters den Unicode-Bidi-Algorithmus auf den Quelltext anwendet.
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 ‎ etwas nicht stimmte. Das Dschumhūriyyat Misr al-ʿarabiyya hinter dem «جمهوريّة مصر العربيّة» wurde ohne ‎ 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 ‎»→agyptenÄgypten, arabisch جمهوريّة مصر العربيّة Dschumhūriyyat Misr al-ʿarabiyya
Tja, der von dir beschriebene Effekt zu جمهوريّة مصر العربيّة könnte genau daher rühren, dass die tatsächliche Anordnung der Zeichen im Quelltext eine andere ist als sie für dich optisch aussieht.
Konkret könnte es sein, dass das Pipe-Symbol in der Zeichenfolge nicht an der Stelle steht, wo es hingehört, sondern woanders; dir jedoch vom Unicode-Bidi-Algorithmus deines Browsers vorgegaukelt wird, es befände sich da und dort.
Ein Pipe-Symbol ist neutral; es ist weder links-nach-rechts noch rechts-nach-links. Ein Unicode-Bidi-Algorithmus kann es optisch an einer anderen Stelle präsentieren, oder ein zweites mag vorhanden sein.
Genau deshalb fügen wir in unserem Quelltext ‎ ein, damit diese Unklarheit gar nicht erst auftritt.
Wenn die Pipe-Symbole exakt dort stehen, wo sie hingehören, dann macht das Lua-Modul nebst Vorlage auch genau das, was erwartet wird. Wenn die Pipes woanders stehen, dann halt nicht.
Umso verheerender wäre deine diesen Thread einleitende Absicht gewesen, ganz einfach überall aus den Quelltexten die ‎ zu entfernen, weil die kann man ja in der Vorlage hinzufügen.
@PerfektesChaos. Beim Beispieltext oben fiel mir auf: جمهوريّة مصر العربيّة und der gleiche arabische Text via Vorlage:lang: agyptenÄgypten, arabisch جمهوريّة مصر العربيّة Dschumhūriyyat Misr al-ʿarabiyya. Der Unterschied ist schon auffällig. Ursache ist offensichtlich der Eintrag in Vorlage:Arab/styles: .Arab { font-size: 120%; } Bis zu 140% habe ich entdeckt. Abgesehen von der besseren Lesbarkeit, ist das schon ein flotter Eingriff, der das Schriftbild demoliert, da ja der Rest des Textes unangepasst daneben steht. In Tabellen eingebaut kann das schon das Layout deutlich beeinflussen. Wo gibt es ein WP-Gesetz, dass vorschreibt, asiatische Schriften übergroß darzustellen? --Klaus-Peter19:13, 12. Nov. 2019 (CET)
Sie sind so groß, dass jemand, der diese Schrift versteht und lesen kann, sie auch auf dem Bildschirm erkennen kann; insbesondere Menschen, die darin noch nicht sehr geübt sind. Sie sind dafür vorgesehen, dass sie in unsere Fließtexte eingefügt werden, und dort passt die Schrifthöhe noch in den Zeilenabstand.
Für Leute, für die das sowieso nur Gekrakel ist, für das sie sich nicht interessieren, ist das dann halt irgendwie was.
Im Beispiel einen Absatz drüber muss es sich beispielsweise für alle Leser ohne besondere Maßnahmen erkennen lassen, dass über dem Buchstaben am weitesten links zwei einzelne Punkte stehen, weil das für Bedeutung und Aussprache wichtig ist; über dem nächstfolgenden steht was und darunter zwei einzelne Punkte. Das ist mit der Auflösung für unsere lateinische Schrift nicht zu unterscheiden; es verschmiert zu einem einzigen Klecks.
Die erforderliche Auflösung für unsere lateinische Grotesk-Schrift und für arabische oder chinesische Schrift ist grundsätzlich verschieden. Wenn du dir mal Wiki-Seiten auf Arabisch, Japanisch oder dergleichen anguckst, dann wirst du feststellen, dass auf diesen Seiten mit ganz anderen Schriftgrößen und Zeilenhöhen gearbeitet wird. Die Mischung lateinischer und asiatischer Schriften im selben Text kann grundsätzlich nicht gut funktionieren. Wir machen das aber dort, wo das für unseren Artikel erforderlich ist und den Lesern etwas bringt, wenn wir Namen einer lemmatisierten Person oder andere Textfragmente angeben.
A propos erforderlich: Unsere FlagIcons sind nur eine kleine optische Orientierung, die denjenigen, die bestimmte Flaggen kennen, eine zusätzliche schnelle Orientierung bieten, wo bei Olympiaden oder Fußballmeisterschaften welche Mannschaften stehen. Für Blinde muss es auch ohne diese Optik funktionieren. Was du hingegen mit deinem {{Flagge|EGY|o=-3}} anstellst, geht fundamental an der Anforderung und der performanten Einbindung Hunderter von Flaggen bei einer Weltmeisterschaft oder Olymiade vorbei und ist ein Holzweg. Vorlagen lösen ein Problem, das in unseren Artikeln besteht; du bastelst eine überkomplizierte Lösung, zu der niemand ein Problem hat. Irgendwelche Staatsnamen in der Landessprache und gar fremden Schriften sind für den Anwendungsfall völlig daneben.
Für den Eigenbedarf habe ich es primär geschrieben. Die ‚Einbindung Hunderter von Flaggen bei einer Weltmeisterschaft oder Olymiade ‘ war nicht meine Intention, da können die Sport-Autoren die Vorlage:FlagIcon einsetzen, die diese Aufgaben perfekt löst. Wer es ‚überkompliziert‘ findet, könnte via {{Flagge|EGY}} »→ agyptenÄgypten auf alle bisher bekannten Darstellungen mit exakt den selben (und optional zusätzlichen) Parametern zugreifen. Einziger Unterschied: Aspect ratio stimmt exakt und in allen Größen, da die komische Breitenausgleichsberechnung der konventionellen Vorlagen nur bei Standardgrößen (WIDTH=20) einigermaßen funktioniert.
Einige Extrawürste entstanden gemeinsam mit ausländischen ‚Spielkameraden‘, die andere Ansichten und Wünsche haben. Da sind noch (er)weiter(t)e Projekte in gemeinsamer Arbeit, die sich nicht nur auf Flaggen und Icons konzentrieren. So gesehen führen einige Holzwege in eine total andere Richtung und die abrufbaren Informationen sind nur ein ‚Abfallprodukt‘ anderer Anwendungsfälle.
Aber das ist hier auch nicht das Problem, denn es geht um Schriftgrößen und andere Darstellungsprobleme, die ja via Vorlage:lang laufen und nirgends meine Handschrift tragen.
Mitunter orientiere ich mich an enwiki, die ja 2 Monate länger im Wiki-Rennen sind und scheinbar die Darstellungsproblematik anders sehen und lösen, siehe z.B. {{Lang-ar}} (funktioniert sogar ohne ‎ perfekt -- was machen die falsch???). Ich kann damit gut leben und brauche keine überkomplizierte dewiki-Lösung, die gerne Probleme formuliert und eigenwillig löst. Handlungsbedarf dieser Art sehe ich allenfalls bei birmanischမြန်မာစာ, aber da ist eine sinnvolle Anpassung nicht erkennbar. --Klaus-Peter21:30, 12. Nov. 2019 (CET)
Wirrwar mit Groß-/Kleinschreibung
Bei den Vorlagen für Sprachen gibt es ein wildes Durcheinander bei Groß- und Kleinschreibung. Tatsächlich sind beide Variationen richtig. Das erklärte mir auf Anfrage ein ausgewiesener Experte via beratung@germanistik.fu-berlin.de (nicht die Schnellsten, aber gründlich). Bei Wikipedia zeigt sich:
Wir schreiben im gesamten Projekt einheitlich seit über zehn Jahren klein, wenn die Sprache einer Publikation, eines Begriffs usw. angegeben wird. Die Vorlagen unterstützen exakt dies; es ist völlig egal, ob das Wort englisch nun direkt im Quelltext stünde oder von der Vorlage generiert wird.
Kleinschreibung ist jedoch nur möglich, wenn es eine Adjektivform gibt; das ist wohl immer dann der Fall, wenn die Form auf -isch endet („englisch“), manchmal wie bei „deutsch“ auch in anderen Fällen.
Zu bestimmten Sprachnamen gibt es keine Adjektivform; das wären etwa Farsi, Urdu, Sanskrit, Thai und viele sehr exotische Sprachen, die es überhaupt nicht in einer deutschen Form gibt. Hier gilt immer Großschreibung. Da es aber sehr exotische Sprachen sind, tritt dieser Fall nur sehr selten in unseren Artikeln auf.
Manchmal wären beide Formen möglich, wie bei „deutsch“ (in deutscher Sprache) oder „Deutsch“ (auf Deutsch gesagt). Hier verwenden wir durchgehend die Kleinschreibung. In einer Zusammensetzung wie „Schweizer Hochdeutsch“ geht jedoch nur noch Großschreibung.
Die Vorlagen bilden nur den langjährigen Projektstandard ab; ansonsten hat dein Anliegen absolut überhaupt nichts mit Vorlagen zu tun. Wenn du darüber diskutieren möchtest, den Quelltext von einer halben Million Artikeln zu ändern, müsstest du dir einen anderen Ort suchen.
Tjo, und manchmal gibt es zwei Formen; als Substantiv „auf Latein“ und als Adjektiv „in lateinischer Sprache“, also sowohl Latein wie auch lateinisch. Hier gilt die möglichst-Klein-Regel; ergo {{laS}} → lateinisch.
Ich kann mir kaum vorstellen, dass es eine halbe Million Sprachen und entsprechend viele Vorlagen gibt, in denen die Schreibweise so eingetragen ist, wie in obigem Muster demonstriert (257 Beispiele) gibt es bei einer ordentlichen Dunkelziffer vielleicht 500. Übertreibungen imponieren mich nicht.
190.000 Treffer im ANR-Quelltext für Kleinschreibung mit Klammer vornedran allein für „englisch“.
Mancher weiß das nicht so genau, und schreibt irrtümlich groß; (Englisch – das wird dann so nach und nach korrigiert.
Eigentlich soll nicht wie in gedruckten Werken zur Papierersparnis abgekürzt werden, aber gibt es auch mal: (engl – heute 773 Treffer für (Engl
Und das kannst du dann für alle Weltsprachen durchspielen, saldieren, und wirst bei einer halben Million herauskommen, wo das also fest in den „Quelltext von einer halben Million Artikeln“ hineingeschrieben wurde und jeweils je nach Kontext „zu ändern“ wäre. Wobei das pro Artikel mehrfach auftreten kann; also mehrere Millionen Textstellen je nach Kontext im Sinne deiner Vorstellungen umzuschreiben wären.
Das gilt auch für die beteiligten Vorlagen, die in den meisten Artikeln bei der Übersetzung des Lemmas eingesetzt werden; sie schreiben alle und praktisch durchgehend von 2006 an Adjektive, also Kleinschreibung (vorausgesetzt dass eine adjektivierte Form existiert).
Deine Unterstellungen, deine Kommunikationspartner würden Zahlen frei erfinden und du hättest die gefühlte Wahrheit, können dich irgendwann zumindest zeitweilig vom Projekt ausschließen.
Das ist jetzt bereits das zweite Mal binnen eines Monats, dass du mir in dieser Werkstatt eine Verbreitung von Unwahrheiten unterstellst.
Du selbst hingegen hättest ja deine gefühlte Wahrheit. Das, was du dir so vorstellen kannst. Pech bloß, dass sich mit wenigen Klicks zuverlässig auch dieses Mal die Größenordnung von Zahlenangaben objektiv herausfinden lässt. Und du um drei Größenordnungen daneben liegst, wenn man die Zahl der Sprachnamenvorlagen mit Kleinschreibung als Basis heranzieht.
Unsere Vorlagen und Module sind nicht irgendwelche freihändig programmierten Softwarebrösel nach deinem privaten Geschmack, sondern sie haben Aufgaben im Sinne der Richtlinien und Standards dieses Projekts, seiner enzyklopädischen Artikel und seiner Projektorganisation zu erfüllen. Du gehst jedoch regelmäßig nicht von der Frage aus, was genau für dieses Projekt benötigt wird und wie zu programmieren wäre, um genau diesen Bedarf zu decken.
@PerfektesChaos Ungefähr 249.000.000 Ergebnisse liefert Google, imponiert mich auch nicht, denn bei meiner Anfrage ging es um VORLAGEN (daher auch die Anfrage unter Vorlagenwerkstatt und nicht ‚... einen anderen Ort suchen‘). Notfalls kann man das auch an den gelieferten Beispielen erkennen. Bei ‚Unsere Vorlagen und Module sind ..‘ taucht der Begriff wieder korrekt auf. Das (und meine Anfrage) bezieht sich nicht auf irgendwelche 190.000 oder mehr Artikel, die das richtig oder falsch einsetzen, NUR auf Vorlagen!
Eine plausible Erklärung der Regeln wurde ja auch gegeben (z.B. -isch-Regel). Der ergänzende Roman, zweifelhafte oder beweisbare Zahlen und sonstige personenbezogene Kritik ist kaum hilfreich und führt weitläufig am Thema vorbei.
@WurglKomisch ist tatsächlich komisch, aber das Volk der Komi spricht tatsächlich die permischen Sprachen komi-permjakisch und komi-syrjänisch. Bei Ableitung einer Sprache von einer gleichlautenden Volksbezeichnung würde ich Komi-Sprache resp. Komisprache oder komisprachig bevorzugen. ‹komisch› wäre zwar korrekt, aber ziemlich zweideutig, somit missverständlich und vorlagenuntauglich Vorlage:Smiley/Wartung/???. Hat somit in einer Vorlagenwerkstatt nichts zu Suchen.
„Unsere Vorlagen und Module sind nicht irgendwelche freihändig programmierten Softwarebrösel nach deinem privaten Geschmack, sondern sie haben Aufgaben im Sinne der Richtlinien und Standards dieses Projekts, seiner enzyklopädischen Artikel und seiner Projektorganisation zu erfüllen. Du gehst jedoch regelmäßig nicht von der Frage aus, was genau für dieses Projekt benötigt wird und wie zu programmieren wäre, um genau diesen Bedarf zu decken.“
Heißt: Die Vorlagen sind nur ein anderer Weg, um (vielleicht mit mehr technischem Zusatznutzen) das Gleiche zu machen, was auch ohne Benutzung einer Vorlage direkt im Quelltext stehen könnte.
Die Vorlagen haben sich, soweit solche hinreichend präzise vorhanden sind, an den Standards und Richtlinien des Projekts zu orientieren.
Deine ursprüngliche Zielrichtung, einfach nur die Vorlagen auf Großschreibung umzustellen, weil du es irgendwie schick fändest, wenn alle Vorlagen einheitlich nur Großschreibung produzieren würden, geht völlig am Sinn und Wesen der Vorlagen vorbei.
Das, was die Vorlagen produzieren, muss übereinstimmen mit dem, was auch ohne Vorlagennutzung im Artikel stehen würde/sollte. Dein Ansatz, hier in der Vorlagenwerkstatt „NUR auf Vorlagen“ bezogen eine andere Schreibweise herbeizuführen ist von vornherein kaputt.
Dann führst du „Mykenisch“ an und findest mal eben so bei mykenisches Griechisch, „mykenisch wäre ausreichend“ – nein, ist es nicht, und deshalb wird das auch ausdrücklich so verwendet. Eine „Mykenische Sprache“ ist nicht bekannt; unser Artikel heißt auch ausdrücklich „Mykenisches Griechisch“ als Vorläufer des „klassischen Griechisch“. „Mykenisch“ ist keine Sprache, sondern ein Territorium oder eine Bevölkerung oder eine Kultur, wo vermutlich auch Minoisch oder sonstwas gesprochen wurde. Aus dem gleichen Grund gibt es keine „Schweizerische Sprache“ oder „Schweizerisch“ und keine „Amerikanische Sprache“, es gibt Schweizer Hochdeutsch, anders Schwyzerdütsch oder Alemannisch sowie schweizerisches Französisch und schweizerisches Italienisch und Rätoromanisch oder mit welchen Feinheiten auch immer.
Ich habe keine Zielrichtung bei diesen Vorlagen, nur manchmal Fragen und keinen Bock auf kaputte, ausufernde Antworten von Allwissenden. Es lohnt auch mal ein Blick in die Infobox 3. Zeile bei Mykenisches Griechisch. Wer hat das verbrochen?--Klaus-Peter17:22, 17. Nov. 2019 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Angeblich falsches Forum um generelle Vorlagen-Richtlinien zu diskutieren--Klaus-Peter05:10, 16. Nov. 2019 (CET)
Vorlage:NNBW leitet weiter auf Vorlage:NieuwNederlBioWoord und ist ein Wrapper um Vorlage:Literatur. Die Fehlermeldung aus der Zwischenüberschrift sehe ich bei allen Einbindungen der Vorlage (5 Stichproben). Diese numerischen Parameter (beim Betrachten der Dokumentation frag ich mich wer sich nur diese Reihenfolge ausgedacht hat) sind Aliase für benamste Parameter, scheinen also okay zu sein. Es wird #invoke:TemplatePar aufgerufen und bei dessen Parametern ist wohl der Wurm, aber da hab ich keinen Schimmer. *ganz lieb in die Runde guck* --Wurgl (Diskussion) 07:22, 17. Nov. 2019 (CET)
Ja, wird wohl an „mir“ liegen, ich mag keine unbenannten Aliasse. Habbich sicherlich vergessen als Option zuzulassen. Ich bin halt etwas ungeschikt mit der Zuweisung TemplatePar/check mir ist das immer etwas … ungewöhnlich --Liebe Grüße, LómelindeDiskussion11:45, 17. Nov. 2019 (CET)
Leider ist mit einer vorhergehenden Änderung die Doku von 2- auf 3-stellig geändert worden, so dass bei der weit überwiegenden Zahl der Wahlkreise der Link immer noch falsch ist. Es ist nicht zielführend, die Doku zu ändern, nachdem die Vorlage bereits vielfach verwendet wurde. Die fehlende Null ist daher in der Vorlage so wie von mir vorgeschlagen zu ergänzen, wenn man vermeiden will sämtliche Nutzungen der Vorlage zu ändern. Sorry, dass ich die Doku nicht angepasst habe. Gleiches gilt für die Vorlage "Nds LTW 2017". (nicht signierter Beitrag vonHambre (Diskussion | Beiträge) 12:55, 17. Nov. 2019 (CET))
Leider verstehe ich nicht, Hambre, wohin „die Reise“ gehen soll. Ausgangspunkt ist: die offizielle Wahlkreisnummer wird in den PDFs mit führender Null (danach zweistellig) geschrieben. Das ist insofern sinnvoll, als zukünftig bei anderem Zuschnitt der Wahlkreise auch eine Zahl ab 100 erfasst werden könnte.
Du hast jetzt die führende Null fest in die Vorlage eingebaut, was einerseits zur Folge hat, dass alle bisher dokugemäß 3-stellig ausgefüllten VLs keinen funktionierenden Weblink bieten, da eine Null zuviel im URL ist; andererseits, dass damit künftig auch keine Wahlkreisnummern ab 100 erfasst werden könnten.
Die VL-Doku muss mit der VL-Funktion übereinstimmen. Dies bedeutete: falls Deine feste führende Null Standard würde, müsste sich auch die Doku ändern.
M. E. wäre es aber besser, die VL wie bisher 3-stellig ausfüllen zu lassen. Dann müsste gar nichts an der VL geändert werden. Nur wären diejenigen VLs zu korrigieren, die vor und von Dir anders ausgefüllt worden sind.
Vllt. möchte der Ersteller, Kevin Price, sich der Sache annehmen.
Das Problem ist, dass die Vorlage ursprünglich auf 2-stellig ausgelegt war. Dass der erzeugte Link fehlerhaft ist, wurde dann bemerkt und anstatt die Vorlage zu ändern ist die Doku geändert geändert worden. Im Ergebnis haben wir jetzt einen Kuddelmuddel, d.h. von den 83 Landtagswahlkreisen ist ein großer Teil 2-stellig und ein anderer großer Teil 3-stellig angelegt worden. Dass die Zahl der Wahlkreise für die Wahl 2013 nachträglich auf >100 geändert wird ist dabei ausgeschlossen. Der feste Einbau der 3. Stelle ist unproblematisch, da die Vorlage ausschließlich für die Wahl 2013 verwendbar ist. Zur besseren Leserlichkeit im eigentlichen Artikel würde ich jedenfalls die 2-stellige Angabe bevorzugen. Die Doku habe ich jetzt auch geändert. Da ich ohnehin gerade dabei bin sukzessive die Ergebnisse 2017 einzubauen, würde ich das dort auch ändern, wo schon auf 3-stellig angepasst wurde. Die Wahlkreise 1-11 habe ich bereits geändert.
In der Vorlage:Nds LTW 2017 habe ich den Link ebenfalls korrigiert. Dort musste die Angabe laut Doku noch 2-stellig erfolgen.--Hambre (Diskussion) 15:41, 17. Nov. 2019 (CET)
Und dass die Vorlage für 2008 eine 2-stellige Eingabe erfordert und dann die Vorlage 2013 eine 3-stellige Eingabe ist ebenfalls inkonsistent. Das ist für mich ein weiteres Argument, bei der 2-stellige Angabe zu bleiben. --Hambre (Diskussion) 16:01, 17. Nov. 2019 (CET)
Es gibt seit 2006 die nette Parserfunktion padleft: – wenn klar ist, was in welchem Jahr passieren soll ließe sich das damit alles nett und unabhängig von der Eingabe glätten. VG --PerfektesChaos17:06, 17. Nov. 2019 (CET)
Nun gut, Hambre, dann werde ich die zweistellige Eingabe mal sichten. Und ich verstehe recht, dass Du die Artikel zu 2013 ab Nr. 12 noch durchgehst und ggf. korrigierst? Danke dafür schon einmal.
Die Doku sollte so präzisiert werden: „Nummer des Wahlkreises zweistellig, Nr. 1 bis 9 mit führender Null (0)“, um Dopplungen zu vermeiden. Gruß, --Wi-luc-ky (Diskussion) 18:37, 17. Nov. 2019 (CET)
Auf Hinweis von PerfektesChaos habe ich nun die Variable padleft: verwendet, so dass die Zahl nunmehr 1-, 2- oder 3-stellig sein kann. Das ist wohl die beste Lösung. Kannst Du die Vorlage:Nds LTW 2017 auch noch sichten? (nicht signierter Beitrag vonHambre (Diskussion | Beiträge) 18:53, 17. Nov. 2019 (CET))
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.
Leider passen da einige der gewünschten Angaben nicht hinein. Dann gibt es noch die Vorlage:Infobox Sportwettbewerb, Beispiel: Leichtathletik-Disziplin:
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.
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).
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.
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.
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)
@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)
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.7010: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.7011: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)
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)
"Template:Refn" der :en:Wiki in die :de:Wiki importieren
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)
@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)
Hier gehen zwei Bedeutungen von „Gruppieren“ durcheinander:
„Gruppieren“ im Sinne einer Gruppe in einem eigenen <ref>-Block, wie es zutreffend von Chiananda beschrieben wurde.
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.
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.
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ß, -- hgzh01: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]]"
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ómelindeDiskussion12: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. -- hgzh15:11, 7. Nov. 2019 (CET)
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)
Die Klappbox funktioniert nicht auf meinem Tablet mit Betriebssystem Android: sie erscheint dort im aufgeklappten Zustand ohne die Möglichkeit zum Zuklappen.--Mathemix (Diskussion) 15:23, 16. Nov. 2019 (CET)
Tabellen in Klappboxen auszublenden hat den Nachteil, dass die darin enthaltenen Daten z.B. nicht gedruckt werden können und auch in einem pdf nicht zur Verfügung stehen. Wenn du sowieso eine Tabelle erstellst, bekommt diese sicherlich eine Klasse? Du kannst die class=wikitable allerdings ergänzen: class="wikitable mw-collapsible mw-collapsed". Siehe auch Hilfe:Tabellen#mw-collapsible --darkking3Թ18:33, 17. Nov. 2019 (CET)
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ómelindeDiskussion12: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.
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)
Ein Bild sagt mehr als 1000 Worte. War mir schon länger aufgefallen: machen wir da was falsch oder wo liegt das Problem? Ich glaub, das war mal irgendwann für "Kleindeutschland" entwickelt, aber für einige andere Länder haut das nicht hin bei vielen Parteien und vielen Werten. Alternativen? Und danke, --Emeritus (Diskussion) 16:11, 12. Nov. 2019 (CET)
Bei mir im Prinzip auch gut. Nur hängt der Link zur vorausgegangenen Wahl mit einer Zahl etwas in die Überschrift hinein, selbst im großen Browserfenster. Vllt. kann Wiegels Abhilfe schaffen? Gruß, --Wi-luc-ky (Diskussion) 17:02, 12. Nov. 2019 (CET)
oh, ich hatte 18, aber meist vergrößere ich auch noch 2x, damit ich was sehe. Bei FF Schriftgröße 9 waren dann die Werte etwas auseinandergezogen, dann legte ich den Monitor wieder unter das Elektronenmikroskop oder war's die Handlupe :-(. Da fehlt also irgendwie der Hinweise für best resolution und font size, für das dann eine Vorlage gestrickt wurde, alle anderen haben dann vor der Barriere zu bleiben. Seien Eure Äuglein auf ewig gesegnet. --Emeritus (Diskussion) 19:57, 12. Nov. 2019 (CET)
Hast du irgendwo eine andere Bildgröße festgelegt, die von dem hiesigen Standard von 220px abweicht. Das würde für mich dann auch erklären, weshalb bei dir andere Auswirkungen zu sehen sind, als bei mir. Ich habe nämlich mit der besagten Darstellung dort auch kein Problem, ich kann es mal messen. Das Diagramm wird bei mir etwa mit 16 cm Breite ausgegeben und wird etwa doppelt so breit angezeigt, wie die darunter stehende „Sitzverteilung im Abgeordnetenhaus“ ca. 8 cm. Die von dir hochgeladene Grafik scheint hingegen in der Breite fest eingestellt zu sein. Irgendwie siehst du etwas anderes als wir anderen. --Liebe Grüße, LómelindeDiskussion15:42, 13. Nov. 2019 (CET)
⇐⇐Bei mir sieht das Diagramm grauslig aus. Fast alle Texte übereinander. Mein Tipp: Eine SVG erstellen und fertig. Das passt immer. ÅñŧóñŜûŝî(Ð)21:08, 13. Nov. 2019 (CET)
Und wer bitte sollte bei jeder neuen Wahl dann etliche Diagramme zu Bildern umbasteln? Bilder kann man nicht anpassen, was ist wenn ein Ergebnis sich ändert eine Partei umbenannt wird soll man dann jedes Mal neue Bilder hochladen? Ich brauche diese Diagramme nicht wirklich aber der Arbeitsaufwand, den du hier vorschlägst, ist meiner Meinung nach zu hoch. Das wird ja nicht das einzige Diagramm sein, dass bei euch beiden so überlagert wird, wichtiger wäre es die Ursache dafür zu finden und es dann möglichst so anzupassen, dass es überall ordentlich aussieht. Wenn es jedoch an individuellen Einstellungen liegt so weiß ich nicht wie man das anpassen könnte, niemand kann erraten was sich dann wo ändert, wenn er die Einstellungen nicht kennt. Vielleicht ist es ja auch eine Browsereinstellung, die dazu führt (Schriftart, Schriftgröße dort?). --Liebe Grüße, LómelindeDiskussion08:49, 14. Nov. 2019 (CET)
Wenn du nach jeder Wahl die Vorlageneinbindung ändern musst, dann kannst du auch die SVG im Plaintext-Editor anpassen. Wenn man auf Verlinkungen verzichtet, kann man auch mit der Graph-Erweiterung arbeiten. ÅñŧóñŜûŝî(Ð)18:17, 14. Nov. 2019 (CET)
Bist du sicher? Graph funktioniert auch nur bedingt gut. Ich muss diese Vorlagen nicht ändern, ich verwende sie nicht einmal. Es geht ja mehr darum wieviel Aufwand du da im Einzelnen unterschiedlichen Benutzern aufbürden möchtest, die nur mal schnell neue Ergebnisse einfügen möchten. --Liebe Grüße, LómelindeDiskussion18:50, 14. Nov. 2019 (CET)
Soweit ich das sehe benötigt man für die Änderung Lua, da die Änderung des Namens in Kleinschreibung und das Ersetzen des Blanks zwischen Vor- und Nachname durch ein Minus sonst kaum machbar sind.
Wobei sich auch die ID von 2718 zu 70044 verändert hat, was also vermutlich teilweise eine manuelle Prüfung und Ersetzung oder einen Abgleich mit Wikidata erfordern würde. Angezeigt wird bei Steffi Graf nämlich durchaus die neuere ID (http://www.wtatennis.com/player-profile/70044), im Quelltext Steffi_Graf#Weblinks steht hingegen eine alte Nummer * {{WTA|2718}}. Wie das also genau verbucht wird, weiß ich jetzt nicht, es ist zumindest sehr verwirrend, wenn etwas anderes in Quelltext steht als tatsächlich verwendet wird. Ich dachte immer die Quelltext-ID hätte Vorrang gegenüber den Werten aus Wikidata, damit diese auch geprüft werden können. Wie gesagt Lua braucht man dafür nicht. Es wäre schön wenn die Vorlage auf Vorlage:wtatennis.com verschoben werden könnte und zudem Sprechende Parameternamen bekäme. --Liebe Grüße, LómelindeDiskussion18:44, 12. Nov. 2019 (CET)
Naja, nicht nur die Programmierung müsste sich schon ändern.
Darüber müssten sich unsere Tennisspieler zunächst mal verständigen.
Kryptisch benannte Vorlagen bekommen in dieser Werkstatt praktisch keinen Support mehr.
Im Gegenzug würde es dann auch eine moderne Doku geben.
Auch ohne eigenes Lua, aber mit fortgeschrittener Vorlagenprogrammierung wäre für Standardfälle die automatische Generierung vorname-nachname machbar; aber es gibt kompliziertere Vor- und Nachnamen und Adelstitel und so Zeugs, und die lassen sich nicht mehr dummdreist aus dem Lemma unseres Artikels ableiten.
Prinzipiell darf eine Vorlage auch in einem Artikel mit ganz anderem Thema verwendet werden.
Ich würde folgendes Vorgehen vorschlagen:
Umbenennung auf einen selbsterklärenden Namen
Benannte Parameter
Botlauf über die 1663 einbindenden Artikel, der auf den neuen Namen der Vorlage umstellt und aus dem Lemma oder der Personendaten-Vorlage die Vornamen und Nachnamen zu raten versucht und als neuen Parameter einbringt. Oder bei Wikidata nach deren Meinung schaut.
Manuelle Nachkorrektur, wo das nicht so ganz hinkam.
Ganz liebe Bots könnten die neue URL ausprobieren und einen Kommentar im Quelltext oder einen Fehlerparameter schreiben, wenn diese geratene URL nicht zum Erfolg führt.
Wikidata sehe ich nicht so als Problem; das Ziel scheint ja zu sein, dass bei uns eine ID stünde und nur mit Wikidata abgeglichen wird, ob dies übereinstimmt.
Na ja und weshalb sehe ich dann bei {{WTA|2718|Steffi Graf}} im Artikel diese URL →http://www.wtatennis.com/player-profile/70044 wenn da angeblich nur mit Wikidata abgeglichen wird, ob die Werte identisch sind???? Das ist verwirrend wenn etwas anderes dort steht, es funktioniert dann auch nicht, wenn es in einem anderen Artikel verwendet wurde, dann müsste nämlich die passende ID dort nachgetragen werden da sie nicht automatisch aus Wikidata überschrieben werden könnte. Im Quelltext 2718 im Link dann 70044, wenn es die Personenseite selbst ist, im Quelltext und im Link 2718, wenn ich es hier verwenden würde. So etwas mag ich gar nicht, gleiche Einbindungen, egal wo ich sie verwende, sollten auch eine identische URL generieren, oder sehe ich das falsch?
Urlencode wandelt Großbuchstaben nicht in Kleinbuchstaben um und ersetzt auch das Blank nicht durch ein Minus. Damit allein ist es also nicht getan.
Soweit ich die Vorlage verstehe, verwendet sie – wenn vorhanden – die ID aus Wikidata. Die als Parameter angebene ID wird nur verwendet, wenn auf Wikidata keine vorliegt.
Weiß jemand, wie man diese Ersetzungen ohne Lua vornehmen kann?
Auffälligkeiten Vorlage:lang und Vorlage:TransText
Ein paar Sachen sind mir bei dem versuchten Einsatz dieser Vorlagen aufgefallen. Ich kann und will nicht beurteilen ob es so geplant war, ob es Flüchtigkeitsfehler sind oder ein früher Entwicklungsstand im Praxistest:
ב(Bet) wird bei {{transText|Hebr|עברית|ISO259-3}}nicht transkribiert, sondern wird 1:1 in den lateinischen Text übernommen, erscheint somit als «ʿבryt»
Bei Eingabe von {{lang|und-Hebr|עברית|ISO259-3=ʿbryt}}erscheint in der Vorschau die Reklamation «Vorlage:Lang – Parameter unbekannt:'ISO259-3'». Nur bei ‚yi-Hebr‘ wird es nicht reklamiert.
Bei Vorlage:TransText/Doku#Mögliche_Codes ist die Auswahl der Ausgangscodes etwas mager. Ich vermisse z.B. Arab, Armi, Beng, Bopo, Copt, Deva, Geok, Hanb, Glag, Hani, Hano, Hans, Hant, Hira, Kana, Khmr, Laoo, Latn, Linb, Phli, Runr, Sinh, Syrc, Thaa, Thai, Ugar, Xpeo, Xsux und auch bei den Umschriften ist deutlich weniger eingetragen, als man bei Vorlage:Lang/Doku#Umschrift entdecken kann. Siehe auch andere Beispiele. hat die Meldung «Vorlage:TransText – Ausgangscode unbekannt:Latn» etwas damit zu tun?
Wegen der aktuellen politischen Lage geraten immer mehr Orte und Personen in den Fokus, die vorzugsweise arabisch benannt sind. Auch einige Ostasiaten drängeln sich vor. Ich halte es stets für sinnvoll, die auch mit Originalnamen aufzuführen, da es die Möglichkeit weiterer Recherchen via Suchmaschinen eröffnet, um über den germanischen Horizont hinaus zu blicken.
Meine Frage: Kennt jemand praktikable Möglichkeiten bei dewiki, die von Vorlage:lang und Vorlage:TransText offerierten erormen Möglichkeiten, im genannten, erweiterten Umfeld zu nutzen oder bleibt es vorerst bei der konventionellen Methode der Eingabe, insbesondere bei Transskripion/-literation?
Gibt es eine Perspektive, wann in etwa die Funktionalität mit der bei enwiki erreicht wird?
Gibt es andere Vorlagen, mit denen der genannte Zweck erreicht werden kann?
Gibt es eine Vorlage, mit der man ausschließlich Transskripion/-literation nutzen kann? Beispiel {{Transe|ru|Орган стандартизации}}»→Organ standartisazii (russischОрган стандартизации, wiss. TransliterationOrgan standartizacii bzw. parametergesteuert auch andere passende Ausgaben, wie z.B Орган стандартизации (Organ standartisazii).
Bitte knappe, sachliche und hilfreiche Antworten. Mit philosophischen Ausschweifungen und pädagogischen Kritiken kann ich nichts anfangen. --Klaus-Peter09:27, 20. Nov. 2019 (CET)
Ich vermute es gibt ein Problem mit der angehängten -3 = ISO259-3. PC kann das sicherlich reparieren. Ich denke vielleicht fehlt in Zeile 388 einfach die Zuweisung
Mit {{subst:transText|Hebr|עברית|ISO259-2}} zumindest funktioniert es → Ergebnis der Substitution = עברית ISO259-2ʿbryt
Ansonsten habe ich hier massiv den Eindruck, dass du dich mit ihm anlegen möchtest, um zu beweisen, dass du der „fähigere Programmierer“ bist. Das halte ich nicht für sehr sinnvoll, wir sind hier ein Team und keine Konkurrenten.
Die anderen Fragen kann ich aber nicht beantworten. Das ganze hättest du auch auf die →Vorlagendiskussionsseite schreiben können, du kannst sicher sein, dass er die auf dem Schirm hat, satt hier ständig mit riesigem Aufriss die Vorlagenwerkstatt zu überschwemmen. Und meine Bitte wäre auf keinen Fall alle Artikel großflächig mit der Vorlage:lang für jedes Fremdwort zu beglücken. --Liebe Grüße, LómelindeDiskussion11:15, 20. Nov. 2019 (CET)
Mit PC anlegen? Hat er Wiki erfunden oder ist er für alles zuständig? Ich weiß nicht mal, wo diese Zuweisungszeile zu finden ist. Leider bin ich in der Wikipedantischen Programmierumgebung (Vorlagen, LUA-Umbauten) kaum bewandert, daher muss ich fragen. Nach meinen Kenntnissen in C++, Java, PHP usw. fragt hier kein Mensch, da müssten sich Konkurrenten schon anstrengen, um da mitzuhalten. Lua kann ich noch begreifen, auch wenn mir da einiges fehlt, was ich in PHP laufend einsetze. Wie Programme funktionieren müssten, kann ich sehr wohl beurteilen und ich bemerke auch, wenn etwas nicht so funzelniert, wie z.B. in Dokus dargestellt. Mir fallen Sachen auf, die ich wie beschrieben einsetze und dann nicht so wollen, wie dargestellt. Wenn es keiner reklamiert, kann es auch nicht repariert werden, denn auch ich übersehe eigene Fehler gerne und freue mich sogar, wenn sie reklamiert werden (hatten wir das nicht gerade?)
‚Werkstatt überschwemmen‘ ist der Hammer. Reparaturen erst in Debatten zerreden ist wohl kaum die produktive Adresse und auf dem Friedhof ist mehr los als auf der Vorlagendiskussionsseite. Artikel mit Fremdwörtern zu beglücken halte ich auch nicht für sinnvoll. Aber wenn ich bei Putin auch unter ‚Владимир Владимирович Путин‘ googeln kann, bekomme ich ungefähr 4.870.000 Ergebnisse (0,68 Sekunden), die vermutlich nicht immer die Meinungen über Wladimir Wladimirowitsch Putin verbreiten wie bei den hier etablierten Multiplikatoren. Damit baue ich mein mehrseitiges Weltbild auf. lang und transText überschwemmen nicht, sondern machen solche Einträge verständlicher! Bitte nicht die Autoren dieser Vorlagen diskriminieren, da steckt unendlich viel Arbeit drin.--Klaus-Peter12:26, 20. Nov. 2019 (CET)
Rückfrage: Genau welche Aktivitäten auf enwiki sind mit „in etwa die Funktionalität mit der bei enwiki“ gemeint? Mir sind keinerlei annähernd gleichartigen bekannt.
TransText ist relativ jung, wenn auch nicht mehr experimentell und soll sich hoffentlich projektübergreifend weiter entwickeln.
BETA kennt zusätzliche Möglichkeiten in nicht freigegebenem Stadium.
Bei dem fraglichen Beispiel liegt es daran, dass ISO 259-3, zu dem wir noch nicht einmal einen Sammelartikel ISO 259 hätten, das fragliche Schriftzeichen bzw. seine Vokal-Konsonanten-Kombination nicht kennt bzw. keine eindeutige Aussage trifft. Deshalb gibt es keine Lösung.
Die ISO259-3 ist ihrerseits noch experimentell und noch kein offizieller Standard; deshalb auch in Vorlage:lang nicht für beliebiges Hebräisch seit der Bibel für unsere Artikel zugelassen.
Bei Yiddishyi liegt die Situation etwas anders, aber dort kommt das wohl so auch nicht vor. Im Übrigen kommt diese lebende Sprache dem von der ISO 259-3 verfolgten neuartigen Konzept wohl besonders entgegen.
Bei den anderen Transkriptionsmethoden werden andere Zuordnungen vorgenommen, und dieser Zeichenkombination ist dort eine Transkriptionsregel zugeordnet.
Die Universal-Transkription ISO259 hat andere Regeln, passt für alle Jahrtausende, hat jedoch ein anderes Konzept als die vorgeschlagene Variante -3, und liefert ggf. andere Umschriften.
Es bedarf schon inhaltlicher Sachkunde in den entsprechenden Sprachen, um die für die vorliegende Anwendung geeignete Transkriptionsmethode auszuwählen.
Diese Form der Transkription ist hochkomplex und bedarf der Mitwirkung echter Fachleute für die jeweilige Sprache, weil nicht einfach Buchstabe gegen Buchstabe ausgetauscht werden kann, sondern der/die neue(n) Buchstabe(n) von den vorangehenden und nachfolgenden abhängen können; insbesondere ganze Silben bei gleicher Buchstabenfolge der ursprünglichen Schrift eine ganz andere Transkription erhalten könnten (so etwa auch am Wortbeginn oder Wortende).
Wikipedia:Wikyrill-o-mat, von denen der größere Teil der kyrillischen Transkription abgeleitet wurde, sind von mir vor einiger Zeit zur Revision und Beteiligung angefragt woden, hatten sich jedoch bislang nicht geäußert.
Unsere heimischen Experten für kyrillisch geschriebene Sprachen hatten sich noch nicht geäußert; einen Personalstamm, der die systematische Sachkunde in den von dir weiter aufgezählten Sprachen/Schriften hätte und in der Lage wäre, an der technisch-formalen Definition mitzuwirken, sehe ich derzeit eher nicht. Ohnehin würde erst nach vorläufigem Abschluss der in der BETA-Pipeline liegenden kyrillischen Transkriptionen eine Ausdehnung in andere Schriftsysteme erfolgen.
Eine dauerhafte Einbindung einer Transkriptionsvorlage in den Quelltext von Artikeln ist aus Performancegründen unzulässig; es ist ein Hilfsmittel, mit dem ein kompetenter Autor des Artikels einmalig die Umschrift ermitteln und statisch in den Artikelquelltext einfügen kann. Andernfalls müsste der gesamte komplexe Akt bei jedem Neuaufbau der Seite beginnend von Adam und Eva erneut vorgenommen werden.
Einen Ausgangscode und -text aus lateinischer Schrift Latn in lateinische Schrift umzuschreiben weist nicht gerade auf tieferes Verständnis der Angelegenheit. Prinzipiell wäre vorstellbar, mittels dieser Software aus lateinischer Schrift in kyrillische Schrift umzuschreiben; aber dazu liegen mir bislang keine Regeln vor.
Die Engländer sind aus meiner Sicht schlanker und übersichtlicher.
Generell stellt sich die Frage, aber das passt eher in eine Diskussion, ob man wirklich alle angebotenen Variationen braucht. Bei den Hebräern kann ich keinen praktisch verwertbaren Unterschied feststellen und halte 4 Varianten für entbehrlich. OK, die Wikyrill-o-mat-Lösung ist aus meiner Sicht ausreichend: Deutsche Version und dazu eine 'Internationale'. Sprachwissenschaftler werden sicherlich nicht ihre Habilitation bei Wiki abschreiben und deren Ansprüche sollten kein Maßstab für enzyklopädische Brauchbarkeit sein. Mir reicht es, wenn ich das Original sehe, eine Transkription, ggf. IPA und ogg. Die Variation mit mehreren Sprachen und Umschriften nebeneinander, sehe ich eher als technische Spielerei. Also aus meiner Sicht ruhig gesundschrumpfen und den unbedarften Nutzer (wie mir) eins schlanke, übersichtliche Lösung anbieten. Das im Hintergrund viel mehr steckt und ggf. ausgereizt werden kann, spielt auf einer anderen Bühne.
‚Eine dauerhafte Einbindung einer Transkriptionsvorlage in den Quelltext von ...‘ Da bin ich eher datenbankorientiert und frage flott mal eine kleine Tabelle ab. Sprachen sind ja meistens ziemlich statische Angelegenheiten. Da könnte eine einmalige Abfrage (wie via Wikyrill-o-mat) oder transText ausreichen und das Ergebnis eintragen. Zur Formatierung reicht ‚lang‘ mehr als aus. Bei anderen Themen (Sport, Politik), die sich häufiger ändern, kann eine "Zentrale" sinnvoll sein.
Hunderte von Vorlagen für Sprachen, die einzeln gepflegt werden müssen, bergen Gefahr der Vernachlässigung und Fehler. Wenn schon, dann eine einziger Eintrag in Vorlage:skzS: {{#invoke:lang|full}} würde mir locker ausreichen. LUA liest gerne alle Parameter aus dem {{skzS|para1|para2 ...}} bzw. {{lang|full|skz|para1|para2...}} als Direktaufruf und ab geht die Post.--Klaus-Peter16:37, 20. Nov. 2019 (CET)
Ich fragte oben »Rückfrage: Genau welche Aktivitäten auf enwiki sind mit „in etwa die Funktionalität mit der bei enwiki“ gemeint? Mir sind keinerlei annähernd gleichartigen bekannt.«
Ich wiederhole nunmehr meine Frage: An genau welcher Stelle der enWP willst du irgendeinen Transkriptions-Generator gefunden haben?? Die entsprechende Seite möchte ich jetzt gern verlinkt sehen.
Mir sind keinerlei Aktivitäten in dieser Richtung bekanntgeworden, erst recht nichts auch nur annähernd Vergleichbares.
„Die Engländer sind aus meiner Sicht schlanker und übersichtlicher.“ – Ja, wo denn überhaupt?? Da gibt es doch nichts Auffindbares???
Es sind die Autoren der Artikel, die darüber entscheiden, welches der verfügbaren Transkriptionssysteme sie schließlich für eine bestimmte Textpassage in einem bestimmten Kontext und historischer Einordnung im Artikel verwerten.
Selten mal wird man zwei Transkriptionen einfügen wollen; jedoch gibt es öfters eine volkstümliche und eine wissenschaftliche Umschrift; bei Gegenständen der Forschung sind durchaus mal drei und mehr Transkriptionen erwähnenswert. Es gibt abhängig von der Thematik gute Gründen, etwa bei heute lebenden Personen die eine Variante, bei Jahrtausende alten Textpassagen eine oder mehrere andere zu wählen. Du hast ersichtlich nicht die Kompetenz, da mal aus dem Handgelenk darüber zu entscheiden, „Deutsche Version und dazu eine 'Internationale'“ – du hast ja noch nicht mal die Vielseitigkeit des Wikyrill-o-mat und seine Bandbreite erkannt.
Aufgabe der Programmierung ist es, den Autoren eine möglichst große Auswahl anzubieten.
Dass du keinen Unterschied bemerkst, wenn du da nur mal eine Sequenz aus Unicode-Zeichen reinstopfst und noch nicht mal begreifst, warum das aus sprachlichen Gründen Unsinn ergeben muss, qualifiziert dich nicht dazu, sachkundige Urteile abzugeben, was du „bei Hebräern für entbehrlich halten“ würdest.
„Die Wikyrill-o-mat-Lösung ist aus meiner Sicht ausreichend“ – diese besteht darin, dass ein externes Tool aufgerufen wird, aus dem mit C&P ein konstantes Ergebnis in den Artikelquelltext einzufügen wäre.
Die Lua-Lösung verwendet die identischen Definitionen für kyrillisch, nur bedarf es keiner Fremdsoftware und das Resultat kann per Substitution direkt in den Quelltext übernommen werden.
Unmittelbar darauf widersprichst du dir selbst, fändest die Substitution als konstanten Quelltext nicht mehr gut, plädierst nun für „Da bin ich eher datenbankorientiert und frage flott mal eine kleine Tabelle ab“ – was die Anzeige jedes Artikels auf die folgenden Jahrzehnte an die korrekte Verfügbarkeit des Moduls binden würde. Du weißt erkennbar selbst nicht was du eigentlich meinst und willst.
Mein Eindruck ist, dass du nicht die leiseste Ahnung von dem hast, was du uns hier auftischst, und du nur irgendwelche „Damit baue ich mein mehrseitiges Weltbild auf“ zusammengedengelten Sprüche zusammenschiebst.
Archivierung dieses Abschnittes wurde gewünscht von: Die übliche Überheblichkeit des Antworters macht weiteren Dialog sinnlos --Klaus-Peter06:55, 21. Nov. 2019 (CET)
Aus der Nichtbeantwortung stelle ich fest:
Es wurde keine Verlinkung auf eine angeblich in der enWP vorhandene viel bessere Lösung mitgeteilt; trotz mehrfacher Rückfrage.
Es ist in der enWP auch überhaupt kein Lösungsansatz auffindbar.
Die 09:27, 20. Nov. 2019 suggerierte Behauptung, es gäbe eine uns überlegene Funktionalität in der enWP, die wir hier erst noch erreichen müssten, war demnach frei erfunden und diente offenbar nur dem Zweck, uns in der deWP niederzumachen und als rückständig hinzustellen.
Hallo, in LOTUS-Simulator wurde heute die bislang unbenutzte Vorlage:Computerspiel zum ersten Mal angewandt. Dabei trat ein cite-book-Vorlagenfehler auf, sodass der Artikel auch in einer WP-Wartungskategorie aufschlug. Ich sehe folgende Probleme mit dieser Vorlage:
Sie verursacht Vorlagenfehler und ist daher im ANR nicht einsetzbar.
Sie ist äußerst spärlich dokumentiert; was sie eigentlich tun soll, ist nicht wirklich klar („Einzelnachweise […)] formatieren, die aus Computerspielen stammen“ ?!?).
Ich schlage daher vor, diese Vorlage unverzüglich in den BNR des Erzeugers zu verschieben, damit sie dort – falls sie wirklich benötigt wird – überarbeitet werden kann. @Prime Blue: Würdest Du das bitte selbst tun? Danke u. Grüße, --rolf_acker (Diskussion • Beiträge • Logbücher) 13:54, 20. Nov. 2019 (CET)
Na ja selbsr wenn man die Pflichtangaben ausfüllen würde käme da nicht viel heraus. Ich weiß auch nicht wozu man sie verwenden können sollte.
{{Computerspiel |title=Titel |developer=Developer |publisher= Nintendo |date=2015-05-05 |platform=Plattform ??? DS |version=Version Text |scene=Szenerie??? |level=Level |language=englisch |quote=Hmm was auch immer}}
Ich habe auch den Ursprung gefunden, en:Template:Cite video game vermute ich mal stark. Was aber an einem Computerspiel nun Literatur sein soll muss ich nicht verstehen, aber die englische Wikipedia ist ja das Vorbild schlechthin, die müssen das ja wissen. Ich nehme mal deren Beispielangaben
Dieser Abschnitt kann archiviert werden. Gripweed (Diskussion) 23:37, 21. Nov. 2019 (CET): Danke sehr!
Vorlage BibISBN
Die Vorlage finde ich recht hilfreich. Leider ist die Ausgabe in einer Aufzählung unschön, wenn man den Parameter format=Hinweis nutzt, der mir doch nützlich erscheint. Auf meiner Spielwiese habe ich das mal dargestellt.
PS: Ihr dürft auch meiner Spielwiese gerne schreiben (was dieses Thema betrifft).
Leider weiß ich beim besten willen nicht was das Format Hinweis (bei einer Literaturzitation) sein sollte, ich bereits bereits vorhin an, dass ich nicht verstehe, was du dir unter einem „Format Hinweis“ vorstellen würdest. Ich kenne dieses Format bisher nicht in Zitationen.
@PerfektesChaos: Wird die komplette Vorlage langfristig sterben oder nur das Format mit "format=Hinweis"? Ggfls. entferne ich es aus den Atikeln (wo ich es ja selbst verbrochen habe). --tsor (Diskussion) 18:32, 24. Nov. 2019 (CET)
Nö, das System hat glaube ich 75.000 Einbindungen. Dem wird wohl so schnell nichts passieren.
Nur das Dokumentationsformat und das organisatorische Drumherum wird sich irgendwann mal ändern, und dann wird auch dieses Hinweis-format überflüssig.
Ich habe die zwei mal bereinigt, mir ist aber noch immer unklar wozu das mit dem auffälligen Kasten im Artikel gut sein sollte. --Liebe Grüße, LómelindeDiskussion18:57, 24. Nov. 2019 (CET)
Hallo, mir ist gerade etwas aufgefallen. In dieser Version der VM sehe ich bei #Benutzer:*thing goes ein unerwünschtes Verhalten der Benutzer-Vorlage, die ganz offensichtlich nicht mit dem Stern im Benutzernamen umgehen kann. Kann dieses Zeichen (ggf. auch die Raute) im Vorlagen-Code irgendwie maskiert werden? Grüße, Grand-Duc ist kein Großherzog (Diskussion) 22:43, 18. Nov. 2019 (CET)
CAParlbio - Website des kanadischen Parlaments hat sich umstrukturiert?
Hallo,
ich schreibe gerade eine Bio für eine neu Abgeordnete des kanadischen Parlaments. Dabei habe ich gesehen, dass bei anderen Abgeordneten die Vorlage CAParlbio verwendet wird (Nérée Arsenault, Iona Campagnolo). Allerdings führt die aktuell bei Aufruf zur Meldung, dass die Seite verschoben wurde. Es sieht so aus, dass das kanadische Parlament seine Homepage umgestellt hat.
Ich werde die Vorlage jetzt erst mal nicht verwenden. Aber vielleicht fixt das jemand?
alte URL http://www2.parl.gc.ca/parlinfo/Files/Parliamentarian.aspx?Language=E&Section=ALL&Item=35541ccf-8242-4f22-b82c-aebeef40d396
neu URL https://lop.parl.ca/sites/ParlInfo/default/en_CA/People/Profile?personId=11770 The Hon. Sir John Christian Schultz, Senator (ID 11770)
Die Umstellung auf die neuer URL bis zur ID wäre dabei kein problem, aber woher soll man die neue ID nehmen? Da müsste vermutlich jede Einbindung (342 Vorlageneinbindungen wurden ermittelt) angepasst werden, ebenso wie diese 14 ohne Vorlage.
So kann man das? Ich mach aber nichts mit WikiData, oder Properties. Ich arbeite hier und möchte auch hier die richtige ID sehen können. --Liebe Grüße, LómelindeDiskussion14:24, 17. Nov. 2019 (CET)
Tja. Ich habe die Vorlage jetzt auf generelle Wikidata-Einbindung umgestellt. Sobald die lokalen veralteten IDs aus den Artikeln entfernt wurden, kann man optionalerweise auch noch eine lokale Parameterübergabe aktivieren, falls der Wert aus Wikidata aus irgendwelchen Gründen nicht verwendet werden soll oder man alle IDs hart in die Artikel reinschreiben will. 2003:C9:6F2F:7700:89FE:8A5D:6E4B:E2BC14:26, 17. Nov. 2019 (CET)
@Hgzh: Wenn Inkobot Wikidata-API kann, so wäre es eine für alle Beteiligten günstigste Lösung, in Fällen bekannter Property die lange GUID zu ersetzen durch die P6616.
Generell ist das Problem, dass unterstellt wird, der Artikel, in dem die Vorlage eingebunden wäre, sei über exakt dieselbe Person wie das verbundene Item. Das dürfte zwar weitaus überwiegend zutreffen, muss aber nicht.
Nach einem Botlauf lassen sich die verbleibenden Auffälligkeiten mit IstZahl per Wartungskat identifizieren und Fehlermeldungen schreiben.
Vorteil: ID= bleibt Pflichtparameter, und wir können sogar rückwirkend abgleichen, falls es in den kommenden Jahren zu Vandalismus auf Wikidata käme. Wobei ein Abgleich aber wiederum unterstellt, dass ausschließlich einzige Vorlageneinbindung und Person und Item zueinander passen.
Da ließe sich aber nicht prüfen, ob da wirklich eine sinnvolle ID eingetragen wird. Habe zwar lange nichts mehr mit Wikidata gemacht, aber eine API-Query auf eine einzelne Eigenschaft sollte nicht allzu komplex sein. -- hgzh10:42, 18. Nov. 2019 (CET)
Ich werde die nächsten Tage nicht dazu kommen, aber prinzipiell machen könnte ich das schon. So eilig scheint es nicht zu sein, die Vorlage funktioniert ja erstmal. -- hgzh16:04, 26. Nov. 2019 (CET)
Mir gng es auch darum, ob der Abschnitt hier dann weg könnte. Deine Antwort ist aber ungenau, dass du es könntest hatte ich schon verstanden. --Liebe Grüße, LómelindeDiskussion16:56, 26. Nov. 2019 (CET)
Na wenn es schnell gehen soll... Bot ist durch. Hat auch erstmal nichts angemeckert von wegen doppelter Vorlageneinbindung oder falscher Wikidata-ID. Gruß, -- hgzh20:56, 26. Nov. 2019 (CET)
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)
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. --Wickie3720: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. NNW17: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. --Wickie3717: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? NNW17: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? --Wickie3718: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. NNW18: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. --Wickie3719: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. NNW19:04, 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... --Wickie3719:23, 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. NNW10: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. --Wickie3710: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. --Wickie3712: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. NNW12: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. --Wickie3713: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)
Wieviele Tage bis…?
Hi, ich bin Mathestheniker und brauche ein Vorlagenelement, dass mir die Zahl der verbleibenden Tage bis zum 8. Mai 2020 anzeigt (momentan: 98, inkl. 1 Schalttag) – und hinterher auch entsprechende Minustage. Gruß --Chiananda (Diskussion) 18:18, 30. Nov. 2019 (CET)
Hallo, in Triebwerksartikeln, die oft aus en:WP übersetzt werden, wird die Vorlage:Cvt zur Umrechnung von lbf zu kN ({{cvt | <Zahl> | lbf | kN}}) verwendet, was hier natürlich nicht funktioniert. Würde sich mglw. lohnen, eine hiesige Vorlage:Lbf2kN zu bauen. Gruß und Dank, --Wi-luc-ky (Diskussion) 22:59, 29. Nov. 2019 (CET)
Ganz grundsätzlich ist aber nichts gegen den Wuunsch einzuwenden, eine entsprechende Paarung lbf2kN und kN2lbf bereitzustellen; also nach dem Muster der {{PS2kW}} ganz analog, bloß halt mit den entsprechenden Faktoren und Einheitenkürzeln.
Ich sagte ja auch ich sehe keinen riesigen Bedarf, PS/kW hat immerhin rund 9000 Verwendungen nicht 29 mögliche Kandidaten. Ich kann das schon machen, es ändert aber eigentlich nicht wirklich etwas an der angesprochenen Problematik, denn die fragliche nicht existierende Vorlage heißt ja {{Cvt}}. Da weiß dann der Übersetzende trotzdem nicht, dass es eine Vorlage für diesen Zweck geben könnte. Das war die eigentliche Problematik, die ich hier sehe. Wenn sie gewünscht wird, werde ich das umsetzen, schließlich ist ja bald Weihnachten. --Liebe Grüße, LómelindeDiskussion07:25, 1. Dez. 2019 (CET)
Ja, passen beide sehr gut, Lómelinde! Ich danke euch, PerfektesChaos und Lómelinde, für Unterstützung und Umsetzung gleich beider VLs. Hoffen wir, dass die VLs bei Einbindung eine wohlwollende Aufnahme bei den Autoren finden. Und diese könnten betreffs Vorlage {{Cvt}} aus en:WP ja selbst hier vorstellig werden, falls Bedarf besteht.
An welcher Stelle ist eine Verwendung erstgenannter VLs denkbar? Warum sollen die VLs lt. Doku nicht im Fließtext verwendet werden? Also nur in Tabellen, Listen u. ä.? Gruß, --Wi-luc-ky (Diskussion) 12:13, 2. Dez. 2019 (CET)
Siehe →Vorkommen lbf/kN im ANR woher soll denn „ich“ wissen, wo so etwas gewünscht wäre, du hast doch den Wunsch nach dieser Vorlage geäußert. Wenn es dann doch keinen Bedarf gab, hätte ich mir die Mühe auch sparen können. Die andere Frage kann ich dir auch nicht beantworten, ich habe nur die Arbeitsanweisung befolgt.
@Wi-luc-ky: „An welcher Stelle ist eine Verwendung erstgenannter VLs denkbar? Warum sollen die VLs lt. Doku nicht im Fließtext verwendet werden? Also nur in Tabellen, Listen u. ä.?“
Die Fließtexte sollen möglichst einfach bearbeitet werden können, und dort sollen keine vermeidbaren kryptischen Vorlagenbezeichnungen auftreten.
Das gilt ganz allgemein für viele Vorlagen im Fließtextbereich; so auch für {{PS2kW}} usw.
Wenn es um das XY-Flugzeug etc. geht, dann wird dessen Länge einmalig angemessen gerundet von Fuß in Meter umgerechnet, und in den Fließtext-Abschnitt als Konstante reingeschrieben und vielleicht mit adäquat verlinkter Maßeinheit (Meter wäre noch bekannt; Fuß oder Hektar oder Pfund schon weniger) optisch hübsch dargestellt.
In Tabellen und Infoboxen werden die Angaben jedoch teilweise intern automatisch errechnet, teils für 50 gleichartige Objekte übernommen, und dort ist die ansprechendere Formulierung wie im laufenden Fließtext nachrangig, und Tabellen erfordern auch schon fortgeschrittenere Bearbeitungskenntnisse.
Meine 3 Fragen waren eigentlich nur 1 technischer Natur, zielten also auf die grundsätzlich erwünschte Verwendung ab, da in der Doku von der Fließtextverwendung abgeraten wird, wie dankenswerterweise von Dir, PerfektesChaos, erläutert. Dennoch Dank, Lómelinde, für den Link zu den Vorkommen für evtl. Weiterarbeit und natürlich für die Erstellung der Vorlagen – Deine Mühen waren keineswegs vergeblich!
PS: @Lómelinde: Eine Kleinigkeit bitte noch. Ist das gewollt, dass in der Doku der Vorlage:Lbf2kN #Beispiele und #Siehe auch am Ende, d. h. nach #Lua stehen, was da wie ein dazwischengeschobener Fremdkörper wirkt? (Sonst stand #Lua immer am Ende.) Ich konnte die Abschnitte aber nicht selbst tauschen, da ich die Konversionsdokumentation lbf2kN nicht gefunden habe. Analog in Vorlage:KN2lbf.
haben wir eine vorlage, die uns nur die klammerung eines lemma gibt? testen würde ich gerne, ob ein ort NK-regulär nach der verwaltungseinheit geklammert ist (es gibt mehrere orte des namen), oder nur mit "(Ort)" (wegen etwas anderem geklammert). --W!B: (Diskussion) 00:32, 26. Nov. 2019 (CET)
Na ja, ist doch eher ein Workaround als eine Lösung. Würde mal noch eine Einschätzung der Vorlagenwerkstättler*innen abwarten. Bin selbst interessiert, ob's da bereits was gibt... --rolf_acker (Diskussion • Beiträge • Logbücher) 12:00, 26. Nov. 2019 (CET)
Dann hier mal Vorlagenwerkstättler:
Diesen Fall hatten wir in einem Dutzend Jahren wohl noch nie.
Umgekehrt ist häufiger, und dazu haben wir auch eine vielfach eingesetzte Bibliotheksfunktion: Zeige das eigentliche Lemma, und schmeiß mögliche Unterscheidungs-Klammer weg.
Daher kein projektweites Interesse.
Da es für die Darstellung des Artikeltextes irreleant ist und keinen Einfluss darauf haben darf, auch keine Ambitionen.
Für eine reine Wartungsaufgabe verwenden wir heutzutage eher Cirrus-Funktionen; hastemplate: die und die Infobox, intitle:/\(/-intitle:/\(Landkreis/ oder was auch immer.
Damit lässt sich dynamisch rumspielen, und mal nach dieser und mal nach jener Konstellation suchen. Wenn für jede neue Idee die Vorlagenprogrammierung geändert wird und Orte meist einige Tausend Einbindungen haben, dann ist das Nerverei für die Server, die erst nach einigen Stunden die Kat zuverlässig gefüllt hätten, und die VG der Vorlagenprogrammierung wird zermurkst und die Wartungskat usw. stört andere Beobachter.
Einbindung eines Artikels als Vorlage führt zu Referenzfehler
Für die Lösung des folgenden Problems habe ich noch keine Lösung gefunden:
Wie z. B. auf den Seiten Fler oder Heintje zu sehen, führt die Einbindung der Seite "Diskographie" (Fler/Diskografie) als Vorlage dazu, dass aus der Vorlage übernommene Links zu Fehlern führen, wenn sie auf der Ursprungsseite mit Namen referenziert werden.
Sollte dann die Referenzierung auf der Ursprungsseite ohne Namen erfolgen oder gibt es eine andere Möglichkeit der Korrektur? (nicht signierter Beitrag vonPixelect (Diskussion | Beiträge) 22:21, 27. Nov. 2019 (CET))
Nun, das Verhalten ist natürlich keine Überraschung. Ich habe jetzt in den beiden Fällen die Hauptreferenz mit in die Charttabelle genommen, das müsste in Zukunft halt beachtet werden (wird aber meines Wissens für gewöhnlich ganz gut kontrolliert). Gruß–XanonymusX (Diskussion) 22:30, 27. Nov. 2019 (CET)
Es gibt eine Reihe von Infoboxen Musik, wie Musikalbum etc.. Die meisten sind sehr speziell ohne breite Anwendungsmöglichkeiten für Neue Musik, Orchestermusik, Jazznummer etc.
Relativ wichtig wären Infoboxen für
Komponisten
Sinfonien
Kammermusik
Orchesterwerke
Klavierwerke
etc.
Wir hier entscheiden nicht über die Auswahl der vorhandenen Vorlagen, eines jedoch schließe ich aus, eine Vorlage:Infobox Komponist wie (en:template:Infobox classical composer), denn das wäre eine Vorlage zu einer Person und die sind hierzuwiki weitestgehend unerwünscht. Es gibt sie auch nicht für Autoren, Wissenschaftler oder sonstige Berufsgruppen, einzige Ausnahme ist der Sportbereich. Daher ist auch die Vorlage:Infobox Person gegen Anlage gesperrt.
Zu Kategorie:Vorlage:Musik→Kategorie:Vorlage:Infobox Musik: Die Vorlagen sind für
KomponistenSinfonienKammermusikOrchesterwerkeKlavierwerke
etc.
unbrauchbar, super speziell. Absolut nischig, wenn man mal auf populäre Wettbewerbe sieht, die ich als reichlich unwichtig ansehe.
Ich meinte eher Infoboxen mit denen man das Musikrepertoire erschliessen kann.
--Guido Radig (Diskussion) 11:26, 3. Dez. 2019 (CET)
Na, eine etwaige Infobox Sinfonie dürfte deutlich „nischiger“ sein als etwa die Vorlage:Infobox Song. Wie oben korrekt erwähnt, ist eine Infobox für Komponisten in der deWP auszuschließen. Bei musikalischen Werken ließe sich sicher darüber diskutieren (in der Wikipedia:Redaktion Musik), die Infobox Song ist die aktuell einzige Vertreterin (Musikalben sind ja eher Veröffentlichungen und Opern eher Aufführungen). Man muss sich aber natürlich fragen, warum bislang niemand den Bedarf gesehen hat. Gruß--XanonymusX (Diskussion) 11:44, 3. Dez. 2019 (CET)
Es wäre viel einfacher, wenn dies oben in der Editorleiste automatisch aufgeklickt werden könnte, wie bei Belegen oder Links.
Wie ist dazu Eure Meinung?
--Guido Radig (Diskussion) 16:58, 2. Dez. 2019 (CET)
Aber genau das kannst du mit dem visuellen Editor doch tun. Wähle dafür Einfügen → Vorlage → gib in die Eingabebox Zitat ein →Hilfe:Vorlagen/VisualEditor. Das kann zudem auch nicht von der Vorlagenwerkstatt realisiert werden, das ist Softwaretechnik. --Liebe Grüße, LómelindeDiskussion17:09, 2. Dez. 2019 (CET)
Danke Dir .... tja die Software ist da rel. umständlich - siehe: "Der Text ist unverständlich, es sind keine Belege vorhanden."
Der Editor könnte einfach beinhalten: Zitat, Name, Jahr, Quelle
Wenn du das genau so machst wie ich es dir hier beschrieben habe öffnet sich ein Dialogfenster in das du all diese Angaben einfach nur einfügen musst. Da gibt es die Parameter Text, Autor, Quelle, Einzelnachweis und bei Bedarf kannst du noch über „Weitere Informationen hinzufügen“ die optionalen Parameter hinzufügen, das ist nicht wirklich kompliziert. Also oben in der Editorleiste Einfügen → Vorlage → und „Vorlage:Zitat“ übernehmen (oder falls es ein fremdsprachiges Zitat ist, eine der anderen Zitatvorlagen auswählen), dann alles ausfüllen und speichern. Wo genau soll ich sehen „Der Text ist unverständlich, es sind keine Belege vorhanden.“ ? Ich kann doch „deine Bearbeitung auf deinem Bildschirm“ nicht einsehen. Ich verstehe dein Problem jetzt nicht wirklich. Fragen zum visuellen Editor stellst du aber an sinnvollsten auf →Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen. Ob man dir da aber mehr sagen kann als ich es versucht habe weiß ich nicht. --Liebe Grüße, LómelindeDiskussion18:19, 2. Dez. 2019 (CET)
Ich habe mal eine Wartung eingebaut. unter dieser Abfrage sind alle Einbindungen mit einer ID unter 3.000.000 gelistet. Da sind zwar auch ein paar falsche Treffer dabei, aber die meisten veralteten sind wohl erfasst. ÅñŧóñŜûŝî(Ð)16:29, 7. Dez. 2019 (CET)
@Wurgl: Das müsste man wohl manuell alles abändern. Bei noch ca. 200 Artikeln viel Arbeit. Ich wäre da aber vorsichtig. Ich habe den Eindruck, dass bei dieser Webseite sehr darauf geachtet wird, dass niemand per Bot etc. wesentliche Datenmengen abgreifen kann. Eine der Strategien besteht oft darin, die URLs regelmäßig zu ändern. Kann also sein, dass ein manuelles updaten nur kurz Erfolg hat. ÅñŧóñŜûŝî(Ð)20:34, 11. Dez. 2019 (CET)
Kann durchaus sein. Vielleicht ist bei den Kollegen der enWP irgendwas zur Seite bekannt. Ich finde dort die Vorlage nur mit Ids die mit einer 4 beginnen. --Wurgl (Diskussion) 21:10, 11. Dez. 2019 (CET)
@Wurgl: Sieht nicht danach aus, als ob man da weiter ist. Muss man wohl manuell machen. Ich habe ca. 50 abgearbeitet. Würdest du auch einige erledigen? Ich mache das so (Firefox-Browser):
Von den Einträgen ca. zehn in einem neuen Browsertab in den Bearbeiten-Modus bringen.
Für jeden Artikel:
Den Namen komplett in die Zwischenablage kopieren.
In der Infobox das Geburtsjahr nachlesen.
In der Suchmaske den ganzen Namen in das Feld "Nachname" einfügen. Treffer werden sofort angezeigt.
NICHT anklicken sondern das Linkziel per Kontextmenü in die Zwischenablage kopieren
Im Artikel die Vorlageneinbindung suchen und die alte ID durch den Inhalt der Zwischenablage ersetzen, anschließend die URL mit ausnahme der ID am Ende entfernen.
Abspeichern
Sind die zehn durch, kannst du, wenn du noch Lust hast, die nächsten Tabs öffnen. Bei asiatischen und osteuropäischen Personen kann der Name bei Swimrankings abweichen. Im Artikel steht dann aber oft die internationale Transskription.
Sorry, war heute zu beschäftigt. Aber ich guck mal, ob ich da was Halbautomagisches basteln kann. Den AJAX-Zugiff in der Suchmaske kann man ja nachbasteln, kommt nur darauf an, was die sonst noch an Umfeld benötigen. Cookie, Referer, User-Agent etc. --Wurgl (Diskussion) 00:35, 16. Dez. 2019 (CET)
Hallo, bei konkreter Anwendung in den einschl. Artikeln (Wasserstoff ff.) hängen Symbol und Ordungszahl unterhalb des Miniperiodensystem in die nächste Zeile namens „Allgemein“ hinein. Bedürfte wohl einer Leerzeile o. ä., aber wo…? Gruß und Dank, --Wi-luc-ky (Diskussion) 00:02, 20. Dez. 2019 (CET)
Das liegt vermutlich an der zuletzt erfolgten Änderung →Spezial:Diff/192244531/194555896 frag mal Antonsusi ob die zwei Pixel gewinn wirklich so vorteilhaft wären, wobei ich nicht einmal sehe wo da zwei Pixel gewonnen wurden. Aber eine Layoutverschiebung sollte vermutlich nicht erfolgen. Vorher war übrigend das Symbol innerhalb der Grafik. Warte ich zeige es mal.
Die bisherige Minigrafik war so klein, dass man große Mühe hatte, die einzelnen Tabellenzellen und damit die Links mit der Maus richtig zu treffen. "Zwei Pixel mehr" bezieht sich auf die Breite der anklickbaren Fläche einer Tabellenzelle. Das habe ich aber auf eine andere cWeise realisiert. Insoweit ist meine Änderung inzwischen nicht mehr nötig. Ich habe sie daher zurückgenommen. Jetzt müsste es passen. ÅñŧóñŜûŝî(Ð)15:28, 21. Dez. 2019 (CET)
@Lómelinde, Wi-luc-ky: Einer der Gründe für die Umstellung war auch, dass - wie ich heute festgestellt hatte - der Text mit seinem Randbereich (Unterlänge) die Tabelle überlappt hatte und einige Zellen nicht mehr anklickbar waren. Ich habe das durch Justieren der Positionen und vor allem durch Verringern der Zeilenhöhe behoben. ÅñŧóñŜûŝî(Ð)17:18, 21. Dez. 2019 (CET)
Ich käme ehrlich nicht einmal auf die Idee diese kleinen Kästchen anklicken zu wollen. Ich hatte nur versucht die Ursache für den Darstellungsfehler zu ergründen. Und da schaut man ja zuerst einmal bei den zuletzt erfolgten Änderungen nach. --Liebe Grüße, LómelindeDiskussion17:28, 21. Dez. 2019 (CET)
Ausgangspunkt ist der Artikel Alarmstange (Berg), bei dem ein Fehler in den Einzelnachweisen angezeigt wird. Man beachte, dass dieser Artikel zuletzt am 15. Oktober 2019 geändert wurde, die Fehlermeldung aber erst in den letzten Tagen auftrat. Benutzer:Wurgl hat ein wenig analysiert und meint, der Fehler werde durch die genannten Vorlagen verursacht. Könnte sich das mal jemand näher ansehen? Gruß --tsor (Diskussion) 10:00, 20. Dez. 2019 (CET)
Ich vermute mal es liegt eher daran, dass die {{GeoQuelle}} an sich schon ein ref-erzeugt und diese hier nun zusätzlich in ein ref eingebunden wurde, also doppelt gemoppelt. Beispiel.[1] erzeugt ein Ref<ref name="Scharte" /> hingegen erzeugt ein ref mit dem sichtbaren Inhalt Nördlich der Ortsmitte von Siershahn N und hier fehlt dann der Inhalt der GeoQuelle siehe Alarmstange_(Berg)#Einzelnachweise (Beleg 2)
<ref name="Scharte">
Nördlich der Ortsmitte von Siershahn {{GeoQuelle|DE-RP|LANDIS-Karte}}
</ref>
Da kann man an den Vorlagen selbst nicht viel machen, das ist, meiner Meinung nach ein Einbindungsfehler. Die Infobox wurde gestern bearbeitet (also nicht dort geändert, aber bearbeitet) mag sein, dass das dazu führt, dass der Fehler nun gelistet wird, mag aber auch sein es war vor Kurzem Donnerstag und es gab irgendein Update, was diesen Fehler jetzt sichtbar macht. --Liebe Grüße, LómelindeDiskussion10:44, 20. Dez. 2019 (CET)
Im Artikel ursächlich ist: <ref name="Scharte">Nördlich der Ortsmitte von Siershahn {{GeoQuelle|DE-RP|LANDIS-Karte}}</ref>
Diese erzeugt ein <ref>-im-<ref>.
Das war schon immer unerlaubt gewesen und erzeugt eine Fehlermeldung.
Weil: <ref name="Scharte">Nördlich der Ortsmitte von Siershahn<ref>Kartendienst des Landschaftsinformationssystems der Naturschutzverwaltung Rheinland-Pfalz (LANIS-Karte) (Hinweise)</ref></ref>
Die Auslösung der Fehlermeldung ließ sich bisher mittels #tag:ref austricksen; deshalb wohl so in Vorlage:GeoQuelle/Ref1. Ansonsten gibt es keinen Grund, warum in dieser Untervorlage #tag:ref statt <ref> verwendet wird.
Seit einigen Wochen wird die ein Jahrzehnt alte Programmierung der für <ref> zuständigen Extension von Grund auf überarbeitet, schlauer gemacht und viele Schlupflöcher, Lücken und Unsauberkeiten der ersten Programmierung eliminiert.
Wenn jetzt ein Artikelquelltext, dessen Darstellung bisher im Cache schlummerte, aus irgendwelchen Gründen erneut durch den Parser läuft, etwa weil eine andere eingebundene Seite sich verändert haben mag, oder ein purge ausgelöst wurde, dann wird der seit langer Zeit bestehende Fehler jetzt entdeckt.
Dass ein nicht geänderter Artikel jetzt auf einmal in der Wartungskat aufschlägt wird also demnächst regelmäßig zu erwarten sein.
Aus dem Artikel wurde das Dingens jetzt kurzerhand ganz rausgelöscht.
In der Doku zu Vorlage:GeoQuelle sollte die unzulässige Verwendung erwähnt werden.
Nichtsdestotrotz sollte ein Kundiger die Vorlagen GeoQuelle & Co entsprechend reparieren. In Elpe (Fluss) und Hainbach (Woogbach) sehe ich ebenfalls solche Fehlermeldungen, beide Artikel verwenden innnerhalb der Einzelnachweise diese Vorlage. --tsor (Diskussion) 13:30, 20. Dez. 2019 (CET)
Wir können an den Vorlagen nichts „reparieren“.
Die Aktion war schon immer unerlaubt gewesen; nur wurde mit der Austricks-Syntax in Vorlage:GeoQuelle/Ref1 die normalerweise ausgelöste Fehlermeldung unterdrückt, weil die historische Programmierung damit nicht gerechnet hatte und es nicht finden konnte.
Die neue Programmierung findet das jetzt aber trotzdem, egal ob es versteckt wäre oder nicht.
Nebenbei ändert sich seit Anfang Dezember auch die Parser-Programmierung; das System wurde umgestellt von Parsoid-JS auf Parsoid-PHP. Auch das hat auf die Verwaltung der gefundenen Tags und deren Syntax und die Inhalte der Elemente Einfluss.
Auf humane Art und ohne Informationsverlust das ref aus dem ref herausoperieren.
Das hier war die brachiale Methode mit kompletter Löschung.
Ggf. das dynamische Ziel der Quelle selbst verwenden. Ich habe noch niemals was mit dieser Vorlage zu tun gehabt, aber mit ohne Parameter wird ein ref erzeugt, während ref=nein dies unterdrücken solle.
@Lómelinde: Schreit sicherheitshalber nach faculty.
Ich kenne die Vorlagen so auch nicht, wegen faculty kann ich mal schauen, war mir vorhin auch gleich ins Auge gesprungen. Nur mag ich solche Schachtelvorlagen eigentlich gar nicht. Allein schon weil ich erst suchen muss, wo ich es einfügen müsste. --Liebe Grüße, LómelindeDiskussion15:39, 20. Dez. 2019 (CET)
Mit ref=ja in einer Referenz gibt es keinen Treffer.
Wenn das Ding in einer anderen Vorlage oder gar in einer Tabelle ist und diese in einer Referenz … das kann mein Tool nicht finden, die Daten hab ich nicht. --Wurgl (Diskussion) 16:00, 20. Dez. 2019 (CET)
WD-basierte Infoboxen für Artikel zu Bibliotheken, Archiven und Museen
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.
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.
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?
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.
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.
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.
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.
Grundprinzip wäre, dass entweder bei uns oder bei Wikidata eine ISIL oder sonst eine statische Information vorliegt, und diese der anderen Seite ggf. nach Prüfung übermittelt wird. Haben beide eine Information und diese unterscheidet sich, läge Vandalismus nahe.
Es scheint auch viele Institutionen zu geben, die keine ISIL haben; etwa Neue Stadtbücherei Augsburg. Dabei geht es jedoch wohl nicht nur um kleine örtliche oder private Einrichtungen, sondern die Ägyptische Nationalbibliothek hat per d:Q2778411 auch keine. Obwohl es „International“ heißt, haben offenbar eine Reihe von Institutionen jeweils nationaler Bedeutung keine.
Wenn nennenswerte internationale Institutionen dauerhaft keine ISIL haben, weil das anscheinend eher eine europäisch zentrierte Mode ist, dann ist die derzeitige Abfrage auf fehlende ISIL allerdings nicht mehr zielführend. Das ergab sich jedoch erst durch Anlage jener Kategorie, die sich irgendwer gewünscht hatte.
Was da mit diesem Beobachtungs-Feature ist, weiß ich nicht und ist mir mittlerweile auch egal.
Es war jedenfalls mindestens fünf Jahre lang in einem unbrauchbaren weil jede Beobachtungsliste mit täglich Hunderten unwichtiger Aktivitäten flutenden Zustand, die sich nicht sinnvoll aktivieren ließ, aber immer und permanent als Alibi vorgetragen wurde: Ihr braucht ja nur ein Häkchen zu machen, dann seht ihr auch alles, was sich da auf Wikidata tut und könnt Vandalismus zurücksetzen. Nee, konnte man nicht, weil Bildschirmkilometer voll Gedöns. Und nachdem dieses Märchen fünf Jahre lang immer und immer wieder dreist erzählt wurde, hat mittlerweile kein normaler Autor mehr Lust, dieses Häkchen in Betrieb zu nehmen; dieses Thema ist verbrannt und verleidet.
Es ändert auch nichts an der Problematik, dass damit maximal diejenigen Veränderungen in unseren Artikeln auffallen könnten, zu denen noch ein Beobachter (damaliger Hauptautor) aktiv und am Leben ist und diesen einen Artikel laufend beobachten würde. Bei allen anderen Artikeln fänden die Veränderungen in der Darstellung durch Wikidata von uns unbemerkt statt. Hingegen muss jede Veränderung an unseren Artikeln und darin eingebundener Informationen durch uns nicht längere Zeit bekannte Personen zuerst ein Placet der Sichter bekommen, selbst wenn null Personen einen Artikel beobachten würden.
Dass hier größere Mengen an Autoren dafür gewonnen werden könnten, nun ständig Wikidata auf Vandalismus zu beobachten bezweifele ich. Wir sind hier alle sehr gut ausgelastet und niemand braucht zusätzliche Aufgaben und Ablenkung.
Was mir missfällt ist die Attitüde der diversen Wikidata-Missionare, die regelmäßig hier bei uns aufschlagen. Wir bringen euch jetzt Infoboxen und Daten, damit ihr auch mal was habt. Und wir nisten uns gleich mal in euren Projekträumen ein und legen ungefragt Vorlagen oder Module oder sonstwas an. Die Vorlage:Infobox Bibliothek etwa gibt es seit 2006 – wo war 2006 denn Wikidata gewesen? Der Grundstock für Wikidata wurde aus Wikipedien gelegt, und auch heute noch dürfte ein wesentlicher Anteil neuer Informationen für Wikidata von Wikipedien und Wikipedianern stammen.
@ "Flutung" durch irrelevante Edits sollte mittlerweile behoben sein
Ich hatte jetzt am Wochenende mal spaßeshalber die WD-Beobachtung aktiviert.
Nach einem guten Stündchen kam d:Special:Diff/1059924973 und das ist genau das, was mich nicht die Bohne interessiert und auch absolut null mit dem Inhalt unseres Artikeltextes zu tun hat.
Das ist genau der Mist, der seit sechs Jahren unsere Beos vollbrabbelt.
Die Story, da wäre angeblich irgendwas entschärft worden und auf unseren Beos würde nur noch erscheinen, was unseren Artikel beeinflussen würde, ist also weiterhin ein Märchen.
Solange das so bleibt, ist es ein wertloses Alibi, dass wir auf unseren Beos ja alle relevanten Veränderungen auf Wikidata überwachen könnten.
Hallo zusammen, JackPilot hat gerade die Seite ISO 2848 neu übersetzt und dabe festgestellt, dass die Vorlage:Einheitenumrechnung nur bei der Vorschau funktioniert. Um diese richtig im Arbeitsraum nutzen zu können, muss "Einheitenumrechnung|" weggelassen werden. Bitte JackPilot ggf Ergänzungen. Bitte Beschreibung oder Vorlagenänderung--Vielen Dank und Grüße Woelle ffm (Uwe) (Diskussion) 15:41, 25. Nov. 2019 (CET)
Den Overhead einer Vorlage zu benutzen, um einen fixen Wert in einen anderen fixen Wert umzurechnen, ist auch nicht wirklich sinnvoll und trägt nicht zur Lesbarkeit bei. --Magnus(Diskussion)15:46, 25. Nov. 2019 (CET)
Deshalb ist dies auch keine Vorlage im klassischen WP-Sinn, sondern eher ein Tool, welches die Umrechnung vereinfachen soll, wenn man z. B. Texte von en:WP übertragen will. Steht alles in der Beschreibung der Vorlage. ÅñŧóñŜûŝî(Ð)16:02, 25. Nov. 2019 (CET)
Es wäre ganz sinnvoll, wenn die Vorlage (bzw. Vorlage:Konvert, die von Vorlage:mm2in aufgerufen wird) vor die Zieleinheit ein typographisch schmales Leerzeichen anstelle eines geschützten Leerzeichens setzen würde. Das geht mit Vorlage:nnbsp, beim Kopieren ist der Effekt (mittlerweile) derselbe. Würde ich ja selber einbauen, leider ist die Vorlage gesperrt. --95.116.50.17816:21, 25. Nov. 2019 (CET)
Zur letzten Bemerkung: Nö, das Dings rechnet nur Zahlenwerte aus, mehr nicht.
Durch die Hintertür den Quelltext aufzublähen und eine wenig akzeptierte Vorlage zwangsweise einzuschmuggeln ist nicht sauber.
Es ist Sache des Anwenders der Einheitenumrechnung, anschließend beim Übertragen des Ergebnisses nach eigener Entscheidung zu verfahren. Wenn das Teil substituiert wird, was man wohl im Prinzip machen kann, und sich die Substitution auf die eingeschmuggelte nnbsp auswirkte, gibt das ein Quelltext-Desaster.
Wir verwenden möglichst einfachen und für viele Autoren verständlichen Quelltext, und deshalb bei der Angabe von Zahlen das eine und einzige Zeichen für alles, und selbst das wird nicht von jedem Autor akzeptiert. Jetzt noch eine zusätzliche Vorlage macht es für Visual-Editor- und weniger technikaffine Autoren noch schwerer, auch nur die Größe eines Stadtparks anzugeben und zu korrigieren.
@PerfektesChaos: Eben drum soll das Zeichen ja in die Vorlage, damit nicht jeder Autor immer wieder {{nnbsp}} hinschreiben muss (und überhaupt wissen muss, dass es das gibt und wann man es einzusetzen hat). Konkreter Fall (deswegen habe ich es hier erwähnt): In ISO 2848 stehen nun Dinge wie Ein Metrischer Zoll ist {{mm2in|0.4|3}} kürzer als ein [[Zoll (Einheit)|angloamerikanischer Zoll]]. Dem Nutzer der Vorlage:mm2in ist es schnurz, ob die ein geschütztes oder ungeschütztes oder schmales Leerzeichen verwendet (und ob das über eine Vorlage namens nnbsp passiert oder auf andere Weise), aber wenn in der Vorlage das schmale Leerzeichen steht, hat man überall bei ihrer Verwendung für lau typographisch korrekte Einheitenanbindungen. Deine Ausführungen kann ich daher nicht nachvollziehen:
Wie umfangreich der Quelltext nach Vorlagenauflösung ist, kümmert allenfalls den Parser (und die Hamster), nicht aber doch den Artikelautoren. Und ebenso wenig sollte es ihn kümmern müssen, wie die Vorlage intern realisiert ist.
Dass es eine Vorlage gibt, die nur Einheitenumrechnung macht und an die der Nutzer (der ggf. wieder eine Vorlage sein kann) dann selbst die Einheit (mit geeignetem Leerzeichen) anzuhängen hat, halte ich ja für sinnvoll. Wenn die Vorlage aber eine Einheit anhängt, und das tut Vorlage:mm2in mit den Millimetern (und mir schien, mit den Inches würde Vorlage:Konvert das tun, aber das war wohl ein Irrtum – aber wo kommen die bloß her, im Quelltext finde ich sie nicht), dann kann (und meiner Meinung nach: soll) sie das doch typographisch korrekt machen.
„Wir verwenden möglichst einfachen und für viele Autoren verständlichen Quelltext“ ist bei Vorlagenprogrammierung offensichtlich nicht der Fall, guck dir die Vorlage an. Frohes Zählen geschweifter Klammern. Schlimmer als LISP, der Kram. Den VE benutze ich aus Prinzip nicht, daher weiß ich nicht, wie das da mit den Vorlageneinbindungen läuft, aber den weniger technikaffinen Leuten ist auch geholfen, wenn sie Vorlagen benutzen können, die die Komplexität vor ihnen verbergen (bzw. ihnen auch ersparen, bestimmte Dinge immer wieder einzugeben, das ist ja der ursprüngliche Sinn von Vorlagen).
Ich gehe mal davon aus, dass dein Kommentar sich auch teilweise auf das mit Vorlage:Konvert bezog, das war, wie gesagt, ein Irrtum – dort, wo Einheiten ausgegeben werden, kann die Vorlage das gleich typographisch korrekt tun, aber dort, wo keine Einheiten ausgegeben werden, braucht man sich um die natürlich keine Gedanken zu machen. --95.116.50.17820:54, 25. Nov. 2019 (CET)
Wie groß und breit und rot dransteht, wird die Vorlage:Einheitenumrechnung in überhaupt keinerlei Artikel eingebunden, sondern da wo das ggf. mal geschehen wäre müsste sie substituiert werden.
Sie ist nur ein Werkzeug, um einmalig eine fremde Zahlenangabe umzurechnen und das Ergebnis anschließend in den Quelltext des Artikels hineinzuschreiben.
Das Begehren 16:21, 25. Nov. 2019 zielte jedoch darauf ab, diese nnbsp-Vorlage mit in das dargestellte Resultat von Vorlage:Einheitenumrechnung aufzunehmen und auf diesem Weg in den Quelltext des Artikels hineinzuschmuggeln, weil die Vorlageneinbindung damit im Resultat der Umrechnung sichtbar auftauchen würde.
In diesem Wiki wollen wir die Größe eines Blumenbeetes noch für Normalsterbliche bearbeitbar angeben, und deshalb zwischen Maßzahl und Einheitensymbol weder ein {{nnbsp}} noch ein   noch ein   zu stehen haben; wenn überhaupt irgendein Umbruchschutz, dann ausschließlich für alles und sonst nix.
Und nein, wir wollen auch nicht jede Angabe einer Größe oder Länge oder sonstwas in irgendwelche Vorlageneinbindungen verstecken, mit der sich dann jeder nachfolgende Autor herumärgern muss, sondern dies offen und verständlich und im Klartext sehen.
Du hast ganz offensichtlich nicht verstanden, wofür Vorlagen gut sind, und noch weniger, worauf ich hinauswollte. Insofern bin ich mit EOD einverstanden. Ich werde dann mal demnächst eruieren, wo das „in“ bei Vorlage:mm2in herkommt, und auch dort das schmale Leerzeichen einfügen – ganz ohne dass irgendein normalsterblicher was davon mitbekommt, geschweige etwas dadurch für ihn unbearbeitbar würde. Das ist übrigens keine Ankündigung von WP:BNS, weil ich, wie gesagt, niemanden damit stören werde. --95.116.50.17800:00, 26. Nov. 2019 (CET)
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)
Möglich schon, stelle ich mir aber nicht besonders schick vor. Und das sollte am Besten nochmal irgendwo abschließend diskutiert worden sein. -- hgzh23:21, 26. Nov. 2019 (CET)
Eine Frage zur Möglichkeit des Spalten-Verschmälerns
… bei der Vorlage:Fußballtabelle habe ich dort gestellt, worauf ich auch hier gerne aufmerksam machen möchte, weil auf der dortigen Disku Fragen von 2017 und 2018 noch unbeantwortet wirken. Dankbar für jeden Tipp: --WwwurmParoles, paroles15:51, 23. Dez. 2019 (CET)
In der Vorlage:Fußballtabelle/Kopf sind die Spaltenbreiten fest eingetragen. Wer es ändert könnte Ärger mit anderen Anwendern bekommen. -- Also UNMÖGLICH. Möglich wäre es, eine eigene Tabelle mit gleichem Strickmuster und anderen Spaltenbreiren zu erstellen.--Klaus-Peter16:28, 23. Dez. 2019 (CET)
Auf solche unsinnigen Vorlagen einfach verzichten und die Tabellen selbst bauen. Dann ist man nicht durch solche Designvorgaben eingeschränkt und ganz nebenbei wird der Quelltext auch leichter und flexibler bearbeitbar. -- Chaddy · D16:33, 23. Dez. 2019 (CET)
Unsinn hin und her, manche Vorlagen bieten ja auch echte Hilfen bei der einheitlichen Darstellung. Im vorliegenden Fall habe ich mir mal den Code kritisch angesehen und mache folgenden Versuchsvorschlag:
Kopf durch einen selbst erstellten Tabellenkopf mit der selben Spaltenaufteilung, aber angepassten Breiten erstellen -- Tabellenfragment unten unbedingt offen lassen, also ohne|}
Theoretisch ginge das schon, denn Vorlage:Positionskarte Namibia exisitiert glücklicherweise bereits. Dennoch wäre hier einiges an Arbeit erforderlich, denn das bisher der Infobox übergebene Koordinatenformat (einfacher Text) ist für die automatisierte Auswertung innerhalb einer Positionskarte völlig ungeeignet. Zudem: soll die Positionskarte die bisherige Lagekarte ersetzen oder zusätzlich ergänzt werden? Generell sieht es mir danach aus, dass die gesamte Infobox eine grundlegende Überarbeitung sowohl in der Programmierung als auch im Layout benötigt – und das ist keine Aufgabe, die man mal eben erledigt. -- hgzh23:17, 26. Nov. 2019 (CET)
Wie ihr vermutlich mitbekommen habt, wurde dieses Jahr das Thema “Leichter mit Vorlagen arbeiten” als Themenschwerpunkt für die Arbeit des Teams Technische Wünsche bei Wikimedia Deutschland gewählt. Bis Anfang 2020 soll ermittelt werden, welche Verbesserungen darin umgesetzt werden sollen. Als erster Schritt dazu wurden bestehende technische Probleme gesammelt. Die Ergebnisse davon sind nun auf der Projektseite zu sehen. Feedback dazu ist wie immer gerne auf der Diskussionsseite gesehen. -- Michael Schönitzer (WMDE) (Diskussion) 17:53, 19. Nov. 2019 (CET)
"Expansion depth limit exceeded"
Zum Artikel Chorda dorsalis gehört an dieser Stelle ein ziemlich großes Kladogramm. Heute musste ich feststellen, dass die rechte Seite des Kladogramms nicht mehr dargestellt wird. Stattdessen erscheint haufenweise die Fehlermeldung „Expansion depth limit exceeded“ (zumindest in den Browsern Chrome und FireFox).
Was kann da getan werden? Vielen Dank für Eure Tipps, --Dreisam (Diskussion) 20:23, 29. Nov. 2019 (CET).
Bedeutet Dein Hinweis, dass alle Kladogramme durch Grafiken ersetzt werden sollten/müssen? Aus meiner Sicht wäre das sehr schade, weil sich (zumindest in der systematischen Biologie) die Kladogramme noch immer ständig ändern.--Dreisam (Diskussion) 10:11, 30. Nov. 2019 (CET)
„Mach mehrere daraus.“ (Wurgl) – Vermutlich wird mir kaum etwas anderes übrig bleiben. Allerdings habe ich auf der Vorlage:Klade zudem folgenden Satz lesen müssen: „Diese Vorlage sollte in keiner anderen Kategorie außer Kategorie:Vorlage:Veraltet stehen, damit sie möglichst schnell verwaist. Sobald sie nicht mehr verwendet wird, kann ein Löschantrag für diese Vorlage gestellt werden.“ – Ohne nachgezählt zu haben, scheinen mir in unseren biologischen Lemmata hunderte von Kladogrammen verbaut zu sein. Sind die alle gefährdet? Beziehungsweise was soll jener Hinweis überhaupt bewirken, wenn der angestrebte Zeitpunkt des Verwaisens niemals eintreten *kann*? Aber danke.--Dreisam (Diskussion) 10:34, 30. Nov. 2019 (CET)
@Dreisam: Die konkreten Fehlermeldungen „Expansion depth limit exceeded“ können nur bei sehr tief verschachtelten Strukturen auftreten.
Vermutlich gibt es dort zwanzig Ebenen.
Jede Ebene zieht in der aktuellen Programmierung wohl zwei Vorlagen-Verschachtelungen nach sich, meine ich mich zu erinnern; diese sind absolut und zum Schutz des Servers auf 40 begrenzt.
Durch einen uns nicht ganz verständlichen und auch nur hin und wieder auftretenden Effekt werden neuerdings bereits bei 39 Vorlagen-Verschachtelungen die Limitierungen ausgelöst; es scheint zuweilen eine weitere Ebene oben drüber konsumiert zu werden, so dass nur 39 drunter überbleiben.
Kladogramme, die jahrelang darauf ausgelegt wurden, genau bis an das Limit von 40 zu gehen, brechen deshalb noch vor ihrem Nirwana-Level ab.
Für diese Riesenteile bleibt tatsächlich, wie Wurgl anriet, nichts anderes als den oder die Zweige, die an das Limit stoßen, auszugliedern und wieder bei Null anzufangen; dafür kann dort ja jetzt noch tiefer gegangen werden.
Grundsätzlich sind solche Riesen-Kladogramme keine Freude für die Leser.
Aber nett für die Autoren, die das rausgefummelt hatten.
Die gesamte momentane Technik basiert auf trickreicher Textgestaltung.
Es ist relativ erstaunlich, dass diese Linien bis heute in HTML noch sauber zusammenpassen.
Generell ist dieses Verfahren aus technisch-strategischer Sicht aber nicht sehr zukunftsfähig.
Das hat offenbar irgendwen mal dazu bewogen, diese „Veraltet“-Box reinzusetzen und den Umstieg auf sichere grafische und dann in der Tiefe auch nicht mehr begrenzte Verfahren anzuraten.
Es gibt aber bisher weltweit keine vollkompatible robuste grafische Ersatzlösung, und deshalb ist das nur eine stille Mahnung, aber mit wenig praktischen Konsequenzen.
Idealerweise würde die Struktur bei Benutzern mit aktiviertem JavaScript teilweise eingeklappt sein, auf Wunsch komplett oder aber Zweig für Zweig weiter entfaltet werden, oder Knoten für Knoten interaktiv wieder eingeklappt werden. Eine echte Grafik könnte sogar gezoomt werden. Das ist programmierungstechnisch mit einem Nachfolgemodell möglich, aber hat noch keiner geschrieben und innerhalb der Grafik auch anklickbare Links auf Artikel und dynamische Klappmechanik sind auch nicht trivial. Bräuchte wohl eine gesonderte PHP-Extension.
Danke, PerfektesChaos, dass Du eine ausführliche Antwort für mich geschrieben hast. Ich bin inzwischen tätig geworden, habe mein ehemaliges Riesenkladogramm aufgespaltet und hier in zwei separaten Teilen neu zusammen montiert. Ehrlich gesagt scheint mir das Ergebnis weitaus übersichtlicher auszusehen und es erweist sich vermutlich auch als pdf-freundlicher. Darüber hinaus kommt die neue, aufgezwungene Verzweigungstiefenbegrenzung für mich als Autor nicht ganz ungelegen. Denn je größer die Kladogramme wurden, desto mehr Fehler schrieb ich bei ihrer Erstellung in den Code hinein. Manchmal benötigte ich viele Anläufe und gute Nerven, bis die Darstellung endlich klappte. Wirklich verflixt! Derlei Probleme werde ich zukünftig jedoch mit generell kleineren Kladogrammen nicht mehr haben.--Dreisam (Diskussion) 17:54, 30. Nov. 2019 (CET)
Etwas offtopic: @Dreisam: Magst du bitte auf Peripatopsidae gucken? Dort ist eines mit 23 Untergruppen, die Vorlage kann aber nur 20. "Vescerro" und das doppelte(??) "Wambalana" werden nicht angezeigt. --Wurgl (Diskussion) 18:04, 30. Nov. 2019 (CET)
@PerfektesChaos: Da es, wie du korrekt aufgezeigt hast, leider keine wirklich sehr praktische Alternative gibt - Der Hinweis ist für kleine Kladogramme gedacht, die man auch noch als Imagemap erstellen könnte - habe ich jetzt wenigstens mal die veralteten HTML-Attribute auf CSS umgestellt. Ich hoffe, dass damit die Lebenserwartung erhöht wird ;-) ... Gruß von ÅñŧóñŜûŝî(Ð)20:26, 1. Dez. 2019 (CET)
Die Vorlage erzeugt auch weiterhin Linterfehler durch diese Expansionsproblematik, aber das ist jetzt nicht der Grund für meine Anmerkung. Was soll mir denn dieser Hinweis sagen?
„Bitte verwende stattdessen Grafiksoftware. Näheres ist auf der Diskussionsseite angegeben.“
Wo genau steht dort etwas zur alternativen Verwendung und welche Grafiksoftware da gemeint wäre? Sicher es war ein IP-User, der →das eingefügt hat, den kann man jetzt schlecht direkt fragen. So etwas hilft natürlich auch nicht wirklich. Zudem werden viele der Kladogramme zusätzlich in eine Benutzervorlage {{Userboxtop}} eingebunden, was die Problematik weiter verschärft (734 hastemplate:Userboxtop und 733 hastemplate:Userboxbottom). In einigen Fällen reichte es diese Box durch andere Syntax zu ersetzen, um die Linterfehler oder die Expansionstiefenüberschreitung zu beheben. --Liebe Grüße, LómelindeDiskussion06:57, 2. Dez. 2019 (CET)
Wir haben schon genügend Stammbaum-Klade-Vorlagen-Ärger.
Wir haben wahrscheinlich zigtausende von Artikeln zu Fürstens aller Art mit von und zu über ein Dutzend Generationen, die seit einem Jahrzehnt alle ohne derartige Linien auskommen.
Entweder, die biografischen Genealogie-Stammtafel-Fürstenhaus-Wikiprojekte setzen sowas massenhaft und tausendfach ein, oder es bleibt dabei.
Dieser Aufriss für einen einzelnen Artikel, ohne dass es eine wirkliche Notwendigkeit dafür gäbe, ist nicht verhältnismäßig.
So Zeugs muss umfassend dokumentiert, den Autoren und Wartungskräften erläutert und mit Testserien versehen werden; das ist als Sahnehäubchen für einen einzelnen Artikel nicht drin.
Der Genealogy-Laden muss dann auch die dauerhafte Verantwortung für die Angelegenheit übernehmen und es in allen seinen Artikeln systematisch verbauen.
Möglicherweise gibt es auch Konstellationen, in denen irgendwas nicht hinkommt, und dann haben wir das Ding hier wieder an der Backe.
Also... Die Dokumentation ("Füge am Anfang einer *-Liste{{XYZ}} und am Ende {{XYZ-Ende}} ein") dazu ist wirklich extrem einfach, und macht wirklich keinerlei Ärger (einfach mal einen Blick auf die wirklich extrem einfache Grundlage werfen) und wäre potentiell auf über 500 Seiten einsetzbar. Habitator terrae15:04, 21. Dez. 2019 (CET)
Das CSS ist komplett undokumentiert.
Falls sowas jemals bei uns aktiviert werden würde, hat unsere CSS-Dokumentation die folgenden Fragen anschaulich zu erläutern:
Da stehen -2981px drin – wo kommen die her, wie errechnen die sich, wie müssten sie unter welchen Umständen angepasst werden? -5971px dito.
Wovon hängen die 21px ab? Könnten das auch andere Werte sein?
Wodurch kommt die Ecke links-unten └ zustande? Wodurch kommt die Verzweigung ├ zustande?
Auf welche Weise wird auch nach Zeilenumbruch die durchgehende vertikale Linie sichergestellt?
first line here deals with new situation after RemexHTML switch, where emptyline cause the first child to become the 2nd child. Such a mess – klingt mitnichten nach einer trivialen Aufgabe.
Wenn sowas produktiv bei uns eingesetzt werden soll, dann müssen wir auch in der Lage sein, es notfalls zu reparieren und zu pflegen. Sich darauf zu verlassen dass irgendein anderes Wiki schon ungefragt in die Verantwortung zu nehmen sei, unsere Artikel sauberzuhalten – das läuft nicht.
Bevor das nicht komplett nachvollziehbar deutschsprachig dokumentiert ist, läuft da gar nix. Wir haben noch Berge an undokumentierter Pfuschereien und Murksereien aus der Kindergartenzeit aufzuarbeiten, als auch irgendwelche Narren irgendwelche Bastelarbeiten in die Welt gesetzt haben, und das dann hundertfach in unsere Artikel gedroschen wurde, und die Verantwortlichen sind futsch.
Also ich denke mal jedem mit ein bisschen Ahnung in CSS müsste klar sein, dass die 21px sich aus der Breite des Hintergrundbildes https://upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png ergeben und -2981px bzw. -5971px den Ausschnitt bestimmen (damit erledigen sich auch die Fragen 3. und 4.). Frage 5. ist wie du korrekt feststellst nicht ganz so trivial, erklärt sich mir aber recht einfach: Es gibt offensichtlich eine Einstellung/Erweiterung/Syntax, bei der vor einer Liste automatisch eine "emptyline" eingefügt wird, die berücksichtigt werden muss. Habitator terrae18:04, 21. Dez. 2019 (CET)
Und was machen so arme Leutchen wie ich, die von CSS nichts verstehen und dann auch mit Template/Styles rein gar nichts anfangen können, aber trotzdem hier als Mitarbeiter der Vorlagenwerkstatt versuchen alle erdenklichen Probleme zu analysieren und nach Möglichkeit zu beheben? Wir sind so schon viel zu wenige hier. Jede (für mich) komplizierte oder unverständliche Neuanlage bürdet dann also den anderen wenigen, die das verstehen noch mehr Arbeit auf, weil jene herausfallen, die es schlicht nicht lösen können, weil ihnen das Hintergrundwissen fehlt. --Liebe Grüße, LómelindeDiskussion18:18, 21. Dez. 2019 (CET)
(BK, vor Ló geschrieben)
Den Spruch „jedem mit ein bisschen Ahnung in CSS“ kannst du dir gern von L. oder sonstwem um die Ohren hauen lassen.
Das ist mitnichten trivial, und undokumentiertes Rumgepfusche stellen wir nicht mehr als projektweit verfügbare Ressource bereit. Wir haben noch haufenweise undokumentierter Murksereien und Hacks und wilde Bastelarbeiten aus unserer eigenen Krabbelphase auf Halde, da kommt kein zusamnmenkopierter Scheißdreck mehr in den ANR.
Zu deinem dahingerotzten „-2981px bzw. -5971px den Ausschnitt bestimmen“ kannst du dann mal eine Skizze vorlegen, und auf dieser Skizze verdeutlichen, wo der Nullpunkt liegt, was er bedeutet, und welche Wirkung genau worauf diese Koordinaten hätten, und was woraus ausgeschnitten würde.
Genauso leer ist damit deine Behauptung, damit wäre ja 3 und 4 auch schon klar.
Du bist immer vornedran, wenn es darum geht, hier irgendwas einzuführen, was außer dir vielleicht noch drei oder fünf Leute nach Einarbeitung verstehen könnten, und alles in einem möglichst komplizierten und undurchdringlichem Dschungel zu verbasteln. Und diese wenigen Leute müssen dann für Tausende solcher Hacks und Tricksereien verantwortlich sein und das alles am Laufen halten, und bekommen noch nicht mal die Gnade einer Dokumentationsseite. Je länger ich mir das ansehe, desto mehr bin ich grundsätzlich gegen die Einführung deiner zusammenkopierten Dingse.
Seit wann ist das eine "[m]einer zusammenkopierten Dingse"? Das ist eine im englischen Common.css benutzte (und nun ausgelagerte) außerdem schon seit 9 Jahren in der französischen Wikipedia erprobte Technik, die einfach nur 1 zu 1 importiert werden sollte - aber wenn nun auch Lo dagegen ist, lassen wir es lieber. Habitator terrae18:49, 21. Dez. 2019 (CET) PS: Und soll ich das mit dem "Scheißdreck" (falls es sich auf die vorliegende Technik bezieht) an die französischen und englischen Kollegen weitergeben?
Gerade der Einsatz solcher Techniken macht eine präzise Beschreibung und Dokumentation des Soll- und Ist-Zustands um so dringlicher.
Auf commons:File:Treeview-grey-line.png steht: Fehler beim Erstellen des Vorschaubildes: Ungültige Thumbnail-Parameter oder Bilddatei mit mehr als 2.500 Millionen Pixels oder GIF, TIFF >100 MP
Aus den Bildabmessungen kann ich mir ungefähr zusammenreimen, was vermutlich auf dem Bild zu sehen wäre, wenn ich es denn sehen könnte, wobei auf einem thumbnail mutmaßlich nichts zu sehen wäre.
Umso dringlicher ist eine präzise textliche Beschreibung, was auf dem Bild sichtbar wäre, und was das mit den Ausschnitten und Koordinaten zu tun hätte.
Nebenbei bemerkt vermute ich, dass ich Anfang des Jahrhunderts genau die gleiche Verwendung schon mal gesehen hatte, noch mit HTML4, und Ende der 1990er hingegen kleinteiliger dafür interaktiv-dynamisch das auch noch mit JavaScript. Letzteres habe ich vermutlich noch in den Abgründen meiner zentralen Festplatte in irgendeinem Verzeichnis.
Es bleibt dabei: Keine Bastelarbeiten mehr ohne professionelle und exakte Dokumentation hier in diesem Wiki. Es gibt in der ganzen deWP wahrscheinlich nur eine Handvoll Benutzer, die fachlich damit umgehen könnten, wobei wohl nur zwei oder drei davon aktiv die gesamte Projekt-Infrastruktur warten und pflegen. Je mehr hingeschissene C&P-Trümmer da irgendwo reingeflickt werden, desto aufwändiger wird es, die Millionen an Artikel unzerschossen zu präsentieren.
Na dann kann man ja nur hoffen, dass niemals jemand auf die Idee kommt so etwas [[Datei:Treeview-grey-line.png|mini|Stammbaumlinie]] irgendwo in einen Artikel einzufügen, ich mach es hier jetzt lieber nur mit nowiki. --Liebe Grüße, LómelindeDiskussion09:32, 22. Dez. 2019 (CET)
@Habitator terrae:
Wenn es darum geht, die alltägliche Drecksarbeit dieser Werkstatt zu machen, und die Fehler aus den vorhandenen Programmierungen des Altbestands herauszuholen, unseren Altbestand robuster zu machen und zu dokumentieren, dann ist von dir absolut null zu sehen.
Kaum gibt es die Möglichkeit, mit einem neuen völlig kryptischen Spielzeug den Dschungel noch undurchdringlicher zu machen und irgendwoher was abzukopieren, durch das Normalsterbliche noch weniger durchfinden, dann bist du binnen 18 (achtzehn) Minuten zur Stelle und schreist Hurra! Her damit!
Dir geht es nicht darum, unsere Artikel und Funktionsseiten robust und leicht zu bedienen und zukunftsfähig zu machen; du geilst dich regelmäßig nur an möglichst abgedrehtem möglichst exotischem möglichst unverständlichem Zeugs auf.
Ich habe dein übles Gepfusche noch nur zu gut in Erinnerung, mit dem du ohne Vorwarnung den unschuldigen Kurier-Ticker überfallen hattest, und die Parameterversorgung und seine Funktion zerschossen hattest, und es den nachfolgenden Kurier-Autoren unmöglich gemacht hattest, deine konfuse Bastelarbeit noch zu bedienen. Es hatte mich dann eine Woche Hauptprogrammierzeit gekostet, das wieder in einen von normalen Menschen nutzbaren Zustand zu bringen. Wobei du nur rumgetönt hattest, dass dann halt alle außer dir zu blöd wären, dein Meisterwerk zu bedienen. Sowas lese ich in diesem Thread auch wieder. Problem war, dass du dabei nicht eine wenigstens technisch funktionierende Lösung irgendwoher abkopiert hattest, sondern deine eigenen Ideen live in eine produktive Seite hineinbasteltest, sie ohne Grund stark verkompliziert hattest, und da dies völlig fehleranfällig, nur mit größerem Mehraufwand und damit außer durch dich von niemandem mehr nutzbar war, hattest du eine wohl ein Jahrzehnt problemlos und von allen Kurier-Autoren zu bedienende Funktionsseite in ein kryptisches Desaster verwandelt.
Und ich bin wirklich begeistert von Deiner Freundlichkeit. Habitator terrae13:43, 22. Dez. 2019 (CET) PS: Und ich vergesse ja auch immer wieder zu betonen, dass Du ja, mit meiner ausdrücklichen Billigung, beim Kurier-Ticker einfach mich Zurücksetzen hättest können, das wäre auf jeden Fall freundlicher gewesen als Beschimpfungen rauszuhauen.
Kann bitte einer in die Infobox Naturrodelbahn einfügen das man auch ein Bild anzeigen kann und Koordinaten mit Bild wo die Naturrodelbahn steht? Das wäre sehr nett. --कार (Diskussion) 12:32, 4. Dez. 2019 (CET)
Wo soll das Bild ausgegeben werden oben oder unten? Koordinaten, mach ich aber nicht, dafür kann man doch immer die {{Coordinate}} einbinden. Wenn es allerdings eine Koordinate mit Karte sein soll also {{Positionskarte}} dann erst recht nicht ich. Denn das ist eher kompliziert. Das Bild aber sollte machbar sein. Wie möchtest du es dann eingebunden haben, mit einer Standardgröße, als Dateipfad, als Komplette Datei? Mit Bildlegende (mini) oder rahemenlos und mit eigenem Parameter Bildunterschrift? --Liebe Grüße, LómelindeDiskussion13:02, 4. Dez. 2019 (CET)
Das wäre sicherlich machbar aber da ist scheinbar absichtlich so ein Konstrukt eingefügt worden.
{{#if: {{{upload|{{{d|{{{3|{{{zugriff|{{{z|{{{kommentar|{{{k|}}}}}}}}}}}}}}}}}}}}}|.}} = wenn kommentar upload zugriff … einen Inhalt haben, dann setze einen Punkt ans Ende. Es müsste also geklärt werden, weshalb das so eingebaut wurde, ehe man das einfach so entfernt. Das bewirkt den Punkt →{{#if: {{{upload|{{{d|{{{3|{{{zugriff|{{{z|{{{kommentar|{{{k|Inhalt}}}}}}}}}}}}}}}}}}}}}|.}} →. Frag mal PM3, hätte ich gesagt, aber der ist nicht mehr aktiv, auch Uwe Martens ist ausgeschieden. Ich kann es dir nicht beantworten, in Einzelbelegen gehört ein Punkt ans Ende →Hilfe:Einzelnachweise#Internetbelege. --Liebe Grüße, LómelindeDiskussion10:33, 14. Dez. 2019 (CET)
Hmm, ok. Diese Vorlage scheint demnach nur für Einzelnachweise vorgesehen zu sein, anders kann ich mir auch den obligatorischen Parameter für das Zugriffsdatum nicht erklären. Dann werde ich die Vorlage entsprechend im Weblinks-Abschnitt nicht (mehr) nutzen. -- Danke und Gruß Sir GawainDisk.13:24, 14. Dez. 2019 (CET)
Video von Lu Likes: „Sichtbar sein“ auf YouTube, 10. Oktober 2018 (2,5 Minuten).
Hier ohne zugriff= (oder leer).
Bei der Gelegenheit: Vielleicht hätte Ló Lust, dort zusätzlichabruf als Parameter zu akzeptieren, und dann vielleicht auch abruf-verborgen= einzubauen – es ist bei der URL-Pflege immer hilfreich, wann das Ding eingefügt oder gecheckt wurde, auch wenn im Artikel der Zugriff nicht angezeigt wird. --Chiananda (Diskussion) 22:11, 14. Dez. 2019 (CET)
Also, in dem Klammertheater wird sicher niemand aus dieser Werkstatt noch herumbauen wollen.
Was ginge, das wäre dieses Teil komplett auf Fütterung der Internetquelle umzustellen, und der die Formatierung zu überlassen. Zumindest mit einer zukünftigen Version selbiger.
Die beteiligten oben erwähnten Bearbeiter wären nun nicht grad von der kollegialen und kooperativen Sorte; ein Grund mehr, das heiße Eisen ein Jährchen abkühlen zu lassen, und dann mal sehen.
@Chiananda:: Es ging mir bei dieser Vorlage nicht um den Aufzählungspunkt am Anfang, sondern den Punkt am Ende des Textes. Auch in deinem Beispiel ist er ja vorhanden. Es war genau dieser Punkt, der mich gestört hatte. Ich kann verstehen, dass er für Einzelnachweise nötig ist, aber wenn die Vorlage unter Weblinks genutzt wird, ist er gemäß Formatierung von Weblinks nicht gewollt und überflüssig. -- Gruß Sir GawainDisk.00:10, 15. Dez. 2019 (CET)
Kann ich dir nicht beantworten, aber es geht mit weniger Rand, für mich ist das allerdings schon zu viel Spielerei. Statt einer Tabellenschachtel kann man auch einfach die Ränder ausblenden.
Meine alten Schachteln dressiere ich möglichst fehlerfrei, siehe Liste der Flughäfen und das Ergebnis der Spelerei kann man dort betrachten. Probleme macht allein mw-datatable und das habe ich da rausgeschmissen. --Klaus-Peter18:21, 25. Dez. 2019 (CET)
Lesefähigkeit und ästhetisches Empfinden mögen sehr unterschiedlich ausgeprägt sein. Meine Präfrernzen muss man nicht teilen. Dennoch sind die "Missbildungen" mitmw-datatableerkennbar.
Inzwischen habe ich den "Übeltäter" entdeckt ab Zeile 453 in shared.css. Da ist viel Holz drin, obwohl der Effekt nur in Zeile 470 mit
bewirkt wird. Warum da mw-datatable td, mw-datatable th { border: 1px solid #a2a9b1; padding: 0.2em 0.4em;} mit drin ist, bleibt mir ein Rätsel. DAS halte ich für Spielerei!--Klaus-Peter15:06, 26. Dez. 2019 (CET)
So, das Problem ist zwar nicht gelöst, da der Fehler in der css bleibt, aber ich habe nun im Modul:Flagge quasi diese Einstellungen durch das Gewünschte ersetzt/überschrieben. Das Ergebnis sieht man oben. Nicht elegant, nicht effektiv, aber funzelniert jetzt zumindest mit der Vorlage:Flagge. Dennoch bleibt das Problem weiterhin bestehen, aber das betrifft mich nun nicht mehr. Vielen Dank für die zahl- und hilfreichen Expertenantworten; guten Rutsch Klaus-Peter09:58, 28. Dez. 2019 (CET)
Nachtrag: Gerade habe ich festgestellt, dass auch die Einfärbung einzelner Tabellenzeilen (z.B. mit |- bgcolor="#f0f8ff"komplett (wie alle sonstigen Daten-Zeilen) von mw-datatable in knallweiß überschrieben werden. Da hat jemand den css-Eintrag wirklich extrem kurzsichtig angelegt! --Klaus-Peter06:33, 31. Dez. 2019 (CET)
Letzteres ist aber, denke ich, bewusst so, denn wer eine mw-datatable verwenden möchte, der sollte nicht zusätzlich noch mit weiteren Farben in der Tabelle herumspielen, man sollte schon wissen, was man möchte, entweder eine Einfärbung per Mouseover oder eine generelle variable Zellenfärbung. Datatable hat wohl den Vorrang, es ist nicht kombinierbar mit Zebrastreifen oder sonstigen Farben, gleiches gilt ja auch für zebra
Beispiel
Zelle
Zelle 2
Zelle 3
Zelle 4
Zelle
Zelle 2
Zelle 3
Zelle 4
Zelle
Zelle 2
Zelle 3
Zelle 4
Zelle
Zelle 2
Zelle 3
Zelle 4
Da ist auch immer eine Zeile weiß, man könnte sie zwar übertünchen, dann aber hat man kein Zebra mehr sondern irgendetwas buntes. Wie gesagt, wenn man unbedingt mit Farben herumspielen muss, sollte man sich dessen auch bewusst sein, was man da tut. Meiner Meinung nach sind beide Klassen nur für die einfache Verwendung gedacht, entweder oder. Es ist also nicht wirklich nett, denjenigen, der das CSS festgelegt hat als „extrem kurzsichtig“ zu bezeichnen. --Liebe Grüße, LómelindeDiskussion10:10, 31. Dez. 2019 (CET)
Ich will nicht nett sein, sondern die Realität bewerten. Die schon erwähnten Einträge in der css ergeben keinen erkennbaren Sinn, denn bei ‚mouseover‘ ist es irrelevant, welche Farbe vorher war. Auch Rahmen müssen für die Funktion nicht geändert werden. Beides kann getrost von oben übernommen werden. Auch bei zebra hat die manuelle Eingabe des Anwenders Priorität. Das ist auch korrekt so und nicht mit mw-datatable vergleichbar. Da bleibt der Anwender chancenlos, es sei denn er verzichtet total darauf. zebra verträgt sich übrigens perfekt mit „Flagge“, das war auch schon vor der Modul-Anpassung so. Übrigens verändert mw-datatable auch den normalerweise schwach grauen Tabellenhintergrund bzw. eingestellten Hintergrund
So, das soll eine sinnvolle Lösung sein? Ist und bleibt Myopie! Ansonsten ist bei langen Tabellenzeilen zebra oder mw-datatable durchaus hilfreich. --Klaus-Peter11:25, 2. Jan. 2020 (CET)
Was hat denn das Ganze hier mit der Vorlagenwerkstatt zu tun? Wenn dich da etwas stört wende dich an die Entwickler, hier können wir nicht weiterhelfen. Was ich zu deiner Vorlage anzumerken hatte habe ich dir bereits gesagt, für mich ist sie weder wartungs- noch bedienerfreundlich und erschwert die Bearbeitung der Artikel. --Liebe Grüße, LómelindeDiskussion12:28, 2. Jan. 2020 (CET)
Hallo da die mehrspaltige Darstellung der ENs derzeit Probleme leidet, wird auf die Vorlage:Mehrspaltige Liste zurückgegriffen und Spalten erzwungen. Abgesehen davon, dass Mehrspaltigkeit nicht unbedingt einen Vorzug hat und deshalb manchmal abgelehnt resp. revertiert wird – was haltet ihr von solchen „Überbrückungsmaßnahmen“ ((Einzweck-)Edit)? @44Pinguine: FYI.
Ich halte davon gar nichts, denn ich mag die Mehrspaltigkeit in Einzelnachweisen absolut nicht! So wird sie jedem aufgezwungen, auch denen, die das bewusst abgeschaltet haben. Zudem ist die Vorlage nicht dafür gedacht.
Ja gut. Die verwendung dieser vorlage habe ich u.a. vorgenommen. Denn: ich finde, dass die EN tatsächlich in mindestens zwei spalten "besser dargestellt" werden. Wie in jedem guten buch sind sie *fußnoten* und daher dort fast immer in kleinerer schrift gesetzt, in der englischen WP sogar mittels einer passenden vorlage. Weil die kleine schrift aber anderer stelle von anderen nutzer*innen abgelehnt wurde, halte ich es für richtig, wenn mindestens die hauptautor*in oder ersteller*in eines lemmas diese darstellung wählt und das nicht von anderen danach geändert wird. - Ich weiß, dass auf den smartphones die kleinen texte nicht so vorteilhaft zu lesen sind. Aber diese FN sind eben nur eine zusatzinfo zum eigentlichen lemma. - Schönes & gesundes neujahr auch von mir an alle aktiven! 44pinguine☕11:03, 1. Jan. 2020 (CET)
Findest du wirklich dass der/die/das Hauptautor das Recht hat allen anderen vorzuschreiben, wie bei ihnen die Einzelbelege angezeigt werden müssen? Ich bin schon froh, dass sie nicht auch noch in Kleinschrift daherkommen, denn im Gegensatz zu anderen verwende ich Einzelbelege oftmals gezielt zur Prüfung der Angaben. Es wird aber erschwert, wenn diese in kleine Häppchen umgebrochen werden, nur weil andere sie als unwichtige Fußnoten einstufen. Wer es für sich persönlich so haben möchte kann das über CSS regeln, es allen anderen aufzudrücken ist … dafür habe ich keine Worte. Meine Anpassung auf Einspaltig wird dadurch jedenfalls außer Kraft gesetzt. Ich würde dich daher bitten das nicht fortzusetzen, sondern wenn dann für dich persönlich anzupassen. --Liebe Grüße, LómelindeDiskussion13:39, 1. Jan. 2020 (CET)
@44Pinguine: Bitte unterlasse solche fehlinformierten Eingriffe, auch ich musste schon einige davon zurücksetzen; Serienedits für subjektive Wunschvorstellungen sind belästigend. --Chiananda (Diskussion) 14:50, 1. Jan. 2020 (CET)
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?
--Wickie3713:31, 24. Okt. 2019 (CEST)
@Wickie37: Flash ist tot. Jeder Browser blockiert das mittlerweile standardmäßig und werden die Ausführung demnächst überhaupt nicht mehr erlauben. -- hgzh23:34, 26. Nov. 2019 (CET)
@Hgzh: Das ist richtig. Nun ist die Vorlage aber immer noch hundertfach eingebunden, obwohl sie - zumindest ohne Flash - nicht mehr funktioniert. Also Vorlage und alle Einbindungen löschen? Oder wie wird sowas hier gehandhabt? --Wickie3713:04, 6. Dez. 2019 (CET)
Vorlage:Infobox Wrestler
Hallo zusammen, in der Vorlage gibt es einen Darstellungsfehler. Wenn der Parameter "|birth_name" nicht gefüllt ist, wird als Wert {{{birth_name}}} angezeigt
wenn ich mir die doku der Vorlage anschauen, finde ich den parameter "|birth_name" nicht aufgeführt. es ist nur in der Kopiervorlage genannt. Vielleicht kann das auch gleich mit behoben werden. Vielen Dank und viele Grüße --Thomas12:17, 10. Dez. 2019 (CET)
@Tsungam: vielen Dank. kannst du auch "mein" Problem zwei weitere oben beheben. mit den falschen Bilderdarstellung in der Wikipedia-App? Ich hau aber schon mal WP:TWS an. viele grüße --Thomas16:29, 10. Dez. 2019 (CET)
Hallo zusammen! Ich bin heute zum ersten Mal bewusst dieser Vorlage begegnet und prompt darüber gestolpert, dass bei ihr die deutsche Übersetzung jeweils in einfachen Anführungszeichen ausgegeben wird (warum?) und bei anderen ohne diese dafür aber kursiv. Das einfache Anführungszeichen wird aufgrund der Ähnlichkeit bei längeren Begriffen eher als (falsches) Komma gelesen und irritiert dadurch. Konkretes Beispiel aus dem Artikel Kurtisane:
Das mag sein, aber die Formatierung richtet sich nach Wikipedia:Fremdwortformatierung und folgt linguistischen Gepflogenheiten. Insbesondere wird der (lateinisch verschriftete) fremdsprachliche Ausdruck in Kursivschrift wiedergegeben, die wörtliche deutsche Übersetzung in einfachen Anführungszeichen. In dieser Form wird es seit über einem Jahrzehnt projektweit recht einheitlich gehandhabt. VG --PerfektesChaos20:48, 22. Dez. 2019 (CET)
Vorlage Mehrere Bilder hat Probleme mit der Darstellung in der WP-App
Hallo zusammen, kann sich jemand bitte mal das hier anschauen. Irgendwie werden in der WP-App die Bilder in der Vorlage falsch dargestellt. Danke und Gruß --Thomas19:04, 5. Dez. 2019 (CET)
Es gibt zahlreiche Einträge in der einfachen Form {{BBLD}}, die nun in Kategorie:Wikipedia:Wikidata P2580 Wartung gesammelt sind, weil das WD-Property P5280 entfernt wurde. Anscheinend soll stattdessen das Property P213 genommen werden. Kann das jemand anpassen, dass P213 genutzt wird, wenn P2580 nicht vorhanden ist? --Magnus(Diskussion)12:33, 12. Dez. 2019 (CET)
Ich hab mich mal eingelesen. Bei Wikidata war eines der Argumente für das Entfernen dieses Property, die global gesperrte IP (die übrigens wieder mal bei FzW nervt: hier und hier). Vielleicht sollten wir diese Vorlage BBLD komplett aus den Artikeln werfen. Einfach um dieser IP (Der angebliche Name ist bei Diskussion:Wikidata#Kritik_durch_BBLD genannt) den Weg zur Tür zu zeigen. --Wurgl (Diskussion) 14:04, 12. Dez. 2019 (CET)
Das sie von einem mutmaßlichen Troll initiiert wurde, ist allein kein Entlinkungs- und damit Löschgrund. Es ist ja nicht automatisch ausgeschlossen, dass sie Sinn macht. ÅñŧóñŜûŝî(Ð)14:21, 14. Dez. 2019 (CET)
Vorlage:Infobox Alm
Liegt es an der Vorlage:Infobox Alm, daß der folgende Text (also die Einleitung zum Artikel) einige Zeilen nach unten gerückt ist? Siehe z.B. Enningalm.
Moin! Ich habe ein paar Probleme mit Vorlage:Infobox Verwaltungsgliederung (Ghana). Angedacht auch für Regionen, wird sie bislang in diesem Themenbereich nicht verwendet, sondern nur für die unterhalb der Regionen angesiedelten Distrikte. Meine Probleme, zumindest in der Vorschaufunktion:
Ohne Angabe von |Region= erscheint keine Regions-Kategorie. Die Region anzugeben ergibt aber keinen Sinn, weil eine Region nicht in sich selbst liegt. Könnte man das über den ISO-Code regeln? Es ist sicherzustellen, dass der Regionsartikel ganz vorne in seiner Kat einsortiert wird.
(nach BK) Ich bin nicht Freund von automatischer Kategorisierung (habe das auch nicht eingebaut; diff). Das macht mehr Probleme als es löst. Habe die Vorlage nicht mehr unter Beobachtung, aber es war wohl nicht beabsichtigt Distikte und Regionen gleichzeitig damit abzubilden, die Regionen brauchen andere Parameter (beispielsweise den Regionalminister). Dazu ist eine komplette Neuschreibung notwendig. --Atamari (Diskussion) 12:07, 17. Dez. 2019 (CET)
Meinetwegen kann die automatische Kategorisierung auch ganz raus, zumal es Probleme bei ehemaligen Verwaltungseinheiten gibt, wo ich in den letzten Tagen dann die Infobox ganz rausnehmen musste. Neuschreibung meinetwegen, bevor ich mich an die Arbeit mache. NNW12:09, 17. Dez. 2019 (CET)
Ich habe es jetzt erstmal wie vorgeschlagen umgesetzt (Ergänzungen zu spät gesehen). Wenn Region= nicht belegt ist, wird dies als Einbindung in einen Regionsartikel verstanden und die entsprechenden Kategorien werden gesetzt; andernfalls als Distrikt mit den entsprechenden beiden Kategorien. „Sauber“ wäre es natürlich, wenn ein zusätzlicher Parameter Art= oder dergleichen die Art der Verwaltungseinheit definieren würde, bzw. ein weiterer für aufgelöste Verwaltungseinheiten, der dann u.a. die Kategorisierung deaktiviert. Zusätzliche Parameter für Regionen wären jederzeit möglich. Generell müsst ihr sagen, was ihr haben wollt.
Berechnung der Bevölkerungsdichte funktioniert nun automatisch, falls keine manuell angegeben ist.
Vielen Dank! Es geht um Artikel, die seit über einem Jahrzehnt praktisch unbeachtet vor sich hin gammeln. Inwieweit da jemand noch großartig Mühe reinstecken will, weiß ich nicht, muss aber nicht hier besprochen werden. NNW13:33, 17. Dez. 2019 (CET)
Vorlage Beschreibung von Staaten der Eurozone, Währungsvorgabe Euro, ansonsten US-Dollar
Sehr geehrte Damen und Herren,
könnten Sie bitte für die Beschreibung von Ländern der Eurozone in der Wikipedia die Währung Euro in Ihren Vorlagen vorgeben.
Leider wird auch in der Beschreibung der Bundesrepublik Deutschland für den Wert des Bruttoinlandsproduktes (BIP) die Währung US Dollar in Ihrer Vorlage verwendet.
Des Weiteren könnten Sie weitere wichtige Kennzahlen wie die Staatsverschuldung in Euro (Maastricht-Definition) und die Staatsverschuldung in Prozent des BIP in die Vorlage integrieren.
zunächst einmal beschäftigt sich diese Werkstatt mit technischen Belagen zu Vorlagen, weniger mit inhaltlichen Angelegenheiten. Ihr Anliegen wäre also zunächst bspw. unter Wikipedia:Fragen zur Wikipedia besser aufgehoben. Dennoch kurz inhaltlich: das Bruttoinlandsprodukt ist bewusst in USD angeben, damit die weltweite Vergleichbarkeit gegeben ist. Ansonsten soll eine Infobox lediglich einen groben Überblick über den Staat geben und sich nicht in allzuviel Details verlieren bzw. zum Aufzählen aller möglichen Daten verwendet werden, weshalb die Abhandlung weiterer Kennzahlen in einem einordnenenden Abschnitt im Artikeltext in den meisten Fällen besser ist. Gruß, -- hgzh19:33, 20. Dez. 2019 (CET)
Guten Abend Werkstattler, ich würde gerne den Turnierplan32 mit einer größeren Team- und Ergebnisbreite nutzen. team-width= und score-width= funktionieren allerdings nicht, vermutlich sind sie nicht definiert. Könntet ihr die Variabilität der Vorlage ermöglichen, um die Vorlage:Nowrap bei langen Texten zu vermeiden? Vielen Dank und ein frohes Fest wünscht --Jakob Gottfried (Diskussion) 17:17, 25. Dez. 2019 (CET)
Die Turnierbäume sind m. E. sowieso zu verbessern. Da gibt es einige Mängel:
Eine Hintergrundfarbe #F2F2F2 oder #F9F9F9 ist für den Bildschirm sinnlos, da bei vielen Geräteeinstellungen nicht mehr von weiß zu unterscheiden. Das sollte entweder durch ein dunkleres Grau ersetzt oder ganz entfernt (=transarent) werden.
Rahmen mit "1px solid #aaaaaa" machen beim Drucken Ärger, denn je nach Skalierung kommt ggf. ein so geringe Linienbreite heraus, dass dieses helle Grau und damit die Linie teilweise verschwindet. Die Linien sollten entweder Ein Pixel breit und schwarz oder zwei Pixel breit und grau sein.
Eine Hintergrundfarbe #98A1B2 hat so wenig Sättigung, dass sie genausogut durch eine Grauton ersetzt werden kann, was viel Farbtinte im Drucker einsparen kann.
Die Breitenangaben sollten eine schriftrelative Einheit wie z.B. "em" erhalten.
#F2F2F2 macht im Gegensatz zu #FFFFFF schon einen großen Unterschied, zumindest an meinem Bildschirm, weil dunkler als #F9F9F9. Vielleicht sollte ein Turnierbaum einmal nach aktuellen Standards perfekt designed werden, um dann nach und nach alle anderen Turnierpläne einheitlich daran anzupassen. Viele Grüße --Jakob Gottfried (Diskussion) 19:31, 25. Dez. 2019 (CET)
Der Unterschied hängt von der eingestellten Helligkeit und der Gammakorrektur ab. Zur Technik: Es gibt Probleme mit etwas längeren Texten mit der Breite, beim Druck und mit der Gleichmäßigkeit der Höhen. Es gibt zwei generell andersartige Möglichkeiten, da etwas zu ändern:
Statt einer Monstertabelle eine Hintergrundgrafik mit den Linien und die Kästchen als überlagerte Kleintabellen.
Diese Diagramme müssen meistens einmal erstellt und dann nicht mehr verändert werden. Da bieten sich auch reine Grafiklösungen an. So z. B. eine anklickbare Imagemap auf SVG-Basis. Quelltextvorlagen wären leicht zu erstellen und hier vorrätig zu halten. Muss man dann halt hochladen, wenn das Aussehen fertig ist.
Aber doch müssen die Inhalte änderbar sein, etwa um einen Eintrag zu verlinken oder um eine Verlinkung zu korrigieren oder etwa um einen Namen zu ändern ... Oder habe ich da etwas nicht richtig verstanden? --tsor (Diskussion) 20:59, 25. Dez. 2019 (CET)
Der Name der Sportler/Sportlerinnen dürfte sich kaum noch ändern, wenn das Turnier erst einmal vorbei ist und das Ergebnis inkl. Dopingkontrollergebnis vorliegt. Der kann also Teil der SVG sein und verlinkt wird mit Hilfe der Imagemap, also durch Anklicken der der Grafik im Bereich eines Namens, was auch via Vorlage geht. Ansonsten muss man Änderungen durch Upload einer neuen Grafik bewirken. ÅñŧóñŜûŝî(Ð)22:32, 25. Dez. 2019 (CET)
Guten Morgen Antonsusi (der Ping kam nicht an), die Einbindung eines solchen Turnierplans halte ich für nicht so benutzerfreundlich wie solcher in den bislang genutzten Varianten, da immer eine Grafik nachgeladen werden muss. Soweit ersichtlich (ich habe ein wenig herumgespielt), lassen sich auch Größe, Schriftgröße von seed und score nicht ändern und zu lange Texte gehen schlichweg über den Kastenrand hinaus. Die Nowrap-Vorlage wäre jedenfalls glücklicherweise hinfällig. Viele Grüße --Jakob Gottfried (Diskussion) 10:47, 27. Dez. 2019 (CET)
Da Mandarin-Chinesisch eine plurizentrische Sprache wie Deutsch und Englisch ist, täte der Vorlage die Hinzufügung von eigenen Parametern für die Unterschiede zwischen den drei national standardisierten Aussprachenormen gut; siehe Wikipedia:Redaktion Ostasien#Vorlage:Zh-Parameterfehler in Vor-Qin-Zeit. — P.S.: Die bis vor rund zwei Jahrzehnten fast ausschließlich kantonesischsprachigen Gebiete Hongkong und Macau haben nach der Angliederung an die Volksrepublik China deren Pǔtōnghuà-Aussprachestandard für Mandarin übernommen (aber nicht die in Festlandchina sowie Singapur und Malaysia benutzen Kurzzeichen als Rechtschreibnorm), und Malaysia teilt den Huáyǔ-Aussprachestandard mit dem früher zu seinem Territorium gehörenden Singapur. Daher sind für diese drei keine eigenen Aussprache-Parameter nötig. Lieben Gruß —LiliCharlie (Disk.) 00:07, 20. Dez. 2019 (CET)
KfZ-Kennzeichen der Stadt manuell zu korrigieren?
Hallo Werkstattmitglieder,
im Artikel zur Stadt Schwelm erscheint in der Infobox oben rechts unter KfZ-Kennzeichen "automatisch" eine falsche Angabe. Angegeben werden dort nämlich zwei Kennzeichen, DIE JEDOCH NUR FÜR DEN KREIS GELTEN, zu dem die Stadt gehört (Ennepe-Ruhr-Kreis). Die Stadt selber hat nur 1 mögliches Kennzeichen (EN), nicht 2 (EN, WIT - letzteres ist für die kreiszugehörige Stadt Witten).
Wie korrigiere ich die Vorlage? (Oder bitte Eurerseits korrigieren)
Inhaltliche Zwischenfrage: Sicher, dass man als Schwelmer kein WIT-Kennzeichen beantragen und führen kann? In meinem Landkreis kann ich mir alle vier möglichen "Heimatkennzeichen" auswählen, wenn ich das möchte. Egal, in welcher Gemeinde ich wohne. Ist schließlich der Kreis, der sie vergibt, nicht die Stadt. Das bitte erst einmal prüfen, bevor hier eine Änderung herbeigeführt wird. --j.budissin+/-00:56, 31. Dez. 2019 (CET)
Diese Werkstatt beantwortet keine „inhaltlichen Fragen“. Geändert habe ich auch nichts, dem Parameter Kfz-manuell gibt es seit Jahren.
Wikidata?? Welche Einbindung??
Der eigentliche Inhalt des Parameters |Kfz= steht, so meine ich zumindest, in der →Vorlage:Metadaten Kfz-Kennzeichen DE unter dem jeweiligen Gemeindeschlüssel. | 05954 = EN, WIT <!--Ennepe-Ruhr-Kreis-->
Man hätte es auch dort ändern können, aber ich bin mir nicht sicher, ob das dann überall passt, wo dieser Schlüssel (mit dieser Vorlage) verwendet wird. Daher war mein Vorschlag, es über den Parameter |Kfz-manuell= zu lösen, da ich vermute, dass er für solche Fälle gedacht ist.
Moin, ich bin auf der Suche nach einem Weg, wie ich eine bestehende Grafik als Hintergrund definieren kann. Idealerweise könnte ich ein div nutzen und über Background dieses definieren, die Frage wäre wie ich den Pfad der Grafik dafür automatisiert ermitteln kann. -- Gunnar💬23:16, 15. Dez. 2019 (CET)
Wofür würdest du das nutzen wollen? In Artikeln, dann wäre ich dagegen, auf deiner Benutzerseite? Welche Art von Grafik meinst du?
Deine Frage wie man „den Pfad der Grafik dafür automatisiert ermitteln kann“ verstehe ich nicht. Wie soll den jemand einen Pfad finden ohne ihn zu kennen? Im Prinzip könnte man sicherlich den Parameter image nutzen um zwischen Bildern zu wechseln, aber wie das automatisch funktionieren soll ohne zu wissen was man suchen soll, ist mir schleierhaft. --Liebe Grüße, LómelindeDiskussion09:14, 16. Dez. 2019 (CET)
Im Medialayer hinterlegte Grafiken (aka Image-Namespace), werden beim Generieren der Seiten von Referenz auf absolute Adresse gewandelt. Um also deine Frage zu beantworten: Weil sie dem System ja intern vorliegt. Diese absolute Adresse, als ohne img-Tag und Parameter, wäre notwendig um das verarbeiten zu können. Ich hatte gehofft dass es ein MagicWord oder andere Option gibt, diese als Rückmeldung zu bekommen. Sonst müsste man Bild hinter Bild mit überlagerten div verwenden, womit man leider aber die dynamische Höhe durch den Vordergrund verhindert. -- Gunnar💬10:12, 16. Dez. 2019 (CET)
media:Simple shapes example.png erzeugt einen Direktlink auf den Speicherort. Ich ahne aber, dass dir das nicht weiterhelfen wird. Und bevor du dir weitere Mühe machst: aus Sicherheitsgründen wird in normalen Wikiseiten (und Vorlagen) eine Zuweisung eines Hintergrundbildes zu einem div über eine URL mit background-image nicht erlaubt. -- hgzh10:44, 16. Dez. 2019 (CET)
ich hatte eine direkte Verlinkung ,hotlinking um genau zu sein, getestet, diese wurde vom Parser entfernt aus Sicherheitsgründen entfernt. /* insecure input */ auch wenn ich nicht sicher bin wieso Commons und WP-Projekte nicht whitelisted sind. Das betrifft leider auch die Media-Links. Daher war ich in der Hoffnung auf magicword etc. bezüglich einer Parsereinstellung die nur den Pfad ermittelt. -- Gunnar💬11:43, 16. Dez. 2019 (CET)
Wenn ich das richtig verstanden habe, soll das Bild per Vorlagenparameter variabel sein, dann fallen TemplateStyles raus. -- hgzh14:41, 16. Dez. 2019 (CET)
Inzwischen gibt es die Vorlage:Bild mit Hintergrund, ich hoffe, wie schon oben angesprochen, dass es „nicht für die Verwendung in Artikeln“ gedacht ist. Denn das widerspricht so fast allem, was ich zur Bildeinbindung und den Richtlinien kenne. Es muss kenntlich sein was da was ist, dass ein Bild vor einem Bild liegt, oder ein individueller nicht zum Bild gehörende Hintergrund eingebunden wurde. Auch wie man zur Beschreibungsseite des Bildes im Hintergrund kommen kann. Das ist so ziemlich das, was ich vermutet hatte, was das werden sollte. Dass man auf diese Art Bilder verfälschen könnte. sollte man zumindest bedenken und somit eine mögliche Verwendung im ANR von Anfang an unterbinden, das zumindest ist meine Meinung. Aber meine Frage oben nach „Wofür würdest du das nutzen wollen?“ wurde ja scheinbar überlesen. --Liebe Grüße, LómelindeDiskussion14:00, 18. Dez. 2019 (CET)
@Gunnar.offel: Ich bin da mit Lómelinde absolut einer Meinung: Diese Vorlage ist nicht ANR-geeignet. Ich würde vorschlagen, dass erstens in der Doku klar zustellen und zweitens (noch wichtiger) in der Programmierung eine Namespace-Abfrage einzubauen und im Falle der Einbindung im NS:0 den Dienst zu verweigern, sprich: ohne Hintergrund nur das Bild zu zeigen.--Mabschaaf14:08, 18. Dez. 2019 (CET)
Ich sehe den Grund nicht. Die Überlegung ist primär die eines Farbverlaufes. Bei einem Hintergrundbild kann man den Infolink verwenden. Auch ist die Vorlage nirgendwo eingebunden. Zum Sprachlichen es handelt sich um Skripte keine Programme. Des Weiteren ist das keine Antwort auf meine Frage: Ob und wie man eine durch den Parser generierte Adresse nutzbar erhalten kann, sondern ein anderes Thema. -- Gunnar💬15:36, 18. Dez. 2019 (CET)
Es mag sein, dass DU nur diesen einen Verwendungszweck im Sinn hast - aber wenn die Vorlage erst mal da ist, wird sie für alles eingesetzt werden, was sie technisch möglich macht.
Schon wenn Du zwei Bilder übereinander legst, kann per Klick auf das Bild nur noch eine der beiden Dateibeschreibungsseiten erreicht werden. Das halte ich schon aus lizenzrechtlichen Gründen für bedenklich. Dass die Aussage eines Bildes durch die Wahl eines anderen Hintergrundes verfälscht werden kann, hat dir Lómelinde schon erläutert. Und dass die Vorlage (noch) nirgendwo eingebunden ist, ist ja wohl nur ein Übergangszustand oder eine Frage der Zeit.--Mabschaaf15:46, 18. Dez. 2019 (CET)
Wie wäre es wenn du dies erst prüfst, bevor du Behauptungen aufstellst. Des Weiteren hat das immer noch nichts mit meiner Nachfrage zu tun. -- Gunnar💬16:21, 18. Dez. 2019 (CET)
Doch das hat es sehr wohl, denn es geht um eine Vorlage, ansonsten wäre allein deine Anfrage auf der falschen Seite gestellt, denn hier geht es um Vorlagenerstellung und darum was richtlinienkonform erstellt werden kann und in den Vorlagennamensraum, zur Verwendung durch alle Benutzer gehört, oder was private Spielerei wäre und somit ausschließlich in den Benutzernamensraum gehören würde. Man muss da nichts prüfen, um zu wissen was andere tun, wenn sie scheinbar schicke, tolle Vorlagen irgendwo vorfinden, das kennen wir hier leider zu Genüge. Also entweder du kennzeichnest es deutlich als untauglich für den ANR oder es muss aus dem Vorlagennamensraum auf eine deiner Unterseiten verschoben werden. Das widerspricht auch den Vorgabe für Farbgestaltung. Siehe Hilfe:Farbe; nicht alles was geht ist auch erwünscht. Ich zitiere „Um ein einheitliches Erscheinungsbild zu wahren, sollten Farben in der Wikipedia mit viel Bedacht eingesetzt werden. Nutze Farben in Artikeln nur in Ausnahmefällen, wenn sie inhaltlich sinnvoll sind.“ Ich sehe hier den inhaltlichen Sinn nicht gegeben, schon gar nicht durch ein zusätzliches Hintergrundbild. Du weigerst dich ja hartnäckig die Frage nach dem „wo das verwendet werden soll“ zu beantworten, was nahelegt dass es wohl doch für Artikel verwendet gedacht ist. Und deine Aussage ist ebenso falsch, wir sprechen hier durchaus von Vorlagenprogrammierung und sicher nicht von Vorlagenskript --Liebe Grüße, LómelindeDiskussion17:05, 18. Dez. 2019 (CET)
Info: Und da haben wir auch leider schon einige Negativbeispiele für solche Syntax, die dann in Artikeln landet, als Farbverlauf oder zweifarbig gestreift. 23 Vorkommen Tendenz steigend Chemie (Verlauf im Tabellenkopf) und Sport. Die obige Vorlage wäre wohl fürs Militär.
Ich halte es nicht einmal für leserfreundlich Bunt gestreift. Für Leser mit rot-grün Sehschwäche ist es auch eher ungeeignet wie hier →DDR-Meisterschaften im Feldfaustball 1960 die Tabellen.
Platz
Mannschaft
Punkte
–
Motor Suhl
10:34
–
Lokomotive Görlitz
9:35
–
Motor Ost Dresden
4:40
–
Chemie Jena
5:5
Einer fängt damit an und andere übernehmen das dann. Schön finde ich das nicht, und was die Streifung da in den Tabellen kennzeichnen soll, erschließt sich auch nicht. Der Mehrwert für den Leser ist nicht erkennbar. Und das letztere trotz des deutlichen → Hinweises durch Schnark (auch da hatte ich schon so meine Befürchtungen) Zitat: „Aber bitte wenn überhaupt, dann nur mit sehr viel Bedacht einsetzen.“ Das halte ich nicht für sinnvoll. @Tommes ich würde dich bitten das aus den Artikeln wieder zu entfernen. Zur Chemie würde ich Mabschaaf bitten das intern im Portal Chemie zu klären. So etwas ist auch nicht wirklich toll. Und es verleitet, wie gesagt, leider auch zur Nachahmung. --Liebe Grüße, LómelindeDiskussion08:50, 20. Dez. 2019 (CET)
Willst Du stänkern? So eine Tabelle wie Du sie hier darstellst, gibt es nicht in Artikeln von mir, auch nicht rosarot und nicht gelb-grau. Ich setze diese Formatierung nur unter bestimmten Bedingungen ein. (Sportliche Absteiger, die dann doch nicht absteigen und vice versa.) Dir muß nicht alles gefallen, was andere in Artikeln verwenden. --Tommes✉16:09, 20. Dez. 2019 (CET)
Es widerspricht den Richtlinien für Farbverwendenung, das ist dir doch wohl klar. Deine Artikel machen einen Großteil der Verwendung des unerwünschten Formats background: linear-gradient aus. --Liebe Grüße, LómelindeDiskussion16:25, 20. Dez. 2019 (CET)
Wenn jetzt genug Alternativbeispiele geklärt sind würde ich gerne auf meine Frage zurückkommen. Ich hoffe immer noch auf inhaltliche Rückmeldungen. @Lómelinde wie wäre es statt mir deine Mutmaßungen und Andeutungen vor die Füße zu werfen meiner Aussage den Respekt der Ernsthaftigkeit entgegenzubringen. Meine Nachfrage bezieht sich auf eine noch zu erstellende Vorlage, welche die Umsetzung der neueren taktischen Zeichen angehen soll. Also bitte, inhaltliche Hinweise erwünscht. -- Gunnar💬09:34, 5. Jan. 2020 (CET)
All Coordinates, Rücksprunglinks bei Umlauten im Lemma
Ich habe in einer Liste Liste_von_Aussichtstürmen_in_Brandenburg Koordinaten eingebaut und ein All coordinates-Link unten angefügt. Frage: wenn ich nun oben auf oben auf
"Karte mit allen Koordinaten" und OSM klicke, erscheint dann, so wie es sein sollte, die Karte und links die Liste mit den Einzelobjekten, wo beim Mouseover das entsprechende Symbol auf der Karte rot wird.
Was aber nicht funktioniert, ist: wenn ich links in der Liste auf ein Objekt klicke, kommt man nicht wieder in die Liste zurück und es erscheint eine Fehlermeldung: "Liste von Aussichtstürmen in Brandenburg - diee Seite existiert nicht." Liegt nicht an mir, wenn ich in die Liste_der_Stolpersteine_in_Düsseldorf oder in die Liste der Baudenkmale in Jüterbog gehe, habe ich dasselbe Problem.
Liegt definitiv an den Umlauten im Lemma. Für Lemmata ohne Umlaute geht es. Vermutlich spielen da wechselnden Umlautkodierungen zwischen OSM und Wikipedia mit rein. Kann man da etwas machen? --Global Fish (Diskussion) 10:14, 23. Dez. 2019 (CET)
Das Problem habe ich auch und auch schon oft reklamiert. Nicht alle kennen UTF-8. Scheinbar traut sich da niemand ran. --Klaus-Peter10:24, 23. Dez. 2019 (CET)
(BK)
Vermutlich.
Wenn „man“ du selbst bist, noch dieses Jahr.
Lies mal in ansiPercent@WLink und tüftele, ob du es damit gewuppt bekommen würdest.
Der Plan: An das Dingens, was dieses Rückwärtslink erzeugt, soll nicht das „ü“, sondern ein schon runterkodiertes „ü“ übergeben werden; vielleicht muss das aber auch mit normalem UTF-8-Encoding passieren.
Das müsste aber ggf. in Vorlage:All Coordinates passieren, und da könnte es dünn mit dieser Werkstatt werden; diese Vorlagen pflegt besser zentral das Geo-Projekt und behält den Überblick.
Danke an Euch für die Erklärungen! Nein, ich bin leider nicht dieser "man". Ich kann Vorlagensyntax so halb verstehen und analog anwenden, aber nicht tiefer weiterentwickeln. Grüße, --Global Fish (Diskussion) 12:07, 23. Dez. 2019 (CET)
@Global Fish: Du müsstest dich an das Geo-Projekt wenden; die koordinieren Koordinaten.
Diese Werkstatt hier pfuscht denen nicht in ihr Zeugs.
Die haben dort Erfahrung, wie welche Website mit was für Werten klarkommt; das muss nicht für alle Dienste gelten und ist nicht allein auf unserer Vorlagenseite pauschal lösbar. Dass da manche Angebote Encoding-Probleme haben, wissen wir schon seit langem.
Na ja, ich habe mir mal gerade Vorlage:All Coordinates etwas reingezogen und auf dem ersten Blick sehe ich da paar Aufrufe für Pearl-Programme. Peaerl kennt standardmäßig kein UTF-8, das muss man der Perle erst ausdrücklich befehlen (use utf8; bzw. binmode(STDOUT, ":utf8");). Vermutlich haben das unsere englischsprachigen Freunde entwickelt, denen Sonderzeichen nicht ins linguistische Denkbild passen. Es sind ja nicht nur Umlaute, sondern ALLE Sonderzeichen, Kyrilisch, Arabisch ... usw. --Klaus-Peter10:50, 23. Dez. 2019 (CET)
Soeben habe ich festgestellt, das Vorlage:All Coordinates nicht mehr osm4wiki bedient, aber nun recht ordentlich wikimap. Vielleicht sollte man osm4wiki vorübergehend während der Bearbeitungsphase ausblenden/deaktivieren.--Klaus-Peter09:08, 7. Jan. 2020 (CET)
Neue Infobox „Personenwahl“/„Präsidentschaftswahl“
Hallo,
ich habe folgende Bitte an die Experten der Vorlagenwerkstatt: es gibt wohl bisher keine gute allgemeiner anwendbare Infobox für Personenwahlen (z. B. Präsidentschaftswahlen, aber auch z. B. Oberbürgermeisterwahlen u. ä.).
Ich habe aber gesehen, dass von Benutzer:Christian140 die Infobox Vorlage:Infobox Präsidentschaftswahl in Südkorea gebastelt wurde, die er wohl im wesentlichen von der Vorlage:Infobox Präsidentschaftswahl in Polenübernommen hat.
Diese Infobox gefällt mir optisch sehr gut (siehe z. B. hier) und ich fände es gut, wenn wir eine ähnliche allgemeinere generische Infobox hätten, die man für jedes beliebige Land anwenden könnte. Man könnte versuchen, die Infobox so generisch zu gestalten, dass sie für alle möglichen Personenwahlen anwendbar wäre („Infobox Personenwahl“), oder so, dass sie spezifisch für Präsidentschaftswahlen („Infobox Präsidentschaftswahl“) anwendbar wäre. Beides wäre auf jeden Fall eine große Hilfe. Ich bin kein Vorlagen-Experte und würde hier sicher eine ganze Weile herumbasteln müssen. Könnte ein Geübter aus der Vorlagenwerkstatt das bitte in die Hand nehmen? Vielen Dank --Furfur ⁂ Diskussion14:45, 1. Dez. 2019 (CET)
Mag sein, aber nicht im Auftrag einer Einzelperson.
Es müsste eine Redaktionskonferenz der Politik oder sowas das Datenmodell beraten.
Wenn diese dann zu dem Schluss kommt, dass Personenwahlen mit sowas ausgerüstet werden sollen, dann muss zunächst ein allgemeines abstraktes Datenmodell mit allen Aspekten aller globalen Systeme erarbeitet werden.
Der/die Kandidaten, die zur Wahl standen / noch stehen.
1., 2. Wahlgang, noch mehr?
Stichwahl?
Wer in welcher Partei oder unterstützt durch welche Bündnisse?
Termine der 1., 2., 3. Wahlgänge
Für welches Amt? In welchem Staat oder Gebiet oder Organisation (Partei, Verband)?
Kandidaten der Stichwahl
Doppelspitze (B90/G, SPD)
Periode, Jahr, …
Weitere Aspekte
Das wäre dann eine allgemeine, abstrahierte Vorlage mit einheitlichem Design, und aufbauend auf dieser kann dann relativ einfach für eine bestimmte Serie von XY-Wahlen das Schema befüllt und mit Schaltern versehen werden, und daraus ein spezifischer Artikel ggf. ohne gesonderte Vorlage mit den Angaben befüllt werden, oder aber für die gesamte Serie gleichartiger Vorgänge würde eine eigenständige Infobox programmiert werden, die konstante Angaben an die abstrakte Basisvorlage durchreicht.
Nach einer Diskussion auf der Diskussionsseite des WikiProjekts Politik besteht jetzt Konsens, dass die oben beschriebene Infobox den „Normalfall“ abbilden soll. Das hieße:
Datum der Wahl(en)
mehrere Kandidaten sind möglich (bis zu vier)
Wahltermin(e) sollten genannt sein
erster und eventueller zweiter Wahlgang sollten abgebildet sein
Parteizugehörigkeit sollte, wenn sinnvoll, genannt werden können, aber nicht die unterstützenden Parteien
keine Doppelspitze
Die anderen Informationen können im Fließtext genannt sein. Ich fände, wie schon erwähnt, die derzeitige Vorlage:Infobox Präsidentschaftswahl in Südkorea optisch ganz ansprechend. Diese Infobox lässt aber wohl nur die Darstellung eines Wahlgangs zu. Ein Vorschlag wäre, dass man die Balken, die den Stimmenanteil anzeigen, entsprechend verschmälert und dann eben zwei Balken mit Prozentzahlen für den ersten/zweiten Wahlgang mit entsprechenden Indexnummern (1., 2.) für den ersten/zweiten Wahlgang verwendet. Grüße --Furfur ⁂ Diskussion12:44, 1. Jan. 2020 (CET)
Frohes Neues, eine Rückfrage hätte ich noch:
Was ist mit Primaries? Gibt einen wesentlichen Abonnenten der neuen Infobox, für den das irgendwie relevant sein könnte. Besser vorher sauber den Parametersatz definieren als hinterher fluchend umschmeißen und rumfrickeln.
Ansonsten ist das Fließband-Handwerk für routinierte Werkstattler, basierend auf dem genannten Südkorea-Muster. Weitere soeben nicht explizit genannte Parameter:
Wie heißt die Funktion?
Welche Periode?
Logo: Standarte des Bundespräsidenten (DE), Seal of POTUS.
Definitiver Wahlausgang.
Vier Kandidaten für den Start; falls eines Tages _5 oder _6 sinnvoll würden, lässt sich das ja beliebig ausdehnen.
Gleichfalls noch verspätet ein gutes neues Jahr! Die Primaries waren jetzt nicht mit auf der Wunschliste. Ich denke, das wäre auch definitiv zu viel und würde verwirren, wenn sowohl Primaries, und möglicherweise zwei Wahlgänge aufgeführt würden (bei der Gelegenheit sehe ich jetzt gerade, dass es auch schon eine Vorlage:Infobox Präsidentschaftswahl in den Vereinigten Staaten nach ganz ähnlichem Muster und in ganz ähnlicher Optik gibt – da sind die Primaries auch nicht integriert, allerdings die Wahlmänner im Electoral College und Parameter für die Kartenlegende). Grüße --Furfur ⁂ Diskussion01:32, 3. Jan. 2020 (CET)
Was ist der Grund warum sie nicht von den zentral definierten Parteifarben Gebrauch macht? Erscheinen die zu blass? Ein Ausschlussgrund, die amerikanische Präsidenten-Infobox nicht auch mit einzubinden ist das meiner Ansicht nach nicht unbedingt. In der Vorlage Wahldiagramm kann man beispielsweise auch selbst gewählte Farben verwenden, das müsste auch in der hier projektierten Infobox möglich sein, da viele Parteien ja gar keine zentral definierten Parteifarben haben. --Furfur ⁂ Diskussion01:06, 8. Jan. 2020 (CET)
Diskussion:Die_Tageszeitung#Auflagenvergleich-relativ_liefert_keine_zuverlässigen_Ergebnisse - Die Tageszeitung
Danke an alle Beteiligten! Viele Grüße --Maddl79orschwerbleede! 16:16, 8. Okt. 2019 (CEST)
15:15, 16. Okt. 2019 (CEST)
Sir Gawain Disk. 17:05, 28. Okt. 2019 (CET)
Sir Gawain Disk. 10:59, 29. Okt. 2019 (CET)
Ägypten, arabisch جمهوريّة مصر العربيّة Dschumhūriyyat Misr al-ʿarabiyya
--Wurgl (Diskussion) 18:30, 15. Nov. 2019 (CET)
. Hat somit in einer Vorlagenwerkstatt nichts zu Suchen.
UdSSR
Berlin
oder Achtung: Das Objekt WTA player ID auf Wikidata existiert noch nicht [70044] = Steffi Graf 
(Diskussion) 21:28, 16. Nov. 2019 (CET)
Bilder und Medien
Vorlage
Tabelle
Mehr
Rik VII. my2cts 09:19, 23. Dez. 2019 (CET)
Rik VII. my2cts 19:15, 23. Dez. 2019 (CET)
16:33, 23. Dez. 2019 (CET)
Umhausen
Thomas 12:17, 10. Dez. 2019 (CET)
Thomas 16:29, 10. Dez. 2019 (CET)
(CallMyCenter) Wikinews ist nebenan! 08:30, 6. Jan. 2020 (CET)
