Help:Helpdesk

Overzicht hulppagina's
Alfabetische index Portaal:Hulp en beheer Helpdesk Toch een paar regels Veelgestelde vragen (FAQ) Veelgestelde verwijderingsvragen Hoe je mee kunt doen Waarom zou ik meedoen? Uitleg Terminologie op Wikipedia Nieuwe pagina aanmaken Titel kiezen Titel wijzigen Redirectpagina aanmaken Pagina's samenvoegen Tips voor het schrijven van een goed artikel Tips voor het vertalen van een artikel Tekstopmaak Spelling Tabellen Formules Tijdbalken Afbeeldingen en bestanden Geluid Links Interwiki-links Sjablonen Navigatie Categorieën Kleine wijziging Bots Coördinaten & externe kaarten Hulpmiddelen Donkere modus Toegankelijkheid Privacy
Zie ook Regels en richtlijnen Zie ook Artikelen bewerken

Welkom op de Wikipedia-helpdesk! 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. Klik hier om een vraag te stellen 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.

Cursor positioneren

De laatste dagen kost het soms moeite om in bewerkingsvensters met muis of tutsjpet de cursor op de gewenste plaats te positioneren (broncode, monobook, LM 20.3, FF 98.0.2 64). Het lijkt geen hardwareprobleem te zijn: in bv. LibreOffice Writer en Xed speelt dit niet. Weet iemand wat er aan de hand kan zijn en of er wat aan te doen is? Wutsje 2 apr 2022 21:18 (CEST)

Ik merkte het ook al op, maar vandaag niet meer. De cursor weigerde domweg te verschijnen of kwam een of meer alinea's hoger dan waar ik klikte. Dubbelklikken of driemaal klikken hielp ook niet, dat had geen enkel merkbaar effect. In de brontekstmodus vond ik een wurkeround (om in Wutsjes stijl te blijven): Met Ctrl-A selecteer ik alles, daarna gebruik ik een willekeurige cursortoets en is de cursor weer zo mak als een lammetje. Een hardwareprobleem kan het inderdaad nauwelijks zijn, want met mijn chromebook erbij hebben we drie totaal verschillende apparaten. Mijn skin is Vector, versie 2010.

In de visuele modus is en was er niets aan de hand, Wikimedia zet harde middelen om ons die kant op te duwen!  →bertux 2 apr 2022 21:41 (CEST)

Ja, dat gevoel heb ik er ook steeds bij, maar er is vast gewoon iets gemisprogrammeerd, net als een week of wat geleden met dat overlegtabjestekstongelukje. Wutsje 2 apr 2022 21:51 (CEST)

Dank trouwens voor de wurkerount, daar ben ik blij mee. Wutsje 2 apr 2022 21:54 (CEST)

Ik loop tegen hetzelfde probleem aan, zelfs bij het schrijven van dit berichtje. Je klikt je af en toe bijkans een ongeluk, voordat je de cursor op de plek hebt waar je hem hebben wil. Heel lastig. Als je even niet oplet, zit je op de meest onmogelijke plekken je wijzigingen of aanvullingen door te voeren. Kortom, heel vervelend, dit. Groet, Piet.Wijker (overleg) 3 apr 2022 12:50 (CEST)

@Piet.Wijker: Zoals gezegd is er een handigheidje: CtrlA en dan ↑ of een andere pijltjestoets. Daarna doet de cursor het goed  →bertux 3 apr 2022 13:17 (CEST)

@ →bertux: Dank voor de tip. Ik ga het proberen. Groet, Piet.Wijker (overleg) 3 apr 2022 13:38 (CEST)

Aangezien ik niet die software (Linux/FireFox) gebruik kan ik daarbij niet helpen. Echter, misschien ligt het aan de browser. Kijk dan eens naar Brave (Chrome Engine met nieuwerwetsere voordelen). Wikipedia is reeds een erkende ontwikkelaar in het Brave ecosysteem. Wellicht loont het om je hier eens in te verdiepen en is daarmee ook het cursorprobleem verholpen. Démarche Modi (overleg) 3 apr 2022 14:41 (CEST)

Een andere browser dan Chrome is op een chromebook nauwelijks een optie. Los daarvan, dergelijke basisfunctionaliteit zou altijd moeten werken.

Overigens zijn er ook bij de visuele editor cursorproblemen, zij het dat die eerder vermoeiend dan hinderend zijn: in de dialoogvensters voor het toevoegen van een bronvermelding is er geen peil te trekken op de focus: soms staat die in het invulvakje waar die mijns inziens hoort, maar vaak genoeg moet je net zo lang op Tab ⇆ drukken tot de cursor daar verschijnt. Lastig en tijdrovend als je door een visuele of motorische handicap niet met muis of touchpad kunt of wilt werken. Dat focusprobleem speelt trouwens al jaren, terwijl het cursorprobleem nieuw lijkt te zijn. Ik verdenk een recente update van de Wikimedia-software  →bertux 3 apr 2022 15:12 (CEST)

Ik vermoed dat de ontwikkelaars out of the box denken. Démarche Modi (overleg) 3 apr 2022 15:26 (CEST)

Na het aanzetten van de syntax highlighting moet ik tot de trieste conclusie komen dat ik soms in Brave (MacOS Monterey 12.2.1 (21D62), Brave Versie 1.36.119 Chromium: 99.0.4844.83 (Officiële build) (x86_64)) ook het probleem van de zoek geraakte cursor heb. Maar ondertussen ben ik wel 0,07 USD rijker... tenminste, als die volatiele crypto niet ineens als een kaartenhuis in elkaar stort. Démarche Modi (overleg) 6 apr 2022 15:22 (CEST)

Het merkwaardige is: op de:wiki, en:wiki, es:wiki, fr:wiki, it:wiki en sv:wiki, alsmede op Commons en Meta, waar ik allemaal ook broncode/monobook gebruik, treedt dit verschijnsel consequent niét op. Nu begin ik me af te vragen of het wellicht enkel op de Nederlandstalige wiki speelt. Wat denken jullie? Wutsje 4 apr 2022 05:27 (CEST)

Dat zou me niet verbazen, ik merk al jaren dat nlwiki anders 'aanvoelt' dan de rest. Het zou iets met de css kunnen zijn, al dan niet in interactie met een recente updeet van de softwèèr. Zelf heb ik er al twee dagen geen last meer van, maar ik gebruik vooral de VE en de reageerfunctie. Ik heb dus ook niet geprobeerd de werkbalk uit te schakelen  →bertux 4 apr 2022 08:45 (CEST)

Als ik syntax highlighting uitzet lijkt het cursorpositioneringsprobleem niet meer op te treden. Jammer dat dat er voor nodig is. Wutsje 4 apr 2022 20:38 (CEST)

Dat zal ik dan ook maar doen, want dat eerdere voorstel van  →bertux met die knoppen heeft bij mij in elk geval tot niets geleid. Ik moest trouwens ongeveer 20 keer klikken, voordat ik de cursor op de juiste plaats kreeg en aan deze reactie kon beginnen. Tussen haakjes, waar vind ik dat, syntax highlighting? Ik zoek me rot, maar kan het niet vinden. Bvd en groet, Piet.Wijker (overleg) 4 apr 2022 21:28 (CEST)

In het balkje direct boven het bewerkingsscherm (dat je te zien krijgt als je hier Bewerkingsbalk inschakelen hebt aangevinkt) staat een pictogram van een potloodje. Daarop klikken zet syntax highlighting aan of uit. Wutsje 4 apr 2022 21:46 (CEST)

Ik heb het probleem nu ook en de truc met Ctrl-A die eergisteren werkte, hielp zojuist niet meer, maar nu weer wel. Wat bij mij ook werkt: dubbelklikken in de tekst als je de eerste keer in het bewerkingsvenster klikt; Normaal zou het dubbelgeklikte woord geselecteerd worden, maar dat gebeurt niet. Soms moet ook mijn volgende klik een dubbelklik zijn, maar daarna is het afwijkende gedrag over. Het uitschakelen van de syntax highlight is bij mij dus niet nodig, al helpt het inderdaad  →bertux 4 apr 2022 22:08 (CEST)

Intussen heb ik op en:wiki syntax highlighting eens aangezet – en prompt kreeg ik het gedoe daar ook. Dit is wel een oefening in zen zeg. Wutsje 4 apr 2022 22:21 (CEST)

Ik dacht eerst dat het een probleem op mijn computer was, maar niet dus. Inmiddels los ik het ook op met een of meer keer dubbelklikken. Maar na op "toon bewerking ter controle" geklikt te hebben begint het gedoe weer van voren af aan. Gouwenaar (overleg) 4 apr 2022 22:54 (CEST)

Dit klinkt als het rapport in T305333, welke inmiddels in ontwikkeling is en zal hopelijk over 2-3 dagen klaar en op Wikipedia uitgedraaid zijn. Zo niet, meld het dan aldaar of ping mij hier even. Groet! --Krinkle (overleg) 4 apr 2022 23:41 (CEST)

Ha, dat is bemoedigend. Dank voor je reactie. Groet, Wutsje 5 apr 2022 00:04 (CEST)

---

Zonet heb ik syntax highlighting weer eens aangezet. De cursor lijkt nu steeds twee regels lager dan ik wil terecht te komen. Hoe is dat bij jullie? Wutsje 9 apr 2022 09:28 (CEST)

De bovengenoemde Phab staat nog open, dus dat klopt: sinds 5 april is er geen voortgang. Bij mij komt de cursor altijd hoger dan waar ik klik en nog altijd helpt dubbelklikken en wederom dubbelklikken bij mijn chromebook, dus persoonlijk heb ik er weinig last van. Toch maar even Krinkle pingen, want dit kan honderden gebruikers het leven zuur maken. Desnoods maar terug naar een oude versie, zoals voorgesteld op Phabricator.

Voor de volledigheid: bij mij kan het meerdere alinea's schelen, zodat de cursor soms onzichtbaar en buiten het bewerkingsveld is. Dat wordt bevestigd als ik met Shift-pijltje de tekst selecteer: Normaal als je dat doet verspringt het beeld zodat de cursor in beeld komt, maar door deze bug gebeurt dat niet en komt de selectie pas na een tijdje in zicht.

Kwantitatief: bij drie experimenten scheelde het 114, 81 en 647 tekens en 1, 2 en 3 alinea's in Plagiaat, Kustwolfspin en CAMERA JAPAN Festival. Als ik het met die laatste herhaal krijg ik 391 tekens verschil, maar ik heb op een ander punt in het document geklikt. Er is een verband tussen de plaats waar je klikt en het verschil dat je krijgt.

Mijn indruk is, dat de cursor meestal twee alinea's te hoog komt, geen twee regels dus. Verder is de positionering in links-rechtsrichting goed, mits de alinea waar hij terechtkomt lang genoeg is. Zo niet, dan komt de cursor aan het eind van die alinea.

Verder: als ik in de eerste twintig of dertig tekens van een artikel klik gaat het daar, maar alleen daar goed. Bij Wutsje zou dat eventueel kunnen gelden voor de laatste tekens.

---

Een ander punt dat hier wel of niet mee te maken kan hebben: als ik de ongewijzigde bewerkpagina herlaad met Ctrl-Shift-R reageert de pagina soms alsof ik iets gewijzigd heb. Dat is iets dat op Commons al langer speelt, daar krijg ik de vraag of ik de pagina echt wil verlaten soms zelfs zonder dat ik een bewerkknop aangeraakt heb  →bertux 9 apr 2022 20:25 (CEST)

Dat laatste heb ik van de week op Commons voor het eerst kort achter elkaar ook een paar keer gehad, maar het was daar toen erg druk (avond in de VS) en ik heb er verder geen aandacht aan besteed. Het is ook nog niet weer gebeurd.

Wat je opmerking boven het streepje betreft: als ik in je eerste regel klik voor de b van "bovengenoemde", dan kom ik reproduceerbaar voor de r van "Voor" in de volgende alinea terecht, bij mijn bewerkingsschermbreedte exact drie regels lager. Klik ik in je eerste alinea voor de p van "persoonlijk", dan belandt de cursor voor de g van "verspringt" in de volgende alinea, voor mij weer precies drie regels lager. Verder lijkt je bevinding over de links-rechtsrichting en het verband met de lengte van de alinea voor mij ook op te gaan. Wutsje 9 apr 2022 21:07 (CEST)

@Wutsje The Phab taak staat nog open, echter de software wijziging is sinds dindag 5 april al gecontroleerd en in de software ingevoegd. De wekelijkse uitdraai begint maandagavond en het heeft de trein dus net gemist. Wellicht kun je op de beta wiki alvast een kijkje nemen? (Je kunt wanneer je aldaar inlogt evt de experimentele Vector 22 skin uitschakelen.) Krinkle (overleg) 9 apr 2022 22:12 (CEST)

Neuh, ik wacht gewoon wel even af. Dank voor de updeet. Wutsje 11 apr 2022 10:38 (CEST)

Dierenzorg Zaanstreek

Vorig jaar heb ik een artikel geschreven over Dierenzorg Zaanstreek. Ik begrijp dat dit artikel op de beoordelingslijst is geplaatst en later is verwijderd. Waar kan ik de argumenten vinden op grond waarvan het artikel is afgekeurd? Mogelijk staan deze op een oude beoordelingslijst die ik niet kan vinden. Ik wil het artikel graag aanpassen en opnieuw aanbieden ter plaatsing. – De voorgaande bijdrage werd geplaatst door Marquesta (overleg · bijdragen)

Hoi, het is te vinden op Wikipedia:Te_beoordelen_pagina's/Toegevoegd_20210505#Dierenzorg_Zaanstreek. Dajasj (overleg) 5 apr 2022 16:49 (CEST)

Verkleinde letters in bewerkingsvenster

Vandaag constateer ik dat de letters in de bewerkingsvensters veel kleiner zijn dan voorheen. Ik constateer dit niet alleen op nl-wiki maar ook elders (en-wiki, wikidata), dus kennelijk is dit een ingreep van 'hogerhand'. Is daar iets tegen te doen? Dit is namelijk voor mijn oude ogen heel vermoeiend. En er schijnen toch best veel ouderen onder de wikipedianen te zijn? Pommée (overleg) 6 apr 2022 15:04 (CEST)

Heb je een link naar het probleem? En kan het zijn dat je browser uitgezoomd is? Démarche Modi (overleg) 6 apr 2022 15:10 (CEST)

@Pommée: Los van de oorzaak, Wikipedia:Scriptbibliotheek#Lettergrootte bewerkvenster geeft een mogelijkheid om de lettergrootte zelf aan te passen  →bertux 6 apr 2022 15:36 (CEST)

@Démarche Modi: Nee, browser staat 'gewoon' op control nul. Het externe aanzicht was namelijk niet veranderd, alleen binnenin het bewerkingsvenster.

@Bertux: Dank voor de tip van de scriptbibliotheek. Aanpassing van lettergrootte werkt. Pommée (overleg) 6 apr 2022 15:58 (CEST)

Een link naar het probleem is wat lastig, maar het is te reproduceren door de brontekst van een willekeurige pagina te openen, of door een pagina te bewerken in de modus 'brontekst bewerken'. En het komt niet doordat Pommée's browser is uitgezoomd: ik constateerde vandaag exact hetzelfde: in het bewerkingsvenster wordt een ander letterype gebruikt, en het opvallendste daaraan is dat het kleiner is. Je kunt het ook zien in de bewerkingsgeschiedenis wanneer je daar 'geselecteerde versies vergelijken' klikt. WIKIKLAAS overleg 6 apr 2022 16:04 (CEST)

Opeens herinner ik me dat ik, bij het aanzetten van de computer vandaag, werd 'verblijd' door een nieuwe versie (99) van FireFox. Waarschijnlijk zijn zij de daders. Pommée (overleg) 6 apr 2022 16:07 (CEST)

Nou, ik ben blij dat ik iets van jouw hulpvraag heb geleerd Pommée! (1. ik ben geen geschikte helpdeskmedewerker en 2. er gaat een wereld voor me open met global.css) Brave had dit probleem overigens niet :') Démarche Modi (overleg) 6 apr 2022 16:15 (CEST)

@Démarche Modi: Tip: creëer jouw global.css beter niet op nl-wiki maar op meta. Dan werkt-ie op alle projecten van wikimedia. Zie de mijne: meta:User:Pommée/global.css. Pommée (overleg) 6 apr 2022 16:26 (CEST)

Done! https://meta.wikimedia.org/wiki/User:D%C3%A9marche_Modi/global.css Démarche Modi (overleg) 6 apr 2022 16:29 (CEST)

De boosdoener is inderdaad FireFox. Ik heb net even de test gedaan met wat andere browsers, en die geven nog het oude beeld. Sinds versie 99 gebruikt FireFox kennelijk geen Courier (-achtige letter) meer voor monospace, maar iets wat veel weg heeft van een Consolas (de 'i', 'j' en 'l' zijn de enige letters met een schreef). En die lijkt een punt kleiner, maar is (op mijn scherm) ook duidelijk scherper. WIKIKLAAS overleg 6 apr 2022 19:22 (CEST) Nu ik onderteken zie ik ook dat de tilde heel anders is: een golf met een twee keer zo grote amplitude als ik gewend was)

Als ik in FF 99 LM achtereenvolgens klik op Edit – Settings – Fonts and Colours (onder Language and Appearance) – Advanced, dan verschijnt een submenu/kader met de titel Fonts. Daar staat bij mij nu als Monospace-verstekwaarde DejaVu Sans Mono, maar dat is desgewenst te vervangen door een ander lettertype en/of een andere lettergrootte. Ook een algemene minimumlettergrootte opgeven is mogelijk. Verder kun je de optie Allow pages to choose their own fonts, instead of your selections above uitvinken. Mozilla's helppagina hierover staat hier. Wutsje 6 apr 2022 20:45 (CEST)

Bij mij begint het rijtje met Tools – Settings enzovoort. En daar stond inderdaad ineens 'Consolas' waar voorheen 'Courier New' moet hebben gestaan. Dus als Pommée terug wil naar de vertrouwde omgeving, dan weet hij nu wat hij kan doen. WIKIKLAAS overleg 6 apr 2022 21:05 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Opgelost! Met grote dank aan Wutsje en Wikiklaas. Ik moest in mijn Nederlandstalige FF-menu ff zoeken, maar sta nu terug op Courier New. Fontgrootte in global.css weer op de standaardwaarde 13pt gezet en het bewerkingsvenster (alsmede de verschillenlijst bij 'Wijzigingen bekijken') is/zijn weer als vanouds. Pommée (overleg) 6 apr 2022 23:32 (CEST)

Ik verbaas me er regelmatig over hoe goed de Helpdesk werkt in gevallen als deze. Fijn dat we er met vereende krachten binnen een dag uit zijn gekomen, en mooi dat je dat nog even als feedback gaf. WIKIKLAAS overleg 7 apr 2022 02:31 (CEST)

Subjectieve reisgidsteksten

In 2008 heeft een gebruiker op verschillende plaatsen subjectieve reisteksten ('impressies' zoals hier) toegevoegd. Zouden jullie kunnen meehelpen om deze bijdragen na te lopen? Encycloon (overleg) 7 apr 2022 23:07 (CEST)

Het aantal is te overzien dus ik zet ze hier even neer. Als iedereen er een paar aanpakt zijn we er zo! Gebruik  Uitgevoerd en  Mee bezig ({{d}} en {{bezig}}) →bertux 7 apr 2022 23:33 (CEST)

• wijz Gaja-et-Villedieu Impressie, bezienswaardigheden en economie van Gaja-et-Villedieu
• wijz Loupia Impressie, bezienswaardigheden en economie van Loupia
• wijz Villelongue-d'Aude →‎Externe links: Site van Villelongue d'Aude zelf toegevoegd
• wijzMalras Impressie, bezienswaardigheden en economie van Malras
• wijz gesch Pomy (Frankrijk) →‎Externe links: link toegevoegd: serie foto's van Pomy: dorp en omgeving
• wijz Pieusse →‎Impressie: tikfout
• wijz Pieusse Impressie, bezienswaardigheden en economie van Pieusse
• wijz La Digne-d'Amont Impressie, bezienswaardigheden en economie van La Digne-d'Amont
• wijz Saint-Martin-de-Villereglan Impressie, bezienswaardigheden en economie van Saint-Martin-de-Villereglan
• wijz Cournanel Impressie, bezienswaardigheden en economie van Cournanel
• wijz Castelreng Impressie, bezienswaardigheden en economie van Castelreng
• wijz Bourigeole Impressie, bezienswaardigheden en economie van Bourigeole
• wijz k Categorie:Gemeente in Aude gemeente --> gemeenten
• wijzk Bouriège →‎Externe links: omschrijving link officiële site van Bouriège gewijzigd
• wijz Bouriège Impressie, bezienswaardigheden en economie van Bouriège
• wijz La Digne-d'Aval →‎Bezienswaardigheden: tikfout
• wijz La Digne-d'Aval Officiële site van de gemeente
• wijz Saint-Couat-du-Razès →‎Externe links: tikfout
• wijz k Saint-Couat-du-Razès →‎Externe links: Officële site van de gemeente, maar laatste update uit 2003
• wijz Saint-Couat-du-Razès Impressie, bezienswaardigheden en economie van Saint-Couat-du-Razès
• wijzTourreilles Impressie, bezienswaardigheden en economie van Tourreilles
• wijz Pauligne Impressie, bezienswaardigheden en economie van Pauligne
• wijz Véraza Impressie, bezienswaardigheden en economie van Véraza
• wijz Cépie Impressie, bezienswaardigheden en economie van Cépie
• wijz Magrie →‎Economie: tikfout
• wijz Magrie →‎Externe links: titel link aangepast; toegevoegd: L'art s'invite à Magrie
• wijz Magrie Impressie, bezienswaardigheden en economie van Magrie
• wijz Festes-et-Saint-André Impressie, bezienswaardigheden en economie van Festes-et-Saint-André
• wijz Alet-les-Bains Geen bewerkingssamenvatting
• wijz La Bezole Impressie en bezienswaardigheden van La Bezole
• wijz La Bezole Impressie en bezienswaardigheden van La Bezole
• wijz k Ajac →‎Externe links: tikfout: gemeentehuisn --> gemeentehuis
• wijz Pomy (Frankrijk) volgorde gewijzigd
• wijz Pomy (Frankrijk) Geen bewerkingssamenvatting
• wijz Pomy (Frankrijk) Impressie, bezienswaardigheden en economie van Pomy
• wijz Ajac impressie, bezienswaardigheden en economie van Ajac
• wijz Villelongue-d'Aude Geen bewerkingssamenvatting
• wijz Limoux (gemeente) →‎Externe links: naar een collectie foto's van Limoux

Bovenstaande artikeltjes zijn inmiddels allemaal aan de beurt geweest. Wutsje 8 apr 2022 01:26 (CEST)

Fijn! Encycloon (overleg) 8 apr 2022 07:33 (CEST)

Witregel op beoordelingslijsten

Weet iemand waarom op de beoordelingslijsten opeens onder ieder kopje een witregel staat (vb.)? En is daar wat aan te doen (in het algemeen of in de eigen common.css)? Achtergrond: zelf vind ik het niet mooi en ik heb de pest aan overbodig skrollen. Wutsje 8 apr 2022 00:49 (CEST)

Het enige dat ik op dit tijdstip kan aandragen en je hopelijk verder help: op mijn kladblok krijg ik niet die witregel te zien, maar op de pagina Wikipedia:Te beoordelen pagina's/Toegevoegd 20220406 zie ik de witregels wel. Ik vermoed daarom de common.css, maar daar heb ik verder helaas geen verstand van. Démarche Modi (overleg) 8 apr 2022 01:45 (CEST)

En in de voorbeeldweergave zie ik die witregel ook niet... Démarche Modi (overleg) 8 apr 2022 01:57 (CEST)

Ik heb er evenmin verstand van, maar MediaWiki:Common.css is vier dagen geleden voor het laatst gewijzigd (link) en die witregel was er bij mijn weten (eer)gisteren nog niet. Dat die regel in de voorbeeldweergave niet wordt getoond viel me ook al op. Wutsje 8 apr 2022 02:04 (CEST)

Het viel me ook net op. Naar mijn snelle analyse, lijkt het bij de afdeling DiscussionTools te liggen. Deze voegt (indien je "Overleghulpmiddelen" in je voorkeuren hebt ingeschakeld) [edit: dat was wat te snel geconcludeerd] wat onzichtbare elementen aan discussiepagina's toe om de functionaliteit te ondersteunen. Tussen het kopje en de tbp-links wordt zodoende een <span data-mw-comment-start="" id="..."></span> ingevoegd, ik vermoed i.v.m. het in de ogen van DiscussionTools wellicht ongebruikelijke div-element (de tbp-links). Dat is al lange tijd zo, maar de crux zit 'm in de recent toegevoegde css-regel span[data-mw-comment-start], span[data-mw-comment-end] { display: inline-block; } (die ontbreekt in de styling van een discussiepagina die ik al een tijdje heb openstaan; WikiMedia-versie 1.39.0-wmf.5). Blijkbaar is een leeg inline-element voor een div onzichtbaar, maar zorgt een leeg inline-block-element voor een div voor die witruimte. Even met het ontwikkelteam sparren of zij dit kunnen oplossen, of dat er een eenvoudige fix hier mogelijk is, lijkt me. Met vriendelijke groeten — Mar(c). ^[overleg] 8 apr 2022 08:14 (CEST)

Hm... de releasenotes van 1.39.0-wmf.6 meldt expliciet "Make comment markers inline-block to fix comment wrapping in Safari". Ik heb op de daar genoemde phab:T298371 een melding gemaakt. — Mar(c). ^[overleg] 8 apr 2022 08:49 (CEST)

De Bètafunctie Overleghulpmiddelen maken bij mij geen verschil voor de betreffende witregel. Niet in Chrome/Brave en Safari. Verder gekeken naar gebruikersinstellingen, geen verschil. Voorts, een niet ingelogde gebruiker (getest in Safari) ziet de witregels wel in de namespace Wikipedia hier en niet in de namespace Gebruiker hier. In andere spaces heb ik het niet geprobeerd. Wel heb ik nog even gekeken naar het gedrag van Sjabloon:Tbp-links en de witregel lijkt inderdaad wel daaraan gerelateerd te zijn, zie hier. Mijn indruk is daarom dat het euvel in de combinatie sjabloon - namespace - gezocht moet worden. Démarche Modi (overleg) 8 apr 2022 10:37 (CEST)_{Nabrander; of wellicht de combinatie sjabloon+namespace - standaard .css instellingen.}

Ik had het niet gecheckt met "Overleghulpmiddelen" uitgeschakeld, maar het lukt me nu niet eens om het uit te schakelen (d.w.z. ik blijf de reageerfunctionaliteit krijgen). De Gebruiker-naamruimte is geen discussieruimte, dus daar is DiscussionTools sowieso niet actief.

Hoe dan ook, het blijft een issue veroorzaakt door de beschreven verandering in css (die de hulpelementen veranderde van "inline" naar "inline-block"). Op de phabricator-ticket is ook al een andere issue gemeld die van dezelfde css-wijziging afkomstig is.

Met vriendelijke groeten — Mar(c). ^[overleg] 8 apr 2022 11:11 (CEST)

@Mar(c): Overleghulpmiddelen kun je uitschakelen in je Globale Voorkeuren  →bertux 8 apr 2022 11:26 (CEST)

Dat weet ik; ik heb het via de Globale geprobeerd, via de gewone voorkeuren (met "lokale uitzondering"), en met dtenable=0 in de url. Allemaal tevergeefs. Ik zie nu dat met die laatste mogelijkheid wel de reageerfunctie verdwijnt, maar DiscussionTools blijft wel de hulp-spans invoegen (het zou kunnen dat het samenhangt met de hele bètafunctie-opzet met A/B-tests e.d., dat bètafuncties hoe dan ook deels actief zijn, onafhankelijk van voorkeurinstellingen), en de issue verdwijnt er dus ook niet mee. Check this: WP:TBP/Toegevoegd 20220406?dtenable=0 – geen reageerlinks, wel de gewraakte ruimte onder de koppen. Met vriendelijke groeten — Mar(c). ^[overleg] 8 apr 2022 11:56 (CEST)

@Verdel, m.b.t. deze quickfix: hou je phab:T298371 en phab:T305721 in de gaten? Trouwens, om het voor nu ook in de voorvertoning goed te krijgen, kan #wikiPreview .tbp-links { margin-top: -0.35em; } aan de quickfix toegevoegd worden. Met vriendelijke groeten — Mar(c). ^[overleg] 9 apr 2022 09:42 (CEST)

Toch anders gedaan, zie de bewerkingsgeschiedenis van Sjabloon:Tbp-links/styles.css. Hiermee zou het in alle gevallen (ook in de voorvertoning) goed moeten gaan. Zodra phab:T305721 gefixt en live is kan de quickfix teruggedraaid worden. — Mar(c). ^[overleg] 9 apr 2022 14:58 (CEST)

@Mar(c): Ik merkte die plotselinge witregel al op, vandaar mijn bewerking. Maar bedankt voor jouw aanpassing! Verdel (overleg) 12 apr 2022 10:15 (CEST)

Ja helemaal prima! Zodra er allemaal overlap geconstateerd wordt op de TBP-dagpagina's, betekent het dat ze de issue opgelost hebben en kan de quickfix verwijderd worden; dan zou alles weer als voorheen moeten zijn. Met vriendelijke groeten — Mar(c). ^[overleg] 12 apr 2022 10:22 (CEST)

Buslijn 39 (Gent)

In Buslijn 39 (Gent) staat broncode onder het kopje Traject dat er niet thuishoort. Ik weet niet hoe dat weggehaald kan worden, dus aan iemand anders de vraag er even naar te kijken. — Chescargot ツ (overleg) 9 apr 2022 07:30 (CEST)

Ik heb het even vergeleken met Buslijn 38 (Gent). zo zou het moeten kloppen. Mvg, Ennomien (overleg) 9 apr 2022 09:55 (CEST)

Terugkeer Puberruil

Vanwege de effectiviteit van de Helpdesk maar even hier, hoe zit het precies met dit programma? Volgens onze infobox is het negen jaar niet op tv geweest, maar volgens de media 4 jaar. Hier een concrete verwijzing daarnaar: "Puberruil stopte in 2018 na negentien seizoenen.". Al dacht ik een paar dagen terug ergens gelezen te hebben dat er in die negen jaar andere programma's met dezelfde opzet op tv zijn geweest, maar niet Puberruil zelf. Kan iemand dit raadsel oplossen? Groet, Ennomien (overleg) 9 apr 2022 15:09 (CEST)

Zo te zien op de lijst van afleveringen zat er tussen 2013 een gat van drie jaar; in december 2013 was voorlopig de laatste aflevering, in april 2016 ging het weer verder. Sietske | _Reageren? 9 apr 2022 15:22 (CEST)

En in 2014 startte "Puberruil Zapp". Zo te zien was dat voor een jongere doelgroep. Sietske | _Reageren? 9 apr 2022 15:24 (CEST)

Erg bedankt! Afgehandeld. Ennomien (overleg) 9 apr 2022 17:45 (CEST)

Gedachten, Vragen en Wikidata

Beste Wikipedianen,

In afwachting van de implementatie van mooi weer schrijf ik jullie dit bericht. Onlangs ben ik gewezen op het bestaan van WikiData en er ging een wereld voor mij open. Het is mooi om te zien hoe groot en breed Wikipedia geworden is, ik vind het erg knap wat er gerealiseerd is. Na het kleine beetje aan ervaring dat ik tot op heden heb opgedaan kan ik niet anders dan concluderen dat alles wat Wikipedia betreft te groot en te veel is voor een individu om volledig te doorgronden. Oftewel een compliment voor iedereen die eraan bijgedragen heeft; van de wiki software-bouwers tot de anonieme artikel redacteuren.

Echter, ik zie ook ruimte voor verbetering, risico's, communicatieve uitdagingen en wellicht een iets te vage stip op de spreekwoordelijke horizon. Als voorbeeld noem ik inwoneraantallen (waardoor ik op Wikidata terecht kwam). De huidige aanpak is tweeledig, twee sjablonen met twee verschillende soorten bron data (sjabloon array of Wikidata). Er zijn voordelen en nadelen voor beide oplossingen, het eerste is eenvoudig maar minder bestendig (en heeft actuelere data), WikiData is moeilijker maar robuuster (en is minder actueel).

Nu zal ik jullie niet vermoeien met ál mijn gedachten en proberen een aantal concrete vragen te stellen.

1. Wat heeft binnen wiki-nl de voorkeur? Data vanuit Wikidata of vanaf de nl-wiki server?
2. Wie zijn er actief met / in Wikidata vanuit wiki-nl? (ik laat de overige vragen wat dit onderwerp betreft nu links liggen)
3. Wie zijn binnen wiki-nl de collega's die werken aan geautomatiseerde data generatie? (dus ook alleen binnen wiki-nl of WikiMedia)
4. Zijn er (licentie) beperkingen van informatie die wel op wiki-nl mag staan maar niet in de (Amerikaanse) Wikidata? Wie heeft hier verstand van?

Mochten mijn gedachten en vragen raar overkomen, dan verneem ik dat ook graag. Wellicht zie ik het wel helemaal verkeerd...

Groet, Démarche Modi (overleg) 9 apr 2022 20:10 (CEST)

Over vraag 2: de personen die je op Wikipedia:Wikidata-café en WP:WOW tegenkomt. Encycloon (overleg) 9 apr 2022 20:52 (CEST)

Wat betreft vraag 1, mijn observatie is dat de consensus is dat gebruikmaken van WikiData niet de voorkeur heeft (prachtzin dit ;)). Desalniettemin wordt er verspreid over de encyclopedie gebruikgemaakt van data van WikiData. Ik ben zelf redelijk actief op WikiData, als antwoordd op vraag 2. Mocht je leuke ideeën hebben - en steun van de gemeenschap - dan help ik graag. Wat betreft vraag 4, volgens mij zijn daar eigenlijk geen beperkingen op. Misschien is dit onderwerp overigens geschikter voor de Kroeg in plaats van de Helpdesk? :) Dajasj (overleg) 9 apr 2022 21:14 (CEST)

Dank u beide! En Krinkle dank voor de correctie. Ik zal mijn gedachten en vragen omtrent Wikidata aldaar voortzetten...

Wat betreft 3, blijf ik benieuwd (dus data generatie vanuit externe bronnen, bijvoorbeeld CBS Open Data) Wellicht duik ik er later mee de kroeg in. :) Démarche Modi (overleg) 9 apr 2022 21:55 (CEST)

Ik ben momenteel vooral bezig met uploaden van Kiesraaddata, dus ik denk dat ik voldoe aan je omschrijving? Als je er aan wilt beginnen, is Open Refine iets om naar te kijken :) Dajasj (overleg) 9 apr 2022 21:58 (CEST)

Als je met data-generatie bedoelt het toevoegen van data aan Wikidata, ik ben niet in staat zelf data te verzinnen, ik ben van plan inwonerdata van Nederlandse plaatsen en gemeentes aan Wikidata toe te voegen om vervolgens via een sjabloon iedere gemeentepagina te voorzien van een tabelletje met alle plaatsen en zo. Staat al een tijdje op mijn kladblok, maar ik zie misschien de mogelijkheid om volgende week voorzichtig te beginnen. Mvg, Ennomien (overleg) 10 apr 2022 14:20 (CEST)

Wilde je daar dan gebruikmaken van het sjabloon:inwonertal? Wikiwerner (overleg) 10 apr 2022 15:24 (CEST)

Ik denk dat een bepaalde invoer van dat sjabloon precies zou doen wat ik anders zelf zou schrijven. In dat geval: ja. Ennomien (overleg) 10 apr 2022 16:30 (CEST)

Ennomien dat lijkt een beetje op wat ik tot nu toe samengesteld heb. Ik heb nu een tabel per gemeente met inwonertallen tot feb-22, per maand selecteerbaar. Wellicht is het volgende ten overvloede, maar ik deel het graag me je en wens geen gras voor je voeten weg te maaien. De tabel 'WijkenEnBuurten' van het CBS (in pandas python: pd.DataFrame(cbsodata.get_meta('83765NED', 'WijkenEnBuurten')) geeft je de indeling van gemeenten en plaatsen. De populatie gegevens zijn te dowloaden via pd.DataFrame(cbsodata.get_data('37230NED'), daar zit veel data in, dus een selectie is wellicht wenselijk. Ik gebruik nu (pd.DataFrame(cbsodata.get_data('37230NED', select=["RegioS","Perioden","BevolkingAanHetEindeVanDePeriode_15"]). Echter heb ik niet de volledigheid van alle inwonertallen in deze tabel gecontroleerd, maar met 160343 regels ziet het er gedetailleerd uit. Tot slot kan je ook een indeling van de gemeenten per provincie maken via de provinciecode in tabel 'https://www.cbs.nl/-/media/cbs/onze-diensten/methoden/classificaties/overig/gemeenten-alfabetisch-2022.xlsx'. Ook in pandas te laden. Indien gewenst kan ik mijn code met je delen via email en desgewenst samenwerken. Ik heb het nog niet in Github staan, maar hoop dat snel voor elkaar te maken... over een weekje vermoed ik. (ik hoop er even tussenuit te gaan de komende dagen, een nodige mini wiki break ;)) Démarche Modi (overleg) 10 apr 2022 18:58 (CEST)

Dat is al een mooi begin! Ik denk vooral dat het even wat uitzoeken wordt hoe we de data in Wikidata kunnen krijgen. Dat zou ideaal zijn, iedere wiki die een beetje moeite steekt in hun sjablonen heeft heel actuele informatie van onze inwoneraantallen. Dat vergt wel even wat organisatie. Ook moet er een koppeling gemaakt worden tussen woonplaats en gemeente, zodat een te maken sjabloon "weet" welke plaats bij welke gemeente hoort. Ennomien (overleg) 10 apr 2022 19:31 (CEST)

Ook dat laatste kan met Wikidata. {{#invoke:Wd|properties|raw|Q101918|P1383}} geeft voor mijn Apeldoorn: "Q1627397, Q171214, Q171215, Q1867889, Q1915779, Q1992756, Q2105254, Q2229163, Q2328114, Q237300, Q2406582, Q2434331, Q2510245, Q2692088, Q2696030, Q2893671, Q2893675, Q3145711, Q3912302, Q3929695, Q58425, Q3018561, Q1025689, Q1737267, Q2548107". In het gemeentelemma zelf kun je Q101918 weglaten. De resulterende string met Q-nummers moet dan nog gesplitst worden; dat kan misschien met de Module:String. De Q-nummers kun je vervolgens (hopelijk) een voor een invoeren in het sjabloon:inwonertal. Wikiwerner (overleg) 10 apr 2022 21:43 (CEST)

Mooi Werner! Erg interessant wat er met de wd templates kan. En dank dat je me zo'n module laat zien... :)

Een paar gedachten hierbij, helaas zonder dat ik een oplossing kan aanreiken... In pseudo achtige code zou je dan zoiets doen als:

| FOR item LIST: (loop alle items af, dus variabele tabelgrootte, Q237300 als voorbeeld)

-> {invokeWD | *template om naam plaats te halen* | Q237300} <-- nederlands label is niet per se nederlandse artikel naam (bijvoorbeeld Engeland (Q237300 wikidata) en Engeland (Apeldoorn) (wikipedia)

-> {inwonertal|Q237300} of {#invoke:Wd|properties|raw|Q237300|P1082} (alleen inwonertal)

-> koppeling maken met (bijvoorbeeld) Engeland (Apeldoorn)

Wellicht is het ook een idee om een lege waarde, foutieve waarde en checksum (controleer totaal aantal inwoners) toe te voegen. Indien het niet klopt een waarschuwing te geven zodat het gecontroleerd kan worden.

Terwijl ik me nu afvraag of dit nog hier in de helpdesk thuis hoort schrijf ik rustig verder. Wat wellicht ook nog in de overwegingen meegenomen kan worden is of inwonertal de beste oplossing is (die gebruikt rechtstreeks de #invoke (afgeraden) en niet de #invokewd (aangeraden). Niets ten nadele van RonnieV die daar een knap stukje werk geleverd heeft!! Misschien voelt RonnieV zich wel geroepen om mee te denken. Démarche Modi (overleg) 10 apr 2022 22:51 (CEST)

Oh ja het ging mij er niet om of het kon, maar meer dat het wel allemaal moet kloppen. Dat het gedaan is met de juiste property en dat alle plaatsen in een gemeente staan. Ik begrijp namelijk dat het daarin nog wel eens fout kan gaan. Ennomien (overleg) 11 apr 2022 09:41 (CEST)

Over vraag 4: Wikidata hanteert de CC0-licentie voor de gestructureerde data, dus die mag iedereen overal gebruiken, ook buiten Wikipedia. Wikiwerner (overleg) 10 apr 2022 17:39 (CEST)

Ten eerste: inwonertallen op Wikidata zijn soms minder actueel, soms actueler, het hangt er maar net vanaf wie wanneer zin heeft om bepaalde gegevens bij te werken. Over vraag 1: we hebben bijvoorbeeld zo'n 25.000 artikelen over Franse gemeenten. Stel je wil zorgen dat al die artikelen gebruik maken van een bepaalde census, gepubliceerd door een bepaalde bron. Als je dat vanaf Wikidata wil doen, kan je van één of een paar gemeenten checken of ze de gewenste gegevens bevatten, maar hoe weet je of iemand niet halverwege is gestopt met bijwerken? Je moet dus 25.000 items controleren, en de gegevens toevoegen wanneer nodig. Of je kan gewoon de tabel downloaden van de bron, omzetten in sjabloonvorm en het statistieksjabloon updaten. –bdijkstra (overleg) 11 apr 2022 10:04 (CEST)

Ook die werkwijze heeft nadelen. Bij herindelingen ontstaan er fouten in de samengevoegde/opgeheven gemeenten; die zijn lastig op te sporen. Ik neem aan dat als iemand duizenden gemeenten bijwerkt op Wikidata, diegene dat niet handmatig doet en vervolgens halverwege stopt vanwege RSI, maar dat doet met een script dat gebruikmaakt van de gedownloade tabel, en ze dan allemaal bijwerkt. Een ander nadeel is dat andere wiki's er niks aan hebben, en dat dus elke wiki het wiel opnieuw uitvindt. Anderzijds kunnen wij gebruikmaken van het werk van de Fransen op Wikidata. Wikiwerner (overleg) 11 apr 2022 11:10 (CEST)

Mijn ervaring is dat aannames leiden tot sluimerende en moeilijk op te sporen fouten. Bij een herindeling weet je precies om welke gemeentes het gaat, hoe is dat lastig op te sporen? En en klusje van in de orde van een kwartier gelijkstellen aan de uitvinding van het wiel, lijkt me nogal overdreven. –bdijkstra (overleg) 11 apr 2022 11:27 (CEST)

En als iemand toch niet alles bijwerkt: dan staat er een ouder inwonertal dan het laatst bekende. Dat is minder erg dan het huidige systeem: daarin ontstaat een foutcode in de samengevoegde/opgeheven gemeenten na een update. Vis die er maar eens uit in een kwartier. Overigens: Wikidata heeft cijfers van 2019 en onze cijfers dateren van 2011 ... Wikiwerner (overleg) 11 apr 2022 11:40 (CEST)

En als iemand toch niet alles bijwerkt, dan zal er inderdaad een ouder inwonertal staan, wat niet heel erg is, maar mijn uitgangspunt was de intentie om alles te updaten naar een bepaalde census. Of er een zichtbare of onzichtbare foutmelding komt, en hoe gemakkelijk die is op te sporen, hangt natuurlijk af van hoe het sjabloon is opgebouwd. –bdijkstra (overleg) 11 apr 2022 11:56 (CEST)

Tja, in de lijstjes zoals Ennomien ze wil maken met een sjabloon, moeten de inwonertallen van de woonplaatsen wel van hetzelfde jaar zijn. Sowieso is Lua-code nodig, alleen al om de plaatsnamen te sorteren op alfabet. De namen krijg je door "raw" weg te laten: {{#invoke:Wd|properties|Q101918|P1383}} geeft: "Hoog Soeren, Groenendaal, Gerritsflesch, Loenen, Ugchelen, De Krim, Radio Kootwijk, Wenum-Wiesel, Hoog Buurlo, Engeland, Oosterhuizen, Nieuw-Milligen, Woeste Hoeve, Uddel, Beemte, Beekbergen, Beemte-Broekland, Hooilanden, Meerveld, Assel, De Haere, Apeldoorn, Hoenderloo, Klarenbeek, Lieren". Ik heb nog nooit Lua gebruikt, maar ik zat te denken dat we dan een Lua-tabel moeten maken met de Q-nummers als keys en de namen als waarden. Dan sorteren we de tabel op naam en lopen we de Q-nummers af: haal voor elk Q-nummer de Nederlandse titel op, samen met het inwonertal en het bijbehorende tijdstip (al dan niet weer te geven in het artikel). Als de tijdstippen verschillend zijn, dan laten we een verborgen trackingcategorie toevoegen. Kan dat überhaupt: de module:Wd aanroepen vanuit een andere module? Wikiwerner (overleg) 11 apr 2022 13:48 (CEST)

Niet alleen het inwonertal en het tijdstip ophalen, maar ook de methode van vaststelling (P459) (want je wil neem ik aan geen schattingen meenemen), de bron (want je wil neem ik aan een tabel maken met gegevens uit dezelfde bron) en eventueel ook het gebruikt criterium (P1013). –bdijkstra (overleg) 11 apr 2022 14:02 (CEST)

Raadsel

Op deze pagina Gebruiker:VanBuren/Kladblok1 zie ik de bovenste verzameling als twee kolommen. In de onderste verzameling staat de tweede kolom onder de eerste. Wat gebeurt daar? VanBuren (overleg) 11 apr 2022 14:20 (CEST)

Het kritieke verschil is dat je eerste tabel keurig uit twee tabelcellen bestaat, maar je tweede tabel slechts uit eentje, er ontbreekt namelijk een |. –bdijkstra (overleg) 11 apr 2022 14:25 (CEST)

Pfffff, ik heb er op uren naar zitten turen en niet gezien. Dat is zorgelijk. Dank voor je heldere blik :). VanBuren (overleg) 11 apr 2022 16:13 (CEST)