Hilfe Diskussion:Variablen/Archiv/1

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

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

[[Hilfe Diskussion:Variablen/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Variablen/Archiv/1#Thema_1

Fragen

• Gibt's auch Zeitzone und Monats-Kurzname, statt nur eine Langform Dezember ({{CURRENTMONTHNAME}}) -- Traut 17:21, 15. Nov 2004 (CET)

Soweit ich weiß: nein. --DaB. 23:50, 6. Mai 2005 (CEST)

monatsabkürzung geht mit CURRENTMONTHABBREV :) 23.144.186.42 18:36, 17. Jul 2005 (CEST)

• Wieso gibt's eigentlich nicht sowas wie {{USERNAME}}? Bei Hinweisen auf css- oder js-Dateien des Benutzers könnte man die Links automatisieren, derzeit muss man recht plump z.B. [http://de.wikipedia.org/wiki/Benutzer:BENUTZERNAME/monobook.js] "verlinken", statt mit [[Benutzer:{{USERNAME}}/monobook.js]] einen direkten Link setzen zu können. --Das emm 19:20, 1. Feb 2006 (CET)

Wozu? Es funktioniert doch ganz normal über [[Benutzer:BENUTZERNAME/monobook.js]], wie es auf meiner Benutzerseite auch unter "Wichtige Seiten" verlinkt ist. Oder habe ich da etwas falsch verstanden? --CyRoXX ^(?) 22:41, 6. Apr 2006 (CEST)

• Funktionsweise Variable: {{NUMBEROFARTICLES}} geht nicht? Ich verwende auf meinem eigenen privaten Wiki auf der Startseite die Variable {{NUMBEROFARTICLES}}. Aber: Die Anzahl aller Artikel unter "Specials:Allpages" ist immer viel höher als die Anzahl, die mir die Variable ausgibt. Mache ich neue Artikel, werden die nicht mitgezählt, verflixt, wieso? Grüße --Captaincrunch 10:25, 2. Mär 2006 (CET)

Mitgezählt werden nur Artikel, die bestimmte Kriterien erfüllen. Die genauen Bedingungen kann ich dir leider nicht sagen, es gab immer mal wieder auf WP:FZW ähnliche Fragen, aber dort kam immer nur stückweise eine Antwort zusammen und bei den ganzen Korrekturen der jeweiligen vorherigen Poster wird es schwierig, sich dran zu erinnern und das Ganze hier wiederzugeben. --CyRoXX ^(?) 17:31, 28. Mär 2006 (CEST)

• Gibt oder kann man irgendwie mit Variablen die Anzahl der eigenen bearbeiteten Artikel anzeigen oder so? --Spam 02:15, 27. Aug 2006 (CEST)

nein, es sei denn du verwendest eine Benutzerunterseite dazu, z.B. {{:Benutzer:Spam/editcounter}}, die du aber manuell auf einem halbwegs aktuellen Stand halten musst. --BLueFiSH ✉ (Klick mich!) 02:22, 27. Aug 2006 (CEST)

Thanks, das hier meinte ich und danke für die rasche Antwort. --Spam 03:04, 27. Aug 2006 (CEST)

_NOEDITSECTION_

Ist die Variable __NOEDITSECTION__ nicht sparsam zu verwenden!? Ich finde sie öfters in den Hilfe-Seiten und ich frage mich ob es nur eine Layout-Frage ist?

Anzeige dieser Seite

Sieht bei mir mit Seamonkey unter "Classic" sehr unschön aus, Mit IE6 geht's etwas besser, aber es bleibt eine Lücke links neben der Navigation, ehe die Tabelle anfängt. XHTML ist valide, aber ... Kümmert sich mal ein Tabellenspezialist? Danke schon mal, -- RainerBi - ✉ - ± 18:44, 6. Apr 2006 (CEST)

Ohje - ich glaube nicht, dass man da viel machen kann. Mach mal bitte reload und sag, ob es ein bißchen besser geworden ist. --Elian Φ 19:03, 6. Apr 2006 (CEST)

Leider nicht, deine Änderung hat gegenüber meiner (die ich nach dem Screenshot durchführte) keine Veränderung gebracht, die Tabelle ragt mit Seamonkey immer noch in die Navigation hinein. -- RainerBi - ✉ - ± 19:47, 6. Apr 2006 (CEST)

Ich denke es liegt daran das bei Dir die Kategorie nach oben gerutscht ist!? Probiere mal überall eine Leerzeile einzufügen. Sieht die Vorschau auch so aus? -- Ολλίμίνατορέ ^•Ω• 20:12, 6. Apr 2006 (CEST)

Feature Request

Ich habe hier einen Feature Request bezüglich der Anzeige von MEZ/MESZ mithilfe einer Variablen gestellt. Wer vom jetzigen Zustand auch genervt ist, möge diesen unterstützen. --schizoschaf 19:30, 22. Apr 2006 (CEST)

NOGALLERY - wofür?

was macht die neue Variable __NOGALLERY__? Wurde im Wikizine #31 erwähnt, aber nicht wofür das gut ist. Eine Gallery im Artikel unterdrückt es zumindest nicht - macht ja auch nicht viel Sinn, die kann man ja auch gleich so rausnehmen. --BLueFiSH ✉ (Klick mich!) 08:12, 1. Jul 2006 (CEST)

Gute Frage, ist auch an mir vorbeigegangen. In den Release-Notes zu MediaWiki wird sie auch nicht erwähnt. Werde ich Anfang der Woche mal auf Forschungsreise gehen :) --Raymond ^Disk. 08:55, 1. Jul 2006 (CEST)

Habs herausgefunden ;-) Basiert auf Bug 6031. Die Variable unterdrückt die Bilderdarstellung in Kategorien (siehe Test in RoRo). Funktioniert allerdings nicht in der Vorschau, das Ergebnis - die Darstellung der Dateiname in Listenform - sieht man erst beim Speichern der Kategorie. Unter Umständen eine nützliche Funktion, damit in einer Kategorie "URV" die Bilder nicht angezeigt werden. --Raymond ^Disk. 17:46, 5. Jul 2006 (CEST)

Fehlende Variable?

Gibt es eine (evtl. undokumentierte) Variable, die zu einer Unter-Unterseite immer den Namen der Seite der obersten Ebene liefert, also z.B. zu "Benutzer:FritzG/Test/ABC" den Wert "FritzG"? Diese Variable hat mir beim Erstellen der Vorlage:Baustelle gefehlt. --Fritz @ 12:08, 5. Jul 2006 (CEST)

Probiers mal mit {{BASEPAGENAME}}, das sollte das eigentlich bringen. --BLueFiSH ✉ (Klick mich!) 12:12, 5. Jul 2006 (CEST)

Dachte ich auch erst, aber die Variable geht nur eine Ebene höher, siehe Benutzer:FritzG/Test/Untertest. --Fritz @ 12:14, 5. Jul 2006 (CEST)

Ist mir auch nicht bekannt. Werde dazu mal eine Bugmeldung aufmachen. --Raymond ^Disk. 17:55, 5. Jul 2006 (CEST)

Wurde schon mit Bug 6067 bemängelt und von den Devs abgewiesen. Unter-Unter-Verzeichnissen sind „Pfui“... --Raymond ^Disk. 18:14, 5. Jul 2006 (CEST)

Ah ja, danke. Gut daß ich selbst keine verwende! *g* --Fritz @ 18:41, 5. Jul 2006 (CEST)

Um nochmal an der Stelle nachzuhaken: Wie siehts mit Unter-Verzeichnissen aus? Ich bräuchte von z.b. "Benutzer:BLueFiSH.as/Test" nur das Test. Scheinbar bringt das keine der angegebenen Variablen, oder? --BLueFiSH ✉ (Langeweile?) 12:52, 7. Dez. 2006 (CET)

{{REVISIONID}}

{{REVISIONID}} versteh ich nicht ganz.

Stimmt die Gruppe "Generelle, konstante Variablen" oder die Funktion "Nummer einer spezifischen Seitenversion,"?

-- MichaelFrey 17:40, 12. Jul 2006 (CEST)

Gewissermaßen stimmt beides... eine einmal vergebene REVISIONID ist konstant für die jeweilige Artikelversion. Insgesamt handelt es sich jedoch um einen Zähler, der pro Speichervorgang (Artikel, Diskussion, Bilder usw. usf.) ums 1 hochgezählt wird, so dass jede Version ihre indivuelle ID erhält. --Raymond ^Disk. 17:57, 12. Jul 2006 (CEST)

Danke für die schnelle Antwort :-)

Dann gehört es doch zu Seitenabhängige Variablen?

-- MichaelFrey 18:06, 12. Jul 2006 (CEST)

Hmmm ja... gute Frage. Vielleicht auch eher zu den „Zählern“? Sehr ambivalent (schönes Fremdwort, nicht?)... Andere Kommentare/Meinungen noch? --Raymond ^Disk. 18:25, 12. Jul 2006 (CEST)

{{CURRENTMONTHNAMEGEN}}

Die Variable liefert im Moment <august-gen>. Sie sollte eigentlich "Monatsname im Genitiv" liefern (wäre das "des Augusts"?). --Blaubahn 14:07, 3. Aug 2006 (CEST)

Wurde bereits als Bug 6911 gemeldet. Abwarten und Tee trinken... --Raymond ^Disk. 18:15, 3. Aug 2006 (CEST)

Für's Protokoll: Fehler ist mittlerweile behoben. --Raymond ^Disk. 18:57, 23. Aug 2006 (CEST)

{{CURRENTMINUTE}}

CURRENTMINUTE wurde der Tabelle entfernt. Für mich schien die Variable zu funktionieren, obwohl ihre Einführung nirgends dokumentiert schien. Bin leicht verwirrt... --Raymond ^Disk. 07:13, 23. Aug 2006 (CEST)

Siehe Vorlage:CURRENTMINUTE, bitte auch im aufschlussreichen Editmodus betrachten :-) Wer basteln mag, ist mit der aktuellen Version von Template:CURRENTMINUTE gut bedient. --:Bdk: 14:53, 23. Aug 2006 (CEST)

Auauaua... das tut weh.. ich meine das ich da nicht drauf gekommen bin. Zu CURRENTMINUTE gibt es übrigens den Bug 5733. --Raymond ^Disk. 18:38, 23. Aug 2006 (CEST)

Der Bug wird wohl nicht weiter verfolgt. Die Vorlage ist inzwischen erheblich kürzer, indem die neue #time:-Funktion verwendet wird. --CyRoXX ^(? ±) 16:12, 27. Aug 2006 (CEST)

Ist diese überhaupt noch sinnvoll? -- Ολλίμίνατορέ 19:22, 27. Aug 2006 (CEST)

Ändern der Link-Ersetzung für RFCs

Derzeit werden RFCs verlinkt nach einem Muster, dass aus "RFC 989" ein Link http://www.ietf.org/rfc/rfc989 wird. Bei der IETF finden sich neben den Text-Links aber auch via Hyperlinks navigierbare Versionen der RFCs, verfügbar unter http://tools.ietf.org/html/rfc989. Auf dieser Seite findet sich auch ein Link zu der Plain-Text-Version des Dokumentes für diejenigen, die es brauchen. Die englische Wikipedia benutzt diese Links und ich würde diese Änderung auch für uns vorschlagen. -- R. Buchholz 13:52, 6. Nov. 2006 (CET)

Interessant, gefällt mir. Um dies aber zu ändern, muss die Software angepasst werden. Sollte es in den nächsten Tagen keine abweichenden Meinungen dazu geben, werde ich einen Bug dazu aufmachen. --Raymond ^{Disk. Bew.} 21:24, 6. Nov. 2006 (CET)

Gute Anregung. Hab' mal Rfcurl entsprechend geändert. --:Bdk: 01:27, 7. Nov. 2006 (CET)

NUMBEROFUSERS

Hallo, wieso erscheint bei manchen Wikis bei Eingabe der Variable NUMBEROFUSERS als Ergebnis eine fehlende Vorlagenseite (>Vorlage:NUMBEROFUSERS)? Müsste dies nicht überall gleich funktionieren? Bin bisher nur Wiki-Konsument gewesen. Sorry also, falls ich hier falsch poste. Z.B. hier ist die Anzeige nicht wie wohl beabsichtigt: zum:Hilfe:Variablen

Danke für eine Antwort! --88.134.42.65 00:39, 13. Dez. 2006 (CET)

Das ZUM-Wiki läuft mit MediaWiki 1.6.8 (siehe zum:Spezial:Version. Die Variable NUMBEROFUSERS wurde aber erst in der Version 1.7 eingeführt, siehe Release notes. --Raymond ^{Disk. Bew.} 00:56, 13. Dez. 2006 (CET)

Danke für die schnelle Antwort. Wie klappt dann die Anzeige der registrierten User auf der Spezialseite Statistik? Könnte man das nicht in der Form auch auf anderen Seiten einsetzen? --88.134.42.65 07:01, 13. Dez. 2006 (CET)

Dafür gibt es fertige MediaWiki-Texte: MediaWiki:sitestatstext und MediaWiki:userstatstext: Kannst du in der Form {{MediaWiki:userstatstext}} einsetzen:

Ups, nein, das geht so doch nicht. Muss mal also die Variablen nehmen. --Raymond ^{Disk. Bew.} 07:51, 13. Dez. 2006 (CET)

Seitenname

Mittlerweile besteht die Seite nicht mehr nur aus Variablen, sondern auch aus vielen Formatierungsanweisungen. Der Seitenname ist dadurch irreführend/falsch geworden. Für mich stellen sich zwei Möglichkeiten dar:

1. Seitenname ändern
2. Seite splitten und Formatierungsanweisungen auf eine eigene Seite verlagern.

Ideen für Seitennamen, Meinungen, Vorschläge? --Raymond ^{Disk. Bew.} 22:00, 29. Dez. 2006 (CET)

formatnum - Tausendertrennzeichen

Die Funktion formatnum kollidiert mit dem, was in dem Artikel Tausendertrennzeichen steht. Entweder benutzt man wie mit formatnum (und fuer mich sinnvoll erscheinend) den Punkt oder wie in dem Artikel ein Leerzeichen. Aber es waere schoen, wenn das ein eindeutiges Konzept waere. Jedenfalls habe ich nun schon erlebt, dass Leute mit Hinweis auf dem Artikel nun mit Punkt formatierte Zahlen in ein Leerzeichen umeditieren. --LugPaj 21:02, 4. Jan. 2007 (CET)

Wer erstellt die Variablen eigentlich?

Hallo, hilfreich wären neben {{NUMBEROFADMINS}}

• {{NUMBEROFUSERBLOCKADE}} = Anzahl total der Benutzersperren
• {{NUMBEROFFILEDELETION}} = Anzahl total der Dateilöschungen
• {{NUMBEROFPAGBLOCKAD}} = Anzahl total der Seitensperren

Sie wären unerlässlich für Wachstumsprognosen und Arbeitsanfall in der Wikipedia. Herzlichst -- Jlorenz1@web.de 14:06, 15. Feb. 2007 (CET)

Die werden von der Software, sprich MediaWiki zur Verfügung gestellt. Lokale Admins können keine Variablen erstellen. Dafür muss programmiert werden und die Funktion in MediaWiki eingebaut werden.

{{NUMBEROFADMINS}} gibt es aber: 174

Für die anderen kannst du via Bugzilla (Hilfe:MediaZilla) einen Wunsch äußern. Erwarte aber keine schnelle Realisierung. --Raymond ^{Disk. Bew.} 16:02, 15. Feb. 2007 (CET)

Benutzername

Irre ich mich, oder gibt es eine Variable, die den Namen des eingeloggten Benutzers bzw. die IP angibt? — nintendere 21:12, 6. Mär. 2007 (CET)

~~~? Ergäbe bei mir Klapper (+/-)

Gruss--Klapper (+/-) 19:27, 2. Mai 2007 (CEST)

Vielleicht nicht ganz das Gefragte, aber mir würde da noch Spezial:Mypage und die JavaScript-Variable wgUserName einfallen. --  Ολλίμίνατορέ 01:46, 3. Mai 2007 (CEST)

Als anonymer Benutzer steht

var wgUserName = null;

Also nicht die IP.

Eine solche Variabel im Sinne von Hilfe:Variablen gibt es nicht und es wäre auch nicht Sinnvoll, weil dann die Seite für jeden einzelnen Benutzer neugerendert werden müsste.

Besonders bei den Anonymen Benutzer wäre das eine grosse Belastung.

(Betrachte mal Unangemeldet bei Hilfe:Variablen die Uhrzeit und dann mal angemeldet. Für Anonyme Benutzer "steht die Zeit", für angemeldete läuft sie weiter. Grund: Als Anonymer Benutzer wirst du vom Chace bedient, amgemeldet aber von Datenbank Server selbst)

-- MichaelFrey 19:13, 3. Mai 2007 (CEST)

Also bei mir steht die Zeit auch als angemeldeter Benutzer. Die Zeit kann auch ohne JS nicht weiterlaufen (mit JS wird allerdings nur die Computerzeit angezeigt, die evtl. flasch ist), außer es wird AJAX verwendet, allerdings ist dies sinnlos. Die Variable __CURRENTTIME__ bzw. __LOCALTIME__ wird so selten benutzt. -- MfG, ThoRr 12:14, 14. Jul. 2007 (CEST)

var wgUserName = null; 

kann ich diese Variable auch als Abfrage in einer Wikiseite verwenden? Wie müsste dafür der Code heißen? Zum Beispiel

{{#switch:wgUserName|null=Anonymer Benutzer|Eingeloggter Benutzer}}

funktioniert leider nicht - aber ist so etwas ähnliches möglich? --80.149.179.2 11:10, 16. Feb. 2012 (CET)

Gegenteil von __NOEDITSECTION__ [Bearbeiten]

Hi! Ich möchte die Bearbeiten-Links abschalten, allerdings an zwei Stellen erzwingen. Wie mache ich das? -- MfG, ThoRr 12:07, 14. Jul. 2007 (CEST)

__NOEDITSECTION__ angeben, und bei den Überschriften explizit einen Link zu „edit section“ setzen (so wie von mir in der Überschrift dieses Abschnitts als Beispiel eingefügt).

Vorher aber die Section No. ansehen und merken. Die darf sich dann auch nicht mehr ändern. --Geri, 18:45, 14. Jul. 2007 (CEST)

Vielen Dank! -- MfG, ThoRr 19:17, 14. Jul. 2007 (CEST)

Leichter navigierbare Seitenstruktur

Ich habe mich mal an einer neuen Seitenstruktur versucht, nebst einigen kleineren Änderungen in Syntax und konsequenter Schreibung. [1] Mir ging es vor allem darum, dass sich ein unkundiger Leser wenigstens anhand des Inhaltsverzeichnisses leichter zurechtfindet und nicht erst alle lila-farbenen Balken nach was Passendem durchsuchen muss. Vielleicht profitieren ja auch die alten Hasen ;-) Auch wenn ich das größte Gegenargument schon zu kennen glaube ("Schau dir doch nur mal die unterschiedlichen Spaltenbreiten an"), würde ich ggf. gern Feedback dazu haben, bevor schnelle (Teil-)Reverts eventuell die Arbeit zunichte machen. ;-) Grüße, --CyRoXX ^(? ±) 01:01, 7. Aug. 2007 (CEST)

nicht nur der unkundige - so navigiert es sich auch fuer die Leute, die die Seite dauernd brauchen, viel angenehmer und schneller :-) --Elian Φ 02:07, 7. Aug. 2007 (CEST)

Meinen „Segen“ hast du auch ;-) Evtl. die Tabellenbreiten einheitlich auf 100 % oder 90 % festzurren? --Raymond ^{Disk. Bew.} 07:27, 7. Aug. 2007 (CEST)

Schön, dass es euch gefällt. Ich muss die Seite auch von Zeit zu Zeit konsultieren und kam einigermaßen mit der Navigation zurecht... Nach einer Weile weiß man ja ungefähr wo was steht. Aber als ich gestern "nur mal schnell" den Link zur DEFAULTSORT-Seite hinzufügen wollte und dazu die ganze Seite bearbeiten musste, anstelle nur die Tabelle mit den Parserfunktionen auswählen zu können, hatte ich dann die Faxen dicke.

Ich habe das Ganze jetzt mal noch mit Raymonds Tipp abgeschmeckt und eine einheitliche Tabellenbreite von 90% vergeben. Der einzige Schönheitsfehler ist nun, dass sich die Tabelle mit den Magic Words mit der Leiste am rechten Rand überlappt, aber das sollte noch im Rahmen des Erträglichen sein. Außerdem musste ich feststellen, dass die Datums- und Zeitvariablen noch völlig ohne Kommentar waren und habe versucht, den Unterschied zwischen CURRENT und LOCAL ein wenig aufzudröseln. Grüße, --CyRoXX ^(? ±) 13:34, 7. Aug. 2007 (CEST)

Letzter Edit eines Benutzers

Gibt es eine Variable, die ausgibt, wann der letzte Edit eines Benutzers erfolgt ist? LG, Hans Urian (d) 21:56, 21. Apr. 2008 (CEST)

Nein. Es ist auch nicht möglich das mit einem Aufruf oder einer Variable auszulesen. Blribt wohl nur der Links auf die Beiträge des Benutzers. Gruß, --Revolus Echo der Stille 22:08, 21. Apr. 2008 (CEST)

Danke für die rasche Antwort. Hans Urian (d) 22:14, 21. Apr. 2008 (CEST)

Sichter

Gibt es eine Variable, die die Anzahl der „Sichter“ ausgibt? Wurde nun eingeführt und ist sicher von allgemeinen Intereresse. Daß die Zahl abrufbar ist zeigt die Statistik: Anteil von gesichteten Artikeln in der Wikipedia von Benutzer:Aka mfg --DSC 23:38, 17. Mai 2008 (CEST)

Dass die Daten auf dem Tool-Server direkt aus der DB geholt werden können, heißt nicht, dass sie gleichzeitig auch als Variable z.V. stehen. Vorlage:NUMBEROFEDITORS und Vorlage:NUMBEROFREVIEWERS als Schuss ins Blaue, ist einer ins Rote :-) In mw:Extension:FlaggedRevs konnte ich nichts dazu entdecken. Also sage ich mal: leider, aber nein. --Geri , 04:15, 18. Mai 2008 (CEST)

Interessant wäre auch eine Variable, die die Anzahl der gesichteten / geprüften Artikel bereitstellt: Vorlage:NUMBEROFREVIEWEDARTICLES und Vorlage:NUMBEROFCHECKEDARTICLES. Was heute rot ist, kann morgen schon blau sein. -- Abubiju 14:40, 18. Mai 2008 (CEST)

#titleparts

Ich habe die Funktion #tileparts von dieser Seite entfernt, da sie nicht auf meta:help:magic words dafür aber auf meta:Help:ParserFunctions gelistet ist. Die Änderung wurde revertiert. Erklärung meinerseits: #titleparts mag eine Parserfunktion sein, aber sie ist erst mit Installation der Extension:ParserFunctions aktiv. Alles was mit der Extension installiert wird, wird auf Hilfe:Vorlagenprogrammierung erklärt, da ansonsten auf Hilfe:Variablen auch die #ifs und #rel2abs gelistet werden müsste, aber die Seite gibt nur ein Überblick über das, was mit einer einfachen Installation verfügbar ist. Siehe auch diesen Revert oder siehe auch Spezial:Version - Abschnitt "Parser-Funktionen" Der Umherirrende 22:21, 18. Mai 2008 (CEST)

Ups, hast natürlich Recht, wobei ich hätte schwören können, dass... Ich habe mich mal selber revertiert. Sorry. — Raymond ^{Disk. Bew.} 23:11, 18. Mai 2008 (CEST)

Kein Problem, ist ja gut das es geklärt ist. Darfst dich aber gerne aussprechen... Der Umherirrende 16:48, 19. Mai 2008 (CEST)

displaytitle

Diese Parserfunktion ist doch schon etwas merkwürdig. Mit ihr ist es nur möglich den ersten Buchstaben des Seitennamens klein darzustellen. Was mich aber verwundert ist, das es möglich ist, den Namensraum in Groß- und Kleinschreibung zu verändern (beliebig). Mir ist kein guter Erklärungstext eingefallen, vielleicht kann jemand etwas schreiben. Sie funktioniert auch in der Vorschau, dort kann sich das ganze angeschaut werden. Der Umherirrende 02:46, 11. Jul. 2008 (CEST)

Als Information noch gefunden: Wikipedia:Fragen zur Wikipedia/Archiv/2008/Woche 36#Soft redirect per Vorlage:DISPLAYTITLE ({{DISPLAYTITLE:n}}), zusätzlich kann man auch ein Doppelpunkt vor das lemma packen: :Wumpscut: --Der Umherirrende 22:47, 6. Okt. 2008 (CEST)

Oder ein leerzeichen zwischen Namensraum und Seitenname: Benutzer: RevoBot --Der Umherirrende 14:04, 26. Okt. 2008 (CET)

Ich glaube ich habe verstanden, was geht und was nicht: Es sind solche Lemmaabwandlungen möglich, wo bei copy&paste noch sichergestellt ist, das der Wikilink auf der gleichen Seite landet. Nur so kann man das nicht auf die Hilfeseite schreiben … --Der Umherirrende 16:22, 6. Mär. 2009 (CET)

Gehören {DEFAULTSORT} und {DISPLAYTITLE} zur Vorlagenprogrammierung?

Das mit dem finde ich okay, außer bei {{DEFAULTSORT:Sortierbegriff}} und {{DISPLAYTITLE:Lemma}}, welche in Artikeln alltäglich oder zumindest praktisch nur in Artikeln angewendet werden. Beide haben wohl eher extrem wenig bis nichts mit Vorlagenprogrammierung zu tun, oder? --ParaDox 17:43, 17:48, 20. Aug. 2008 (CEST)

Da hat jemand den Satz (Auch die Grundfunktionalität bringt bereits einen Satz von Parserfunktionen mit sich; diese werden separat unter Variablen besprochen.) überlesen. Siehe auch #titleparts. Zur Erkärung: Parserfunktionen und ParserFunctions sind verschiedend, zwar sind die ParserFunctions auch Parserfunktionen, (aber nicht andersherum), aber nicht von anfang an verfügbar, etwas verwirrend, aber wenn man einmal durchschaut hat, dann geht es. Vielleicht ist der Name der Extension etwas unpassend gewählt. Hilfe:Vorlagenprogrammierung#Funktion tag war ja auch eigentlich falsch, aber im jetztigen Abschnitt geht es. --80.143.77.154 19:19, 20. Aug. 2008 (CEST)

Diese Änderung ist nicht sinnvoll, da es sich um einen Eigennamen handelt (beides, also Extension und ParserFunctions) und nicht um "Denglisch". Ich werde aber nicht revertieren, da IPs gerne unbegründet revertiert werden, dadurch kommt man ja auch nicht weiter und keiner kann damit etwas anfangen. Vielleicht kann ja jemand mit einem Benutzerkonto dies nachvollziehen und revertieren. Schonmal vielen Dank. 80.143.111.232 18:05, 21. Aug. 2008 (CEST)

Du hast Recht. Ich habe die Änderung rückgängig gemacht. — Raymond ^{Disk. Bew.} 18:40, 21. Aug. 2008 (CEST)

{{PAGENAME}}

Kann ich Variable {{PAGENAME}} irgendwie modifizieren, erweitern, etc., dass das Lemma ohne einen Zusatz in Klammern angezeigt wird? Bei Weblinks, die durch ein Vorlage eingebunden werden, schaut es ansonsten etwas komisch aus siehe John Leech (Mathematiker).-- Alexkin 16:24, 14. Sep. 2008 (CEST)

Nein das ist nicht möglich. Es würde wohl auch zu viel Verwirrung und Fehlnutzung führen. Sehr viele Artikel haben so einen Klammerzusatz (bestimmt weit über 20%) und er stört ja auch nicht weiter. Es gibt auch Lemma, die Zeichen enthalten, die gar nicht in der Unicode-Tabelle vorhanden sind. Da muss man halt immer Abstriche machen, damit das ganze System funktioniert. Gruß, --RevoLus Echo der Stille 17:22, 14. Sep. 2008 (CEST)

Dank und Gruß -- Alexkin 17:42, 14. Sep. 2008 (CEST)

Bitte Beispiel bei {{anchorencode:Parameter}} korrigieren

Jetziger Text ist: Beispiel: {{Benutzer:Raymond/anchor|Köln|section=Mülheim}} (Mülheim) erzeugt die korrekte URL http://commons.wikimedia.org/wiki/K%C3%B6ln#M.C3.BClheim. -- Kann ich nicht nachvollziehen... Danke! G.Hagedorn 21:32, 20. Nov. 2008 (CET)

%C3%B6 ist die URL-kodierte Darstellung eines UTF-8 ös. Bei .C3.BC wurden die Prozentzeichen zu Punkten umgewandelt. Wofür weiß ich auch nicht, aber so macht das die MediaWiki-Software nunmal. :-) Ich hoffe, ich konnte deine Frage damit beantworten? Gruß, --Revolus Echo der Stille 21:38, 20. Nov. 2008 (CET)

Gegenteil von {{padright:Text|Länge|Füllzeichen}} bzw. {{FÜLLENRECHTS:Text|Länge|Füllzeichen}}

Gibt es auch so eine Variable, die einen Text verkürzt? Beispiel: {{***right:ABCD|3}} = ABC --87.162.3.214 17:34, 11. Dez. 2009 (CET)

Extension:StringFunctions oder indirekt durch padright: {{padright:|3|ABCD}} = ABC, siehe auch Vorlage:Str left, sollte aber Aufgrund der Serverlast mit Vorsicht genossen werden --Der Umherirrende 18:26, 11. Dez. 2009 (CET)

Danke für die Antwort, aber dann habe ich noch eine Frage: Wie macht man, wenn möglich, das selbe für die andere Seite, also: {{***left:ABCD|3}} = BCD? --87.162.49.108 18:37, 11. Dez. 2009 (CET)

Da fällt mir mit Core-Funktionen gerade nichts zu ein. Vorlage:Strcutright macht es ja andersherum --Der Umherirrende 19:03, 11. Dez. 2009 (CET)

nicht ganz symetrisch aber es gibt auch {{padleft:Text|Länge|Füllzeichen}} bzw. {{FÜLLENLINKS:Text|Länge|Füllzeichen}} -- visi-on 22:07, 11. Dez. 2009 (CET)

LiquidThreads

Hallo!

Es hat sich ein WikiProjekt geformt (Wikilink später), dass die Umstellung auf LiquidThreads, die in Zukunft irgendwann kommen sollen, helfen soll. Ich weise jeden, der denkt seine Skripte/Bots/etc. könnten von der Umstellung betroffen sein auf dieser Diskussion hin. Es geht dort nicht um den Vorschlag von Kolossos, sondern um die Vorbereitung zur Umstellung auf LiquidThreads. Bitte nicht hier oder auf der Hilfeseite antworten, sondern direkt zur Projektseite gehen oder sie zumindest beobachten. Weihnachtsgruß --Euku:^⇄ (LiquidThreads) 22:57, 25. Dez. 2009 (CET)

Revisionsid, Revisionsdatumsvariablen werden falsch eingefügt.

Hallo,

ich habe eine Vorlage in der ich die Revisionsid und die Revisionsdatumvariablen benutze. Diese Vorlage ist unter Jeder Seite, sodas mann immer die Aktuelle Revisionsid und das aktuelle Datum sieht. Wenn ich aus den Seiten eine PDF erstelle wird dies alles Falsch übernommen, dass Datum wird als das erstellungsdatum der Vorlage ersetzt und die ID erscheint überhaupt nicht.

Hat jemand eine Idee?

--141.35.213.221 12:23, 25. Aug. 2011 (CEST)

Das dürfte besser auf Hilfe:Buchfunktion/Feedback passen, auch wenn dort leider nicht mehr so viel geantwortet wird. Der Umherirrende 20:07, 4. Okt. 2011 (CEST)

Aktualisierungsrate

In welchem Interval werden die Zähler aktualisiert? Z.B. ARTIKELANZAHL. Geht das live oder nur alle paar Stunden? Alle 24h? --Stefan 09:24, 4. Okt. 2011 (CEST)

Das sind Livezahlen. Auch nachzusehen auf Spezial:Statistik. Etwas anders funktioniert hier Spezial:Markierungsstatistik. Hier wird mehrmals am Tag neu gezählt. Datum/Zeit der letzten Berechnung steht in der Einleitung. — Raymond ^Disk. 09:47, 4. Okt. 2011 (CEST)

Wobei eine Seite, die eine solche Variable enthält, trotzdem eine Zeit lang im Cache gehalten wird, sodass die angezeigte Zahl etwas älter sein kann, bei ARTIKELANZAHL bis zu eine Stunde, nachzulesen in MagicWord.php. --Schnark 10:27, 4. Okt. 2011 (CEST)

Ah, super. Danke. :) --Stefan 10:37, 4. Okt. 2011 (CEST)

durcheinander und behaviour switches

gudn tach!
im rahmen der aktuellen aenderungen ist mir aufgefallen, dass bei uns "magic words" nur ueber einem teil der "magic words" stehen. noch dazu werden hier im artikel die woerter teilweise anders zugeordnet als auf meta bzw. in w:en. "#redirect" wird dort z.b. gar nicht genannt.
und hat sich fuer die "behaviour switches" eigentlich ein begriff bei uns eingebuergert? -- seth 00:26, 20. Dez. 2011 (CET)

1. Es ist gut, dass dir das aufgefallen ist, und deine Beobachtung ist völlig richtig.
2. Ich denke, wir sollten diese Begrifflichkeit nicht überstrapazieren.
   • Der Begiff “magic word” wird schon nicht konsistent benutzt zwischen mw:Help:Magic words und mw:Manual:Magic words. Wenn das bereits bei größtmöglicher Nähe zu den Entwicklern uneinheitlich ist, sollte man daraus keine falschen Schlussfolgerungen ziehen.
   • Die #REDIRECT, RFC, ISBN und PMID tauchen hier überhaupt nicht auf.
   • Ich sehe keine normative Definition des Begriffs.
     • Eine solche wäre gerade für Programmierer sehr hilfreich, um dann per BNF usw. exakt und explizit das Wirken von Software vorzugeben bzw. das aktuelle Verhalten beschreiben zu können.
     • Als ich mich zuletzt dafür interessiert hatte, gab es noch nicht einmal eine normative und BNF-geeignete Beschreibung der WikiSyntax. (Hier würde <MagicWord> ebenfalls definiert auftauchen müssen).
   • Vermutlich hat der Begriff im Lauf der Jahre seine Bedeutung auch etwas geändert; wenn man 5, 8 oder gar 10 Jahre zurückgeht, wird sich wahrscheinlich ein Gebrauch finden, der unserer momentanen Hilfeseite entspricht.
   • Folgt man den Beschreibungen auf mw:, dann wären auch die ungeklammerten http:// usw. hinzuzuzählen.
   • Für die Einbeziehung einer parser function in die “magic words” wäre es nach einer der Darstellungen auf mw: relevant, ob sie zum “standard core PHP” (ohne präzise Definition) oder aber zu einer Erweiterung gehören würde.
3. Unsere Hilfeseite richtet sich an normale Vorlagenprogrammierer, nicht an Entwickler auf PHP- und Parser-Ebene. Für uns müsste reichen:
   • Mit gequirlten Klammern drumrum ist eine Variable; gibt es auch Parameter, dann ist es eine Funktion.
   • Alle anderen ohne Klammern (__ oder RFC, ISBN, PMID und #REDIRECT) nennen wir Magic Word. Die mit den __ haben zufällig die Eigenschaft, dass sie für irgendeinen Kontext (Suchmaschine, Darstellung des Seiteninhalts, „+“ rechts von „Seite bearbeiten“) irgendein Verhalten ändern. Dies würde ich aber nicht gesondert mit “behaviour switch” thematisieren.
   • Für deinen letzten Edit würde ich deshalb im Sinne Didaktischer Reduktion einen Teilrevert empfehlen. Das ist alles schon kompliziert genug, so auch die formale Übereinstimmung einer Vorlageneinbindung und einer Zeitvariablen.

HGZH --PerfektesChaos 12:32, 20. Dez. 2011 (CET)

Die magischen Wörter mit den Unterstrichen stehen auch in MagicWord.php drin, somit sind sie auch im Sinne von MediaWiki magische Wörter und keine Schalter zum Ändern von Verhalten. Im Entwicklerumfeld von MediaWiki habe ich das auch noch nie gelesen (wobei das nichts heißen muss, so tief stecke ich auch nicht drin). WP:VAR beschreibt alle Core-Funktionalität und WP:VP beschreibt im großen und ganzen die ParserFunctions-Extension. Der Umherirrende 19:35, 20. Dez. 2011 (CET)

gudn tach!

@PerfektesChaos: gegen einen teilrevert habe ich nichts. aber die bezeichnungen sollten nicht denen auf mw widersprechen. und das taten sie und tun sie in teilen immer noch.

@Umherirrender: ja, die "mDoubleUnderscoreIDs" bzw. "behavior switches" (laut w:en und mw) sind auch magic words, dem wollte afaics auch niemand widersprechen. oder was meintest du? -- seth 21:55, 20. Dez. 2011 (CET)

In jüngerer Zeit hat irgendwer angefangen, die Begrifflichkeit durchzuquirlen. Über viele Jahre waren die Magic Words genau das, was unsere Hilfeseite darstellt. In jüngerer Zeit werden die „alten“ und die weiteren in der vom Umherirrenden benannten Einheit MagicWord.php zusammengeführt, die nun wieder nicht die Parser Functions enthält. Das führt zu dem Kuriosum, dass es dort die „richtigen“ MagicWordMagicWords und die falschen, nämlich MagicWordwgVariableIDs gibt. Wobei die mDoubleUnderscoreIDs die "behavior switches" sind, und die RFC, ISBN, PMID sowie die parser functions überhaupt nicht vorkommen. Das ist alles zu hemdsärmelig, als dass wir damit noch mehr Verwirrung stiften sollten. Weder ist irgendwo eine belastbare, präzise und dauerhafte Definition von MagicWord gegeben (letztlich nur irgendwie ein string, der ein besonderes Verhalten auslöst), noch ist eine konsistente begriffliche Untergliederung in Einzeltypen vorhanden. All dies ist auch für den Zweck unserer Hilfeseite auch nicht erforderlich, und wir sollten dieses Perfekte Chaos unauffällig umgehen. Für die Benutzung in der Vorlagenprogrammierung ist es einerlei. LG --PerfektesChaos 23:17, 20. Dez. 2011 (CET)

ok, wenn das chaos erst seit kurzem existiert, dann ist es vermutlich am geschicktesten, wenn man die explizite benennung moeglichst weit reduziert, da stimme ich dir zu. aber langfristig sollte es schon darauf hinauslaufen, dass man die gleichen dinge mit den gleichen begriffen (von mir aus auch uebersetzt) bezeichnet, damit kommunikation ueber die grenzen (der dt.-sprachigen wikipedia zum rest der welt) hinweg nicht unnoetig erschwert und nicht sogar missverstaendnis-potenzial gefoerdert wird. -- seth 00:28, 22. Dez. 2011 (CET)

Ich kannte die Unterscheidung nach "behaviour switches" noch nicht, daher hatte ich das alles zu MagicWord gezählt, aber "behaviour switches" sind eine Untergruppe von den MagicWords. Ob man das allerdings extra aufzeigen muss, kann ich nicht sagen. Der Umherirrende 21:17, 22. Dez. 2011 (CET)

Die Dinger selbst gab es namenlos wohl fast von Anfang an bei den klassischen Magic Words, und ihre C-Syntax verweist auf Kindertage der Wikis (um 2005), als aus allen möglichen Konzepten unser heutiges Riesenbaby zusammengebaut wurde. Die Klassifizierung "behaviour switches" ist wohl erst wenige Jahre alt, und man kommt offenbar auch ohne aus. Ein frühes meta: – und das aktuelle meta:Help:Magic words zählt auch alle tags wie <nowiki> und die Bildparameter noch zu den Magic words. Vergesst all diese nachträglichen Klassifizierungen, es sind einfach unverbindliche Beschreibungen und keine klar abgegrenzten normativen Konzepte. --PerfektesChaos 22:03, 22. Dez. 2011 (CET)

1. Ursache ist offenbar, dass auf den englischsprachigen Seiten zwei Bedeutungsebenen von Magic Word durcheinander gehen:
   1. Allgemeines Konzept in der Software, siehe en:Magic word #Magic words in technology.
   2. Spezifisches Syntaxelement im Wikitext, mit einer präzisen Definition, was dazugehören soll und was nicht. Eine Definition gibt es nicht, nur in der klassischen Verwendung eine genau bekannte kleine Teilmenge und darüber hinaus neuerdings vielleicht alles Mögliche.
2. Ein erst noch zu schreibender Artikel oder besser Abschnitt in demselben könnte lauten:

   In der Informationstechnik sind Magic Words charakteristische Zeichenketten, die bei der Verarbeitung durch weitere Software Aktivitäten auslösen. Insbesondere wird die Zeichenkette als Platzhalter durch einen aktuellen Wert ersetzt, eine bestimmte Formatierung dafür ausgelöst oder eine Funktion gestartet und beispielsweise eine statistische Zählung bewirkt.

   Verwendet wird dieses Konzept unter anderem bei:

   • Server Side Includes

     Bewirkt beispielsweise unmittelbar vor Auslieferung einer HTML-Seite vom Webserver einen Ersatz durch aktuelle Daten und kann auch logische Ausdrücke enthalten.

     Um den HTML-Quelltext auch in anderen Zusammenhängen nutzen zu können, werden hier Server Side Includes meist in Kommentare eingebettet; das ist aber nicht zwingend notwendig, und im Text entsteht ohnehin eine dann unbemerkte inhaltliche Lücke.

   • Präprozessor-Anweisungen

     In der Programmiersprache C ersetzt der C-Präprozessor sogenannte Makros durch benutzerdefinierte oder standardisierte Zeichenketten. So werden etwa die charakteristischen __FILE__ oder __LINE__ durch Angaben zum Quellprogramm ersetzt.

   • Der Beginn von URL wie http:// oder mailto: wird im unformatierten Rohtext von E-Mails, Diskussionsforen, Twitter-Nachrichten oder Wikitext als solcher erkannt und die URL kann als aktivierbare Verlinkung angezeigt werden. Wenn das Ende der vermuteten URL gesucht wird, wäre auch eine Syntaxprüfung sinnvoll, um Fehlinterpretationen zu vermeiden.
   • In Kommentaren werden oft Hinweise für nicht standardgemäße Aktivitäten versteckt, die nur von der dafür vorgesehenen Software erkannt und sonst ignoriert werden.

     Nur für Interpretation durch den Internet Explorer sind Conditional Comments vorgesehen; so kann in HTML eingefügt werden:

     <!--[if lt IE 7]--> HTML-Code für IE vor Version 7<-- ![ENDIF] -->

     Die gleiche Methode kann auch für die bedingte Kompilierung von JScript benutzt werden:

     /*@cc_on @*/

   Allgemein kann man Magic Words als einen Trick der Programmierer auffassen, um pragmatisch zu Lösungen zu kommen, die über das standardisierte Repertoire einer formalen Sprache hinausgehen.

   Ein Sonderfall ist die Magische Zahl, die insbesondere am Beginn einer Datei steht und einen Hinweis gibt, wie der Inhalt der Datei vermutlich zu interpretieren sei. Dabei muss es sich nicht mehr ausschließlich um Ziffern handeln.

3. Auf der hier in Rede stehende Hilfeseite sollten wir keine Interna der Server-Programmierung diskutieren.
   • Für den WP-Autor genügt erstmal die Vorstellung, dass {{DISPLAYTITLE}} so eine Art Vorlage ist, und genau so funktioniert. Nur dass es eben keine Vorlage:DISPLAYTITLE gibt, und deshalb steht es hier auf dieser Seite. Außerdem steht Doppelpunkt statt Pipe.
   • Alles, was in lockigen Klammern steht, ist bereits formal als spezifische Wikisyntax erkennbar. Dies sollten wir nicht in die Begrifflichkeit Magic Word aufnehmen, und auch nicht spitzfindig unterkategorisieren. An geeigneter Stelle mag ein beiläufiger Hinweis auf „im engeren Sinne“ erfolgen, um ohne Verwirrung der Normalleser auf die erweiterte Bedeutung bei englischsprachigen Seiten hinzuweisen.
   • Die ISBN, RFC und PMID sind hingegen echte Zauberei – denn nirgendwo sonst ginge aus der Wikisyntax hervor, dass bei diesem normalen Text gefolgt von Ziffern plötzlich eine Verlinkung erfolgt. Gleiches gilt für die Underscore-Schlüsselwörter, die aus der C-Welt stammen.
   • Das #redirect ist sogar eine Magic Number; ein # im ersten Byte, gefolgt von einem geeigneten Schlüsselwort und einem Wikilink charakterisiert diese Seite als "besonders".

VG --PerfektesChaos 10:43, 22. Dez. 2011 (CET)

gudn tach!

von meiner seite zustimmung in allen drei punkten. -- seth 14:59, 23. Dez. 2011 (CET)

Bitte keine weiteren sinnlosen Verdenglichungen verbreiten

Also wenn hier schon eine Hilfeseite in deutscher Sprache gepflegt werden soll, dann sollte diese bitte auch keine unnötigen Fremdwörter beinhalten. Bei einem Satzteil wie parser functions und behavior switches bilden zusammen die Magic Words^[2] kann man auch gleich eine Weiterleitung oder – bei solch einem Neusprech hier – einen redirect auf die englische help site einrichten. Also soll das hier nun eine Hilfeseite für deutschsprachige Wikipedia-Autoren sein werden oder für Zauberlerlinge? --92.229.55.217 07:26, 21. Dez. 2011 (CET)

Sein. Und Fachsprachen haben nun mal eigene Begrifflichkeiten. --CC 07:32, 21. Dez. 2011 (CET)

Sein? Keine Ahnung was du damit ausdrücken wolltest, aber das ist hier kein Informatiker- oder Programmierer-Wiki, sondern die deutschsprachige Wikipedia, in der auch Nicht-Englischsprecher mitarbeiten wollen. --92.225.56.186 07:37, 21. Dez. 2011 (CET)

Was durch die Wortwahl nicht verhindert wird. Lass also bitte Seths Version bestehen. Sie ist besser. Danke. --(nicht signierter Beitrag von Carol.Christiansen (Diskussion | Beiträge) 07:41, 21. Dez. 2011) (Signatur nachgetragen von Martin1978 ^☎/_± WPVB)

Achso, na dann ist das Thema natürlich erledigt. Mir war bis eben nur noch nicht klar, daß angemeldete Benutzer immer recht haben. --92.225.58.247 08:09, 21. Dez. 2011 (CET)

Von dem Unfug mit dem angemeldeten Benutzer mal abgesehen ist es dann ja gut. Kopfschüttelnd, -CC 08:10, 21. Dez. 2011 (CET)

Das war ironisch gemeint, falls du das nicht mitbekommen hast. Und wenn du noch nicht weißt was das bedeutet, dann kannst du das auch unter „Rhetorische Ironie“ nachlesen. --92.225.61.22 08:35, 21. Dez. 2011 (CET)

Die deutsche Bezeichnung „Schlüsselwort“ (siehe auch „Schlüsselwort (Programmierung)“) wurde übrigens auch mit dieser und dieser und dieser Änderung wieder entfernt. --92.225.61.22 08:35, 21. Dez. 2011 (CET)

Solltest du selbst mal nachlesen, den Artikel. Und dass die Bezeichnung "Schlüsselwort" in diesem Zusammenhang mehrfach entfernt wurde hat damit zu tun, dass es sich in der Syntax der Mediawiki-Software um einen englischsprachigen Fachausdruck handelt, der diverse Typen von Funktionen in sich vereint. Im Gegensatz zu einem Schlüsselwort umfassen sie aber keine Variablennamen, sondern beschreiben ausgelöste Funktionen. Vielleicht solltest du einfach mal die Seite lesen und verstehen. Danke für das Ende deiner Bemühungen, den Text inhaltsärmer zu gestalten. --CC 09:20, 21. Dez. 2011 (CET)

Inhaltsärmer sind deine Unterstützungsversuche, die Verdenglichungen vom lustigen seth in unsere Sprach unterzuschieben. Der deutschsprachige Ausdruck „Schlüsselwort“ (Mehrzahl „Schlüsselwörter“ – falls es dazu einen besseren deutschsprachigen Oberbegriff gibt, dann immer her damit) könnte nämlich bereits die hier genannten Variablennamen oder -bezeichner und die komischen magischen Wörter (die sich die WikiMedia-Leute angeblich ausgedacht haben) miteinbeziehen. Aber einigen Leuten (wie dir und seth, siehe auch vorhergehende Diskussion) scheint es hier auch garnicht mehr um die Hilfe zu diesen Funktionen, Parametern, Variablen usw. zu gehen, sondern darum alles mögliche bis ins kleineste (unwichtigste) Detail (haarklein) aufzuspalten und dabei (mit einer Flut von Fremdwörtern und nichtssagenden Abkürzungen) möglichst viel Unklarheiten zu hinterlassen, mit denen normale Leser nichts mehr anfangen können. Es ist schon schlimm genug, daß unsere eigene Sprache auf der Quelltextebene bis heute als Sprache zweiter Klasse behandelt wird. Damit muß endlich mal Schluß sein! --92.225.62.197 10:31, 21. Dez. 2011 (CET)

Ich sehe, dass du keine Sachargumente hast, sondern lediglich schwadronierst. Wir lassen es also bei der Version von Seth. Nimm dies als feststehenden Beschluss. --CC 10:32, 21. Dez. 2011 (CET)

gudn tach!

92.225.62.197, du hattest auch in den vielen anderen faellen keinen erfolg, in denen du krampfhaft versuchtest, ohne auf den inhalt zu achten, scheinbar deutsche begriffe zu etablieren, die kaum jemand oder gar keiner ausser dir in diesen kontexten verwendete. dass du dabei meist angemeldet warst, hatte uebrigens genausowenig eine rolle gespielt, wie es jetzt deine vermeintliche anonymitaet tut.

in diesem fall war "schluesselwort" gar nicht so dumm, allerdings zu allgemein. ich hatte in meiner aenderung uebrigens den begriff "schalter" als beschreibung fuer "behavior switches" verwendet, das haette dir eigentlich doch gefallen sollen. nichtsdestotrotz solltest du deinen teutschen uebersetzungsdrang mal zurueckhalten, und zwar mind. bis die inhaltlichen fragen (siehe oben) geklaert sind. denn erst mal sollte sichergestellt sein, was ueberhaupt die originalen begriffe bezeichnen, bevor mal wild irgendwelche kontextfreien uebersetzungen anwendet. -- seth 00:16, 22. Dez. 2011 (CET)

Mehrzahl: „(die) Variable“ oder „(die) Variablen“?

Hinsichtlich der letzten Zurücksetzung mit Verweis auf den Scheinbeleg bei canoo.net (siehe auch [3]) wurde bereits unter WP:FzW eine öffentlichere Diskussion, mit der Überschrift Mehrzahl: „(die) Variable“ oder „(die) Variablen“?, begonnen.
--FBE2005 – 09:54, 23. Jan. 2012 (MEZ) 09:54, 23. Jan. 2012 (CET)

Hi FBE2005! Danke für den Hinweis, das kannte ich noch nicht.

Zur Sache: Dort findet man auch den Kommentar „Kluge und Variable sind Adjektive, die substantiviert wurden, und werden wie Adjektive gebeugt (kluge Menschen, variable Werte). Die Klugen und die Variablen sind richtige Substantive und kriegen die (feminine) Pluralendigung -(e)n.“ Dem schließe ich mich an:

Es heißt also zwar „Die Klugen sind schlauer als die Dummen“ und „Die Variablen werden eingesetzt, indem sie durch Klammern eingefasst werden“, aber eben „Kluge sind schlauer als Dumme“ (und natürlich nicht „Klugen sind schlauer als Dummen“), also auch „Variable werden eingesetzt, indem sie durch Klammern eingefasst werden“. Liebe Grüße, Franz 11:37, 23. Jan. 2012 (CET)

Zur Erklärung: der Begriff Variable wird in dieser Hilfeseite ausschließlich als Substantiv verwendet. Die Variable meint hier immer einen Platzhalter, der einen veränderlichen Wert ersetzt. Und der Plural eines weiblichen Substantivs endet im Akkusativ auf -(e)n. Ein anderer Fall ist die adjektivische Verwendung. Dann steht Variable (als substantiviertes Adjektiv) für variable Werte, variable Eigenschaften etc. Dann würde Variable wie ein Adjektiv gebeugt, also mit Akkusativ-Plural "Variable". Eine solche Verwendung liegt hier aber nicht vor. Oder zur Verdeutlichung:

1. Es gibt verschiedene Arten von Platzhaltern, variable und konstante.
2. Es gibt verschiedene Arten von Platzhaltern. Es gibt Variable und Konstante.
3. Es gibt verschiedene Arten von Platzhaltern. Es gibt Variablen und Konstanten.

Im ersten Fall sind "variable" und "konstante" Adjektive, die sich auf die Platzhalter im Hauptsatz davor beziehen. In einem eigenen Satz wie in Fall 2 werden "Variable" und "Konstante" zu substantivierten Adjektiven und müssen groß geschrieben und adjektivisch gebeugt werden, ergänzen aber die Platzhalter im Satz davor. Und in Fall 3 stehen die "Variablen" und "Konstanten" als eigenständige Beispiele für Platzhalter, der zweite Satz könnte aber auch völlig alleine ohne den Satz davor stehen.

Warum sich Canoo auf die adjektivische Verwendung beschränkt, weiß ich nicht. Die Ersetzungsprobe (Variable = Platzhalter / Variable = variable Werte) zeigt jedenfalls den Unterschied. Ich hoffe, ich konnte erhellen. Gruß -- HvW 12:31, 23. Jan. 2012 (CET)

Dieses Substantiv hat zwei Pluralformen:

1. Variablen
2. Variable (fachsprachlich, ohne Artikel)

Duden, Band 1: Rechtschreibung.

• Weiterführend mit Deklination: wikt:Variable

--PerfektesChaos 21:26, 23. Jan. 2012 (CET)

Ja, das ist ziemlich hinterhältig. Auch dort mischen sie wieder beides (es heißt dort übrigens "fachsprachlich auch Variable"). Im Duden wird es gleichgesetzt mit "veränderliche Größe", als solches ist Variable okay, siehe oben. Aber Variablen wie x und y sind Variablen. Das mag verwischen, weil man einfach mutmaßen kann, es seien variable Größen gemeint. Und sprachliche Ungenauigkeiten tun ein Übriges, wobei "exotische" Varianten einen besonderen Reiz ausüben. Der grammatikalische Hintergrund ist jedenfalls obiger und wenn der Duden ohne ganz genaue Differenzierung beide Varianten akzeptiert, dann gibt es keinen Grund, auf "Variable" umzusteigen. -- HvW 23:19, 23. Jan. 2012 (CET)

• Alle Verwendungen auf dieser Hilfeseite betreffen die informationstechnisch-mathematische Bedeutung, also fachsprachlich, und im Übrigen nur als Substantiv. Hier ist auch das im Einleitungsabsatz formulierte werden [[Variable (Programmierung)|Variable]] eingesetzt in beiden Formen zulässig.
• Das Ändern von einer richtigen Form in eine andere richtige Form und das Rumrevertieren zurück in eine richtige Form gehört sich nicht; siehe WP:RS.
• Ich verwende in der WP, wenn ich daran denke und selbst schreibe, durchgehend den Universal-Oma-Plural „Variablen“.
• „Verbesserungen“ bereits richtiger Verwendungen nehme ich nicht vor; sie sind auch für das Ziel dieser Hilfeseite absolut bedeutungslos und hindern niemand am Verständnis.
• Ein angeblicher „Schreibfehler“ hat hier niemals vorgelegen. Die grammatische Konstellation hat im vorliegenden Einzelfall keine Bedeutung. Die Herumschubserei der letzten Tage war völlig überflüssig; das rechthaberische Beharren auf der im eigenen Besitz befindlichen absoluten Wahrheit darf in diesem Themengebiet unterlassen werden.

--PerfektesChaos 00:09, 24. Jan. 2012 (CET)

gudn tach!

ich stimme PerfektesChaos weitgehend zu. woerterbuecher belegen ja, dass beide versionen korrekten sind.

allerdings ist grundsaetzlich ein revert von gegen WP:RS-verstossenden aenderungen selbst kein verstoss gegen WP:RS, denn sonst ware WP:RS ja ueberfluessig. -- seth 22:55, 24. Jan. 2012 (CET)

Variable für Login Status?

Hallo, gibt es eine Variable, die angibt ob ein Benutzer eingeloggt ist? Mfg, 80.149.179.2 10:40, 16. Feb. 2012 (CET)

Nein, es lässt sich aus dem WikiText heraus nicht erkennen, ob der Betrachter ein angemeldter Benutzer oder eine IP ist und auch nicht, wer er ist. Dies würde den Cache aushebeln und dadurch zu einem Performanzproblem führen. Der Umherirrende 17:01, 16. Feb. 2012 (CET)

Bedeutung der Magic Words

Es wäre schön, wenn noch die Bedeutung der Magic Words ergänzt würde, also zum Beispiel, dass NOTOC für no Table of Contents steht. --Seth Cohen (Diskussion) 16:42, 16. Jun. 2012 (CEST)

Ja; das gesamte Paket an Hilfeseiten zu Vorlagen, Programmierung und auch diese hier müsste mal komplett überarbeitet und verständlicher werden. Da kann man deiner Anregung sicher folgen. Allerdings wird das ein größerer Kraftakt. Schönes Wochenende --PerfektesChaos 17:45, 16. Jun. 2012 (CEST)

Danke, gleichfalls. :-) --Seth Cohen (Diskussion) 18:37, 16. Jun. 2012 (CEST)

Ich wollte meine Benutzerseite erstellen- da fiel mir folgendes auf: "Jede Benutzerseite ist nach Erstellung sofort öffentlich einsehbar. Standardmäßig werden Benutzerseiten aber derzeit nicht von Suchmaschinen indiziert, soll diese Seite trotzdem von Suchmaschinen gefunden werden, muss das Magic Word __INDIZIEREN__ in den Seitentext eingefügt werden." Auf der Hilfeseite dazu fand ich das:"lädt Suchmaschinen ein, die Seite zu indizieren, ist aber in der Wikipedia nicht sinnvoll, da diese Einladung für Suchmaschinen ohnedies für viele Wikiseiten in der Serverkonfiguration vermerkt ist." Das verstehe ich nicht.--VomMüller (Diskussion) 16:15, 25. Okt. 2012 (CEST)

Naja, vielleicht hieße es besser „ist aber in der Wikipedia nur selten sinnvoll“ – auf Wikipedia:Suchmaschinenindex wird direkt danach verwiesen. Für die allermeisten Seiten ist das schon Namensraum- und blockweise einheitlich geregelt, und das __INDIZIEREN__ ist nicht erforderlich; teils wirkungslos.

• Benutzerseiten sind gerade die individuelle Ausnahme vom Regelfall, den „vielen Wikiseiten“.

VG --PerfektesChaos 16:37, 25. Okt. 2012 (CEST)

Dann sollte ich es also auf meiner Benutzerseite einfügen?--VomMüller (Diskussion) 16:41, 25. Okt. 2012 (CEST)

Ob du das solltest, musst du selbst wissen. Standardmäßig wird den Suchmaschinen erstmal gesagt, dass du nicht bei Google & Co. auftauchen sollst. Wenn du das aber individuell gern möchtest, kannst du die Anweisung einfügen und wirst von Google wahrgenommen. Grüße --PerfektesChaos 16:53, 25. Okt. 2012 (CEST)

Danke--VomMüller (Diskussion) 18:14, 25. Okt. 2012 (CEST)

Nur Variablen oder auch allgemein Schlüsselwörter?

Es mag ja durchaus zutreffen, daß beispielsweise ers: und subst: streng genommen keine Variablen sind,^[4] sondern wohl eher Funktionen – so wie das auch bei weiteren hier aufgeführten Schlüsselwörtern (oder in enWP/WM-Sprech Magic Words) der Fall ist. Warum nun aber ausgerechnet diese beiden Schlüsselwörter wieder aus der Projektseite – die ja offenbar nicht nur Variablen im engen Sinn sondern auch andere Dinge beschreibt – entfernt wurden, ist nicht so ganz ersichtlich. Hinzukommt noch, daß diese – ich nenne sie nun einfach mal – Ersetzen-Funktion wohl auch nicht nur für Vorlagen sondern für jede beliebige Quellseite, die hier mit doppelt geschweiften Klammern {{eingebunden}} werden kann, genutzt werden kann, was ein weiterer Grund ist, diese Schlüsselwörter nicht (nur, versteckt) in der genannten Vorlagen-Hilfe zu nennen. --92.225.50.252 09:05, 18. Aug. 2012 (MESZ)

• Ich gebe dir insofern recht, dass das gesamte Paket an V-Hilfeseiten einmal überarbeitet und neu gegliedert werden müsste; das ist aber ein Riesen-Akt und nicht durch kleine Edits an einzelnen Stellen zu beheben.
  • Das darf nicht dazu führen, dass Leute nicht mehr damit arbeiten können, die schon seit vielen Jahren mit der historisch gewachsenen Seitenstruktur wursteln.
  • Dazu müssten zunächst interessierte und versierte Leutchen (aus Werkstatt-Kreisen) eine für Leser verständliche Systematik abstimmen. Erst danach hätten massive Edits eine Spur von Sinn. Zurzeit ist Urlaubszeit und ein wesentlicher Teil offline. Es wäre aber auch eine Arbeit für mehrere Monate, und die Beteiligten sind ganz gut eingespannt.
  • Betroffen sind Hilfe:Variablen, Hilfe:Vorlagen, Hilfe:Vorlagenprogrammierung sowie möglicherweise neu oder als Unterseiten zu erstellende Seiten. Zurzeit quellen die Seiten bereits über, und es sind noch gar nicht alle relevanten Themen in der deWP oder sonst irgendwo in deutscher Sprache abgehandelt.
• Die Seiten folgen dem Prinzip, dass jedes Syntaxelement nur an genau einer Stelle erklärt wird. Ansonsten hätte man bald auf allen Seiten alles doppelt und dreifach.
• Mir schwebt unter anderem ein Register aller Schlüsselwörter vor, über das man als alphabetisch und nach Typ sortierbare Tabelle zur richtigen Seite kommen kann. Es gibt echte Magic Words, echte Variablen, behavior switches, Basisfunktionen, Parser-Funktionen, Erweiterungs-Funktionen und noch allerlei; das ganze englisch oder deutsch übersetzt. Auf einer einzelnen Seite kann man nicht alles ausbreiten, zumal es unterschiedliche Bedürfnisse von reinen Vorlagen-Benutzern und Programmierern gibt.
• Hinzu kommt, dass in absehbarer Zeit die zusätzliche Einführung einer neuen Vorlagen-Technologie bevorsteht: Lua.

Ich hoffe geholfen zu haben; schönes Wochenende --PerfektesChaos 10:20, 18. Aug. 2012 (CEST)

Naja, teilweise. Also deine Erklärungen sind zwar nachvollziehbar und dadurch ein Stück weit auch hilfreich, wer aber so wie ich (und wie du offenbar selbst auch) eine zentrale Seite (oder ein Register, wie du es nennst) bevorzugt, muß sich nun wohl leider dem gewachsenen Kaos unterordnen oder dieses irgendwie auswendig lernen – egal wie widersinnig dieses ersteinmal erscheint. Und das dieses Kaos nun nur noch von einigen Wenigen (wer auch immer Diese sind) irgendwo im Hintergrund regiert wird, macht es nicht besser und verstößt meinem Empfinden nach auch gegen das Wikiprinzip, nach dem ja eigentlich Jeder hier möglichst leicht mitarbeiten können soll oder darf. --92.224.250.113 11:22, 19. Aug. 2012 (MESZ)

Nebenwirkung der Funktionen uc und lc

Ist das erste Zeichen des Parameters ein "#" oder "*", erfolgt ein Zeilenumbruch und das zeichen als Listenelement verwendet. So ergibt {{uc:#abc}}

1. ABC, und {{gross:#abc}}
2. ABC, bzw. {{ucfirst:#abc}}
3. abc sowie {{lcfirst:#AB}}
4. AB
   

oder {{uc:*123}}

• 123.
  

Ebenso erzeugt die Kombination {{uc::::**}}

• • folgerichtig Zeilenumbruch und dreifache Einrückung und zweifache Liste.

Das scheint mir einen Implementierungsfehler darzustellen. Weitere mögliche Nebenwirkungen dieser Funktionen habe ich noch nicht untersucht, die meisten Zeichen veranlassen nicht diesen Umbruch. -- sarang♥사랑 23:15, 16. Sep. 2012 (CEST)

Das ist ein Problem, welches viele Parserfunktionen und Vorlagen haben, siehe dazu Bug 12974. Dort dürften auch verschiedene Möglichkeiten geben, das etwas zu umgehen. Der Umherirrende 20:39, 17. Sep. 2012 (CEST)

Ich habe zu diesem speziellen Fall ein eigenen Bug angelegt: Bug 40294. Inhaltlich ist das aber nur ein weiteres Duplikat zu Bug 12974. Ich markiere es als Duplikat. --Fomafix (Diskussion) 08:19, 18. Sep. 2012 (CEST)

indexieren

Das Schlüsselwort heißt "NICHT_INDEXIEREN". Ich halt das für mindestens unschön. Korrekt wäre eigentlich "NICHT_INDIZIEREN". Wer hat das zu verantworten? 213.54.46.88 22:29, 20. Dez. 2012 (CET)

Es geht beides, siehe auch diesen Versionsunterschied. Der Umherirrende 22:58, 20. Dez. 2012 (CET)

Ich weiß, dass beides geht, finde es aber unschön. Inwiefern ist die Bedeutung unterschiedlich, wie der Edit-Kommentar behauptet? 213.54.46.88 22:59, 20. Dez. 2012 (CET)

Geitost hatte das auch auf dem translatewiki ergänzt, siehe diesen Versionsunterschied. Ich fand indexieren auch immer besser, aber wenn das andere gewünscht ist, hatte ich das nicht weiter verfolgt. Der Umherirrende 23:06, 20. Dez. 2012 (CET)

• „indexieren“ ist der korrekte Fachausdruck für das, was bei Suchmaschinen passiert.
• „indizieren“ ist ein vieldeutiges Wort, das landläufig mit dem Verbieten von Schriften verbunden wird; das wäre das genaue Gegenteil von dem, wofür Suchmaschinen hier sorgen. Man darf es aber laiensprachlich auch statt „indexieren“ sagen.

Liebe Grüße --PerfektesChaos 23:42, 20. Dez. 2012 (CET)

Unterscheidung von Benutzergruppen

Könnte man eine Variable programmieren, die je nach Benutzergruppe des jeweiligen Nutzers einen anderen Wert zurückgibt? Mir würde es schon reichen, wenn die Variable zwischen angemeldetem und nicht angemeldeten Nutzern unterscheiden könnte. Also so ähnlich wie {{GESCHLECHT:Benutzername}} je nach Geschlecht etwas anderes liefert, könnte bspw. {{BENUTZERGRUPPE:Benutzername}} bei angemeldeten Nutzern WAHR zurückgeben und bei IPs FALSCH.

Ich habe auch mal bei der Vorlage:Benutzer versucht nachzugucken, wie diese zwischen angemeldeten Nutzern und IPs unterscheidet und bin dabei auf Kommandos, wie {{lc:{{{1}}}}}, {{uc:{{{1}}}}}, {{#if:trim|{{{1}}}}} und <span class="adminonly"> gestoßen - kann mir die vielleicht jemand erklären?! Grüße — Alleskoenner (Diskussion) 23:06, 26. Mär. 2013 (CET)

Da unterliegst du einem grundlegenden Missverständnis: Der Inhalt einer Seite ist völlig unabhängig von den Eigenschaften des Lesers; die Variablen unterscheiden sich deshalb nicht zwischen angemeldeten und nicht angemeldeten Lesern, angemeldeten Männlein, Weiblein oder Weißnicht. Es ist immer derselbe Inhalt.

Lediglich wenn man etwas auf eine Benutzerseite einbindet, könnte man herausfinden, ob diese Benutzerseite als Namensraumpräfix „Benutzerin“ oder „Benutzer“ trägt. Das ist aber eine Eigenschaft der Seite und nicht des Lesers.

--PerfektesChaos 23:57, 26. Mär. 2013 (CET)

Das Missverständnis ist ganz Deinerseits: Der Inhalt der Variable {{GESCHLECHT:Benutzername}} richtet sich nach den persönlichen Einstellungen, 1. Tab, Feld Geschlecht. Mit der Eigenschaft der Seite, auf der sie eingebunden wird, hat das nichts zu tun. --Stepro (Diskussion) 00:07, 27. Mär. 2013 (CET)

Bedaure, das ist ein Denkfehler.

• Die Anfrage zielt offenbar darauf ab, ob der Leser einer Seite angemeldet sei oder nicht; und falls ja, welchen Geschlechts.
• Die Funktion GENDER/GESCHLECHT benötigt als Parameter einen ganz konkreten Benutzernamen.
• Der Name des lesenden Benutzers ist aber grundsätzlich der Wikisyntax unbekannt. Es gibt keine Variable dieser Art, und es kann keine geben.
  • Es gibt nur zwei Ausnahmen:
    1. Beim Abspeichern: REVISIONUSER oder mit drei Tilden ~~~
    2. Bei Einbindung im BNR oder Benutzerdisku. Hier lässt sich ein Name aus dem Seitennamen extrahieren; das eingetragene Geschlecht ergibt sich bereits aus dem Präfix „Benutzerin“. Es ist dann aber der Name des Seiteninhabers und nicht des Lesers.
• Hintergrund ist, dass die Seite (zunächst der Content-Bereich innerhalb des Skin-Portals, dann wohl auch die damit zusammengefügte HTML-Seite nach Bedarf) nach Expansion aller Vorlagen und Auswertung aller Variablen fest im Server-Cache abgespeichert wird. Es zählt nur, was in diesem Moment der Abspeicherung bekannt ist.
  • Nur einige wenige Zähler und Datum/Zeit werden etwa stündlich aktualisiert (TTL); sofern nach Expansion noch vorhanden.
  • Für die nächsten mindestens 60 Minuten, in der Regel mehrere Tage erhalten alle Leser die identische Seite geliefert.
  • Nur wenn eine eingebundene Vorlage sich ändert (oder purge) oder eine verlinkte Seite gelöscht oder erstellt wurde, wird die fest vorbereitete Seite ungültig und neu aufgebaut; natürlich auch, wenn sie selbst sich ändert.
• Beiläufig wird GENDER/GESCHLECHT nur selten in Wiki-Seiten benutzt; häufig aber in spontan zusammengestellten Systemnachrichten, die den momentan eingeloggten Benutzer kennen.
• Diese Anfrage kommt etwa alle halbe Jahre auf dieser Disku oder in der Vorlagenwerkstatt.

HGZH --PerfektesChaos 09:59, 27. Mär. 2013 (CET)

Möglicherweise schreiben wir ja aneinander vorbei (Du hast Dich auf Leser bezuogen, ich auf Nutzer), aber ich kann an meiner Aussage oben keinen Fehler finden. Konkretes Beispiel:

{{GESCHLECHT:Widescreen|männlich|weiblich|unbekannt}} ergibt auf dieser wie auch auf jeder anderen Seite die Ausgabe »weiblich«, gleich, welcher Leser die Seite aufruft.

Wie ich schrieb wird die pers. Einstellung des angegebenen Nutzers abgefragt. Ob auf der eingebauten Seite oben Benutzer oder Benutzerin steht ist egal. --Stepro (Diskussion) 10:56, 27. Mär. 2013 (CET)

Doch, ich glaub ich weiß, was PerfektesChaos sagen will; er meint, eine Vorlage könnte wenn überhaupt nur dann zwischen angemeldetem und nicht angemeldetem Nutzer entscheiden, wenn der jew. Benutzername konkret per Parameter in die Vorlage eingebunden wird, es aber nicht möglich sei, dem Leser eine Vorlage nur aufgrund seiner Benutzergruppe unterschiedlich darzustellen, ohne dass dafür ein Parameter verwendet wird (hab ich das richtig verstanden?).

Dazu möchte ich aber zwei Dinge sagen:

1. wäre es mir ja schon recht, wenn wenigstens das ginge - d.h. wenn man den Benutzernamen als Parameter eingibt, soll die Funktion zurückgeben, welcher Benutzergruppe er angehört; z.B. für die Vorlage:Benutzer würde das von großem Nutzen sein. Und hierbei sollte es auch problemlos möglich sein, das zu realisieren, denn - wie schon gesagt - funktioniert GESCHLECHT auf die selbe Weise (und nicht etwa nur auf Benutzerseiten etc).

2. Glaube ich im übrigen nicht ganz, was PC oben schrieb (wenn ich es denn richtig verstanden habe) - wie ich in der Einleitung nämlich schon dargestellt habe, gibt es bspw. den tag <span class="adminonly">, der eben genau das tut, was PC oben für unmöglich erklärt hat: Dieser tag unterscheidet zwischen der Nutzergruppe des jeweiligen Nutzers und gibt daraufhin je nach Ergebnis (hier: Admin oder nicht) ein anderes Ergebnis zurück. Das heißt, technisch ist es offensichtlich sehr wohl möglich, ohne jegliche Parameter zu unterscheiden, welcher Benutzergruppe der individuelle Leser angehört und daraufhin unterschiedliche Ergebnisse zu liefern. Mich würde deshalb interessieren, ob es auch <span class="useronly"> oder so ähnlich gibt. Grüße — Alleskoenner (Diskussion) 16:05, 27. Mär. 2013 (CET)

(Mir sind die verschiedenen Ebenen dieser Anfrage und Antworten schon durchaus klar; ich versuche sie sauber auseinanderzuklamüsern.)

• @Stepro: Gegenfrage: Wo bekommst du denn die Zeichenkette Widescreen her?
  • Du könntest sie nur fest in die Vorlageneinbindung hineinschreiben und würdest wohl immer das gleiche Ergebnis bekommen, oder dir blieben die beiden oben von mir aufgezeigten Wege.
• Wir sind hier auf der Diskussionseite zum Thema Variablen.
• Die gestellte Anfrage läuft in ihrem Tenor und in der notwendigen Konsequenz darauf hinaus, eine Variable {{BENUTZER}} einzufordern, die dann in der skizzierten Weise ausgewertet werden solle.
  • Aus den oben dargelegten Gründen kann und wird es keine solche Variable geben.
  • Das Operieren mit Benutzernamen in Vorlagen ist eine extrem begrenzte und seltene Angelegenheit, bei der es in der Regel um eine Benutzerseite geht, auf der eingebunden wird. Ansonsten gibt es bloß den handgeschöpften Mechanismus wie auf WP:VM zu „Benutzer melden“ angewendet: „ersetze die in Großbuchstaben stehenden Platzhalter durch den entsprechenden Benutzernamen“.
• Administratoren bekommen in ihren load.php aus MediaWiki:Group-sysop.css die folgenden Zeilen CSS zusätzlich ausgeliefert:

span.adminonly { display: inline !important; }
div.adminonly { display: block !important; }

• In manchen Seiten, die auch administrativ relevante Angelegenheiten enthalten, gibt es von vornherein immer Elemente etwa in der Art:

  <span class="adminonly" style="display:none;">Aufregend</span>

  • Alle erhalten ein und dieselbe Seite.
  • Normalbenutzer sehen das Element nicht, weil display:none.
  • Administratoren können es sehen, weil sie das mitttels display:inline!important übersteuern.
  • Alle angemeldeten Benutzer können sich in ihre common.css die gleichen Zeilen hineinschreiben, die die Admins von Hause aus sehen. Sie würden dann irgendwelches wirkungsloses Zeugs wahrnehmen.
  • Wie du dich hier überzeugen kannst, ist das auch das einzige Gruppen-CSS. Ein Weiteres wird es ohne projektweite Notwendigkeit auch nicht geben.
  • Vom Server werden Spezialseiten, die immer erst dynamisch im Moment generiert werden, bei Administratoren ggf. mit zusätzlichen Bedienelementen generiert.
  • Der Portal-Rahmen der Skin wird Administratoren mit zusätzlichen Elementen vom Server geliefert; den sogenannten „Knöppen“.
  • Nochmals: Der HTML-Inhalt (content area) regulärer Seiten ist immer derselbe; er wird auch nicht durch Nutzereigenschaften und Variablen nachträglich beeinflusst.
• Im Übrigen ist Alleskönner ein erfahrener und routinierter Programmierer zahlreicher Vorlagen. Wenn noch Klärungsbedarf besteht, kann gern in der Vorlagen-Werkstatt weiterdiskutiert werden; unter penibler Beachtung der dort zu Seitenbeginn aufgeführten „W-Fragen“ mit einer präzisen und vollständigen Fragestellung.

VG --PerfektesChaos 20:36, 27. Mär. 2013 (CET)

FYI: Wikipedia:Fragen_zur_Wikipedia#Unterscheidung_von_Benutzergruppen. Dort wurde auf die Funktion {{#if:{{#invoke:IPAdressen|isIP|127.0.0.1}}|Eine IP!|Keine IP!}} und bugzilla:15352 hingewiesen. Grüße — Alleskoenner (Diskussion) 01:15, 28. Mär. 2013 (CET)

Die Anfrage scheint zwei Dinge zu vermischen. Einmal geht es um die Möglichkeit, auf die Benutzergruppe des aktuell lesenden Benutzer zuzugreifen, was aber nicht geht. Anderseits geht es darum für einen per Parameter angegeben Benutzer, die Benutzergruppe zu bekommen? Nur das würde im Kontext von {{Benutzer}} Sinn machen. GENDER funktioniert in diesem Kontext, in dem man einen Benutzernamen angibt. GENDER hat nur die zusätzliche Eigenschaft, das bei einer Verwendung als Navigationselement und zeitgleichen fehlenden ersten Parameter der aktuell lesende Benutzer genommen wird. Das funktioniert aber nur im Kontext von Systemnachrichten, weil es ansonsten, wie eine Variable CURRENTUSER den Cache umgehen müsste, was die Server nicht leisten könnne. Per adminonly werden nur einige Links auf Sperren oder Löschen versteckt, damit es keine Links gibt, die der Benutzer eh nicht ausführen kann. Was möchtest du den vor den admins verstecken, das du useronly brauchst? Jeder Admin ist auch Benutzer, sollte soetwas auch sehen. Jede IP kann auch Autor sein, ein angemeldete Benutzer kann auch nur lesend tätig sein (mit für ihn angepassten Einstellungen beispielsweise). Daher halte ich eine solche Unterscheidung nicht für sinnvoll, vorallem wegen der Pauschalisierung der Tätigkeiten. Der Umherirrende 08:56, 28. Mär. 2013 (CET)

Jap, um diese zwei Dinge geht es hier.

• Zum ersten Punkt (Benutzergruppe des Lesers): Du schreibst oben, es ist unmöglich, auf die Benutzergruppe des aktuell lesenden Benutzers zuzugreifen - dazu aber nochmal der Hinweis: bei adminonly geht es doch auch! Wieso sollte es dann bei allen anderen Nutzergruppen nicht gehen?? Und übrigens hast du da glaube ich ein wenig was falsch verstanden: Es geht mir nicht darum, vor Admins etwas zu verstecken - diese sind wie du ja auch schon sagtest sowieso angemeldete Nutzer; viel mehr soll ermöglicht werden, dass IPs - genau wie bei adminonly - Links ausgeblendet werden können, die für sie ohnehin nutzlos sind, da sie sie nicht ausführen können (z.B. Funktionen, wie Spezial:Beobachtungsliste oder Spezial:Meine Benutzerseite wie sie oftmals auf Hilfeseiten vorkommen, die IPs nicht aufrufen können und sie daher nur verwirren.)
• Zum zweiten Punkt (Benutzergruppe per Parameter): Wie gesagt wäre so etwas sehr hilfreich, um bspw. Begrüßungsvorlagen für IPs oder Vorlagen, wie Vorlage:Benutzer besser anpassen und zwischen angemeldeten und nicht angemeldeten Nutzern unterscheiden lassen zu können. An sich sollte die Realisierung auch nicht wirklich schwer sein, denn bei GESCHLECHT geht es ja auch.

Grüße — Alleskoenner (Diskussion) 15:52, 28. Mär. 2013 (CET)

IPs können diese Seiten aufrufen. Formuliere die Hilfeseite, auf der solche Links vorkommen, einfach so, dass die Vorzüge einer Anmeldung klar werden. Das Selbe gilt für Begrüßungsvorlagen. Sofern es überhaupt sinnvoll ist, IPs zu begrüßen, sollten diese einfach die selbe Vorlage erhalten. Wir haben immer Wert darauf gelegt, dass jeder bei uns mitmachen kann. Mir ist klar, dass IPs in der Praxis anders behandelt werden als angemeldete Benutzer, aber ich halte es für nicht wünschenswert, diesen Graben durch technisch erzwungene Ausgrenzungen weiter zu vertiefen. Meine Meinung. Darüber hinaus möchte ich euch bitten, diese Diskussion, in der es nicht um die Verbesserung der Hilfeseite sondern um die Einführung einer neuen Funktion geht, woanders fortzusetzen. --TMg 16:29, 28. Mär. 2013 (CET)

Ach TMg, sei doch nicht immer so konservativ... Wenn du so argumentierst, brauchen wir auch adminonly nicht, denn man kann als Nicht-Admin diese Links zwar nicht gebrauchen, aber wenn man nur ausreichend darauf hinweist, ist das doch auch ok usw. Wir grenzen doch keine IPs aus, wenn wir ihnen Links oä. ausblenden, mit denen sie sowieso nichts anfangen können! Viel mehr verhindert man dadurch unnötige Verwirrung - so wie es bei adminonly ja auch gedacht ist. Es ist schon manchmal nervig, wie ablehnend hier viele gegenüber Neuerungen sind... Grüße — Alleskoenner (Diskussion) 16:50, 28. Mär. 2013 (CET)

Zwei Punkte: Zum einen geht du wie so oft großspurig über Aspekte hinweg, die über deinen eigenen Erfahrungshorizont hinaus gehen. Unangemeldete Benutzer können sehr wohl etwas mit den Links anfangen. Wenn jemand versehentlich unangemeldet auf seine Beobachtungsliste oder Benutzerseite zugreifen will, wird er an den Login erinnert, loggt sich ein und kann nahtlos weiter machen. Du willst ihm diese Möglichkeit entziehen. Darüber hinaus hinkt der Admin-Vergleich ganz gewaltig: Nicht-Administratoren daran zu erinnern, dass sie „nur“ Admin werden müssen, um auf bestimmte Funktionen zuzugreifen, wäre wirklich frustrierend. Admin wird man nicht mal eben so. Aber registrieren kann man sich in unter 1 Minute, und daran wollen wir (bzw. die Foundation) die unangemeldeten Benutzer stets erinnern. --TMg 18:49, 7. Jan. 2014 (CET)

Funktionen die sich auf andere Seiten beziehen - neue REVISION*-Funktionen

Seit Donnerstag gibt es neben der Variable auch die Parserfunktion REVISIONTIMESTAMP. Dort kann man einen beliebigen Seitennamen mitgebenn, wo dann der Zeitstempel von genutzt wird. Entsprechend für die anderen Variablennamen auch. Wo listet man diese Möglichkeiten am besten auf? Auf dieser Seite fehlen eigentlich auch die Parserfunktionen NAMESPACE und ähnlich, wo man auch einen Seitennamen mitgeben kann und dann entsprechend den Namensraum davon bekommt. Hat jemand eine Idee? Der Umherirrende 20:00, 15. Nov. 2013 (CET)

erledigtErledigt Raymond wars. Somit rledigt. Der Umherirrende 17:20, 21. Nov. 2013 (CET)

Dies geht auch bei anderen Funktionen, zum Beispiel REVISIONDAY/MONTH/YEAR, vermutlich sogar alle Seitenabhängige Variablen. Wäre da ein allgemeiner Hinweis à la „mit angeschlossen Doppelpunkt und darauf folgend dem Seitennamen können diese Funktionen auch für eine andere als die aktuelle Seite verwendet werden“ nicht besser? -- SuPich [Diskussion] [Beiträge] um 19:37, 27. Feb. 2016 (CET)

Letzter Edit

Kann man irgendwie den letzten Edit eines Artikelerstellers am Artikel bzw. im Allgemeinen per Variable ermitteln? –ðuerýzo ?! SOS 15:42, 5. Dez. 2013 (CET)

Nein, du kannst nicht auf die Beitragsliste (Spezial:Beiträge) eines Benutzers per Variable zugreifen, für Nicht-WMF-Wikis könnte es aber auch eine Extension auf mediawiki.org geben. Der Umherirrende 15:15, 6. Dez. 2013 (CET)

Auf die Beitragsliste selbst will ich ja gar nicht zugreifen, sondern nur auf die Versionshistorie von Artikeln. Ich will folgende "Abfrage":

• Benutzer A ist Ersteller des Artikels B
• C = Datum, an dem Benutzer A den Artikel B zum letzten Mal bearbeitet hat

So wie hier („Letzte Wirtsbearbeitung“). –ðuerýzo ?! SOS 15:42, 6. Dez. 2013 (CET)

Aso, aber auch hier gibt es keine Möglichkeit. Du kannst mit REVISIONUSER nur auf den Benutzer der gerade angeschauten Version zugrifen oder mit REVISIONUSER: auf die aktuellste Version einer anderen Seite. Der Umherirrende 17:57, 6. Dez. 2013 (CET)

Schade. –ðuerýzo ?! SOS 18:38, 6. Dez. 2013 (CET)

Weißraum bei DISPLAYTITLE oben

Wird die Funktion DISPLAYTITLE/SEITENTITEL oben in einen Artikel zur Veränderung des Seitentitels eingesetzt, so kann oben ein Weißraum, analog zu einer Leerzeile am Artikelanfang entstehen. Darum wird die Funktion gerne am Artikelende eingesetzt. Meiner Meinung nach wäre sie aber am Anfang besser, weil der Edit-Modus den Seitentitel unverändert darstellt: Als Konsequenz könnten Neulinge, die den Artikel editieren, über den plötzlich anderen Namen verwirrt sein - auf die Idee, ganz unten nach der Ursache zu suchen, kommen sie schwerlich. Gibt es daher zur Vermeidung des Problems eine Möglichkeit, diese 'Leerzeile' zu vermeiden? --KnightMove (Diskussion) 17:17, 7. Jan. 2014 (CET)

Der Seitentitel sollte immer ganz oben stehen, alles andere ist verwirrend. Die Leerzeile in n-Steiner entstand nicht (direkt) aufgrund des Seitentitels, sondern durch die Kombination mit der nachfolgenden Vorlage. Dort lässt sich das meist auch reparieren, was ich schon getan habe. --TMg 18:57, 7. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: TMg 18:57, 7. Jan. 2014 (CET)

Interwiki

Gibt es die Vorlagen unter Hilfe:Variablen#Zähler auch für andere Wikis? --Impériale (Diskussion) 01:23, 17. Sep. 2014 (CEST)

Ja, diese Vorlagen [wohl eher] Schlüsselwörter^{[WWB][WP-ANR]} (für Wiki[eigene/-innere]-Funktionen) sollten in jedem MediaWiki enthalten sein (siehe auch unter Spezial:Spezialseiten, etwa die Statistik – hier in der Wikipedia – oder auch im Wikiwörterbuch, ..oder Weitere auch unter Wikipedia:Schwesterprojekte). -- 3.4.2015, 12:39 (MESZ) (ohne Benutzername signierter Beitrag von 92.226.177.39 (Diskussion))

Tausendertrennzeichen

„{{formatnum:1234.56}} … Formatiert eine beliebige Zahl in der lokal üblichen Form, in der deutschsprachigen Wikipedia also mit Punkt als Tausendertrennzeichen (ab 5 Stellen, positiv) und Komma als Dezimaltrennzeichen.“ scheint nicht zu funktionieren: {{formatnum:8790}} in Marktheidenfeld (Marktheidenfeld) wird entgegen „Ein Tausendertrennzeichen wird in der Regel erst ab fünf Stellen gesetzt.“ (Wikipedia:Schreibweise von Zahlen#Tausender- und Dezimaltrennzeichen) mit Tausendertrennzeichen ausgegeben. Vgl. Wikipedia Diskussion:Lua/Modul/FormatNum#Parserfunktion --Peter Gröbner (Diskussion) 19:05, 6. Apr. 2015 (CEST)

Das ist eine Empfehlung und keine technische Restriktion..., wenn ich dich richtig verstehe. ↔ User: Perhelion 19:44, 6. Apr. 2015 (CEST)

Die Funktion der Parserfunktion widerspricht der „umseitigen“ Beschreibung oder umgekehrt die Beschreibung widerspricht der Ausführung der Funktion. --Peter Gröbner (Diskussion) 19:48, 6. Apr. 2015 (CEST)

Ist jetzt korrigiert. Der Umherirrende 11:40, 7. Apr. 2015 (CEST)

Super, danke! --Peter Gröbner (Diskussion) 11:43, 7. Apr. 2015 (CEST)

#property: und #statements:

Mit dieser Änderung vom Juli 2013 kam eine auskommentierte erste Beschreibung von {{#property:…}} auf diese Hilfeseite, die durchgehend nicht sichtbar ist. Können wir das ändern, und ggf. die Hilfebeschreibung aktualisieren? Neu ist im Übrigen das sehr ähnliche {{#statements:…}}, welches bei der Gelegenheit ebenfalls eingefügt werden könnte. Dessen Funktionsweise ist mir allerdings nicht nicht ganz klar… Viele Grüße, MisterSynergy (Diskussion) 09:34, 21. Dez. 2016 (CET)

Ergänzen: Ja klar. Zur Funktionweise siehe auch diese Beispielseite. — Raymond ^Disk. 10:09, 21. Dez. 2016 (CET)

Ja das habe ich gesehen, hilft mir aber noch nicht so recht. Das habe ich bei wikidata:Wikidata:Project chat#Parser function Statements enabled bereits kundgetan und man verspricht nun eine „echte“ Hilfeseite. Wir sollten hier aber auch was vorhalten, als Vorlagenprogrammierer möchte man sicher nicht erst bei Wikidata oder gar mediawiki.org rumsuchen, ob dort evtl. was brauchbares vorhanden ist. —MisterSynergy (Diskussion) 10:25, 21. Dez. 2016 (CET)

{{#property:}} habe ich nun mal sichtbar gemacht, und bei der Gelegenheit auch besser beschreiben. Verbesserungen sind gern willkommen! Zu {{#statements:}} kann ich was machen, wenn ich hinreichend informiert bin. —MisterSynergy (Diskussion) 14:23, 21. Dez. 2016 (CET)

Weiterleitung „Hilfe:Schlüsselwörter“

Hallo alle zusammen, also ich war gerade drauf und dran auf die Hilfeseite (nebenan) die Weiterleitung(en) „Hilfe:Schlüsselwörter“ (und zudem nebenher auch „Wikipedia:Schlüsselwörter“) anzulegen (siehe dazu ggf. auch allgemeiner das [also auch über das MediaWiki hinaus] u.a. wohl (in der auch sogenannten Programmierung) bekannte „Schlüsselwort“. Nebenher bemerkt, gibt es dazu auch schon die wohl einfach nur aus dem Englischen entlehnte (denglische) Weiterleitungen ‚[[Wikipedia:Magic Words]]‘ und ‚[[Hilfe:Magic Words]]‘. Gibt es dazu Gegenstimmen? ..also echte Gründe oder Begründungen, die gegen die Einführung der hier eigentlich heimatsprachigen Weiterleitungen sprechen. -- 9ai877, am 31.1.2017, 03:47 (MEZ)

• Zunächst ist es wunderschön und äußerst lobenswert, dass du erstmal anfragst, bevor du die Seite anlegst.
• In der Sache: Nein, eine neue Begriffsprägung „Schlüsselwörter“ ist absolut unerwünscht.
  • Es kommt auch umseitig überhaupt nicht vor.
  • Es existiert auch in der MediaWiki-Software kein Begriff key word.
  • Ich stecke ziemlich tief in der Materie, wüsste aber auch nicht, was jemand meinen würde, der das erwähnt, und wäre sehr erstaunt, wenn man mir als Beweis der Existenz ein solches Weiterleitungslink präsentieren würde.
• Der Präzedenzfall „Magisches Wort“ ist eher ein abschreckendes Beispiel.
  • Er kommt tatsächlich seit 2003 in der Software vor.
  • Dummerweise wurde er im Lauf der anderthalb Jahrzehnte von einzelnen Programmierern mit abweichender Bedeutung verwendet, so dass heutzutage niemand mehr weiß, was genau gemeint wäre, wenn der Ausdruck fällt. Es gibt wenige Leute, die verstehen einfach alles und jedes Element der Wikisyntax als magisch, auch Parserfunktionen und Variablen und Schalter und die ursprünglichen Magic Words.
  • Diese werden aber explizit umseitig aufgezählt und erwähnt, so dass eine Weiterleitung hierher legitim und geboten ist.
• Da nirgendwo definiert ist, was im komplexen Gefüge der Wikisyntax denn ein Schlüsselwort wäre und was nicht, würde die Einführung eines neuen scheinbaren Fachausdrucks niemandem helfen, sondern die Verständigung weiter erschweren.
• Die umseitigen Begriffe sind nicht Eindeutschungen von irgendwelchem Denglish, sondern fußen auf den in der Programmierung der MediaWiki-Software verwendeten Konzepten und den dafür benutzten Bezeichnungen.
• Ein WP:Schlüsselwörter heutzutage neu anzulegen wäre noch unerwünschter, weil unter dem Gesichtsfeld des Gesamtprojekts die Vokabel auch eine inhaltliche Verschlagwortung eines Artikel-Inhalts meinen könnte, oder Sortierschlüssel, oder Einträge in einem Glossar/Index, oder eine Art Hashtag-Kategorisierung, oder Vorlagenparameter, oder Lemmata, oder sonstwas.

LG --PerfektesChaos 10:18, 31. Jan. 2017 (CET)

Parserfunktionen fullurl: und fullurle:, canonicalurl: und canonicalurle:, localurl: und localurle:

Gemäß Hilfe:Variablen#fullurle ist als Besonderheit von fullurle: gegenüber fullurl: „URL-konform kodiert“ angegeben. Aus der Angabe geht jedoch nicht hervor, ob die Parserfunktion fullurle: – im Gegensatz zur Parserfunktion fullurl: – eine URL-konforme Kodierung vormimmt, so dass sich der Nutzer um diese keine Gedanken machen muss, oder ob sie vielmehr eine URL-konforme Kodierung als Eingabewert vorausetzt und diesen dann unverändert (und somit vor eventuellen Fehlinterpretationen bei der Umkodierung geschützt) weitergibt. Habe mal ein bisschen rumprobiert und dabei festgestellt, dass die Parserfunktionen fullurl: und fullurle: Parameter­werte im URL auf die gleiche Art und Weise weitergeben. Hier ein Beispiel mit Links auf den GeoHack unter Verwendung des OSM-GeoTemplates aus dem Meta-Wiki:

Die Parserfunktionfullurl: und die Parserfunktion fullurle: geben (für den URL-Parameter title) den Parameterwert „Köln“ ebenso wie den Wert „K%C3%B6ln“ so kodiert weiter, dass er innerhalb des URL als „Köln“ dargestellt wird, wenn sich der URL in der Adressleiste des Webbrowsers befindet; zugleich wird er in der GeoHack-Seite oben links innerhalb des blauen Bandes in weißer Schrift als „Köln“ wiedergegeben:
mit fullurl und Parameterwert Köln,
mit fullurle und Parameterwert Köln,
mit fullurl und Parameterwert K%C3%B6ln,
mit fullurle und Parameterwert K%C3%B6ln.
Kopiert man den URL in einen Editor, so wird der Wert des Parameters title in allen Fällen als „K%C3%B6ln“ dargestellt.

In Hilfe:Variablen#fullurle wird mithin ein Unterschied zwischen fullurl: und fullurle: postuliert, der nicht nachvollziehbar ist. Die betrifft gleichermaßen die Parserfuntionen canonicalurl: und canonicalurle: sowie localurl: und localurle:

Für diejenigen, die die Parserfunktionen nutzen möchten, wäre es eine Verbesserung, wenn laienverständlich dokumentiert wäre, worin genau der Unterschied zwischen der „normalen“ und der „+e“-Version dieser Parserfunktionen besteht, auf welche Weisen er sich bei der Anwendung bemerkbar macht und wie die Parserfunktion arbeitet/funktioniert. Idealerweise einschließlich einer Erläuterung der Vor- und Nachteile der Anwendung der einen oder andern Parserfunktion sowie ihrer jeweiligen Beschränkungen und Ausschlusskriterien für ihre Anwendung. Außerdem wäre es hilfreich zu wissen, was die Vor- und Nachteile der Verwendung der Parserfuntionen fullurl:, fullurle:, canonicalurl: und canonicalurle: gegenüber dem direkten Eintragen des URL in den Quelltext (Weblink) sind. Auch fehlt ein Hinweis, dass auch Interwiki-Links innerhalb dieser Parserfunktionen verwendet werden können. --X:: black ::X (Diskussion) 17:35, 3. Jul. 2017 (CEST), korrigiert 09:57, 16. Apr. 2018 (CEST)

Bemerkenswert ist, dass die englische Hilfe-Seite die Funktionen mit angehängtem "e" nicht kennt. --FriedhelmW (Diskussion) 21:53, 3. Jul. 2017 (CEST)

Vor zehn Jahren gab es mal einen wirksamen Unterschied.

Heute ist es einfach nur ein funktionierender Alias.

Bei historischer Konfiguration der Wiki-Server hatten die auf irgendwas mal empfindlich reagiert; das wurde inzwischen behoben und alle Formen werden akzeptiert.

Hatte meiner vagen Erinnerung nach auch was mit ungeschicktem Verhalten damaliger Browser zu tun gehabt; deshalb der Hinweis auf „URL-konform kodiert“, was in bestimmten Konstellationen erforderlich wurde.

LG --PerfektesChaos 11:59, 16. Apr. 2018 (CEST)

Ad PerfektesChaos: Danke für die Info. Weißt Du zufällig, ob dies bei mediawikiwiki:Talk:GeoHack#Difference between {pagename}, {pagenamee} and {pagename_gmaps} / between {title} and {titlee} auch so ist? {pagename_gmaps} wandelt vermutlich (im Gegensatz zu {pagename}) nicht-ASCII-Zeichen in ihre UTF-8-basierte URL-Kodierung um (macht also aus „ü“ „%C3%BC“). Viele Grüße --X black X (Diskussion) 17:57, 17. Apr. 2018 (CEST)

Sachverhalt mir nicht verständlich.

Mit einem angehängten „E“ kennzeichnen wir generell „encoded“, und das bedeutet dann:

• ohne E: Hänschen klein
• mit E: H%C3%A4nschen_klein
• FULLPAGENAME = Hilfe Diskussion:Variablen/Archiv/1
• FULLPAGENAMEE = Hilfe_Diskussion:Variablen/Archiv/1 mit _

Sowas ähnliches bedeutete das vor zehn Jahren bei fullurl:, wobei es hier aber um zwei Varianten der Kodierung in Spezialfällen ging; eine Art „Encoding des Encoding“.

Was da jemand bei deinen GeoHack meint, weiß ich nicht.

LG --PerfektesChaos 18:09, 17. Apr. 2018 (CEST)

Schaltflächen nicht klickbar

Auf der Seite Wikipedia:Redaktion Film und Fernsehen lassen sich in Kästen am Seitenbeginn mehrere Schaltflächen nicht anklicken. Das betrifft zum Beispiel die Bearbeiten-Schaltflächen in den Boxen Im Fokus – Film und Im Fokus – Fernsehen. In dieser deshalb geführten Diskussion kam die Vermutung auf, dass das ein Bug sein könnte, der in Verbindung mit fullurl und float:right steht. Kann das bitte jemand bald beheben? Vielen Dank im voraus!!!--Stegosaurus (Diskussion) 07:25, 12. Mai 2018 (CEST)

• fullurl: und damit die umseitig aufgelisteten Funktionen und damit auch diese Diskussionsseite hier haben mit der Angelegenheit absolut null und rein gar nichts zu tun.
• Verantwortlich ist vielmehr Vorlage:Portal-Kopf2 und deren Programmierung.
  • Dort wird zum einen mit <div> und zusätzlich mit position:relative; gearbeitet.
  • position: ist dafür bekannt, dass es permanent für Ärger sorgt, wenn es nicht sehr mit Bedacht und am Besten überhaupt nicht verwendet wird; schon mit relative wie hier, erst recht mit absolute und sowas nur dann, wenn man ganz genau weiß was man da tut und alle Anwendungsfälle genau vorhersehen kann.
  • Im vorliegenden Fall haben die Helden der Portal-Programmierung es durch Kombination von <div> und position:relative erreicht, dass der div-Block sich immer über die ganze Breite des Tabellenkopfes erstreckt.
• Im Zusammenspiel bei der RFF ergibt sich folgende Situation:
  1. Zuoberst vom Leser aus liegt ein div-Block in ganzer Breite des Tabellenkopfes mit der Überschrift.
  2. Darunter/dahinter und wegen gesetzter Transparenz des div-Blocks immer durchscheinend liegt der Bearbeiten-Link.
     • Er ist layoutmäßig von der Überschrift abgekoppelt worden und darf auch unterhalb der Beschriftung liegen.
     • Ein Klick auf „Bearbeiten“ wird vom darüberliegenden und nicht anklickbaren div-Block abgefangen. Damit ist der Link als solcher nicht mehr erreichbar, nur noch nett anzuschaun.
• Alles Weitere bitte nicht hier, sondern in der von vornherein zuständig gewesenen WP:VWS.

VG --PerfektesChaos 14:38, 12. Mai 2018 (CEST)

Danke für die ausführliche Antwort, ich habe jetzt auf WP:VWS angefragt.--Stegosaurus (Diskussion) 17:44, 12. Mai 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Stegosaurus (Diskussion) 09:04, 13. Mai 2018 (CEST)

Zauberwörter, Zauberworte, magische Wörter …

Warum darf die Weiterleitung Hilfe:Zauberwörter nicht erhalten (und gepflegt) werden und die Anderen (wie bspw. Hilfe:Zauberworte^[*] und …:magische Wörter) aber schon? -- 77.183.134.157 09:03, 20. Dez. 2018 (CET)

Wie schon mehrfach gesagt: „magischen Wörter“ kommt im Zielartikel vor, "Zauberwörter" nicht. --Logo 09:05, 20. Dez. 2018 (CET)

Stimmt, im gegenwärtigen (und zudem auch teilgesperrten) Zustand ist das richtig, aber vor einigen Tagen wurde die anliegende Hilfeseite schonmal dahingehend ergänzt, was euch anscheinlich auch nicht recht war, stattdessen wurde (und wird wahrscheinlich von euch auch weiterhin) hier ein Bearbeitungskrieg geführt, welcher (anscheinlich nur) die willkürliche Zerstörung bisher auch nützlicher Weiterleitungen zur Folge hatte. Andersrum könnte hier auch gefragt werden, warum die ähnlichen (je nach Sichtweise sinnvollen oder auch sinnlosen) Weiterleitungen zu den magischen Wörtern (oder auch denglisch ‚magic words‘, siehe bspw. auch [[Hilfe:Magic Words]], was ja genaugenommen so [also in dem haargenau selben Wortlaut] auch nicht im betreffenden Zielabschnitt vorkommt) weiter gehalten werden? -- 77.183.134.157 09:28, 20. Dez. 2018 (CET)

Im Übrigen gab es beide (heute gelöschten) Weiterleitungen schon einige Jahre, wobei „Hilfe:Zauberworte“ bereits am 3.1.2014 (durch Messerjokke79) angelegt wurde. -- 77.183.134.157 09:34, 20. Dez. 2018 (CET)

Nochwas deine Schnelllöschberündung, mit „Begriff kommt im Zielartikel nicht vor.“, ist sachlich falsch, denn der Begriff (gegenwärtig u.a. mit „allgemein der Bedeutungsinhalt einer Bezeichnung“) kommt sehr wohl (nach wie vor) auf der Zielseite (nebenan, u.a. mit dem Bezeichner „magische Wörter“) vor, er wurde lediglich anders (also mit einer anderen [und zudem umständlicheren] Wortverbindung) benannt. -- 77.183.134.157 09:56, 20. Dez. 2018 (CET)

Es gibt keinen Wiki-Fachausdruck „Zauberwörter“, und es gibt deshalb keinerlei Notwendigkeit, einen nicht existierenden Begriff auf einer Hilfeseite zu erwähnen, erst recht nicht ihm auch noch eine eigene Weiterleitungsseite zu spendieren.

• Die Wiki-Begriffswelt ist schon kompliziert genug, und man muss sie nicht noch verkomplizieren, indem neue Synonyme dazu erfunden werden.
• Der Fachausdruck heißt „Magisches Wort“ oder magic word und nichts sonst.
• Niemandem wird irgendwas erleichtert, wenn private Kreationen erfunden und dann auch noch dokumentiert werden. Es wird dadurch absolut kein wenig verständlicher; es wird nur Verwirrung geschaffen, wenn abweichende neue Vokabeln in den Raum geworfen werden, die einen abweichenden Sachverhalt vortäuschen.
• Deshalb sind auch irgendwelche unautorisierten Weiterleitungsseiten konsequent gelöscht worden; egal wie lange sowas schon in die Welt gesetzt wurde.
• Zusätzlicher Pflegeaufwand für Weiterleitungsseiten zu Begriffen, die es nicht gibt und nach denen niemand suchen kann ist kontraproduktiv, und vermüllen nur den Namensraum.
• Was für ein seltsamer Kreuzzug ist das eigentlich, dem Projekt durch freie Erfindung nicht existierender Fachausdrücke dienen zu wollen, und mit dieser Energie und dieser Beharrlichkeit auf Teufel komm raus seine Begriffsverwirrung durchsetzen zu müssen?

VG --PerfektesChaos 10:07, 20. Dez. 2018 (CET)

Achso, dann geht es hier (kurz gefaßt) eigentlich (auch wieder) nur um die Deutungshoheit oder was? Gut, da ihr hier ja offensichtlich am längeren Hebel sitzt, belasse ich es einfach dabei. Viel Spaß dann noch, beim (rückschrittlichen) denglisieren oder auch bevormunden (unter dem Vorwand, das Wikisprech vorgeblich einfach[er] zu halten). Im Übrigen wäre es meiner Ansicht nach eigentlich besser oder auch vernünftiger, auf einen derartigen (Zauber- oder auch Magie-)Begriff hier möglichst ganz zu verzichten, dann würde nämlich auch eben die Zauberei (oder die gleichbedeutende Magie) wohl eher mal der Vernunft weichen. -- 77.183.134.157 10:26, 20. Dez. 2018 (CET)

Mimimi. LG, ℳ웃79 13:18, 24. Dez. 2018 (CET)

Funktionen: Raute oder keine Raute

Ich komme bei den Funktionen immer wieder bzgl. der Schreibung mit oder ohne vorangestellter Raute durcheinander. Wieso heißt es beispielsweise {{#formatdate:, aber {{formatnum:? Oder {{canonicalurl:, aber {{#special:? Das erscheint mir nicht konsistent gelöst, oder ich sehe die Logik dahinter nicht. Oder hat das einfach historische Gründe? -- hgzh 10:59, 20. Feb. 2019 (CET)

Das entstammt verschiedenen Paketen verschiedener Zeiten:

• Die weitaus überwiegende Zahl der Funktionen, die es meist auch von Anfang an gegeben hatte, wird ohne Dingens geschrieben. Sie gehören zum core, und auch alle neuen core-Parserfunktionen schreiben sich ohne.
• Ein besonderes Paket mit Berechnungen, das im März 2006 allen WMF-Wikis zugeschaltet wurde, hatte seine Funktionsnamen einheitlich vergittert und dadurch vom Parser-core abgegrenzt. Fremde Wikis außerhalb der WMF haben diese Extension ggf. nicht aktiviert.
• Spätere Extensionen wie #invoke übernahmen diese Unterscheidung.

Damit werden auch Namenskonflikte unterbunden: Wenn die mit ohne, also der core, in alle Sprachen übersetzt werden, können sie niemals mit einem Bezeichner aus den optionalen Extensionen kollidieren, und die Extensionen müssen ihren Namensraum untereinander klären.

Für den Autor innerhalb der WMF ist es relativ egal; bei Export und Übernahme in externe Wikis aber sehr hilfreich bei Interpretation der Fehlermeldungen.

HGZH --PerfektesChaos 11:13, 20. Feb. 2019 (CET)

Also eine Sache von Core und Extensions. Merci für die Aufklärung. Gruß, -- hgzh 16:17, 20. Feb. 2019 (CET)

ü→ue

Irgendwie benötige ich mal kurz etwas, dass Umlaute umschreibt, aber nicht von Uraufführung in Urauff%C3%BChrung oder Uraufführung sondern in Urauffuehrung. Gab es das nicht irgendwo?

• Uraufführung. In: Jacob Grimm, Wilhelm Grimm (Hrsg.): Deutsches Wörterbuch. 16 Bände in 32 Teilbänden, 1854–1960. S. Hirzel, Leipzig (woerterbuchnetz.de).  N
• Urauffuehrung. In: Jacob Grimm, Wilhelm Grimm (Hrsg.): Deutsches Wörterbuch. 16 Bände in 32 Teilbänden, 1854–1960. S. Hirzel, Leipzig (woerterbuchnetz.de).  J

Ich meine ich könnte eine doofe Schachtel bauen die nach [ä ö ü] sucht und [ae oe ue] zurückgibt aber mir was so als gäbe es irgendwo eine einfachere Lösung. --Liebe Grüße, Lómelinde Diskussion 17:16, 28. Mär. 2019 (CET)

Mir fällt da nur Vorlage:Str replace ein. Gruß --FriedhelmW (Diskussion) 17:24, 28. Mär. 2019 (CET)

Na, das soll ja durchs ganze Alphabet gehen.

Tlatin@Sort Urauffuehrung

LG --PerfektesChaos 17:42, 28. Mär. 2019 (CET)

Ich wusste doch, dass du weißt, wo ich so etwas finden kann. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 17:47, 28. Mär. 2019 (CET)

API für Variablen wie NUMBEROFARTICLES?

Gibt es eine API um z.b. die NUMBEROFARTICLES auf einer anderen Seite anzuzeigen um so auf Wikipedia aufmerksam zu machen? --Riepichiep (Diskussion) 08:00, 29. Jun. 2019 (CEST)

@Riepichiep: Ja. Mehr. WP:API – LG --PerfektesChaos 13:15, 29. Jun. 2019 (CEST)

fullurl - klickbare URL

fehlen bei Hilfe:Variablen#Funktionen bei fullurl in der Anweisung die eckigen Klammern damit die URL klickbar wird - so wie es im Codebeispiel im Quelltext auch gemacht wird? --Mrmw (Diskussion) 12:43, 21. Okt. 2020 (CEST)

@Mrmw: gut beobachtet. De erste Spalte „Anweisung“ würde ich so lassen wie sie ist, weil es eben das magische Wort als solches ist. In der letzten Spalte „Anwendungsbeispiel, Bemerkungen “ könnte man das sicherlich so umsetzen: Syntax mit Verlinkungsklammern, dann das Ergebnis in einer 2. Zeile, wie jetzt schon vorhanden. Wer ist „man“? Du? :-) — Raymond ^Disk. 13:07, 21. Okt. 2020 (CEST)

Bitte nichts dazubasteln.

Die eckigen Klammern haben mit dem Thema dieser Seite absolut null zu tun.

Hier geht es darum, dass alle diese (drei plus) Funktionen eine URL zu der Seite liefern.

Was dann irgendjemand hinterher mit dieser URL anfängt, sie als Parameter einer Vorlage übergibt, sie offen in den Wikitext schreibt, oder mittels eckiger Klammern anklickbar und beschriftet gestaltet ist ein völlig anderes Thema und hat rein gar nichts mit der umseitigen Seite zu tun, würde nur verwirren.

Wenn eine URL offen im Wikitext steht, wird sie nur dann klickbar, wenn auch ein Protokoll vorhanden ist. Hier, bei fullurl:, ist sie „protokoll-relativ“, und dann ist auch noch nichts mit Klicken. Das wird auf H:Links erläutert und ist eine ganz andere Syntax.

VG --PerfektesChaos 13:21, 21. Okt. 2020 (CEST)

@PerfektesChaos, Raymond: ich will hier nichts verbasteln - ich bin auch ein Freund der Übersichtlichkeit - ich konnte nur nicht verstehen was ich falsch mache, dass meine Anwendung von fullurl nicht klickbar war.

von der anderen Seite kommend müsste die Frage lauten, wieso ist das Anwendungsbeispiel rechts klickbar? dann fände ich es logischer, wenn es dort nicht klickbar ist, also ohne [], und sich der User dann überlegt, was er weiter tun will bzw. muss, um die URL als Text beispielsweise klickbar zu machen

mich hat die Differenz zwischen dem Code links und dem Anwendungsbeispiel irritiert - musste in Quelltext schauen um Klarheit zu bekommen --Mrmw (Diskussion) 14:45, 21. Okt. 2020 (CEST)

Weil das vor neun Jahren mal jemand zusätzlich klickbar gemacht hatte.

Bislang war das niemandem aufgefallen, und den sonstigen Leutchen war der Hintergrund klargewesen. Mit dem VisualEditor ist den künftigen Benutzern aber die Klammersyntax gar nicht mehr so einleuchtend.

Wenn es dich verwirrt hat, sollte der Zusatzeffekt wieder eliminiert werden.

Sinn der Seite ist es, das Resultat darzustellen, das die entsprechende Parserfunktion liefert. Da muss nichts klickbar sein. Wenn die canonicalurl benutzt wird, ist es zufällig direkt klickbar (könnte man sogar umseitig unterbinden); die localurl ist es auch nicht und da käme auch niemand drauf.

Der ganze Themenkomplex ist mir sowieso schon seit vielen Jahren ein Dorn im Auge: Es stehen nicht alle Parserfunktionen drauf, weil einige erst im März 2006 hinzukamen, was aber für die Anwender völlig egal ist, dafür stehen mit #property: und #invoke: usw. welche dabei, die erst in diesem Jahrzehnt neu hinzukamen. Die Seite ist sehr unübersichtlich, hat keine Gesamtnavigation. Schon der Name ist traditionell falsch; es gibt überhaupt keine „Variablen“; es gibt nur Parserfunktionen und nichts anderes.

Was ich auf keinen Fall möchte, wäre eine Ergänzung um Sachen, die hier nicht hergehören, und damit noch komplizierter und unübersichtlicher; eher eine Reduzierung, Vereinfachung, ggf. Aufteilung auf mehrere Seiten zu jeweils einem Themengebiet, dieses dafür ausführlicher soweit das auch Thema wäre, und einen Gesamtindex für alles.

VG --PerfektesChaos 15:39, 21. Okt. 2020 (CEST)