Help:Helpdesk

Zie H:H
Zie H:HD

Helpdesk

Overzicht hulppagina's
Wikipedia Hulppagina's

Zie ook Regels en richtlijnen
Zie ook Artikelen bewerken

Welkom op de Wikipedia-helpdesk!
Help-browser.svg

Stel hier uw vragen aan hulpvaardige Wikipedia-gebruikers.

Voordat u uw vraag stelt ...
  • Net als andere pagina's op Wikipedia is deze helpdesk vrijwilligerswerk. Er wordt geen garantie geboden voor de juistheid en volledigheid van de gegeven informatie.
  • Gebruik van de informatie is geheel vrij, maar wel voor eigen risico. Als u advies zoekt op het gebied van recht of geneeskunde, stel dan uw vraag niet hier, maar bij een jurist of arts.
Wachten op antwoord...
  • Uw vraag wordt op deze pagina beantwoord, soms al binnen enkele minuten, doorgaans binnen enkele uren. Kijk dus regelmatig op deze pagina.
  • Vragen die beantwoord zijn worden na ongeveer een week in het archief geplaatst.

Hoe noem je een artikel over een spel dat je speelt met flippo's?Bewerken

Jij en je tegenspeler hebben elk een eigen kaartje, schijfje of stapeltje gevouwen papiertjes. Het kaartje, schijfje of stapeltje gevouwen papiertjes van je tegenstander ligt op de grond, en door je eigen kaartje, schijfje of stapeltje gevouwen papiertjes erop te gooien, probeer je dat van je tegenstander 180 graden om zijn x-as te laten draaien. Je kunt het spelen met flippo's, het was ooit een rage die vanuit Hawaii onder de naam pogs via de Verenigde Staten naar Europa is overgewaaid, oorspronkelijk komt het uit Japan onder de naam Menko, en momenteel schijnt het door de Squid Game-rage op schoolpleinen veel gespeeld te worden onder zijn Koreaanse naam Ddakji.

Wat zou een geschikte naam zijn voor een artikel dat het spelconcept beschrijft? Sietske | Reageren? 14 okt 2021 22:54 (CEST)[]

Zijn er al bronnen te vinden die het spel beschrijven, en welke naam wordt daar dan gebruikt. Pogs is de commerciële variant van het Melkdoppenspel (zie hier), dat trouwens een interwikilink heeft naar het al genoemde Flippo. Daar staat trouwens een hele grote aanname in. De Flippo kan natuurlijk gebruikt worden voor dit spel, maar of dat ook echt de bedoeling was is mij niet helemaal duidelijk. Nou ben ik nog redelijk jong (ahum) maar ik heb nog nooit gehoord van een spel dat met (melk)doppen op deze manier gespeeld wordt. Maar misschien is dat er wel, een korte google-zoektocht leverde mij nog niets op. Ik geef dus eigenlijk totaal geen antwoord op je vraag, maar misschien kom je met die melkdoppen wat verder. Nietanoniem (overleg) 15 okt 2021 10:44 (CEST)[]
Dan wordt het Ddakji. Want melkdoppenspel is een anglicisme en wordt als naamgeving in onze contreien niet gebruikt. Minder dan Ddakji iig. Sietske | Reageren? 15 okt 2021 11:32 (CEST)[]
Is dit een conclusie op grond van een antwoordt dat het bovenstaande ("dus eigenlijk totaal geen antwoord op je vraag") geeft? Hoezo anglicisme. Welke contreien zijn de "onze"? Trouwens, melkdoppen waren er in verschillende soorten: die van aluminium (voor flessen met wijde hals waar een flessenlikker gebruikt kan worden) met vaak een kleurtje (yoghurt, melk, karnemelk, karnemelkse pap etc.); en de kroonkurk-doppen (voor melkflessen met smalle hals) (geschiedenisles van een boomer ;-) Melkdoppenspel lijkt me ook niet zo'n geschikte naam, dus verzin (?) maar wat anders. PAvdK (overleg) 15 okt 2021 12:04 (CEST)[]
Ja, het spelen met melkdoppen (@Nietanoniem) herinner ik me nog wel. Je moest die gekleurde, aluminium doppen heel voorzichtig van de fles afpeuteren, ze mochten niet kapot gaan. We hadden meerdere kleuren, zoals licht- en donkerblauw (van -half-volle melk) en rood (van de karnemelk). Mijn moeder nam die doppen 's avonds dan mee met de afwas.
Ik weet niet hoe dat spel ging, het waren mijn oudere broers die die doppen meenamen naar het schoolplein. Dit moet tweede helft jaren '70 zijn geweest, in de tijd dat we in Gelderland woonden. Later kwamen er kartonnen melkpakken voor de glazen melkflessen in de plaats en droogde de stroom melkdoppen op - en daarmee het spel. Groet, Rozemarijn vL (overleg) 15 okt 2021 12:23 (CEST)[]
De flessen met melkdoppen ken ik nog wel, niet alleen glazen flessen, maar ook van die plastic - met vieze chocolademelk. Heb er alleen nooit spelletjes mee gespeeld. Nietanoniem (overleg) 20 okt 2021 12:06 (CEST)[]

Ik stel in vraag ?Bewerken

Beste , ik stel in vraag, bij het artikel Explosiegrens Of de waarden van Diesel wel juist zijn..? Omdat Kerosine en Diesel Dezelfde waarde Hebben. Dank voor antwoord M.v.g Paul www.ardennen-gids.be – De voorgaande bijdrage werd geplaatst door 212.239.239.247 (overleg · bijdragen)

De waarden zijn correct, alleen de ondergrens is hetzelfde. --Sb008 (overleg) 19 okt 2021 17:43 (CEST)[]
staat in die tabel benzine met opzet verkeerd gesorteerd? michiel043 (overleg) 19 okt 2021 17:50 (CEST)[]
Zal zijn overgenomen van een Engelstalige tabel, waar dus gasoline stond. –bdijkstra (overleg) 19 okt 2021 17:55 (CEST)[]

Visuele diff awolBewerken

Ik plaatste dit bericht op mw:Talk:VisualEditor/Diffs, maar vraag me nu af: hebben anderen hetzelfde verschijnsel of ligt het aan mijn chromebook? Het gaat om de link direct hieronder:

Nl:special:diff/60191909 (simply correcting a sorting error) shows up immediately in Wikitext, but takes endlessly in visual mode. When I switched back to wikitext diff after waiting for fifteen minutes (!) it responded immediately. A second try gave the same result.
I encountered the problem while editing in the visual mode, but clicking the diff from the history page or the link above made no difference.
The previous diff has no such issues. My computer is a chromebook with lavish amounts of memory but a slow outdated processor. The browser is Chrome of course.  →bertux 19 okt 2021 19:24 (CEST)[]
Gaat dit over het bewerken of over het tonen van de diff? –bdijkstra (overleg) 19 okt 2021 20:37 (CEST)[]
De diff wordt niet getoond en er blijft eindeloos een wachtbalk heen-en-weren. Dat was al zo toen ik hem tijdens het bewerken wilde bekijken en dat bleef zo toen ik de diff op andere manieren wilde benaderen, maar alleen bij de visuele diff. De Wikitekst-diff is in orde  →bertux 19 okt 2021 20:44 (CEST)[]

Wat te doen tegen ongewenst automatisch scrollen tijdens het doornemen van tekst (op diverse websites)?Bewerken

Op veel websites (gelukkig niet op Wikipedia) wordt (in ieder geval met Firefox) het doornemen van tekst steeds verstoord doordat na enig scrollen extra tekst aan het eind wordt toegevoegd, waarbij automatisch vooruit wordt gescrolled. Je moet dan terugscrollen en zoeken waar je gebleven was, als je daar verder wil gaan. Het gebeurt onder meer bij Google Nieuws en bij reacties op Youtube. Is daar wat tegen te doen? - Patrick (overleg) 20 okt 2021 11:05 (CEST)[]

Een antwoord heb ik niet, wel een aanvullende vraag, en wat linkjes voor wie het wil bekijken: in The Week Speedreads en cartoons verandert de url tijdens het scrollen en moet je soms even wachten op het laden, bij YouTube blijft de url hetzelfde. Het uitschakelen van JavaScript (bijvoorbeeld met deze schakelaar) zal in veel gevallen helpen, maar bij YouTube zie je dan helemaal niks meer.
Zijn dit twee fenomenen, met/zonder veranderende url?  →bertux 20 okt 2021 11:30 (CEST)[]
Ik heb er last van bij gevallen waarin de url niet verandert. Ik heb in Firefox Automatisch scrollen en Vloeiend scrollen uitgeschakeld, maar dat werkt niet, of niet altijd. Ik ga dat verder uitproberen en ook het uitschakelen van Javascript. Met dat laatste werkt YouTube zelf bij mij nog wel. - Patrick (overleg) 20 okt 2021 12:13 (CEST)[]
Ik ken het fenomeen van een tekst die zich al scrollend uitbreidt onder meer van de Encyclopædia Britannica. Zo kun je beginnen in het lemma 'Hamlet', om vervolgens al scrollend automatisch het lemma 'Claudius' binnen te glijden, waarbij overigens ook de URL verandert. Bij mij gebeurt dat alles echter redelijk soepeltjes, in elk geval zonder dat de tekstfocus zomaar verspringt – en dat geldt zowel voor Firefox als voor een aantal andere browsers waarin ik het net even heb getest. Je zou eens kunnen kijken of je er ook last van hebt als je Firefox opstart in de zogeheten safe mode (oftewel, in ietwat moeizaam maar scrabblewaardig Nederlands, de probleemoplossingsmodus). Zo niet, dan zou het wel eens aan een van je add-ons kunnen liggen. — Matroos Vos (overleg) 20 okt 2021 12:49 (CEST)[]
Ik heb er nooit last van gehad, maar ik gebruik Firefox dan ook slechts zelden. –bdijkstra (overleg) 20 okt 2021 13:53 (CEST)[]

plaatje verwijderenBewerken

Is er iemand die weet hoe het plaatje op ceb:Kruppomenia levis kan worden verwijderd? Dat is namelijk een foutief plaatje dat bij een heel andere diersoort behoort. Ik heb het op alle andere sites (Wikipedia, Wikidata, Wikispecies) verwijderd gekregen, maar ceb-wiki is kennelijk hardnekkig. Overigens ook merkwaardig dat er een © op staat terwijl het plaatje wel is vrijgegeven.
Eigenlijk zou het goed zijn de naam van het bestand te wijzigen omdat die de verkeerde diersoort suggereert, maar is dat überhaupt mogelijk?  Erik Wannee (overleg) 20 okt 2021 15:53 (CEST)[]

ik heb ceb:Espesyal:Purge geprobeerd en nu is het weg. het hernoemen van afbeeldingen op commons is mogelijk. Zie commons:Commons:File renaming Rwzi (overleg) 20 okt 2021 16:04 (CEST)[]
Ik zie daar geen plaatje en blijkens de geschiedenis en de brontekst is er ook nooit een geweest. Ik vermoed daarom, dat het om een plaatje gaat dat direct uit Wikidata werd geplukt. Nu het daar weg is, moet het op cebwiki ook weg zijn. Zo nodig kun je even de paginacache legen  →bertux 20 okt 2021 16:05 (CEST)[]
Ik zie geen plaatje meer op die pagina. Mogelijk zit die versie nog in jouw cache. Mbch331 (overleg) 20 okt 2021 16:06 (CEST)[]
Inderdaad is het plaatje nu weg. Het lag niet aan mijn cache, want ik had het plaatje gisteravond al uit Wikidata verwijderd, en redelijkerwijs zou het een dag en een computerstart later toch weg moeten zijn. Ik denk dat het de actie van rwzi is geweest die het voor elkaar heeft gekregen.
Fijn dat het ook mogelijk is om het plaatje te (laten) hernoemen. Alleen moet ik er nu nog achter zien te komen welk diertje het wel is, zodat het die naam kan krijgen. Ik heb een sterk vermoeden dat hij uit de familie Terebridae komt, en vermoedelijk een Terebra is, maar is het dan de T. bernardi, de T. dislocata, de T. fujitai, de T. lima, de T. russoi, de T. vanuatuensis, de T. venilia of nog een andere? Of misschien toch zelfs uit een ander geslacht? Is er een malacoloog in de zaal?  Erik Wannee (overleg) 20 okt 2021 18:53 (CEST)[]
Dat tijdsverloop zegt mij niets en die herstart weinig: mijn computer serveert mij gewoon de pagina van gisteren als ik hem 's middags start na 16 uur rust, tenzij de pagina zelf een update-verplichting specificeert  →bertux 20 okt 2021 19:29 (CEST)[]
Maar in de anderstalige wiki's, Wikidata en Wikispecies was hij instantaneously verdwenen, alleen in de ceb-versie bleef hij alsmaar staan.  Erik Wannee (overleg) 20 okt 2021 19:55 (CEST)[]
Update-instellingen kunnen per project en per pagina verschillen en weinig bezochte pagina's krijgen niet de hoogste prioriteit. Niet dat ik wil suggereren dat de ceb slechter bezocht wordt dan de nl.  →bertux 20 okt 2021 22:11 (CEST)[]
Dank voor het meedenken. Ik heb inmiddels hernoeming van het plaatje aangevraagd.  Erik Wannee (overleg) 22 okt 2021 11:03 (CEST)[]

Vertakking in sjabloon Stamboom2 die niet luktBewerken

Ik heb zitten puzzelen in de stamboom op Kraakbeenvissen#Taxonomie. Daar staat onderaan die stamboom een figuurtje dat er niet hoort. Als ik een * weghaal in de onderste regel dan verdwijnt dat ongewenste figuurtje, maar staat de aftakking te ver naar links. Doe ik iets fout, of zit er ergens een foutje in het sjabloon? Is er iemand die dit weet te fiksen?  Erik Wannee (overleg) 21 okt 2021 14:09 (CEST)[]

Je kan met dat sjabloon geen niveau's overslaan. Dus je zal een naamloze orde in moeten voegen. –bdijkstra (overleg) 21 okt 2021 15:06 (CEST)[]
Voor die naamloze orde heb ik dan maar een  -spatie ingevoerd. Mooier wordt het er niet op, maar kennelijk is dat de beperking van het systeem.  Erik Wannee (overleg) 21 okt 2021 16:29 (CEST)[]

Nietbestaande bijdragenBewerken

Ik heb gekeken naar de Speciaal:MijnBijdragen. Daarin staan bijdragen uit 2011 aan het artikel over Glazen Bouwsteen en Martin Verkerk. Deze bijdragen kan ik niet hebben gemaakt, want mijn laptop heb ik vorig jaar gekocht en is nieuw, niet tweedehands. 94.208.124.179 21 okt 2021 20:33 (CEST)[]

De bijdragen van oningelogde gebruikers worden toegekend aan een IP-adres, want dat is het enige wat we weten. Kennelijk hebt u een adres dat voorheen is gebruikt door iemand anders. Dat is volkomen normaal, IP-adressen worden voortdurend hergebruikt. Het is niet iets om u zorgen over te maken.
Met vriendelijke groet  →bertux 21 okt 2021 21:35 (CEST)[]
Oké, dat bergijp ik. Maar waarom wisselde ik opeens van IP-adres? Ik heb ook eens andere bijdragen gemaakt en die staan er nu dus niet meer.94.208.124.179
Dat is grotendeels een beslissing van uw internetprovider, al kan het ook te maken hebben met de nieuwe laptop. Mogelijk hebt u een dynamisch IP. Dergelijke IP's blijven ondanks hun naam vaak jarenlang stabiel, maar kunnen veranderen als dat de provider uitkomt. Als u wilt dat uw bijdragen bij elkaar blijven, kunt u het beste een gebruikersnaam aanmaken; dat is ook gunstiger voor uw privacy, want u hoeft zelfs geen mailadres of iets dergelijks op te geven. Hoewel IP'ers soms aangeduid worden als anoniemen, zijn zij in feite minder anoniem dan mensen met een gebruikersnaam, want uit een IP is informatie over uw regio en provider af te leiden →bertux 21 okt 2021 21:48 (CEST)[]
Zoals gezegd, met een gebruikersnaam kunt u vrijwel anoniem zijn, zolang u zich niet met projectverstoring bezig houdt. Niettemin heeft het opgeven van een mailadres in de Voorkeuren wel voordelen, waaronder de mogelijkheid van wachtwoordherstel  →bertux 21 okt 2021 21:56 (CEST)[]

Advies/hulp gevraagd m.b.t. sjabloon voor woonplaatsen in een gemeenteBewerken

Ik heb gezien dat het ene artikel over een gemeente een redelijk dynamische tabel met woonplaatsen in de gemeente geeft, terwijl andere artikelen een opsomming of lijst geven. Zo zijn er vast ook nog gemeentes waar helemaal geen lijst wordt gegeven of waar een tabel is met "vaste" aantallen. Ik wilde daarin een lijn trekken en het dan het liefst nog een stap hoger aanpakken. Zie voor een globaal overzicht van mijn plan mijn kladblok. Ik zou graag willen weten of jullie tips hebben of nog suggesties of andere opmerkingen, alvorens ik begin te puzzelen aan iets wat wellicht helemaal niet mogelijk is. Mvg, Ennomien (overleg) 22 okt 2021 10:13 (CEST)[]

De tekst in je kladblok maakt voor mij niet alles duidelijk. Heb je een link naar een gemeente waar het in jouw optiek goed of bijna goed gedaan is?
Ikzelf vind vooral de ontwikkeling van de aantallen belangrijk, ik erger me dood als ik de aantallen van 2015 vervangen zie worden door die van 2020. Die laatste zijn niet belangrijker of beter dan de eerste. Volgens mij is RonnieV aan het stoeien geweest met mooie grafieken voor de ontwikkelingen, die hun gegevens ontlenen aan Wikidata  →bertux 22 okt 2021 11:07 (CEST)[]
Een voorbeeld waar het heel erg de goede kant op gaat is Hulst (gemeente). Ik snap wat je bedoelt, ik ben benieuwd wat Ronnie of anderen daar over in te brengen hebben. Wel vraag ik me af of die ontwikkeling wenselijk is in een tabel met de woonplaatsen, of dat die beter apart kan worden weergegeven voor alle plaatsen in de gemeente tezamen. Ennomien (overleg) 22 okt 2021 11:46 (CEST)[]
Juist bij de woonplaatsen. (Nederlandse) gemeenten groeien vaak sprongsgewijs door annexaties en herindelingen, zodat totalen eerder een bestuursopvatting weerspiegelen dan een echte toename van het inwonertal. Daardoor sneeuwen ontwikkelingen in de echte wereld, zoals urbanisatie en suburbanisatie vaak onder. Bij woonplaatsen komt zoiets ook voor, zoals bij Heeswijk-Dinther, maar dat is toch veel zeldzamer. Als zo'n tabel veel jaren en veel kernen omvat kan hij waarschijnlijk beter gesplitst worden over de woonplaatspagina's, a fortiori als de gegevens in grafiekvorm staan.  →bertux 22 okt 2021 12:25 (CEST)[]
Oh ja, natuurlijk. Maar die grafieken kunnen dan beter op de desbetreffende pagina zelf komen te staan en niet op de pagina over de gemeente, dat zou een beetje too much zijn. Dan zijn Ronnies project en mijn idee dus eigenlijk twee losstaande dingen. Misschien kunnen we gebruikmaken van dezelfde module met data (of via Wikidata), waarbij mijn project alleen de recentste data gebruikt. Ennomien (overleg) 22 okt 2021 14:11 (CEST)[]

──────────────────────────────────────────────────────────────────────────────────────────────────── Uiteraard kan je een dynamische (verschillend aantal regels) tabel maken. Ik misbruik even de module voor het creeren van de stand bij 'n sport.

Pos Team Wed Ptn
1 Clinge 0 0
2 Graauw 0 0
3 Heikant 0 0
4 Hengstdijk 0 0
5 Hulst 0 0
6 Kapellebrug 0 0
7 Kloosterzande 0 0
8 Kuitaart 0 0
9 Lamswaarde 0 0
10 Nieuw-Namen 0 0
11 Ossenisse 0 0
12 Sint Jansteen 0 0
13 Terhole 0 0
14 Vogelwaarde 0 0
15 Walsoorden 0 0
Bijgewerkt tot wedstrijd(en) gespeeld op 2021. Bron: CBS

Dit is uiteraard niet wat je zoekt, maar denk de "pos" en "wed" kolom weg, lees bij "team" "woonplaats" en bij "ptn" "inwoners". Zolang de data meer ergens voorhanden is, dan is de kolom inwoners correct in te vullen. Ook is de plaats "Hulst" vet, ik heb maat even aangenomen dat het gemeentehuis daar staat. Zolang als de data ergens voorhanden is, kan jij eigenlijk alles maken. Dit was alleen even snel bedoeld om een dynamisch regelaantal te laten zien. --Sb008 (overleg) 22 okt 2021 14:54 (CEST)[]

Dank je wel! Het ging mij er inderdaad om óf het kon. Nu ik weet dat het kan en welke sjablonen dat doen (Sjabloon:Tabel woonplaatsen Nederland bijvoorbeeld ook), kan ik uit hun broncodes wel opmaken hoe het precies moet. Ik denk dat ik nu een heel eind kom. :) @Bertux, zie jij dan nog een manier om bevolkingsontwikkeling in zo'n tabel weer te geven of kan dat beter in de artikelen van de woonplaatsen zelf? Ennomien (overleg) 22 okt 2021 16:14 (CEST)[]
Het praktische antwoord is: gewoon aan de rechterkant kolommen toevoegen: 2019, 2020, 2021 of 1940/60/80/2000/20. Tot 10 kolommen is dat voldoende leesbaar. De vraag op welke pagina's dit het meest wenselijk is (plaats, gemeente of beide) kun je opgooien in De kroeg of het Redactielokaal. De grafiekrepresentatie van de gegevens kan het beste op de plaatspagina's, of je moet het aantal reeksen beperken tot drie à vier, bijvoorbeeld de grootste kernen. Bij Franse gemeenten, waar veel minder heringedeeld wordt, is zo'n grafiek per gemeente veel vaker zinvol.
Het zouden balkgrafieken moeten zijn, want je ziet het lelijk misgaan met de lijngrafiek bij Marseille#Demografie, waar vermoedelijk 70 jaar aan gegevens ontbreekt. Dan moet er ook meteen ruimte onder de laagste waarde komen, want anders krijg je een onzichtbare balk, met lengte 0. Meteen maar weer @RonnieV pingen hiervoor  →bertux 22 okt 2021 16:47 (CEST)[]
Dat was niet het doel van mijn project, maar als ik dan toch bezig ben en het is gewenst, doe ik dat er natuurlijk bij. Nadeel is wel dat ik dan ook al die inwoneraantallen uit het verleden ergens vandaan moet halen. Ik zal het eens gaan vragen op een van die twee plekken als ik ermee verder ga. Bedankt. Ennomien (overleg) 22 okt 2021 17:42 (CEST)[]
  • Hallo Gebruiker:Ennomien en Bertux, Ik had vanmorgen al een lange reactie getypt, maar die is ergens verloren gegaan met een bwc tijdens een telefoongesprek op mijn mobiel in een hand. Ik ga proberen het alsnog uit te schrijven.
Ik ben bezig geweest met de bevolkingsaantallen voor Slowakije en Frankrijk. Die zitten allemaal (voor een beperkt aantal jaren) of deels (Frankrijk) in Wikidata. Zo worden op Ljubljana de aantallen in de infobox en in de tekst veranderd als het als belangrijkste aangemerkte (doorgaans: meest recente) inwonertal in Wikidata wordt aangepast.
De grafieken, zoals voor de Franse plaatsen, gebruiken alle gegevens die beschikbaar zijn op bijvoorbeeld d:Q846947#P1082. Het resultaat is een grafiek zoals La_Chapelle-sur-Chézy#Demografie. Het toevoegen van de grafiek aan Ljubljana vroeg niet meer dan deze wijziging.
Voor een tabel zoals Ennoniem die voorstelde op de overlegpagina zou iemand iets moeten maken in LUA. Deze query geeft wel een aardig beeld van de plaatsen binnen Ljubljana, maar dit lijkt mij niet goed voor de gemeente Hulst. Probleem is dat bij de wel opgenomen kernen geen van de waarden is gemarkeerd als belangrijkste (En overigens zijn het erg oude cijfers). Ander probleem is dat veel kernen kennelijk niet zijn aangemerkt als behorend tot de gemeente Hulst, of er geen inwonertal is ingegeven op kernniveau, zelfs niet voor de hoofdstad.
Bertux merkt terecht op dat annexaties en hervormingen kunnen leiden tot (grote) veranderingen in het inwonertal. Bij het opvragen van de inwonertallen moet dus goed gekeken worden naar het jaartal van de meting, en geprobeerd worden alle gelijk te krijgen: liever een totaaloverzicht per 2020, dan een overzicht per 2021, waarbij de helft van de kernen of wegvalt of stiekem nog een niet-bijgewerkt aantal over 2020 presenteert. Voor de grafieken vond ik dat ik kon volstaan met het weergeven van de daadwerkelijke aantallen, dat de uitleg in de tekst op de pagina gegeven moet worden.
Willen we, zoals Bertux ook aangeeft, aantallen van meerdere jaren naast elkaar plaatsen, dan moet er dus voor meerdere jaartallen gezocht worden naar de cijfers en per jaartal moeten de beschikbare cijfers getoond worden. Bedacht moet worden dat (om bij Hulst te blijven) de cijfers van Kloosterzande niet getoond moeten worden in de jaren voor 2002, omdat Kloosterzande toen nog onder Hontenisse viel. Technisch is dat allemaal mogelijk, maar het is wel belangrijk dat een en ander heel duidelijk is aangegeven in Wikidata. Dat is het (nu) nog niet. Een groot voordeel van Wikidata is dat informatie meteen voor iedereen beschikbaar is, dus dat de tabel zo op de Engelse, Portugese en Slowaakse Wikidata beschikbaar is.
Of de inwonertallen in staafgrafieken of in lijngrafiek moeten, daarover kunnen we nog best een boompje opzetten. Staafgrafieken geven doorgaans geen lineaire verdeling op de x-as, dus als er cijfers uit 1901, 1968, 1975, 2011, 2016, 2017 en 2018 zijn, laat een grafiek een even grote afstand tussen 1901 en 1968 zien als tussen 2017 en 2018. Dat vind ik dan weer niet wenselijk. Als er in de loop der tijd meer aantallen beschikbaar komen, zoals voor Marseille, dan zal de rechte lijn van 1901 naar 1968 vanzelf onderbroken worden.
Ik heb er juist voor gekozen om de nulwaarde los te laten (het nulpunt van de y-as dynamisch te laten kiezen), om bij plaatsen met een redelijk stabiel inwonertal de wijzigingen in beeld te brengen. Begint de y-as bij nul, dan zijn wijzigingen als 1010, 1033, 989, 1020 niet of nauwelijks zichtbaar in een grafiekje. Een makkelijke optie waarmee het beginpunt op de y-as (zeg) een kwart van het verschil tussen de minimale en maximale waarde op die as gelegd wordt, is mij niet bekend. Met vriendelijke groeten, RonnieV (overleg) 22 okt 2021 18:27 (CEST)[]
Zie vooral Gebruiker:RonnieV/Slovenië voor het gebruik van Wikidata. Wikiwerner (overleg) 22 okt 2021 19:59 (CEST)[]
Bedankt voor je reactie en zonde dat die vorige verloren is gegaan! Als ik het goed begrijp is LUA nodig om meerdere bevolkingsaantallen van Wikidata af te halen, want een (1) enkel aantal kan gewoon met {{#\property:Pxxx|from=Qxxx}} toch? Een grafiek met assenstelsel (en dus geen staafdiagram) lijkt mij het beste, die interpoleert en dat lijkt mij beter dan een onjuiste schaalverdeling bij de staafdiagrammen. Voor de rest ga ik binnenkort eerst eens kijken wat de wensen zijn. Ik vind tabellen maken met alle plaatsen in gemeentes om te beginnen wel een opdracht die groot genoeg is eigenlijk. Mvg, Ennomien (overleg) 23 okt 2021 10:26 (CEST)[]
Iets als deze query geeft een overzicht van alle nederzettingen in de aangegeven gemeente (het mooie Hulst). Die query geeft nu nog een aantal dubbelen (Bosschehoofd (wegens meerdere bevolkingsaantallen), Kloosterzande) en een enkel ongewenst object (een klein houten bijenverblijf.
Deze variant beperkt het tot woonplaatsen, moeten we alleen nog de ongewenste bewonersaantallen eruit vissen. Idealiter zouden we bij iedere kern aangeven van wanneer het weergegeven inwonertal dateert en welke bron ervoor gegeven wordt.
{{Inwonertal|id=Q437|soort=waardepuur}} inwoners ({{Inwonertal|id=Q437|soort=datumbron}}) geeft het aantal inwoners, de datum en de bron weer voor Q437 (Ljubljana). Op vergelijkbare wijze zou je dit voor de afzonderlijke kernen in Hulst kunnen doen (alleen moeten die waarden nog naar Wikidata gebracht worden.
De query helpt in ieder geval om de kernen in beeld te brengen, en we kunnen van daar uit verder gaan werken om het te automatiseren. Maar het blijft voorzichtig werken met plaatsen die verschuiven van de ene gemeente naar de andere.
Volgende week maar eens verder puzzelen... Met vriendelijke groet, RonnieV (overleg) 23 okt 2021 14:26 (CEST)[]
Bedankt voor het meedenken! Ik ga er binnenkort ook mee aan de slag. Het ziet er veelbelovend uit. Ennomien (overleg) 23 okt 2021 15:51 (CEST)[]

Kan afbeeldingsgegevens niet laden (fout: http)Bewerken

Op mijn overlegpagina kreeg ik de volgende vraag, waar ik zelf geen antwoord op weet:

Op de pagina van het Experiment van Milgram staat een afbeelding met als titel 'De advertentie waarmee Milgram proefpersonen wierf.' Als ik die aan klik, staat er 'Kan afbeeldingsgegevens niet laden (fout: http)' Hoe kan dit opgelost worden?

Op mobiel levert het bij mij geen problemen op. Op desktopversie wel, bij allebei de afbeeldingen overigens. Weet iemand wat hier fout gaat? Dajasj (overleg) 24 okt 2021 10:07 (CEST)[]

Ik zie op de desktop in FF/Chrome beide geen problemen, dus kan het niet reproduceren. Ik heb nu wel op beide afbeeldingen een 0 edit gedaan, soms helpt dat. Ciell need me? ping me! 24 okt 2021 10:38 (CEST)[]
Is het een probleem bij het weergeven van de afbeelding in het artikel, het laden van de afbeelding in de mediaviewer (de 'grote versie' in de pop-up waar gebruikers komen als ze op de afbeelding klikken), of bij het bekijken van de bestandspagina op Commons? Ciell need me? ping me! 24 okt 2021 10:40 (CEST)[]
De mediaviewer, waar dan normaal ook rechtsonderin de blauwe knop met "Meer informatie" verschijnt. Het ontbreken daarvan is op zich wel vervelend, want je kan dus niet gemakkelijk naar Commons.
Ik ga even verder testen. Ik zie dat in privémodus het probleem zich niet voordoet. Dus misschien is het een add-on. Dajasj (overleg) 24 okt 2021 10:46 (CEST)[]
Hmm het komt door adblockers. Zowel uBlock als AdBlocker Ultimate. Op zich wel vreemd en vervelend dat een adblocker dat verhindert. Dank voor je hulp in ieder geval! Dajasj (overleg) 24 okt 2021 10:50 (CEST)[]
Dat is inderdaad niet handig. Het is misschien een goed idee om dit in ieder geval te melden op Phabricator, en kan er van onze kant iets gedaan worden aan de blokkering van de pop-up. Ciell need me? ping me! 24 okt 2021 10:54 (CEST)[]
Ik gebruik uBlock Origin, dat is vermoedelijk wat Dajasj ook gebruikt. Die heb ik standaard uitgeschakeld voor alle Wikimedia-projecten, er zijn hier immers geen advertenties, behalve de banners. Maar als ik uBlock inschakel voor de pagina en de afbeelding heb ik nog steeds geen problemen.
Ik heb standaard de mediaviewer uitgeschakeld, kan even niet vinden waar, anders zou ik daarvan het effect uitproberen. En ik heb de optie 'rechtstreeks naar de beschrijvingspagina op Commons gaan' ingeschakeld. Dat zal wel geen verschil maken, die optie werkt niet bij rechtstreekse links zoals deze: File:Milgram Experiment advertising.png. Ook dan heb ik geen probleem. Helpt het om de mediaviewer uit te schakelen?  →bertux 24 okt 2021 12:37 (CEST)[]
Schakel ik de mediaviewer en uBlock in, dan wordt de afbeelding gewoon weergegeven, maar krijg ik onderaan wel de genoemde melding en dus geen vervolg op Commons. UBlock geeft bij Commons een tweetje: twee elementen geblokkeerd. Bij nlwiki is niets geblokkeerd en de rechtstreekse link blijft gewoon werken. De adblocker maakt dus ruzie met de mediaviewer.
Ik heb er te weinig verstand van om te weten of het relevant is, maar als ik binnen de paginabron specifiek de elementbron voor de afbeelding aanklik, krijg ik de pagina:
view-source:chrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/web_accessible_resources/epicker-ui.html?secret=k3xf45&epid=offxp5ek1&zap=1
met de melding:
cjpalhdlnbpafiamejdnhcphjbkeiagm wordt geblokkeerd
Deze pagina is geblokkeerd door een extensie
Probeer je extensies uit te zetten.
ERR_BLOCKED_BY_CLIENT  →bertux 24 okt 2021 13:17 (CEST)[]
Intussen lijkt het erop dat iemand de mediaviewer centraal uitgeschakeld heeft, althans krijg ik hem niet meer te zien, hoewel ik hem net ingeschakeld had  →bertux 24 okt 2021 13:23 (CEST)[]
Nu weer wel, en ik heb een wat uitgebreidere versie van de foutmelding opgespoord:
<p class="mw-mmv-credit empty mw-mmv-ttf-container mw-mmv-ttf-normal">Kan afbeeldingsgegevens niet laden (fout: http)

 →bertux 24 okt 2021 13:32 (CEST)[]
Ik kan de mediaviewer omzeilen door de afbeelding in een nieuw tabblad te openen (rechter muisknop of Ctril-klik of Shift-Ctrl-klik). Dan krijg je bovenaan een link 'bekijken op Commons'. Daar heeft de adblocker geen moeite mee  →bertux 24 okt 2021 15:21 (CEST)[]
Los van de discussie hierboven gebeurde er iets geks toen ik het bestand opende in IrfanView, maar na opnieuw opslaan en uploaden veranderde er niets. –bdijkstra (overleg) 24 okt 2021 12:45 (CEST)[]
Volgens mij komt het door een mislukte CORS-aanvraag voor de afbeelding, maar ik weet ook niet zo goed wat je er aan doet, anders dan je adblocker uitzetten. --Strepulah (💬) 24 okt 2021 16:39 (CEST)[]
Ik heb even verder geklikt vanuit Strepulahs link en kwam uit op https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. Daar lees ik:
What requests use CORS?
This cross-origin sharing standard can enable cross-site HTTP requests for:
Is de afkorting ttf in de foutmelding die ik hierboven noemde een daderspoor?  →bertux 24 okt 2021 16:55 (CEST)[]
Nee. Dat is iets anders met toevallig eenzelfde afkorting. --Strepulah (💬) 24 okt 2021 17:31 (CEST)[]

Prive gegevens verwijderen aubBewerken

Goede morgen,

Wilt u mijn prive gegevens verwijderen uit wikipedia a.u.b. ? Het gaat om de volgende pagina : https://www.classicistranieri.com/nl/articles/r/0/0/Gebruiker~R00dbaard_ec93.html

Dank voor uw begrip, Met vriendelijke groet,

```` – De voorgaande bijdrage werd geplaatst door 85.148.142.84 (overleg · bijdragen)

De website waar u naar verwijst is, ondanks de logo, geen website van Wikipedia, maar een mirrorsite. Op de oorspronkelijke wiki-pagina Gebruiker:Roodbaard is te zien dat de genoemde privégegevens reeds gewist zijn. Mvg, Chescargot ツ (overleg) 26 okt 2021 11:14 (CEST)[]
We hebben hier wel de pagina Gebruiker:R00dbaard en ik zal een verzoek indienen om oude versies te verbergen. Maar op de pagina die u linkt hebben wij geen invloed, dat is géén Wikipedia-pagina, al ziet hij er wel zo uit. U kunt een verwijderverzoek indienen bij de site waar die pagina deel van uitmaakt: https://www.classicistranieri.com/
Met vriendelijke groet →bertux 26 okt 2021 11:18 (CEST)[]
Misschien is een verzoek om de gegevens uit Google te verwijderen mogelijk? Zie deze pagina. En contact opnemen met de eigenaar van dit domein is natuurlijk altijd te proberen (edit: de link naar dit contactformulier is tijdelijk, anders ook te vinden via de whois-records). Verder zou ik de link die hier geplaatst is misschien beter weer verwijderen, wanneer de vraag voldoende beantwoord is. N👁vopas (overleg) 26 okt 2021 12:32 (CEST)[]
P.s. De gebruikerspagina op Wikipedia heeft inmiddels een nuweg-nominatie, maar als dit om een (automatische) mirror-website gaat, is het misschien beter om dit juist niet te doen of om i.i.g. een nieuwe pagina aan te maken zonder privacy-gevoelige informatie, zodat de genoemde mirrorpagina ook tzt automatisch geüpdatet wordt (en dus de ongewenste info wordt vervangen). N👁vopas (overleg) 26 okt 2021 12:43 (CEST)[]
De mirror heeft de wijzigingen van na maart 2008 niet meegenomen, dus van automatisch updaten lijkt me geen sprake. –bdijkstra (overleg) 26 okt 2021 12:49 (CEST)[]
De mirrorversie is van 30 mrt 2008 23:50, sindsdien zijn er nog vier versies geplaatst. In oktober van dat jaar is de tekst wissen aub geplaatst, maar die versies zijn niet opgemerkt. Het verwijderen zal dan ook niets verstoren  →bertux 26 okt 2021 12:50 (CEST)[]