Wikipedia:Verzoeken voor wijziging menu's en dialoogteksten

· ·

Verzoekpagina voor gebruikers met extra bevoegdheden

Deze pagina is bedoeld voor het indienen van verzoeken aan interfacemoderatoren, om onderdelen van de gebruikersinterface te wijzigen die andere gebruikers niet kunnen aanpassen. Inclusief verzoeken over:

• site-brede softwarepagina's in de MediaWiki-naamruimte (zoals CSS, JSON en JavaScript);
• Uitbreidingen die in de voorkeuren staan;
• twee-factor-authenticatie.

Tips

• Lijst van systeemberichten
• Lijst van uitbreidingen (ookwel "gadgets")
• Om te zien welke systeemberichten gebruikt worden, voeg de parameter "uselang=qqx" toe aan de URL
• Om te zien hoe een pagina eruit ziet in een bepaalde skin, voeg de parameter "useskin=<skin>" toe aan de URL (bijv. useskin=monobook)

Deze pagina is niet voor verzoeken om bepaalde artikels te wijzigen. Dat kan je zelf. Klik op de pagina van het artikel dat je wilt aanpassen op "Pagina bewerken" en maak de aanpassingen. Of plaats een verzoek of opmerking op de "overlegpagina" van dat artikel.

Afgehandelde verzoeken worden na 2 weken verplaatst naar het archief.

Overzicht
beheerpagina's

Verzoeken

Nieuwe verzoeken

"verbergen" werkt niet

In verborgen HTML-commentaar staat hierboven de instructie nieuwe verzoeken bovenaan toevoegen, wat voor mijn gevoel onlogisch is, maar bij dezen. Ik loop al een tijd, sinds de tijdelijke accounts bij Nederlandse Wikipedia geactiveerd zijn, aan tegen een issue. Namelijk dat de Nederlandse Wikipedia niet onthoudt de verberg status/voorkeur van Hulpmiddelen rechts (en sinds kort ook het Hoofdmenu links, daarom is het tijd om maar eens melding te maken hier). Na elk browser (her)laden van een artikel zijn ze weer zichtbaar, wat verbergen een zinloze actie maakt. Maar ik wil de Hulpmiddelen (en het Hoofdmenu) niet zien. Misschien is dit enkel bij tijdelijke account (~2025-...) zoals het mijne, en wellicht enkel als die een of meer bewerkingen hebben gedaan; misschien zelfs enkel op de desktop. Maar het is behoorlijk irritant, in ieder geval. ~2025-26549-39 (overleg) 24 sep 2025 20:50 (CEST)

Gadget-fixhoofdbetekenis.js

Momenteel gebruikt de gadget voor fixhoofdbetekenis deze code: document.getElementById('sjabloon_zie'). Dit sjabloon kan soms meerdere keren op het artikel voorkomen, waardoor het id meer dan eens op het artikel voorkomt. Dit geeft problemen met toegankelijkheidssoftware. Ik wil daarom het id van dit sjabloon af hebben en heb deze verplaatst naar een klasse. Om te zorgen dat deze gadget blijft werken staat er nu zowel een klasse als een id op dit sjabloon via deze bewerking.

Ik zou graag willen vragen om de volgende wijziging in MediaWiki:Gadget-fixhoofdbetekenis.js:

Vervang regel 9 door: if (document.querySelector('.sjabloon_zie')) {

Dit zorgt ervoor dat hij nu naar de klasse kijkt. Daarna kan Sjabloon:Zie artikel aangepast worden door het id eruit te halen. Sum^?urai8^? 20 sep 2025 19:51 (CEST)

 Uitgevoerd. –bdijkstra (overleg) 20 sep 2025 20:15 (CEST)

isMobileSite check in TBx-Manager

Het MediaWiki:Gadget-TBxManager-core.js script kijkt naar het web adres om te merken of de MobileFrontend extensie actief is. Dit soort checks zijn mogelijk incompatibel met de "Unified mobile routing" die volgende maand komt (m:Tech/News/2025/37). De meeste van dit soort checks zijn geen probleem, omdat het meestal over de URL zelf gaat, en dan is de check simpelweg overbodig en doet automatisch niks. Maar, in dit geval, gebruikt Wikipedia:TBx-Manager het om de mobile versie van discussiepaginas te detecteren. Ik heb dit vorige week in XFDcloser gefixt (GitHub-wijziging). Moeten we die wijziging hier ook toepassen? Ping @Bas dehaan. Krinkle (overleg) 15 sep 2025 03:53 (CEST)

Lijkt me wel. –bdijkstra (overleg) 15 sep 2025 22:15 (CEST)

Menu's van nuweg

Ik weet niet zeker of ik op deze pagina moet zijn, maar zo niet, dan merk ik het wel. Het gaat over de verwijderoptie m.b.t. computervertalingen:

• in het menu 'Hulpmiddelen' staat de optie 'Niet-Nederlandstalig of resultaat van een computervertaling'.
• in Twinkle wordt 'Machinevertaling of niet in het Nederlands geschreven' gegeven als optie.

Het deel over niet-Nederlandstalig klopt conform de RvM, maar het deel over de computervertaling/machinevertaling staat nergens in de RvM beschreven. Officieel mogen we als mods dus geen artikelen nuweggen die het resultaat zijn van een vertaalprogramma. Inmiddels rekken sommigen deze niet-bestaande nuwegreden op naar AI-artikelen, en dan moet ik gaan uitleggen dat AI geen nuwegreden is en een computervertaling ook niet. Kan iemand de RVM nog eens langs de nuwegmenu's leggen en er voor zorgen dat die echt 100% overeenkomen met de RVM? Het kan immers toch niet de bedoeling zijn dat nuwegjes op verschillende manieren afgehandeld worden, afhankelijk van welk menu je gebruikt. Thieu1972 (overleg) 10 jun 2025 19:23 (CEST)

De opties voor de standaard-dropdown staan in MediaWiki:Deletereason-dropdown, het deel "Computervertaling" is in 2010 toegevoegd. Sjoerd de Bruin (overleg)‍ 10 jun 2025 19:27 (CEST)

Dan staat het dus al 15 jaar fout. Thieu1972 (overleg) 10 jun 2025 19:29 (CEST)

Opmerking: zie ook Overleg_Wikipedia:Richtlijnen_voor_moderatoren/Archief/4#Niet-Nederlandstalig_of_resultaat_van_een_computervertaling (2015). Wutsje 10 jun 2025 19:43 (CEST)

(na bwc) Aanvulling: zie ook Overleg_Wikipedia:Richtlijnen_voor_moderatoren/Archief/4#Machinevertaling_als_nuwegreden en daaronder. Wutsje 10 jun 2025 19:57 (CEST)

Dat deel computervertaling is toegevoegd door MM, die had er sowieso een handje van de regels van RVM op te rekken. Mbch331 (overleg) 10 jun 2025 19:49 (CEST)

Ik heb er een aantal gevonden die niet in RVM staan:

• Doorverwijzing naar niet-bestaande of verwijderde pagina, overbodige of onjuiste doorverwijzing
• Experimenteerpagina (kan je eventueel als een variant op geen zinvolle inhoud beschouwen)
• Geklieder of ander vandalisme (kan je eventueel als een variant op geen zinvolle inhoud beschouwen)
• Pagina bestaat al onder andere naam of tekstdeel gekopieerd uit bestaand artikel

Ik heb alles wat niet conform RVM was verborgen. Mbch331 (overleg) 10 jun 2025 19:48 (CEST)

Iets meer discussie lijkt me wenselijk, er is iets te zeggen voor de stelling dat hier sprake is van staande praktijk c.q. codificatie. Alle wrakke doorverwijzingen via TBP moeten sturen lijkt me bijvoorbeeld niet doelmatig. Wutsje 10 jun 2025 19:57 (CEST)

Dat is een beetje het probleem op nlwiki. In principe zou de staande praktijk gewoon in de richtlijnen moeten staan. De RvM zou de huidige consensus moeten weergeven, niet de consensus (lees: werkwijze) van 15 jaar geleden. Als we dat niet doen blijven we discussies voeren over dit soort dingen en komen er misverstanden. Tegelijkertijd begrijp ik ook dat het wijzigen van de richtlijnen geen prettige ervaring kan zijn binnen een community zoals die van nlwiki.. XXBlackburnXx (overleg) 10 jun 2025 20:24 (CEST)

Hoe dan ook begrijp ik die haast en vrijwel complete afwezigheid van on wiki-overleg vooraf niet. Hier is in het verleden uitgebreid over gesproken en daarbij zijn best zinnige dingen gezegd (zie bv. hier). Bij zoiets betrek en informeer je toch de rest van de nl:wiki-gemeenschap, bijvoorbeeld op Overleg Wikipedia:Richtlijnen voor moderatoren? Wutsje 10 jun 2025 20:37 (CEST)

Als dat 10-15 jaar geleden is besproken, waarom is dat dan niet ook meteen doorgevoerd in de RVM? Wordt het niet eens tijd - na 10-15 jaar - om óf de regels gewoon te hanteren óf te constateren dat de regels slechts een suggestie zijn en de RVM overboord te gooien?

Bovenaan de RVM staat op dit moment vrij duidelijk:

Dit is een pagina waarvan de inhoud 'vastligt'. Inhoudelijke wijzigingen aan deze pagina mogen alleen met instemming van de Wikipedia-gemeenschap gebeuren.

Het is m.i. dan bijzonder dat we dat aan onze laars lappen door via een andere route - een keuzemenu - alsnog onze alternatieve wensen door te drukken. Dat is niet zuiver.

Mij maakt het persoonlijk niet uit hoor: ik nuweg met alle plezier die AI-rotzooi. Maar laten we dan de RVM ook niet meer serieus nemen als dat zo weinig voorstelt. Thieu1972 (overleg) 10 jun 2025 21:36 (CEST)

Het is toch niet alles of niets? We kunnen het er toch – en dan met "iedereen" – over hebben of we de staande praktijk (alsnog) willen codificeren? Denk bv. ook aan het voor twee jaar blokkeren van ip-adressen: daarover staat ook niets in de RVM, maar het gebeurt al jaren en met goede redenen. Moet die mogelijkheid nu opeens ook stante pede uit het blokkadeduur-uitklapmenu worden verwijderd?

Als een LLM als tekstgenerator én als enige "bron" wordt gebruikt, zoals hier, lijkt mij dat net zoiets als Bron:Google en levert dat daarom naar de geest zeker een nuweg op. Wutsje 10 jun 2025 22:16 (CEST)

Op de RvM-pagina staat het sjabloon {{vast}}, dat volgens de documentatie alleen bedoeld is voor vaste reglementen. De RvM zelf is, zoals de naam al aangeeft, echter een verzameling richtlijnen voor moderatoren, en is geen reglement. Wikipedia:Regelingen rond moderatoren is dat wél. Op de meeste Wikimedia-wiki's zijn beleid (policy) en richtlijnen (guidelines) strikt gescheiden. Wij mixen dit en RvM wordt behandeld als een quasi-reglement, terwijl het eigenlijk flexibeler zou moeten zijn. Dit is zo'n typisch voorbeeld van een discrepantie in het governance-systeem van nlwiki. Maar hoe lossen we dit op? Ik zou het niet weten. XXBlackburnXx (overleg) 10 jun 2025 22:39 (CEST)

Beleidsvorming is altijd een tweerichtingsverkeer geweest, governance groeit hier (deels) ook van onderop: de ene keer worden vernieuwingen eerst vastgelegd via een peiling of stemming, de andere keer (denk bv ook aan de criteria voor gebruikersnamen) komt er vanuit het dagelijks werk een 'best practise' die langzaam de standaard wordt.

Ik heb de RvM vorig jaar op de moderatorbijeenkomst in Utrecht al voor willen leggen, want ik zie inderdaad ook dat de huidige pagina beleid, richtlijnen en best practice (o.a. voorbeelden en aanwijzingen) teveel door elkaar bespreekt. Dat werkt volgens mij verwarrend voor zowel de moderatoren als de gemeenschap. Ciell need me? ping me! 11 jun 2025 11:46 (CEST)

"De RvM zelf is, zoals de naam al aangeeft, echter een verzameling richtlijnen voor moderatoren, en is geen reglement." Is dat niet een klein beetje spelen met woorden? Regelmatig wordt gemeld dat de RvM zo belangrijk is - je moet het zelfs onderschrijven bij je aanmelding - maar als het niet uitkomt, is het 'slechts een verzameling richtlijnen'. Of we moeten vooral niet zo rechtlijnig denken en de nuwegcriteria gewoon naar eigen inzicht invullen o.b.v. wat naar de 'geest' weg zou mogen.

Ik weet dat het vreselijk moeilijk is om op NL-wiki ook maar één regel af te spreken en dan ook te hanteren, maar is het echt niet mogelijk om voor een keer wat duidelijker te werk te gaan? Of haal anders dat sjabloon van de RVM-pagina af en vervang het door iets als 'het is een vrij te interpreteren richtlijn'. Ook prima, maar dan moet ook niemand meer piepen als de nuwegcriteria per moderator verschillen. Er is nu al een verschil in interpretatie - en dat is niet erg, want we zijn mensen met eigen inzichten - maar dat wordt dan alleen maar erger. Thieu1972 (overleg) 11 jun 2025 13:06 (CEST)

Er lopen volgens mij nu wat dingen door elkaar. De originele vraag of computervertaling een valide nuwegreden is lijkt me een redelijke vraag die het best op de overlegpagina van RvM besproken kan worden. De vraag hoe "strikt" en "vast" de RvM is is mogelijk ook een losse discussie, maar wel eentje die enkel zal kunnen leiden tot de conclusie dat het losser interpreteren van de regels een noodzakelijk kwaad is of anderszijds een volledige herschrijving van de huidige richtlijnen vereist (want niemand zal bv. eenzelfde definitie van "zinvolle inhoud" hebben).

Dat nu vier andere nuwegredenen zijn weggehaald lijkt me erg voorbarig; ze kunnen gemakkelijk allemaal worden ondersteund door de RvM via "geen zinvolle informatie". Geklieder en experimenteer zijn inderdaad niet per se nodig, maar kunnen mogelijk wat nuance aanbrengen voor verwijderredenen die gewoon passen onder "geen zinvolle inhoud". Ik gebruik ze zelf niet, maar als anderen dat wel doen zie ik geen goede reden om ze weg te halen. Als afhandelaar van Speciaal:GebrokenDoorverwijzingen is de doorverwijzingsreden mogelijk mijn meest frequent gebruikte verwijderreden. Het is zoveel duidelijker en correcter naar iedereen toe om hier een deze losse reden voor te hebben. We moeten onderhoudswerk voor onszelf niet moeilijker maken dan nodig. De verdubbeling van pagina's/teksten is ook iets waar je normaal geen TBP-proces voor nodig hebt; het is geen zinvolle inhoud als het al correct staat onder een betere naam. @Mbch331: zou je in ieder geval de doorverwijsreden weer terug willen zetten? - Kippenvlees (overleg‽)‍ 11 jun 2025 16:19 (CEST)

Ik heb die deels teruggezet. Overbodig/onjuist is discutabel en valt niet altijd onder geen zinvolle inhoud. "niet-bestaande of verwijderde pagina" valt er wel duidelijk onder. Mbch331 (overleg) 11 jun 2025 16:30 (CEST)

Sommige dingen zijn gewoon onderhoud en logisch nadenken. Dus dat een onzinnige RD wordt genuwegd, snap ik.

Dat de invulling van sommige nuwegredenen onderling anders is vanwege interpretatieverschillen, snap ik ook, net als dat je wat creatief kan zijn om iets er alsnog onder te scharen.

Wat ik niet snap, is dat we verstrekkende nuwegredenen als computer-/machinevertaling (flexibel uitgebreid tot 'AI') gewoon ertussen moffelen. Eerst de RVM aanpassen, en dan de systemen. Niet andersom. Thieu1972 (overleg) 11 jun 2025 17:25 (CEST)

Ik ben zelf die verwijderreden enkel tegengekomen in de context van mensen die letterlijk en.wp door de vertaalmachine gooien, inclusief dingen als "[1]" en niet-bestaande sjablonen. Dat was dus altijd zonder twijfel een rechtstreekse kopie. Zo heb ik zelf ook altijd die verwijderreden geïnterpreteerd: niet-Nederlandstalige tekst die door de vertaalmachine wordt gehaald en zonder verdere breininspanning wordt geplaatst. Ik ben ook niet voor een bredere toepassing, dus misschien is de formulering in die zin ook niet goed en dus te breed. - Kippenvlees (overleg‽)‍ 11 jun 2025 18:04 (CEST)

Met wat creativiteit zou het 'copyvio' kunnen zijn, omdat dergelijke rommel zelden een correcte licentievermelding heeft. Maar los daarvan: ik stoor me ook mateloos aan dat soort 'vertalingen'..... Thieu1972 (overleg) 11 jun 2025 18:17 (CEST)

Even als antwoord op de "waarom...?"-vraag: er was in het verleden geen behoefte om de RvM en de verwijder-dropdowns tekstueel volledig overeen te laten komen, zie de verschillende onderwerpen van discussie over toevoegingen en inkorten door de jaren heen op Overleg MediaWiki:Deletereason-dropdown.

Daarnaast, ook aanvullend: mocht je je afvragen hoe vaak de moderatoren een specifieke verwijderreden gebruiken, dan geeft het jaaroverzicht 2024 misschien nog goeie inzichten. Ciell need me? ping me! 11 jun 2025 18:27 (CEST)

Mbch331, je maakt(e) zelf ook gebruik van die opties, ga je nu zulke verwijderingen niet meer uitvoeren, of ga je andere redenen opgeven? –bdijkstra (overleg) 10 jun 2025 21:32 (CEST)

@Mbch331, ik wacht nog op een antwoord op bovenstaande vraag. En ik heb nog een vraag: wat stel je voor als verwijderreden voor dit soort pagina's? Of stel je voor om ze te laten staan? –bdijkstra (overleg) 12 jun 2025 18:01 (CEST)

Dat laatste zal niemand voorstellen. Het verwijderen van onzinnige redirects zal niemand tegen zijn. Discussies over nuwegjes gaan m.i. vooral over interpretatie van de inhoud van een artikel (is dit reclame? is dit onzin?) en over computergegenereerde teksten (AI, Google Translate etc). Als de RvM daar dan ook nog eens weinig ruimte geeft, schept dat verwarring en willekeur: de ene mod weigert een vertaling of AI te verwijderen ('staat niet in de RvM'), de ander verwijdert het zonder probleem ('mag volgens het keuzemenu').

Ik geef toe dat het weghalen van de optie voor doorverwijzingen niet heel fijn is, en wellicht onder 'geen zinvolle inhoud' of 'technische redenen' weggezet kan worden, maar dat is natuurlijk een omweg. Dus wmb kan die optie wel weer terug, vanwege gezond verstand, gebrek aan gevoeligheid, en overeenstemming alhier. Thieu1972 (overleg) 12 jun 2025 18:29 (CEST)

Mediawiki Maps

Op de meeste Wikipedia's is een jaar of tien geleden het script GeoHack.js beschikbaar gekomen, waardoor een kaartje getoond kan worden op GeoHack middels Wikimedia Maps. Zou deze ook naar de NL wiki geïmporteerd kunnen worden? Volg bijvoorbeeld de versie van EN, IT, FR of RU. JBX (overleg) 9 apr 2025 19:45 (CEST)

Wat is er mis met het kaartje op GeoHack wat nu getoond wordt? Op de genoemde wiki's zie ik subtiel verschillende scripts waarbij het mij onduidelijk is welke versie voor deze wiki het meest relevant zou zijn, maar bovendien is het mij onduidelijk waar en hoe dit script gebruikt wordt. Het equivalent van Sjabloon:GeoTemplate lijkt niet of nauwelijks te worden gebruikt op die wiki's. –bdijkstra (overleg) 9 apr 2025 22:11 (CEST)

De Nederlandse GeoHack kent geen dynamische kaart. Zie voor gebruik van de Wikimedia Maps bijvoorbeeld de Engelse GeoHack. Hierbij krijgt de gebruiker dus gelijk inzicht in de locatie, waar die nu altijd nog moet doorklikken (waarschijnlijk het vaakst) op de google maps link. Op je vraag welke versie het meest geschikt is: waarom de Engelse versie de appendCSS functie introduceert weet ik niet, we kunnen het simpeler houden door de Franse versie te volgen. JBX (overleg) 20 apr 2025 15:00 (CEST)

Inmiddels begrijp ik (hoewel dit nergens gedocumenteerd lijkt) dat dat sjabloon wordt gebruikt om de GeoHack-webpagina op te bouwen. Kan ons sjabloon niet gewoon worden aangepast om een gedeelte "Wikimedia Maps" te tonen, zonder gebruik van scripts? –bdijkstra (overleg) 20 apr 2025 15:17 (CEST)

GeoHack is opgebouwd op een manier dat de scripts van de Wikipedia met de 'lokale taal' worden gebruikt, zie https://www.mediawiki.org/wiki/GeoHack#JavaScript. De functie embedOpenStreetMap is zoals je ziet erg beperkt, het zorgt er simpelweg voor dat GeoHack maps.wikimedia.org kan aanroepen met de relevante coördinaten. JBX (overleg) 20 apr 2025 23:10 (CEST)

We zijn weer even verder. Zou hier een keuze in gemaakt kunnen worden? De klassieke GeoHack behouden, dus zonder GeoHack scriptje, of een met kaart zoals sinds 2009 op de grotere wikipedia talen wordt gebruikt. JBX (overleg) 9 jun 2025 18:09 (CEST)

Nee, ik denk niet dat hier een keuze gemaakt kan worden. Dit is een eenvoudige verzoekpagina, voor een keuze is input van de gemeenschap nodig over wat wenselijk is. –bdijkstra (overleg) 9 jun 2025 23:43 (CEST)

Zou dit dus in Wikipedia:De kroeg geplaatst moeten worden? JBX (overleg) 10 jun 2025 14:51 (CEST)

Misschien is het verstandig om eerst de mensen van Wikipedia:De Nulmeridiaan de keuzes te laten inventariseren en begrijpelijk maken voor een groter publiek. –bdijkstra (overleg) 10 jun 2025 21:00 (CEST)