Diese Seite bietet eine Übersicht der archivierten Diskussionen der Vorlagenwerkstatt. Die Abschnitte der einzelnen Archive sollten nicht mehr verändert werden.
Datumsformat des Webarchives "Waybackmachine" vs. Datum des Mementos generiert von der Vorlage Webarchiv
Hallo,
ich habe noch nicht viel Erfahrung im Einbinden von Webarchiven aber mir fiel bei einer Vorbereitung für einen Artikel folgendes auf. Ich ließ bei web.archive.org (Waybackmachine)
am 5.April 2019 folgende Webseite speichernː https://www.geosight3d.com/geosight-support-5-deeps-expedition.
Die Waybackmachine Nummer habe ich dann wie in die Vorlage Webarchiv eingetragen.
Hat web.archiv.org etwas am Format der Datumsangabe geändert oder ich habe nur die Existenz eines alt bekannten Bugs für mich neu entdeckt? Denn wie zu sehen ist gibt die Vorlage aus, dass das Memento vom 04.Mai 2019 ist, die Wayback Maschine schaut also nicht zurück sondern nach vorn. ;-)
Komisch: Bei mir wird zum obigen Link "20190405103521" angezeigt, also 2019-04-05 – obwohl du selber "20190504103521" (2019-05-04) angegeben hast. Vielleicht hat das Webarchiv KI ?
Vielen Dank Chiananda für das Korrigierenǃ Ich habe wohl den Fehler gemacht nur die letzten Ziffern der Waybacknummer einzugeben und der Dreher im Datum geht auf mein Konto.
der obige link mit 20190504103521 fuehrt auf keinen existenten fund, sondern wird von archive auf den naechsten existenten weitergeleitet. im header der ersten antwort von webarchive steht auch:
x-archive-redirect-reason: found capture at 20190405103521
also ist die frage, wie du zu dem obigen parameter wayback=20190504103521 gekommen bist. hast du immer mit copy-&-paste gearbeitet oder diesen datums-teil abgetippt (und dich dabei evtl. vertippt)? -- seth14:39, 7. Apr. 2019 (CEST)
Die dahinter stehende Datenbank hat die Urls verschoben, so dass die bisherigen Einträge ins Leere gehen. Irgendwie wird mir nicht klar, welchen Teil der neuen Url nunmehr in die Vorlage einzutragen wäre oder ob die Vorlage insgesamt umgestellt werden müsste. Schaut mal jemand rüber? Vielen Dank!--Rik VII.my2cts12:16, 6. Apr. 2019 (CEST)
Sieht für mich so aus, als würde die bisherige ID nicht mehr ausreichen, um einen funktionierenden Link zu generieren. Wenn das stimmt, müsste die Vorlage um mindestens einen Parameter (Name in der dortigen Datenbank) erweitert und alle Artikel entsprechend ergänzt werden. Vielleicht erst mal dem dortigen Webmaster eine Mail schicken und fragen, ob der Zustand jetzt stabil ist und ob es eine Möglichkeit gibt, weiterhin nur mit der ID einen Link aufzubauen.--Mabschaaf12:27, 6. Apr. 2019 (CEST)
Danke für die prompte Rückmeldung. Nachfrage beim Webmaster ist natürlich sinnvoll.
Ich sehe gerade, dass sich die bisherige Id im Mittelteil versteckt (hier:833) Interessant ist, dass in der Url nunmehr der Klarname relativ rasch hinter der Datenbank-Art auftaucht, wie bei der PCS-Datenbank, wo wir dies für eine Abfrageoption in der Vorlage:ProCyclingStats nutzen. Kann man darauf aufbauen?--Rik VII.my2cts12:35, 6. Apr. 2019 (CEST)
Das hatte ich schon gesehen. Evtl. Kann man mit Hilfe des hiesigen Lemmas etwas konstruieren, aber das geht mit großer Wahrscheinlichkeit schief, wenn Umlaute enthalten sind (Gerben Löwik), Akzente (René Wolff), ggf. Zweitvornamen/Namenszusätze etc. - kurz, wenn das WP-Lemma von der Namensbezeichnung in der dortigen URL abweicht. Dafür bräuchte es eben wie in der Vorlage:ProCyclingStats einen zusätzlichen Parameter.--Mabschaaf19:50, 6. Apr. 2019 (CEST)
Das Ganze liefe ja - vorbehaltlich der erfolgten Nachfrage bei rad-net - darauf raus, die Vorlage zu ändern UND alle Einbindungen. Ich spreche es mal auf dem Portal an. Nicht das wir (Portal) hier (Vorlagenwerkstatt) Arbeit machen, die dann auf kein großes Interesse stößt.--Rik VII.my2cts20:55, 6. Apr. 2019 (CEST)
Schönheitsfehler bei Vorlage:Infobox Schiff/Sonstiges
Hallo,
ich habe nach dem Einbinden der Vorlage:Infobox Schiff/Sonstiges beim Anschauen des Artikles gemerkt, dass die Textzeile beim Parameter "Klassifizierungen" nicht auf gleicher Höhe ist wie die Textzeile zum Klassifizierer siehe Beispiel bei der Infobox zur Polarstern (Klassifizierung - Germanischer Lloyd)oder bei der Queen Mary 2. Lässt sich da mit wenig Aufwand etwas ändern z.B. das Wort Klassifizierungen vertikal mittig zentrieren so dass es auf gleicher Höhe dargestellt wird oder kommen dann andere Nutzungen der Vorlage durcheinander?
Auch diese Vorlage scheint wieder einen Fehler zu haben, wie sie schon die Vorlage:Turnierplan24 hatte. Sofern es Eintragungen gibt und die Paramater für die erste Partie der ersten Runde nicht benutzt werden, gibt es dennoch einen verbindenden Strich zwischen dem ersten Spiel der zweiten Runde und dem der ersten Runde (siehe bspw. hier). Nachdem ich nach einem Hinweis auf meiner Disk. auf den Fehler aufmerksam gemacht wurde, habe ich alle entsprechenden Parameter der Vorlage mit denen der von euch schon verbesserten Vorlage:Turnierplan24 ergebnislos verglichen und auch selbst versucht, einen etwaigen Fehler beim Erstellen zu finden, auch dies ohne Ergebnis. Wisst ihr dankenswerterweise Rat? Grüße, --Snookerado (Diskussion) 20:43, 7. Apr. 2019 (CEST)
Kann sich mal jemand diese Vorlage ansehen? Für mich armen alten Mann sind die Zeichen bei normaler Schriftgröße kaum zu unterscheiden...-- Leif Czerny12:57, 2. Apr. 2019 (CEST)
Was genau möchtest du denn verändert haben, die Größe, Dicke, siehe auch Dateien ((Venussymbol))((Marssymbol))
Halo Lomelinde, sprengt "larger" nicht die Zeilenhöhe bei der inline-Verwendung? Sonst fände ich as nämlich gut so. Bei Hintergrundfarben wird bestimmt wieder gestritten, welche da jeweils zu wählen werden, obwohl das natürlich klarer erkennbar ist.-- Leif Czerny13:36, 2. Apr. 2019 (CEST)
Das kann wohl sein, ♂ aber man könnte ja einen Parameter dazusetzen mit dem man die Größe einstellen kann, leider sind die symbole sehr winzig, selbst das bold funktioniert bei den beiden oberen nicht. Einfacher wäre es daher mit den Dateien zu arbeiten entweder blauer Mars (10px) oder schwarz (15px), Male , Gendersign (12px) na ja auch sehr klein, (12px). Aber ich weiß ja schließlich nicht wozu du das verwenden möchtest. --Liebe Grüße, LómelindeDiskussion13:59, 2. Apr. 2019 (CEST)
Ich habe jetzt mal einen Tooltip ergänzt. Wichtig ist auch, dass Sortierbarkeit unterstützt wird. Außerdem: Würde die Disku nicht hier, sondern auf der Vorlagen-Disk geführt, würde auch der Vorlagen-Autor und Interessierte etwas davon mitbekommen. Aber man bleibt wohl lieber unter sich und kommuniziert per LA … -- Wolfgang Rieger(Diskussion)14:10, 2. Apr. 2019 (CEST)
Zur Kommunikationstechnik:
Diese Werkstatt führt die Erörterung immer dort fort, wo sie begonnen wurde.
Mit der ersten Reaktion seitens der Werkstatt wurde der Vorlagenersteller mit angepingt.
Dass hier ein direkterer Kommunikationsweg zielführender gewesen wäre, wurde auch bereits in der ersten Reaktion seitens der Werkstatt angemerkt.
Alle weitere Erörterung zu bereits eröffneten Aspekten wird im selben Thread weitergeführt und beendet, wo dies auch angefangen wurde.
Eine „Kommunikation per LA“ müssen demnach die Geisteswissenschaftler unter sich ausmachen; da diese Werkstatt unverzüglich den Vorlagenersteller einbezogen hatte, kann „bleibt wohl lieber unter sich“ sich nicht auf diese Werkstatt beziehen.
data-sort-value= kann nur eine Eigenschaft einer Tabellenzelle sein.
Als Attribut eines anderen HTML-Elements, das keine Tabellenzelle ist, muss es unwirksam bleiben, weil ansonsten nur der Inhalt von HTML-Elementen von der Sortierung berücksichtigt wird, nicht aber deren Attribute.
Ich wüsste nicht, dass ich einen LA auf die Vorlage gestellt habe. Von der Verwendung der Vorlagen-Disk hingegen wird ja per Hinweis abgeraten. Daher habe ich es hier versucht. Ob der Löschantragsteller jetzt unbedingt als "Geisteswissenschaftler" unterwegs ist, kann ich nicht sagen, sein Löschgrund ist ja eher formaler Natur--- Leif Czerny15:11, 2. Apr. 2019 (CEST)
Ich habe auch keinen LA gestellt, ich habe lediglich Vorschläge zur Veränderung gemacht. Ich finde diese Unterstellung von wegen „unter sich bleiben“ auch absolut unpassend, zumal Wolfgang gleich zwei „Pings“ von unterschiedlichen Personen bekommen haben sollte, es sei denn, er hat das deaktiviert. --Liebe Grüße, LómelindeDiskussion16:17, 2. Apr. 2019 (CEST)
Von der Verwendung der Vorlagen-Disk wird nicht „per Hinweis abgeraten“ – es wird dort darauf hingewiesen, dass bei vor längerer Zeit durch einen möglicherweise auch gar nicht mehr aktiven Benutzer erstellten Vorlage diese und damit auch die Disku möglicherweise auch keinerlei Beobachter mehr haben könne. Hintergrund ist, dass ich auch schon in jüngerer Zeit Vorlagen-Disku gefunden hatte, bei denen 2009 eine Frage oder Fehlermeldung zu einer 2007 erstellten Vorlage auflief, deren Ersteller aber schon seit 2008 nicht mehr aktiv war. Weshalb es nie eine Antwort gab. VG --PerfektesChaos16:36, 2. Apr. 2019 (CEST)
Im Nachgang möchte ich aber darauf hinweisen, dass das m.E. ein technisches Problem wäre, und kein inhaltliches. Im Standardkasten wird man damit aber auf die Werkstatt verweisen. -- Leif Czerny13:34, 3. Apr. 2019 (CEST)
Das Problem hier ist erstmal nicht, dass die Symbole zu klein wären, sondern dass sie überhaupt keine konsistente Größe haben. Die hängt nämlich von der Schriftart und damit (bisher) vom Betriebssystem ab. Anscheinend sind ♀ und ♂ in einigen Schriftarten sehr klein. Außerdem hat nicht jede Schriftart die anderen Symbole, sodass die entweder aus einer anderen Schriftart entnommen werden oder gar nicht funktionieren (so bei mir unter Firefox auf Android).
Ich ergänze die Vorlage mit einer expliziten Schriftartanweisung, sodass die Darstellung unter Linux und Android ordentlich funktionieren sollte. Was andere Betriebssysteme angeht müsste das jemand machen, der auch prüfen kann, welche der dortigen Schriftarten alle Symbole enthalten.
Hallo Universalamatuer, da hast Du ganz recht, die Variabilität ist das Problem - meine Grundgröße ist für text ganz got, aber nicht für diese Symbole. Dass wir keinen webfont haben, der das kann, ist schade. Was ist mit den math-fonts von tex? Die werden ja gerendert. Gibt es ein Paket mit astronomischen Symbolen, das geladen wird? -- Leif Czerny10:23, 3. Apr. 2019 (CEST)
Das würde wieder das Größenproblem auslösen zudem werden die Symbole, soweit ich weiß nicht unterstützt. Es könnte jedoch als Text eingebunden werden nur wird es dann zum Bild und ist somit nicht für alle Verwender „sichtbar“. Auch da zeigt sich der Unterschied in der Größe der einzelnen Zeichen. Wobei ich noch immer nicht weiß wie das untere n = Zeichen ∅? aussehen soll, da ich da nur dieses merkwürdige Kästchen sehe. --Liebe Grüße, LómelindeDiskussion11:06, 3. Apr. 2019 (CEST)
Ich blicke nicht ganz durch und Frage nochmal - es gibt passende LaTex-Pakete, aber die werden nicht geladen, und wenn doch, dann wären sie nicht semantisch lesbar, da Bilder? Aber wie soll das mit der Font-Einbindung eines nicht-Webfonts gehen? Mit der aktuellen font-family-Anweisung werden bei mir die Symbole in der Tabellenzeile leider oben und unten abgeschnitten angezeigt... Liebe Grüße -- Leif Czerny11:14, 3. Apr. 2019 (CEST)
Da WolfgangRieger meine Änderungen wieder rückgängig gemacht hat und anscheinend die inkonsistenten Größen bevorzugt, ist das jetzt auch egal. In der Form wäre es besser, die Vorlage zu löschen. --Universalamateur (Diskussion) 11:44, 3. Apr. 2019 (CEST)
Also, wir haben uns in dieser Angelegenheit bereits mit zwei Löschanträgen zu beschäftigen gehabt.
Jetzt sollte erst mal abgewartet werden, bis der LA auf die Vorlage entschieden wurde.
Danach können wir mal schaun, wie zur Verwendung in Tabellen sowie in Fließtext auf Mobilgeräten und bei allen Desktop-Browsern eine allen Anforderungen bestmöglich entgegenkommende Lösung aussehen kann.
TeX ist zum einen auf mathematische Zeichen spezialisiert, und kann nicht intersexuell, und deren Darstellungssystem bringt eine eigene Pandorabüchse an Problemen mit sich, gerade was Einbettung in Fließtext anginge.
Bis dahin sollten keine hektischen unabgesprochenen Basteleien ablaufen.
@Universalamateur, genau aus dem Grunde habe ich meine Finger auch von der Vorlage gelassen und schrieb oben: „der wird mir auf die Finger hauen wenn ich an ‚seiner Vorlage‘ herumpfusche“. Er ist etwas „eigen“. --Liebe Grüße, LómelindeDiskussion11:51, 3. Apr. 2019 (CEST)
Ach was, sei mutig gilt auch weiterhin. dafür gibt es ja im Zweifelsfall Versionsgeschichte. LaTex hat hier in Table 333 die "fontawesome" Biological Symbols, die wären doch ganz gut. Ist die Extension:FontAwesome in der de-wiki installiert? -- Leif Czerny12:15, 3. Apr. 2019 (CEST)
OK, das sieht auch für mcih in jedem fall besser aus, auch weil dann die Kreis-Anteile der Symbole nicht so arg unterschiedlich groß sind. Was ist mit der Zeilenhöhe? Liebe Grüße -- Leif Czerny13:31, 3. Apr. 2019 (CEST)
Als interessierter Mitleser verfolge ich aufmerksam dieses Problem mit der Darstellung der Genderzeichen. Die beiden ♂ und ♀ setze ich gerne in Tabellen ein – aber in Fettschrift (in Kopfzeilen) verschwimmen die: ♂ ♀, mit doppelter Fettsetzung (style plus ' ' ' ) werden sie kleiner, aber deutlicher: ♂ ♀. Aus der Testseite vom Universalamateur entnehme ich, dass die Schrift "DejaVu Sans" das beste Ergebnis liefert: ♂ ♀ ⚧ + ♂ ♀ ⚧ + ♂ ♀ ⚧.
Zunächst wird unter den Beteiligten eine Strategie abgesprochen.
Das beträfe auch zusätzlich einzuführende Parameter für verschiedene Zwecke.
Unterschiedliche Einsatzgebiete sind zu bedenken.
Nachdem ein gemeinschaftlicher Lösungsweg abgestimmt wurde, wird das testweise außerhalb des Normalbetriebs implementiert und durchgespielt.
Erst nachdem die Erprobung erfolgreich war, wird die Programmierung der produktiven Vorlage angefasst und verändert.
Was die Wünsche nach mal diesem, mal jenem Font angeht:
Niemand kann wissen, was bei einem Leser überhaupt installiert ist, noch weniger, was sich jemand in seinem Browser konfiguriert hätte; an Schriftarten und Schriftgrößen und wie gut die Augen noch sind.
Auch Fonts gleichen Namens können bei den nicht-alphanumerischen Zeichen, also gerade bei den in Rede stehenden Symbolen, im Design und in der Größe unterschiedlich ausfallen; je nach Betriebssystem und Alter der Installation.
Aus dem Umstand, dass Benutzer X findet, bei ihm sähe das aber nett aus, lässt sich nicht schließen, dass das für alle Leser gut aussähe; noch nicht einmal, dass auf den Rechnern aller Leser überhaupt Zeichen für nicht-traditionelle Orientierungen vorhanden wären; und dass die dortige Software sie ggf. auch aus anderen Fonts zuliefern würde.
Bis zur Entscheidung über den LA ist Moratorium angesagt; bei Verbleib wird das angefragte Werkstattpersonal anschließend die zukünftigen projektweiten Einsatzgebiete und robusten Umsetzungen erörtern.
Ich wüsste nicht was ich hier erörtern soll, ich fasse diese Vorlage nicht an. Wolfgang [wert]schätzt meine Mitarbeit absolut nicht. Im Gegenteil. Daher war alles was ich tun konnte Vorschläge zu unterbreiten, das „Geht’s noch“ zu einer ‚wie auch immer gearteten‘ farblichen Kennzeichnung, sagt doch alles. Es geht besser ‚ohne mich‘. Für dich hätte ich es getan. Aber Wolfgang vertreibt mich, wie schon andernorts geschehen, da habe ich mich sogar gänzlich zurückgezogen. --Liebe Grüße, LómelindeDiskussion11:07, 10. Apr. 2019 (CEST)
Das verstehe und bedauere ich. Meiner Meinung nach wären Font-size und line-height, wie auf der Testseite, ja schon hinreichend. Aber ich kann nicht abschätzen, ob das jetzt wieder aus irgendwelchen Gründen höchst unerwünscht oder technisch falsch oder sonstwas ist. M. E. ist das aber nach wie vor ein technisches, und kein inhaltliches Problem, und ich wüsste gerne, ob eine solche Lösung in Ordnung wäre, oder es andere varianten gibt.-- Leif Czerny11:32, 10. Apr. 2019 (CEST)
Das kann ich dir nicht beantworten, dafür reicht mein Wissen nicht aus. Was mir noch immer fehlt ist das neutrale Symbol, denn da sehe ich noch immer nichts als ein DummySymbol. ⚲ Und so etwas halte ich dann für eher ungünstig, wenn es nichts als ein Kreis _ sein sollte, gäbe es da sicherlich irgendetwas. --Liebe Grüße, LómelindeDiskussion12:22, 10. Apr. 2019 (CEST)
Gleiche Erfahrungen habe ich mit dem autistischen Herrn auch schon gemacht bzgl. seiner Vorlage:Nnbsp: Eine zweckmäßige Vorlage, aber unter seinem Gehört-nur-mir-Anspruch stehend.
Andere als den hier bereits belegten allgemeinverständlichen Namen werden sich nicht verwenden lassen; und ich wüsste keinen kurzen selbsterklärenden intuitiven nichtkollidierenden Begriff.
Zwangsverschiebung in den BNR bedürfte einer administrativen Entscheidung.
Oben hatte jemand ein Sei mutig! eingeworfen, in der Erwartung, dass dies jemand anders an seiner Stelle machen würde.
Die weitere Erörterung erfolgt geschlossen auf der Vorlagendisku, damit das zusammenbleibt. Dort mag man auf die hiesige Disku hinweisen, bzw. auf deren zukünftige Archivierung.
Für diese Werkstatt ist die Angelegenheit nunmehr erledigt; alle technischen Fragen sind ausdiskutiert.
Als ich damit durchkäme, wenn ich das allein versucht hätte,. Ich weiß schon, warum ich vorher frage. Und ein naheliegender Name wäre natürlich Vorlage:Gender. Man kann es sich auch schwer machen. Und meine eigentliche Frage, wie man die Zeichen vergrößern kann, ohne die Zeilenhöhe zu stören, ist m.E. nicht geklärt. Naja, trotzdem danke.-- Leif Czerny09:37, 11. Apr. 2019 (CEST)
Unterdrückung der Anzeige einer Falschschreibung in den Suchergebnissen bei korrekt eingegebenem Lemma
Guten Abend. Ich finde, dass, wenn ein korrekt geschriebener Begriff in die Suchzeile eingegeben wird, zu dem es auch eine oder mehrere Falschschreibungen gibt (Bsp. Reiner Calmund richtig in die Suchzeile eingegeben, erscheint auch Rainer Calmund (falsch), um da mal ein einfaches Beispiel zu nennen, oder Kreißsaal (richtig), erscheint auch Kreissaal (falsch)), die Falschschreibung nicht in den Suchergebnissen angezeigt werden sollte, da dies zu Verwirrungen führen kann. Ist das denn über die Vorlage möglich, muss da an der Wiki-Software rumgespielt werden, oder geht das überhaupt nicht?
Die Karte ist etwas schwierig einzupassen, weil wenig zu sehen ist und der Fluss recht stark generalisiert ist, aber im Großen und Ganzen sollte es so funktionieren. Ich mache sowas übrigens mit Google Earth, wo ich die Bilder als Bild-Overlay lade und dann so gut wie möglich einpasse. Dort liest man dann die Koordinaten ab, die die obere und untere, die linke und die rechte Kartenseite bezeichnen. NNW18:41, 10. Apr. 2019 (CEST)
eigentlich wollte ich im Artikel Iljuschin Il-2 nur friedlich die Normdaten nach unten verschieben, um den zu großen Zeilenabstand verschwinden zu lassen. Dabei fiel mir folgende Einbindung auf:
Das taucht auch in anderen Artikeln zu Il-Flugzeugen auf, sonst habe ich es nirgends gefunden. Hat der zweite "Parameter" da irgendeinen Sinn? Ich kann keine Wirkung feststellen und habe das so auch noch nie gesehen. Die Doku-Seiten zur Vorlage und zur Vorlage "Erweiterte Navileiste" haben mich nicht weitergebracht. Ist das Kunst, oder kann das weg?
Doku-Ergänzung in Vorlage:Zitat, betr. Vorlage:Zitat-de
Hallo, von Itti wurde ich von WP:AA hierher gewiesen, deshalb noch einmal die Kopie meiner Anfrage wie folgt:
Hallo, da die Seite gesperrt ist, wünsche ich die Einfügung einer Fußnote im Abschnitt Vereinfachte Fremdspracheneinbindung, in der Zeile Vorlage:Zitat-de, am Ende der Spalte nach deutsch mit »…« statt „…“ als Anführungszeichen
<ref>Die [[Vorlage:Zitat-de]] ist für den regulären Einsatz in enzyklopädischen Artikeln ungeeignet. Stattdessen wird hierfür auf die [[Vorlage:Zitat]] unter Verwendung der beiden mit <code>»</code> und <code>«</code> befüllten Parameter <code>|vor=»</code> und <code>|nach=«</code> verwiesen.</ref>
Steht so schon in der VL-Zitat-de-Doku. Die Gründe aus verschiedenen Diskussionen sind im Thread der VL-Zitat-Disku zusammengefasst. (Ein #EN müsste zudem neu erstellt werden.)
Hätte ich eigentlich wissen sollen, Lómelinde. Danke für den Doku-Link. Hatte vorher die VL-Seite selbst geöffnet, die nicht bearbeitbar war. Habe die Doku jetzt entsprechend geändert, falls von Interesse. Gruß, --Wi-luc-ky (Diskussion) 23:05, 24. Apr. 2019 (CEST)
Ich bastel grade ein bisschen an Infoboxen rum und habe dazu zwei Fragen:
Unter Voraussetzung, es gibt konsolidierte Parameter in Wikidata, ist es OK, die automatisch in eine IB einzubinden? Oder ist das noch zu „experimentell“ für den ANR?
Ist es sinnvoll, eine bestehende IB (ohne Designänderung!) auf die Vorlage:Infobox umzustellen? Ich würde mir das dann wartungsmäßig viel besser vorstellen: Falls es irgendeine technische Umstellung gibt, wären so doch alle betroffenen IBs gleich wieder aktuell ohne an vielen unterschiedlichen Stellen herumzudoktern.
Ja, machen manche Vorlagen, wird aber von einigen kritisch gesehen bzgl. Verfolgen von Änderungen und Belegbarkeit.
Besser nicht. Selbst im besten Fall verschiebst du damit nur Arbeit, aber wahrscheinlich ist die Arbeit umsonst. Im schlimmsten Fall will jemand in die Vorlage etwas einbauen das die Vorlage:Infobox nicht unterstützt, und dann muss alles wieder zurückgesetzt werden. --mfb (Diskussion) 12:49, 11. Apr. 2019 (CEST)
Zu Wikidata:
Wenn es sich um sich permanent ändernde Daten handeln solte, etwa wie jetzt grad der zuletzt gewählte Bürgermeister heißt, wäre das unter Beachtung der Anforderungen okay.
Wenn es um weitgehend konstante Daten geht, etwa wie viele Quadratkilometer der Landkreis groß ist, wäre Wikidata unnötig, macht die Rückverfolgung sehr schwierig, und gäbe Ärger; auch weil Wikidata im Gegensatz zu uns keine Sichtung oder wirksame Verifiaktionsprozesse nach Veränderung der Einträge hat. Heißt: Es lässt sich relativ unbemerkt vandalieren und fake news in alle das übernehmenden Wikis einschleusen.
Wenn konstante Angaben bereits in unserem Artikel stehen, wäre es definitiv nicht in Ordnung, diese bei uns zu eliminieren und durch die Vandalismus-anfälligen Einträge bei Wikidata zu ersetzen.
Wir haben auch aus der Vor-Wikidata-Zeit Mechanismen, um sich regelmäßig ändernde Informationen wie etwa Einwohnerzahlen zentral zu pflegen und auf Artikel zu verteilen.
Die ist dazu gedacht, um von Null aus eine Infobox im Standard-Design recht simpel zu erschaffen und seine spezielle Anwendung drüberzulegen, die speziellen Parameternamen dann zu übersetzen in Daten2 |Feldname2=Stadt |Daten2=Name der Stadt für diesen Artikel
Wenn es bereits eine ausgereifte erprobte Infobox gibt, hätte es weniger Sinn, diese zurückzubauen.
Cool, vielen Dank für die Antwort! Re. WikiData: Mein Gedanke war gar nicht, bestehende Parameter zu ersetzen. Ich wollte vielmehr nicht gesetzte Parameter per Fallback auf Wikidata setzen. Dann gibt es also keine grundsätzlichen Widerstände gegen sowas, insofern die zuständige Redaktion die WD-Datenbasis als ausreichend gesichert ansieht.
Man könnte dein Argument übrigens auch umkehren: Solange WD-Einträge nicht auf breiter Basis über Wikipedia präsentiert werden, bleiben sie mehr oder weniger unsichtbar und damit übermäßig fehleranfällig ;) Von meiner Warte aus überwiegen die Chancen bei einer Einbettung für das Wiki-Projekt insgesamt schon. Gibt es irgendwo vielleicht eine redaktionelle Diskussion zu solchen Richtungsentscheidungen?
Re. IB-Vorlage: Hätte gedacht, die Seitengestaltung könnte man auf Basis einer gemeinsamen Grundvorlage leichter vereinheitlichen. Habe aber auch festgestellt, dass das eigentlich schon über die css-Klasse infobox sichergestellt ist. Damit hat sich das zumindest dann wohl erledigt. Hatte halt die ursprüngliche IB selbst vor über nem Jahrzehnt angelegt, als es noch nicht soviele IBs und dementsprechend auch die leere VL noch gar gab. Inzwischen hat die IB durch viele Ergänzungen soweit an Struktur und Übersicht verloren, dass ich die eh mal überarbeiten möchte und dann hätte ich auf diesem Wege auch umgestellt… EiragornLet's talk about...Flachkräcker14:52, 11. Apr. 2019 (CEST)
@Eiragorn: „Man könnte dein Argument übrigens auch umkehren: Solange WD-Einträge nicht auf breiter Basis über Wikipedia präsentiert werden, bleiben sie mehr oder weniger unsichtbar“
99,999 % der Leser akzeptieren jeglichen in der Wikipedia angezeigten Zahlenwert oder Namen ohne weitere Prüfung, weil er durch die „Wikipedia-Redaktion“ ja bereits überprüft wurde.
Wikidata unterläuft das und ermöglicht Direktdarstellung beliebiger Inhalte.
Wenn man Hintertupfingen nicht grad eine Einwohnerzahl von Millionen zuschreibt, sondern die Einwohnerzahl bloß verdreifacht oder verfünffacht, wird das jahrelang niemand merken.
Unsere Autoren sind auch nicht dazu da, täglich sämtliche im Artikel sichtbaren Daten erneut mit amtlichen Quellen zu vergleichen, um herauszufinden, ob in den letzten 24 Stunden jemand auf Wikidata vandaliert hatte.
Viele Daten sind auch etwa Schlüsselnummern in Datenbanken, die zur Generierung von Verlinkungen genutzt werden, etwa von Filmen oder Musikern. Wenn diese einfach mal umgehängt, Goethe auf Schiller umgeleitet wird, würde das erst nach dem Anklicken des Links bemerkt werden. Deinen Vorstellungen nach müssten also die Autoren täglich sämtliche Verlinkungen in allen Artikeln anklicken, um Vandalismus auf Wikidata zu entdecken. Statt Personen schlicht zu tauschen, kann auch eine nicht existierende ID angegeben werden, dann kommt halt ein fehlender Datenbankeintrag heraus, daran wäre die Datenbank schuld, und auch das bleibt jahrelang unbemerkt.
Kurzum: Konstante Informationen gehören explizit bei uns hinterlegt, statt im Faulheitsmodus einfach nur eine leere Infobox in den Artikel zu klatschen und darauf zu hoffen, dass die sich schon irgendwie von selbst mit den richtigen Inhalten füllen wird. Wir haben Sichter, Wikidata nicht.
Nur bei sich permanent ändernden Daten ist der Rückgriff auf Wikidata mangels ausreichender Pflegekapazitäten bei uns vertretbar.
Wenn irgendwer mal mit einem großflächigen Datenvandalismus-Wirrwarr auf die Fresse fällt und ein ganzes Fachgebiet nicht mehr weiß, welche Informationen frei erfunden und welche noch gültig sind, gibt es keinerlei Gnade für vorsätzliche Dummheit.
Hab ich als Warnung auch von da mitgenommen ;) Solange das Ganze eine Einbahnstraße Data->Pedia ist, ist eine redaktionelle Überprüfung kaum möglich. Selbst hier schlupfen Kleinigkeiten tw. lange durch: ich selbst habe z.B. die Tage einen Fehler in ner IB eines Films geändert, der da seit über einem Jahrzehnt unverändert drinstand… EiragornLet's talk about...Flachkräcker18:00, 11. Apr. 2019 (CEST)
das wird sich jetzt dann übrigens schnell ändern. wikidata ist so "redaktionell" wie die WP, auch wir haben 10 jahre lang primär mit recht ungeniert eingetippsten daten hantiert. dass die "Quadratkilometer der [deutschen] Landkreise" von uns hier gepflegt werden, ist eh klar, aber einerlei, ob hier oder auf wikidata, sie werden eh sukzessive aus den amtlichen quellen von einem bot eingespielt, und dem ist egal, wo er sie hinterlegt. das "redaktionelle" bezieht sich nur auf die sorgfalt in der auswahl des zugrundegelegten quell-dokuments. und die quelle kann man auf wikidata genauso angeben wie bei uns. über die angabe der "Quadratkilometer der papuanischen Landkreise" hingegen wird sich jeder über wikidata freuen, wenn das die papuanischen kollegen erledigen, die wissen, was ihr vermessungsamt publiziert. auch die genauen "Koordinaten jedes burundischen Weilers" werden wir über wikidata abgreifen, dort wird die hauptreferenz via OSM erledigt werden. es werden sich also lokal zuständige, aber projektübergreifend arbeitende fachredaktionen bilden, um die verbindlichste koordinate und die aktuelleste flächenmessung zu eruieren. und die geographischen eckdaten der großen weiten welt werden das erste sein, was wir nurmehr zentral auf wikidata pflegen, nicht in lokaler eigenbrödelei.
wichtig ist nur, bei der abfrage die wikidata-quelle mit-abzufragen. aber ehrlich gesagt, 95% aller IBs der de:wp ist die beleglage der anggebenen daten auch heute noch völlig einerlei, fehlangaben zu finden ist nicht "redaktionelle arbeit", sondern meist purer zufall. also ja: es geht gerade jetzt, 2019, los, die lokalen und die zentralen daten per vorlage zu vergleichen und zu validisieren: vorerst aber im aufbau der infrastruktur, die direkte anwendung in infoboxen und automatisierten listen wird noch etwas dauern, weil sie an allen ecken noch hapert. --W!B: (Diskussion) 13:17, 13. Apr. 2019 (CEST)
@Rik VII. Ich habe noch zwei weitere ergänzt, ich frage mich aber, ob es nicht generell einfacher wäre in dieser Vorlage mit →ifexist zu arbeiten, dann würden die Links automatisch erscheinen, sobald es den Zielartikel dazu gibt. Du kannst das ja mal im Portal ansprechen. --Liebe Grüße, LómelindeDiskussion14:46, 15. Apr. 2019 (CEST)
O.k., dann anders, ich warte mal ab was mfb oder Hgzh dazu meinen. Ich möchte ungern so ganz ohne … na ja ist eben Radsportbereich, da sind meine Erfahrungen auf der Portaldisk immer irgendwie „ambivalent“ gewesen. --Liebe Grüße, LómelindeDiskussion15:39, 15. Apr. 2019 (CEST)
Verstehe, aber das Problem ist tatsächlich weniger eine andere technische Auffassung als unsere geringe technische Kompetenz. Das kann nerven, aber leider schwer zu vermeiden. Ich verlinke mal auf diese Diskussion.--Rik VII.my2cts15:44, 15. Apr. 2019 (CEST)
Als ich die Seite angelegt habe waren da nur ein paar wenige Links. Mittlerweile ist eine ifexist-Lösung sinnvoller. Ich habe das beispielsweise bei Paris eingebaut, bitte schauen ob das funktioniert wie gewünscht, wenn ja kann man den Rest ersetzen. --mfb (Diskussion) 16:11, 15. Apr. 2019 (CEST)
Ist tatsächlich nicht erwünscht, und war seit Anlage bereits auf meiner Beo und meinem Radar.
Würde Tausende von Präzedenzfällen schaffen, und wäre nicht mehr zu überblicken.
Das Zeichen ist seit Jahrzehnten kodiert, es muss also von jedem Benutzer grafisch wahrgenommen werden können, und das Verpacken eines vielleicht nicht darstellbaren Zeichens ist hier nicht erforderlich. Zusatznutzen liegt somit nicht vor.
Wenn überhaupt, dann machen wir nicht für ein einzelnes Zeichen eine einzelne Vorlage, sondern für eine große Familie wie etwa die Smileys usw., und die einzelnen Zeichen werden per Parameter spezifiziert.
Wir möchten nicht x-1000 Namen von Vorlagen verwalten, zumal Englisch, was ohnehin kein suchender Benutzer erraten würde, um damit alle möglichen einzelnen Unicode-Zeichen unter allerlei Bezeichnungen in Texte einfügen zu können. Wer sowas sucht, der möge sich an Sonderzeichen-Tabellen halten, oder fachliche Symbol-Legenden, und sich dann per C&P helfen. Notfalls geht erstmal HTML-Entity, das macht dann schon irgendwer platt.
SUBSTen würde sie ja als Präzedenzfall belassen, und ist keine zukunftsfähige Lösung.
@Leyo: Eine projektweite LD möchte ich vermeiden, wurde deshalb nicht tätig; falls du jedoch auf dem kurzen Dienstweg tätig werden möchtest, würde ich notfalls zur richtigen Uhrzeit einen SLA stellen.
Noch nicht erledigt. Warum wurden im genannten Artikel die double dagger jetzt mit Bildern ersetzt, anstatt mit dem Zeichen ‡? Und warum gibt es im Artikel keine Erklärung, wofür das Zeichen steht? 129.13.72.19712:50, 29. Apr. 2019 (CEST)
Das musst du denjenigen fragen der diese Zeichen in die Tabelle gesetzt hat, das hat nichts mit der Vorlagenwerkstatt zu tun. --Liebe Grüße, LómelindeDiskussion13:20, 29. Apr. 2019 (CEST)
Die Dinger sind gesubstet worden. War schon so, ist auch nicht weniger geworden.
Was irgendwelche Spezialzeichen im Filmgewerbe bedeuten müssen die Filmleute wissen; als Bildchen liefert es immerhin noch einen Alternativtext „Award“ gegenüber dem Unicode-Zeichen.
Unter Benutzer:Felix1411/Vorlagen hat der Benutzer eine Vorlage für Fußballvereine erstellt. Ich würde das auch gern für Handballvereine nutzen, nur müssten die Verlinkungen zu den Cupwettbewerben umgestrickt werden. Geht das?--scif (Diskussion) 12:52, 1. Apr. 2019 (CEST)
Gehen tut vieles, zumindest technisch.
Es gibt mehrere Strategien. Welche ihr angeht, müsstet ihr innersportlich entscheiden:
Die bisherigen Vorlagen werden verschoben, bekommen das Wort „Fußball“ in den Namen.
Dann wird vom letzten Stand eine Kopie gemacht, die bekäme „Handball“ in den Namen, und wird angepasst.
Die bisherigen Vorlagen bekommen einen zusätzlichen Parameter Sportart und der defaultet bei Nicht-Angabe zu Fußball, sollte aber zur Klarheit nach und nach auch bei den Einbindungen in bestehenden Artikeln nachgerüstet werden.
Anhand des Parameterwertes wird dann intern verzweigt.
Es werden neue Vorlagen ggf. mit „Fußball“, „Handball“ usw. erstellt; diese setzen erforderliche Links und Icons und Textstücke und verwenden eine für alle Sportarten gemeinsame „generische“ und zentral gepflegte Programmierung in nicht direkt in Artikeln auftretenden Vorlagen. Setzt voraus, dass allerlei Modi mit Zahl der Mannschaften und Turniersystemen und Punkten sehr analog sind. Wohl eher nicht.
Das Wort „Europapokal“ kann heute und in Zukunft bei beliebig vielen Sportarten verwendet werden.
Grundsätzlich geht es nicht an, dass eine einzelne Sportart den Begriff „Europapokal“ nur für sich reserviert. Unsere Namen der Vorlagen gelten projektweit und müssen bei allen Fachgebieten und Themen ohne Namenskonflikte oder Überschneidungen oder Verwirrung oder Unklarheiten verwendbar sein.
Zunächst: ich bin begeistert, wie schnell und zielorientiert hier eine Antwort kommt. Super. Dann lehne ich mich jetzt mal weit aus dem Fenster, da ich auch keine 15 mehr bin und weiß wie manche Vorschläge in Endlosdiskussionen versanden. Wir machen einfach mal Nägel mit Köpfen. Grundsätzlich trifft der Satz Grundsätzlich geht es nicht an, dass eine einzelne Sportart den Begriff „Europapokal“ nur für sich reserviert. Unsere Namen der Vorlagen gelten projektweit und müssen bei allen Fachgebieten und Themen ohne Namenskonflikte oder Überschneidungen oder Verwirrung oder Unklarheiten verwendbar sein. voll meine Intention. Der 2. Vorschlag sollte wohl am ehesten den Nerv treffen, weil ich vermute, das er die wenigsten Umbaumaßnahmen notwendig macht. Damit wir mal wissen worüber wir reden, wäre als Beispiel Bayer 04 Leverkusen#Statistiken und dort die Europapokalbilanz zu nehmen und der Europapokal der Landesmeister (Handball) 1974/75, exemplarisch da der ASK Vorwärts Frankfurt. Ich denke, es sollte deutlich werden.--scif (Diskussion) 13:40, 1. Apr. 2019 (CEST)
Derzeit sind diese ALEX-Texte in der Vorlage:ANNO mit dem für ALEX falschen Text bei der Verwendung eingebunden, siehe im Abschnitt Anno plus, ersichtlich jeweils in der Spalte Bemerkung. Ich vermute, dass das einen Entstehungs-geschichtlichen Hintergrund hat und der Anfang der historischen Rechtstexte noch innerhalb von ANNO gelaufen ist.
Kurzum: Ich plädiere zur dementsprechend korrekten Auslagerung der ALEX-Texte aus dem Anno-plus-Teil in die eigene Vorlage:ALEX. Als Beispiel:
((ANNO|rgb|00|00|1862|62|AUTOR=|RGBl. 1862/18. Gesetz vom 5. März 1862, womit die grundsätzlichen Bestimmungen zur Regelung des Gemeindewesens vorgezeichnet werden|NAME=[[Reichsgesetzblatt (Österreich)|Reichs-Gesetz-Blatt]] für das [[Kaisertum Österreich|Kaiserthum Österreich]]|ALTSEITE=36–41.|anno-plus=ja))
Das heißt, der seitenspezifische Linkteil apm=0&aid=rgb&datum=18620000&page=62 bleibt unverändert, sodass wohl der entsprechende Quelltext aus der Vorlage:ANNO für die anzulegende Vorlage:ALEX übernommen werden könnte. Sinngemäß müsste dann anstelle von "Online bei ANNO" der Text "Online bei ALEX" stehen.
Aktuell schon mit der Vorlage:ANNO eingebundene ALEX-Seiten könnten danach per Bot auf die neue Vorlage:ALEX umgebogen werden entsprechend dem sich aus dem Unterscheidungskürzel "aid" (siehe als Parameter in der Vorlage) ergebenden fixen Linkteil, wie im Beispiel oben mit apm=0&aid=rgb&datum=18620000&page=62.
Eventuell könnte in weiterer Folge die Artikel durchforsten, wo ALEX-Seiten entweder schon direkt (über alex.onb.ac.at) oder indirekt (über anno.onb.ac.at mit Weiterleiten beim Draufklicken auf alex.onb.ac.at geführt wird) in Artikel eingebunden sind und diese soweit geht vollautomatisch in die Vorlage:ALEX überführt werden. (Danach gegebenenfalls analog dann auch für nicht in die Vorlage:ANNO eingebundene ANNO-Seiten.)
In beiden Fällen überdies, ANNO wie ALEX:
Besser sollte mMn ohnehin besser "Volltext in: ANNO – AustriaN Newspapers Online" bzw. analog "Volltext in: ALEX – Historische Rechts- und Gesetzestexte Online" oder ähnlich stehen. Der Zusatz des Abrufdatums kann wie bisher schon unterbleiben, da es sich um Permanentlinks bei der Nationalbibliothek onb.ac.at handeln wird.
Wenn keine stichhaltigen Einwände gegen die eigenständige Vorlage:ALEX kommen, ersuche ich die VorlagenspezialistInnen sich dessen wie oben beschrieben anzunehmen. Mit Dank.
Nebenbei bemerkt ist der Parameter anno-plus=ja völlig überflüssig.
Mit einem Konstrukt wie vorstehend lässt sich diese Situation aus 1=Kürzel bereits erschließen, ein gesonderter Parameter ist in den Artikeln nicht erforderlich.
Dabei unterstelle ich mal, dass in der URL die &aid=<Kürzel>& nie doppelt vergeben sind.
Ggf. wäre es schlau, die darstellende Programmierung in eine Untervorlage /core auszulagern, die die beiden intern neu generierten Parameter alex=1 bzw. plus=1 zusammen mit den sonst durchgereichten Parametern aus dem Artikel erhält; bzw. nur die von diesen beiden intern gebildeten Parametern beeinflussten Teile aus einer solchen Untervorlage zuzuliefern.
Ein Wert für alex= ergibt sich dann aus dem obigen Konstrukt zu 1 oder nichts.
Weil für <1> auch ein vollständiger Zeitungsname auftreten kann, sind diese ggf. genau wie die Kürzel zu betrachten, sofern dieser Fall in alex oder zumindest plus möglich wäre.
Wir versuchen immer, die wirksame Programmierung an genau einer Stelle beisammenzuhalten, hier insbesondere die URL-Generierung, statt Dubletten aus zwei Vorlagen praktisch gleicher Funktion anzulegen. Erst recht ändern wir deshalb null Einbindungen in Artikel.
Es gibt mindestens einen booleschen Wert ues=on – dafür verwenden wir heutzutage weltweit ues=1 und ein Durcheinander von ja oder hier on oder true oder global einheitlich 1 sollte durch eine schlauere Programmierung abgefangen und damit diese Vorlage langfristig irgendwann auch für den VisualEditor verwendbar gemacht werden.
Ob Zahlen ein- oder zweistellig mit führender Null anzugeben sind, stellen wir üblicherweise intern sicher, um das URL-Format optimal zu generieren, statt dies im Artikel den Autoren abzuverlangen.
Die Vorlage hat eine aktive Betreuung; ich empfehle, diesen Abschnitt dorthin zu kopieren und das Weitere dort zu erörtern, damit alles beisammenbleibt.
Hallo, hatte o. g. Umstand schon auf der einschl. Disku angesprochen, da ich selbst keinen Link setzen konnte. Ist das so gewollt? Es gab auch ein ebenda verlinkt dokumentiertes Verschiebeproblem zum Monatswechsel. Dank fürs Drüberschauen sagt --Wi-luc-ky (Diskussion) 10:56, 3. Mai 2019 (CEST)
Ja, perfekt, Lómelinde. Danke. Und für das nächste Mal: Kannst Du mir bitte den den Diff-Link aufschreiben, damit ich die Werkstatt mit diesen Kleinigkeiten nicht behelligen muss. Danke, --Wi-luc-ky (Diskussion) 11:34, 3. Mai 2019 (CEST)
ich habe erfolgreich auf unserer Seite die Infobox einfügen können. Nun habe ich aber gesehen, dass auf unserer Seite (https://de.wikipedia.org/wiki/Zentrum_f%C3%BCr_Fernstudien_im_Hochschulverbund) eine
Art Quelltext beim Logo angezeigt wird ([[Datei:|rahmenlos|200x125px|Logo]] . Kann man diesen Quelltext auf der Seite irgendwie Unsichtbar machen?
Ich hatte bereits auf BD:Zfh-koblenz #Vorlage:Infobox zfh das Problem angesprochen, dass dies eine Infobox nur für einen einzigen Artikel werden soll; und dass dies nicht dem Konzept unserer Vorlagen entspricht.
Falls es dabei bleiben soll, könnte eine Werkstattmitarbeiterin vielleicht eine Einzeleinbindung der Vorlage:Infobox einfügen; das wird der Angelegenheit wohl eher entsprechen.
@Benutzer:Zfh-koblenz Ich verstehe nur Bahnhof, was sollte denn die ((Infobox zfh)) bewirken? Ich würde das eher löschen lassen, da ich nicht verstehe welchem Zweck das dienen soll. Da ist doch schon eine ((Infobox Hochschule)) im Artikel. Und die dortige Logoeinbindung wurde ja auch bereits repariert. --Liebe Grüße, LómelindeDiskussion16:42, 3. Apr. 2019 (CEST)
Hallo im dem Artikel zeigt es in der Vorlage:Infobox Gemeinde in Deutschland <imagemap>-Fehler: Ungültige Koordinate in Zeile 3: es sind nur Zahlen erlaubt an. Hat von euch einer Einblick in den Aufbau der Vorlage und voran es liegt. Wird die Vorlage Visualeditor bearbeitet wird es während der Bearbeitung ohne Fehlermeldung angezeigt. Danke euch Gruß Michael Hoefler50DiskussionBeiträge09:20, 9. Apr. 2019 (CEST)
Die waren schon immer da, wurden aber vormals ignoriert. Oberallgäu hat NNW ja schon repariert. Gibt es da einen Trick, oder war das Handarbeit? --Magnus(Diskussion)14:16, 10. Apr. 2019 (CEST)
Handarbeit. Allerdings muss man nicht alle Minuswerte korrigieren, man muss nur in Zweiergruppen denken und jeweils das erste und das letzte Paar anpassen und den Rest dazwischen rausschmeißen. Bei Freyung-Grafenau hat sich dadurch die Vorlagengröße sogar fast halbiert. NNW14:26, 10. Apr. 2019 (CEST)
Weil sie immer zu einem negativen Wert gehören und damit auf einer Linie liegen. Wie ich schon oben sagte: Man muss nur das erste und letzte Paar nehmen, da die dann die Linie bilden, auf der alle anderen Punkte dazwischen auch liegen und damit überflüssig sind. @Doc Taxon: Ich setze den negativen Wert auf 0, das ist alles. Die leichte Verschiebung der Flächengrenze, die dabei passiert, ist zu vernachlässigen. NNW16:50, 10. Apr. 2019 (CEST)
Gibt es eine Vorlage, die verhindert, dass man einen BNR-Artikel in den ANR, damit man nichts übersieht, z.B. bei einem großen Artikel? Wenn nicht, wünsche ich mir deren Erstellung.--Schweiz02 (Diskussion) 10:08, 14. Apr. 2019 (CEST)
Kannst du diese Frage bitte verständlich stellen. Was soll die Vorlage verhindern?
Wie soll eine Vorlage verhindern können, dass ein Artikelentwurf direkt im Artikelnamensraum erstellt wird, sie kann nicht wissen, dass es nur ein Entwurf werden sollte.
Wie soll eine Vorlage verhindern, dass ein unfertiger Entwurf in den Artikelnamensraum verschoben wird? Sie kann nicht wissen, wann etwas als komplett und damit verschiebereif angesehen wird.
Sollte deiner Meinung nach also jegliche Neuanlage (→Hilfe:Neuen Artikel anlegen) immer im Benutzerbereich des Erstellers landen, damit er das in aller Ruhe ausarbeiten kann? Dann bist du hier ebenso falsch, denn das müsste softwareseitig und im Einvernehmen mit der hiesigen Community festgelegt werden. So etwas wird vermutlich eher hohe Wellen schlagen, weil man dann für jede Weiterleitung, Begriffsklärungsseite und sonstige Neuanlage immer gezwungen wäre eine Seite im BNR zu erstellen, diese zu verschieben und die bei der Verschiebung entstehende Weiterleitung aus dem BNR löschen lassen.
Gibt es eigentlich Infoboxen, die sich an den Bildschirm anpassen, bzw. an die von den BenutzerInnen eingestellten Ansichtswerte für Bilder oder so? Oder haben die alle eine festgemauert-in-der-erden-px-Angabe eingebaut? Ist mir gerade bei der aktuellen Diskussion um die Infobox:Staat aufgefallen, die fest eingestellte 330px hat, was sie für mich und meine Bildschirmeinstellungen viel zu schmal erscheinen lässt. Ich fände es gut, wenn meine 400px für Bilder auch von solchen grafischen Gestaltungselementen respektiert werden würden. Bei normalen Tabellen, und vom Prinzip her sind das ja nix anderes als Tabellen, geht das ja sogar komplett ohne Angaben, nur abhängig vom Inhalt und/oder der Bildschirmauflösung. Grüße vom Sänger ♫(Reden)18:38, 14. Apr. 2019 (CEST)
Inhalt der Box
Inhalt der Box
Inhalt der Box
Für viele wären 400px schon viel zu breit. Der Text wird dann je nachdem wie die Bildschirmbreite ist oft unleserlich gequetscht.
Für viele wären 400px schon viel zu breit. Der Text wird dann je nachdem wie die Bildschirmbreite ist oft unleserlich gequetscht.
Inhalt der Box mit vw
Inhalt der Box
Inhalt der Box
Allerdings habe ich neulich etwas in der Art gesehen, ob man da allerdings sinnvoll für unsere Artikel verwenden könnte weiß ich nicht. Man kann ja auch mit Prozenten arbeiten, aber die Gefahr ist dabei immer, dass die Inhalte der Boxen unansehnlich gedehnt oder gestaucht werden. Vielleicht gibt es irgendwie eine CSS-Einstellung, das weiß ich aber nicht. Besonders bei Infoboxen, die intern mit nowrap arbeiten sind Boxen oftmals überbreit so, dass sie fast die Hälfte des Bildschirms füllen (also etwas 600px) und ich habe schon einen Breitbildschirm. --Liebe Grüße, LómelindeDiskussion19:03, 14. Apr. 2019 (CEST)
Eine variable Breite würde ich auch befürworten. Aber das muss dann ganz konsequent im ganzen Artikelnamensraum samt Vorlagen umgesetzt werden. ÅñŧóñŜûŝî(Ð)19:44, 14. Apr. 2019 (CEST)
(BK) Da gäbe es megrere Optionen:
1) Jeder angemeldete User kann in seinen Einstellungen eine "Standardgröße der Vorschaubilder" einstellen. Es obliegt den Programmierern der WP-Software, diesen Wert als benutzerabhängige Variable (Quasi als "Maßeinheit" für den User) zur Verfügung zu stellen. Damit könnte man dann Btreiten variieren.
2) Prozentuale Breiten. Das wurde in der Vergangenheit schon mehrmals versucht und es gibt immer wieder Schwierigkeiten, wenn das Elternelement nicht die Breite des Hauptfensters hat. Angaben wie style="min-width:25%; width:33%; max-width:40%;" könnten prinzipiell funktionieren, wenn man sicherstellt, dass das Hauptfenster das Elternelement ist.
3) Noch nicht getestet: irgendwelche Tricks mit "upright" bei Infoboxen mit Bildern. Das bewirkt, wenn es funktioniert, eine Mindestbreite.
Unsere rund 1000 aktiven Infoboxen haben Hunderte individueller Programmierungen.
Jeder Depp kann irgendwie eine Infobox oder sonst eine Vorlage zusammenfrickeln; es gibt keinerlei Eingriffsmöglichkeiten, das irgendwie zu steuern, außer einer Löschdiskussion. Es gibt keine Verpflichtung, irgendwelchen Rat anzunehmen, oder eine Vorlage auch nur nachvollziehbar zu benennen.
Diverse Infobox-Ersteller und ihre Redaktionen sind absolut beratungsresistent, und beharren heftigst auf ihrer traditionell eingeführten Programmierung. Sich mit denen rumzustreiten ist vergeudete Zeit.
Nahezu alle Infoboxen stammen aus der Zeit vor den Mobilgeräten; fast keine ist geeignet für moderne Einsatzbedingungen, wie Smartphone oder Großbildschirme.
Die Verantwortung für die fachgerechte Programmierung der Infobox und ihre Dokumentation trägt der jeweilige Ersteller sowie die zugehörige Redaktion-Portal-Wikiprojekt oder wer auch immer.
Nebenbei bemerkt fordern gut dokumentierte Infoboxen eine Maximalbreite für Bilder ein; wenn das Bild breiter ist als zugelassen, dann bleibt ggf. für den Einleitungsabschnitt links daneben nicht genug Platz und auf schmalen Bildschirmfenstern wird der Text zerquetscht. Breite Bilder gehören als dynamisch vergrößerbares Miniaturbild in den Artikelrumpf oder in Galerien; wer Einzelheiten sehen möchte, kann sich reinzoomen. Größere Bilder mit zu vielen Pixeln nötigen alle Leser, auch solche mit langsamem oder teurem Internet, zum zwangsweisen Download größerer Datenmengen, auch wenn die Leser sich überhaupt nicht für den Bildinhalt interessieren.
In Nummer 2.5.2.3 Encoding issues steht, dass nur Sonderzeichen, die im doi-Code nichts zu suchen haben, maskiert werden müssen. Beispiel dafür ist das '#', das in %23 maskiert werden müsste. Wie gesagt aber nur, wenn es keine Funktion für die doi hat.
Zitat: "Hexadecimal (%) encoding must be used for characters in a DOI that are not allowed, or have other meanings, ..."
Dadurch, dass doi.org erkennt ob ein # oder ein - oder ) verwendet wird, kann abgeleitet werden, dass das '#' als Teil der doi-Nummer erlaubt und wichtig ist.
Das Problem noch einmal zusammengefasst:
Wenn in Vorlage:Literatur der Parameter DOI ein '#' enthält gibt es eine Fehlermeldung von Wikipedia.
DOI=10.11588/diglit.4751#0390
Fehlermeldung: Fehler in Vorlage:Literatur – *** Ungültig: 'DOI'
Auch wenn das '#' maskiert als # ist, bekommet man die Fehlermeldung von Wikipedia.
DOI=10.11588/diglit.4751#0390
Fehlermeldung: Fehler in Vorlage:Literatur – *** Ungültig: 'DOI'
oder maskiert mit %23, bekommet man die Fehlermeldung.
DOI=10.11588/diglit.4751%230390
Fehlermeldung: Fehler in Vorlage:Literatur – *** Ungültig: 'DOI'
Auch wenn man bei Parameter ID die spezielle Vorlage:DOI nutzt, gibt es Fehlermeldungen von Wikipedia.
Im WP:en funktioniert der Parameter doi in cite book und cite journal zumindest soweit, dass der Link erstellt und anklickbar ist. Wen man drauf klickt, wird das '#' dort automatisch in %23 umgesetzt, was zu einer Fehlermeldung bei doi führt, denn das unmaskierte '#' ist ein wichtiges Zeichen für die Adressierung durch doi.
Zusammenfassung: Ein '#' in einem DOI® Namen kann wichtig sein und darf nicht von der Vorlage als Fehler gesehen oder vor dem Absenden der Adresse maskiert werden. Selbst wenn es unwichtig ist, kann DOI trotzdem damit umgehen, vorausgesetzt es ist hinter die zur Dokumentenerkennung notwendige Zeichenkolonne angehängt. In diesem Fall ist es dann egal, ob es maskiert oder unmaskiert abgesendet wird. Weil die Vorlage aber automatisiert arbeitet, sollte '#' in jedem Falle unmaskiert abgesendet werden.
Meine Antworten können ein paar Tage dauern. Bitte anpingen. Danke im voraus.
In letzterem Fall, weil mir das auch schon ab und an passiert ist, mache ich es folgendermaßen
((Literatur |Autor=Julius Elias |Hrsg=Karl Scheffler |Titel=Alice Trübner † |Sammelwerk=Kunst und Künstler. Illustrierte Monatsschrift für bildende Kunst und Kunstgewerbe |Band=14. Jahrgang |Nummer=Heft 7 |Verlag=Bruno Cassirer |Ort=Berlin |Datum=1916 |Seiten=367 |Online=[https://digi.ub.uni-heidelberg.de/diglit/kk1916/0390/scroll uni-heidelberg.de] |DOI=10.11588/diglit.4751.41))
Julius Elias: Alice Trübner †. In: Karl Scheffler (Hrsg.): Kunst und Künstler. Illustrierte Monatsschrift für bildende Kunst und Kunstgewerbe. 14. Jahrgang, Heft 7. Bruno Cassirer, Berlin 1916, S.367, doi:10.11588/diglit.4751.41 (uni-heidelberg.de).
Ich gehe also über den Reiter Vollansicht und nehme von dort die URL als Eintrag im Parameter Online und die DOI bestücke ich mit der ID zum Werk, zum Heft oder zum Artikel. --Liebe Grüße, LómelindeDiskussion07:43, 21. Apr. 2019 (CEST)
@Lómelinde: Der Fehler in der Vorlage ist also bereits in der Werkstatt bekannt. Deinem Beitrag entnehme ich einen weiteren Workaround für die Umwandlung in einen Link, die seltsamerweise funktioniert: [[doi:10.11588/diglit.4751#0390]]. Komischwerweise ist dabei das '#' kein Problem. Naja. Daran schließt sich für mich die Frage an, warum der Hinweis auf den '#'-Fehler und ein Workaround in der Vorlagen-Beschreibung fehlen. --Temdor (Diskussion) 00:34, 25. Apr. 2019 (CEST)
Nein wirklich bekannt würde ich das nicht nennen, eigentlich soll über die DOI das Werk angegeben werden, dass es in dem Link ohne Vorlage geht wusste ich so nicht, habe ich nur ausprobiert. Wer das wie oder wo ändern kann weiß ich gerade auch nicht. Ich verlinke eher nicht über DOI auf eine Einzelseite. Zudem soll der DOI-Link nicht identisch zum Link im Parameter Online sein, weil das dann redundant wäre. Man zitiert ja aus dem Buch = Werk oder ein Kapitel im Werk = DOI-Link eine Einzelseite = Online-Link auf eine Seite. Zumindest ich mache das so. --Liebe Grüße, LómelindeDiskussion06:31, 25. Apr. 2019 (CEST)
@Lómelinde: Ja, die Redundanz. In meinem letzten Artikel habe ich Parameter 'DOI' auf den Anfang des Artikels gelegt und Parameter 'Online' auf die Seite mit der Fundstelle. Dazu habe ich beim Parameter 'Seiten' den Seitenbereich für den Artikel angegeben und beim Parameter 'Fundstelle' dann die Seite mit dem Fundort genannt. Meine Frage dazu: Könnte man den Parameter 'DOI' direkt auf die Fundseite legen und damit die Parameter 'Online' und 'Abruf' einsparen? --Temdor (Diskussion) 20:03, 25. Apr. 2019 (CEST)
Die Adressierung von Fragmenten in einem bestimmten Dokumentformat ist nicht kompatibel mit dem Konzept der Digital Object Identifier (DOI).
Was sind DOI? Sie sind eine Art von hoffentlich ewig funktionierenden Weiterleitungen von URL auf Ressourcen.
Die ursprüngliche Domain kann nach einigen Jahrzehnten verkauft werden, oder die Rechte an den Dokumenten und der finanzielle Aufwand zur Pflege und Bereitstellung kann durch den Betreiber einer anderen Domain erfolgen. Von der bisherigen Domain wäre hingegen keine Unterstützung für uralte Geschichten möglich.
DOI verbirgt alle URL aller Domains und organisiert eine Weiterleitung (sogar mehrere), falls die Ressource irgendwohin umgezogen wäre.
Das Prinzip, dass Ressourcen über lange Zeit und möglichst die Ewigkeit verfügbar sein sollen, widerspricht jedoch dem Begehren, in einem ganz bestimmten Dokumentenformat in einer ganz bestimmten Technik einen Fragmentbezeichner zu unterstützen.
Der Fragmentbezeichner wird zu einem kompletten HTML-Volltext gehören.
Vielleicht wird aber zunächst nur eine kurze summary/abstract angeboten, damit Besucher erstmal sehen können, ob das der Text ist, den sie wirklich herunterladen wollen.
Oder es sind jetzt zunächst die Metadaten wie bei PMID 1 oder dazu ein Angebot von PDF, PostScript, irgendwelche eBooks, und ggf. anderer Formate wie unter arxiv:cs.SE/0105018 oder jetzt überhaupt nur noch PDF oder lediglich Scan-Grafik, was nichts mit HTML-Fragmenten anfangen kann? Es muss noch nicht einmal der Inhalt online verfügbar sein; kann auch heißen: Exemplare stehen in den und den Museen, zurzeit keine Scans verfügbar. Vielleicht auch Lizenz- und Kostengründe.
Das hatte ich am 4. April 2017 schon einmal beantwortet, wie auch oben verlinkt:
Der DOI ist eine zeitlose, Generationen überdauernde Identifikation eines Dokuments, egal, wo die Kopie gerade abgespeichert ist, und in welchem Format, und mittels welcher Technologie. Deshalb gibt es hier keine Sprungadressen, weil diese von einem Internet und einem bestimmten Dokumentenformat abhängen, und einer bestimmten Technik. Garantiert ist hingegen nur das Wiederauffinden des gesamten Dokuments. Verlinkungen sind nett, aber nicht gewährleistet, Sprungziele erst recht nicht.
Es ist auch nicht gesichert, dass ein DOI-Resolver oder Browser zukünftig Fragmente beibehalten wird, wie das momentan anscheinend geschehen war; möglicherweise sogar nur innerhalb bestimmter Browser.
Du kannst Fragmente ausschließlich auf die heute bekannte http-URL setzen, zu der jetzt im Moment der DOI aufgelöst wird, aber der zukünftigen Hinterlegung von Ressourcen keine Vorschriften machen, was für Fragmente sie gefälligst zu unterstützen haben.
Wenn die Syntaxanalyse von Vorlagen ungültige Werte detektiert und nicht erlaubt, dann bauen wir auch keine Anleitungen ein, mit welchen Tricks man ungültige Werte vielleicht doch irgendwie hintenrum einschleusen könnte.
@PerfektesChaos: Häufig mache ich Sachen falsch, aber wenn ich darauf hingewiesen werde, mache ich sie in der Regel richtig. Das nennt sich 'Learning by auf die Finger klopping'. Wenn's aber an der Software liegt, die die Syntaxregeln von doi.org nicht beherrscht, ist's nicht mein Fehler.
Ich hatte den Fehler in der Vorlage bemerkt und Stunden damit verbracht das DOI-System zu verstehen, vor allem § 2, wo es um die Syntax geht. Dort steht, dass das Zeichen '#' nicht nur eine Funktion in einem DOI-Identifikator hat, sondern ZWEI Bedeutungen hat.
Die Erste ist, dass man das Zeichen in einem DOI-Identifikator so benutzen kann wie ein '-' oder einen '.'. Der so geschriebene DOI-Identifier muss dazu lediglich bei doi.org mit seiner Weiterleitungsadresse hinterlegt sein und der Hinterleger muss dafür bezahlen. Ein einfacher Test gefällig? Bei diesem Link doi:10.11588/diglit.4751#0390 einfach das '#' durch das passende Zeichen-Entity '#' ersetzen: doi:10.11588/diglit.4751#0390 Schon bekommt man eine Fehlermeldung von doi.org, dass eine Weiterleitung nicht möglich ist. Somit ist '#' unheimlich wichtig für die Weiterleitung. Wenn nicht, käme eine Fehlermeldung von digi.ub.uni-heidelberg.de.
Siehe: DOI-Syntax § 2.5.1
Die zweite Funktion des '#' ist, dass es dem Event-Handler auf doi.org mitteilt, dass alles rechts von dem Zeichen für den Empfänger der Weiterleitung wichtig ist. Dann braucht man für diese spezielle Funktion keine separate Weiterleitungsadresse zu hinterlegen und auch nicht für die Hinterlegung zu zahlen. In diesem Sonderfall erfolgt die Weiterleitung nach der Angabe links vom '#'-Zeichen. Die muss hinterlegt sein, klar. In diesem Falle ist es egal, ob das '#'-Zeichen als Einzelzeichen oder Zeichen-Entität geschrieben wird. DOI kommt damit zurecht.
Siehe DOI-Syntax § 2.5.2.3
Dies hatte ich alles schon vor ein paar Tagen in mühevoller Recherche herausgefunden.
Somit kam die Frage auf, warum wird dieses bei doi.org wichtige '#' von der Syntaxanalyse von Wikipedia angemeckert? Es besteht kein Grund dafür. Es ist alles richtig geschrieben und die Syntax ist eingehalten.
Somit kann es nur an einem defekten Prüfalgoritmus für die Syntax liegen. Oder es gibt irgendeinen Streit zwischen Wikipedia-USA und DOI, was ich nicht hoffe.
Ich schreibe hier,
weil der Gebrauch von '#' in einem DOI-Identifikator vollkommen konform zur DOI-Syntax ist,
weil man '#' nicht einfach durch eine Zeichen-Entität ersetzen kann,
weil das '#' in der DOI-Syntax sogar ZWEI Funktionen hat,
weil ich gesehen habe, dass der Fehler im Jahr 2017 nicht erkannt wurde und
weil es nur an der Syntaxprüfung der Vorlage liegen kann, dass Wikipedia Probleme damit hat.
Alternativ könnte es auch an der Programmiersprache der Vorlage liegen, die vielleicht kein '#' als Einzelzeichen in eine URL einbringen kann ohne es in ein Zeichen-Entity zu wandeln. Aber das glaube ich nicht.
Darum bitte ich an dieser Stelle die Syntaxprüfung in Vorlage:Literatur und Vorlage:DOI an die Syntaxvorschriften von doi.org anzupassen. Danke im Voraus.
So, das war Ernst und nun kommt Spaß.
Habe gerade einen gemäß doi.org Syntax „2.5.2.3 Encoding issues“ nach rechts erweiterten DOI-Identifikator
doi:10.11588/diglit.4751#0390#HalloIchBins abgeschickt. Wenn man ganz schnell einen Screenschot macht, sieht man in der Adressleiste, dass doi den Link verändert hat zu:
digi.ub.uni-heidelberg.de/diglit/kk1916#0390#HalloIchBins. Kurz danach setzte die uni-heidelberg den Link um in:
digi.ub.uni-heidelberg.de/diglit/kk1916/0390/image, aber für kurze Zeit war's lustig. Ein Beweis, dass Syntaxvorschriften 2.5.1 und 2.5.2.3 auch ein bisschen Spaß machen können. Viele Grüße. --Temdor (Diskussion) 21:37, 25. Apr. 2019 (CEST)
Es ist hübsch, dass du die Spezifikation auf doi.org gefunden hast; jedoch muss ich leider befürchten, dass du zwar die Buchstaben, nicht jedoch den Geist verstanden hast. Weder auf doi.org noch meine Darlegungen oben. Ich versuch mal aufzuräumen:
„einfach das '#' durch das passende Zeichen-Entity '#' ersetzen“ – das ist eine Geschichte, die man ganz allgemein mit URI nicht machen kann und sollte. DOI sind URI=Uniform Resource Identifier und für alle diese gelten die gleichen Syntaxregeln, auch betreffend solcher Zeichen. Hier geht es meistens gut.
Ich spiel mal die Varianten anhand deines Beispiels durch:
Wir lernen also: Die Seite bei der Uni-Bibliothek Heidelberg ist immer dieselbe.
Eine Fragment-Information ist ggf. für die innere Struktur eben dieser momentanen Heidelberger HTML-Seite interessant und nett zu wissen. Damit kann ggf. an eine bestimmte Stelle in der HTML-Seite gesprungen werden; gibt man das nicht an, landet man ganz oben auf der HTML-Seite; wie immer.
Nun führen wir uns bitte vor Augen, was ich 2017 und heute mittag zum Sinn und Zweck von DOI schrieb: Ewige Bezeichnung einer Ressource, auch wenn sich die Rahmenbedingungen ändern.
Es wird nur versucht, einen oder mehrere Orte ewig zu kennzeichnen, an dem eine vollständige Sammlung der Ausgaben von Kunst und Künstler: illustrierte Monatsschrift für bildende Kunst und Kunstgewerbe verfügbar wäre.
Momentan wird das an erster Stelle von der Uni-Bibliothek Heidelberg geleistet.
Es wäre übrigens möglich, noch beliebig viele weitere Orte gleichzeitig unter demselben DOI verfügbar zu machen, aber mit normalen Browsern leitet doi.org nur auf den allerersten weiter, sofern vorhanden.
Momentan ist die Seite in Heidelberg ein HTML-Dokument, in dem es ein #0390 geben soll.
Das würde aber genauso funktionieren, wenn die HTML-Seiten sich ändern; etwa weil die Auflistung dieser ganzen Zeitschriftenjahrgänge auf einer gesonderten HTML-Seite stünde, und die allererste gezeigte Seite nur ganz kurz wäre. Da wäre auch kein #0390 mehr vorhanden.
Die Uni-Bibliothek Heidelberg könnte sich aber umstellen und statt einer HTML-Seite ein PDF-Dokument anbieten. Das kann aber mit so einem #0390 überhaupt nichts anfangen.
Statt in Heidelberg könnte aber eine Nationalbibliothek in Frankfurt oder Leipzig die Sammlung anbieten. Die haben ihre ganz eigene Seite und können mit #0390 nichts anfangen. Sie haben dann ihre eigene URL, was mit http://dnb.de/ oder so. Oder es steht eines Tages nur in Washington oder nur noch in Peking zur Verfügung.
Weil ein DOI gleichzeitig nicht nur eine, sondern mehrere Auflösungen haben kann, könnten theoretisch jetzt im Moment noch mehrere andere gleichartige Sammlungen angeboten werden; also Frankfurt oder Washington oder Berlin könnten jetzt schon alternative Auflösungen sein. Alle anderen können mit deinem Fragment nichts anfangen.
Fasse ich das jetzt mal zusammen:
Das Fragment #0390 ist nicht erforderlich, um auf die Startseite zu kommen.
Das Fragment #0390 ist spezifisch für eine ganz bestimmte momentane Zielseite, die sich aber jedezeit ändern kann und weder für die Zukunft noch momentan bindend oder sinnvoll ist.
Deshalb ist die Angabe von Fragmenten hier grundsätzlich unerwünscht.
Was du ansonsten oben zu „Bezahlen“ und dergleichen geschrieben hast („und auch nicht für die Hinterlegung zu zahlen“), ist leider Nonsens.
Die DOI sind grundsätzlich kostenfrei; oder die „Autorität“ bezahlt eine Spende für alles.
Es gibt derzeit wohl bald 15.000 „Autoritäten“.
Die „Autorität“ hat eine vier- bis fünfstellige Nummer hinter der 10. (steht für DOI).
Unsere Beispiel-Autorität hat die 11588 und könnte die Unibib Heidelberg selbst sein, oder vielleicht ein süddeutscher Verbund von Uni- und Staatsbibliotheken oder wer auch immer. Lässt sich durch Rumprobieren rausfinden und googlen: Offenbar gehören alle Treffer irgendwie zur Uni Heidelberg. Und die muss sich natürlich nicht selbst irgendwas bezahlen.
DOI.org hat die Autorität 1000 und damit die niedrigste.
Andere Autoritäten sind meistens wissenschaftliche Verlage, Stiftungen und andere Wissensinstitutionen; auch Wikimedia könnte eines Tages aus irgendwelchen Gründen eine „Autorität“ sein, und Wiki-Seiten dann durch entsprechende DOI verfügbar machen. Vielleicht für die momentane Diskussionsseite: doi:10.22222/dewiki.1525386
Das Prinzip läuft so, dass der Server von DOI.org (oder andere; siehe unten) weiß, wer sich hinter 11588 verbirgt und an einen speziellen Server dort eine Anfrage schickt, was und wo dessen Dokument diglit.4751 sein soll. Wenn alles wach ist, antwortet der Server dort mit der URL https://digi.ub.uni-heidelberg.de/diglit/kk1916 und das wird wiederum an den Browser des Lesers (also deinen) geschickt und der schaltet dann automatisch auf diese Weiterleitung um.
Es gibt auch alternative Resolver, die mehrere Ergebnisse anbieten würden, wenn es beispielsweise statt der kostenpflichtigen vom Verlag angebotenen Version kostenfreie Vollversionen geben würde; etwa:
https://doi.org/10.1002/2014JD022441 – liefert ein früher mal kostenpflichtiges HTML-Dokument beim Verlag wiley.com, von dem früher nur der Abstract gebührenfrei lesbar war. Ist aber inzwischen wissenschaftlich veraltet und mittlerweile offen.
Wir lernen: Ein und derselbe DOI kann zu PDF oder HTML aufgelöst werden, durch verschiedene Resolver an verschiedenen URL. Für eine Version kann ein Fragment #0390 zeitweise sinnvoll sein, für alle anderen ist es Quatsch und irritierend.
@Lómelinde:@Wi-luc-ky:@PerfektesChaos: Vielen Dank für die Antworten. Wie ich sehe, sind wir alle auf dem gleichen Stand. Das Problem ist, dass die Software eine vollkommen richtige DOI-Nummer mit '#' darin als "ungültig" erklärt. Diese Behauptung ist falsch und damit unwahr. Sie hat nicht nur mich verwirrt. Die Behauptung impliziert ferner, dass Wikipedianer zu blöd zum abschreiben der DOI-Nummer sind. Außerdem impliziert sie, dass Fachkräfte in den Bibliotheken zu blöd sind nach den Syntaxregeln der doi.org zu arbeiten. Dies sind Beleidigungen, außerdem sind sie falsch, damit unwahr und somit eine ungerechtfertigte Beleidigung. Bislang habe ich dererlei Worte nicht verwendet und dadurch anscheinend Verwirrung gestiftet. Ob gültig oder ungültig definiert die Stiftung hinter der DOI durch die Syntaxanweisungen und nicht Wikipedia. Es wirkt, als ob die Wikipedia-Foundation (USA) einen Krieg gegen die International-DOI-Foundation führt.
Bitte nehmt die Beleidigungen und das Säbelrasseln der USA aus der Kommunikation der Vorlage:Literatur, Vorlage:DOI und anderen Vorlagen mit der gleichen Problematik heraus. Bitte, bitte, bitte.
Vorschlag zur Kommunikation: Wenn Wikipedia im Sinne des vergangenen, gegenwärtigen und vor allem zukünftigen Geistes einer ursprünglichen DOI-Idee möchte, dass eine vollkommen regelkonforme DOI-Nummer um das '#' und die Zeichenfolge rechts davon gekürzt werden soll, dann wäre es sinnig das auch so zu kommunizieren. Wikipedia wird kein Zacken aus der Krone fallen, wenn die Syntaxprüfung der Vorlage schreiben würde: "Fehler in Vorlage:Literatur - *** Zeichen '#' und die Zeichenfolge rechts daneben unerwünscht: 'DOI' " oder "Fehler in Vorlage:Literatur - *** Hier nur den DOI für das gesamte Dokument eintragen: 'DOI' ". So einfach könnt's sein. Gespannt auf eure Lösung wartend, euer -- Temdor (Diskussion) 12:45, 27. Apr. 2019 (CEST)
Ich kann mich beim besten Willen nicht erinnern womit ich dich beleidigt haben soll, ich habe lediglich versucht eine Lösung aufzuzeigen, das finde ich jetzt aber reichlich weit ausgeholt. Das geht so nicht! Ich habe nirgendwo Beleidigungen in eine Vorlage eingefügt, daher kann ich auch keine entfernen. --Liebe Grüße, LómelindeDiskussion13:06, 27. Apr. 2019 (CEST)
@Lómelinde: Entschuldige, nein. Ich dachte, du wärest eine Programmiererin. Die Software wurde so programmiert, wie sie ist. Deinen Workaround hatte ich in die Dokumentation der Vorlage:Literatur eingebracht, wurde aber zurückgewiesen mit dem gleichen Schlagwort, wie sie von der Software in der Vorlage gewählt wird. An der Software kann ich auch nichts ändern. Weil ich mich selber als Wikipedianer sehe, bin ich für diesen Fehler in der Syntaxprüfung aber auch mitverantwortlich und versuche hier seit einiger Zeit zu verhindern, dass ich als Person wie auch alle anderen Wikipedianer von der Software weiterhin beleidigt werden. Ich muss dazu die Problematik denen klar machen, die die Software ändern können. Mit Höflichkeit ging das bislang nicht. Mal sehen was sich tut. -- Temdor (Diskussion) 14:33, 27. Apr. 2019 (CEST)
Ich habe etwas Probleme bei meiner erstellten Vorlage (Vorlage:Ligue1).
Siehe Doku (Vorlage:ligue1.com/Doku) – an den Beispielen 7, 8 und 9 funktioniert die externe Verlinkung nicht ganz richtig, aber bei Beispiel 10 funktioniert es, weil dort neben den ersten beiden Zahlen/Zeichen keine weiteren Zeichen wie in den anderen Beispielen(7,8,9) stehen.
Ich habe jedoch noch ein organisatorisches Anliegen:
Ich möchte gern, dass auf Vorlage:ligue1.com verschoben wird.
Und das möglichst bald, so lange es nur in zwei Artikel eingebunden ist.
Grund ist, dass es auch noch andere Anwendungen geben können, die dieselbe Ligue1 beträfen, und sogar andere Staaten ihre Kiste ebenfalls „Ligue1“ nennen könnten, und dann blickt überhaupt niemand mehr durch, wofür diese Vorlage zuständig ist.
Vorlage:ligue1.com kann jedoch zu nichts anderem als dieser Domain gehören.
Danke Wiegels, für den Anfang sehr geholfen. Gibt es vielleicht eine Möglichkeit durch eine „((#ifeq:“-Zeile in der Vorlage das Problem automatisch auszumerzen?
Das ist meine erste Frage hier und es war für mich auch nicht leicht rauzufinden was ich eigentlich suchen musste um den Fehler zu melden, daher verzeiht mir wenn etwas falsch an der Meldung ist.
Es geht um diese Vorlage. Sie erzeugt einen Verweis auf die Seite von Alfa Aesar, zu dem zum Produkt gehörenden Sicherheitsdatenblatt. Das Linkziel direkt auf das PDF hat sich etwas geändert. Es müsste also das Template für den Link angepaßt werden.
Beispiel:
Datenblatt Adrenalin bei Alfa Aesar (Seite nicht mehr abrufbar).Fehler bei Vorlage * Parametername unbekannt (Vorlage:Alfa): "Datum"
Ich hoffe mal, dass ich mit der Frage hier richtig bin: Da im Index-Katalog die Nummer IC 4900 anscheinend doppelt vergeben wurde, gibt es dazu nun eine Begriffsklärungsseite, die auch in o.g. Vorlage auftaucht. Da es eine "runde" Zahl ist, erscheint sie bei sehr vielen anderen Galaxie-Artikeln im 4000er-Bereich in der Navigationsleiste. Könnte man, um diese vielen unerwünschten BKS-Links zu vermeinden, die Vorlage so umbauen, dass IC 4900-1 und IC 4900-2 einzeln in der Navileiste stehen? Danke und Gruß, --Magipulus (Diskussion) 11:16, 5. Apr. 2019 (CEST)
Nicht ohne die Vorlage gigantisch aufzublähen oder ohne viel umzuschreiben. Nur den 100er-Link umzuschreiben ginge mit halbwegs sinnvollem Aufwand, denke ich. --mfb (Diskussion) 07:41, 7. Apr. 2019 (CEST)
Die Vorlage:Base Mérimée funktioniert nicht mehr, da das frz. Kultusministerium Änderungen vorgenommen hat. Was können wir tun? Es eilt, da Tausende Links zur Base Mérimée nicht mehr funktionieren.--Reinhardhauke (Diskussion) 14:46, 5. Mai 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Vielen Dank das ist mir einfach nicht aufgefallen. Entschuldige die Späte Antwort. Theater88 (Diskussion) 06:40, 11. Mai 2019 (CEST)
Abfrage zum Quelltext
Servus, Ist es möglich, eine #if-Abfrage an eine Bedingung im Artikel im Seitenquelltext zu knüpfen? Insbesondere würde mich folgende Möglichkeit interessieren:
Lua hat Zugriff auf den Seitenquelltext, normale Vorlagen nicht. Kein schöner Ansatz. Vielleicht lässt sich das anders lösen? --mfb (Diskussion) 12:45, 11. Apr. 2019 (CEST)
jepp, hört sich böse nach endlosschleife an, wenn die vorlage (falls sie im artikelraum steht) beginnt, sich selbst auszuwerten: da können minimale änderungen in der infrastruktur (etwa, welche gecachte quelltextversion ausgewertet wird) zu bösen nebeneffekten führen.
anders sieht hingegen eine abfrage von "wo anders" zu wartungszwecken aus: da kann man schlicht die whatlinks auf die "Vorlage X" („links auf diese seite: vorlageneinbindung“) nach dem artikelnamen durchsuchen: die whatlinks sind genau die liste "welche Seite Vorlage X aufruft" --W!B: (Diskussion) 12:54, 13. Apr. 2019 (CEST)
@W!B: Danke für Deinen Hinweis. Kannst Du mir dafür ein einfaches Beispiel nennen/zeigen/geben? Brauche ich dafür auch Lua, oder geht das normal? Danke & Gruß, Ciciban (Diskussion) 08:44, 16. Apr. 2019 (CEST)
Kann man sicherlich und wo genau soll es hin? Oberhalb oder unterhal der Karte? Ganz unten am Ende, weiter oben, unter das Wappen? --Liebe Grüße, LómelindeDiskussion16:20, 16. Apr. 2019 (CEST)
→So? Du kannst das nun über |Bild= und |Bildtext= einbinden. Falls da noch ein Strich zwischen Wappenbereich und Bild soll, dann könnte ich den noch hinzufügen --Liebe Grüße, LómelindeDiskussion07:39, 17. Apr. 2019 (CEST)
@Lómelinde: Das sieht super aus Lómelinde! Herzlichen Dank! Ich weiss nicht, wieviel man da noch wünschen kann. Aber hier meine Anregungen:
Vielleicht könnte man die Wappen und das Bild mit einem dünnen Strich trennen (So wie auch die anderen Themanbereiche in der Box getrennt sind).
Es wäre schöner, den Titel in einer farbig hinterlegten Titelzeile statt neben den Wappen zu haben. zB so wie in der italienischen Infobox hier.
Es wäre schöner, wenn nicht eine Karte als jpg- oder png-Bild in der Infobox eingebunden würde, sondern wenn automatisch wie auf der italienischen Seite die Standard-Namibiakarte mit dem eingezeichneten Ort erscheinen würde. Vielen Dank für Dein Engagement! Gruss, Hp. --Hp.Baumeler (Diskussion) 09:39, 17. Apr. 2019 (CEST)
Das ist alles machbar
Die Vorlage ist aber scheinbar absichtlich ohne vertikale Ränder erstellt worden, du meinst doch senkrecht oder?
Titel nach oben ist auch kein Problem, Farbe?
man könnte sicherlich die Standard-Namibiakarte immer einbinden, aber Positionskarten mit Koordinaten ist nicht so meins, das sollte dann jemand machen, der weiß was er tut.
@Lómelinde, Hp.Baumeler: ich komme. Aber erst am Ostersamstag oder nach Ostern dazu. Ich kann das umsetzen, aber ist das auch Konsens, die jpg/png-Karten der Gemeinde durch Positionskarten zu ersetzen? Beides erschiene mir zuviel. lg --Herzi Pinki (Diskussion) 23:29, 17. Apr. 2019 (CEST)
Beides fände auch ich zu viel, die Box ist ja schon so recht hoch. Ich dachte mehr an alternativ, wenn für den Parameter nichts angegeben wurde. --Liebe Grüße, LómelindeDiskussion06:12, 18. Apr. 2019 (CEST)
@Herzi Pinki, Lómelinde, Chtrede, Olga Ernst: Vielen Dank Herzi Pinki und Lómelinde für das Engagement bei der Anpassung der Infobox. Die zur Zeit in der Infobox eingetragenen png-Karten zeigen den Wahlkreis, zu dem der beschriebene Ort gehört. Bei Windhoek zum Beispiel mag das ok sein, weil die Stadt wohl fast so gross wie der Wahlkreis ist. Aber das Beispiel von Aranos zeigt, dass dies im Allgemeinen nicht geht, weil der Wahlkreis Aranos riesengoss ist und der beschriebene Ort Aranos nicht eingezeichnet ist. Auch ich bin der Ansicht, dass nur eine Karte, eben die Standardkarte Namibias mit dem eingezeichneten Ort, etwa so wie auf der italienischen Aranos-Seite, in der Infobox stehen sollte. Freundliche Grüsse, Hp. --Hp.Baumeler (Diskussion) 08:54, 18. Apr. 2019 (CEST)
Coordinate nur das Format
gibts es das modul, das das interne DMS-format dd/mm/ss/N dd/mm/ss/E einfach nur in das „schöne“ format dd° mm′ ss″ N, dd° mm′ ss″ O umwandelt, als eigene vorlage (ohne alles, ich bräuchte es plaintext als koordiatenbeschriftung) --W!B: (Diskussion) 23:04, 9. Apr. 2019 (CEST)
Vorlage:DPMA
Hallo,
könnte sich jemand erbarmen, die [[Vorlage:DPMA|DPMA-Vorlage]] VE-ready zu machen? Die Vorlage hat nur zwei Parameter. Dankeschön --KeksPing mich an! um 15:13, 14. Mai 2019 (CEST)
Ein maßgeblicher Grund, warum bisher niemand diese Vorlage angefasst hatte, ist, dass sie einen unverständlichen Namen trägt.
Schweizer und Österreicher im Projekt kennen die Abkürzung überhaupt nicht; nur technisch oder juristisch versierte Deutsche.
Deal: Verschiebung auf DtPatentMarkenA, dann von hier aus VE-ready und Organisation eines langfristigen Migrationsprozesses?
Für die projektweite Verwaltung von über 50.000 Vorlagen verwenden wir keine kryptischen Codes mehr, sondern nur noch projektweit für jeden Benutzer auf einen Blick und ohne nachzuschlagen zu entschlüsselnde Bezeichner. Egal, wie eingeführt und vertraut in einem winzigen Spezialgebiet irgendeine Abkürzung für eine Handvoll Spezialisten wäre.
Allenfalls bei Zehntausenden von Einbindungen und für sämtliche Fachgebiete relevanter und deshalb allgemein bekannten Abkürzungen belassen wir diese. Diese hier hat lächerliche 69 Einbindungen; sowas muss niemand kennen.
Neuer Namensvorschlag: Vorlage:Deutsches Patent- und Markenamt (Registerauskunft)
Der zweite Namensvorschlag wäre doch okay, vielleicht trotzdem mit Weiterleitung von DPMA. Wegen der Abkürzung: Die steht so im Artikel und die Webadresse des Patent und Markenamtes lautet auch dpma.de. Ich wäre auch weiterhin für die Abkürzung (zumindest als WL), da es ja z.B. auch Vorlage:IMDb gibt. Vorteil bei dem zweiten Namensvorschlag von dir @PC wäre, dass der Nutzer nicht erst auf die Dateibeschreibungsseite gehen muss, um zu erfahren, was die Vorlage macht, Vorteil der WL ist ein schneller Zugriff auf die Vorlage. Langfristig sollte das dann doch auch bei IMDb umgesetzt werden. Gibt es da Namenskonventionen für Vorlagen? Gruß vom Keks (--178.201.111.138 07:51, 15. Mai 2019 (CEST)) Bestätige --KeksPing mich an! um 08:46, 15. Mai 2019 (CEST)
Nein bitte ohne WL, das führt nur dazu, dass der eigentliche Vorlagenname nicht verwendet wird. Ich bin strikt dagegen hier für ein paar einzelne eine Abkürzung vorzuhalten, nur weil sie nicht die auf jeder vernünftig dokumentierten Vorlagenseite zur Verfügung gestellte Kopiervorlage oder andere Hilfsmittel verwenden wollen, es geht nicht darum Zeichen beim Einfügen einzusparen. Vorlagen sollen selbsterklärend sein, das gilt auch für die Namen der verwendeten Parameter. Ich habe noch tausende ThB-Abkürzungen die beispielsweise durch ThiemeBecker ersetzt werden sollten, und das schlimme ist, es kommen immer wieder neue hinzu, weil Benutzer einfach wieder die veraltete WL ThB ohne die benannten Parameter einfügen und eben nicht die tatsächlichen Vorlagen- und Parameternamen verwenden, das ist absolut kontraproduktiv und auch schlecht für Benutzer, die den visuellen Editor verwenden. --Liebe Grüße, LómelindeDiskussion12:04, 15. Mai 2019 (CEST)
Nun Lomelinde, im VE wird man keine Kopiervorlagen nutzen. Ohne WL muss man den Namen fast ausschreiben. Wenn ich nach allen Vorlagen, die mit "Deut" beginnen suche, dann komme ich auf 42 Ergebnisse [2]. Erst bei "deutsches" gibt es nur noch drei Ergebnisse. Nicht-VE Nutzer können das leicht beiseite schieben, aber ohne WL ist der Seitentitel für den VE einfach nicht praktikabel. Also bitte mit WL, denn wenn es im Artikel steht juckt es doch keinen mehr. Und selbst wenn: kann man die Abkürzung auch jederzeit auf einer vernünftig dokumentierten Vorlagenseite nachschlagen. :) --KeksPing mich an! um 13:01, 15. Mai 2019 (CEST)
Vorlage:IMDb hat 135.964 Vorlageneinbindungen und genießt ob des resultierenden Bekanntheitsgrades Sonderstatus; DPMA hat 69 Einbindungen und ist völlig unbekannt (außer Experten).
Es geht um die Auflistungen der enthaltenen Vorlagen sowie Kategorien von Vorlagen; die hier auftretenden Bezeichner sollen selbsterklärend oder allgemeinbekannt sein; sich jedenfalls in ihrer Funktion ungefähr enträtseln lassen.
DPMA könnte auch Deutsche Produkt-Marken-Agentur bedeuten; es gibt -zig Wörterbücher und Vereine und Institutionen und Standards, die irgendwas mit D-Dingsda enthalten.
DtP hat null, künftig dann nur einen Eintrag und würde ideal für VE geeignet sein.
Auch Dt hat nur eine Handvoll ähnlicher Möglichkeiten; davon zwei mit der Bedeutung Dt→„deutsch“.
DtPatentMarkenA erfüllt alle Anforderungen für die Namensgebung unserer Vorlagen; erläutert die Bedeutung und hat wenige Treffer mit den ersten Buchstaben. Deshalb mein obiger Vorschlag.
Schon mal versucht, eine Navileiste oder Infobox im VE auszuwählen?
Eine Verschiebung bedeutet auch die sukzessive Auflösung und schließlich Löschung der WL. Permanent koexistierende Doppelbezeichnungen gibt es für ANR-Vorlagen grundsätzlich nicht; lediglich temporär im Verlauf eines Migrationsprozesses. Mittels Wikipedia:LT/vorlagenparser usw. müssen sich perspektivisch unter einheitlichem Namen die Verwendungen auswerten lassen, und genauso müssen den ANR pflegende Bots und Skripte sowie nach der Stelle der Einbindung suchende Bearbeiter den einheitlichen Namen auffinden können, und nicht auf ewig diverse Synonyme durchprobieren müssen. Nur bestimmte sehr häufige Vorlagen zur Projektorganisation haben dauerhaft unterstützte Kürzel-WL; das ist aber wohl weniger als ein Dutzend.
Es gibt kaum formelle Richtlinien für Vorlagen; jeder Depp kann solche Seiten anlegen und jeden Unsinn damit verbauen und sie auch denkbar schwachsinnig benennen. Diese Werkstatt pflegt jedoch nur verständlich benannte und sinnvolle Vorlagen; ansonsten gibt es keinerlei Support.
Das stimmt nicht: Die Vorlage mag selten eingebunden sein (tatsächlich ist sehr oft zum DPMA referenziert) das möchte ich ändern: Vergleiche Insource-Suche nach 'dpma.de' = 1136 Ergebnisse
Wo du gerade fragst: Einmal, habe ich eine Infobox eingebunden und nie wieder, das tue ich mir nicht mehr an!
Ich denke DtPatentMarkenA ist das kleinere Übel gegen den vollausgeschreiebenen Namen, auch wenn mir ein WL-Konstrukt natürlich lieber wäre :)
Update: Hab mich etwas eingelesen und mich mal an der VE-Kompartiblität versucht. Gerne mal drüberschauen, dass ich nix falsch gemacht habe. --KeksPing mich an! um 14:42, 16. Mai 2019 (CEST)
Fein, das übt. Man lernt dazu.
Auch schön, dass dann ja Einigkeit über die längere Namensgebung erzielt wurde.
@Lómelinde: Verschiebst du dann bitte mal und erledigst nach der Verschiebung die Restarbeiten auf der neuen Seite?
Die TD gehört nämlich immer auf eine /Doku-Unterseite.
@Lómelinde: danke für die Arbeit. Ich würde gerne aus Neutralitätsgründen die von mir ursprünglich eingetragene Wortmarkennummer 306362511 für die Wikipedia Wortmarke anstelle der KeylessGo Marke verwenden. Es kommt auch vor, dass der Eintrag eben nicht das Lemma des Artikels ist. Im Beispiel Lotuseffekt habe ich das gerade wieder bemerkt. Daher würde ich gerne den Text „*Beispielmarke* in der Registerauskunft des Deutschen Patent- und Markenamtes (DPMA)“ in den Text „Eintrag *Beispielmarke* in der Registerauskunft des Deutschen Patent- und Markenamtes (DPMA)“ ändern, was das neutraler beschreibt. Gäbe es da Einwände? --KeksPing mich an! um 17:39, 17. Mai 2019 (CEST)
Du hast doch den Parameter Name um den Linktext anzupassen. Natürlich ist es nicht immer das Lemma, aber wenn du jetzt etwas generell davor schreibst könnte das bei Einträgen wie hier
Aber mach wie du denkst es ist nicht meine Vorlage. Ich passe nur die Vorlagen an um dann die WL löschen zu lassen und natürlich zu testen ob alles funktioniert. --Liebe Grüße, LómelindeDiskussion17:49, 17. Mai 2019 (CEST)
Nur zu meinem Verständnis: Das ist doch gerade: Name=Abweichend
„Eintrag eben nicht das Lemma des Artikels“ – Das ist die Vorgabe für schreibfaule Vorlagenanwender, und scheint sehr häufig zu sein.
Ein vorangestelltes „Eintrag“ schreiben wir heutzutage eigentlich nicht mehr, weil es die Angelegenheit nur aufbläht, aber keinerlei neue Information liefert. Was anderes als einen „Eintrag“ soll die Abfrage einer Registerauskunft denn sonst liefern?
Ich war mal mutig und hab das mit der Wikipedia Wortmarke mal umgesetzt. Um auf deine Frage zurückzukommen: Bei dem „Eintrag eben nicht das Lemma des Artikels“ versteh ich nicht was du damit meinst. Wenn ich mir den aktuell ersten Beleg unter Lotuseffekt anschaue, mag mir das nicht so ganz gefallen:
Der Leser mag denken, der Artikel führt dort vielleicht weiter, weil er runtergescrollt hat und nun bei den Einzelnachweisen ist. "Lotus-Effekt" behandelt das Artikelthema gar nicht. Gerade bei solchen Konstellationen mag das verwirrend sein. Nicht für uns junge Burschen aber für manch andere?
Es ist ja nicht "Lotus-Effekt", was hinter dem Link zu sehen ist sondern eben "der Eintrag "Lotus-Effekt"".
Du kannst alles im Parameter Name unterbringen, auch kurze Zusätze. Das ist bei der Mehrzahl der Einträge, die ich gesehen habe, auch so gemacht worden. Da steht dann Wortmarke „XY“ oder Wort-Bildmarke „ABC“ oder was auch immer man zur Spezifizierung haben möchte, einzige Einschränkung, es sollte kein ausufernder Text sein. Sonst könnte man noch einen Parameter Kommentar spendieren. So ich bin offline. --Liebe Grüße, LómelindeDiskussion18:35, 17. Mai 2019 (CEST)
Ach ich Doofkopf, ich hab deinen Beitrag oben völlig übersehen und nur PCs Beitrag gesehen. Ich meinte gar nicht "Beispielmarke" als Text :) Ich meinte das so: „Eintrag Lotus-Effekt in der Registerauskunft des Deutschen Patent- und Markenamtes (DPMA)“. Das Wort "Eintrag" kann ich ja auch erstmal vor die Vorlage schreiben um den Effekt zu haben, ist aber nicht professionell, aber wenn man das eben in die Vorlage reinschrieb sähe das so aus:
Na ja das halte ich dann doch für überflüssig, es ist doch eigentlich logisch, dass es um einen Eintrag dort geht, ich mag auch keine Vorlagen, wo beispielsweise steht
Hans Autor: Artikel Mustermann, Hans. In: Das Beste Lexikon aller Zeiten. XY-Verlag, Musterstadt 2000, S. 123.
Auch da ist für mich „Eintrag“ überflüssig. Aber wie gesagt es ist nicht meine Vorlage, ich habe sie niemals zuvor verwendet. Wie also genau der Text aussehen sollte, darf jemand entscheiden, der damit öfter arbeitet.
Es gibt aber auch jede Menge Vorlagen die darauf verzichten so etwas vroanzustellen
Bozen, in der Datenbank Geschichte Tirol des Vereines „fontes historiae – Quellen der Geschichte“
Bregenzerwald auf der Website des Welterbezentrums der UNESCO zu Tentativlisten.
Du siehst es macht ein jeder so, wie er es gerade gut findet. Ich persönlich mag es nicht, wenn es vorangestellt wird, aber das ist nicht ausschlaggebend. Ich kann auch nicht ausschließen, dass ich selbst schon so etwas getan habe. Aber es klingt manchmal dann so als wenn ein Wort fehlt „Eintrag über“ XYZ oder „Eintrag über die/den/das einen“ … „Eintrag über die“ Neue Hofburg in Wien
Guten Morgen, Gut da haste auch wieder Recht... „Noch schlimmer finde ich (POV) es dann, wenn „Eintrag“ noch mit verlinkt ist“ Das wäre ja der Fall, wenn man das "Eintrag" in das Feld "Name" schreibt – mag ich auch nicht. "zu" oder "über" hätte ich weggelassen. Egal, dann lassen wir's erstmal so, so wichtig ist es mir nicht, als dass wir uns hier den Kopf zerbrechen :) Ich werde ja in Zukunft öfter damit arbeiten und mal schauen, wie sich das entwickelt. Danke für die Beratung! --KeksPing mich an! um 09:51, 18. Mai 2019 (CEST)
Ich würde gerne, dass diese Infobox mal überholt werden und mehr Parameter bekommen soll. Wenn man bei der englischen Wiki anschaut, sieht die bei der deutschen Wiki sehr mager aus . Beispielsweise existiert bei en.wiki der Parameter „missing“, den es bei uns nicht gibt. Das heißt, dass alle Vermissten als Todesopfer angeben werden müssen und bei Survivors der Wert „0“ stehen muss, obwohl beide Werte nicht bestätigt sind. Außerdem gibt es bei en.wiki „total fatalities“ für den Fall eines Zusammenstoßes von mind. 2 Flugzeugen; bei uns muss man dann bei Injuries „0“ einsetzen, obwohl der Wert nur bedingt Sinn macht, weil ein Überlebender nicht automatisch ein Verletzter ist, was hier besonders gut zu sehen ist. Außerdem kann sich dann das Theater mit den Flugzeugbildern sparen, wenn man das wie bei en.wiki macht--Schweiz02 (Diskussion) 09:19, 14. Apr. 2019 (CEST)
Ich bin gerade bei einer Übersetzung auf die Vorlage Externe Medien gestoßen. Leider scheint sie nicht zu funktionieren und es gibt auch keine vernünftige Anleitung dazu. Bei mir erscheint nur eine Überschrift, aber nicht die Links zu den Bildern. Was mache ich falsch? (siehe Benutzerin:Rita2008/Oleg Michailowitsch Gasmanow. --Rita2008 (Diskussion) 23:08, 11. Mai 2019 (CEST)
Das würde ich eher als privaten Gehversuch denn als funktionierende Vorlage klassifizieren.
Es geht ja hier nicht um eine Infobox, sondern um mehrere Bilder zu einem russischen Sänger. Dann lasse ich das wohl besser ganz weg. Danke. --Rita2008 (Diskussion) 18:40, 14. Mai 2019 (CEST)
Man muss sich nur die Vorschau anschauen, dann sieht man es schon, bei Eingabe von ISO-Codes macht die Vorlage einen Fehler. Könnte das bitte korrigiert werden?--Antemister (Diskussion) 14:33, 26. Mai 2019 (CEST)
Ja, danke, diese und alle anderen werden soeben für die neuen Server unter PHP7 fitgemacht. Danke für die Info anyway, klärt sich hoffentlich bald auf. LG --PerfektesChaos13:02, 29. Mai 2019 (CEST)
Da gibt es leider keinen Konsens. Wir müssen ja auch mit so einem Unsinn wie Vorlage:Pipe leben, weil die Mineralienfreunde nach eigenem Bekunden (!) entweder zu dumm oder wohl eher zu faul sind, | einzutippen... ÅñŧóñŜûŝî(Ð)18:20, 3. Mai 2019 (CEST)
Kann bitte jemand den Parameter Logo so bearbeiten. das eine gelöschte Datei oder eine nicht existierende Datei als Rotlink erscheint und der betroffene Artikel in der Kategorie:Wikipedia:Defekter Dateilink landet? Mir ist nämlich in Teutoburger Ölmühle aufgefallen das die Datei:Logo teutoburger oelmuehle.svg seit Monaten gelöscht ist. Betroffene Artikel tauchen in keiner Wartungskategorie auf und die fehlenden Dateien werden nicht bemerkt und entlinkt. --2003:DE:71B:2405:4001:6047:A9E2:1C4F09:29, 30. Mai 2019 (CEST)
Logos von Firmen, Sportvereinen oder Parteien sind wegen Urheberrechtsproblemen oft Gegenstand von Löschungen; auch auf Commons mit dortiger international sicherer Anforderungen.
Es kann deshalb gut sein, dass nach dem Hochladen und Einbau in den Artikel einige Wochen später wieder gelöscht wird.
Bei Verwendung in normalem Wikitext laufen zwar globale Bots durch und entfernen nach Löschung, aber bei Vorlagenparametern könnte das scheitern, weil nur der Titel und nicht das komplette Konstrukt mit Klammern und Namensraum erscheint.
Es wäre deshalb okay, wenn nach und nach Infoboxen zu Logo-typischen Themen die Existenz einer solchen Datei abfragen und eine Wartungskat auslösen; dafür jedoch gar nicht erst das Bild-rottlink anzeigen, sondern eine verborgene Fehlermeldung.
Kann eigentlich nur funktionieren, wenn der Parameterwert ein Bildname ist, nicht jedoch bei vollständiger Einbindung. Mit Lua allerdings auch aus einer ganzen Wikisyntax.
Die Existenzfrage wäre teuer, aber eine Infobox gibt es meist nur einmal pro Artikel und das können wir uns leisten.
@PerfektesChaos: Die Bots können auch entlinken wenn nicht das komplette Konstrukt mit Klammern und Namensraum erscheint. Beispiel eines Artikels der die Vorlage:Infobox Band verwendet. Hier war das der Benutzer:Dateientlinkerbot. Sein Kollege der Benutzer:CommonsDelinker macht das aber auch. Die Box muss einfach den Rotlink liefern. Dann trägt sich der Artikel m. E. alleine in die Kategorie:Wikipedia:Defekter Dateilink ein. Dann machen das fleißige User, wie ich und andere, oder die Bots. Der CommonsDelinker kann natürlich keine Bilder entlinken die nur hier auf deWp gespeichert sind. Das macht der Dateientlinkerbot und/oder User. -- 87.169.32.11720:43, 30. Mai 2019 (CEST)
Ich verstehe jetzt nicht so restlos, was eigentlich dein Begehr ist, aber wir können die oben von mir skizzierte Standardprogrammierung der Infoboxen wie folgt erweitern:
Im standardmäßig ausgeblendeten Bereich bei Auslösung der Kategorie wird auch eine unsichtbare Medieneinbindung ausgelöst; die erscheint dann trotzdem auf Kategorie:Wikipedia:Defekter Dateilink.
Dann verschwindet ein Rotlink erstmal so schnell wie möglich aus dem Blickfeld der Leser, und es wird parallel auch die Wartungskat ausgelöst, wo auch fleißige Bienchen umherschwirren.
Logos sind international aus rechtlichen Gründen nicht so beliebt und deshalb weitaus überwiegend nur dewiki-lokal hinterlegt denn auf Commons. Wenn unsere Admins allerdings Bilder löschen, dann gibt es auch irgendein Prozedere, um Medieneinbindungen zu entfernen.
Genau das wäre gut. Entweder solche Artikel erscheinen in der Kategorie, dann machen das fleißige User oder es wird ein Rotlink dann macht das ein Bot. Der kommt nach der Botbeschreibung nach ca. 15 Minuten nach der Löschung. Wenn der Link der gelöschten Datei nicht sichtbar ist, ist das dem Bot auch egal, der macht trotzdem seinen Job. Steht der Artikel nur in der Kategorie ist der Rotlink für Leser nicht sichtbar, fleißige User machen das in der Regel nach wenigen Tagen. Als ich mit der Kategorie vor einigen Jahren angefangen bin standen dort an die 1000 Artikel. Das gibts aber noch andere User die da ebenfalls mit aufräumen. Deshalb ist die Kategorie meistens ziemlich abgeräumt. Es geht mir darum, dass es möglicherweise eine größere Menge von Artikeln gibt, die die Vorlage:Infobox Unternehmen verwenden und bei denen das Bild gelöscht wurde. Diese sind so nicht zu identifizieren. --87.169.32.11722:14, 30. Mai 2019 (CEST)
Der Urheberechtsstatus der Bilder ist mir insoweit egal. Da hab ich keine Ahnung von. Die landen häufig in der Wikipedia:DÜP, da sieht man dann schon weiter. So wie jetzt bleibt der Dateiname da stehen den keiner der User bemerkt die sowas entlinken. Für den Nurleser aber schon blöd. --87.169.32.11722:18, 30. Mai 2019 (CEST)
@Herzi Pinki: Kannst du das bitte so āndern das die gelöschte oder nicht existierende Datei ein Rotlink wird. Den Rest macht mediwiki und die Bots und User. Mediawiki trägt die Artikel in die Kategorie ein. Das wäre sehr nett. Danke --2003:DE:71B:24B7:4001:6047:A9E2:1C4F06:18, 31. Mai 2019 (CEST)
Guten Abend! Ich habe eine Frage: ich versuche beim Artikel Inhaltskette eine NavFrame nicht im ausgeklappten, sondern im eingeklappten Zustand darzustellen, schaffe es aber mit dem Befehl class="NavFrame collapsed" nicht. Wie schafft man es, dass diese Box automatisch eingeklappt ist? --DJGrandfather (Diskussion) 00:49, 2. Jun. 2019 (CEST)
Eine Möglichkeit wäre einfach massen an Navigationsleisten versteckt einzubinden, so werden automatisch alle Leisten auf der Seite eingeklappt. Wenn Du das machen willst füge einfach folgendes ein:
Hallo DJGrandfather, du kannst Elemente wie div-Bereiche oder Tabellen mit den Klassen mw-collapsible und mw-collapsed zusammenklappbar bzw. zusätzlich initial zusammengeklappt anzeigen lassen. Dies verträgt sich allerdings schlecht mit Navigationsleisten. Siehe auch hier oder hier. (Und an Habitator terrae: Eine zweite Navigationsleiste würde schon reichen.) --Wiegels„…“02:21, 2. Jun. 2019 (CEST)
Wow: Kompliment und Dank an euch beide… aber ich verfluche euch, weil ihr meine Experimente mit eingeklappten NavFrame/Head/Content in den Staub getreten habt: Ich habe mit mehreren gleichzeitig in einem Abschnitt experimentiert und mich dabei auf ihr Stand-alone-Eingeklapptsein verlassen, hätte das sogar eidesstattlich bescheinigt :-( Dafür beherrsche ich Klapptabellen, die schaffen das alone ;) --Chiananda (Diskussion) 05:13, 2. Jun. 2019 (CEST)
Vielen Dank, ihr habt mir sehr geholfen! Ist ja ziemlich kompliziert, die Lösung... --DJGrandfather (Diskussion) 10:32, 2. Jun. 2019 (CEST)
Das Commons-Bild "c:File:Flag of Syria.svg" wurde bearbeitet (Versionsgeschichte), was eine notwendige Sichtung in allen einbindenden Artikeln (weltweit) erfordert (Beispiel: "Ankara"), weil es von der Vorlage:SYR benutzt wird – meine Frage: Kann die Vorlage die Sichtung nicht selber vornehmen, ohne sie an einbindende Artikel durchzureichen?
Gibt's für so ein Vorkommnis eine empfohlene Verkürzung? Ich habe das schonmal bei einer Grafik erlebt, die ich per Vorlage auf Kat-Seiten anzeige: musste alle Seiten einzeln nachsichten… :-( Gruß --Chiananda (Diskussion) 22:17, 24. Mai 2019 (CEST)
Oder ein Bot so was übernehmen? Scheint übrigens nicht immer so aus zu gehen. Als vor ein paar Wochen t-online.de das Logo wechselte, hat ein unerfahrener Benutzer das neue Logo bei commons einfach über das alte drüber kopiert, wohl weil er dachte, dass so gleich bei allen Einbindungen automatisch das aktuelle Logo zu sehen ist. Dabei tauchte aber der besagte Hinweis zu einer neuen notwendigen Sichtung nicht auf. (Habe dann den Tausch zurück gesetzt und für das neue Logo eine eigene Datei angelegt und die Einbindungen händisch geändert, war allerdings nur ein halbes Dutzend)--Ciao • Bestoernesto • ✉23:28, 24. Mai 2019 (CEST)
Ló: Alle Artikel, welche die Vorlage ((SYR)) (SyrienSyrien) einbinden (Liste), haben aktuell zuoberst im Artikel stehen (jedenfalls für mich):
„Vorlagen- und Dateiänderungen dieser Version sind noch nicht markiert. Die gesichtete Version wurde am 17. Mai 2019 markiert.“
Der Link führt zu einer Seite, auf der steht dann oben:
„Vorlagen/Dateien wurden aktualisiert (nicht markierte Seiten sind in fett gekennzeichnet): Datei:Flag of Syria.svg“
Meine Frage also: Was hat dazu geführt, dass die eingebundene Flagge auf jeder einbindenden Seite neu gesichtet werden muss, und lässt sich der Prozess irgendwie abkürzen oder vermeiden? --Chiananda (Diskussion) 14:15, 25. Mai 2019 (CEST)
Na ja, ich hatte schon in die Liste (der Vorlage) geschaut, aber bei keinem der Artikel, die ich zur Probe angeklickt hatte, eine Meldung gesehen. Daher ja meine Verwunderung. Vielleicht hatte ich zufällig immer schon die erwischt, die erledigt waren. Nein, eine Beschleunigung kenne ich nicht, wie gesagt Vorlage sichten wenn es eine tatsächliche Vorlagenänderung ist, bei Dateien kenne ich mich nicht so aus, da habe ich immer wenn ich so etwas hatte auf sichten geklickt. Der Sinn dahinter ist ja wohl, dass die Änderung geprüft werden soll. Es könnte ja wer weiß was für eine Datei drübergeladen werden. Weltweit stimmt aber vermutlich nicht ganz manuell sichten ist eher ein de-Wiki-Thema oder für ein paar andere Wikis auch. --Liebe Grüße, LómelindeDiskussion15:10, 25. Mai 2019 (CEST)
Vielleicht ist der Sichtbot zwischendurch mal ausgefallen und hatte das Flaggenbild gerade nicht aufm Schirm (hier ein weiteres von 1600 Einbindungen). Auf Commons wurde die Flagge zwischenzeitlich mehrfach bearbeitet, ohne erneuten Sichtungsalarm auszulösen… komische Sache, das. --Chiananda (Diskussion) 03:13, 31. Mai 2019 (CEST)
die Datei wurde kurzzeitig gelöscht [3]. Dann wurde die neue Flagge auf diesem Dateinamen hochgeladen. Das ganze hat innerhalb einer Minute stattgefunden. Daher haben die Bots die Dateieinbindungen nicht entfernt. Das machen sie erst wenn die Löschung länger als 10 Minuten andauert. Weil jetzt unter dem alten Namen eine neue (andere) Datei in den Artikeln erscheint, wird das ungesichtet Symbol gezeigt. Das betrifft weltweit jedoch nur die Wikipedias die ihre Artikel sichten, Das sind keine zehn. Ein Bot kann das aber nicht so einfach Sichten, weil er nicht weiß ob ein Vandalismus vorliegt (es hätte unter dem zuvor gelöschten Dateinamen jemand eine Hakenkreuzflagge hochladen können). Der Benutzer:NowCommons-Sichtbot hat andere Aufgaben, siehe dort. Also ist es an den Sichtern nach einer anderweitigen Bearbeitung oder bei einem zufälligen Artikelbesuch die Datei auf möglichen Vandalismus zu prüfen und den Artikel dann nachzusichten. -- 2003:DE:71B:24B3:2CD5:9877:64CB:197320:02, 31. Mai 2019 (CEST)
Danke für die Recherche und Erklärung – die zwischenzeitliche Dateilöschung dürfte die letztendliche Ursache sein.
Mit der Suche konnte ich leider keine Empfehlung finden, welche Variante bevorzugt wird. Gibt es eine Empfehlung dafür? Wäre es gerechtfertigt, entsprechende Vorlagen anzupassen?
Das ist Geschmackssache. Beide Formen sind hier grundsätzlich erstmal möglich, eine explizite Regel gibt es so nicht.
Allgemein bevorzugen wir kurze, knappe verlinkte Titel und dann gern anschließend unverlinkte Bereiche; auch zur Trennung aufeinanderfolgender Links, um unmittelbar auffallend zu machen, von wo bis wo eine Verlinkung aktiv wäre.
Hinzu kommt, dass diese Links ja in den meisten Fällen direkt den Text des Lemmas wiedergeben; gelegentlich mag es Unterarten oder Abschnittsverlinkungen geben, wodurch der dargestellte Titel und das Lemma nicht ganz identisch sind. Die Jahreszahl ist aber nicht Teil des Lemmas; wenn wir auf den Artikel zum „Silberner Wetterhahn“ verlinken, dann ist auch nur „Silberner Wetterhahn“ blau und nicht noch eine Jahreszahl.
Beide Aspekte sprächen dafür, die Jahreszahl besser nicht mitzuverlinken.
Die Angelegenheit sollte zunächst auf irgendeiner geeigneten Fach-Plattform diskutiert werden, bevor du dich einsam und allein an eine Umstellerei machst und das irgendwem nicht gefiele.
Da die technische Vorlagenprogrammierung nicht betroffen ist, kann diese Werkstatt ansonsten wenig in dieser Angelegenheit vornehmen.
Das klingt vernünftig. Ich kenne mich noch nicht so aus: Die Diskussionsseiten der Vorlagen scheinen ja keine besonders populäre Austauschplattform zu sein. Was könnte die geeignete Fachplattform sein? --Frupa (Diskussion) 22:50, 15. Mai 2019 (CEST)
@Frupa: Du könntest mal stichprobenartig in ein paar Versionsgeschichten gucken; insbesondere auf die Ersteller. Es gab ja mal irgendwen, der dieses Design schick fand; und falls dies immer derselbe Benutzer sein sollte und dieser noch aktiv ist, wäre eine vorherige Absprache dort anzuraten.
Ich persönlich würde die Jahreszahl unverlinkt zu Beginn und als Sortierkriterium erwarten, dann einen Doppelpunkt und dann den Link auf das Gemüse oder Viecher oder was.
Unverlinkt ist sicher richtig. Machen wir bei unseren Filmleisten auch. Warum ich sie „damals“ mitverlinkt habe, kann ich nicht mehr sagen. Womöglich vom Vorgänger übernommen...? Was meine Leisten betrifft, darf es gern geändert werden. VG --Goldmull (Diskussion) 22:39, 30. Mai 2019 (CEST)
Du kannst das doch selbst ändern. Das ist jetzt nicht vorlagenspezifisch und auch nichts was man umprogrammieren könnte. Das ist eine reine Fleißaufgabe die Links richtig in die Karte zu setzen. Ich weiß doch auch nicht für welche Abmessung das ausgerechnet wurde. Siehe auch → Hilfe:Imagemap#Umfangreichere Anwendung. --Liebe Grüße, LómelindeDiskussion18:32, 25. Mai 2019 (CEST)
Na das habe ich ja toll hingekriegt, die vorherige Dimension ist wieder hergestellt. PS: Ich weiß auch nicht mehr was ich mit dieser Karte zu tun hatte, ich habe seit 15 Jahren keinen TV mehr. MfG -- Benutzer: Perhelion00:12, 29. Mai 2019 (CEST)
Bei der Implementierung dieser Vorlage auf en.wikipedia wird en:template:Fix verwendet, welches ich folglich ebenfalls versucht habe in die deutsche Wikipedia zu übertragen.
Momentan habe ich auf Modul:Kategorisierer versucht das en:module:category handler zu übertragen, doch mein jetzig geschriebenes Vorlage:Kategorisierer, in dem ich keine Fehler sehe, gibt bei
((#invoke:Kategorisierer|main)) die Fehlermeldung:
Lua-Fehler in package.lua, Zeile 80: module 'Modul:Kategorisierer/data' not found
aus.
Da ich noch nicht viel mit Lua gearbeitet habe, und auch mit dem Wikipedia Backend nicht vertraut bin, weiß ich nicht, was diesen Fehler verursacht, oder wie ich ihn beheben kann.
Wenn es eine Vorlage, die es sonst fast überall, nur nicht hier, gibt, hat das meistens einen der folgenden Gründe:
die Vorlage existiert mit anderer Funktionsweise bereits unter einem anderen Namen
sie wird als unerwünscht oder unnötig angesehen
Hier trifft Punkt zwei zu. Auch wenn ich zugehörige Diskussionen gerade nicht finden kann, kannst du nicht einfach so irgendwelche Vorlagen erstellen, ohne vorher deren Sinnhaftigkeit oder Erwünschtheit in der Gemeinschaft zur Diskussion zu stellen. Noch weniger gern gesehen wird es (vor allem in dieser Werkstatt), wenn ohne Sinn und Verständnis der hier herrschenden Konventionen und Gebräuche irgendetwas von anderswo kopiert wird. Da entsteht ein Rattenschwanz an Spezialvorlagen für nur einen Fall (in deinem die citation needed), den nur dafür niemand aktuell halten kann und möchte. Gruß, -- hgzh19:53, 10. Jun. 2019 (CEST)
Die Sinnhaftigkeit besteht in der Markierung von quellenlosen Behauptungen, um nicht ganze Paragraphen löschen zu müssen. Wikipedia:sei mutig: Ich kann einfach so Vorlagen erstellen, wenn es einen Sinn ergibt. Wenn die Deutsche Wikipedia kein Interesse an Sachlichkeit hat, dann wird Wikipedia seinen Ruf in Deutschland zurecht behalten: Unzuverlässig. Strikefinger (Diskussion)
Ob eine Vorlage Sinn ergibt oder nicht, entscheidest in einem kollaborativen Projekt aber nicht allein du Kraft deiner Wassersuppe. Stell deinen Vorschlag zur Diskussion, wenn sich dafür ausgesprochen wird, kann es gern weiter gehen. -- hgzh20:04, 10. Jun. 2019 (CEST)
Lesetipp: Wikipedia:Citation needed. „Hingegen hat sich 2013 eine deutliche Mehrheit der abstimmenden deutschsprachigen Wikipedianer gegen die Verwendung des Bausteins ausgesprochen, weil nach ihrer Ansicht das Missbrauchspotenzial und andere Schwächen des Bearbeitungshinweises dessen Vorteile überwiegen.“
Dies gilt weiterhin.
Bitte sorge unverzüglich selbst dafür, dass deine Module eliminiert werden.
Nebenbei ist es ein totaler Overkill, um einen winzigen Hinweis „Zitation erforderlich“ darzustellen, wenn man denn sowas überhaupt wollen würde, sogleich hier einen riesigen Apparat von bei uns nicht erforderlichen Modulen aufzufahren; umso mehr, als du selbst „Da ich noch nicht viel mit Lua gearbeitet habe“ einräumst, es selbst nicht verantwortlich warten und pflegen könntest, und du einfach mal festlegst, dass das restliche Projekt nun auf ewig die Wartung und Pflege und permanente Betreuung deiner Kopien übernehmen würde.
Wir sind seit fünfzehn Jahren im Geschäft; diejenigen Vorlagen und Module, die diese Community für allgemeine Aufgaben benötigen würde, hat sie in aller Regel schon längst. Solltest du den Eindruck haben, es bestünde Ergänzungsbedarf, dann frage bitte zuallererst nach, statt erstmal Tatsachen zu schaffen und deine private Entscheidung über die Community zu stellen und das Ergebnis der Beratung vorwegzunehmen.
Die Auswirkungen von dem, was du da zusammenkopiert hast, scheinst du auch nicht annähernd zu überblicken; die Einführung einer solchen Infrastruktur mit derart weitreichenden Konsequenzen kann nicht mal so eben per Handstreich erfolgen.
Um den Quelltext der Liste Frequenzen der terrestrischen Fernsehkanäle zu verkürzen, sollen diese beiden Vorlagen erstellt werden. Zum Beispiel wird in den meisten Ländern der Alten Welt auf UHF ein 8-MHz-Kanalraster verwendet, jedoch mit unterschiedlichen Tonunterträgerfrequenzen. Außerdem wird in den meisten Ländern der Neuen Welt auf UHF ein 6-MHz-Kanalraster verwendet, jedoch mit unterschiedlichen Trägerfrequenzen für digitales terrestrisches Fernsehen. --88.70.35.23014:58, 16. Mai 2019 (CEST)
Lässt sich grundsätzlich drüber reden.
Wir machen für sowas aber keine zwei einzelnen Vorlagen, sondern eine vereinheitlichte Programmierung, ggf. mit Parametern UHF=6 und UHF=8 oder das lässt sich von den Parametern ableiten und automatisch ermitteln. Ist einfacher zu pflegen.
Der Name ist mir noch ein wenig kurz; UHFrequenz oder sowas wäre besser.
Wenn du dich mit dieser Liste auskennst und inhaltlich Ahnung hast, wäre es nett, wenn du uns die gewünschten Parameter mundgerecht aufbereiten würdest.
Und wo als in diesem einen Artikel könnte eine derartige Vorlage denn noch eingesetzt werden? Besser wäre eine Universalvorlage für allerlei UKW KW LW MW und möglichst viele analoge Artikel.
Und wie soll die Wahlmöglichkeit zwischen der Ausgabe nur der analogen Bildträgerfrequenz, der Ausgabe nur der digitalen Mittenfrequenz und der Ausgabe aller auf der Welt üblichen Trägerfrequenzen bewerkstelligt werden? Ich schlage folgendes vor: ((UHF|E|21|A)) für 471,25 MHz, ((UHF|E|21|D)) für 474 MHz und ((UHF|E|21)) für die Zeile im von mir verlinkten Artikel. Allgemeiner: ((UHF|Land|Kanal|Technik)). --88.70.35.23015:49, 16. Mai 2019 (CEST)
Drei Buchstaben gehen gar nicht (sind reserviert für Flagicons); noch weniger als drei Buchstaben und eine Ziffer.
Weil wir grad bei Flagicons sind: Die aktuellen Staaten (seit etwa 1970) kodieren wir mit zwei Großbuchstaben; ich wüsste jetzt grad nicht so genau, welches Land „E“ sein soll.
A für Analog-UHF, D für Digital-UHF, das ginge klar.
Wir verwenden bei neuen Vorlagen kaum noch unbenannte Parameter, weil bei breiterer Anwendung über einen einzelnen Artikel oder einen einzelnen Frequenzbereich hinaus.
Ich denke eher an ein breiteres Gesichtsfeld im Sinne von Vorlage:FreqTab, das sich universell in vielen Artikeln für Listen von Frequenzen und Kanälen nutzen lässt.
„Und wie soll die Wahlmöglichkeit zwischen der Ausgabe nur der analogen Bildträgerfrequenz, der Ausgabe nur der digitalen Mittenfrequenz und der Ausgabe aller auf der Welt üblichen Trägerfrequenzen bewerkstelligt werden?“ – Sowas regeln wir über geschickt und von Anfang an schlau konzipierte Parameter, an denen sich erkennen lässt, was für eine Art von Tabelle mit welchen Spalten das jeweils ergeben soll.
Es wäre also an dir, mit deiner Fachkenntnis über Mittenfrequenz und Trägerfrequenzen, ein für sämtliche Tabellen aller Frequenzbereiche und Technologien und nationale Systeme anwendbares Datenmodell zu konzipieren, wodurch sich auch alle derartigen Listen einheitlich formatieren und gestalten lassen.
Zunächstmal: Du hast nicht nur eine Vorlage angelegt, so als Entwurf, mal zur Demonstration, sondern dies unverzüglich auch überall in den Artikel eingebaut.
Damit hast du dir eine dreitägige Halbsperre für den Artikel eingehandelt.
Es ist nicht sauber, dass du, noch während wir hier diskutieren, einfach vollendete Tatsachen schaffst, unter kryptischem Namen eine Vorlage anlegst und diese in „deinen“ Artikel einbaust.
Das wurde noch ohne mein Zutun erkannt und administrativ gestoppt.
Es gilt: Zuerst wird diskutiert, dann eine für das Projekt verträgliche Lösung verabredet, danach diese in Vorlagenprogrammierung umgesetzt, und nachdem diese komplettiert und gegengecheckt wurde, folgt die erste Verwendung in einem Artikel.
Dann erstmal zur Organisation dieses Projektes:
Wir haben über zwei Millionen Artikel.
Wir haben weit über 50.000 Vorlagen.
Tausende von Menschen müssen über Jahrzehnte all das pflegen und weiterentwickeln, ohne eine Ausbildung dafür zu haben.
Daraus folgen ein paar Spielregeln:
Syntax im Artikel muss verständlich und leicht nachvollziehbar sein.
Wenn Vorlagen verwendet werden, dann müssen ihre Anwendung und ihre innere Programmierung leicht verständlich sein.
Aus den Namen von Vorlagen muss ihre Funktionalität leicht zu erschließen sein.
Für einen einzelnen Artikel eine Privatvorlage anzulegen, um dort irgendwelche Syntax abzukürzen, ist ein absolutes No-go. Das auf Millionen Artikel angewendet führt zu einem unwartbaren nicht mehr zu pflegenden Wirrwarr von konfusen Bastelarbeiten.
Zu deinen geografischen Bezeichnungen:
Wir werden sie nicht benötigen. Dazu einen Punkt später mehr.
A soll Amerika heißen; warum nicht Afrika, Asien oder Österreich (Kfz-Kennzeichen)?
„C für China, E für Europa, und J für Japan“ – nein, die VR China hieße bei uns CN und Japan JP (siehe ISO-3166-1-Kodierliste). Wir verwenden nicht in jeder einzelnen Vorlage ein anderes spontan ausgedachtes Abkürzungssystem, in das sich jeder Bearbeiter einfummeln und es sich merken muss.
Das sind übrigens dieselben Codes, die auch an den Internet-Domains dranstehen, und viele davon unseren Autoren durchaus vertraut. Da heißt eine URL (TLD) für Japan .jp und wir erfinden das Rad nicht in jeder Vorlage neu und denken uns Privat-Codes aus.
AU für Australien ist okay.
E ist Espana (Kfz-Kennzeichen), oder vielleicht Estland, so wie C und J einzelne Staaten sein sollen. „Europa“ wäre aber etwas wie Eur und ohne Erläuterung begreift jeder: Ame für Nordmittelsüdamerika, Afr, Asi.
Die Tabellen sind nicht nach geografischen/staatlichen, sondern nach technisch-physikalischen Merkmalen zu differenzieren.
Welcher Staat, welche Region in welcher historischen Periode welches System verwendet, hat ausschließlich aus dem Artikel hervorzugehen.
Die Vorlage weiß absolut rein gar nichts davon.
Damit kann ohne eine Änderung der Programmierung irgendeine Umstellung von regionalen Angeboten 2020 oder 2023 in vorher/nachher beschrieben werden.
Die Parameterwerte sind technisch-organisatorische Identifikatoren, wie vielleicht PALNTSCDAB-TDVB-TUHF6DVHFq13UHF8A oder wie auch immer sinnvoll ausgedacht.
Für das jeweilige System mögen sich aus physikalischen oder organisatorischen Gründen bestimmte Tabellenspalten ergeben und andere nicht sinnvoll sein.
Das hat aber nichts mit Geografie zu tun, sondern hängt ausschließlich von Physik und Technik ab.
Die Vorlage ist so zu konzipieren, dass sie in möglichst vielen Artikeln ähnlicher Anforderung wiederverwendet werden kann.
Es sind nur benannte Parameter zu verwenden, damit je nach Kontext eine möglichst vielseitige Verwendung ermöglicht wird.
Die Vorlage ist umfassend zu dokumentieren.
Es sind alle Parameter anzugeben.
Die dafür möglichen Parameterwerte und ihre Interpretation sind aufzulisten.
Es kommen Formeln mit expr vor; diese sind in der Dokumentation oder inneren Kommentierung im Klartext zu erläutern.
Ohne diese Dokumentation ist es Bearbeitern außer dir nicht möglich, die Programmierung und den Artikel zukünftig weiterzuentwickeln und zu pflegen.
Du verschwindest wieder, und uns bleibt ein undurchdringlicher Scherbenhaufen zurück.
Ohne vollständige Dokumentation kein Einbau in einen Artikel.
Du schreibst align=right an jede einzelne Zelle.
Das HTML-Attribut align= ist seit 1998 veraltet.
Es heißt heute universell: style="text-align:right"
Du jubelst uns also nach zwei Jahrzehnten obsoletes Zeugs frisch unter, dessen Überreste wir seit längerem aus dem Artikelbestand wieder rauswerfen.
Du schreibst das in Artikel und Vorlage an jede einzelne Tabellenzelle gesondert dran.
Das ist Unfug. style="text-align:right" kann einmalig für die gesamte Tabelle angegeben werden und wirkt dann auf sämtliche Zellen, sofern dort nicht anders angegeben.
In diesem Beispiel habe ich dir mal eine ähnlich ungeschickt mit veralter Programmierung gebastelte rechtsbündig-Tabelle umgeschrieben und dadurch wesentlich gekürzt (−2 kB), vereinfacht und übersichtlicher gemacht.
Die ersten Wikis gab es 2001. Wie kommt man dazu, 2001 und auch 2019 eine schon seit 1998 veraltete und abgelöste Syntax zu verbauen?
Es ist egal, ob Namen von Vorlagen oder Parametern etwas länger werden; entscheidend ist, dass sie selbsterklärend und verständlich sind. Es geht nicht darum, in unseren Artikeln einen auf ganz wenige Bytes komprimierten Syntaxdschungel zu hinterlassen, den wir hinterher wegschmeißen müssen, weil ihn niemand verändern und anpassen und weiterentwickeln kann.
Ich habe in den letzten Wochen interessiert deine Lua-Programmierung verfolgt.
Ich wollte dich ohnehin schon deshalb kontaktieren; dann halt auf diesem Weg.
Glückwunsch – Dokumentation und Programmierung hast du vorbildlich und nachvollziehbar umgesetzt.
Ich habe wenig mit Frequenzen, aber viele andere Sachen zu tun. Du scheinst dich ja mit der Materie befasst und ein gewisses Grundverständnis erarbeitet zu haben – könntest du bitte als Mentor diesen Artikel, diese Vorlage (oder genauer gesagt ihren selbsterklärend benannten Nachfolger) und unsere IP unter deine Fittiche nehmen?
zum Thema: kann ich Monitoren, habe mir die Vorlage gerade angeschaut, da wäre das Komplettprogramm nötig. Meine Anmerkungen habe ich auf der Diskussionsseite im Abschnitt „Überarbeiten“ angebracht. --Labant (Diskussion) 09:16, 18. Mai 2019 (CEST)
Bitte um Vorlagenerstellung!
Ich bin seit dem letzten Jahr damit beschäftigt, die Turnierartikel der Snooker-Saison 1988/89 anzulegen bzw. zu überarbeiten. Im Moment fällt mir zum Abschluss der Aktion im Wesentlichen nur noch ein Artikel, leider ist es der zur Snookerweltmeisterschaft 1989. Da es im Vergleich zu den restlichen Turnieren eine deutlich komplexere Qualifikation mit fünf Runden gibt und es dazu noch keine passende Vorlage gibt und ich nicht zwei Turnierpläne benutzen will, bräuchte ich eine relativ komplexe Vorlage. Bevor ich bei der Erstellung dieser allzu viele Fehler mache, bitte ich euch Experten, mir zu helfen.
Die Vorlage soll im Groben und Ganzen eine Mischung zwischen den Vorlage Turnierplan64Teams3Runden und Turnierplan32Teams3Runden sein, lediglich mit insgesamt fünf Runden. Dabei sollen die ersten drei Runden jeweils 32 Spiele umfassen, des Weiteren sollten die Spiele der ersten Runde nur bei Bedarf nutzbar sein. Ab der vierten Runde soll eine Spalte nur noch 16 Spiele umfassen, wobei jeweils zwei Sieger aus der dritten Runde aufeinandertreffen. Die fünfte Runde umfasst ebenso 16 Spiele. Ich hoffe, ich konnte mein Wunsch vermitteln und ich würde mich freuen, wenn ich mir helfen könntet. Für Rückfragen stehe ich gerne bereit. Grüße und vielen Dank im Voraus, --Snookerado (Diskussion) 20:04, 5. Jun. 2019 (CEST)
Hallo Wiegels, du bist der Hammer! Ein großes Danke! So passt alles (bei den Namen kenne ich mich auch nicht allzu gut aus, aber den finde ich gut) und um die Dokumentation kümmere ich mich gern selbst. Grüße, --Snookerado (Diskussion) 14:03, 8. Jun. 2019 (CEST)
Hallo die Diskussionsteilnehmer bräuchten eure Hilfe: Einzig bei Wivoelke funktioniert die Verlinkung, bei (allen) anderen Usern auch nach einem halben Jahr nicht. Was machen letztere falsch? Dank, --Wi-luc-ky (Diskussion) 00:15, 15. Mai 2019 (CEST)
Das Problem ist nicht die Vorlage:Spk-digital, sondern die Erreichbarkeit des Servers www.spk-digital.de. Dass dieser nur durch mich erreicht werden kann, ist eine mehr als gewagte Schlussfolgerung.
Meine Angaben zur Erreichbarkeit bezogen sich auf die vorliegenden Rückmeldungen der Diskutanten in der im Mai wiederaufgenommenen Disku. Inzwischen hat sich die Vermutung erhärtet, dass eine IPv6-Konfiguration den intendierten Link blockiert. Bitte weiter mit Vorschlägen auf der einschl. Disku, um die Beiträge zusammenzuhalten. Vielen Dank, --Wi-luc-ky (Diskussion) 23:46, 20. Mai 2019 (CEST)
Kann der Zahlenkasten so verbreitert werden, dass dort auch Kombinationen wie 1600/56800 hineinpassen (Beispiel aus den gewählten Mandaten sämtlicher brasilianischen Stadträte), bisher wohl nur auf 100er angelegt. Ist eigentlich eher Kosmetik, aber die 2. Zahl fällt aus dem Kasten heraus. --Emeritus (Diskussion) 17:14, 31. Mai 2019 (CEST)
also, nachdem ich die Leerzeichen unten herausgenommen hatte, steht bei Stadträten jetzt alles in einer Reihe, zuvor gab es einen Umbruch!, die letzte 0 (fett) steht bei mir ausserhalb des Kastens und überschneidet sich mit der Fußnotenrefzahl [1]. Soviel zum Symptom. 1624 / 56810[1] sollte es aussehen. --Emeritus (Diskussion) 18:32, 31. Mai 2019 (CEST)
Wäre es gemäß Diskussion, d.h. mit frei benennbaren Parametern unkompliziert umsetzbar? Ansonsten wäre vielleicht eine neue Parteinfobox für alle Parteien außerhalb von D mit freien Parameterbezeichnungen sinnvoll. Was könntet ihr am einfachsten umsetzen? Danke & Gruß --Chtrede (Diskussion) 07:32, 5. Jun. 2019 (CEST)
Vielen Dank! So wie ich es verstehe sind aber die Aspekte wie z.B. "Sitze in Landtagsmandaten" dann nicht in anderen Staaten umsetzbar, da es z.B. dort nicht Landtag heißt. Oder kann man dort die Benennung auch flexibler machen? Gruß --Chtrede (Diskussion) 15:12, 13. Jun. 2019 (CEST)
Hallo, im Zuge der Parserfehlersuche hier und nach Hinweis von Perfektes Chaos möchte ich fragen, ob die Vorlage:Nextroom bitte auf https umgestellt werden kann, auf die die Links weiterleiten. In der Doku funktionieren zudem Bspp. 2 und 3 nicht; und auf die zughörige Linkliste sei hingewiesen, mglw. ein bot job. Danke, --Wi-luc-ky (Diskussion) 19:06, 19. Jun. 2019 (CEST)
ich hoffe, mit meinem Anliegen hier richtig zu sein. Und zwar geht es darum, dass der Hinweis auf den Diskussionsseiten kürzlich erschienener Artikel des Tages nicht mehr aktualisiert wird. Am Tag des Erscheinens des Artikels auf der Startseite steht auf der Disk des Artikels korrekterweise „Dieser Artikel ist heute Artikel des Tages“. Leider bleibt dieser Hinweis dann aber weiterhin so stehen, auch wenn der Artikel längst nicht mehr AdT ist. Doc Taxon meinte hier, dass es vielleicht an der Vorlage liegen könnte. Könnte sich das mal jemand anschauen?
Kannst du das irgendwie genauer zeigen? Es gibt diese beiden Vorlage:AdT-Vorschlag und Vorlage:AdT-Vorschlag Hinweis soweit ich das sehe, dann noch Vorlage:War AdT, das ist vermutlich jene, die du meinst. Dann liegt es wohl daran, dass es falsch ausgefüllt wurde, denn die Vorlage benötigt den Tag also das konkrete Datum.
Zur Problemschilderung müssen wir es machen wie bei Und täglich grüßt das Murmeltier: Wir erleben jeden Tag „heute“ immer wieder. Die Problemlösung: Wir vereinbaren einen Termin: Wann? morgen.
Aber im Ernst: So wie geschildert hat die Wiki-Software offenbar zur Zeit ein Problem mit der Seitenaktualisierung. Wenn man heute (21. Juni 2019) eine Seite öffnet, die am 19. Juni 2019 Artikel des Tages war, steht da „Dieser Artikel war am 19. Juni 2019 der Artikel des Tages“. Hätte man diese Seite am 19. Juni 2019 das erste Mal geöffnet, würde heute (21. Juni 2019) der Text „Dieser Artikel ist heute Artikel des Tages.“ stehen.
Danke für eure Rückmeldung. Als Bsp. kann ich die Disks der Artikel Steffi Graf, Lilien, Wilhelm Riedel (Tuchfabrikant) und Jüdischer Parasit nennen. Es gibt aber noch weitere Juni-AdTs, bei denen noch immer „ist heute AdT“ steht (zumindest bei mir). Bei allen Seiten wird die Vorlage mit Datum verwendet und trotzdem aktualisiert sich der Hinweis nach Ablauf des Präsentationstages auf der Startseite nicht. Am Tag der Präsentation war ich bei keinem der Artikel auf der Disk, weshalb eigentlich nichts im Cache gelandet sein dürfte, oder? (Sorry, bin nicht so der Techi.) Bei der Flagge Argentiniens (gestern AdT) oder Jürgen Habermas (vorgestern AdT) scheint der Hinweis hingegen aktualisiert worden zu sein?! --Seesternschnuppe (Diskussion) 14:03, 21. Jun. 2019 (CEST)
Ich würde sagen es ist trotzdem ein Servercacheproblem. Was passiert denn wenn du die Seiten mal aktualisierst? Ich habe es jetzt extra nicht gemacht, um das Ergebnis nicht zu verfälschen. Siehe Hilfe:Cache. Wenn die Vorlagen korrekt ausgefällt sind, kann man da leider wenig machen, manchmal geht halt irgendwo auf dem Weg im Netz etwas verloren. Es hakt halt ab und zu. --Liebe Grüße, LómelindeDiskussion14:59, 21. Jun. 2019 (CEST)
Habe den Cache geleert, aber es hat sich nichts getan. Die Lilien sind laut Hinweis bei mir noch immer AdT. Na ja, warten wir auf das Nachpurgen. :) Danke für eure Unterstützung. Liebe Grüße, --Seesternschnuppe (Diskussion) 15:37, 21. Jun. 2019 (CEST)
Hallo zusammen, gibt eine Möglichkeit, einen urlencode im Zeichensatz ISO 8859-1 durchzuführen? https://www.udeuschle.de erwartet das für den Paraemeter title offensichtlich so (also z.B. %F6 für "ö" und nicht %C3%B6). Auf die Schnelle habe ich nichts gefunden.--Cactus26 (Diskussion) 13:28, 24. Mai 2019 (CEST)
@PerfektesChaos: Eine Kleinigkeit, für codes < 0x10 kam ein Leerzeichen in die URL. Als Dankeschön habe ich versucht, das gleich zu beheben, kenne aber die Standard-Modul-Konventionen nicht, ich hoffe, es passt so: [5].--Cactus26 (Diskussion) 15:05, 25. Mai 2019 (CEST)
Weil das halbmillionenfach eingebundene Dings Vollschutz hat, hätte ich ansonsten über A/A gehen müssen.
Solch minderjährige Codes können im Wiki eigentlich nur Zeilenumbruch und ggf. horizontaler Tab sein; ich hatte bei der Erprobung allerdings nur normale einzeilige Namen auf dem Zettel.
@PerfektesChaos: Mir war es zufällig beim Linefeed aufgefallen. Nicht dass die von mir geplante Vorlage dass vernünftig unterstützen würde (da müsste ich noch ein bisschen was inverstieren, auch die Deuschle-Seite scheint sich bei Verwendung von %0A aus unerfindlichen Gründen schlicht aufzuhängen), aber mir war es aufgefallen und ich dachte, da dein Modul weit häufiger verwendet wird, könnte wirklich mal jemand darauf angeweisen sein.--Cactus26 (Diskussion) 12:09, 26. Mai 2019 (CEST)
Metadaten Italien und ISO-Code-Neuigkeiten
Hallo!
Bin da auf was gestoßen, was mir eine Spur zu heiß ist, um es irgendwie alleine anzugehen: Es hat gewisse Änderungen an den Codes von ISO 3166-2:IT gegeben, was Auswirkungen auf Metadatenvorlagen hat.
Zum Beispiel ist IT-GO für die Provinz Gorizia gelöscht worden. Den Code einfach (aus dem Artikel) zu eliminieren, bietet sich nicht wirklich an, weil die Vorlage:Metadaten Einwohnerzahl IT-36 (für die "über" Gorizia angesiedelte Region) auf "GO" besteht. Da gehört irgendwas umgeschichtet. Betrifft auch die anderen Provinzen dieser einen Region.
Außerdem stimmt bei Sardinien (neuer Code IT-SD für Provinz Sud Sardegna) irgendwas noch nicht, vergleiche beispielsweise, aber nicht nur San Pietro (Insel).
Bei Kategorie:Wikipedia:Lagewunsch (IT-36) wäre außerdem Der Eintrag kann mit Hilfe der ISO 3166-2:IT-36-Liste verfeinert werden. zu unterdrücken. Leider ist da die betroffene Vorlage nicht dokumentiert und ich werd aus dem Quelltext nicht schlau, wie man den Satz unterdrückt, ohne den Rest auch zu verändern, was nicht notwenig wäre. … «« Man77 »»Alle Angaben ohne Gewehr.21:33, 26. Mai 2019 (CEST)
Bei San Pietro und in der Lagewunschkategorie passt mittlerweile alles. … «« Man77 »»Alle Angaben ohne Gewehr.13:12, 27. Mai 2019 (CEST)
Vorlagenflut
Ist das so wirklich o.k.? Rund 550 neue, meiner Meinung nach redundante Vorlagen. Denn man kann das auch über die bereits vorhandenen Ländervorlagen realisieren.
Habe ich auch schon seit einiger Zeit mit großem Missfallen betrachtet, aber das müssen die Sportler unter sich ausmachen.
Es ist ein Rückfall in das Jahr 2005, bevor es Parameter gab.
Wenn man Ahnung hätte, dann würde man eine Programmierung mit der Jahreszahl und dem Staatskürzel verwenden, wie bereits umrissen; dadurch wird die Einbindung kein Byte länger. Aber so sindse halt.
Wenn sich da irgendwann mal was ändern soll oder die TemplateData haben wollen, dann haben die mangels einer einzigen zentralen Programmierungsseite ein größeres Problem; aber Support gibt es für solche Quatsch-Aktionen nicht.
Na ja Support, die sind mir ja nur in die Finger gefallen, weil sie Linterfehler erzeugt haben. Und den musste ich ja wohl beheben, ehe das Kreise zieht. --Liebe Grüße, LómelindeDiskussion13:40, 28. Mai 2019 (CEST)
So eine Vorlage wäre aus mehreren Gründen nützlich und wünschenswert. Die LeoBW-Datenbank gehört zum Netzangebot des Landeskundlichen Informationssystem Baden-Württemberg des Landesarchivs Baden-Württemberg und bietet eine Vielzahl an fundierten Beiträgen zur Landesgeschichte und Landeskunde. Mittlerweile referieren auf Beiträge aus dieser Seite zahlreiche Wikipedia-Artikel. Aus diesem Grund wäre es mal an der Zeit, für ein einheitliches Aussehen der Links zu sorgen und mit einer Vorlage natürlich auch die Einbindung komfortabler zu gestalten.
Da mir schlicht die Zeit fehlt, mich in das Thema von null auf neu einzuarbeiten, kann ich die Programmierung kaum alleine bewerkstelligen. Selbst mit entsprechendem Zeitaufwand würde ich vermutlich laufende Betreuung benötigen. Daher wäre es prima, wenn ein versierter Vorlagenbauer dies übernehmen könnte.
Natürlich habe ich mir auch zusammen mit Ziegelhar einige Gedanken gemacht, wie die Vorlage aussehen sollte. Für Rückfragen stehe ich natürlich gerne zur Verfügung. --Alabasterstein (Diskussion) 10:41, 18. Jun. 2019 (CEST)
Erläuterung: Link auf Landesarchiv Baden-Württemberg mit dem Titel Landeskundliches Informationssystem Baden-Württemberg–LeoBW, Doppelpunkt, Linkname des Inhaltes (am besten Übernahme des Datenbanktitels), – (Gedankenstrich), Zusatzinformation (als frei wählbarer Text)
(2) Parameteroptionen
(a) Eine mögliche Option sollte auf jeden Fall ORT sein. Denn die Ortseinträge sind bei LeoBW alle standardisiert nach dem Strichmuster:
Der nicht-fette Teil der URL ist stets der selbe. Die eindeutige Nummer (hier: 15165) ordnet hier im Beispiel aus dem Ortslexikon eindeutig den Wohnplatz Vogelbach zu. Man sollte der Vorlage die Nummer übergeben und als Output sollte der Link angesteuert werden.
(b) Als weitere Option soll ein Aufruf DOKUMENT möglich sein. Dazu ebenfalls eine Beispiel-URL:
Auch hier verändert sich der nicht-fette Teil der URL bei Dokumenten nicht. Jedes Dokument hat eine eindeutige Signaturnummer (hier: 5-515784), die den Aufruf ermöglicht und sogar im Partnersystem des Landesarchivs-BW ebenfalls einen Zugriff erlaubt.
Der Parameter Typ soll „Ort“, „Dokument“, „Person“ enthalten und muss an die Vorlage übergeben werden. Der Parameter ist für die Ermittlung der URL zwingend erforderlich.
Die ID soll die Datenbankschlüsselnummer enthalten und muss der Vorlage übergeben werden. Der Parameter ist für die Ermittlung der URL zwingend erforderlich.
Der Parameter URL-Titel komplettiert zusammen mit der Schlüsselnummer die URL. Der Parameter ist für die Ermittlung der URL zwingend erforderlich.
Der Parameter Anzeigetitel gibt die gewünschte Titelanzeige aus. Hier ist keine Verarbeitung notwendig.
Linktext soll ein freier Text sein, der lediglich von der Vorlage wiedergegeben wird. Hier ist keine Verarbeitung notwendig.
Hinweis an den Vorlagen-Programmierer: die dann noch zu schreibende Doku kann ich als Arbeitserleichterung gerne übernehmen.
Diskussion zu leo-bw.de
Hm, da fehlen aber noch zwei Parameter. Einer für das Ende der URL (Vogelbach+-+Wohnplatz) und einer für die Zusatzinformation mit Gedankenstrich hinter dem Link. Gruß, -- hgzh11:11, 18. Jun. 2019 (CEST)
Stimmt, das wäre dann schon die erste Hürde, mit der ich vermutlich zu kämpfen hätte. Der letzte Teil der URL hinter dem letzten Slash / resultiert letztlich aus der Lemmabezeichnung des jeweiligen Objektes in der Datenbank. In dem Fall reicht es wohl nicht nur, sich auf die Übergabe der Schlüsselnummer zu beschränken. --Alabasterstein (Diskussion) 11:14, 18. Jun. 2019 (CEST)
Es ist nicht möglich, innerhalb einer Wikipedia-Vorlage auf externe Inhalte zuzugreifen. Alles, was man hier angezeigt bekommen möchte, muss man auch hier hinterlegt haben. Es führt also leider kein Weg an der vollständigen Aufnahme des kompletten veränderlichen URL-Teils und von Parametern sowohl für die eigentliche Linkbeschriftung als auch für den angehängten Zusatztext vorbei. -- hgzh11:23, 18. Jun. 2019 (CEST)
Zum Thema URL: Ich bin mir nicht sicher, ob ich es richtig verstanden habe. Beispiel Orts-Link:
der rote Teil der URL ist für alle Ortsartikel gleich. Damit die Vorlage unterscheiden kann, um welchen Typus des Datenbankeintrag es sich handelt bekommt sie via dem Inputparamter Typ=Ort die Information, dass sie nach dem unveränderlichen Teil das Stück ORT/labw_ortslexikon/ dranhängen muss. Als nächstes folgen die Parameter ID und Titel. Und aus diesen beiden wird der Bestandteil 15165/Vogelbach+-+Wohnplatz erzeugt, oder wahlweise fasst man ID+Titel in einen Parameter zusammen. Vermutlich ist das Aufteilen aber übersichtlicher.
Zum Thema Zusatztext verstehe ich dich leider gar nicht. Der Wunsch ist lediglich, einen selbst gewählten Text (z.B. Hallo Welt) zusätzlich hinter den Link auszugeben. Das sollte ganz trivial sein.
Was mir aber gerade auffällt: man muss sowohl einen URL-Titel als auch einen Anzeige-Titel definieren, weil in den Fällen wo die Lemmabezeichnungen aus mehreren Worten zusammengesetzt sind hat die URL Steuerzeichen (Vogelbach+-+Wohnplatz), die man in der Beschreibung natürlich nicht haben möchte.
Sorry, ich hatte den Titel-Parameter übersehen, deshalb die Verwirrung. So wie von dir vorgeschlagen, geht es natürlich. Was noch fehlt, ist, wie du selbst bemerkt hast: man muss sowohl einen URL-Titel als auch einen Anzeige-Titel definieren, weil in den Fällen wo die Lemmabezeichnungen aus mehreren Worten zusammengesetzt sind hat die URL Steuerzeichen (Vogelbach+-+Wohnplatz), die man in der Beschreibung natürlich nicht haben möchte. Ebendiesen meinte ich mit dem Parameter für die eigentliche Linkbeschriftung. Gruß, -- hgzh11:40, 18. Jun. 2019 (CEST)
(2) Und noch eine Frage: scheinbar war die Unterscheidung zwischen dem URL-Text und der Beschriftung der Seite doch nicht erforderlich? Ich sehe nämlich nicht, dass du lediglich 4 statt 5 Parameter verwendest. --Alabasterstein (Diskussion) 13:39, 18. Jun. 2019 (CEST)
(4) Während die Parameter auf der Vorlagenseite selbst (mit dem Fehler) angezeigt werden, werden die Kopiervorlage und die Beispiele nicht angezeigt. Mag daran liegen, dass da generell noch ein Fehler drin ist. --Alabasterstein (Diskussion) 13:52, 18. Jun. 2019 (CEST)
Zu Punkt (3) weiß ich woran es liegt. Scheinbar gibt es mehrere (mind. 2 Verzeichnisstrukturen) für die Dokumententypen, was ich allerdings jetzt erst festgestellt habe.
weil es sich unter labw_findmitte befindet klappt das von mir gewählte Beispiel (Dokument Lehnbrief) nicht weil es unter labw_findmittel_02/labw-4-1910886 zu finden ist. Demzufolge muss man bei Dokumenten eine andere Lösung oder einen anderen Input wählen. --Alabasterstein (Diskussion) 14:02, 18. Jun. 2019 (CEST)
Beim TYP=DOKUMENT wird es schwierig, da LEO-BW eine Vielzahl von Kooperationspartnern [6] hat deren Dokumente jeweils mit anderen Bezeichnungen vor der ID arbeiten:
z.B. UB Freiburg
@Alabasterstein: zu (1) entweder muss „required“ (Pflichtparameter) oder „suggested“ (vorgeschlagen) gelöscht bzw. auf „false“ gesetzt werden. Wenn required = true, dann muss der Parameter „default“ entfallen. --Labant (Diskussion) 16:34, 18. Jun. 2019 (CEST)
Die Vorlagendoku habe ich repariert. Zu (2): ja, ich habe eine Möglichkeit gefunden, die URL-Kodierung korrekt umwandeln zu lassen, sodass ein eigener Anzeigetitel nicht in jedem Fall nötig ist. Falls es aber doch einen Fall geben sollte, in dem der automatisch generierte Titel unpassend erscheint, gibt es einen optionalen Parameter. -- hgzh13:37, 19. Jun. 2019 (CEST)
Fazit nach einigen Tagen der Benutzung: Ich bin generell sehr zufrieden mit der Vorlage. Die Schwierigkeiten bei dem Dokumenten-Typ liegt an der Uneinheitlichkeit der Ablage des Archives und der Aufwand, hier alle möglichen Fälle in der Vorlage einzubinden sehe ich nicht gerechtfertigt. Insofern deckt die Vorlage eine hohe Zahl bereits ab. Nochmal vielen Dank an hgzh für die Erstellung. Ich sehe damit den „Auftrag“ als beendet an und setzte hier mal auf erledigt. --Alabasterstein (Diskussion) 10:25, 26. Jun. 2019 (CEST)
Hallo! Wegen dieses Edits habe ich eine Nachfrage. Was wurde in die Vorlage falsch eingetragen, damit das Wort „keine“ erscheint? Auch auf Vorlage:Fußballspiel national erscheint im Artikel (Paarung Manu/Chelsea) bei Platzverweise „keine“, obwohl dort ein Eintrag erfolgte. Danke und Gruß. --Horst Gräbner (Diskussion) 19:38, 28. Jun. 2019 (CEST)
Bei dem Artikel Metropolregion Bogotá mußte ich auf die obige Infobox zurückgreifen und da steht unten barrios, was an sich in dieser Infobox richtig ist aber bei diesem Artikel falsch, weil es keine barrios sind sondern Städte und Gemeinden in der Metropolregion. Kann man das ändern? Tokota (Diskussion) 16:14, 25. Mär. 2019 (CET)
@Tokota: Du müsstest uns schon genauer spezifizieren, was du geändert haben möchtest.
Wir können dir inhaltlich nicht folgen und sind in der kolumbianischen Kommunalverwaltungsgliederung nicht so bewandert.
Du möchtest einen zusätzlichen Parameter als Schalter haben, der bei manchen Infobox-Einbindungen irgendwas anders macht?
Wobei das Design ja für einen „Ort“ konzipiert ist, und eine Metropolregion anscheinend nicht wirklich ein Ort im Sinne der Vorlage wäre, sondern als „Ort“ Städte und Gemeinden gelten, die hier jetzt aber Städte und Gemeinden enthalten sollen.
Was genau soll sich mittels dieses Schalters denn ändern?
In der optischen Darstellung von Metropolregion Bogotá taucht das Wort barrios nicht auf, also hat der Artikel selbst wohl kein Problem.
Die Doku zu Vorlage:Infobox Ort in Kolumbien ist herzlich nichtssagend und wurde noch niemals inhaltlich erstellt. Eigentlich wird dort aber wohl für Barrios= die Anzahl von, äh, wohl Stadtteilen erwartet, also eine Zahl, und das möge dann hier die Anzahl der politischen Gemeinden sein.
Das kann man eigentlich in der Beschreibung auf der Doku-Seite lösen, indem dort reingeschrieben wird, dass dies normalerweise die Anzahl der Stadtteile wäre, im Fall einer Metropolregion jedoch was anderes.
Ich denke, der allererste Schritt sollte sein, dass du die Seite Vorlage:Infobox Ort in Kolumbien/Doku bearbeitest und da erstmal überall inhaltliche Beschreibungen einträgst.
Hallo. Mir fällt immer wieder mal auf, dass manche Vorlagen nicht richtig an die mobile Ansicht angepasst sind. Der Quelltext quetscht sich manchmal links neben der Vorlage rein, so, dass die einzelnen Buchstaben eines Wortes untereinander stehen oder zwei oder mehrere Buchstaben nebeneinander stehen und der Rest dann abgeschnitten wird und eine Zeile tiefer wieder angefügt wird, so z. B. bei einigen Seiten, die die Vorlage:Infobox ICD eingebunden haben oder die Vorlage:Zeitleiste FDP Mitglied der Bundesregierung in Deutschland, bei der sogar im Artikel der FDP eine riesige Lücke Mitten im Satz klafft. Das erschwert das Lesen des Textes, und sieht auch nicht so toll aus. Ist es möglich, das so anzupassen, dass Vorlagen in der mobilen Ansicht möglichst zentriert erscheint oder der Quelltext erst nach der Vorlage angefügt wird? Einen Absatz oder so einzufügen, ist nicht wirksam. Viele Grüße – Olivenmus • Problem? Bitte hier entlang! • Beiträge • 11:50, 26. Mai 2019 (CEST)
Massiv falsche Angaben durch geändertes Verhalten der Vorlage:Inflation
Hallo,
bisher war es offenbar so gedacht, dass wenn man in die Vorlage:Inflation als Land „DE“, als Anfangsjahr ein Jahr vor der Euroumstellung und als Endjahr nichts (für aktuell) eingibt, automatisch die Umrechnung von DM in Euro mitvorgenommen wird. Das ist zwar nicht ganz klar dokumentiert, aber offensichtlich sind Autoren davon ausgegangen (z. B. hier oder hier – die Links gehen aufs Eingabefenster, damit man die Vorlageneinbindung gleich sieht).
Das ist nun aber offensichtlich aus irgendeinem Grund (der nach dem 1. Mai 2019, 21:10 eingetreten sein muss) nicht mehr der Fall, was zu krass falschen Angaben führt. Es scheint länderabhängig aufzutreten: ((Inflation|AT|140|1995)) liefert „16“, ((Inflation|DE|20|1995)) liefert „17“. Im Moment sehe ich da in der Vorschau „15“ und „28“ stehen, das passt nicht zusammen (eine Mark war etwa 7 Schilling).
Dem sollte zeitnah jemand mit Vorlagenkenntnissen nachgehen (ich habe auf die Schnelle nicht gefunden, wo diese Änderung herkommt).--Hanekomi (Diskussion) 13:01, 6. Jun. 2019 (CEST)
Ich habe noch nie was damit zu tun gehabt, aber einen ersten Blick in die beteiligten Vorlagen geworfen.
Verändert wurde wohl nichts; im Gegenteil.
Schaue ich etwa in Vorlage:Inflation/DE, dann stehen dort Berechnungsausdrücke, die als Parameter ein Bezugsjahr verarbeiten, und die bis 2018 explizite Zahlenwerte kennen.
Danke für den Hinweis auf die Unterseite. Ich vermute nach Vergleich mit der entsprechenden AT-Unterseite und Vorschauexperimenten, dass die Änderung vom 1. Juni mit der Begründung „Werte in 2002 wurden im Ergebnis um den Faktor 1,95583 falsch angezeigt.“ das Problem verursacht und im Sinne des Benutzers (den ich auf diese Diskussion hingewiesen habe) statt einer Löschung des Faktors eine Verschiebung in die Zeile für das Jahr davor angebracht gewesen wäre. (2002 war schon Euro-Ära, die Bargeldumstellung begann am 1.1.2002. Anscheinend wird in der Vorlage jede Jahresänderung einzeln aufmultipliziert, sodass die Änderung in einer Zeile auch Rechnungen für frühere Anfangsjahre betrifft; einen Schönheitspreis in Numerik bekommt man für sowas zwar nicht, aber für den gegebenen Zweck wird es reichen.) Das habe ich, da von den Experten nichts kam, jetzt erstmal so gemacht, obwohl es die Änderung mit der Begründung „Moved euro transition to 2002“ vom 20. Oktober letzten Jahres zurücksetzt, deren Urheberin als IP nicht ansprechbar ist, aber nicht vandalisch wirkt. Kann bitte jemand mit Ahnung kontrollieren, ob ich jetzt nicht meinerseits etwas verschlimmbessert habe?--Hanekomi (Diskussion) 13:21, 10. Jun. 2019 (CEST)
Hallo Hanekomi, Danke für Deinen Hinweis auf meiner Diskussionsseite. Mir war am 1. Juni 2019 auf der Seite Schönes-Wochenende-Ticket#Preisentwicklung der Berechnungsfehler aufgefallen. Ich hatte danach die Änderung in der Vorlage vorgenommen. Danach wurde es korrekt berechnet. Durch Deine Änderung werden dort jedoch die Beträge aus 2001 und älter wieder falsch berechnet (40,00 DM am 1. Jan. 2001 sind niemals inflationsbereinigt 13,60 €, sondern 13,60 x 1,95583 = 26,59 €). Das muss sich dann jemand ansehen, der mehr von dieser Materie versteht. Gruß, --PKautz (Diskussion) 13:59, 10. Jun. 2019 (CEST)
@PKautz: Ich glaube, hier kann ich weiterhelfen: ich hatte die Werte im Artikel Schönes-Wochenende-Ticket am 8. Juni als Notlösung durch 1,95583 geteilt, da die Vorlage zu diesem Zeitpunkt nicht automatisch von DM auf Euro umrechnete (siehe u.a. Hinweis auf der Diskussionsseite) und der Artikel auf der Hauptseite stand. Nach @Hanekomi:s edit sollte nun aber wieder alles passen und ich habe meine Änderungen im Artikel soeben zurückgesetzt. Grüße, --Földhegy (Diskussion) 21:31, 11. Jun. 2019 (CEST)
@Hanekomi, PKautz: Ihr könntet beide an der Verbesserung der Situation mithelfen.
Auf Vorlage:Inflation/Test gibt es lustige Testfälle, die jedoch in dieser Form nicht ausreichen.
Grund: Es steht nur eine Zahl da, was jetzt im Moment grad rauskommt – es fehlt jedoch der Vergleichswert, was hätte rauskommen sollen.
Auf dieser Seite findet ihr beispielsweise eine Gegenüberstellung, welcher konstante Wert erwartet wird, welcher Wert momentan herauskommt, und das diff wird automatisch knallrot, wenn beide nicht übereinstimmen.
Für einen Soll-Ist-Vergleich könnte euch hiesiges Werkstattpersonal sogar mithelfen, indem eine spezielle kleine Test-Untervorlage geschrieben wird, die sämtliche Parameter von Vorlage:Inflation übergeben bekommt, plus das erwartete Resultat. Damit ließe sich eine komplette kleine Tabellenzeile generieren, die alle Eingabewerte auflistet, und das berechnete Ergebnis, und ein Häkchen bzw. die komplett rot unterlegte Tabellenzeile wenn das nicht zusammenpasst.
Erst mit sowas lässt sich die Programmierung pflegen.
Ihr habt euch ja jetzt in die Materie eingearbeitet; könntet insbesondere kritische Eckwerte rund um 2001 erarbeiten, und außer DE noch mehr Länder zumindest kursorisch abgrasen.
Klar ist, dass es nicht mit dem aktuellen Jahr geht, sondern nur mit zwei explizit vorgegebenen.
Nur dann kann nach einer Veränderung der Programmierung die weiterhin korrekte Funktion nachgeprüft werden.
Ohne Kenntnis der richtigen Zielwerte kann es momentan noch nicht einmal repariert werden.
Insgesamt ist das ein Fall, der von jemandem mit Langeweile dringend auf „Lua“ umgestellt werden sollte, wo sich die Daten sehr viel übersichtlicher pflegen lassen und die Programmierung auch wesentlich nachvollziehbarer machbar wäre.
Da muss das Problem irgendwo bei dir liegen. Ich sehe nämlich eine weiße zwölf auf grünem Grund, sowohl am Laptop (Firefox Windows 10) als auch mobil (Chrome Android). Gruß, -- hgzh00:42, 17. Jun. 2019 (CEST)
Der ist in der Navileiste vereinbart als Verlinkung auf Jüdischer Friedhof (Usingen), und dass das ein Selbstlink ist, nämlich eine implizite WL auf sich selbst, kann die Vorlage nicht wissen.
Sowieso eine höchst merkwürdige Konstruktion, der Artikel, mit einer Navileiste mitten in der Landschaft.
Es ginge nur, in der Navileiste eine Abfrage einzubauen, ob die momentan dargestellte Seite Usingen wäre, und falls ja dann nicht zu verlinken und falls nein dann wie gewünscht.
Vielen Dank zunächst für die Antwort. Eine Abfrage einzubauen, ob die momentan dargestellte Seite Usingen wäre, löst nur den Spezialfall. Generell kann der Inhalt unter einem Lemma beliebigen Namens stehen. Anderers Beispiel Landtagswahl in Lippe 1838 behandelt einerseits die Wahl und andererseits die Abgeordnetenliste. Aus pragmatischen Gründen ist das ein Artikel, bei anderen Wahlen haben wir eine Trennung (z.B. Landtagswahl im Volksstaat Hessen 1921 und Liste der Mitglieder des Landtages (Volksstaat Hessen) (2. Wahlperiode)). Die Vorlage:Navigationsleiste Wahlen zum Landtag Lippe (Fürstentum Lippe) verküpft die Sammelartikel. Jetzt könnte ich in einzelnen Artikeln dieser Serie die Abgeordnetenlisten auslagern. Dann bräuchte ich Vorlage:Navigationsleiste Abgeordnete Landtag Lippe (Fürstentum Lippe). Und die würde dann teilweise auf reine Abgeordneten-Listen (unproblematisch) und manchmal eben auf die Mischartikel á la Landtagswahl in Lippe 1838 verweisen. Da kommen wir über Namensähnlichkeit nicht hin. Sinnvoll wäre imho die Möglichkeit, optional Parameter "Link X ist zu schwärzen". Im Usingen-Beispiel würde dann in der Navi sinngemäß stehen ‹Zu schwärzen1="Jüdischer Friedhof (Usingen)"; Zu schwärzen2="Schmitten_(Hochtaunus)#J.C3.BCdische_Gemeinde"› Und die Vorlage müsste diese Parameter dann so interpretieren: "Wenn das Lemma den "zu schwärzen"-Parameter entspricht, dann als Schwarz darstellen". Dann könnten die Inhalte in Artikeln beliebigen Lemmas stehen.--Karsten11 (Diskussion) 09:59, 12. Jun. 2019 (CEST)
Sie bietet lediglich den einheitlichen technischen Rahmen.
Das Begehren würde erfordern, dass der extrem unterschiedliche und beliebige übergebene Textinhalt als Wikitext interpretiert und dann in einen anderen Wikitext umgewandelt werden solle.
Sowas machen wir nicht. Das ist extrem fehleranfällig und komplex, dies dann auch noch für mehrere in Frage kommenden Verlinkungen in Alternativtexte umzubasteln.
Vorlage:Navigationsleiste wird in über 482.000 Artikeln verwendet und ist ein Rückgrat der Artikelnavigation. Sie hat robust zu sein, einfach programmiert, für viele Fachautoren vieler Themenbereiche für viele eigene Ableitungen anwendbar, und verträgt keine Bastelarbeiten, um drei oder fünf ohnehin fragwürdige Extrawürstchen irgendwie hinzufummeln.
In Usingen wird die innere Navigationsleiste missbräuchlich eingesetzt.
Das ist für Leser verwirrend und habe ich noch nie vorher gesehen.
Es gibt nur eine einzige Navigationsleiste(n-Gruppe), und die steht geschlossen am Ende des momentan dargestellten Artikels und betrifft den gesamten dargestellten Artikel.
Artikelchen-im-Artikel gibt es nicht.
Tipp: Einfach die Navileiste dort weglassen, wo es keinen eigenen Artikel gibt, und gut ist.
Ich vermute, bei den anderen genannten Fällen wird es sich ähnlich verhalten; möglicherweise vom identischen Autorenkreis stammend oder beeinflusst.
Vorschlag für solche Sonderfälle: Statt der Navileiste im Abschnitt ein handverlesenes "Siehe auch", das zu Artikeln führt, welche die Navileiste enthalten:
Hallo, die Ausgangsfrage stammte von mir. Nach den beiden Diskussionen ist festzustellen, dass es – so wie die Vorlage:Navigationsleiste konstruiert ist und wohl auch bleiben soll – einen funktionalen Zielkonflikt gibt, d. h.:
A) Wer in der NL auf einen Artikelabschnitt verlinken will, um von der NL aus schnell an den richtigen Abschnitt zu navigieren, wird im dortigen Artikel auf die Markierung in der NL verzichten müssen – wo immer die NL im Artikel steht (wenn sie denn im Art. steht).
Oder:
B) Wer die Markierung haben will, muss auf die Abschnittsverlinkung verzichten.
Deshalb möchte ich nochmals anregen, die Hilfe:Navigationsleisten um den Hinweis zu ergänzen: „Weiterleitungen und Abschnittslinks als Linkziele werden in den Navigationsleisten der einschlägigen Lemmata nicht markiert angezeigt.“
Wenn das so richtig wäre, würde ich um eine gut oder besser formulierte Ergänzung bitten. Danke für bisherige Erläuterungen und Vorschläge oben, --Wi-luc-ky (Diskussion) 22:27, 16. Jun. 2019 (CEST)
Das liegt außerhalb der Zuständigkeit dieser Werkstatt und ist eine Angelegenheit der Artikelgestaltung und Strukturierung.
Diese Werkstatt beschäftigt sich mit der Programmierung von Vorlagen und ihrer Organisation im Vorlagen-Namensraum.
Navileiste(n) gehören an das Ende des Gesamt-Artikels und verknüpfen den Gesamt-Artikel mit anderen Artikeln im selben Themengebiet.
Wenn man eine Navileiste in einen einzelnen Abschnitt mitten in einem Artikel setzt, dann muss zwangsläufig Schrott dabei herauskommen.
Ist immer so, wenn man Sachen, die für einen ganz bestimmten Zweck vorgesehen sind, dazu missbraucht, etwas völlig anderes damit anzustellen.
Die im vorigen Beitrag getroffenen Feststellungen über Verlinkungen sind falsch. Die Navileiste selbst funktioniert problemlos – in allen anderen Artikeln. Nur in denjenigen Zielartikeln, die sich überhaupt nicht komplett mit dem gemeinsamen Thema beschäftigen, sondern wo das nur ein Unterabschnitt ist, kann eine Navileiste nun mal nicht nur für einzelne Teilaspekte verbaut werden, weil sie per Grundkonzept zwischen Artikeln navigiert, die in ihrer Gesamtheit zum selben gemeinsamen Oberthema gehören.
Nichts anderes habe ich mE deskriptiv gesagt, PerfektesChaos: „Wenn jemand dieses macht (WLs oder Abschnittlinks einbaut), kriegt er das (keine Markierung). Wenn jemand jenes macht (keine Abschnittlinks), kriegt er das in der NL nicht (keine Verlinkung auf den Abschnitt).“ Als reine Funktionsbeschreibung erst einmal nach Erfahrung mehrerer Nutzer richtig; ob als Anleitung sinnvoll oder falsch, ist eine andere Frage (die ich ja gern geklärt haben wollte).
Du willst es präskriptiv sagen: „Gebrauche keine WLs und Abschnittlinks als Linkziele, denn dann funktioniert die NL nicht bestimmungsgemäß!“ Eine solche oder ähnliche Anweisung findet sich bisher nicht auf der Doku, so dass es zu vermeidbaren Anwendungsfehlern kommt.
Ist halt nur eine Frage, wie es den Erstellern von NLs beigebogen wird, keinen „Schrott“ zu bauen, und welche Formulierung in die Doku kommt.
Nun gibt es jene angetroffene fragliche NL, in die nach meiner Ersetzung der WLs und Abschnittslinks durch Lemmata + Pipelink wiederum Abschnittslinks eingefügt wurden. Schnöder WP-Alltag. Offensichtlich ist es Nutzern wichtiger, auf einen Abschnitt zu verlinken, als dass das Lemma in der NL im einschl. Artikel mit entsprechendem Abschnitt markiert wird. Nachvollziehbare vermeintliche Güterabwägung ohne Rücksicht auf die intendierte Funktionsweise.
Hallo, ich habe auf Wikidata eine deutsche Übersetzung des Datenobjekts "tcl" rückgängig gemacht. Die Übersetzung hatte ich vorher eingefügt und dachte mir, die Vorlage ((Infobox Programmiersprache)) (und ((Infobox Software))) übernähmen den deutschen Text (Sprache der Daten musste ich ja angeben). Tatsächlich werden aber beide Titel (englisch und deutsch) übernommen und hintereinander angezeigt. Ist es technisch vorgesehen, dass man den Titel noch mal nach der Sprache konkretisieren kann? --KeksPing mich an! um 20:36, 4. Jun. 2019 (CEST)
Nach Studium des verantwortlichen Moduls Modul:Wikidata ist in Zeile 430 und 431 vermerkt:
-- More snaks with same property, we concatenate using a commavalue=table.concat(value,", ")
also mehrere Angaben werden mittels Komma hintereinander zusammengefügt.
In diesem Modul ist auch festgelegt, dass mehrere Einzelnachweise alle eingefügt werden, unabhängig von der jeweiligen Sprache.
Da dieses Modul in mehreren Wiki-Sprachversionen verwendet wird, müsste eine entsprechende Änderung an geeigneter Stelle angeregt werden, wobei ich nicht weiß wo. --Labant (Diskussion) 07:13, 17. Jun. 2019 (CEST)
@Labant: Vielen lieben Dank, ich werde das auf Phabricator anstoßen und hier dann den Task hinterlegen. Komme heute aber wahrscheinlich nicht mehr dazu. --KeksPing mich an! um 12:51, 17. Jun. 2019 (CEST)
Wenn ein User - so wie ich - die automatische Silbentrennung aktiviert, dann bekommt man die linke Spalte extrem schmal mit vielen Zeilenumbrüchen in einer Tabellenzelle und ojne diese Einstellung nach fast jedem Wort (das längste Wort bestimmt die Spaltenbreite). Die Vorlage braucht also (Mindest-)breiten für alle Spalten. Das teste ich zurzeit mit diesen Parametern. Da ich nicht weis, ob das so passt, sind sie noch ohne Doku. ÅñŧóñŜûŝî(Ð)23:47, 19. Jun. 2019 (CEST)
Das lag an Vorgabewerten für diese Parameter. Ich habe die jetzt auf Null gesetzt. Damit dürfte es auf "unbescholtene" Einbindungen keine auswirkung mehr haben. Jetzt sehen die Einbindungen normal aus. ÅñŧóñŜûŝî(Ð)12:12, 20. Jun. 2019 (CEST)
Moin, kann dort bitte jemand den Parameter Nebenbox einschl. Dokumentation einbauen? Damit in einem Artikel mit zwei Boxen nicht der Lagewunsch oder die Koordinaten der einen Box die der anderen Box im Kopf des Artikels überdeckt. Danke ••87.169.32.11718:56, 12. Jun. 2019 (CEST)••
Hat keiner widersprochen; Websites sind mehr kurzlebig denn unsterblich, also mag unser Artikel ein off-dings beschreiben, und ich wüsste aus dem Handgelenk ein Dutzend relevante Artikel, die auf die 1990er zurückgehen.
Irgendeine automatisch auslösbare Kat mit Jahreszahl?
sieht nicht so aus, es wäre aber dringend an der zeit, die systematik für alle publikationen (erstveröffentlicht + letztveröffentlicht) anzugehen. das ganze kann man aber sicherlich bald sinnvoll aus wikidata ziehen. --W!B: (Diskussion) 13:02, 25. Jun. 2019 (CEST)
Hallo. Ich hatte am 8. und 10. Juni LAs auf die Vorlagen in der Kategorie:Vorlage:Land IOC alias und der Kategorie:Vorlage:Landesflagge IOC alias gestellt, weil diese Vorlagenflut (IOC-Code) weitgehend eine Parallelstruktur zu den Ländervorlagen mit Flagge (ISO-Code) abbildet. Im Rahmen der LD zeigte sich, dass es wohl einen Bedarf daran gibt, Die mit Vorlage:FlaggeIOC umgestzte Funktionalität verbessert zu erhalten. So z. B. nur eine Vorlage statt Hunderte. Die LAs habe ich zurückgezogen und bitte hier um Meinungen zur Verbesserung. ÅñŧóñŜûŝî(Ð)00:58, 23. Jun. 2019 (CEST)
Da gibts nix zu verbessern. Das ist unwartbar und gehört entfernt. Sowas muss (und kann) man mit einem dicken Switch-Statement abbilden, aber das ist ein Neuschreiben. --Wurgl (Diskussion) 13:57, 25. Jun. 2019 (CEST)
Da könntest du richtig liegen. Statt einem Switch wäre auch Lua möglich, denn das ist ja mehrfach Verzweigt. Einmal IOC-Kürzel, Jahr -> Name des Landes und einmal IOC-Kürzel, Jahr -> oly. Wettbewerb. und dann nach IOC-Kürzel, Jahr -> Flagge. letzteres gibt es schon mit ISO-Kürzeln. ÅñŧóñŜûŝî(Ð)17:48, 25. Jun. 2019 (CEST)
Jetzt ist das flach quer über den Namensraum. Wenn das wenigstens Namen mit FlaggeIOC/irgendwas wäre, also Unterseiten zur Vorlage. Und ob Lua notwendig ist … so viel hab ich mit dem switch-Statement nicht gemacht und weiß nicht ob man das verschachteln kann, von der Syntax ist diese Möglichkeit zu erwarten. Dass das Zeug recht wild wird, ist klar – egal ob Lua oder Vorlagen-Syntax. Eventuell kann man auch Teile davon generieren um die Tipparbeit und Fehleranfälligkeit beim Tippen zu reduzieren. Aber so wie das jetzt ist … man kann es so machen, aber dann ist es halt unwartbar. Oder guckt jemand tatsächlich 600+ Files durch und das auch noch bei voller Konzentration? --Wurgl (Diskussion) 19:51, 25. Jun. 2019 (CEST)
Nein, dass wird keiner machen. Denkbar wäre eine zentrale Seite mit Daten hier (nicht auf Wikidata, da es dort nicht wartbar ist), welche aktualisiert werden kann. ÅñŧóñŜûŝî(Ð)20:43, 25. Jun. 2019 (CEST)
Umfrage Technische Wünsche: Themenschwerpunkt „Leichter mit Vorlagen arbeiten“
Falls es nicht okay ist, diesen Hinweis hier zu veröffentlichen, sind Tipps für geeignete Diskussionsseiten per Ping an Benutzerin:Johanna Strodt (WMDE) gern gesehen.
Bis zum 30. Juni findet in der deutschsprachigen Wikipedia die vierte Umfrage Technische Wünsche statt. In diesem Jahr wird erstmals darüber abgestimmt, in welchem Themenschwerpunkt das Technische-Wünsche-Team für Verbesserungen sorgen soll. Es stehen 13 Schwerpunkte aus ganz unterschiedlichen Bereichen zur Wahl. Für die hier Mitlesenden könnte von Interesse sein, dass „Leichter mit Vorlagen arbeiten“ einer der Themenschwerpunkte ist, für die abgestimmt werden kann.
Nach der Umfrage wird sich das Team Technische Wünsche mit dem Gewinnerschwerpunkt auseinandersetzen und in enger Zusammenarbeit mit der deutschsprachigen Community verschiedene Probleme darin angehen. Welche Probleme das sind, wird gemeinsam mit den Aktiven in den Wiki-Projekten nach der Umfrage ermittelt.
Vorlage Infobox für Aussichtswarten bzw. Aussichstürmen
Hallo, mir ist in den letzten Tagen aufgefallen das es für diese Art von Gebäuden bzw. Bauwerken keine richtig passende Vorlage gibt, es gibt sogar eine Art Versuch durch Tabellen eine Aet Infobox zu bauen die mehr Schlecht als Recht Funktioniert.
Bekomme ich da auch Betreiber bzw. Eigentümer untergebracht? Habe ja beim ÖTK gesehen das diese aktuell genutzte Vorlage (Selbst gebaute Tabelle) nicht so wirklich alles erfasst, gerade der Abschnitt Lagekarte ist ja nicht möglich. Teils haben die noch Betriebenen Warten auch eine Kontaktadresse die sollte wie bei den Schutzhütten auch in die Infobox. Wenn der Erbauer und Betreiber (aktueller Eigentümer) abweichen muss das ja auch irgendwie gekennzeichnet werden. Da es auch nicht so leicht zu erkennen ist wo dieses alles umgebaut werden müsste kann ich nicht sagen ob noch weitere Angaben rein gehören würden. Einige ÖTK Warten haben bis auf 1 bis 2 Bilder und einen kurzen Text garkeine grossen Angaben. Wohl weil es halt kein Feld gab wo diese hätten angegeben werden können. --Seeler09 • Leider nicht in Ihrem Land verfügbar • Mitstreiter im Alpinprojekt gesucht10:03, 20. Jun. 2019 (CEST)
Da ich zur Zeit die Bauwerke aus der Kategorie:Sendeanlage mit der Vorlage anpasse, kann ich sagen, dass dort sehr ähnliche Fragestellungen auftreten. Meine Vorgehensweise ist da: Erbauer als Bauherr zu T_BAU_HERR, Besitzer kommen zu BESITZER, Eigentümer, Betreiber, Nutzer etc. zu WEITERES
Der Parameter WEITERES ist praktisch eine Tabelle, in dem jeder beliebiger Text eingefügt werden kann. Nach dem Muster:
Wenn ich es Richtig verstehe sollen Ort, Region und Staat in einer Zeile und kommagetrennt angezeigt werden: kann man machen, müsste aber auf Vorlage Diskussion:Infobox Sendeanlage diskutiert werden, da es dann die Artikel mit der Infobox Sendeanlage auch betreffen würde.
Ort der Lagekarte: Bei Sendeanlagen und Aussichtstürmen verschiedene Positionen: schwierig, Wenn bei allen gleich verschoben werden, einfach, aber eine Diskussion scheint auch hier angebracht.
Wann ist die Vorlage fertig? Wenn die obigen Fragen geklärt sind, dann sehr zeitnah.
Die Lage wie bei Vorlage:Infobox Schutzhütte, wo man die Bezugslage eintragen müsste, da die Höhenlage ja Unterschiedlich ist, M.ü.A. H.N.N., und so weiter... je nach Land wo die Anlage steht. Diese gehört ja nicht als Liste aufgezählt (Siehe Schutzhüttenvorlage) Der (Vorlage) würden im Grunde auch nur die Stufenanzahl, und einige Bauliche Unterschiede fehlen. Da braucht man keine Gesonderten Angaben, da gibt es ein Feld wo die Genaue Lage rein kommt. Die Lage-Karte wird ja dann aus der Position (Längen // Breiten Grad) erstellt. --Seeler09 • Leider nicht in Ihrem Land verfügbar • Mitstreiter im Alpinprojekt gesucht13:23, 21. Jun. 2019 (CEST)
Wenn du mit Lage die HöhenlageLAGEPUNKT meinst, habe ich das obige Beispiel um einen fiktiven Lagepunkt ergänzt. Für Deutschland wird hinter dem Zahlenwert ein Schrägstrich eingefügt und dann der Bezugswert. Für andere Staaten ist dies nicht erforderlich, da die Vorlage diese Information automatisch aus dem Parameter REGION-ISO bezieht.
Höhenlage Richtig wo Hoch die Stelle ist wo das Gebäude steht. Treppenstufen nunja da wird es auch kaum Quellen für geben die diese Anzahl erwähnen. Also im Grunde eine Nette Ergänzung die aber wohl kaum zum Tragen kommen wird. Ob wirklich noch weitere Daten zum Gebäude Wichtig sein dürften halte ich erstmal für Fraglich. Damit dürfte im Grunde alles Relevante zum Tragen kommen? --Seeler09 • Leider nicht in Ihrem Land verfügbar • Mitstreiter im Alpinprojekt gesucht13:07, 23. Jun. 2019 (CEST)
"Blöde" Frage: Haben wir damit nicht nun eine Redundanz? Vorlage:Infobox Sendeanlage und Vorlage:Infobox Aussichtsturm haben doch, wenn ich das auf die Schnelle richtig überblicke, im Wesentlichen die gleichen Parameter. Wir haben – beginnend beim einst heftig umkämpften DT – einige große Türme, die Aussichtstürme sind und die als Nebenfunktionen auch/unter anderem (umfangreiche) Sendeanlagen haben, vulgo behauptete "Fernsehtürme". Wäre es eventuell nicht sinnvoller doch nur eine gemeinsame Vorlage zu haben, z.B. als Vorlage:Infobox Turm – als solche wären alle Varianten von Türmen abgedeckt, meint mit j2mc --Elisabeth17:21, 26. Jun. 2019 (CEST)
Ich musste zunächst noch einige Anpassungen am Modul vornehmen, da einige Listenwerte aus der Vorlage:Infobox Sendeanlage übernommen wurden.
Da das mit der Definition, was ein Fernsehturm, ein Sendeturm oder ein Funkturm ist, behandelt das Modul (und damit die Vorlagen) Aussichtstürme als Aussichtstürme ohne Sendeanlagen (Kategorie:Aussichtsturm nach Staat). Sendetürme und Fernsehtürme werden gleich behandelt (Kategorie:Sendeturm nach Staat) und sind Türme, ggf. Aussichtstürme mit Sendeanlagen.
Vom Prinzip kann man eine Infobox für einen Aussichtsturm (ohne Sendeanlagen) mit der Vorlage:Infobox Sendeanlage und der Zuweisung CAT_TYP = Aussicht erstellen, nur ich kann mir schon denken, was dann aus dem großen Kreis der Benutzer gefragt wird: „Warum die Infobox Sendeanlage bei einem Aussichtsturm?“.
Die Weiterentwicklung zu einer Vorlage:Infobox Turm ist sinnvoll, ist dann aber ein längerfristiges Projekt, da dann z. B. eine Loslösung des Moduls von der Vorlage:Infobox Sendeanlage erfolgen muss. --Labant (Diskussion) 21:03, 26. Jun. 2019 (CEST)
Danke, Labant, für die Antwort. Wenn ja in den beiden Vorlagen sowieso die Wörter "Aussichtsturm" und "Sendeanlage" problemlos austauschbar sind, dann zeigt mir das doch, dass es nur ein Vorlage braucht, deren Namen unverfänglich passend für beide ist, für "Aussichtsturm" und "Sendeanlage" und deren beider Schalter für die Zusatzfunktionen. … Oder irre ich grob?
Du sprichst das Problem eh auch an, das ich oben etwas diskret dargelegt habe. Es gibt nämlich keine wirklich tragfähige Definition, was wirklich "ein Fernsehturm, ein Sendeturm oder ein Funkturm ist". Und dadurch, dass die meisten Aussichtstürme (siehe DT, Eiffelturm, Stratosphere Las Vegas, etc. pp, die eindeutig als Aussichtstürme errichtet und betrieben werden) sowieso auch Sendeanlagen tragen, als Sende- bzw. Funktürme quasi "missbraucht" werden; umgekehrt aber wiederum sehr viele Funktürme, sogenannte "Fernsehtürme", aus verschiedenen Hintergründen gleichzeitig als Aussichtstürme dienen (aus touristischen Gründen, als Statussymbol; auch aus Gründen, weil die Türme mit der Aussichts- und Restaurantfunktion besser der Bevölkerung zu verkaufen sind, als hohe Trümmer als Türme, die begonnen mit dem Stuttgarter Fernsehturm wie Schlote aussehen – deutlich wahrnehmbar bei diesem, wie z.B. auch beim Fernsehturm Emley Moor.
Besser sollte, mMn, jetzt schon eine Vorlage:Infobox Turm für alle gemacht werden, bevor jetzt vielfach die Vorlage:Infobox Aussichtsturm eingebunden wird und es damit später dann komplizierter wird, die beiden Vorlagen zu einer zusammenzuführen, meint --Elisabeth11:00, 27. Jun. 2019 (CEST)
Ganz generell ist es sicher wünschenswert wenn der mittlerweile stark gewachsene „Zoo an Vorlagen“ deutlich verschlankt und übersichtlicher gestaltet wird. Gegen diesen Wunsch ist gar nichts einzuwenden.
Trotzdem ist zu berücksichtigen, dass eine Sendeanlage in Turmform, sei es nun ein Stahlfachwerkturm, ein Betonturm oder welche Ausführungsart auch immer, ganz viele technische Felder braucht, wogegen ein reiner Aussichtsturm neben Standort, Gesamthöhe und Plattformhöhe (oder -höhen) die restlichen Felder nicht braucht. Stahlbetontürme, welche Senden und eine öffentlich zugängliche Aussichtsplattform bieten fallen rein technisch dann trotzdem in die Sparte der Sendeanlagen. Ob man bei einer Vorlage mit zig Optionen als Anwender dann noch zurecht kommt wenn man sich an einem Bauwerk anwendet, wo man die Optionen nicht braucht sei mal dahin gestellt.
Vielleicht lässt sich das technisch am ehesten so lösen, dass man eine Generalvorlage mit allen Optionen baut, diese Vorlage wie von Elisabeth vorgeschlagen schlicht als Vorlage: Infobox Turm bezeichnet und dann in der Doku drei Standardkopiervorlagen für die gängigsten Turmarten anfertigt. Alle nicht benutzten Optionen werden dann auch automatisch nicht angezeigt. --Alabasterstein (Diskussion) 11:21, 27. Jun. 2019 (CEST)
Turm, Aussichtsturm, Aussichtswarte, Wasserturm, und so weiter was mit Sendeanlagen wirklich oft Null zu tun hat getrennt von den Sendeanlagen? Denn diese Vier angesprochenen Turmarten sind wohl kaum Sendeanlagen? Ob man nun noch den Leuchttum mit aufnimmt? So das alles was Sendet (Sendeanlage) wird, und der Rest wird zum Turm, eine genauere Bezeichung um welche Art von Turm es sich handelt lässt sich ja einbauen. Siehe Vorlage:Infobox Schutzhütte wo auch Biwaks, Biwakhütten und Biwakschachteln inbegriffen sind zu den eigentlichen Schutzhütten, Berghütten, Almhütten. Um werlche Art Schutzhütte es sich handelt lässt sich ja eintragen. --Seeler09 • Leider nicht in Ihrem Land verfügbar • Mitstreiter im Alpinprojekt gesucht11:28, 27. Jun. 2019 (CEST)
Ich habe einen neuen Abschnitt begonnen, da die eigentliche Anfrage aus meiner Sicht erledigt ist.
@Elisabeth59, Alabasterstein: Vom Prinzip richtig. Zu bedenken gilt es, das beim Hinzufügen der Vorlage im Visual Editor die Handhabung auch dem nichttechnisch visierten Benutzer nahegebracht werden muss.
benötige ich selber ersteinmal wieder einen funktionstüchtigen Rechner. Zur Zeit arbeite ich mit Tablet, Dauer: Tage (hoffentlich) oder Wochen (befürchte ich).
sind Namensvorschläge für dieses Modul immer Willkommen.
Da das Modul aus mehreren Untermodulen besteht, ist während der Umstellung die Vorlage:Infobox Sendeanlage nicht einsatzfähig. Ein Hinweis in den betreffenden Artikeln (ca. 1100) wäre wünschenswert, sonst erscheint der relativ unschöne Modul-Fehlertext nebst Einsortierung in die Kategorie:Wikipedia:Seite mit Skriptfehlern.
Da komme ich auf die Frage zurück. Wieso nicht eine Vorlage für Türme? Die dann Aussichtstürme, Aussichtswarten, Wassertürme, Leuchttürme, und was es da noch gibt Beinhaltet? z.B. Burgtürme? Und die Sendeanlagenvorlage davon trennen. Da diese Sendeanlagenfunktion nicht bei jedem dieser anderen Turmarten überhaupt vorgesehen ist. Soweit bekannt ist eine Sendeanlage eine Spezielle Form eines Turmes. Ob dieses am Ende auch mit nureiner Vorlage machbar ist kann ich nicht Beurteilen. Im Grunde ist es wie etwas weiter Oben erwähnt wie die Vorlage:Infobox Schutzhütte, wo nicht nur Schutzhütten, Berghütten, Almhütten, sondern auch Biwaks bzw. Biwakschachteln die eher keine richtige Hütten sind inbegriffen sind. --Seeler09 • Leider nicht in Ihrem Land verfügbar • Mitstreiter im Alpinprojekt gesucht12:40, 28. Jun. 2019 (CEST)
Die Frage ist: was benötigen Aussichtstürme mehr als nicht bspw. bereits über die Vorlage:Infobox Bauwerk abgedeckt wäre? Der von mir in diesem Jahr geschriebene und sogar exzellent gewählte Bauwerksartikel über den Thyssenkrupp Testturm (kein reiner Aussichtsturm, in 1. Linie ein Industriebauwerk, keine Sendeanlagen aber mit öffentlich begehbarer Aussichtsplattform) nutzt den und ich vermisse in der Vorlage eigentlich nichts. --Alabasterstein (Diskussion) 12:43, 28. Jun. 2019 (CEST)
Hallo, hatte in der Disku dort die Frage gestellt, wie eine Phrase wie bspw. in situ mittels dieser Vorlage verlinkt werden könnte. Dank für Beiträge dort, --Wi-luc-ky (Diskussion) 22:15, 29. Jun. 2019 (CEST)
Sorry, aber bei einer Vorlage mit einem derart kryptischen Namen werde „ich“ nichts tun. Nicht einmal dort etwas schreiben. Selbst, wenn ich wüsste, wie es funktionieren könnte. Wenn die Vorlage allerdings auf einen sprechenden Namen verschoben würde, ließe ich da mit mir reden und würde mich sogar um das TemplateData kümmern. --Liebe Grüße, LómelindeDiskussion11:44, 30. Jun. 2019 (CEST)
Verständlich, wenn da so’n Kryptokürzel daher kommt ;) Aber es ist die gängige Abkürzung für das Standardwerk Digitales Wörterbuch der deutschen Sprache, und diesen "geschwätzigen" Namen würdest du der Vorlage doch nicht verpassen wollen, oder? Vielleicht als WL, oder vielleicht ginge auch "DigWörDeuSpra"? ;) --Chiananda (Diskussion) 15:19, 30. Jun. 2019 (CEST)
Die Vorlage stammt noch aus einer Zeit, als man weniger als 100 Vorlagen und namentlich Datenbanklinks hatte; es ist eine der allerersten aus 2004. Seinerzeit hatte man noch sämtliche Vorlagen und sogar ihre Parameter auswendig gekannt.
Solange nur Germanisten mit dem Dings umgehen, verstehen die sicherlich die Bedeutung.
Nur müssen bei uns nicht nur Sprachwissenschaftler mit dem Teil hantieren, sondern der Vorlagen-Namensraum umfasst global alle Angelegenheiten aller Fachgebiete, und Autoren mit unterschiedlichem Hintergrund müssen mit Artikeln zurechtkommen, in denen solch eine Vorlage unter einem durch uns gewählten Namen auftritt.
Vorlage:DigWbDtSpr würde den Germanisten das Lesen der Großbuchstaben ermöglichen, allen anderen gäbe es einen Tipp, worum es gehen könnte und ermöglicht, sich den Sinn zusammenreimen, wenn irgendwann schon mal sowas unterkam.
Zustimmung zum letzten Vorschlag von PerfektesChaos. (Wörterbuch hätte ich mit WöBu abgekürzt; aber die Überlegung, dass mit Vorlage:DigWbDtSpr wieder die 4 Großbuchstaben erkennbar sind, ist zwingend.) Übergangsweise eine WL vom alten zum neuen Namen. Dank an Lómelinde für die Bereitschaft zur Verbesserung. JakobVoss: FYI. Danke, --Wi-luc-ky (Diskussion) 16:36, 30. Jun. 2019 (CEST)
Ich mach mir aber diese Mühe nur ungern, ich habe es schon mal bei einer anderen Vorlage gemacht und eine ordentliche Dokumentation mitgeliefert, am Ende wurde es auf ein kryptische Gekürzel verschoben und meine Hilfsbereitschaft wurde ausgenutzt. So zumindest habe ich das empfunden. (für WSCP hätte ich es wohl nicht getan) Ich meine das war auch nicht die einzige, wo ich meine Zeit sinnlos investiert hatte. Vorlagen sollen für alle zugänglich sein, nicht nur für eingeweihte.
Vielleicht als WL nein! Entweder ein sprechender Name, der dann auch so bleibt oder ohne meine Hilfe. Dieses „das ist nunmal das gängige Kürzel“ finde ich einfach nur unangebracht, nicht barrierefrei, niemand muss hier Zeichen einsparen es gibt mehrere Hilfsmittel, die das Einfügen von Vorlagen unterstützen und notfalls hat eine gute Vorlage auch eine Doku mit Kopiervorlage. Und ehrlich unter DigWbDtSpr kann ich mir (als Laie) auch noch nichts vorstellen. Wenn es jemand ordentlich verschiebt schaue ich morgen mal was geht. Aber nur wenn es nicht zurückverschoben wird. --Liebe Grüße, LómelindeDiskussion17:01, 30. Jun. 2019 (CEST)
Wenn du das Lit-Portal fragst, dann meckern auch 100 Leute, die noch niemals diese Vorlage eingesetzt hatten, aber meinen, alles solle immer so bleiben, wie es immer schon war.
Außerdem wären es dort alles Germanisten, und die wüssten alle ganz genau, was die Abkürzung bedeuten würde. Bei der Problematik geht es aber darum, dass nicht alle Bearbeiter im Wiki promovierte Germanisten wären.
Wer viel fragt, bekommt viel Antworten.
Anfrage dort bedeutet, dass du diesen Abschnitt hier eigentlich gleich als erledigt abhaken kannst.
Was allerdings passieren sollte, ist, dass die Umbenennungsabsicht sowie das eingangs geschilderte Problem auf der Vorlagendisku vorgetragen werden sollte.
Dort beobachten es nur Leute, die sich tatsächlich ernsthaft für die Vorlage interessieren.
Eine Woche Antwortzeit dort wäre ohnehin vor der allerersten Maßnahme abzuwarten.
Verschieben kann ja dann hinterher jemand von den Interessenten.
Ich habe nicht wirklich so viel Zeit lange zu warten, da ich nur noch bis zum 8. Juli online sein werde und danach für rund drei Wochen nicht erreichbar bin. Wäre schön wenn wir das noch davor verschoben bekommen, damit ich dann auch gleich die passende Dokuseite anlegen kann. Sonst vergesse ich auch wieder wie ich das umsetzen wollte. --Liebe Grüße, LómelindeDiskussion07:16, 2. Jul. 2019 (CEST)
Hallo Lómelinde, ich sehe einen Konflikt zwischen der oben vorgeschlagenen und dann gesetzten Ein-Wochen-Frist und der Urlaubsplanung. Bisher hat sich nur 1 Nutzer zustimmend zur Verschiebung geäußert, der aber ohnehin an der Disku beteiligt war. Vllt. kannst Du Dir dennoch ein paar Stichpunkte machen, wie Du das umsetzen würdest. Wenn Du die vorgezogene Verschiebung aber auf die eigene Kappe nehmen möchtest, kann und werde ich Dich nicht daran hindern. Zu bedenken wäre, dass die VL sehr oft eingebunden ist, und zu klären wäre, wie die alten Vorlageneinbindungen behandelt werden sollen. Eine Umstellung riefe viele kluge Nutzer auf den Plan, die von der Verschiebungsabsicht nichts mitbekommen haben… Gruß, --Wi-luc-ky (Diskussion) 11:53, 2. Jul. 2019 (CEST)
Nee möchte ich nicht, weil es dann keine Garantie gibt, dass es auch dort bliebe. Die 115 Einbindungen anzupassen wäre nicht so das Problem. Ich habe viel höhere Berge (>1760). :-) --Liebe Grüße, LómelindeDiskussion12:24, 2. Jul. 2019 (CEST)
Hi Lómelinde, die Vorlage macht nach dem Umzug auf einen anderen Betreiber offensichtlich nicht mehr das wofür sie mal gedacht war. --Succu (Diskussion) 20:49, 14. Jun. 2019 (CEST)
Das scheint mir auch so, was machen wir nun mit den Einbindungen? Zumal niemand, außer einer handvoll eingeweihter versteht, was genau ein LCL sein soll. Ich jedenfalls hätte Probleme zu erraten, was diese kryptische Abkürzung bedeutet. --Liebe Grüße, LómelindeDiskussion06:15, 15. Jun. 2019 (CEST)
Damit wir alle mit dem Namen der Vorlage etwas anfangen können, darf das sicher unter dem neuen Namen Vorlage:LinnaeanCorresp oder ähnlich erfolgen?
Die Nummer im bisherigen Parameter 1 ist offenbar auf eine neue (sechsstellige) Nummer alvin= umzustellen, was die Autoren dann einzeln ermitteln müssten.
Wir können mit Hinweistext und Wartungskat für die Migration helfen; vielleicht das schon ausgefüllte Suchformular zur Ermittlung der neuen Nummer als Weblink anbieten: Fahrenheit für Daniel Gabriel Fahrenheit – Daniel+Gabriel+Fahrenheit.
|Adressat= gibt es nur in James Petiver und ich habe das bislang noch nicht so ganz verstanden. Wenn das eigentliche Ziel ist, die Korrespondenz zwischen Linné und dessen Partner darzustellen, dann ist dies ein Missbrauch der Vorlage, und auch der Umstand, dass sich zufällig früher mal eine gültige URL bilden ließ, und man irgendwie auf eine Webseite gelangen könnte, rechtfertig nicht die Verwendung der Vorlage, um beliebige URL zu beliebigen Zwecken zu generieren. Das ist maximalunfreundlich verwirrend. Die Vorlage heißt nicht „Briefwechsel zwischen beliebigen X und beliebigen Y“.
Ich habe mir ehrlich gesagt den Quellcode der Vorlage gar nicht angesehen, ich wunderte mich nur über das Ziel. Und da ich das gleich zweifach bemerkte habe ich eben in der Zusammenfassung nach dem Sinn gefragt. --Liebe Grüße, LómelindeDiskussion11:08, 15. Jun. 2019 (CEST)
LCL steht für "Linnaean Correspondence Letters". Es ist einige der wenigen Vorlagen die ich vor über zehn Jahren erstellt habe. Die Vorlage verlinkte zu dieser schönen Übersicht (Beispiel). Ob sich das mit der neuen Datenstruktur wieder realisieren lässt weiß ich nicht. Der Umzug ist wohl noch nicht lange her. Gruß --Succu (Diskussion) 20:08, 15. Jun. 2019 (CEST)
Es geht nicht darum dass „LCL“ für dich verständlich für „was auch immer“ steht. Vorlagen sollen „allgemeinverständlich“ benannt und mit Parametern versehen werden, die selbsterklärende, sprechende Namen verwenden.
Du bist auch nicht auf den Beitrag von PerfektesChaos eingegangen. Bitte verschiebe die Vorlage auf ein allgemeinverständliches Lemma und überarbeite die Vorlage so, dass die Links wieder sinnvolle Angaben generieren oder eine Fehlerkategorie ausgelöst wird, damit die Angaben korrigiert werden können.
@Succu wie wollen wir da jetzt vorgehen. Ich könnte versuchen das umzubauen, wenn du mir sagst welchen Namen das bekommen sollte. Vorlage:LinnaeanCorresp, Vorlage:LinneanCorrespLetters, Vorlage:LinnéBriefe? Irgendetwas woraus man „erraten“ könnte worum es hier geht. --Liebe Grüße, LómelindeDiskussion14:48, 17. Jun. 2019 (CEST)
Es geht um die Korrespondenz zwischen Linné und einer weiteren Person. Die Abkürzung Corresp ist auch nicht unbedingt intuitiv. Vorlage:LinnaeanCorrespondenceLetters ist vmtl. für die hiesigen Vorlagenbauer zu lang. Eindeutschungen wäre vllt. Vorlage:LinnéBriefwechsel oder Vorlage:LinnéKorrespondenz. --Succu (Diskussion) 19:42, 17. Jun. 2019 (CEST)
Wir können sogar mit Vorlage:LinnéBriefw leben.
Es geht lediglich darum, dass in diversen Auflistungen und Kategorien die Namen von Vorlagen auftauchen, etwa diejenigen, die im momentanen Artikel verwendet werden, oder was Fehler auslösen würde, oder was es so alles in dem Funktionsbereich geben würde. Dann soll sich einigermaßen erahnen lassen, was für eine Funktion damit verknüpft sein könnte. LCL ist dafür zu kurz; das mag der FlagIcon von Lampukistan sein.
Ein anderer Hintergrund ist, dass gerade auch die kommende Generation über den VE Vorlagen zum Einfügen auswählt; und dort genügt linn, um eindeutig die Auswahl auf ein oder mal zwei Kandidaten einzuschränken und in diesem Angebot anzuklicken. Und das lässt sich unter heutzutage über 60.000 Vorlagen auch noch merken. Früher, vor zehn Jahren, gab es gut 100 Datenbanklinks und weniger als 100 „Bausteine“; da war die Wiki-Welt noch übersichtlicher gewesen.