Vorlage Diskussion:Vorlage

Benutzung:

{{Vorlage|Name der Vorlage}}	{{Name der Vorlage}}
{{Vorlage|Name der Vorlage|Parameter ...}}	{{Name der Vorlage|Parameter ...}}

---

Hab mit einem wild gewordenen Default Parameter hack es ermöglicht optional Parameter anzugeben. Zwar wird der Seperator zZ noch in den Linknamen integriert. Aber eine bessere Lösung fiel mir vorläufig nicht ein. --Kingruedi 00:01, 23. Feb 2006 (CET)

Hä?

Was soll das denn bringen? Dass man vor den Vorlagennamen noch mal Vorlage| schreibt? --172.178.242.34 20:43, 3. Jan. 2007 (CET)

Nein, es wird bloß ein Link auf eine Vorlage als Beispielseinbindung schöner formatiert.
hilft -- ✓ ^Bergi 17:16, 4. Dez. 2009 (CET)

Verwirrung pur

Ich bin ein waschechter Neuling, versuche mich gerade in Wiki einzuarbeiten und versuche verzweifelt zu verstehen, wie das mit den Vorlagen und WikiCodes etc. geht. Quasi eine Schritt für Schritt Anleitung. Ich klicke mich seit drei Tagen durch das Wiki und bekomme immer mehr ein Durcheinander. Mir persönlich fehlt einfach ein Vorlagen für Dummys Anleitung. --Mabba 21:46, 14. Apr. 2007 (CEST)

Hilfe:Vorlage. -- ✓ ^Bergi 17:16, 4. Dez. 2009 (CET)

<code>-Tag einfügen

Sollte man in die Vorlage noch den HTML-Tag <code> einfügen, da mit der Vorlage ja ein Quelltext-Beispiel generiert wird?

• Derzeit: {{Vorlage}}
• Mit <code>: {{Vorlage}}

Würde IMO aus semantischen Gründen mehr Sinn machen. --Kam Solusar 14:57, 13. Aug. 2008 (CEST)

Commonsvorlage

Hat jemand Lust Benutzer:Saibo/CTL (Beispiel: {{PD-Art|PD-old-100}}) in {{CVL}} oder {{Commonsvorlage}} umzubauen (dann natürlich in der Verwendung ohne subst) und evtl. mit mehr Features von der Vorlage hier auszustatten? Oder könnte diese Vorlage hier so erweitert werden, dass man auch Commonsvorlagen verlinken kann? Ich (häufig Dateibereich) brauche das recht häufig, daher habe ich mir ne eigene gebastelt. Würde aber vielleicht auch anderen Benutzern hilfreich sein. Viele Grüße --Saibo (Δ) 18:35, 30. Jul. 2011 (CEST)

Diese Vorlagen entsprechend zu erweitern sehe ich schwierig, da ja auch Parameter unterstützt werden. Da eine Abgrenzung zu schaffen zwischen "darzustellenden Parameter" und "Parameter des Wiki-Projektes" würde schwierig. Da lieber "Commonsvorlage" nehmen. --Quedel 18:22, 8. Nov. 2011 (CET)

Wenn ich mir das so überlege, müsste es eigentlich doch auch mit dieser Vorlage gehen. Benannte Parameter können ja, wenn ich es richtig verstehe nicht als "darzustellender Parameter" genommen werden. Beispiel: {{Vorlage|Benutzer:Saibo/CTL|subst=ja|Vorlagename|Parameter1|...}} → {{subst:Benutzer:Saibo/CTL|Vorlagename|Parameter1|...}} Also könnte mit {{Vorlage|iw=commons|own}} ja nach Commons verlinkt werden. wenn man es es so macht, dann auch mit {{Vorlage|iw=en|own}} nach en.wikipedia. Nur: man müsste noch eine "Weiterleitungsvorlage" bauen, denn so ist das wirklich kein Spaß zu schreiben... ;) Ist die Frage was sinnvoller ist. Um die eh schon kompliziert zu durchschauende Vorlage nicht noch komplizieter zu machen vllt. wirklich lieber ne eigene. Und in andere Wikis außer Commons wird man wohl nur selten verlinken wollen. Viele Grüße --Saibo (Δ) 19:09, 8. Nov. 2011 (CET)

Na wenn wir schon eine Interwiki-Vorlagen-Vorlage machen, dann aber bitte gleich als Interwiki und nicht als reine Commons-Vorlage. Also {{Interwikivorlage|Parameter}}. Oder doch "IW-Vorlage"? --Quedel 19:34, 8. Nov. 2011 (CET)

Nu hast du mich falsch verstanden. Ich überlegte die Vorlage:Vorlage so umzubauen, dass sie auch für Vorlagen in anderen Wikis verwendet werden kann. Da ich keine Lust auf rumbauen habe, handle ich nun einfach mal nach KISS und habe meinen Entwurf nach {{Commonsvorlage}} verschoben. Weiterleitung: {{CVL}}. Wenn man was umbauen will, kann man das ja dann immer noch machen. Viele Grüße --Saibo (Δ) 21:09, 8. Nov. 2011 (CET)

Frage zu Quelltext für Vorlagenparametern

Was genau macht eigentlich die Abfrage {{#ifeq:{{{2|x}}}|{{{2}}}||{{{2}}}}} für die Vorlagenparameter? Würde ein einfaches {{#if:{{{2|}}}||{{{2}}}}} hier nicht genügen? --Patrick87 (Diskussion) 14:14, 3. Mai 2013 (CEST)

Habe mir die Frage selbst beantwortet, der Code ermöglicht es auch leere Parameter anzugeben (wozu auch immer man das braucht), z.B. {{Vorlage|eins||drei}}. --Patrick87 (Diskussion) 20:26, 7. Mai 2013 (CEST)

Code Hervorhebung entfernt

Da neuerlich diese über 5 Jahre bestandene (und das Pendant in der EN über eine 1 Mill. Mal eingebundene) mir nichts dir nichts mit einer scheinbar subjektiven Begründung entfernt wurde (also ohne den Anschein eines Konsens zu geben, die Begründung ist trotzdem halbwegs nachvollziehbar), möchte ich hiermit Gelegenheit zur Diskussion geben. Vorschlag wäre die Vorlage wie in EN zu splitten. Über einen Parameter bin ich mir nicht sicher, evtl. ein Redirect mit Paramter. ↔ User: Perhelion 21:11, 6. Dez. 2014 (CET)

• Ich kann dir geistig leider nicht folgen.
• Korrekt ist hier die Verwendung des <tt>, nachdem <code> vor einer Weile weltweit andere Eigenschaften erhielt.
  • Das ist auch mitnichten ein „Hack“, wie bereits an anderer Stelle erläutert.
• Was konkret wäre mit „splitten“ gemeint?
• Ich bin gegen jede nicht zwingend erforderliche Veränderung an der Funktionalität dieser seit acht Jahren vielfach eingesetzten Vorlage.

VG --PerfektesChaos 21:23, 6. Dez. 2014 (CET)

Wir haben hier zwei Probleme:

1. Den visuellen Stil des <code> Tags. Dieses wurde vor einiger mit einer Umrandung ergänzt, welche nicht jedem gefällt. In der Vorlage macht dieses Tag syntaktisch absolut Sinn (wir zeigen wie der Wikitext, also Code, auszusehen hat). <tt> wird hingegen in HTML5 nicht offiziell unterstützt (und ist damit sehr wohl ein Hack) und sollte deshalb nicht verwendet werden. Wenn also der Stil des <code> Tags einigen hier nicht als tragbar erscheint, dann sollte dieser optimiert werden, statt die Vorlage mit einem veralteten Tag zu modifizieren welches (zumindest noch) den gewünschten Stil aufweist, sich jedoch auch jederzeit ändern könnte.
2. Den visuellen Stil der Vorlage: Meiner Meinung nach sollte sich diese einfach an den globalen Standard halten (d.h. den des <code> Tags). Das ergibt im Endeffekt das konsistenteste Gesamtbild und den einfachsten Vorlagen-Code. Mehrere verschiedene Vorlagen mit minimal angepasstem Stil machen in meinen Augen keinen Sinn solange die Funktionalität die gleiche bleibt.

--Patrick87 (Diskussion) 22:46, 6. Dez. 2014 (CET)

Das ist so in etwa auch meine Meinung (und das obwohl ich weiß das Patrick an anderer Stelle sich generell gegen farbliche Textänderungen ausgesprochen hat. Allerdings wollte ich hier wie gesagt vordergründig meine Bedenken zur Änderung der Vorlage festhalten und zur Diskussion bringen).

@PC: Hm* die @Änderung wurde ja "eigtl." jetzt herbeigeführt.

@Splitten würde entweder Kopie oder zusätzliches IF heißen. Aber wenn du meinst dass eine farbliche Unterlegung sinnlos sei oder/bzw. eine Template-Syntax kein Code ist, dann überlasse ich gerne anderen ihre Meinung hier. Sich auf eine Vorlage zu beschränken halte ich nicht mehr für zeitgemäß (vgl. EN mit gefühlten 20 für das Gleiche).

@Hilfe:Tags#code Wie ist hier dieser Satz genau zu verstehen: "Zurzeit wird der code-Bereich auf weißem Hintergrund dargestellt. Das ist normalerweise nicht zu bemerken und wird wohl eines Tages entfallen; geht auch noch auf frühere Einsatzzwecke zurück."

Genau genommen ist er ja zurzeit Hellgrau oder ist hier gemeint dass er noch dunkler wird?

@Zum Argument von Boshomi: "Das stört den Textfluss": IMO fällt genau das jetzt seltsam auf wenn nur die Schrift auf Monospace steht. Ohne zusätzliche Kenntlichmachung sieht das einfach blöd aus. Das ist auch mein Hauptargument gegen die Änderung.

VG ↔ User: Perhelion 23:19, 6. Dez. 2014 (CET)

<einschub>

@Perhelion: Mit einer brauchbaren Monospace Schrift (z.B. die unter freier Lizenz stehende SourceCodePro von Adobe) stört ein Umschalten von Proportionalschrift auf Monospace nicht sonderlich. Der Unterschied ist gerade so, dass dieser wie etwas kursiv gut wahrnehmbar ist, aber nicht gröber ablenkt. Frohes Schaffen — Boshomi ☕⌨☺  14:01, 7. Dez. 2014 (CET)

• Ich habe dem immer noch nicht entnehmen könne, welche optische Darstellung jetzt eigentlich gewünscht oder nicht erwünscht ist. Vielleicht machen die Herrschaften mal konkrete Mock-ups auf und stellen dar, wann welche Präsentation ihnen gefällt und was in welcher Schrift mit welchem Rahmen wo herum erscheinen soll oder auch nicht.
• Was den Satz unter Hilfe:Tags #code angeht, so bezieht er sich auf einen merkwürdigen Schlingerkurs der MediaWiki-Designer. Welche optische Präsentation sich da über die Jahre ergeben wird, ist schwer vorherzusagen. Zwei oder drei Leutchen ändern das mal so eben auf Zuruf weltweit.
• Was <tt> angeht, so gibt es hier mal wieder ein verbreitetes Missverständnis: Unsere Artikel werden in Wikitext geschrieben, nicht in HTML5. Was in HTML5 drinsteht, das interessiert eine Handvoll Software-Entwickler bei MediaWiki und nicht unsere Autoren. Hier bei uns weiß vielleicht ein Dutzend Nerds, was in HTML5 drinsteht; Tausende von Autoren wissen es nicht, und es muss sie auch noch eine ganze Weile absolut nicht interessieren. Ob <tt> in HTML5 drin vorkommt oder nicht, ist völlig Banane, weil zwischen dem Wikitext unserer Seiten und dem zum Browser ausgelieferten HTML-Dokument zurzeit noch zwei Software-Instanzen leigen, künftig auch mehr. Sollten wir in einigen Jahrzehnten mal ein Problem damit haben, dass der erste Browser <tt> nicht mehr verstehen würde, dann können wir das jederzeit zum Wiki-Tag erklären und die Server-Software setzt es auf ein geeignet attribuiertes <span> um.
• Also, #F9F9F9 zählt bei mir noch zu den Weißtönen, die ja von Reinweiß über Altweiß bis Perlweiß gehen. Hellgrau ist bei mir bei 249 noch nicht angesagt.

VG --PerfektesChaos 23:39, 6. Dez. 2014 (CET)

In er Tat, ich schlage daher vor wir hinterlegen hier das tt einfach mit Weiß (Perlweiß - das sollte auch so unmissverständlich bei den tags genannt werden die CSS Farbe GhostWhite kommt hier am Nähesten) mittels CSS (dabei fällt jetzt zusätzlich auf das <code> auch noch ein schöneres padding hat, mit Rahmen 5px, folgend Mock-ups):

1. Text {{Vorlage Beispiel}} Vorlage Beispiel – momentan (<tt>)
2. Text {{Vorlagen Beispiel}} soll es sein – +leichtem Hintergrund, seltsam fällt hier auf dass nachfolgendes schmaler ist mit Rahmen⁈? (gleich in FF & Chrome)
3. Text {{Vorlage Beispiel}} soll es sein – + leichterem Rahmen
4. Text {{Vorlage Beispiel}} soll es sein – wie vorher (<code> mit Rahmen)
5. Text {{Vorlage Beispiel}} soll es sein – +Schrift ein My kleiner – Mit der Schriftgröße kann ich mich auch getäuscht haben, da eh stark Client abhängig

Als Kompromiss könnte ich mich für 2. entscheiden. ↔ User: Perhelion 00:56, 7. Dez. 2014 (CET)

• Das Ziel der ganzen Übung wurde mir immer noch nicht deutlich. Könnte jemand mal klar und einfach formulieren, was überhaupt erreicht werden soll?
• Es gibt die .mw-code – die bildet gerade die <code> ab: Vorlage:Vorlage mit größerem Rahmen.
• Für mich sehen die Beispiele praktisch alle gleich aus; nur bei #4 sehe ich einen Rahmen.
• Bei einer Variante mit Rahmen ist der Zeilenumbruch zu bedenken. Das sieht immer doof aus.
• Ich wäre für KISS – keep it simple and stupid; deshalb #1 und fertig.

VG --PerfektesChaos 01:34, 7. Dez. 2014 (CET)

Mal ganz abseits vom schlussendlich tatsächlich angezeigten Stil: <tt> ist veraltet und jegliche Diskussion das als "Wikicode" implementieren zu wollen halte ich für Unsinn. Wikicode ist bereits kompliziert genug für den "Laien", da ist ein einzelnes Tag für Code fast schon zu viel. Das es ganz ohne aber nicht geht, sollten wir uns für eine Variante entscheiden. Oben verwendet ihr beide fleißig <code> (und die Mehrheit der Autoren inklusive mir macht das genauso) deshalb bin ich der Meinung, dass wir das getrost zum Standard erklären können.
Die Verwendung des nicht standardkonformen <tt> macht damit nur alles unnötig kompliziert (selbst wenn es derzeit noch funktioniert). Nicht zuletzt führen wir damit auch eine unnötige Inkonsistenz ein, denn alle sonst üblichen Tags zur Codeformatierung ("code", "pre" und "pre" eingeleitet durch ein Leerzeichen) besitzen derzeit einen einheitlichen Style.
Alles in allem denke ich, dass Boshomi vor allem die neu eingefügte Umrandung stört, und die wurde (wie PC schon schreibt) von ein paar wenigen ohne vorige Absprache eingeführt. Wenn diese uns also wirklich stört (nach anfänglichem Zähneknirschen stört sie mich persönlich z.B. gar nicht mehr, nachdem ich mich daran gewöhnt habe – im Gegenteil, sie hebt Codepassagen wirkungsvoll hervor), sollte das Problem an der entsprechenden Stelle (MediaWiki Software) angegangen werden, statt es hier durch andere "Tricks" umgehen zu wollen. Damit sparen wir uns dann auch direkt diese ganze Diskussion hier und insbesondere eine Haufen Arbeit (wenn nämlich plötzlich jede Vorlage anders aussehen soll, als es die MediaWiki-Software standardmäßig vorsieht, dann verzetteln wir uns nur mit einem Haufen unnötiger Style-Angaben). --Patrick87 (Diskussion) 04:28, 7. Dez. 2014 (CET)

Dieser Edit ist ein POV-begründeter, und wegen der vielen Einbindungen und bisher langen unveränderten Verwendung auch eigenmächtiger Eingriff, welcher auf jeden Fall vorher hätte abgesprochen werden müssen. Ich bin absolut dagegen, hier aus subjektiven Gründen einfach zu ändern. Ich verlange schlichtweg ein Revert aus folgenden Gründen:

1. Die Änderung ist POV und andere User mögen den Rahmen gutheißen
2. Kein Einfügen irgendwelcher CSS-Attribute. Diese Überschreiben i.d.R. die User-CSS, wenn diese nicht angepasst wird. Die Definition einer CSS-Klasse für diese Vorlage (z. B. "vorlagevorlage") wäre aber vertretbar.
3. Boshomi weis genau, wie man mit der eigenen CSS umgeht. Wenn ihm der Rahmen nicht passt, soll er ihn in seiner CSS-Datei abschalten.

ÅñŧóñŜûŝî (Ð) 10:33, 7. Dez. 2014 (CET)

@Antonsusi:

• Dem schließe ich mich zumindest soweit an, dass es fatal wäre, an den tags irgendwelche individuellen Attribute anzubringen; es sollte nackt und ohne Attribute benutzt werden.
• Grund: Das tag kann in ein paar Monaten von MediaWiki mit anderen Stilen ausgestattet werden, oder nächste Woche durch die deutschsprachige Wikipedia, und heute schon durch Benutzer. Wenn dann bei jeder Verwendung ein Rattenschwanz individueller Formatierungen angebaut wird, dann müssen nach einigen Jahren alle Vorkommen irgendwie uneinheitlich aussehen.
• Ob Rahmen oder nicht, sehe ich leidenschaftslos, benötige ihn insbesondere wegen Zeilenumbruch nicht so sonderlich. Umgekehrt ist es eine Code-Sequenz in Wikisyntax, <code> ist berechtigt. Hauptsache keine Attribute.

@Patrick87:

• Von dir ganz persönlich hätte ich gern mal folgende Frage beantwortet bekommen: Wenn auf einer unserer Seiten ein <pre> steht – ist das ein HTML-Element oder Wikisyntax?

VG --PerfektesChaos 11:13, 7. Dez. 2014 (CET)

• Die Ausgabe der Vorlage wurde durch eine Softwareänderung verändert, und damit das Aussehen vieler tausend Seiten, inlusive dieser selbst: Der Beitrag von Kam Solusar aus dem Jahr 2008 ist inzwischen sinnentstellt. Er wollte damals einfach nur ein Monospace-Font in der Darstellung, anstatt der Standard-Proportionalschrift.
• Wäre schön, wenn mal geklärt würde, wo ein Rahmen innerhalb eines Fließtextes Sinn macht.
  • Meine Meinung: Eine derart auffällige Hervorhebung wie dies derzeit mit dem code-Tag der Fall ist, wirkt wie eine Eyecatcher, wodurch der eigentliche Inhalt des Satzes gegenüber der Darstellung in den Hintergrund gedrückt wird.
  • Falls ein Rahmen im Fließtext nützlich sein sollte, dann sollen auch die Darstellungsprobleme etwa bei Zeilenumbruch gefixt werden. Das sieht häufig recht hässlich aus, insbesondere bei manchen mobilen Browsern.
• Über eine dezente Hintergrundfarbe kann man sich ebenfalls Gedanken machen, sollte aber bedenken, dass diese von manchen Menschen gar nicht wahr genommen werden kann. Wenn es aber der großen Mehrheit nützt, dann ist das eine Abwägungssache. Diesem Punkt stehe ich neutral gegenüber. Frohes Schaffen — Boshomi ☕⌨☺  14:01, 7. Dez. 2014 (CET)

  @Boshomi „sinnentstellt“: das ist die Frage, das war IMHO der wesentliche Sinn der Vorlage, eine Hervorhebung. Ehrlich gesagt erkenne ich keine Software-Änderung. Denn wenn man keine Hervorhebung möchte kann immer noch (damals wie heute) ganz einfach (ohne extra Vorlage jedoch mit ein paar extra Klammern) eine {{[[Vorlage:Beispiel|]]}} {{Beispiel}} schöner verlinken. PS: Dies soll dann auch mein letzter Einwurf hier gewesen sein, ich persönlich kann auch ohne Hinterlegung leben. ↔ User: Perhelion  15:54, 13. Dez. 2014 (CET)

@Boshomi: Aus dem D-Verlauf ergibt sich eine Mehrheit und die bessseren Argumente gegen deine Änderung. Ich bitte dich daher, deinen Eingriff zurückzusetzen und dein Problem mit dem Aussehen in deiner CSS-Datei zu fixieren (frage, wenn du doch nicht weist, wie). ÅñŧóñŜûŝî (Ð) 19:37, 16. Dez. 2014 (CET)

@Antonsusi: Nö, das sehe ich nicht so. Siehe etwa das Tag <syntaxhighlight lang="text"> Hier funktioniert die für den Fließtext vorgesehene Variante enclose="none" sehr wohl ohne Rahmen und Hintergrundfarbe. Auf Wunsch ist eineHintergrundfarbe möglich, führt aber zu einem Zeilenumbruch. enclose="none" wird in diesem Fall unwirksam. Insgesamt eine durchaus sinnvolle Konstruktion.

Eine Hintergrundfarbe und ein Rahmen zusätzlich zu einer Monospace-Schrift ist innerhalb von Fließtext einfach viel zu viel, und lenkt allzuhäufig vom tatsächlichen Inhalt der Aussagen in den Sätzen ab.  Frohes Schaffen — Boshomi ☕⌨☺  21:18, 18. Dez. 2014 (CET)

Vielleicht zur Abwechslung mal ein paar Fakten, weil weiter oben ausgiebig mit falschen Argumenten gearbeitet wurde:

1. Das <code>-Element hatte im Monobook-Skin am 5. September 2004 die Hintergrundfarbe #f9f9f9 (Beleg, Direktlink), möglicherweise sogar schon vorher (habe ich nicht nachgeschaut). Daher ist es eine völlig falsche Aussage, dass die farbliche Hervorhebung in irgendeiner Weise neu sei.
2. Diese Formatierung wurde später aus Monobook 1:1 nach Vector kopiert (Beleg kann ich auf Anfrage heraussuchen, ist mir momentan zu viel Arbeit).
3. Diese Formatierung bestand 10 Jahre lang und wurde am 22. Juli 2014 um einen Rahmen ergänzt (Beleg). Als Begründung wurde eine größere Konsistenz mit der Formatierung von <pre>-Elementen angegeben.
4. Seither ist die <code>-Formatierung unverändert. Daher ist die obige Behauptung eines „merkwürdigen Schlingerkurses der MediaWiki-Designer“ vollkommen absurd, sondern es gab in 12 Jahren genau eine konsistente Änderung.

Und nun meine persönliche Meinung:

1. Ich bin genau entgegengesetzter Meinung zu einigen anderen, was das Thema Semantik angeht: Meiner Meinung nach sollten Wikipedianer in erster Linie semantisch sinnvollen Text schreiben, also die semantisch passenden Elemente verwenden, und sich nur sehr wenig dafür interessieren, wie dieses gerade aussieht.
2. Selbstverständlich ist für diese Vorlage das <code>-Element semantisch korrekt, während <tt> vollkommen falsch ist.
3. Ich bin explizit nicht an einem bestimmten Aussehen der Vorlage interessiert (also weder für noch gegen die Formatierung mit Hintergrund und Rahmen), sondern wünsche das semantisch korrekte Tag und dessen standardmäßiges Aussehen, wie auch immer dieses gerade sein mag.

Gruß --Entlinkt (Diskussion) 00:59, 20. Mai 2016 (CEST)

Zusammenhalten der Pipe mit dem Parameter bei dynamischen Seitenumbruch

@PerfektesChaos: hast du einen alternativen Vorschlag wie man erreichen könnte, dass die Pipe zusammen mit dem Parameter umgebrochen wird. Dass die Pipe bei dynamischen Zeilenumbruch rechts stehen bleibt ist im Kontext dieser Vorlage nicht unbedingt erwünscht. Frohes Schaffen — Boshomi ⌨   18:01, 28. Mai 2016 (CEST)

Erstmal würde mich ein sinnvoller Anwendungsfall interessieren.

• Ich war schon mit Tausenden von Vorlagenprogrammierungen und Dokus zugange, und mir ist diese Notwendigkeit noch nie aufgefallen.
• Wahrscheinlich ist die umseitige Vorlage über ihren sinnvollen Bereich hinaus eingesetzt worden.

Und: Ja, Leser der Hilfeseite über Tags wüssten Bescheid, auch wenn das hier kein asiatisches Gericht ist.

VG --PerfektesChaos 18:04, 28. Mai 2016 (CEST)

Der Anwendungsfall ist dort wo die Vorlage in Tabellen verwendet wird. Wenn die Pipe an der mit dem Parameter zusammen gehalten werden, sind dort die Zeilenumbrüche etwas vernünftiger. Bei Verwendung vieler Parameter nimmt die Spalte dann auch deutlich weniger Platz ein. mit dem wbr-tag wird aber auch das Gleiche erreicht, wie mit den unsichtbaren utf-Zeichen.  Frohes Schaffen — Boshomi ⌨   18:42, 28. Mai 2016 (CEST)

Ich weiß nichts von einem sinnvollen Anwendungsfall in Tabellen.

• Es ist unklug, das in Tabellenspalten zu quetschen; die umseitige Doku ist auch nicht grad ein leuchtendes Beispiel für eine Syntaxdemo.

Ich hoffe, du hast dich hinsichtlich des wbr-Tags lediglich unpräzise ausgedrückt: Es würde mitnichten das Gleiche passieren. Analog wäre nur die gewünschte Stelle des Zeilenumbruchs. Bei deiner Lösung klebt allerdings am Namen der Vorlage hintendran ein unsichtbares ‌, und das ist legitimes Zeichen jedes Seiten- und Vorlagennamens. Und das bedeutet, dass es jemand, der sich mit C&P dein supertolles Beispiel kopiert, unsichtbar am Namen der Vorlage dranklebt. Und das heißt, dass es eine derartige Vorlage nicht gibt. Und dabei sieht der Quellcode in der Seite haargenau so aus wie in deinem schlauen Demonstrationsbeispiel.

Mir war der Zusammenhang binnen fünf Sekunden klar, und meine Augäpfel standen jenseits der Nase und wurden nur noch vom auf je zehn Zentimeter Länge gedehnten Sehnerv gehalten.

Lass deine Tabellenspalten bleiben und nimm eine neue, zusammenhängende Zeile in voller Breite für ein Code-Beispiel, und quetsch das nicht so bescheuert wie umseitig zusmmen. Keine richtige Vorlagendoku macht solch einen Schwachsinn. Wenn du auf die Vorlage verlinken willst, dann einmal richtig als Überschrift.

VG --PerfektesChaos 19:54, 28. Mai 2016 (CEST)

Dass derartige Zeichen legitime Zeichen von Vorlagen und Steitennamen sind ist eigentlich ein Bug, auch wenn es im gesamten dewiki exakt eine einzige sinnvolle Verwendung gibt (WP:Verlinken). Der Hintergrund der Änderung war gar nicht die Vorlage selbst, sondern ein Beispiel für seltsame Syntax-Gestaltung, wo bei einer Vorlage jeweils hinter der Pipe ein manueller Zeilenumbruch folgte. Damit war die Lesbarkeit des Quelltextes schon mal deutlich eingeschränkt. Frohes Schaffen — Boshomi ⌨   20:13, 28. Mai 2016 (CEST)

Es ist kein Bug, auch wenn du immer wolkige Ausflüchte parat hast, um dich rauszureden und regelmäßig versuchst deine Fehler allen anderen und irgendwelcher böser Software zuzuschieben.

Die Zeichen, die du naiv ausgestreut hattest, gehören in asiatische Sprachen und nirgendwohin sonst.

In asiatischen Sprachen wirken sie bedeutungsunterscheidend; zwei Wörter mit den gleichen sichtbaren Schriftzeichen aber unterschiedlichen unsichtbaren Zeichen haben unterschiedliche Bedeutung, sind unterschiedliche Wörter, und werden resultierend auch optisch anders dargestellt.

Weil es unterschiedliche Wörter sind, würden sie auch in unterschiedlichen Artikeln im Wiki dargestellt, und bilden deshalb selbstverständlich auch unterschiedliche Seitennamen.

Ich wäre dir sehr verbunden, wenn du dich zukünftig ausschließlich mit Angelegenheiten beschäftigen würdest, von denen du auch was verstehst, und deine unsubstantiierten Stammtischphilosophien somit auch nicht mehr zur Verdeckung deines Gemurkses herhalten müssen. Du kostest seit geraumer Zeit reichlich viel Kraft und Nerven.

VG --PerfektesChaos 21:22, 28. Mai 2016 (CEST)

Was ist denn hier los?!? Reiß dich mal am Riemen, so geht man noch nicht mal mit Vandalen um... Einem langjährigen Benutzer wie dir sollte man nicht die WP:Wikiquette verlinken müssen. --Patrick87 (Diskussion) 23:53, 28. Mai 2016 (CEST)