Ik merkte bij uitbreiden van wat artikel dat er een nieuwe feature actief is geworden. Bij het linken van een artikel(naam) dat een doorverwijspagina is naar meerdere betekenissen kreeg ik een pop-up-venster die dat aangeeft en vervolgens kan je of de doorverwijspagina bekijken of kiezen welk artikel je eigenlijk wilde linken. Erg handig. [[Gebruiker:DagneyGirl|DagneyGirl]] ([[Overleg gebruiker:DagneyGirl|overleg]]) 15 jan 2022 11:19 (CET)
Ik merkte bij uitbreiden van wat artikel dat er een nieuwe feature actief is geworden. Bij het linken van een artikel(naam) dat een doorverwijspagina is naar meerdere betekenissen kreeg ik een pop-up-venster die dat aangeeft en vervolgens kan je of de doorverwijspagina bekijken of kiezen welk artikel je eigenlijk wilde linken. Erg handig. [[Gebruiker:DagneyGirl|DagneyGirl]] ([[Overleg gebruiker:DagneyGirl|overleg]]) 15 jan 2022 11:19 (CET)
:Fijn! Dat scheelt een hoop zinloos werk [[User:Bertux|'' →bertux'']] 15 jan 2022 15:03 (CET)
De Nederlandstalige Wikipedia heeft op 10 mei 2024 2.158.100 artikelen. Om de kwaliteit van Wikipedia verder te verbeteren, worden hier iedere dag tien artikelen getipt: vijf artikelen die een opknapbeurt verdienen en vijf artikelen die nog aangemaakt kunnen worden. Uw hulp is van harte welkom!Artikel van de dag
Sekscoaching (veel te weinig bronvermeldingen en risico op reclame door belangenverstrengeling van auteur) (10/11/2023)
Scandinavië - De Nederlandstalige versie over Scandinavië is erg summier, terwijl de Engelse versie zeer uitgebreid is, inclusief bronvermelding.De definitie van Scandinavië is niet onomstreden, en dit wordt uitvoerig toegelicht op de Engelse versie. (23/03/2024)
The Bear (film, 1988) - Beroemde film van Jean-Jacques Annaud. Heeft al op nagenoeg alle andere grotere WP's een artikel (d:Q379460). De extra disambiguatie is hier nodig omdat er nog enkele films met deze naam bestaan (zie hier).(22/12/2023)
Henricus Joannes Verhagen, priester en journalist die in de eerste helft van de 20ste eeuw veel voor Zuid-Limburg zou hebben betekend. (23/3/2024)
Als ik zo vrij mag zijn feedback te geven, de manier waarop jij iets opschrijft beïnvloedt in sterke mate hoe andere mensen op jou zullen reageren. Ik kan me voorstellen dat veel gebruikers niet-constructief zullen reageren op iets wat toch ervaren kan worden als een sneer. Als je iets wilde veranderen, was het misschien beter te vragen "Waarom hebben wij als een van de weinige grotere wiki's nog geen BLP-sjabloon?" of "Hey, ik kwam dit BLP sjabloon tegen met deze en deze voordelen, is dat misschien iets voor nl-wiki?". Ik zeg niet dat het daarmee er komt, maar het komt de discussie wel ten goede :) Dajasj (overleg) 3 jan 2022 10:49 (CET)Reageren
Dat alle andere wiki's in een vieze sloot springen is geen reden dat zelf ook maar te doen, om ze te redden van nodeloze stickerplakkerij zijn we toch al te laat. ♠ Troefkaart (overleg) 3 jan 2022 11:44 (CET)Reageren
Het doel is om bewerkers er op te attenderen dat een WP-artikel een grote impact kan hebben op de privacy van de hoofdpersoon en in het slechtste geval zijn of haar carrière of zelfs leven kan verwoesten. Wickey (overleg) 3 jan 2022 11:58 (CET)Reageren
Om dit uit te leggen is geen sjabloon nodig. Er zijn grote verschillen van geval tot geval, en ik denk dat er per geval gereageerd of gewaarschuwd moet worden. Dat is nauwelijks in een sjabloon te vatten. Dat er bij ons niet zo'n sjabloon is, betekent niet dat wij geen BLP-richtlijnen hebben. WIKIKLAASoverleg3 jan 2022 12:18 (CET)Reageren
Tja, als er zoveel wiki's zijn die dit zinvol vinden geeft dat te denken, toch? Of je dit standaard of van geval tot geval moet toepassen is een andere vraag. Het is ook een middel om iedereen bij de les te houden. Wickey (overleg) 3 jan 2022 13:49 (CET)Reageren
Dat zoveel wiki's het zinvol vinden mag je niet afleiden uit het feit dat zoveel dat sjabloon hebben. Tussen die twee zaken bestaat immers geen oorzakelijk verband. Het valt evengoed te verklaren met de redenering dat er een kudde makke schapen achter één schaap aanhobbelt. En in feite stel jij hier nu voor dat wij hetzelfde moeten doen. Je geeft namelijk geen enkel argument waarom het voor ons project belangrijk is om zo'n sjabloon te hebben. Wij hebben op ons project bijvoorbeeld wél een sjabloon 'leeswaarschuwing'. Omdat iemand dat ooit gemaakt heeft. Ik heb wel eens bezwaar gemaakt tegen het gebruik ervan op een bepaalde plek, omdat ik vind dat de lezer mag verwachten dat de inhoud van een film of boek hier besproken wordt, en daarvoor dus niet gewaarschuwd zou moeten worden. De reactie die ik kreeg: we hebben dat sjabloon, dus het zal wel niet voor niks zijn, en daarom mag ik het gebruiken. Terwijl dat sjabloon gemaakt was door een van de vrijwilligers van dit project, en die hebben niet noodzakelijk de wijsheid in pacht. Het is niet voor niets dat we ook niet naar wikipedia-artikelen verwijzen om aan te tonen dat iets correct is: die artikelen zijn immers geschreven door medewerkers die fouten kunnen maken of onjuist kunnen redeneren. Dus in plaats van hier zonder verdere argumenten voor te stellen dat we achter andere projecten moeten aanhollen: geef eens wat redenen waarom we volgens jou niet zonder dat sjabloon kunnen. WIKIKLAASoverleg3 jan 2022 15:42 (CET)Reageren
Er is al een wikipedia-pagina hierover, Wikipedia:Biografieën van levende personen, met vier redirects WP:BLP, WP:BIO, WP:LEVEND en WP:LIVING. Sjabloon hoeft van mij niet, doet me denken aan Amerikaanse papieren bekers voor koffie waarop staat: "pas op, de inhoud kan heet zijn en voor brandwonden zorgen". Zulke teksten zie ik gelukkig (nog) niet in mijn land/continent, neem aan dat de meesten zich realiseren dat koffie e.d. eerst even moet afkoelen. BlueKnight3 jan 2022 15:50 (CET)Reageren
Ik kan me herinneren dat ik lang geleden voor het eerst een beker koffie bestelde in Ierland, stond geen waarschuwing op, maar dat was wel een tweedegraads brandwond. Dus dat ze daar voor waarschuwen, zeker voor mensen die gewend zijn om koffie te krijgen op een aanzienlijk lagere temperatuur is misschien nog niet zo gek. Peter b (overleg) 3 jan 2022 22:37 (CET)Reageren
De aanpak op de Engelstalige Wikipedia, waarbij er zodra je een artikel over een levend persoon wil bewerken, een waarschuwing in beeld komt, vind ik zeer zinvol, klik bijvoorbeeld hierop. Geen idee hoe dat werkt. Via wikidata zou het beste zijn, daar bestaat imho de grootste kans dat de gegevens actueel zijn. Het bijhouden van sjablonen en categorieën op alle biografieën of OP's daarvan is onbegonnen werk imho. We moeten af en toe eens fundamenteel nadenken over het actueel houden van onze 2 miljoen artikelen. Want we zijn maar met een paar honderd vrijwilligers. Elly (overleg) 3 jan 2022 16:02 (CET)Reageren
Hi @Ellywa, om je vraag m.b.t. editintro te beantwoorden: als je het template zelf bezoekt staat daar hoe dit wordt gedaan. Pagina moet in categorie "Living people" of "Possibly living people" staan. Vervolgens wordt met dit stukje code de editintro aan de URL in je browser toegevoegt zodat je hem te zien krijgt. Is relatief makkelijk te implementeren op de Nederlandstalige Wikipedia indien elke levende of mogelijk levende persoon een dergelijke categorie had. Dat is niet het geval, dus heeft voor ons momenteel nog geen nut. Wiki13 (overleg) 3 jan 2022 16:17 (CET)Reageren
Ja hoor, dat script is relatief simpel te schrijven, maar zal wel even een tijd lopen. Maar laten we eerst maar eens zien of die hele constructie wel gewenst is, dan kan dat verzoek prima op WP:VPB gezet worden. Edoderoo (overleg) 3 jan 2022 22:32 (CET)Reageren
In mijn database zitten personen met een pagina op nl-wiki. Bij 228.090 is een geboortejaar(datum) bekend, en bij 108.510 daarvan een overlijdensjaar(datum). Daarnaast zijn er nog 789 van wie het overlijdensjaar onzeker is, maar het overlijden aannemelijk. Dat wijst erop dat er zo'n 119.000 artikelen over levende personen bestaan. Met 14.400 per dag ben je even zoet...
Ik ben geen voorstander van allerlei sjablonen op onze artikelen, een oplossing vanuit Wikidata zou wel op mijn steun kunnen rekenen. Het handmatig onderhouden van dit soort sjablonen gaat te vaak fout, het bijwerken van overlijdens(data) ook. Met vriendelijke groet, RonnieV (overleg) 7 jan 2022 16:59 (CET)Reageren
Grove inbreuk op privacy @Bertux, wikipedia is de eerste hit op google, dus kwaadwillenden kunnen de meest abjecte onzin over je neerpennen met een gelijk een grote lezersgroep, en onder het mom "waar rook is is vuur" is het kwaad dan al geschied. Hans Erren (overleg) 4 jan 2022 06:52 (CET)Reageren
En gaan al die extra sjablonen die inbreuken dan voorkomen? Ik vrees dat dat ijdele hoop is. Kwaadwillenden laten zich niet door een waarschuwing "weet u zeker dat u deze persoon wilt beschadigen" zullen laten tegenhouden, het wordt dan meer een aanmoedingsprijs. Vandalisme-controle, controle van nieuwe gebruikers, en nalopen van de meest bezochte artikelen en die controleren op bron-gebruik, zullen dan meer effect hebben. Die sjablonen hebben net zoveel effect als de bordjes met 30 in een woonwijk: iedereen scheurt er met minstens 50 langs, en ze worden nauwelijks gezien. Edoderoo (overleg) 4 jan 2022 09:36 (CET)Reageren
(Sjabloon)BLP is er niet alleen voor, al dan niet kwaadwillende, bewerkers, maar vooral ook een steun voor hen die zulke artikelen bewaken en zuiveren. Het geeft houvast bij het terugdraaien van grensoverschrijdende bewerkingen. Dat is onder andere meteen ook het nut van Categorie:Biografie levend persoon. Daarnaast is het natuurlijk ook handig om te zien of er al een biografie over iemand bestaat. Wickey (overleg) 4 jan 2022 13:08 (CET)Reageren
Het ging mij om de gewoonte van categoriseren. Een categorie geeft aan wat het onderwerp van een lemma is (bijv. een schrijver, boek of insect), niet wat het 'genre' van het lemma is (biografisch, literair, biologisch). Als je de paginasoort er wel in zet is het gebruikelijk daar 'Wikipedia:' voor te zetten (Categorie:Wikipedia:Doorverwijspagina). Encycloon (overleg) 5 jan 2022 17:11 (CET)Reageren
Wanneer er sprake is van grensoverschrijdende bewerkingen, moet er sowieso ingegrepen worden. Een categorie met duizenden artikelen verandert daar niets aan. Terwijl het wel extra onderhoud geeft. Voordat we gaan aannemen of zo'n categorie werkelijk helpt (of niet); heeft iemand enig bewijs dat het bestrijden van vandalisme, inbreuk op privacy of verspreiding van fake news makkelijker, beter of efficiënter verloopt sinds op wpen Category:Living people in gebruik is genomen? hirothe club is open5 jan 2022 08:08 (CET)Reageren
Deze enorme onwerkbare categorie zou voor normale lezers niet veel toevoegen. De toegevoegde waarde is dat deze gebruikt kan worden om automatisch te bepalen of de speciale instructie getoond moet worden. Dit zal echter niet werken voor onbestaande artikelen. De vraag is dan mi ook niet of de categorie helpt, maar of zo'n instructie werkt. — Zanaq(?)5 jan 2022 10:07 (CET)Reageren
Daar wordt het slechts een orde van grootte minder van dus dat zet weinig zoden aan de dijk. Maar ik vrees vooral dat het automatische mechanisme daar lastig mee om zal kunnen gaan. — Zanaq(?)5 jan 2022 17:51 (CET)Reageren
@Hans Erren: Categorieën zijn er om structuur aan te brengen, niet om houvast te geven bij het terugdraaien van vandalisme etc. We praten hier over heel andere argumenten dan voor andere categorieën. hirothe club is open5 jan 2022 11:14 (CET)Reageren
Strikt genomen breng je structuur aan, dat klopt. Maar een onzinnige structuur omdat het niveau veel te abstract is. Tenzij die categorieën van de anderstalige Wikipedia's aantoonbaar hebben bijgedragen aan bestrijding van grensoverschrijdende bewerkingen, zie ik geen reden om de categorie hier in gebruik te nemen. hirothe club is open5 jan 2022 14:20 (CET)Reageren
Een categorie als Categorie:Nederlands burgemeester is inderdaad veel minder abstract. Maar zijn er ook andere argumenten dan 'andere Wikipedia's doen het'? Kan er aangetoond worden dat zo'n categorie nut gaat hebben? Of blijft het bij flauwe opmerkingen die verder niets bijdragen aan de discussie? hirothe club is open5 jan 2022 18:02 (CET)Reageren
Opvallend dat sommigen zo krampachtig irrationele gelegenheidsargumenten gaan verzinnen, gewoon om veranderingen zoveel mogelijk tegen te houden, of omdat het idee toevallig van Wickey komt. En dat terwijl ik de categorie ook onopvallend en oncontroversieel had kunnen aanmaken. En dat terwijl het eigenlijk ging om een simpele vertaling van een sjabloon dat bij de meeste andere wiki's doodnormaal en vanzelfsprekend is. Wickey (overleg) 6 jan 2022 11:33 (CET)Reageren
Verandering om de verandering is anders een slecht idee. Veranderingen moeten nuttig zijn en een sjabloon dat geen aantoonbaar nut heeft, is niet nodig. Dqfn13 (overleg) 6 jan 2022 11:48 (CET)Reageren
Wickey stelt wat mij betreft een serieus probleem aan de orde. Veel te veel lemma's over levende personen voldoen niet aan de meest essentiële regels, niet alleen formele regels die gevolgd moeten worden, maar ook op het gebied van bronnengebruik. Om daar meer aandacht voor te krijgen kun je een sjabloon invoeren, je kunt ook een categorie aanmaken, beide kunnen behulpzaam zijn, allebei invoeren zou niet mijn voorkeur hebben, niets doen lijkt me echter geen optie. Peter b (overleg) 6 jan 2022 12:08 (CET)Reageren
Dat klinkt een beetje als een politicus die iets wil doen zodat het publiek niet ziet dat hij niets doet, zelfs als het effect niet duidelijk is, alleen maar zodat zichtbaar is dat men actie onderneemt.
Op welke wijze kan het behulpzaam zijn? Het is mi belangrijk dat het probleem duidelijk is en de oplossing potentieel het probleem oplost. Wat is het probleem precies? Op welke manier lost de oplossing het probleem op? (Ik geef de melding op de bewerkpagina dan meer kans dan een melding op de overlegpagina, hoewel is gebleken dat veel gebruikers die ook niet lezen.) — Zanaq(?)6 jan 2022 12:14 (CET)Reageren
Als wij nu eerst even het bron vermelden bij Biografieën van Levende Personen verplicht maken... The Bannertalk6 jan 2022 17:54 (CET) Ziet nog veel water door de Rijn stromen voor men dat aan durft!Reageren
Vervolg Sjabloon:BLP
Als een reactie op een deel van de discussie hierboven: Een categorie zoals hierboven wordt voorgesteld betekent vooral een hoop extra werk om dat te regelen en bij te houden, daarnaast ook nog eens niet rechtstreeks zinvol voor de inhoud van het artikel zelf, terwijl dat mijn inziens de basis zou moeten zijn. Als we zonodig een melding willen weergeven of wat dan ook ten aanzien van de artikelinhoud, voor zoiets zou het artikel zo min mogelijk bewerkt moeten worden. Verder denk ik, dat als het breed zinvol wordt gevonden om een melding te tonen, dat we dat anders regelen waardoor er veel minder werk nodig is, we gebruik maken van de bestaande infrastructuur en het tonen automatisch laten verlopen. In de meeste artikelen over personen staat een infobox en die kan automatisch op Wikidata nagaan of er aldaar een overlijdensdatum is ingevuld. Op basis daarvan kan dan wel/niet een melding getoond worden. Een tweede route om dit automatisch te laten tonen is via een gadget die ook van Wikidata dit gegeven opvraagt. Dit gadget kunnen ervaren gebruikers in hun voorkeuren dan uitschakelen. Het voordeel van deze twee routes is dat dit na het instellen verder nul extra werk geeft om dit per artikel te gaan bijhouden. Romaine (overleg) 7 jan 2022 11:59 (CET)Reageren
Het aantal artikelen zou op zichzelf een legitiem argument kunnen zijn, alhoewel dat in principe op iedere al bestaande cat van toepassing is. Kennelijk is dat voor andere wiki's niet zo'n probleem. Hier is de Engelse versie, inclusief toelichting.
Dat een cat alleen legitiem is als die "rechtstreeks zinvol voor de inhoud van het artikel zelf" is, is een POV.
Natuurlijk, we hebben ook verborgen onderhoudscategorieën. Die zijn ook niet "rechtstreeks zinvol voor de inhoud van het artikel zelf", maar wel een hulpje voor het redactie- en onderhoudswerk. Daarom zijn ze ook verborgen, tenzij je ze als gebruiker expliciet laat tonen via je voorkeuren. Ik ga mee met Romaine: het vullen zou dan niet moeten gebeuren via een bot die periodiek gedraaid moet worden, maar via de infoboxen en Wikidata. Wikiwerner (overleg) 8 jan 2022 17:21 (CET)Reageren
Ik ben de laatste om tegen alternatieven te pleiten, maar het argument van Romaine ontgaat mij ten ene male. Hij komt hier met een willekeurig voorbeeld als gelegenheidsargument. In principe worden alle artikelen handmatig op dagelijkse basis onderhouden, inclusief punten en komma's. De beste methode om onderhoud te voorkomen is alle artikelen bevriezen en het aanmaken van nieuwe verbieden. Wickey (overleg) 8 jan 2022 17:59 (CET)Reageren
Tja, @Wickey, jij komt met een idee 'omdat anderen het ook doen'. Het is genoegzaam bekend dat iedere gemeenschap grote vrijheid heeft in het kiezen van de wijze waarop zij invulling geeft aan het grotere doel, het verzamelen en beschikbaar stellen van vrije kennis.
Er zijn diverse vragen gesteld, onder meer over de beoogde werkwijze en over het waarom. Ik heb weinig in mijn ogen bevredigende antwoorden gezien over de echte noodzaak van een categorie met 110k artikelen, waarbij deze alle handmatig onderhouden zouden moeten worden.
We hebben dik 2 miljoen artikelen waarvan de inhoud niet kloppen, en ruim 10% van die artikelen gaat over personen. BLP ziet op de artikelen over levende personen, maar dat is natuurlijk geen vrijbrief om in een artikel over een gisteren overleden persoon maar van alles te schrijven. Toch zou dat artikel niet deze waarschuwing krijgen, want uit de groep BLP-artikelen (los van de keuze).
Het plaatsen van allerlei codes, voor het artikel irrelevante categorieën en andere attributen heeft niets met het artikel te maken. Ik heb geen enkele reden gezien waarom het een goed idee is dat dergelijke zaken in een artikel geplaatst worden, terwijl ze juist wel regelmatig de opmaak van het artikel verstoren. Het basisprincipe is dat artikelpagina's bedoeld zijn voor de inhoud en niet voor allerlei andere fratsen, hoe graag die fratsen ook door iemand gewenst worden. En zoals ik al eerder zei is de onderhoudbaarheid een probleem dat anders en effectiever opgelost kan worden.
We hebben inderdaad verschillende volgcategorieën, maar die worden in principe niet rechtstreeks in de artikelen geplaatst (maar via een sjabloon dat er toch als staat of via de MediaWiki-software). Daarnaast zijn die volgcategorieën doorgaans daadwerkelijk van belang voor de inhoud van die artikelen, bijvoorbeeld om referentiefouten in een artikel op te sporen.
"Dat een cat alleen legitiem is als die "rechtstreeks zinvol voor de inhoud van het artikel zelf" is, is een POV." -> Een "POV" die wel breed gedeeld wordt, want in eerdere jaren is dat wel als legitieme reden opgegeven. Dat je dit een POV noemt lijkt mij voort te komen uit de sterke wens iets te krijgen, waarbij andere al jaren geldende uitgangspunten klakkeloos opzij geschoven worden.
"Hij komt hier met een willekeurig voorbeeld als gelegenheidsargument." -> Oja, wat dan? Graag verduidelijking. Ik zie het niet. (Ik heb wel het extra werk, een gangbaar basisprincipe en een alternatieve oplossing beschreven.) Ik denk dat je de aanduiding "gelegenheidsargument" misbruikt omdat wat ik beschreef je niet beviel. Romaine (overleg) 11 jan 2022 12:41 (CET)Reageren
Een hoop woorden om eigenlijk niets te zeggen. Als ik het heb over een categorie dan begin jij over het invullen van overlijdensdata in infoboxen. En nu kom je weer met een vage opmerking over "allerlei codes, voor het artikel irrelevante categorieën en andere attributen".
Je kunt vast wel haarfijn vertellen hoe ze "wel regelmatig de opmaak van het artikel verstoren" en wat er allemaal dan wel voor een hoop extra werk bij een extra cat komt kijken. Hierboven is al lang uitgelegd wat de zin is van een Categorie:Biografie levend persoon.
Uit bovenstaande blijkt geen consensus hiervoor, en het is mi ook niet duidelijk wat er precies wordt voorgesteld om welk probleem precies op te lossen. Als men dit wil doorzetten denk ik dat een concrete peiling/stemming - naast het beantwoorden van die vragen - mogelijk meer duidelijkheid geeft: ik heb het idee dat er vooral ook langs elkaar heen gepraat wordt. — Zanaq(?)12 jan 2022 09:57 (CET)Reageren
@Wickey: Tja, als je aangeeft dat je niet begrijpt wat er geschreven wordt zijn het vanzelf lege woorden. Maar als je het lege woorden vindt, dan heeft het dus geen zin om het er over te hebben.
Laatste bericht: 2 jaar geleden19 berichten7 personen in overleg
Hallo allemaal. Het nieuwe jaar is begonnen en dat geeft de mogelijkheid om terug te blikken op de meest bekeken artikelen van 2021. Ik licht een aantal toe die ik opvallend vond.
Precies. In mijn middelbare schooltijd had je elk jaar bij het natuurkunde eindexamen een keuzeonderwerp. Voor mij specifiek was dat het weer. Stel dat er nog zoiets bestaat en vorig jaar had het keuzeonderwerp iets met astronomie te maken. Dan zou het zo maar eens kunnen dat veel studenten die eindexamen in natuurkunde deden, Kepler raadpleegde. Wanneer ze dit vanaf school deden, dan hebben alle studenten van 'n bepaalde school dit via hetzelfde IP adres (van de school) gedaan. Dan zou je relatief veel bezoeken van 'n beperkt aantal IP adressen hebben met daarnaast het jaarlijks gemiddeld aantal bezoekers van willekeurig andere IP adressen. Dit is uiteraard pure speculatie en zo zijn er vast nog andere oorzaken te bedenken. Echter, daarom kan het wel interessant zijn om het aantal unieke bezoekers te weten. Wanneer het hoge aantal bezoers voornamelijk is toe te wijzen aan een beperkt aantal IP adressen kan dit een indicatie zijn voor de oorzaak van het enorme aantal bezoekers. Dus 80% van de bezoeken komt van 5% van de IP's en die IP's horen voornamelijk bij scholen is een indicatie dat het grote aantal bezoeken met iets op school te maken heeft. Ook interessant is om te weten hoe het voor die pagina in andere jaren was. Verder is het ook interessant om te wetem hoe de verdeling van bezoeken door het jaar heen was. Elke maand ongeveer evenveel of e.g. een enorme piek in mei. Bij het EK zal er ongetwijfeld een enorme piek tijdens en rondom het EK liggen. Kortom, hoe meer je van de lezers te weten kan komen, hoe groter de kans dat je het enorme aantal bezoekers kan verklaren. Van dit soort gegevens en nog vele anderen maakt e.g. Google Analytics gebruik. Ken je lezer (klant) en hoe beter je het gedrag van de klant kan verklaren. Dit uiteraard met als doel om je klant daarna zo proberen te beinvloeden dat ie zoveel mogelijk koopt. --Sb008 (overleg) 4 jan 2022 22:54 (CET)Reageren
Voor mij hoef je het niet uit te zoeken, persoonlijk boeit het me niet echt waarom 'n zekere pagina opeens hoog in de lijst staat. Wanneer je echter redenen wil weten waarom een pagina opeens hoog staat, wordt de kans om dit te achterhalen vergroot met verdere info, zoals aangegeven. Er is technisch gezien nog veel meer te achterhalen. Hier vind je een lijst van zogenaamde Dimensions & Metrics die Google Analytics (GA) allemaal bijhoudt van bezoekers. Het is niet eens de volledige lijst, er zijn er die Google niet publiekelijk bekend maakt en die dus ook niet zijn te raadplegen voor organisaties die GA op hun websites geimplementeerd hebben. Wat Kepler betreft geeft Ciell hieronder al een mogelijke reden aan. Dat zou betekenen dat het aantal unieke gebruikers (lezers) aanzienlijk lager is dan het bruto aantal gebruikers daar een groot deel van de bezoeken werd veroorzaakt door 1 gebruiker ('n bot). --Sb008 (overleg) 5 jan 2022 02:42 (CET)Reageren
Wikimedia registreert geen individuele bezoekers. Wie een artikel in de top tien wil krijgen, legt op 1 januari een baksteen op de F5-toets en gaat op wereldreis →bertux4 jan 2022 23:18 (CET)Reageren
Daar waar "checkuser" bestaat is het ook mogelijk om een lijst te maken op basis van (geanonimiseerde) unieke gebruikers. --Sb008 (overleg) 5 jan 2022 02:15 (CET)Reageren
Van bewerkers worden de gegevens bewaard, maar van passieve bezoekers toch niet? In elk geval mag Wikimedia de checkuser-gegevens onder AVG alleen verwerken voor statistieken als dat doel kenbaar is gemaakt aan de gebruikers. Dat zal niet het geval zijn →bertux5 jan 2022 06:48 (CET)Reageren
Wij leggen aan de serverkant automatisch gegevens vast welke pagina bezocht wordt en hoe vaak, zie de privacy-policy (hulp met de nl-vertaling bijwerken is welkom!), maar dit betekent niet dat ze tot op de persoon teruggeleid worden. Dat zou in potentie misschien kunnen, maar met welk nut? Voor de softwareontwikkeling is het interessant om gedrag van gebruikers te zien: komen ze vanaf laptop of mobiel, internetpagina of de app, met welke browser en welk besturingssysteem. Deze kennis kunnen we gebruiken om de software en de gebruikerservaring te verbeteren, en dient zo ons doel ('toegang tot de som van alle menselijke kennis'). Checkusers hebben volgens mij ook geen zicht op gedetailleerde bezoekers-informatie, maar eventueel wel op de algemene activiteit vanaf accounts en ip's. Ciellneed me? ping me!5 jan 2022 13:11 (CET)Reageren
(na bwc) Een HTTP server logt elk HTTP(S) request zonder aanzien van de client (gebruiker) en diens hoedanigheid (actief/passief). Vanuit het oogpunt van (systeem)beveiliging tegen aanvallen, systeemperformance e.d. wordt er van alles gelogd. Alleen al het feit dat er een lijst is van de meest bezochte pagina's toont aan dat er e.e.a. wordt bijgehouden. Of is het misschien een lijst van meest bezochte pagina's door alleen actieve gebruikers? Een ander verhaal is wat met al die gegevens wordt gedaan (verdere verwerking) en wie toegang heeft tot die gegevens. Daarbij komt i.d.d. de AVG om de hoe kijken. Daarom had ik het dan ook over "is mogelijk". --Sb008 (overleg) 5 jan 2022 13:16 (CET)Reageren
Ter aanvulling, de facto verplicht de AVG zelfs tot het bijhouden van allerlei gegevens. De AVG stelt namelijk dat je verplicht bent om de noodzakelijke technische maatregelen (voorzieningen) te treffen om de data van gebruikers te beschermen. Het is lastig beschermen wanneer je geen inzicht kan krijgen in hoe derden proberen onrechtmatig toegang tot gegevens te krijgen. --Sb008 (overleg) 5 jan 2022 13:30 (CET)Reageren
Het gerucht gaat dat Max er nachten niet van heeft kunnen slapen dat hij door die verplaatsing niet bovenaan is geeindigd. Zoals elke goede sporter dat betaamt, wil hij/zij altijd bovenaan eindigen. --Sb008 (overleg) 5 jan 2022 13:35 (CET)Reageren
Een soortgelijk probleem bestaat ook bij de hieronder besproken pageview-tool. Volgens mij wordt iedere keer dat je het browservenster ververst, CTRL-F5, dit geregistreerd als een pageview. Leuk als veel gebruikers een pagina lange tijd in een tab geopend houden. Dat zal bij de hier genoemde ranking ook wel het geval zijn. Wickey (overleg) 6 jan 2022 11:52 (CET)Reageren
Ik laat pagina's soms weken openstaan maar krijg dan de lokaal opgeslagen versie. Soms wordt die ververst als ik het tabblad open, maar niet altijd →bertux6 jan 2022 13:53 (CET)Reageren
Hangt van de browser-instellingen af (oude tabs alleen openen indien er op geklikt wordt). Iets anders is als je bij het bewerken van een artikel previews opvraagt. Als je 3 keer bewerking ter controle opvraagt zijn dat ws. 3 pageviews, zelfs als je daarna op Annuleren drukt. Wickey (overleg) 8 jan 2022 15:29 (CET)Reageren
Indeling van beoordelingspagina's
Laatste bericht: 2 jaar geleden16 berichten8 personen in overleg
De druk daar is minder, en er gaat wel eens een week voorbij zonder dat er iets gebeurt. Lijkt mij dus niet nodig. — Zanaq(?)6 jan 2022 10:26 (CET)Reageren
Logisch, Erik! Mij zijn geen klachten bekend en de stroom van nieuwelingen die hun nominatie niet konden vinden is opgedroogd. Dan kan meteen de techniek overgenomen worden, zodat de opgegeven reden boven het artikel én op de nominatielijst komt, zonder dubbel werk →bertux6 jan 2022 10:29 (CET)Reageren
Waar ik in feite voor pleitte, is om vergelijkbare pagina's een vergelijkbare lay-out te geven. Dat is zeker rustiger en consequenter voor de (beginnende) Wikipediaan, maar het lijkt me ook voor degenen die een nominatie doen en de moderatoren handiger als op al die plekken hetzelfde wordt gewerkt. Wat daar nog als voordeel bij komt, is dat het dan mogelijk wordt om naar een specifieke nominatie te verwijzen. Zo kwam ik hier eigenlijk op: Ik wil bv. verwijzen naar de samenvoegnominatie van het artikel Status aparte en dan kom ik niet verder dan een verwijzing naar Wikipedia:Samenvoegen/202112, en dan moet de lezer maar zelf verder zoeken. Op WP:TBP kun je veel specifieker verwijzen. Erik Wannee (overleg) 6 jan 2022 16:55 (CET)Reageren
Afhandeling
Het bevalt op zich, maar ik zou willen aanbevelen de {{su}} onder het kopje te plaatsen, zeker als de discussie boven het kopje nog loopt. Het is gebruikelijk een reactie gewoon onderaan te kunnen plaatsen, en de su verhindert dat, en is ook niet te zien in de voorschouwing. — Zanaq(?)6 jan 2022 10:26 (CET)Reageren
Laat het ajb zoals het nu is. Die ene keer dat er per ongeluk een reactie verkeerd komt te staan, weegt m.i. niet op tegen het gepriegel en gezoek onder titelkopjes. En het ziet er ook vreemd uit als de naam van het artikel buiten het groene vlak valt. Thieu1972 (overleg) 6 jan 2022 13:49 (CET)Reageren
Dat ziet er helemaal niet vreemd uit. Als elke nominatie gewoon afzonderlijk gesjabloniseerd wordt bij de afhandeling dan hoeft er nooit gezocht noch gepriegeld te worden. (Die markering in bulk is een overblijfsel van de oude lijst. Nu we individuele kopjes hebben is er mi geen reden dat te willen handhaven.) — Zanaq(?)6 jan 2022 13:50 (CET)Reageren
Ik vind het er wel vreemd uitzien. Los daarvan: ik heb maar 1x gezien dat iemand last had van die code, en dat was jij. Om daar nou een werkwijze voor te gaan passen? Ik heb geen last van die <su> en <einde> op de plekken waar ze nu staan - en uiteindelijk ben ik het drukst bezig met die pagina's en die codes. Thieu1972 (overleg) 6 jan 2022 16:18 (CET)Reageren
Ik vind het er helemaal niet vreemd uitzien. Uiteraard staan moderatoren ten dienste van de gemeenschap en niet andersom. Bovendien is het waarschijnlijk zelfs eenvoudiger voor de moderator. Je hoeft niet te zoeken naar de tags, maar kan gewoon bij het afhandelen van de nominatie, als je toch al een evaluatie typt, meteen de sjablonen meenemen, zonder rekening te hoeven houden met andere plekken en sluiten en zo. — Zanaq(?)6 jan 2022 16:36 (CET)Reageren
Ten dienste van de gemeenschap inderdaad, niet ten dienste van Zanaq. En nee, dit is niet eenvoudiger voor mods, ik sluit mij aan bij Thieu1972. Natuur12 (overleg) 6 jan 2022 20:49 (CET)Reageren
Een onbeargumenteerd bezwaar dat neigt naar een persoonlijke aanval. Als we gewoon op basis van de feiten zouden handelen..... — Zanaq(?)8 jan 2022 11:48 (CET)Reageren
Veel waarde heeft dat argument inderdaad niet, maar merk op dat dat ook voor het tegenovergestelde argument geldt. — Zanaq(?)8 jan 2022 23:43 (CET)Reageren
Gebruiker:2001:1C01:4510:2E00::/64
Laatste bericht: 2 jaar geleden7 berichten5 personen in overleg
Deze gebruiker heeft zoals vele anderen een IPv6 adres dat regelmatig veranderd. Van je provider krijg je een prefix, dat zijn de eerste vier getallen van het IP-adres. Voor de privacy wordt echter het laatste deel regelmatig volkomen willekeurig veranderd zodat je moeilijker te volgen bent op het internet. Voor de Mediawiki software ben je dan weer een andere gebruiker als het IP-adres veranderd. Je krijgt dus ook geen melding van een nieuw bericht op je overlegpagina bij een ander IP-adres. Deze gebruiker heeft sinds 5 januari weer een nieuw IP-adres en kreeg dus keurig een welkomstbericht op de overlegpagina. Met de prefix is deze gebruiker echter wel traceerbaar binnen Wikipedia. Als je de prefix afsluit met ::/64 kun je alle bijdragen bekijken die vanaf die prefix zijn gedaan.
Dit is een gebruiker die sinds een paar jaar regelmatig aanpassingen doet in artikelen over TV-programma's en de deelnemers daaraan. Vaak veranderd die enkele getallen waarbij het bijna onmogelijk is te achterhalen of dat klopt, maar ook worden bewerkingen gedaan waarbij je meteen kunt concluderen dat ze juist zijn. Voor deze gebruikers zou het beter zijn om één centrale overlegpagina aan te maken, bijvoorbeeld Overleg_gebruiker:2001:1C01:4510:2E00::/64, zodat je een beter overzicht krijgt van de geschiedenis van de gebruiker. Behanzane (overleg) 6 jan 2022 14:18 (CET)Reageren
Dat wordt ook wel gedaan, maar automatisch zou beter zijn. Bij de juiste instelling van je voorkeuren kun je ook een gebundelde bijdragenlijst krijgen →bertux6 jan 2022 14:54 (CET)Reageren
Kijk even onderaan de OP van een willekeurige moderator, en daar vind je op dit moment een mededeling dat er binnenkort zal worden opgehouden met het tonen van IP's. Dat wordt namelijk om redenen van privacy niet meer heel kies gevonden. Niet ingelogde gebruikers die een bewerking doen krijgen binnen afzienbare tijd een willekeurig label (waarvan ik aanneem dat het per IP wel hetzelfde zal blijven). Als de softwareontwikkelaars gis zijn, dan doen ze iets met die /64 range, zodat bijvoorbeeld de lijst van bovenstaande bewerkingen aan één label wordt gekoppeld. Ik ga er niet over, dus vraag hier de ontwikkelaars eens naar. WIKIKLAASoverleg6 jan 2022 21:02 (CET)Reageren
De voorgestelde naam (met provider prefix) kan/zal ertoe leiden dat berichten van verschillen gebruikers bij dezelfde provider worden samengevoegd op dezelfde OP.
Het voorgestelde label (moderatorbericht) is niet alleen gebaseerd op IP maar ook op e.g. informatie in het cookie. Het is een sessielabel. Wanneer iemand zijn cookie verwijderd zal er een ander label tot stand komen. --Sb008 (overleg) 6 jan 2022 21:15 (CET)Reageren
Een abonnee krijgt minimaal een hele prefix van de provider, meestal nog minder zodat die zelf nog meerdere prefixen kan aanmaken binnen het netwerk. Alleen gebruikers die hetzelfde abonnement delen hebben waarschijnlijk dezelfde prefix. Maar in ieder geval mooi dat er nu concrete stappen worden gezet in de Mediawiki software. Hopelijk niet een label dat volledig op cookies gebaseerd is, veel browsers hebben tegenwoordig de mogelijkheid om bepaalde cookies niet op te slaan of te verwijderen na een sessie. Behanzane (overleg) 7 jan 2022 10:41 (CET)Reageren
En wie helemaal grondig te werk gaat kan bv Cookie AutoDelete installeren in de browser: dan kan er bijvoorbeeld ingesteld worden dat alle cookies verwijderd worden, bv met het wegklikken van een pagina. Voor mijn gemak heb ik Wikipedia op de whitelist gezet, zodat die cookies blijven staan. Maar terug naar het onderwerp van dit kopje: de privacy van gebruikers verbeteren lijkt me prima, maar misbruik moet natuurlijk bestreden kunnen worden. Ik hoop dat het gemakkelijker wordt op bij wisseling van IP-adres door een structurele vandaal dit toch als één groep te kunnen volgen op een of andere manier. Romaine (overleg) 7 jan 2022 11:39 (CET)Reageren
Een provider kan niet meerdere prefixen creeren. Wel kan hij we voor kiezen om zijn prefix deel op te splitsen in meerdere delen (subnetwerken). Dit resulteert in schijnbaar meerdere prefixen. Dit gebeurt met de zogenaamde network mask. Dit is everigens niets nieuws en werd met IPv4 ook al toegepast. Deze opdeling hoeft helemaal niet zo te zijn dat dit gebeurt op basis van gebruikers met hetzelfde abonnement. Dit is eerder gekoppeld aan de fysieke inftastructuur zodat routeringsregels zo eenvoudig mogelijk kunnen blijven. Zie het maar als onze postcodes. De post wil ook graag post naar postcodes die met dezelfde getallen beginnen initieel naar dezelfde locatie sturen. Dus e.g. alles dat met 11 begint naar A'dam en niet 1101 naar Groningen, 1102 naar Vlissingen, 1103 naar Den Helder en 1104 naar Maastricht. Veel eenvoudiger voor de sorteer (routeer) machines. Bij telefoonnummers voor vaste lijnen zien we hetzelfde. Een telefoonnummer kan daarom wel meegenomen wanneer men bij verhuizing op dezelfde wijkcentrale blijft aangesloten maar niet bij een verhuizing naar de andere kant van het land. --Sb008 (overleg) 8 jan 2022 22:15 (CET)Reageren
Stemmen voor de WikiUilen: laatste uren
Laatste bericht: 2 jaar geleden2 berichten2 personen in overleg
Beste mensen,
Voor iedereen die deze kans bijna gemist heeft: om middernacht (CET) eindigt de mogelijkheid om te stemmen voor de WikiUilen. Heb je je kans nog niet gegrepen, kijk dan op Wikipedia:WikiUilen/Projectpagina/Nominaties voor de genomineerden en de wijze waarop ook jij stemmen.
Laatste bericht: 2 jaar geleden12 berichten6 personen in overleg
Dag allen, het valt mij de laatste tijd op dat YouTube en aanverwante termen inconsequent geschreven worden. Zo zie ik her en der ook wel eens Youtube of youtube voorbijkomen, terwijl het YouTube moet zijn. Indien nodig pas ik dat dan ook aan. Echter, hoe zit het met een YouTuber? Deze zie ik heel erg vaak geschreven in kleine letters, dus youtuber. Is dit iets wat zo is afgesproken of mag er gewoon flink gepoetst gaan worden? JochemPluim (Overleg) 7 jan 2022 20:02 (CET)Reageren
Ik zie het. En die link bevestigt wel de stelling van Encycloon, dat youtuber met kleine letters is, omdat het is afgeleid van het werkwoord youtuben. En YouTube is dan inderdaad met dubbele hoofdletter-constructie. Edoderoo (overleg) 8 jan 2022 11:14 (CET)Reageren
@Wikiwerner: niet per se, zie [2]: Als een samenstelling moeilijk te lezen of te begrijpen is, kunnen we de structuur verduidelijken met een koppelteken. Dus dat is ook gewoon een van hun eigen andere adviezen die ze in dit geval aanhouden. Wel wat typisch dat ze ook bij de TU niet kunnen beslissen welke van hun eigen voorschriften de voorkeur heeft. Overigens vind ik YouTubekanaal, wat volgens WNT blijkbaar de juiste spelling is, totaal niet uitzien. De Wikischim (overleg) 8 jan 2022 11:41 (CET)Reageren
Ja, die bepaling ken ik wel. Dat is echter niet aan de orde bij dit woord: het is een heel gangbaar woord, en de grens tussen de lettergrepen ligt waar die normaliter ligt: voor de k. Wikiwerner (overleg) 8 jan 2022 11:55 (CET)Reageren
Maar ook van de Taalunie mag je in principe elke samenstelling van een koppelteken voorzien. Op deze pagina, waar De Wikischim ook al naar verwees, schrijft ze: "Als een samenstelling moeilijk te lezen of te begrijpen is, kunnen we de structuur verduidelijken met een koppelteken", en het bepalen van die moeilijkheidsgraad is uiteindelijk een persoonlijke afweging, die bij de een anders zal uitvallen dan bij de ander. Zelfs schrijfwijzen als voet-bal, auto-ruit of deur-knop zijn dus niet fout, maar in de meeste gevallen uiteraard wel onwenselijk. — Matroos Vos (overleg) 8 jan 2022 17:50 (CET)Reageren
Helpen verborgen commentaren?
Laatste bericht: 2 jaar geleden12 berichten7 personen in overleg
Volgens mij lang niet altijd. Mensen doen gewoon wat ze van plan zijn, zonder ook maar 1 millimeter naar links of rechts te kijken. Hier weer zo'n tekenend voorbeeld. Zulke lieden hoef je niet aan te sporen om "focus te houden". ;) En toch kan het: ik heb ook weleens zo'n commentaar *middenin* een dergelijk 'blindheidsgevoelig' woord gezet (waardoor je het onmogelijk kunt vermijden), wat tot nu toe aardig heeft geholpen. Apdency (overleg) 8 jan 2022 14:32 (CET)Reageren
Ja. Nog beter: de vraag 'stad of niet' expliciet bespreken. Als het geen bespreking waard is, is het dan een vermelding waard? Welke bronnen noemen het een stad? Sinds wanneer? Wat is de meerwaarde boven de neutrale aanduiding 'plaats'? →bertux8 jan 2022 17:05 (CET)Reageren
Helpen verborgen commentaren? Ja! Helpen verborgen commentaren altijd? Nee! Hetzelfde geldt voor de bewerkknop bovenaan artikelen, niet iedereen heeft de vaardigheden om handig met dingen om te gaan. Romaine (overleg) 8 jan 2022 15:38 (CET)Reageren
Helpen commentaren in een overleg? Ja! Helpen commentaren in een overleg altijd? Nee! Het is me nog niet echt duidelijk wat er beter zou moeten. Apdency (overleg) 8 jan 2022 15:46 (CET)Reageren
Laten we niet vergeten af en toe (of wat vaker) out of the Wikibox te treden. ;) Vooral in ons taalgebruik is dat nogal eens aan te bevelen. Die commentaren zijn verborgen voor de gewone lezer, dat is alles. Apdency (overleg) 9 jan 2022 11:15 (CET)Reageren
Dit commentaar is bedoeld om een toekomstige bewerker even te laten nadenken voordat ze stad in dorp (of vice versa) wijzigen. Er vanuit gaan dat iedereen eerst de overlegpagina gaat doorlezen voordat ze een bewerking doen, lijkt me niet opportuun. En nu ben ik heel eerlijk: ik heb dat nog nooit gedaan, en was dat ook niet van plan. Naar mijn bescheiden mening kunnen deze commentaarhaken wel degelijk een verschil maken. Edoderoo (overleg) 9 jan 2022 11:18 (CET)Reageren
Verborgen commentaren zijn m.i. zeer functioneel en gebruikersvriendelijk: zonder dat de lezer er iets van merkt, kan met respect voor het werk van degene, die de becommentarieerde bijdrage gedaan heeft, suggesties voor verbetering gedaan worden. Wel is idd mijn ervaring dat zonder expliciete waarschuwing hierover (bijv in bewerkingssamenvatting) andere gebruikers het niet altijd opmerken en/of abusievelijk verwijderen. Ik geef die waarschuwing dan ook wanneer ik vermoed dat betrokken gebruiker(s) er niet bekend mee zijn. — Chescargot ツ (overleg) 9 jan 2022 11:28 (CET)Reageren
Helemaal mee eens dat ze functioneel kunnen zijn. Maar ik vrees dat in veel gevallen toch geldt: zouden kunnen zijn. Want ik vermoed dat men in veel gevallen hoogstens een zoveelste wikicode meent te zien waar je je niets van hoeft aan te trekken: ik heb een missie uit te voeren, en die voer ik nu uit! Ik wijt dus niets aan het commentaar of de intentie van de plaatser ervan, maar in het algemeen aan het bewerkgedrag van veel Wikipedianen, nieuw of gevestigd. Apdency (overleg) 9 jan 2022 11:43 (CET)Reageren
Wiki Loves Folklore is back!
Laatste bericht: 2 jaar geleden1 bericht1 persoon in overleg
Help met het vertalen in uw taal
You are humbly invited to participate in the Wiki Loves Folklore 2022 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.
You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.
You can also organize a local contest in your country and support us in translating the project pages to help us spread the word in your native language.
Feel free to contact us on our project Talk page if you need any assistance.
In het artikel Austla trof ik trouwens naast de bovengenoemde onbruikbare archieflink ook nog twee archieflinks aan naar de verkeerde webpagina's. Ik hoop toch niet dat al het werk van de bots gecontroleerd moet worden... Sijtze Reurich (overleg) 9 jan 2022 19:59 (CET)Reageren
Zo te zien gaat het om de bot van mij. Inderdaad is het onmogelijk om 100% te controleren op bruikbare archieflinks, zoals ik ook opmerkte bij het botverzoek dat ik aanhaal in de botbewerkingen: "Uiteraard kunnen we niet botmatig controleren of de archiefversie goed bruikbaar is, zoals bdijkstra vraagt. Aan de andere kant: hoe erg is dat? De archiefversie staat dan immers zojuist op Archive.org, en de Archivebot zal hem dan toevoegen zodra de originele URL dood wordt." Als het om veel pagina's gaat, dan kan ik misschien groepen URL's laten overslaan, bijv. alles met www.saaremaa.ee erin. Het voorbeeld in Austla lijkt op een fout in de API van Archive.org: het lijkt alsof hij het stukje 'ItemID=2953' ziet als een parameter van Archive.org zelf, i.p.v. als deel van de URL. Wikiwerner (overleg) 9 jan 2022 21:17 (CET)Reageren
Zoiets zal het inderdaad wel zijn. Maar het is nu in orde. Met die andere link is iets nog veel ingewikkelders aan de hand. De archieflink verwijst naar de verkeerde pagina, maar de originele pagina is intussen doorgekoppeld naar een soort portal en verwijst dus nu naar een andere verkeerde pagina. Gelukkig heb ik ooit een keer een archiefversie van de originele pagina gemaakt, zij het dan op Archive.today in plaats van op Archive.org. Die staat dus nu in het artikel. Archiveren loont, dat blijkt maar weer eens. Sijtze Reurich (overleg) 9 jan 2022 22:21 (CET)Reageren
Gelukkig maar dan! Ik heb het script zojuist iets aangepast. De hele originele URL moet nu terugkomen in de archief-URL, anders wordt de laatste niet geplaatst in het artikel. Wikiwerner (overleg) 9 jan 2022 22:42 (CET)Reageren
(na bws) Eigenlijk zouden we bij dit soort gegevens niet moeten verwijzen naar de ingangspagina van de statistiekgenerator , maar naar de resultaatpagina. Maar open ik die URL van de resultaatpagina in een andere browser (of anderszins zonder daaraan voorafgaand de ingangspagina te bezoeken), dan wordt er geen resultaat getoond, maar de... ingangspagina. Vanaf de resultaatpagina kan ik wel de gegevens opslaan, bijvoorbeeld als CSV-bestand. Dat bestand zou ik zelfs kunnen uploaden naar Commons. Maar gelooft iedereen dan dat het daar opgeslagen bestand daadwerkelijk direct gegenereerd is uit de betreffende statistiekbron?
Er zijn meer statistiekbureaus die (nagenoeg) dezelfde ingangspagina gebruiken, wat het erg prettig werken maakt als je gegevens uit andere landen wil benaderen. Maar het direct weer beschikbaar maken, is best lastig.
Wikiwerner vraagt of dat erg is. Ik denk dat er, als er een archieflink ingevoerd is, weinigen de moeite zullen doen om te gaan zoeken naar een betere archieflink. Op termijn kan de huidige link vervallen (ook bij nationale statistiekbureaus verandert wel eens wat) en dan vertrouwen we op die archieflink. Is dat een onbruikbare link, dan hebben we daar niets aan. Dat zou dan kunnen betekenen dat we over vijf, tien of vijftig jaar niet meer kunnen controleren wat het inwonertal van Atla (Saaremaa) was per 1 januari 2021, door linkrot.
Het niet beschikbaar stellen van archieflinks zou anderen eerder kunnen prikkelen om te zoeken naar een betere oplossing, bijvoorbeeld Statistics Estonia vragen of het ook mogelijk is om de gegevens in een 'gewaarmerkt' PDF-bestand te verkrijgen, dat in Commons kan worden vastgelegd. Vanuit dat oogpunt voel ik meer voor het negeren van links als 'andmed.stat.ee', dan voor het overspoelen van Archive.org met duizenden verzoeken om deze verder nutteloze ingangspagina op te slaan. Is ook beter voor de goodwill van Archive.org.
Het lijkt verstandig om te inventariseren of er meer van dit soort pagina's zijn. Wellicht zou de bot kunnen tellen hoe vaak bepaalde links in Wikipedia gebruikt worden en als dat meer dan tien (vijftig? honderd? duizend?) keer is, deze negeren en vragen of deze alsnog gelinkt moeten worden. Met vriendelijke groet, RonnieV (overleg) 9 jan 2022 22:43 (CET)Reageren
Bij artikelen over spinnen, waarbij de World Spider Catalog als referentie voor de taxonomie was gebruikt, zie ik regelmatig dat InternetArchiveBot een oudere versie van die Catalog als archieflink toevoegt, terwijl er dan wel een gearchiveerde versie bestaat die van net na het gebruik van de Catalog voor ons artikel dateert. Dat is ronduit onhandig. En tot mijn verbazing zag ik dat diezelfde bot nu ook Archive.org links geeft naar pagina's die wij uit de Biodiversity Heritage Library (BHL) halen. Die twee projecten zijn twee handen op één buik. Als de ene omvalt, valt de andere ook om, dus wat voor nut heeft het dan om er een extra archieflink aan toe te voegen? Te weinig nuttig werk te doen? WIKIKLAASoverleg10 jan 2022 03:16 (CET)Reageren
Wikipedia wordt genoemd! (Met etymologische nonsens)
Laatste bericht: 2 jaar geleden11 berichten5 personen in overleg
En we hebben het verdiend, want een groot deel van onze etymologische informatie is bagger als er geen betrouwbare bron bij staat.
Oproep: wees extra kritisch op zulke info, vooral als er een uitgesponnen verhaal bijhoort. Woordkunde leent zich nu eenmaal voor snelle gevolgtrekkingen en fraaie anekdotes. Bij twijfel schrappen! Ook Hugo de Groot ging de mist in (onderaan) →bertux10 jan 2022 09:37 (CET)Reageren
Maar we kunnen nu wél met z’n allen de kracht van wikipedia laten zien, door het artikel samen binnen een dag te verbouwen tot een verhaal dat wél klopt. Mét bronnen. Sietske | Reageren?10 jan 2022 10:28 (CET)Reageren
Ik heb Nicoline van der Sijs in de commentaarsectie van haar artikel al terugkoppeling gegeven over de bewerkingswoede die is losgebarsten over dit gerecht →bertux10 jan 2022 18:01 (CET)Reageren
Zou ons artikel huzarensalade niet losgekkopeld worden van het huidige wikidata-item aangezien Van der Sijs stelt dat de huzarensalade en de Russische of Oliviers salade allebei een aparte oorspong hebben? Nu is het artikel Huzarensalade dus aan deze Russische salade gekoppeld. Melvinvk (overleg) 10 jan 2022 12:57 (CET)Reageren
De enquête is de manier waarmee gemeenschappen bepalen waar het Community Tech team volgend jaar aan moet gaan werken. We moedigen iedereen aan om voorstellen in te dienen voor de deadline op 23 januari, of om te reageren op andere voorstellen om ze te helpen verbeteren.
De gemeenschappen stemmen op de voorstellen tussen 28 januari en 11 februari.
Het Community Tech team is gefocussed op hulpmiddelen voor ervaren Wikimedia bewerkers. U kunt voorstellen in elke taal opstellen en wij vertalen deze. Bedankt en we kijken uit naar uw voorstellen! SGrabarczuk (WMF) (talk) 10 jan 2022 19:15 (CET)Reageren
Tips voor schrijven voor mobiele devices?
Laatste bericht: 2 jaar geleden22 berichten9 personen in overleg
Collegae, er kwam een vraag bij me op die ik graag aan jullie voorleg. Wikipedia wordt meestal geraadpleegd op een mobiel apparaat, ook door mij. Die smartphone heb ik tenslotte onder handbereik. Bewerken doe ik daarentegen op een laptop. Ik zit daarbij nogal eens te prutsen totdat een artikel er qua lay-out netjes uitziet. Maar ik heb er geen zicht op of dat op een smartphone of tablet ook zo is. Er zal een hele berg software zijn die artikelen ombouwt voor weergave of mobiele devices, maar ik heb geen idee hoe dat gaat. Uiteraard zie ik graag dat het resultaat, met de beperkingen van een kleiner scherm, ook netjes is. Mijn vraag: is er een pagina met tips over hoe ik dat kan bevorderen? Mvg, MartinD (overleg) 10 jan 2022 21:16 (CET)Reageren
Dat is ook altijd iets wat ik meteen ongedaan maak... voor een mobiele weergave is het inderdaad fijner om met een inleiding te beginnen, maar op een desktop/laptop is dat juist spuuglelijk en niet zelden zelfs hinderlijk omdat je dan een enorm brede inleiding krijgt. Dqfn13 (overleg) 10 jan 2022 22:53 (CET)Reageren
De meeste browsers hebben een "Responsive Design-modus" waarin een klein scherm geëmuleerd wordt. Vink dat aan en ververs je pagina; je ziet dan een pagina op telefoon/tablet grootte met bijbehorende layout. (De meest browsers bieden ook een mogelijkheid om een telefoon- of tablettype te kiezen).P.wormer (overleg) 11 jan 2022 10:43 (CET)Reageren
Die terreur van infoboxen helemaal bovenaan artikelen heb ik altijd al heel ergerlijk gevonden. Wikipedianen werken ongetwijfeld meestal met een breedbeeldmonitor en hebben daardoor niet in de gaten hoe het er op een klein beeldscherm uitziet. Ik raad ze aan regelmatig eens hun browservenster op halve breedte te zetten.
Infoboxen reiken in smallere vensters vaak to ver beneden de TOC en verstoren zo de layout van het artikel. Zelfs een afbeelding wordt naar beneden gedrongen. Hetzelfde probleem bij een serie afbeeldingen bovenaan het artikel. Wickey (overleg) 11 jan 2022 10:28 (CET)Reageren
Heb je voorbeeld van pagina? Ik kan dit niet echt repliceren, behalve dat een smal beeldscherm zonder mobiele weergave sowieso niet ideaal is. Dajasj (overleg) 11 jan 2022 10:31 (CET)Reageren
Ik heb natuurlijk geen lijstje paraat, maar hier is een voorbeeld. Het speelt vooral bij korte artikelen met een korte TOC en een lange infobox. Als iemand op het idee komt om er twee onder elkaar te zetten gaat het al snel mis. En wat spuuglelijk is is vanzelf nogal persoonlijk.
Automatische media-selectie via software/browser werkt natuurlijk niet bij twee vensters naast elkaar op één scherm. De boxen onder de intro zetten zou al schelen voor de leesbaarheid van de intro. Dan wordt i.i.g. de intro-afbeelding niet weggedrukt. Wickey (overleg) 11 jan 2022 15:33 (CET)Reageren
Dan ben ik dus het zijmenu, de overzichtelijke werkbalk, de knoppen voor broncodebewerking en de cats kwijt. En de TOC is ingeklapt. En ging dit item niet over een al bestaand probleem? Wickey (overleg) 11 jan 2022 17:34 (CET)Reageren
Op een mobiel is een overdaad aan afbeeldingen vooral lelijk. voorbeeldje Feest- en gedenkdagen. De afbeelding in de Infobox vind ik niet zo hinderlijk, aangezien de overige info van infobox in de app ingeklapt is. Ldhank (overleg) 11 jan 2022 17:25 (CET)Reageren
Ik weet niet of er verschillende infoboxen zijn die wel of niet automatisch ingeklapt zijn, maar de afbeeldingen daarin zijn dwingend opgelegd. Default wordt geloof ik de afbeelding uit Wikidata afgebeeld en het is niet mogelijk die helemaal weg te laten.
Het plaatsen boven de intro is een principieel probleem. Liefhebbers van infoboxen overschatten de waarde ervan en denken dat ze de ruggegraat van het artikel horen te zijn. In werkelijkheid zijn ze onflexibel, ongenuanceerd en eenzijdig en vaak ook misleidend. Met name militaire en geschiedenis-boxen zijn een bron van propagandistische conflicten. Ze behoren dus zeker niet aan het begin te staan. Wickey (overleg) 12 jan 2022 11:29 (CET)Reageren
Volgens mij worden bij de meeste infoboxen de afbeeldingen niet van Wikidata gehaald. Ik kan me voorstellen dat jij geen fan bent van infoboxen, maar het is wel een middel om een overzicht te geven van het beschrevene. Dat dat vervolgens een bron is voor propaganda, lijkt me beter om case by case aan te pakken. Dajasj (overleg) 12 jan 2022 11:34 (CET)Reageren
De plaatsing boven de intro, hetgeen al sinds het begin van infoboxen (op alle Wikipedia's) zo wordt gedaan, is om een hele praktische reden: in een gewoon beeldscherm staat het lelijk om eerst een of meerdere regels intro te zien en daarna pas de infobox. Daarnaast dienen infoboxen om de kernfeiten uit een artikel samen te vatten, die staat logischerwijs bovenaan, onderaan of in het midden is niet logisch: wie op zoek is naar die kernachtige feiten wil die meteen zien. En voor die breedte zijn de artikelen in die versie beschikbaar, want voor mobiele apparaten is de mobiele versie van Wikipedia. Wie niet tevreden is met die mobiele versie, moet niet gaan klagen dat op een mobiel apparaat in de gewone versie de infoboxen niet lekker werken. Als er functionaliteiten in de mobiele versie ontbreken die wel nodig zijn, kan daarvoor een verzoek gedaan worden om die toe te voegen.
Dat er liefhebbers op deze Wikipedia zouden rondlopen die denken dat infoboxen de ruggengraat van een artikel vormen is grote kolder. Ik heb nog nooit ook maar iemand dat horen zeggen. En als iemand dat wel ooit gezegd heeft, heeft diegene niet begrepen waar het op Wikipedia om draait. Ik vraag me af waarom dit verzinsel rondgestrooid wordt. Duidelijk is mijn inziens wel dat dit voorbij gaat aan het onderwerp onder dit kopje: tips voor het schrijven op mobiele apparaten. Laten we maar naar dat onderwerp terugkeren. Romaine (overleg) 12 jan 2022 12:27 (CET)Reageren
Kernpunten die voor de samenvatting van belang zijn staan daar al vermeld. De infobox geeft een onnodige herhaling daarvan plus een vloed van kernfeiten die voor de samenvatting helemaal niet van belang zijn. Die kunnen net zo goed verderop komen. Daarnaast gaan ze maar al te vaak helemaal niet over het artikel zelf, geven ze een onvolledig beeld, worden er dubieuze cijfers uit geselecteerd of staan er feiten in die helemaal niet in het artikel staan vermeld.
Dat ze vanwege de layout altijd al bovenaan hebben gestaan is ook maar een verzinsel. Als op een desktop/laptop de intro er lelijk uitziet vanwege lange regels heb je gewoon je browser te breed afgesteld, wat leestechnisch sowieso ongustig is. Wickey (overleg) 12 jan 2022 15:29 (CET)Reageren
Een gedachte is dat als men de oppervlakte van bv een gemeente wil weten men niet in de tekst daarnaar hoeft te zoeken, maar dat dergelijke kerngetallen in de infobox op een rijtje staan. Dat het daarmee dubbel staat omdat het in de tekst ook wordt genoemd (infobox is immers geen vervanger van informatie) is niet erg, het is een andere vorm waarin de feiten worden weergegeven. De infobox vervult met dat overzicht een behoefte die er bij lezers bestaat die op zoek zijn naar deze informatie. Dat de infobox niet in jouw informatiebehoefte ziet mag natuurlijk.
"Daarnaast gaan ze maar al te vaak helemaal niet over het artikel zelf" -> Ik heb de afgelopen jaren vrijwel alle infoboxen gezien en ik heb in géén een parameters gezien die niet over het onderwerp gaan.
"worden er dubieuze cijfers uit geselecteerd" -> In principe worden alleen betrouwbare cijfers geselecteerd. Als er onbetrouwbare cijfers gebruikt zijn is dat iets wat om aanpassing vraagt.
"staan er feiten in die helemaal niet in het artikel staan vermeld" -> Dit komt soms helaas voor en ik heb er meermaals gebruikers op aangesproken dat een infobox géén vervanging van informatie is in de artikeltekst zelf.
"Dat ze vanwege de layout altijd al bovenaan hebben gestaan is ook maar een verzinsel." -> Absoluut niet, ik kan me nog discussies hierover herinneren.
"Als op een desktop/laptop de intro er lelijk uitziet vanwege lange regels heb je gewoon je browser te breed afgesteld" -> Dit is onjuist, duizenden computers hebben een breder beeldscherm en dat staat los van de instellingen. Romaine (overleg) 13 jan 2022 10:58 (CET)Reageren
Laatste bericht: 2 jaar geleden4 berichten4 personen in overleg
Ik kreeg net deze melding, kan ik hier iets mee of is het eerder een soort spam? Het kwam wel via het officiële kanaal binnen maar je moet al je accountgegevens overdragen als je je wilt aanmelden. B kimmeloverleg10 jan 2022 22:20 (CET)Reageren
Als ik het goed heb, dan levert dat toegang tot vele tijdschriften en boeken die anders betaald zouden moeten worden. Voor ons Wikimedianen zijn er gratis toegangen geregeld, vandaar dat er accountgegevens opgegeven moeten worden; ter verificatie dat lezer echt een Wikimediaan is. Maar, ik heb graag dat iemand van Wikimedia Nederland of een andere persoon met meer kennis van dit onderwerp meer uitleg geeft. Dqfn13 (overleg) 10 jan 2022 22:50 (CET)Reageren
Oh, wow, dat is geweldig, dat zoiets soms geregeld wordt! Ik had er nog nooit van gehoord. Ik hoop ook dat iemand van of nabij Wikimedia Nederland er meer over kan vertellen. Laurier (overleg) 11 jan 2022 07:57 (CET)Reageren
Wat mij opvalt is de grote aanwezigheid van internationale literatuur. Tegelijkertijd ben ik maar weinig lokale literatuur gezien. Als we meer literatuur uit het Nederlands taalgebied willen zullen we daar toe zelf initiatief gaan nemen denk ik. Romaine (overleg) 11 jan 2022 12:15 (CET)Reageren
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
A oauth_consumer variable has been added to the AbuseFilter to enable identifying changes made by specific tools. [3]
Gadgets are now able to directly include JSON pages. This means some gadgets can now be configured by administrators without needing the interface administrator permission, such as with the Geonotice gadget. [4]
Gadgets can now specify page actions on which they are available. For example, |actions=edit,history will load a gadget only while editing and on history pages. [5]
Gadgets can now be loaded on demand with the withgadget URL parameter. This can be used to replace an earlier snippet that typically looks like withJS or withCSS. [6]
Four special pages (and their API counterparts) now have a maximum database query execution time of 30 seconds. These special pages are: RecentChanges, Watchlist, Contributions, and Log. This change will help with site performance and stability. You can read more details about this change including some possible solutions if this affects your workflows. [10]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 January. It will be on non-Wikipedia wikis and some Wikipedias from 12 January. It will be on all wikis from 13 January (calendar).
Events
Community Wishlist Survey 2022 begins. All contributors to the Wikimedia projects can propose for tools and platform improvements. The proposal phase takes place from 10 January 18:00 UTC to 23 January 18:00 UTC. Learn more.
Laatste bericht: 2 jaar geleden1 bericht1 persoon in overleg
Help met het vertalen in uw taal
Greetings! You are invited to participate in Feminism and Folklore 2022 writing competion. This year Feminism and Folklore will focus on feminism, women biographies and gender-focused topics for the project in league with Wiki Loves Folklore gender gap focus with folk culture theme on Wikipedia.
You can help us in enriching the folklore documentation on Wikipedia from your region by creating or improving articles focused on folklore around the world, including, but not limited to folk festivals, folk dances, folk music, women and queer personalities in folklore, folk culture (folk artists, folk dancers, folk singers, folk musicians, folk game athletes, women in mythology, women warriors in folklore, witches and witch hunting, fairy tales and more. You can contribute to new articles or translate from the list of suggested articles here.
You can also support us in organizing the contest on your local Wikipedia by signing up your community to participate in this project and also translating the project page and help us spread the word in your native language.
Learn more about the contest and prizes from our project page. Feel free to contact us on our talk page or via Email if you need any assistance...
Laatste bericht: 2 jaar geleden1 bericht1 persoon in overleg
Als alles goed gaat gaan ingelogde bewerkers vanaf later vandaag een banner zien met de oproep om mee te doen aan de NLWP Bewerkerssurvey 2022. Het is de vierde keer dat Wikimedia Nederland deze survey organiseert; eerdere edities waren 2013, 2015 en 2018. Doel van de survey is om meningen van de Nederlandstalige bewerkersgemeenschap te peilen en om de samenstelling van de gemeenschap in kaart te brengen. De vragenlijst 2022 is sterk gebaseerd op die van de vorige editie. Daarnaast gaan we dit jaar gaan in het bijzonder in op de meningen van de gemeenschap over de neutraliteit van Wikipedia, een belangrijk thema in een tijd van fake news. Bij het totstandkomen en testen van de vragenlijst zijn zoals altijd een aantal bewerkers betrokken geweest - hartelijk dank voor jullie hulp! Sandra Rientjes - Wikimedia Nederland (overleg) 11 jan 2022 10:14 (CET)Reageren
Laatste bericht: 2 jaar geleden7 berichten4 personen in overleg
Ik schreef vorige week het artikel Slag om Heartbreak Ridge (een vertaling). Er stond in de verzochtepagina-oproep hier bovenaan in de kroeg (die oproep is nu weg) dat er ook een Nederlands aspect (troepen geleverd of zo?) aan was maar ik vond in Delpher niets specifieks daarover. Vindt iemand het leuk er even naar te kijken en dit aan te vullen? Tedkişi (overleg) 11 jan 2022 10:50 (CET)Reageren
Sorry dat was dan waarschijnlijk mijn vergissing. Ik dacht dat de link inmiddels was vervuld. Maar als het lemma verbeterd dient te worden, dan hoort het mi wellicht meer thuis onder het kopje te verbeteren ipv aan te maken. Melvinvk (overleg) 11 jan 2022 13:04 (CET)Reageren
Het artikel bestond niet voor Tedkişi het recent aanmaakte. Ik vind het bijzonder positief dat hij vervolgens het artikel beter wilt maken dan het Engelstalige artikel en daarvoor wat hulp vraagt. The Bannertalk11 jan 2022 14:54 (CET)Reageren
Wijzigen van een gebruikerspagina door een anoniem
Laatste bericht: 2 jaar geleden8 berichten3 personen in overleg
Beste, ik had daar een vraagje m.b.t. wijzigingen van een Gebruikerspagina door een anoniem. Kan dit volgens de policy van Wikipedia, en geldt dit voor alle projecten? Thanks. Lotje (overleg) 12 jan 2022 10:21 (CET)Reageren
In principe is de bewerking van een gebruikerspagina van een andere gebruiker toegestaan, maar alleen met grote terughoudendheid (want beschrijft die gebruiker waar een ander maar weinig inzicht in heeft). Het komt regelmatig voor dat een gebruiker uitgelogd was toen die een bewerking deed op de eigen gebruikerspagina. Als het er daar naar uit ziet zou ik niets doen of de desbetreffende gebruiker even een berichtje sturen. Is de wijziging discutabel, is terugdraaien wellicht het beste en een berichtje aan de gebruiker om wiens gebruikerspagina het gaat. Romaine (overleg) 12 jan 2022 13:34 (CET)Reageren
Het is gewoon SVG. Wat voor instructies zoek je precies? Merk op dat je de dynamische functionaliteit niet kan gebruiken voor afbeeldingen op mediawiki-pagina's. — Zanaq(?)13 jan 2022 09:55 (CET)Reageren
Instructies hoe je clickable SVG maakt, en hoe je die op Wikimediapagina's kon gebruiken :-). Maar dat is dus blijkbaar iets voor de wishlist. Milliped (overleg) 13 jan 2022 11:52 (CET)Reageren
The Call for Feedback: Board of Trustees elections is now open and will close on 7 February 2022.
With this Call for Feedback, the Movement Strategy and Governance team is taking a different approach. This approach incorporates community feedback from 2021. Instead of leading with proposals, the Call is framed around key questions from the Board of Trustees. The key questions came from the feedback about the 2021 Board of Trustees election. The intention is to inspire collective conversation and collaborative proposal development about these key questions.
There are two confirmed questions that will be asked during this Call for Feedback:
What is the best way to ensure more diverse representation among elected candidates? The Board of Trustees noted the importance of selecting candidates who represent the full diversity of the Wikimedia movement. The current processes have favored volunteers from North America and Europe.
What are the expectations for the candidates during the election? Board candidates have traditionally completed applications and answered community questions. How can an election provide appropriate insight into candidates while also appreciating candidates’ status as volunteers?
There is one additional question that may be presented during the Call about selection processes. This question is still under discussion, but the Board wanted to give insight into the confirmed questions as soon as possible. Hopefully if an additional question is going to be asked, it will be ready during the first week of the Call for Feedback.
Laatste bericht: 2 jaar geleden3 berichten3 personen in overleg
Het team van NOS op 3 heeft vanochtend een ruim 9 minuten durende thema-video op de website geplaatst, zie hier. Helaas zit er op deze video geen edit-knop zodat kleine foutjes er in blijven ("stichting Wikipeida") maar wel erg leuk. Ook nodigen ze en passant de kijker uit de pagina over hun eigen programma te verbeteren, zo te zien zijn daar inmiddels al mensen mee aan de slag. 2001:983:F8EA:1:750B:2BBB:BA8F:A83A15 jan 2022 09:25 (CET)Reageren
Laatste bericht: 2 jaar geleden2 berichten2 personen in overleg
Ik merkte bij uitbreiden van wat artikel dat er een nieuwe feature actief is geworden. Bij het linken van een artikel(naam) dat een doorverwijspagina is naar meerdere betekenissen kreeg ik een pop-up-venster die dat aangeeft en vervolgens kan je of de doorverwijspagina bekijken of kiezen welk artikel je eigenlijk wilde linken. Erg handig. DagneyGirl (overleg) 15 jan 2022 11:19 (CET)Reageren
.jpg)
Steun Hans Erren (overleg) 3 jan 2022 11:14 (CET)
..LesRoutine..(overleg) 5 jan 2022 13:19 (CET)
Erik Wannee (overleg) 6 jan 2022 10:21 (CET)
Erik Wannee (overleg) 6 jan 2022 16:55 (CET)
JochemPluim (
Overleg) 7 jan 2022 20:02 (CET)
JochemPluim (
Overleg) 8 jan 2022 00:13 (CET)
B kimmel overleg 10 jan 2022 22:20 (CET)
A 
The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 January. It will be on non-Wikipedia wikis and some Wikipedias from 12 January. It will be on all wikis from 13 January (calendar).
.jpg){kind=link}
