Wikipedia:De kroeg/Archief/20220610

(in English) Stavers Belang

The photographer did not say what this sculpture in Stavoren means. I guess it is a sculpture saying that this place was once a train ferry. Could somebody tell me what is it? Johnson.Xia (overleg) 22 mei 2022 00:32 (CEST)

According to this page, it is indeed a memorial of the train ferry. –bdijkstra (overleg) 22 mei 2022 01:37 (CEST)

@Johnson.Xia, I'm not familiar to this memorial. What I've read it's a memorial to the Veerdienst Enkhuizen - Stavoren. Dqfn13 (overleg) 22 mei 2022 21:39 (CEST)

Thank you! You provided crucial information! Johnson.Xia (overleg) 23 mei 2022 02:11 (CEST)

According to your information, I changed the description for this picture:

"Project "Stavers Belang", a memorial in Stavoren, Netherland for Enkhuizen - Stavoren train ferry. Between 1886 and 1936, Goods wagons were shipped from and to Enkhuizen at the opposite bank of Lake IJssel through this ferry." Johnson.Xia (overleg) 23 mei 2022 02:35 (CEST)

@Johnson.Xia: I think, there is some confusion here. The memorial is not called "project Stavers Belang". It actually is a project of the organization with name "Stavers Belang", which is translated like "Interest of Stavoren". By renaming the files and the catogory on Commons, Wikipedia now accidentally introduced a (new) name for the memorial which might be called "Replica Pontgat Stavoren" by the artist [1] or apparently has no name at all. I think it's better to change that. Thanks, Brimz (overleg) 23 mei 2022 11:34 (CEST)

I will tell the photographer of this picture that it should not be called Project "Stavers Belang". Also, I changed the description as this: "This is a memorial in Stavoren, Netherland for Enkhuizen - Stavoren train ferry. Between 1886 and 1936, Goods wagons were shipped from and to Enkhuizen at the opposite bank of Lake IJssel through this ferry." Johnson.Xia (overleg) 28 mei 2022 23:40 (CEST)

2022 WMF Board of Trustees Call for Candidates closed

You can find this message translated into additional languages on Meta-wiki.

Meer talen • Help met het vertalen in uw taal

The 2022 Board of Trustees election Call for Candidates has now closed. The Call led 12 candidates from the community to submit their applications. Learn more about the 2022 Board of Trustees candidates.

The Analysis Committee will now consider the candidates’ applications with the skills and criteria provided by the Board. The trustees seek certain skills and competencies to improve the capacity of the Board. After the Analysis Committee completes their review, the ratings of each candidate will be published. These ratings are for informational purposes only.

For more information about the 2022 Board election, you may find the timeline, voting information and other ways to get involved on Meta-wiki. DBarthel (WMF) (overleg) 27 mei 2022 16:20 (CEST)

Sjabloon:Multiparameters

Sjabloon {{Multiparameters}} wordt op veel pagina's gebruikt en ik heb geen idee waarvoor het dient, maar ik constateer dat je terechtkomt op een pagina over Indiase boter als je klikt op de letters 'ghi' en op een doorverwijspagina als je klikt op de letters 'abc'. Ik weet niet of dat de bedoeling is. ErikvanB (overleg) 28 mei 2022 11:36 (CEST)

Met het sjabloon kun je een opsomming in een lopende zin maken. Dat je op een artikel over boter terechtkomt, is omdat in het voorbeeld in de 'documentatie' van het sjabloon gekozen is voor drie opeenvolgende letters van het alfabet die gewoon toevallig naar een doorverwijzing leiden. It's not a bug, it's a feature. Zo te zien wordt het sjabloon niet rechtstreeks in artikelen gebruikt. Althans, het artikel Groen (partij) bijvoorbeeld zou direct naar het sjabloon verwijzen maar ik zie het in de brontekst nergens terugkomen. Het zal in andere sjablonen gebruikt worden. hiro the club is open‍ 28 mei 2022 11:58 (CEST)

Gevonden. Het sjabloon wordt (o.a.?) gebruikt in Sjabloon:Zie hoofdartikel. hiro the club is open‍ 28 mei 2022 12:01 (CEST)

Bedankt! Duidelijk. ErikvanB (overleg) 28 mei 2022 12:04 (CEST)

Interpreteren

Kan iemand aub duidelijk maken wat de consequenties zijn van wat hier beweerd wordt: [2]. Alvast dank. VanBuren (overleg) 29 mei 2022 09:41 (CEST)

Dat CU's geen IP's meer mogen delen met admins. Aangezien geen van de CU's mod is dus geen blokkades van IP's gevonden tijdens een checkuser-onderzoek meer. Tenminste, totdat de non-compliance verholpen is. Natuur12 (overleg) 29 mei 2022 10:15 (CEST)

Straks worden IP-adressen toch sowieso onzichtbaar? Zie bijv. Tech News: 2021-45 en Meta: "Our preferred approach will be to go with the session-based identity (...) While someone could delete the cookie to get a new identity, the IP would still be visible to all active vandal fighters with the new user right." Ik kan me herinneren dat de keuze voor sessie-gebaseerd inmiddels definitief is. Wat is de status van het nieuwe gebruikersrecht om toch IP-adressen te zien? Wikiwerner (overleg) 29 mei 2022 10:56 (CEST)

Mag het wat minder jargon in de kroeg? Hans Erren (overleg) 29 mei 2022 11:27 (CEST)

Fijn dat er door de OC ook zo'n handig voorstel wordt bijgevoegd om de non-compliance te verhelpen. Het kan toch niet de bedoeling zijn dat onderliggende IP's niet meer geblokkeerd worden? Hoe lossen andere taalversies dit op? WIKIKLAAS overleg 29 mei 2022 12:06 (CEST)

Ik weet niet in hoeverre een uitspraak van de OC bindend is, en of die ook aangevochten kan worden, maar volgens mij valt er wel wat af te dingen op de opvatting dat het doorgeven van een IP aan één admin, hetzelfde is als disclosure to the public. En er wordt daar ook al een uitzondering gemaakt: "(v) when it is a necessary and incidental consequence of blocking a sockpuppet or other abusive account". In het laatste geval is disclosure dus wél toegestaan. Ik zie eerlijk gezegd niet waar het doorgeven van een IP van een sokpop of een (ingelogde) vandaal aan één admin in strijd is met de policy die de OC noemt: dat wordt immers letterlijk als toegestaan genoemd. (dat IP's binnenkort niet meer zichtbaar zullen zijn, heeft hier verder niets mee te maken: voor medewerkers met speciale rechten zijn ze ook dan nog te zien.) WIKIKLAAS overleg 29 mei 2022 12:33 (CEST)

Het oplossen, daar wordt de AC kennelijk over benaderd door de WMF. Niet dat de AC daar over gaat maar goed. Sure, ze kunnen hun CU-regelement aanpassen (en ik geloof dat het gewraakte artikel ergens anders voor bedoeld is dan de OC denkt) maar daar ligt niet de oorsprong van de grief van de OC, namelijk dat mod en CU sinds het bestaan van de functies gescheiden zijn. Daarin zijn we als wiki wel uniek en dat kan ook beter. Maar zoiets regelen kost tijd. Natuur12 (overleg) 29 mei 2022 12:57 (CEST)

Een uitspraak van de OC is bindend. De uitspraak is duidelijk. Een admin is niet een checkuser en het is dus niet toegestaan om een admin ip-adres informatie te geven. Op de meeste andere taalversies worden de checkuserrechten zo goed als enkel gegeven aan moderatoren. Verder zijn checkusers vaak lid van de arbitragecommissie. Dit omdat checkuser een van de meest vertrouwde functies is en moderatoren en arbcom leden al enig vertrouwen genieten. Op de Nederlandstalige Wikipedia wil de arbcom een scheiding van functies en daarom zijn er geen moderatoren onder de checkusers. Dat heeft tot de huidige situatie geleid. Mvg, Taketa (overleg) 29 mei 2022 13:08 (CEST)

Ons CU-reglement is in 2018 opgesteld door de AC, en volgens deze bewerkingssamenvatting in overleg met de toen zittende checkusers. Er zijn perioden geweest dat ik nauwelijks actief was en ik kan dus wat gemist hebben, maar ik zie nergens evidentie dat het reglement ook met de gemeenschap is besproken. Het is dus dan de AC geweest die het huidige reglement heeft bepaald. Een reglement dat kennelijk in de ogen van de OC de toets der kritiek niet kan doorstaan op het punt waar het het uitvoeren van een blokkering van een onderliggend IP van een sokpop of een ingelogde vandaal betreft. Dat het blokkeren van een onderliggend IP wél toegestaan (en gewenst) is blijkt uit de hierboven al aangehaalde regel (v). Het probleem is dan kennelijk dat een IP niet mag worden doorgegeven aan een medewerker die de Vertrouwelijkheidsovereenkomst voor niet-publieke informatie niet heeft ondertekend. Het lijkt me dat daar een mouw aan te passen is door van de admins te verlangen om dat te doen alvorens ze het blokkeren van onderliggende IP's voor hun rekening mogen nemen. Maar ik zou het niet raar vinden als aan de OC een nadere toelichting wordt gevraagd, en hoe ze zelf hun uitspraak zien in het licht van regel (v), waarin disclosure to the public onder voorwaarden wél is toegestaan. WIKIKLAAS overleg 29 mei 2022 13:26 (CEST)

Ik was lid van de AC toen het regelement opgesteld werd. Maar de bedoeling is nooit geweest om mod en CU te verbieden, of om het CU's die mod zijn te verbieden IP's te blokkeren die voortvloeien uit een onderzoek. Ook is er nooit getracht te stellen dat mod en CU een ongewenste combi zijn. Er is wel wat over de combi steward en CU gezegd (en daar is ook uitgebreid over gesproken binnen de gemeenschap) omdat de onderzoeker (CU) meer belangen dient dan die van onze wiki. Artikel 4.2. had misschien netter en duidelijker geformuleerd kunnen worden, maar dat artikel tracht vast te leggen dat het onderzoeksdeel bij de CU ligt en het sanctioneren bij een moderator. De persoon die onderzoekt en de persoon die sanctioneert zijn niet dezelfde persoon. Dat is eigenlijk niks anders dan hoe het eigenlijk sinds jaar en dag gaat. Het meeblokkeren van een IP is dan niks minder dan een technische handeling. De interpretative die de OC geeft aan artikel 4.2. staat vrij ver af van wat er oorspronkelijk bedoeld is met dat artikel. Mogelijk dat er de nodige nuances verloren zijn gegaan in de vertaling, of dat het document van de AC niet in de juiste context is geplaatst, misschien dat de OC over de samenhang tussen artikel 4.1 en 4.2. heen gelezen heeft, ik weet het niet. Maar ik vrees dat de OC een daadwerkelijk probleem constateert maar de context waarbinnen het door hun geconstateerde probleem speelt niet voldoende hebben begrepen. Natuur12 (overleg) 29 mei 2022 15:57 (CEST)

Dat laatste is exact wat ik ook denk, en daarom vind ik dat de OC om een nadere uitleg gevraagd zou moeten worden. Mogelijk zit het probleem hem namelijk alleen maar in onze formulering of hun interpretatie van regel 4.2, en is er met de staande praktijk niets mis. WIKIKLAAS overleg 29 mei 2022 16:03 (CEST)

(Apologies for posting in English. Please translate if that would help the discussion.) I understand that 4.2 is about separation of the investigation (by a CU) and determining sanctions (by another admin). I interpreted the consequence of this to be that if a CU investigation determined that an IP needed to be blocked, the CU would need to provide the IP to an admin to block. Regardless of the intention of 4.2, the important part of the OC post is that CUs may not share private information from the CheckUser results (e.g., IP addresses) with those that do not have access to CheckUser, including administrators. On the point of "when it is a necessary and incidental consequence of blocking a sockpuppet or other abusive account", an example of when this would be true is if a CU blocked some accounts and IP addresses at around the same time, a non-CU may be able to draw a connection between the accounts and the IP addresses based on the timing of the blocks in the CU's block log. A non-CU being provided the IPs to block does not meet this requirement since a CU could make the block instead. JJMC89 (overleg) 29 mei 2022 19:19 (CEST)

@JJMC89: thank you for your reply. In this case, Arbcom seems to be the wrong venue for correcting the non-compliance. Article 1.5. of the Arbcomregulation forbids Arbcom from creating new policies and guidelines. An exception would be a regulation regarding appointing and firing CU's, but if I understand correctly, fixing the non-compliance asks far larger changes regarding our regulations and practices than Arbcom is allowed to make. As such odd are that the community is the proper venue for creating the proper regulations; within limits of the global frameworks and policies of course. Needless to say, I do hope the WMF provides Arbcom with all relevant information on the shortest possible notice because only than we can say for sure who would be responsible for fixing the non-compliance. Natuur12 (overleg) 29 mei 2022 20:43 (CEST)

@JJMC89: our CU's are not admins. And the explanation of section b(v) you give is a very particular one, and not equal to the wording of that section. Under the litteral wording of that section, our CU's are allowed to disclose an IP to an admin. In order to be able to block an IP, the IP must be passed on to someone who effectuates the block, otherwise blocking the IP is impossible. Can you provide any case where section b(v) was indeed explained in the way you do? WIKIKLAAS overleg 29 mei 2022 21:14 (CEST)

Back in 2019 the OC's reading of the acces to non public information policy seems to be less strict? See Ombudsman commission/2019/CU Global Procedure on information disclosure. I quote: "Where a disclosure is required to protect a project (like blocks, page protections, suppressions), there must be no one else who has access to the same or same type of information you do that you can disclose the information to in a timely manner (Example: ptwiki checkuser wishes to disclose an IP the arwiki should block to an arwiki sysop. If arwiki had checkusers, or stewards were around that can action on it, then you would have to inform them instead)" I'm getting confused again. Natuur12 (overleg) 29 mei 2022 21:22 (CEST)

Mogelijke oplossingen liggen op drie vlakken:

• CU en moderator gescheiden houden
  • CU benaderen moderatoren die het juiste niveau van vertrouwen hebben
  • CU benaderen stewards
• CU en moderator deels combineren
  • CU kandideren zich voor het moderatorschap
  • AC benoemt moderatoren tot CU
    • per geval moderatoren benoemen
    • een quotum aan moderatoren
    • arbcomleden die moderator zijn benoemen
    • bureaucraten benoemen
• CU en moderator combineren
  • CU kandideren zich voor het moderatorschap en wie niet gekozen wordt verliest CU
  • Enkel moderatoren kunnen nog CU worden
  • (of de middelvinger oplossing:) AC benoemt alle moderatoren tot CU

Dit zijn enkele theoretische paden die we kunnen volgen. Mvg, Taketa (overleg) 29 mei 2022 13:41 (CEST)

Dank voor deze inventarisatie. Een moderator kan niet zomaar tot checkuser benoemd worden. Conform de Checkuser policy moeten de checusers de vertrouwelijkheidsovereenkomst tekenen, waarbij je een emailadres moet opgeven. In eerdere versies moest je je meen ik je werkelijke identiteit en leeftijd openbaren. Ik denk een mogelijke oplossing ook is enkele moderatoren te vragen die overeenkomst te tekenen. Zij kunnen dan de IP gegevens ontvangen en vervolgens handelen. Overigens is het momenteel zo dat de CU's niet besluiten over blokkades. Dat doet een mod. De CU functie op NL Wikipedia is dan ook zuiver technisch (hoewel vertrouwelijk). Dit is een uitdrukkelijke wens van de Arbcom. Elly (overleg) 29 mei 2022 14:16 (CEST)

Ter info, we hebben al een aantal mods die deze NDA in het verleden al eens getekend hebben (volledige lijst). Feit blijft wel dat deze mods niet officieel het vertrouwen van een CU genieten. Iedereen kan die NDA immers ondertekenen, en dit kan in tegenstelling tot het CU-bitje niet heel eenvoudig worden afgenomen als de gemeenschap het vertrouwen in de betreffende gebruiker verliest. Bas dehaan (overleg) 29 mei 2022 14:39 (CEST)

Zou het niet een oplossing zijn om de CU’s te voorzien van het block gebruikersrecht? Dan kunnen ze zelf de IP-adressen blokkeren. En dan maken we daarbij evt. de afspraak dat het blokkeren van de gebruikers voorbehouden voor moderatoren. Bas dehaan (overleg) 29 mei 2022 21:09 (CEST)

Lijkt mij een prima oplossing! Natuur12 (overleg) 29 mei 2022 21:23 (CEST)

Mijn indruk is dat het hier hooguit gaat om een aanpassing van de formulering van de "Regeling checkusers". Maar de uitspraak is heel vaag in wat er precies overtreden zou zijn; dat maakt het lastiger om te begrijpen wat exact het probleem is. - Brya (overleg) 29 mei 2022 17:15 (CEST)

Ik ben zo vrij geweest om de vraag dan ook maar direct aan de afzender te stellen. WIKIKLAAS overleg 29 mei 2022 18:21 (CEST)

Misschien is dat niet nodig. Als de OC tegen de ArbCom vertelt wat er precies nodig is / zou zijn, kan die de "Regeling checkusers" aanpassen. - Brya (overleg) 29 mei 2022 18:31 (CEST)

Als ik de reactie van JJMC89 hierboven zo lees gaat het niet om een simpele aanpassing van een formulering. Dit is allemaal best op te lossen, maar ik betwijfel of het oplossen binnen het mandaat van de AC valt. Tenzij ze CU's ontslaan en mods als CU aannemen. Maar wie weet waar de WMF mee gaat komen. Natuur12 (overleg) 29 mei 2022 20:46 (CEST)

Ja, er is meer nodig. Zo op het eerste gezicht zouden we met de oplossing van Bas dehaan al een heel eind komen. - Brya (overleg) 30 mei 2022 07:15 (CEST)

Behalve dat dat wellicht een grotere privacyschending op zou leveren. Het is makkelijker de gegevens te zien in het bloklog van checkusers die slechts ip-sokpoppen blokkeren dan tussen de andere ip-blokkades die een moderator regulier uitvoert. — Zanaq (?) 30 mei 2022 09:39 (CEST)

Voorlopig hoeft er volgens mij helemaal niets te gebeuren. Onze praktijk waarbij CU's een IP achter de schermen doorgeven aan één moderator is volledig in overeenstemming met de letterlijke tekst van de hierboven al geciteerde sectie b(v) van het document Access to nonpublic personal data policy. Er is een beleid met betrekking tot het beschermen van persoonlijke gegevens, waaronder IP's, en dat beleid is uitgewerkt in een document met regels. De bescherming is niet absoluut; er worden uiteraard enkele uitzonderingen gemaakt. Een van die uitzonderingen is letterlijk en helder in het document verwoord: in het geval van een sokpop of een vandalistisch account, mag een IP worden geopenbaard aan het publiek (bij ons: één moderator). Als dat niet de bedoeling was van die regel, dan had die regel anders verwoord moeten worden. De OC kan niet zomaar hier komen en ons op de vingers tikken omdat ze van mening is dat een regel anders gelezen moet worden dan letterlijk. Als dat een probleem oplevert, dan is de juiste gang van zaken om te zorgen dat die regel verandert. Tot die tijd is het uiterst onbeleefd om op basis van het bestaande document gedrag af te dwingen dat niet uit de regels in het document zelf volgt. Ik denk dat er huiswerk te doen is voor de OC. WIKIKLAAS overleg 30 mei 2022 11:46 (CEST)

@Wikiklaas: De OC is het hoogste orgaan op het gebied van o.a. CU-aangelegen en gaat hierover. Werken met instituten van de Amerikanen gaat iets anders in zijn werk dan we gewend zijn op onze polderwiki. Of we zorgen dat hun uitspraak opgevolgd wordt, of we lopen het zeer grote risico dat de WMF enkele of alle CU's zonder pardoes afzet. Waar bij onze Arbcom van tijd tot tijd nog ruimte is voor enige discussie is het bij een instituut als de OC heel simpel: dit is hun uitspraak, jullie zullen het er mee moeten doen. Het doet er dan weinig meer toe hoe goed of slecht argumenten die achteraf ingebracht zijn, het gaat niks meer uitmaken. Doorgaan op de huidige voet is de snelste weg naar 0 CU's. Natuur12 (overleg) 30 mei 2022 20:04 (CEST)

Het betreffende document Access to nonpublic personal data policy maakt een zwart-wit onderscheid tussen enerzijds informatiedoorgifte aan personen die daar expliciet toe gerechtigd zijn ( i ) en anderzijds het publiek maken (aan iedereen) wanneer dat een onvermijdelijk gevolg is van het ondernemen van actie ( v ). Doorgeven aan één moderator ligt daar tussenin: er is niet in voorzien. Doorgeven aan één moderator is bijvoorbeeld niet strikt onvermijdelijk; de regeling had ook anders geformuleerd kunnen worden. - Brya (overleg) 30 mei 2022 13:08 (CEST)

Onze praktijk (doorgeven aan één moderator) is strikter dan het document toestaat, en dan is het in overeenstemming met het beleid. Het verwijt dat ons gemaakt wordt is dat we een beleid hebben dat minder strikt is dan voorgeschreven. En dat is op basis van de uitgewerkte regels niet hard te maken. Ik denk bovendien dat we in de geest van het beleid werken, en dat ons dus ook op dat punt niets valt te verwijten. WIKIKLAAS overleg 30 mei 2022 13:51 (CEST)

Nou ja, de eis onder  v  is "when it is a necessary and incidental consequence of blocking a sockpuppet or other abusive account." Dat zou alleen gelden als Zanaq gelijk heeft en het onmogelijk is een IP-adres te blokkeren zonder dat het publiekelijk zichtbaar is (ik heb geen idee of dat zo is). Als dat niet zo (het blokkeren kan wel onzichtbaar blijven), dan is ook die ene mod er teveel aan. Dat de kans dat dit in de praktijk tot problemen zal leiden heel klein zal best zo zijn, en dus voldoet de regeling wel aan de geest van de policy, maar niet aan de letter. - Brya (overleg) 30 mei 2022 18:30 (CEST)

Als de CU tevens moderator is, dan is er geen vrijgeven van prive informatie nodig. Ook niet aan 1 moderator. Het is inderdaad makkelijk een blok log van een CU na te kijken. Dat zou een probleem zijn als je de CU block rechten geeft. Op andere wikis is dat geen probleem omdat er meerdere CU zijn en allemaal actieve moderatoren die ook standaard ips blokkeren en meerdere sokpop onderzoeken tegelijk doen. Mvg, Taketa (overleg) 30 mei 2022 21:18 (CEST)

Net als natuur12 zat ik destijds in de arbcom. Die arbcom had van de Nederlandse gemeenschap mandaat gekregen om CU's aan te stellen. Waar bemoeit JJMC89 zich mee? Hij heeft hier geen mandaat, 0 inhoudelijke bijdragen, en beheerst het Nederlands niet. Het volstaat uit te leggen dat dit is hoe we het hier hebben opgelost. Als hij wil dat al onze CU's mods worden, laat hem artikelen schrijven, en na dat een tijdje te hebben gedaan kan hij een voorstel doen.

Dat gezegd, lijkt me dat JJMC89's interpretatie van de privacywet ook veel strikter dan noodzakelijk is. Daar ligt het probleem: bij JJMC89, niet bij onze wiki of arbcom. Woudloper _overleg 31 mei 2022 02:39 (CEST)

@Woudloper:, ook ligt het probleem bij JJMC89, als lid van de OC heeft hij wel degelijk invloed op deze wiki. De OC heeft in de vorige maand op twee wiki's de rechten van een Checkuser ingetrokken, zonder overleg vooraf, maar ook met minieme uitleg na afloop. Het intrekken heeft zeer waarschijnlijk te maken met een ingediende klacht over het bekendmaken van een IP-adres naar aanleiding van een CU-verzoek. Dat een dergelijk intrekken van rechten zonder overleg vooraf ook bij één van onze CU's zou kunnen gebeuren hangt nu dus eigenlijk als een zwaard van Damocles boven onze Wiki. In dat licht bezien is het al heel wat dat we nu een waarschuwing vooraf krijgen. En hoewel onze interpretatie van de Policy nogal wat nuances bevat, interpreteert de WMF die kennelijk anders. En beroep is niet mogelijk. Wat kunnen we anders doen dan nu vooral de dialoog aangaan met de OC en WMF? Beschouw de discussiebereidheid vooraf van JJMC89 voorlopig maar als uniek, want ik heb die nog niet eerder zo meegemaakt. Hem wegzetten als probleem die hier eerst maar eens wat artikelen moet gaan schrijven is denk ik niet de oplossing. Tenzij we accepteren dat we zo nu en dan een vrijwilliger kwijtraken wegens een door de WMF opgelegde blokkade. Groet, Brimz (overleg) 31 mei 2022 12:04 (CEST)

Oh, als het blokkeren van een IP altijd publiekelijk zichtbaar is, dan ligt de zaak anders. Het beste wat dan haalbaar is, zal dan zijn dat het blokkeren van dit bewuste IP zo goed mogelijk wordt verstopt, tussen andere blokkades van IP's. - Brya (overleg) 31 mei 2022 06:39 (CEST)

Het misverstand lijkt te zitten in het woordje "incidental" van die regeling (v). Bij het opstellen van onze richtlijnen lijken we dat als "incidenteel" geinterpreteerd te hebben (af en toe), maar dat is een valse vriend. "Incidental" betekent "bijkomstig". Het is alleen toegestaan IPs vrij te geven als bijkomstigheid: iedereen die toegang heeft tot de logs kan zien dat een account en een IP-adres op hetzelfde moment geblokkeerd worden, waardoor het IP-adres van de gebruiker "incidentally" bekend gemaakt wordt. Onze CUs sturen het IP-adres echter doelgericht aan iemand anders. Dat is niet "incidental", ook niet als het incidenteel gebeurt. Hoopje (overleg) 31 mei 2022 07:44 (CEST)

Even een snelle reactie aan @Woudloper, @JJMC89 is lid van de ombudsman-commisie die beoordeelt of het privacy-regelement van de foundation goed word uitgevoerd. Vanuit die functie heeft hij wel degelijk recht van spreken en is het ook bindend. Totdat er meer duidelijkheid is zal ik een IP niet meer verstrekken aan een moderator.

Aan privacy word de laatste tijd meer waarde gehecht. De regels zijn aangescherpt, maar de interpretatie van de OC verbaast mij ook. Het maakt ons systeem van CU's die geen mod zijn niet meer houdbaar, en heeft wel aandacht nodig. Akoopal _overleg. 31 mei 2022 10:39 (CEST)

We gaan toch niet meer privacyschending plegen alleen omdat een Amerikaan onze werkwijze niet begrijpt? Het standpunt van Akoopal is mi te begrijpen, maar als alle Checkusers dat voorbeeld volgen dan zullen onderliggende ip-adressen gewoon niet meer geblokkeerd worden. Dat is een te verdedigen keuze. Checkusers dan maar mod maken (of blokkeerrechten geven) is mi een niet te verdedigen keuze. Mi kunnen we de ondoordachte opmerkingen van de OC gewoon negeren. Dan trekt de Foundation onze checkuser-rechten maar in. Dan kunnen ze mi zelf de daaruit voortvloeiende problemen oplossen. Dan zien we ook meteen hoe betrokken bij de gemeenschap ze zijn. De beste keuze is overleggen over de (interpretatie van de) richtlijn met de OC/WMF. — Zanaq (?) 31 mei 2022 10:45 (CEST)

Ik ben niet echt thuis in deze materie, maar zou het een oplossing zijn om onze huidige checkusers niet alleen de reeds door Bas dehaan voorgestelde blokkeerrechten te geven, maar ook het recht om de door hen geblokkeerde IP-adressen in de betreffende logboeken te verbergen? Bij mijn weten kan een account als IsabelleBoslaan6SchubbekutteveenIsEenHoer niet alleen geblokkeerd worden, maar kan zo'n privacyschendende naam ook verborgen worden, dus dan kan dat neem ik aan ook met IP-adressen? Op die manier kunnen de checkusers alles zelf afhandelen en zijn die adressen niet meer zichtbaar voor buitenstaanders. — Matroos Vos (overleg) 31 mei 2022 11:28 (CEST)

Ja dat is mogelijk. Twee dingen. Momenteel kijken CU of het mogelijk dezelfde persoon is, en beoordelen de moderatoren of er vervolgens een blokkade nodig is. De CU zouden dus moeten gaan beoordelen of een blokkade nodig is. Het is aan de CU of zij dit willen. Als tweede is het een extra handeling en verberging, en daarvoor is het de vraag in hoeverre men dit wil hebben. Mvg, Taketa (overleg) 31 mei 2022 11:46 (CEST)

De interpretatie van Hoopje is logisch. Maar toch, als een IP-adres toch publiek gemaakt wordt, is het heel verwrongen dat een moderator, die als lid van het publiek toegang heeft tot dat IP-adres, vijf minuten eerder niet op de hoogte gesteld mag worden van dat IP-adres. Het is dus ook mogelijk om andersom te argumenteren: in de geest van de policy hoort het IP-adres zoveel mogelijk verborgen te worden, dus dan is het wenselijk het bekendmaken van het IP-adres toe te vertrouwen aan een moderator die deze geheimhouding zoveel mogelijk kan bewerkstelligen. Dat kan dan wel degelijk een necessary and incidental consequence van de winst in geheimhouding opgevat worden.

        Maar als het mogelijk is om een IP-adres te blokkeren zonder dit publiek te maken, dan ligt de zaak weer heel anders. - Brya (overleg) 31 mei 2022 12:38 (CEST)

We hebben het hier over de Amerikanen, die geven niet om best practices of enige logica achter procedures maar vooral om compliance. Daar krijg je gekke situaties van, maar daar zullen we het mee moeten doen. Of we het nu leuk vinden of niet. Risico van de uiteindelijke controle in de VS leggen en niet in Europa. Natuur12 (overleg) 31 mei 2022 12:57 (CEST)

Wij geven daarentegen niet om compliance. Aangeven waarom we het er niet mee eens zijn en verder gewoon geen gehoor aan geven, dan zien we wel waar ze mee komen. — Zanaq (?) 31 mei 2022 14:13 (CEST)

Dat kan je vanaf de bijrijdersstoel ook roepen tegen de chauffeur, terwijl je die net hebt gevraagd om met 100 kilometer per uur door de bebouwde kom te rijden: ik geef niet om de wet, dus we zien wel waar ze mee komen. Brimz (overleg) 31 mei 2022 14:26 (CEST)

Behalve dat we juist onder de maximumsnelheid zitten en de chauffeur desondanks waarschuwt dat we te snel gaan?

Dit is geen nieuwe discussie. Binnen de arbcom was het een terugkomende verdienste van Natuur12 op het risico van ingrijpen van de WMF te wijzen. De zorgen berusten op het idee dat niet de gemeenschap maar de WMF hier de macht zou hebben, omdat ze de stekker uit de servers kunnen trekken, of in dit geval CU's uit hun functies zetten. Maar dat is niet hoe de WMF ons Wikipedia verkoopt: ze bewijzen op zijn minst lippendienst aan respect voor lokale gemeenschappen.

Wie zegt dat het geen bluf is, mogelijk van een enkele dwingeland. Er lopen zoveel petjesverzamelaars rond die niet met het hoofdproces bezig zijn maar met "bestuur", wat erop neerkomt dat ze anderen graag de les lezen en het leven zuur maken.

Ik wil wel eens zien waar de WMF werkelijk voor staat. Als ze inderdaad zo weinig respect hebben voor een lokale gemeenschap en arbcom is het ook wel waard dat te weten. Het zou in ieder geval een hoop over de WMF zeggen. Woudloper _overleg 31 mei 2022 17:56 (CEST)

De nuance is dat wij denken dat we niet te hard rijden, omdat onze snelheidsmeter keurig 50 aangeeft. Maar 50 is voor de Amerikanen binnen de bebouwede kom wel 25 mph te snel.

Dat het de WMF ernst is blijkt uit het feit dat onlangs op een grote wiki een CU voor een jaar uit functie is gezet en op een middelgrote wiki een CU OT uit functie is gezet. Een CU uit functie zetten door de WMF was tot vorige maand in al die 18 jaar nog niet gebeurd. We kunnen dat negeren, omdat we het stom vinden en het niet past bij onze Europese kijk op de zaken. Maar ik denk dat dat best een risico is. Brimz (overleg) 31 mei 2022 19:47 (CEST)

Kun je misschien een link geven naar wat er precies gebeurd is op die middelgrote wiki?

Eén CU uit functie zetten is bovendien nog wel iets anders dan alle CU's op een project uit functie zetten. Dat maakt het project in de praktijk vleugellam om allerlei wangedrag te bestrijden. Dan zouden de stewards die taak tijdelijk over moeten nemen, wat betekent dat WMF de macht naar zich toe trekt. Ik geloof niet dat ze dat zomaar zouden doen zonder eerst normaal overleg te zoeken (i.t.t. wereldvreemde berichten en niet nader gespecificeerde dreigementen). Mochten ze het toch doen, dan zegt dat veel over het niveau waarnaar de WMF is afgezakt: pesterijen en machtspelletjes. Woudloper _overleg 1 jun 2022 01:57 (CEST)

Ik ben er groot voorstander van om de rollen in beginsel gescheiden te houden. Degene die het CU onderzoek doet, zou niet degene moeten zijn die besluit tot een blokkade. Ik ben zelf altijd heel terughoudend geweest in het verstrekken van IP-adressen aan een moderator, soms tot frustratie van moderators. Bovendien, als we al IPs verstrekken, dan is dat altijd achter de schermen en zonder onnodige informatie. Ik denk dat de staande praktijk prima is en dat we het probleem op kunnen lossen door de formulering aan te passen. Een waarborg die we eventueel in zouden kunnen bouwen, is dat de AC een aantal (van de huidige) mods aanwijst die vertrouwd zijn en aan wie een CU een IP-adres kan geven als dat echt nodig is. Jcb - Amar es servir 31 mei 2022 19:26 (CEST)

Deliberately in English again, I would like to ask @JJMC89 explicitly if he would see a workable model where the CU's don't have to be moderator, but it will be possible to block IP's if needed by a moderator. A trusted group of moderators might be an option, but I prefer a more general solution. I do think, which I have always done before, we should be careful with giving the IP and consider as CU if it is needed to block an IP directly instead of indirectly via the autoblock feature. Akoopal _overleg. 31 mei 2022 20:14 (CEST)

Well, so far there seem to be two viable options which would overcome the stated objections. Both assume that it is technically possible to hide logs of blocking actions of IP-addresses.

1. Create an extra group of "trusted admins" who "are permitted to access the same Nonpublic Personal Data". They can handle the blocks of IP-addresses.
2. Give the current CUs the additional rights necessary to block IP-addresses (and hide these actions). The power of decision (on what kind of action needs to be taken, if any) can remain with the admins. The CUs could just do their own bit, implementing the decision of the admin. In practice this would require an extra bit of coordination, but nothing unwieldy.

- Brya (overleg) 1 jun 2022 06:41 (CEST)

I think hiding of the logs is possible. I know that at least some logs of oversight actions are invisible. Both of your suggestions seem fine to me. The extra bit of coordination is no big deal. Jcb - Amar es servir 2 jun 2022 17:35 (CEST)

Net terug van vakantie vind in deze lap tekst en ben tevreden over de scheiding tussen moderators en chechusers. Checkusers zijn op de Nederlandtalige versie dienend en houden zich derhalve aan het verzoek op de sokpoppagina. Toevallig zat ik vorige maand in dubio bij het verzoek of Speelvogel een sokpop was van Wwikix. Ik heb naar eer en geweten gehandeld en gemeld dat er geen technisch bewijs is. Ik zag wel andere gebruikers op de adressen van Speelvogel, maar dat waren toen nog geen sokpoppen, dus kon op dat moment ook geen sprake zijn van misbruik en ik heb het dan ook niet gemeld. Volgens mij zou dat bewijs dan onder "vissen" verstaan kunnen worden. Terugkomend op het issue hier. Ik heb er geen bezwaar tegen om zelf de ip-adressen te blokkeren en niet meer te melden aan een vertrouwde moderator. Hoe het dan met het logboek moet, weet ik nog even niet. Japiot (overleg) 2 jun 2022 22:49 (CEST)

Hij/zij ?

Vrienden, ik heb onlangs een lemma geschreven over de Frans-Amerikaanse econoom/econome Julie Battilana. En daarmee raak ik meteen aan het probleem. Zoals jullie aan de naam kunnen zien is het een vrouw, maar maakt dit haar tot een econome? Ik vind het lelijk Nederlands. Moet ik dan het (ook bij Categorieën) houden bij het neutrale econoom ? Genderneutraal is zo modieus en verwarrend. Moet ik Annie M.G. Schmidt een Nederlandse schrijver noemen? Ik gruw ervan. Waarom maakt het bijvoorbeeld niet uit of een longarts een man of een vrouw is ( in de betiteling)? Je ziet het vanzelf, wanneer je langdurig hoest. Kortom, vragen, die zoeken naar een antwoord. Hebben wij een soort van stijlhandboek, waarin wordt beschreven, hoe wij dat doen op Wikipedia ? Hamnico (overleg) 30 mei 2022 11:06 (CEST)

Voor zover ik weet hebben we geen interne richtlijn hierover. Over het algemeen sluiten wij ons aan bij wat gebruikelijk is in het Nederlands. Wel hebben we een artikel Genderneutraal taalgebruik. Zie het kopje "beroepsnamen". Daar staat dat de meningen verschillen. Zelf ben ik fysicus en ik gruw van de aanduiding "fysica," maar er zijn mensen die dat graag zo doen. Kortom, smaken verschillen. Helpt je dus niet concreet, maar alles is goed dunkt mij. Groet van je wikivriend(in), Elly (overleg) 30 mei 2022 12:24 (CEST)

Wellicht interessant om te weten dat de Dikke Van Dale sinds een maand of twee "genderinclusief" is. Bij een woord als minister staat nu dus de aanduiding m/v/x, om aan te geven dat dat woord niet meer per se verwijst naar een biologisch geslacht. Ik heb net even gekeken naar econoom, en ook dat woord is inmiddels voorzien van die genderneutrale aanduiding, met de toevoeging dat vrouwen ook wel econome worden genoemd. — Matroos Vos (overleg) 30 mei 2022 17:32 (CEST)

En 'matroos'? Thieu1972 (overleg) 30 mei 2022 20:50 (CEST)

Dat beroep is uiteraard slechts voorbehouden aan echte mannen. — Matroos Vos (overleg) 30 mei 2022 21:07 (CEST)

Er was toch ooit een meisje loos? Hans Erren (overleg) 30 mei 2022 21:40 (CEST)

Jazeker, maar na haar schandelijk bedrog werd ze gelukkig gewoon weer het vrouwtje van de kapitein, zoals het heurt. Eind goed, al goed. — Matroos Vos (overleg) 30 mei 2022 22:28 (CEST)

Maar hoe heurt het nu eigenlijk: Van Dale is van mening dat een matroos ook met m/v/x aangeduid kan worden. Je zal je moeten aanpassen Matroos aan de veranderde tijden ;) Gouwenaar (overleg) 30 mei 2022 22:47 (CEST)

Wis ende waerachtich niet. Die genderinclusieve definitie van matroos is ongetwijfeld een van de vele fouten in de nieuwe Dikke. — Matroos Vos (overleg) 30 mei 2022 23:06 (CEST)

Ach het eertijds oerconservatieve Ierland dendert je voorbij. Gouwenaar (overleg) 30 mei 2022 23:19 (CEST)

Opvallend genoeg is die foto dan weer wel INS Seamen getiteld. En dat-ie gebruikt wordt in een lemma met de enigszins dubbelzinnige titel 'Matrozenmuts', is haast te mooi om waar te zijn. Tweede van links is trouwens Boris Becker, die de laatste jaren weer gewoon moet werken voor zijn geld. Wel mazzel dan dat hij de komende tijd verzekerd is van gratis kost en inwoning. — Matroos Vos (overleg) 30 mei 2022 23:44 (CEST)

Ik heb geruime tijd in de financiële wereld vertoefd en zeer frequent opgetrokken met beoefenaren van en:The dismal science, maar ik heb de term "econome" nooit horen gebruiken. MartinD (overleg) 30 mei 2022 21:52 (CEST)

Toch heeft het ANW een eigen lemma voor econome, terwijl het lemma voor de econoom zelfs nog niet eens bestaat. En iemand als Barbara Baarsma wordt geregeld econome genoemd — Matroos Vos (overleg) 30 mei 2022 22:12 (CEST)

@Hamnico: De afspraak is als volgt. Degene die er als eerste bij is, bepaald. Dus als jij een lemma begint, dan mag je bij een vrouw zelf bepalen of je econoom of econome schrijft. Een ander mag dat dan niet meer aanpassen wegens WP:BTNI. Ingewikkelder wordt het als je schrijft: "X is een econoom en schrijfster". Hoewel hierover geen harde afspraken zijn gemaakt, zal iedereen beamen dat het logisch is om consequent te zijn. Iemand anders zou er dan "econoom en schrijver" of "econome en schrijfster" van mogen maken. Schrijf je: "X is een econoom, schrijfster en zeilster", dan lijkt het mij duidelijk om sowieso econoom in econome te veranderen. HT (overleg) 31 mei 2022 09:10 (CEST)

Dat consequent zijn lijkt me geen goed idee. Bij de ene beroepsnaam is het gebruikelijk om in het geval van een vrouw de mannelijke vorm te kiezen, terwijl bij de andere beroepsnaam nu juist de vrouwelijke vorm gebruikelijk is. Onze Taal geeft hier wat voorbeelden, waaruit blijkt dat een vrouw die zingt en dicht bij voorkeur een zangeres en dichter wordt genoemd. — Matroos Vos (overleg) 31 mei 2022 09:39 (CEST)

Het gaat weer druk worden bij de wiki-rechter zo meteen. En bepaald is met een t. – De voorgaande bijdrage werd geplaatst door 2001:1c02:1e03:9b00:a110:e9db:cde9:bf29 (overleg · bijdragen) PS: Wil je voortaan alsjeblieft op overlegpagina's ondertekenen met vier tildes (~~~~)? Er wordt dan automatisch een link naar je gebruikerspagina geplaatst.

Tech News: 2022-22

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

• In the AbuseFilter extension, an ip_in_ranges() function has been introduced to check if an IP is in any of the ranges. Wikis are advised to combine multiple ip_in_range() expressions joined by | into a single expression for better performance. You can use the search function on Special:AbuseFilter to locate its usage. [3]
• The IP Info feature which helps abuse fighters access information about IPs, has been deployed to all wikis as a beta feature. This comes after weeks of beta testing on test.wikipedia.org.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 May. It will be on non-Wikipedia wikis and some Wikipedias from 1 June. It will be on all wikis from 2 June (calendar).
• Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 31 May at 07:00 UTC (targeted wikis).
• The New Topic Tool will be deployed for all editors at most wikis soon. You will be able to opt out from within the tool and in Preferences. [4][5]
• The list=usercontribs API will support fetching contributions from an IP range soon. API users can set the uciprange parameter to get contributions from any IP range within the limit. [6]
• A new parser function will be introduced: {{=}}. It will replace existing templates named "=". It will insert an equal sign. This can be used to escape the equal sign in the parameter values of templates. [7]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

30 mei 2022 22:28 (CEST)

Nieuwsbrief 112 Wikimedia Nederland

Nieuwsbrief van mei 2022 Samenwerken | Nieuwe projectleider | Flora i Founa a Wikidata... Samenwerken Grote Wikipedia Enquête Nieuwe projectleider Wikimedia Nederland Flora i Founa a Wikidata Jaarverslag en jaarrekening 2021 Terugblik workshop Wikipedia/Wikidata Steun Wikimedia Nederland AVA_Net Symposium Zien we jou binnenkort? Oude versies vindt u hier

Info over nieuwsbrief · Inschrijven/Uitschrijven · Global message delivery · Germien Cox (WMNL) (overleg) 31 mei 2022 12:59 (CEST)

Next steps on the Universal Code of Conduct (UCoC) Enforcement Guidelines

Meer talen • Help met het vertalen in uw taal

Hello all,

I’d like to share an update on the work on the Enforcement Guidelines for the Universal Code of Conduct.

In 2022 May, the Universal Code of Conduct (UCoC) project team completed a report on the 2022 March ratification vote about the guidelines. Voters cast votes from at least 137 communities. At least 650 participants added comments with their vote. A report is available on Meta-Wiki. (See full announcement)

Following the vote, the Community Affairs committee (CAC) of the Wikimedia Foundation Board of Trustees asked that several areas be reviewed for improvements. A Revision Drafting Committee will refine the enforcement guidelines based on community feedback.

To help the Revisions committee, input from the community is requested. Visit the Meta-wiki pages (Enforcement Guidelines revision discussions, Policy text revision discussions) to provide thoughts for the new drafting committee. (See full announcement)

Let me know if you have any questions about these next steps. DBarthel (WMF) (overleg) 31 mei 2022 15:23 (CEST)

Invitation to participate in the #WPWPCampaign 2022

Dear Wikimedians,

We are glad to inform you that the 2022 edition of Wikipedia Pages Wanting Photos campaign is coming up in July.

This is a formal invitation to invite individuals and communities to join the campaign to help improve Wikipedia articles with photos and contextual images.

The campaign will run from July 1 to August 31, 2022 and several communities and Wikimedia Affiliates have already indicated interest to organize the campaign in their localities. Please find your community or community closer to you to participate: WPWP2022 Campaign: Participating Communities.

The campaign primarily aims to promote using images from Wikimedia Commons to enrich Wikipedia articles that are lacking them. Participants will choose among Wikipedia pages without photos, then add a suitable file from among the many thousands of photos in the Wikimedia Commons, especially those uploaded from thematic contests (Wiki Loves Africa, Wiki Loves Earth, Wiki Loves Folklore, etc.) over the years. In this third edition of the campaign, eligibility criteria have been revised based on feedback and campaign Evaluation Reports of the previous editions. Please find more details about these changes and our FAQ here on Meta-Wiki

For more information, please visit the campaign page on Meta-Wiki.

Best,
Ammar A.
Global Coordinator
Wikipedia Pages Wanting Photos Campaign 2022.
31 mei 2022 19:38 (CEST)

Volgens WD4WP zijn er 71593 lemma's met een afbeelding op Wikidata, maar zonder afbeelding op de NL Wikipedia. Er zijn dus mogelijkheden, maar niet alle suggesties zijn bruikbaar. Hobbema (overleg) 31 mei 2022 23:15 (CEST)

• Is het een idee om deze WD4WP op te nemen in een beheerscategorie. Er staan mis matches in, maar over het algemeen is het een werkbare lijst. Ldhank (overleg) 1 jun 2022 11:32 (CEST)

• Bij nader inzien, laat maar. Ondanks de layout en de mogelijkheid tot filters is mijn bevinding, dat deze query een momentopname (2021?) is geweest, die daarna niet meer is geupdated.Ldhank (overleg) 2 jun 2022 07:28 (CEST)

  Dat is niet correct. Het wordt alle paar dagen ververst. Het aantal is nu 71606. Nieuwe suggesties worden toegevoegd aan het eind van iedere categorie. Hobbema (overleg) 2 jun 2022 08:15 (CEST)

• Dat kan allemaal wel waar zijn, maar hierbij een bevinding uit de categorie 'Human' die ik tegenkwam. Achaemenes, Amenemnesoe, Abd al-Moettalib, Andreas Werckmeister. De getoonde afbeeldingen in wikidata zijn in maart 2021 verwijderd. Ldhank (overleg) 2 jun 2022 11:17 (CEST)

Zoiets had ik ook gezien. Ik heb het hier gevraagd, maar niemand reageerde, ook niet op het Forum daar. Hobbema (overleg) 2 jun 2022 11:44 (CEST)

• We hebben al Categorie:Wikipedia:Geen afbeelding lokaal en wel op Wikidata, maar dit telt slechts zo'n 20.000 pagina's omdat die alleen via infoboxen werkt. –bdijkstra (overleg) 1 jun 2022 11:45 (CEST)

Zelf voeg ik vaak afbeeldingen toe bij Wikidata die dan in veel gevallen in de infoboxen van Wikipedia's komen (niet bij DE-, EN, NL en enkele andere wikipedia's). Die bijdragen tellen niet mee bij de campagne. Wouter (overleg) 1 jun 2022 17:30 (CEST)

Bij NL gebeurt het alleen(?) bij infobox voetballer. Hobbema (overleg) 1 jun 2022 18:23 (CEST)

Nee, kennelijk ook bij de infobox bestuurder. Bij Frederik Nicolaas Nieuwenhuijzen, van wie we zelf geen afbeelding hebben, waren de beide illustraties in het artikel om onnaspeurlijke redenen ook op Wikidata terechtgekomen. Het gevolg was dat de bovenste illustratie in de infobox van het artikel belandde en dus twee keer in het artikel stond. (Even terzijde: volgens Wikidata was de goede man een Belgisch politicus. Hoe iemand dat uit het artikel kan halen is mij een compleet raadsel.) Sijtze Reurich (overleg) 1 jun 2022 20:10 (CEST)

Dat was gebeurd dmv een wikidata-game in 2020. Dat game kijkt blijkbaar naar afbeeldingen op een willekeurige plek in een lemma en stelt voor die in Wikidata te zetten en sommigen doen dat dan ook zonder erbij na te denken. Hobbema (overleg) 1 jun 2022 20:23 (CEST)

We hebben zelfs tientallen infobox-sjablonen die een afbeelding van Wikidata halen (P18). Het gaat om een flink deel van deze sjablonen. Die lijst is niet compleet want er zijn ook infoboxen die wel data van Wikidata halen, waaronder P18, maar waar in de sjabloondocumentatie geen Sjabloon:Gebruikt Wikidata is gebruikt. Ook hebben we heel wat infobox-sjablonen die een logo (P154) van Wikidata halen, bijvoorbeeld een bedrijfslogo. hiro the club is open‍ 2 jun 2022 14:25 (CEST)

• De query wd4wp doet een poging inzichtelijk te maken bij welke lemma's een afbeelding ontbreekt in de infobox of er geen hebben als eerste regel in nl.wp, waar deze wel een afbeelding hebben in wikidata. De grootste categorie is Franse gemeentes (12692). Deze infobox haalt inderdaad ook gegevens op uit wikidata, maar er is geen plaats gemaakt om een afbeelding te tonen. Er zijn overigens ook veel ontbrekende afbeeldingen bij geografische categorien, wellicht om dezelfde reden, dat een afbeelding niet in de betreffende infobox gedefinieerd is. Dat die mogelijkheid niet gegeven is in de infobox, is een keuze. Overigen omvat de query alle lemma's, en kijkt niet alleen naar lemma's met een infobox.Ldhank (overleg) 3 jun 2022 09:20 (CEST)

  De parameter image werkt in die geografische infoboxen. Als ik een tegen kom via willekeurig artikel gebruik ik die altijd. Hobbema (overleg) Hobbema (overleg) 3 jun 2022 11:02 (CEST)