Overleg MediaWiki:Common.js

Hallo. Artikels wat met kleinletters begin kan nou met {{DISPLAYTITLE:tItel}} getag word, bv. {{DISPLAYTITLE:iTunes}}. Daar is dus 'n hele stuk onnodige JS wat uit die common.js gehaal kan word.► AdriaanZA ( Overleg ♥ Bijdragen ) ♪♫ 1 dec 2007 11:26 (CET)

Ik denk dat je gelijk hebt, en ik zal er een moderator op attenderen. Scheelt weer 89 regels code... ;-) - Erik Baas 2 dec 2007 00:20 (CET)

 Uitgevoerd - WebBoy Jelte 2 dec 2007 14:07 (CET)

Toevoegen van een paar handig functies van commons

/** extract a URL parameter from the current URL **********
 * From [[en:User:Lupin/autoedit.js]]
 *
 * paramName  : the name of the parameter to extract
 *
 * Local Maintainer: [[User:Dschwen]]
 */
 
function getParamValue( paramName ) 
{
 var cmdRe=RegExp( '[&?]' + paramName + '=([^&]*)' );
 var h = document.location.href;
 var m=cmdRe.exec(h);
 if (m) {
  try {
   return decodeURIComponent(m[1]);
  } catch (someError) {}
 }
 return null;
}
 
/** &withJS= URL parameter *******
 * Allow to try custom scripts on the MediaWiki namespace without
 * editing [[Special:Mypage/monobook.js]]
 *
 * Maintainer: [[User:Platonides]]
 */
{
 var extraJS = getParamValue("withJS");
 if (extraJS)
  if (extraJS.match("^MediaWiki:[^&<>=%]*\.js$"))
   importScript(extraJS);
  else
   alert(extraJS + " javascript not allowed to be loaded.");
}

Ik stel voor om bovenstaande code toe te voegen. De code komt van commons:MediaWiki:Common.js en is ook in gebruik in mijn monobook.js.

• De functie maakt het mogelijk om makkelijk variablen die in de url zijn meegegeven te ontleden
• withJS maakt het mogelijk om javascript in een url te laden, zie commons:Template:Check categories voor een voorbeeld

Op dit moment maakt MediaWiki:Quick-delete.js en MediaWiki:AddCoordinates.js al gebruik van deze code. Multichill 19 okt 2008 23:42 (CEST)

Wat zijn de voordelen? Zelf denk ik niet dat er veel gebruikers die vaak de variabelen in de url ontleden of js in een url laden, maar onbekend maakt onbemind. Niet dat ik een bezwaar zie om de code toe te voegen en ik waardeer je oproep tot overleg, gewoon plaatsen van de code had waarschijnlijk niemand opgemerkt. Of zijn de gevolgen wellicht voor iedereen merkbaar? Troefkaart 20 okt 2008 09:59 (CEST)

Dit zijn twee ondersteunende functies waar andere hulpmiddelen dan weer gebruik van maken, zie bovengenoemde voorbeelden. Multichill 21 okt 2008 19:03 (CEST)

Ik zie geen probleem met de code, wel dat "(Local) Maintainer" in het commentaar is blijven staan. Bij beide functies wordt dit script op deze wikipedia niet door de genoemde gebruiker onderhouden. ∼ Wimmel 21 okt 2008 19:41 (CEST)

wpDeletereason_clear()

Dit vind ik bijzonder ongewenst. Ik kon nog net de neiging onderdrukken om de toevoeging direct te reverten. Er zijn genoeg momenten geweest dat een moderator de samenvatting inderdaad had moeten aanpassen, maar dan moet men simpelweg beter opletten. De standaardsamenvatting is erg handig en daar moet je maar mee om kunnen gaan. In het ergste geval kun je een steward vragen een logboekvermelding te verbergen. --Erwin 3 jun 2009 21:28 (CEST)

Eens met Erwin: je moet gewoon goed opletten. Nu krijg je dat je van "onschuldige" verwijderingen de delete reason apart moet gaan achterhalen, indien je die wilt weten. Wel zou het handig zijn als er een knop was waarmee je de delete reason in één keer kunt blanken. Wutsje 3 jun 2009 21:47 (CEST)

• Een groot deel van de moderatoren leegt de delete-reasons niet wanneer deze beledigende informatie bevat
• Het is onredelijk om voor elk geval een steward raad te plegen, die hier aanzienlijke handelingen voor moet verrichten om deze samenvattingen te verbergen (zo heb ik zelf ondervonden)
• In veel gevallen verbergen we ze helemaal niet, omdat er niemand is die de moeite doet om erover te klagen
• Voorbeelden van samenvattingen die volstrekt ongewenst zijn: [1], [2], [3]
• In de meeste gevallen is het onnodig om de oude inhoud in de bewerkingssamenvatting weer te geven. Op diverse Wiki's wordt dit - juist om dit soort taferelen te voorkomen - al niet meer gedaan. In principe moet de verwijderreden zelf voldoende indicatie geven van de oorzaak voor verw4ijderen
• In gevallen waarbij het wel zinvol is om de samenvatting weer te geven, kan er op Herstel gedrukt worden om deze toch terug te zetten, maar waarom dat in de vele gevallen wenselijk is, is mij niet duidelijk.
• Als het op minder weerstand stuit, zou er eventueel ook voor gekozen kunnen worden om een wis knop neer te zetten in plaats van een herstel knop. Groet, nl:Mark W (Mwpnl) ¦ talk 3 jun 2009 22:22 (CEST)

Graag ja. Nu moet ik elke keer op twee knopjes klikken om een bestand te verwijderen op de manier waarop ik vind dat het hoort: zo transparant mogelijk. Dat veel moderatoren de samenvatting niet wissen indien dat wel gewenst is, is niet iets dat met technocratische middelen zou moeten worden aangepakt en indien wel, kies dan voor een systeem dat je uit kunt zetten, net zoals dat kan met de waarschuwing voor een lege bewerkingssamenvatting. Ik heb er een enorme hekel aan om gedwongen te worden tot een manier van werken waarvan ik zelf het nut niet inzie (élke verwijderde pagina heeft per definitie "geen zinvolle inhoud", dat zegt helemaal niets). Geef iedereen dan tenminste de optie om het op zijn of haar eigen manier te doen. · Wutsje 4 jun 2009 03:58 (CEST)

@Mwpnl: de voorbeelden die je geeft zijn nu niet bepaald voorbeelden die mij zouden overhalen (of iig 2 vd 3), en om die redenen zou ik ook niet bepaald voor zijn. Als dit af en toe voorkomt, bad luck. Waar het vervelender wordt is wanneer het privacygevoelige informatie betreft. Daarvan is iedere fout er een teveel. Het voordeel is hier wel dat de moderator 9/10 keer direct na het op de knop drukken volgens mij al bedenkt " ohja, shit, die had ik moeten leeghalen", en dus evt een steward kan raadplegen.

Hebben we enig zicht op percentages? Hoe vaak is het nodig dat de samenvatting leeggehaald moet worden? Hoevaak daarvan gaat het fout? Met andere woorden: Hoe hard is het precies nodig? Effeietsanders 5 jun 2009 16:22 (CEST)

Geef mij de oude werkwijze maar. EdBever 6 jun 2009 07:43 (CEST)

Per eia, het risico dat er iets staat dat de privacy schendt, is veel groter dan het voordeel dat je zou kunnen halen uit het laten staan van de standaard inhoud. Bovendien staat in de standaard inhoud vaak nonsens waarin niemand geïnteresseerd is, zoals bij bv. geklieder. Houden zoals het nu is. Annabel_(overleg) 6 jun 2009 09:06 (CEST)

Ik voel het allemaal vooral als paternalistisch gedoe en sluit me aan bij alle voorgangers die terug willen naar de oude situatie. Eigenlijk is het een impliciete belediging. Het ergste vind ik evenwel dat er nu per definitie "geen zinvolle inhoud" staat. En dan moet je bedenken of je eerst wil herstellen en dan aanpassen, en niet andersom, want anders staat er ineens niets meer. Onhandig. Lymantria _overleg 6 jun 2009 15:25 (CEST)

Hoezo waarin niemand geïnteresseerd is? Bron? Als je wilt weten waarom een pagina is verwijderd (omdat je wilt weten waarom dat werkelijk is gebeurd, omdat je op zoek bent naar een bepaalde vorige versie, omdat je wilt weten met welk type vandaal je te maken hebt, whatever) is het stomvervelend om alle eerder verwijderde versies stuk voor stuk te moeten openen. Het punt is hier dat bij het verwijderen van een pagina kennelijk niet iedereen altijd te werk gaat met de zorgvuldigheid die van een moderator mag worden verwacht. Om dat "op te lossen" op een dergelijke paternalistische wijze (want dat is inderdaad het woord) gaat me veel te ver, ook al omdat het met het ten onrechte niet weghalen van de bewerkingssamenvatting werkelijk wel meevalt (zie bijvoorbeeld deze 500 willekeurige verwijderingen van voor dit werd doorgedrukt). Als dit zo blijft, dan kun je trouwens álle verwijderredenen in het deletereason-dropdown-menu wel opdoeken. Wutsje 6 jun 2009 15:50 (CEST)

De duidelijkste samenvatting is nog altijd degene die je zelf invult. Dat heeft niet met paternalisme te maken. De link naar het verwijderlogboek die je geeft is trouwens heel treffend voor de onduidelijkheid die het laten staan van de artikelinhoud in de verwijderreden, schept bij het trachten te lezen van het verwijderlogboek. Annabel_(overleg) 6 jun 2009 16:31 (CEST)

Nee, dan overal "geen zinvolle inhoud", dát is duidelijk. Pff... Wutsje 6 jun 2009 16:40 (CEST)

En als we in lijn met bovenstaande suggesties en deze opmerking, niet standaard "Geen zinvolle inhoud" laten staan, maar gewoon de standaard "Andere reden", om op die manier moderatoren uit te nodigen een duidelijke omschrijving in te toetsen? Het is wellicht ook een idee om onze lijst met redenen eens te verduidelijke met écht heldere meldingen? nl:Mark W (Mwpnl) ¦ talk 9 jun 2009 15:48 (CEST)

Wat mij betreft wordt - net als bijvoorbeeld op Commons en Meta - "Andere reden" standaard en blijft de samenvatting staan. Een knop waarmee die samenvatting met één klik leeggehaald kan worden lijkt me echter wel nuttig. Met betrekking tot het deletereason-dropdown-menu: dat mag inderdaad wel eens wat gestroomlijnd worden. Wie bijvoorbeeld een reden als "Aanstootgevende inhoud" aanklikt zegt daarmee al gauw meer over zichzelf dan over de inhoud van de verwijderde pagina. Het verdient in ieder geval aanbeveling om er eens wat linkjes aan toe te voegen (bijvoorbeeld naar WP:AUT bij "Auteursrechtenschending" en naar WP:Z bij "Experimenteerpagina" - vgl. de menu's op Commons en Meta). Wutsje 10 jun 2009 17:25 (CEST)

Ah, Op Commons heb ik blijkbaar een script aanstaan dat de samenvatting automatisch leegt daar (ik was in de veronderstelling dat dat daar standaard was). Is het dan een idee om:

• Standaard andere reden aan te laten en de verwijdersamenvatting te laten staan;
• De knop herstel te vervangen door wissen en daarbij ook direct Geen zinvolle inhoud te kiezen, tenzij er al een andere reden is aangeklikt
• De redenen goed onder handen te nemen, uit te breiden en van linkjes te voorzien (zoals dat op Commons en Meta heel gebruikelijk is bijvoorbeeld)

In de tussentijd verwijder ik het huidige script. nl:Mark W (Mwpnl) ¦ talk 10 jun 2009 17:54 (CEST)

Het kan ook zijn dat je bij de gadgets van je Commons-prefs "Clean Delete Reasons" hebt aangevinkt. Wutsje 10 jun 2009 18:04 (CEST)

dat was inderdaad het script wat ik bedoelde ;-) nl:Mark W (Mwpnl) ¦ talk 10 jun 2009 18:24 (CEST)

import

Deze functies zijn niet langer nodig. Ze zijn onderdeel van wikibits nu. TheDJ 8 aug 2009 01:20 (CEST)

Ik heb ze weggehaald. Dankje, Erwin 9 aug 2009 19:03 (CEST)

SVG images: adds links to rendered PNG images in different resolutions

Sorry for writing in English. Many users are not familiar with using SVG images available on Wikipedia/Commons in office applications, etc. This is particularly true, if the base size is small (example). Therefore, I suggest adding links to rendered PNG images in different resolutions to the file description page (see same example in en.wikipedia). The script was first implemented on Commons and in de-wikipedia, then in en.wikipedia. I originally had the idea, Commons:User:Slomox did the coding and en:User:TheDJ made some refinements. It is available at en:MediaWiki:Common.js/file.js. --Leyo 13 nov 2010 01:46 (CET)

http(s) google

Hoi, kan iemand googleSearch += '<form method=get action="http://www.google.nl/search">'; zo aanpassen dat het https is als ik over https op Wikipedia zit? Nu krijg ik een foutmelding (niet-beveiligde pagina enzo). Dank je, Multichill (overleg) 2 dec 2012 10:57 (CET)

 Uitgevoerd, diff #39078895. –Krinkle 30 sep 2013 20:09 (CEST)

Link FA

Voor oncyclopedia wouden wij ook de uitgelichte artikelen in andere talen hebben bij de interwiki's. We hebben maar wat gecopypaste, maar het werkt nog niet zo goed. Zou iemand van jullie zo vriendelijk willen zijn om mij uit te leggen wat je hier en in de .css moet veranderen? Alvast bedankt, Tiz (overleg) 21 jan 2013 18:35 (CET)

Je moet in ieder geval een sjabloon zoals Sjabloon:Link FA op de pagina gebruiken. Die zorgt ervoor dat de link naar een uitgelicht artikel voor de Javascript (en CSS) herkenbaar is. Waarschijnlijk kun je het beste http://en.uncyclopedia.co/wiki/Template:Link_FA gebruiken, en de functie linkFA() uit http://en.uncyclopedia.co/wiki/MediaWiki:Common.js. Dat zal beter werken dan 'ons' script, omdat de instellingen van uncyclopedia.co waarschijnlijk niet precies hetzelfde zijn als van wikipedia.org. MrBlueSky (overleg) 21 jan 2013 20:22 (CET)

Daar waren wij (allez, diegene die het heeft geplaatst) daar rekening mee heeft gehouden, maar zonder succes. Misschien heeft het iets te maken met ons ietwat oudere versie van MediaWiki, of ons gebrek aan extensies ervan. Maar toch, andere instellingen of niet, zouden wij graag willen weten hoe het bij jullie zit. En de sterafbeelding is bij ons ook anders, en een klein foutje op een parodie kunnen wij ons natuurlijk niet veroorloven :D! Maar dus, ik zou graag willen horen hoe het hier zit, zodat we dat ook kunnen uitproberen! Tiz (overleg) 22 jan 2013 20:29 (CET)

Hallo? Tiz (overleg) 25 jan 2013 20:28 (CET)

Hoi! ;-)

Je moet in ieder geval een sjabloon als Sjabloon:Link FA hebben, met deze regel (de rest is niet nodig):

<includeonly><span id="interwiki-{{{1}}}-fa" class="FA"></span></includeonly>

Als je dat sjabloon dan op een (test)pagina bij jullie kunt zetten ({{Link FA|en}}) en een link geeft, dan is het wat makkelijker om uit te zoeken wat er fout gaat en hoe dat aangepast kan worden. MrBlueSky (overleg) 25 jan 2013 21:59 (CET)

Ja, dat hebben we al lang. Maar nogmaals: hoe zit jullie code in elkaar? 87.64.118.17 27 jan 2013 20:42 (CET)

oei, vergeten aanmelden :P! Tiz (overleg) 28 jan 2013 19:35 (CET)

Je moet waarschijnlijk dit in jullie Vector.css:

li.FA { list-style-image: url("http://images.uncyc.org/nl/1/1e/SterFA.png") !important; }

vervangen door:

#mw-panel div.portal div.body ul li.FA {
  background: url("//upload.wikimedia.org/wikipedia/commons/thumb/6/66/Fairytale_bookmark_gold.svg/10px-Fairytale_bookmark_gold.svg.png") no-repeat 0% 0%;
  margin-left: -1.25em;
  padding-left: 1.25em;
}

zoals in MediaWiki:Vector.css. MrBlueSky (overleg) 28 jan 2013 23:21 (CET)

Bedankt! Ik zal dadelijk een admin vragen om dit te doen! Tiz (overleg) 14 feb 2013 13:49 (CET)

Link GA/FA

Zou het niet beter zijn de alt-tekst te veranderen in dit is een goed artikel/etalage-artikel in deze taal en niet in een andere taal? Een andere taal verwijst niet direct naar de taal waar het naast staat, deze taal wel. Op andere wiki's, zoals de Engelse, heb ik net gezien, is het ook zo. —mountainhead / ? 3 jul 2013 15:23 (CEST)

Correctie tekst

Kan iemand alsjeblieft de volgende regels aanpassen?

	var collapseCaption = 'verberg';
	var expandCaption = 'toon';

Naar:

	var collapseCaption = 'verbergen';
	var expandCaption = 'weergeven';

Dit is meer in lijn met de vertalingen van MediaWiki. Dank. Siebrand 22 sep 2013 16:19 (CEST)

 Uitgevoerd, diff #39078886. –Krinkle 30 sep 2013 20:08 (CEST)

Ter documentatie: jQuery UI loader

Omdat bepaalde code gisteren niet meer bleek te werken als gevolg van een softwarewijziging is na overleg met de developers met deze edit de code toegevoegd om het weer te laten werken. (Er zit een vertraging in de tijd waarin dit soort code updatet is.) De gebruikte code is onder andere toegepast op de pagina's van Wikipedia:Start. Romaine (overleg) 2 dec 2013 02:36 (CET)

Give search results even when page doesn't exist

Screenshot of the Earth test search, with this script adding links to Wikidata, Reasonator, Commons, and Wikipedia.

Hello, I propose to enable the tool created by Magnus Manske (creator of MediaWiki) to provide results from other languages and Commons (via Wikidata) when a page doesn't exist here: links are added to Special:Search and noarticletext. This helps to encourage translation and to make readers use your wiki more, because they can be sure to find something even if it's not local (rather than searching directly on the biggest wiki). The Italian and Polish Wikipedias, among others already enabled it by default.
Examples: [4] [5] [6]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:Wdsearch_script_screenshot.png]]
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ||  ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgCanonicalSpecialPageName' ) === false ) ) {
	importScriptURI("//en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&ctype=text/javascript");
}
--[[m:User:Nemo_bis|Nemo]] ~~~~~ ([[w:en:MediaWiki talk:Wdsearch.js|comments, translations and last instructions]])
</div>
<!-- EdwardsBot 0661 -->

Announced JavaScript change for badges implementation

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene* (overleg) 18 aug 2014 22:29 (CEST)

Dit is in verband met Verhuizing ster-icoontjes in interwikilijst naar Wikidata. Romaine (overleg) 27 aug 2014 06:21 (CEST)

Extra sorteerwijze

Op diverse plaatsen in onze Wikipedia gebruiken we gegevens in tabellen en bieden we de gebruiker de mogelijkheid om deze gegevens te sorteren. Vaak gaat dat goed, soms laat het sorteren een ongewenste sortering achter. data-sort-type="number" dwingt de parser om de gegevens als numeriek te beschouwen, waardoor '10' niet tussen '1' en '2' komt te staan. Alle niet-numerieke waarden worden als 0 beschouwd en komen dan op die plaats in de sortering terecht.

Via wat links kwam ik op deze pagina terecht, waar wordt uitgelegd hoe een extra sorteerwijze gedefinieerd kan worden. Volgens mij kom ik dan tot deze code om met data-sort-type="plaatsing" te bereiken dat de met '-', '*' en '?' aangeduide waarden onderaan komen te staan.

   $.tablesorter.addParser({ 
       // set a unique id 
       id: 'plaatsing', 
       is: function(s) { 
           // return false so this parser is not auto detected 
           return false; 
       }, 
       format: function(s) { 
           // format your data for normalization 
           return s.replace(/-|\*|?/,MAX_VALUE); 
       }, 
       type: 'numeric' 
   }); 

Met deze code staan ze door elkaar, eventueel kan dat voorkomen worden door iets als

   $.tablesorter.addParser({ 
       // set a unique id 
       id: 'plaatsing', 
       is: function(s) { 
           // return false so this parser is not auto detected 
           return false; 
       }, 
       format: function(s) { 
           // format your data for normalization 
           return s.replace(/\*/,MAX_VALUE).replace(/-/,MAX_VALUE-1e+300).replace(/?/,MAX_VALUE-2e+300); 
       }, 
       type: 'numeric' 
   }); 

Deze code kan desgewenst uitgebreid worden, zodat bijvoorbeeld Formule_1_in_1987#Uitslagen_coureurs ook een sorteerbare tabel zou kunnen worden.

Heeft er iemand bezwaar tegen het opnemen van een van beide codevoorstellen, eventueel in aangepaste vorm, in Common.js? Alvast bedankt voor jullie reactie. Met vriendelijke groet, RonnieV (overleg) 7 jan 2016 00:00 (CET)

Ik heb het niet getest, maar heb wel een paar vragen, die wellicht een inkopper kunnen zijn, maar voor de zekerheid toch even gevraagd.

1. Waar worden de velden met '-', '*' en '?' dan nu geplaatst bij het sorteren? (vraag voor alle bestaande sorteersleutels)
2. En als ze verkeerd in de tabel getoond worden, is er geen enkele reeds bestaande sorteersleutel die ze onderaan plaatst? Of is het niet een probleem met een of meer van de sorteersleutels dat in MediaWiki zelf aanpassing nodig heeft?
3. Heel veel tabellen en codes worden 1 op 1 gekopieerd vanaf een andere Wikipedia, meestal de Engelstalige. Heeft men op en-wiki hier al niet code voor geïmplementeerd? (Dit om te voorkomen dat we straks met twee losse naast elkaar staande sorteersleutels zitten die niet uitwisselbaar zijn tussen wiki's.)
4. Als dit een probleem is met de verschillende reeds bestaande sorteersleutels die gebruikt kunnen worden, kan de hierboven voorgestelde code dan niet toegevoegd worden aan een reeds bestaande sorteersleutel, zodat gewoon een reeds bestaande gebruikt kan worden, in plaats van een nieuwe aangemaakt wordt?

Ik ben niet tegen eventuele invoering, maar omwille van compatibiliteit zou het toevoegen van een geheel nieuwe sorteersleutel pas moeten gebeuren als alle andere opties uitgesloten zijn. (Deze vragen stel ik ook, omdat de onhandigheden van het zelf instellen van codes voor tabellen (class) na 10 jaar nog steeds een probleem is.) Romaine (overleg) 7 jan 2016 00:19 (CET)

Hoi Romaine, bedankt voor je terechte vragen.

1) Het meest in het oog springende gebruik is momenteel Lijst van Radio 2-Top 2000's, waar in ieder geval de '-' en '*' gebruikt worden. De betreffende pagina is nu al fors om te bewerken, en als daar een dikke 34.000 keer 9999 - geplaatst moet worden, helpt dat de omvang van de pagina zeker niet.

2) Ik heb niet alle mogelijkheden geprobeerd die genoemd worden op m:Help:Sorting#Forcing the sort mode for a column. text is duidelijk niet gewenst, omdat '10' dan tussen '1' en '2' komt te staan. 'number' zet deze tekens voor de 1. Beter dan text, maar nog niet afdoende. De code voor 'currency', zoals aangegeven op [7] voldoet ook niet.

    De keuze om niet-numerieke waarden naar 0 te vertalen is in veel gevallen niet per se verkeerd, maar hier is het ongewenst. Het zijn best veel waarden, en het meer zinvolle deel komt dan onder die reeks te staan. De functie FormatDigit verzorgt deze vertaling en wordt onder meer aangeroepen bij de addParser met het id 'number'. Ik kan ook prima leven met een addParser op dat niveau, bijvoorbeeld met 'numberfirst', die een eigen FormatDigit aanroept waarin voor isNaN MAX_VALUE geretourneerd wordt, in plaats van 0.

3) In en:MediaWiki:Common.js zoeken naar addParser levert mij niets op. Ik weet niet of ze nog andere js-bestanden hebben die ook breed ingezet worden.

4) Logisch gezien zou er geen een mogen werken, daarvoor zijn deze te specifiek geschreven. Ik heb nog even geprobeerd of 'date' er wellicht jaartallen van zou maken en dan '123' sorteren als '0123-01-01', maar helaas. ik kom zelf verder te weinig op de Engelstalige Wikipedia om te weten of daar tabellen zijn die een vergelijkbaar probleem hebben, laat staan daar wel een oplossing voor.

Ik kan me helemaal vinden in het zoeken van een zo generiek mogelijke oplossing, dus als iemand die probleem hogerop wil neerleggen, graag! Met vriendelijke groet, RonnieV (overleg) 7 jan 2016 01:07 (CET)

Wellicht kan het allemaal nóg handiger en/of eleganter, maar het kan volgens mij totaal geen kwaad de voorgestelde code nu al op te nemen in deze Common.js. Als er uitbreidingsverzoeken komen om bv. ook "DNQ" bij Formule-1 mee te sorteren, kunnen die alsnog doorgevoerd; en als blijkt dat het allemaal anders kan, kan de toevoeging weer weggehaald. In ben dus in principe voornemens om dit verzoek te honoreren, maar wacht hier nog even mee op verdere reacties - het kan zijn dat ik een technisch detail over het hoofd zie. CaAl (overleg) 7 jan 2016 09:31 (CET)

• Inmiddels een verzoek ingediend bij Phafricator, T123364. Het zou fijn zijn als het daar wordt opgepakt en wiki-breed beschikbaar komt. Met vriendelijke groet, RonnieV (overleg) 12 jan 2016 12:25 (CET)

  Helaas, TheDJ vond het kennelijk niet dringend genoeg en vindt dat we de pagina maar vol moeten proppen met een Sorteer-sjabloon. Leuk voor een paar tekentjes, niet als het er meer dan 34.000 keer in moet (niet vanwege het werk, ik pas het script dat de inhoud genereert eenvoudig aan, maar vanwege de bewerkbaarheid van de pagina). Met vriendelijke groet, RonnieV (overleg) 29 jan 2016 01:31 (CET)