Infobox Noorse gemeentenBewerken

Moi Bdijkstra, waar kan ik vinden of er al een bestand is aangemaakt van een nieuwe Noorse provincie, van Troms og Finnmark was die er al wel en ik ging er een beetje blind van uit dat er dan voor alle nieuwe provincies al een bestand was gemaakt. Peter b (overleg) 29 dec 2019 23:45 (CET)

Inderdaad apart dat dit blijkbaar (nog) niet helemaal gedaan is. De huidige kaartjes staan in c:Category:Locator maps of counties of Norway. Een positiekaart van Agder bestaat wel, nl. in c:Category:SVG locator maps of counties in Norway (location map scheme), maar dat is in een andere stijl. Als je die wil gebruiken moet je (vind ik) alles in die stijl doen, inclusief de gemeentelocatiekaartjes. –bdijkstra (overleg) 29 dec 2019 23:55 (CET)
De combinatie van twee verschillende kaartsoorten is idd geen mooi gezicht. Vooralsnog laat ik daarom dit maar even rusten. Als jij merkt dat de kaarten zijn aangepast, in de zin dat gemeente en provincie in dezelfde opmaak beschikbaar zijn, geef me dan even een seintje. Peter b (overleg) 1 jan 2020 15:18 (CET)

Jubileumster 15 jaarBewerken

Dik verdiend en collegiale groeten, Klaas `Z4␟` V:  1 jan 2020 10:45 (CET)
Dankje! –bdijkstra (overleg) 2 jan 2020 11:25 (CET)

Sjabloon:Citeer boekBewerken

Hallo Bdijkstra, vooreerst, beste wensen voor een succesvol 2020! Ik zag dat je recentelijk nog aan het sjabloon werkte. De ' '. bovenaan links, is dit een typo of bestaat daar een bepaalde reden voor? Thnks. Lotje (overleg) 2 jan 2020 07:57 (CET)

Ook jij de beste wensen! Op een sjabloonpagina voegt het sjabloon zichzelf in, zonder argumenten, en dat is dan het resultaat. Als men zich eraan stoort, is het wel te onderdrukken. –bdijkstra (overleg) 2 jan 2020 11:29 (CET)

random article uit categorieBewerken

Hoi Bdijkstra. Ik zag je op een aantal plekken links naar de randomarticletool van Erwin vervangen door een link naar Speciaal:WillekeurigeUitCategorie. Aangezien de tool stuk is is het een alternatief, maar het is zeker niet gelijkwaardig. Het leuke van randomarticle was namelijk dat hij ook subcategorieën mee neemt, je krijgt dus alleen artikelen uit de hoofdcategorie.   Akoopal overleg 2 jan 2020 22:53 (CET)

De tool is niet zozeer stuk, momenteel is het een serie HTTP-redirects van tools.wikimedia.de naar www.toolserver.org naar tools.wmflabs.org naar Speciaal:WillekeurigeUitCategorie. Dat vond ik onzinnig en daarom heb ik het gewijzigd naar een directe link. –bdijkstra (overleg) 2 jan 2020 23:06 (CET)
De oorspronkelijke tool is wel stuk helaas. Die deed meer dan de speciale pagina. Dat er blijkbaar een vervangende tool is neergezet die alleen redirects doet om links werkend te houden is ok, maar er is helaas minder functionaliteit. Jouw vervangingen ben ik het mee eens hoor, maar ik hoop dat iemand ooit weer eens er brood in ziet een vervangende tool te maken, danwel dat de optie 'met subcats' in de special page komt.   Akoopal overleg 5 jan 2020 12:27 (CET)

Vriendelijk dankBewerken

Geachte Bdijkstra,


Vriendelijk dank voor de uitleg in verband met het toevoegen van de landkaart.


Oprechte groeten.

IDD5000 (overleg) 6 jan 2020 21:41 (CET)


Geachte Bdijkstra,

Heel hartelijk bedankt voor het terugzetten van mijn kladblok! Ik heb geleerd dat de actie die ik ondernam niet de juiste is. Het fijne aan de wikipedia-gemeenschap is dat er mensen zijn zoals u!

Hartelijke groet, Ridderspoor (overleg) 30 mrt 2020 15:00 (CEST)

Fijn om te horen! Het het hernoemen van het kladblok was niet per se fout, hoewel velen prefereren dat er nieuwe pagina wordt aangemaakt. Na hernoeming vind ik dat de pagina verwijderd moet worden, zodat er weer met een schone lei (een lege paginageschiedenis) begonnen kan worden. –bdijkstra (overleg) 30 mrt 2020 15:17 (CEST)

LeetBewerken

Ik zie dat je mijn wijziging op de 1337 pagina hebt ongedaan gemaakt omdat je het kennelijk niet begrijpt. Laat mij het uitleggen. In leetspeak kan de L voorgesteld worden door 1 of 7, de T alleen door 7 niet door 1. Dit staat in de tabel op de pagina. In het woord 1337 staat de 1 voor L en dus de 7 voor T anders staat er leel. Het voorbeeld oliebol is in dit opzicht verwarrend, want daarin staat de 7 wel voor L. De L in 1337 staat dus links, de T rechts. Tik je dit in op je rekenmachine en draai je die om dan komt de L rechts en de T links. Daarom moet je 1337 achterstevoren intikken als 7331 – De voorgaande bijdrage werd geplaatst door 2001:980:3669:1:876:54c2:cc3b:4895 (overleg · bijdragen)

Je kan uitleggen wat je wil, maar als ik op mijn rekenmachine 7331 intik en omkeer staat er IEE'L. Met 1337 kom je een beetje in de buurt met LEE'I, maar dit is geen leetspeak, dit is rekenmachine-orthografie; dat zijn verschillende dingen. Dus eigenlijk moet de hele intro aangepast worden. –bdijkstra (overleg) 9 jan 2020 15:18 (CET)
Prima, pas de hele intro maar aan. Maar zolang die oliebol intro er nog is is mijn correctie geldig.
Dat aanpassen van het intro lijkt me sowieso wel nodig, want rekenmachines en LEET hebben geen enkele overlap, en daar ga je ook geen bron voor vinden. Edoderoo (overleg) 9 jan 2020 15:53 (CET)

bewerkenBewerken

ik zag dat u mijn overlegpagina bewerkte waarom ? je wil waarschijnlijk gewoon helpen maar ik heb het niet graag als iemand die ik niet ken onaangekondigd mijn overlegpagina bewerkt alvast bedankt voor het begrip.Bibnieuws 16 jan 2020 19:39 (CEST)

Sorry. Ik wilde inderdaad gewoon helpen. Ik had het even moeten vragen van tevoren. –bdijkstra (overleg) 17 jan 2020 09:15 (CET)

Archief TaalcaféBewerken

Dag Bdijkstra, zou jij eens willen kijken of je deze edit zo zou willen aanpassen dat het eerste archief van 2020 er ook op komt te staan? Alvast hartelijke dank! Groet, Vinvlugt (overleg) 20 jan 2020 15:00 (CET)

  Uitgevoerd Ik hoop dat je nu het patroon ziet voor de nodige wijziging in 2030. ;) –bdijkstra (overleg) 20 jan 2020 15:04 (CET)
Ga ik onthouden! 😉 Vinvlugt (overleg) 20 jan 2020 15:10 (CET)

HusselenBewerken

Anders blijft-ie husselen schreef je. Maar dat doet hij nog steeds. Edoderoo (overleg) 18 feb 2020 06:35 (CET)

Na het aanpassen van de query moet het vaak nog een laatste keer op volgorde worden gezet. –bdijkstra (overleg) 18 feb 2020 07:48 (CET)
Dat dacht ik ook, maar hier lijkt dat toch nog niet het geval. Wel husselt-ie misschien wat minder vaak, eerder was dat om de dag. Edoderoo (overleg) 20 feb 2020 06:32 (CET)
Ik moest iets verder zoeken ;-) Hier verklaart het fenomeen zich. Edoderoo (overleg) 20 feb 2020 07:19 (CET)

WikiLove-implementatieBewerken

Dag Bdijkstra, zou jij als interfacemoderator dit script ('extensie' zal wel een verkeerd woord zijn) aan de Nederlandstalige Wikipedia kunnen toevoegen? Mvg, Encycloon (overleg) 8 mrt 2020 20:46 (CET)

Aangezien ik daar geen link zie naar een script wat is toegespitst op deze wiki ga ik er vanuit dat je het verkeerd hebt begrepen. Zoals ik het begrijp is mw:MediaWiki:WikiLove.js slechts een voorbeeld. Op mw:Extension:WikiLove#Custom configuration lees ik dat verschillende wiki's een script met die naam hebben gemaakt om de WikiLove-extensie naar hun wensen te configureren. –bdijkstra (overleg) 8 mrt 2020 21:27 (CET)
Zou best kunnen dat ik het verkeerd begrepen heb (al had ik zelf ook niet het idee dat mw:MediaWiki:WikiLove.js letterlijk gekopieerd moest worden.) Wat moet er volgens jou gebeuren om aan A configuration file exists on the local wiki (MediaWiki:WikiLove.js) te voldoen? Encycloon (overleg) 8 mrt 2020 21:42 (CET)
Het lijkt de bedoeling dat de gemeenschap de standaardconfiguratie beoordeelt en dat vervolgens een reeks uit te delen aardigheden gedefinieerd wordt, die in het script gecodeerd wordt. Maar het minimum om aan de genoemde voorwaarde te voldoen is:
//Zie http://www.mediawiki.org/wiki/Extension:WikiLove voor documentatie over configuratie.
//<nowiki>

//</nowiki>
bdijkstra (overleg) 9 mrt 2020 15:32 (CET)
Oké. Het lijkt me dan het handigst om eerst die basis te leggen en als de functie eenmaal bestaat een soort meldpagina aan te maken voor de finetuning; ik zie zelf geen controversiële zaken om nu al te moeten aanpassen (misschien de geiten weghalen).
Denk je trouwens dat de techneuten makkelijk een duimpje o.i.d. kunnen toevoegen in plaats van het hartje? Encycloon (overleg) 9 mrt 2020 18:12 (CET)
Geiten weghalen kan met delete $.wikiLoveOptions.types.goat;. Welk hartje bedoel je? –bdijkstra (overleg) 9 mrt 2020 18:19 (CET)
Javascript-MediaWiki-pagina's kunnen alleen interfacemoderatoren aanmaken/bewerken toch? Verder bedoel ik het hartje bij de tabs op en:User talk:EncyKloon. (Zie de opmerking van Thieu1972, voor hem te veel 'love'-associaties.) Encycloon (overleg) 9 mrt 2020 18:49 (CET)
Ja, alleen interfacemoderatoren. Maar iedereen kan natuurlijk ergens anders een voorstelkladje neerzetten. Het hartje komt vanaf de skin, is via CSS wel te overschrijven (voor Vector: .vectorTabs #ca-wikilove.icon a:before). Moet iemand natuurlijk wel een geschikt plaatje vinden/maken. –bdijkstra (overleg) 9 mrt 2020 19:08 (CET)
Zo dus? En zou dit plaatje geschikt zijn? Encycloon (overleg) 9 mrt 2020 20:34 (CET)
Ja zo. Ik ben geen UI-designer, maar een plaatje als dat zou als basis kunnen dienen. Zie het origineel. Het moet dezelfde afmetingen hebben en op dezelfde manier twee varianten bevatten; de tweede is voor wanneer je eroverheen hangt met de muis. –bdijkstra (overleg) 9 mrt 2020 21:49 (CET)
Zou ik dat voorstelkladje nog even moeten laten beoordelen in de Kroeg?
Verdere aanpassing van dat plaatje is voor mij te hoog gegrepen vrees ik. Kun je zoiets ook op Phabricator vragen of moeten we het dan voorlopig maar bij het hartje houden? Encycloon (overleg) 10 mrt 2020 10:45 (CET)
Laten beoordelen lijkt me niet nodig. In de loop der tijd gaan er denk ik toch wel discussies ontstaan over mogelijke aanpassingen. En in de handleiding hebben ze het ook over een hartje, dus beter zo laten lijkt me. –bdijkstra (overleg) 10 mrt 2020 10:53 (CET)
Prima. Kun je de MediaWiki-pagina aanmaken zodat ik de aanvraag kan doen?
(@Thieu1972: het blijft dus toch het hartje, tenzij jij er veel zin in hebt handleidingen en dergelijke aan te passen.) Encycloon (overleg) 10 mrt 2020 10:59 (CET)
Ach, ik overleef het wel :-) Thieu1972 (overleg) 10 mrt 2020 11:03 (CET)
  Uitgevoerd MediaWiki:WikiLove.js aangemaakt. –bdijkstra (overleg) 10 mrt 2020 11:12 (CET)
Bedankt. Encycloon (overleg) 10 mrt 2020 11:32 (CET)

MisnestedBewerken

Deze edit zal vast nodig zijn, maar ik zie niet helemaal in waarom. Je voegt een niet bestaand sjabloon in, en voor een leek is het resultaat nul. Maar ik wordt er wel nieuwsgierig van. Edoderoo (overleg) 9 mrt 2020 10:26 (CET)

Ik voegde geen niet-bestaand sjabloon in, maar een magisch woord net als DEFAULTSORT. Kijk voor het waarom maar eens in de code van Sjabloon:Infobox sporter/medailles. Daar wordt {{{medals}}} in een tabel gedaan; als je dan niet zorgt dat er een tabelcel komt zoals de op dit punt gebruikelijke sjablonen doen (kijk maar eens hoe de medailles bij Inge de Bruijn zijn ingevuld), dan krijg je lint-fouten (en potentieel opmaakproblemen). Geen idee waarom dit sjabloon zo is opgezet, het is vragen om problemen. –bdijkstra (overleg) 9 mrt 2020 10:37 (CET)
Hehe, ja, nu begin ik het te snappen. Deze opzet vereist een kromme opmaak *in* de infobox, dat is inderdaad niet lekker opgezet. Eigenlijk is jouw toegevoegde sjabloon ook een beetje symptoombestrijding (niet bedoeld als verwijt, maar als constatering). Maar dat allemaal analyseren op oplossen is ook weer een heel project op zich. Edoderoo (overleg) 9 mrt 2020 11:11 (CET)
Ik probeer mijn lijst met lint-fouten een beetje overzichtelijk te houden, dus zo nu en dan vindt er inderdaad symptoombestrijding plaats. Projecten genoeg, en sportartikelen hebben niet mijn prioriteit. –bdijkstra (overleg) 9 mrt 2020 11:23 (CET)
Als ik er in april weer eens aan denk, zal ik er eens induiken. Deze zomer zijn er weer Olympische Spelen, dus gegarandeerd nieuwe artikelen met nieuwe medailles. Als we het voor die tijd weten te fixen, scheelt dat jou weer een lijstje met symptomen. Edoderoo (overleg) 9 mrt 2020 11:59 (CET)

De hulpvaardigheidssterBewerken

  De hulpvaardigheidsster
Beste bdijkstra, dank voor je hulp, geduld en alle uitleg in het botcafé! Ik waardeer dat echt heel erg, vandaar voor jou deze hulpvaardigheidsster! Nogmaals dank en vast tot een volgende ontmoeting! Rozemarijn vL (overleg) 11 mrt 2020 20:39 (CET)

Hoezo?Bewerken

Hoi, wat is hier de bedoeling van? Een pagina die als bedoelt uitzag, ziet nu als niet bedoelt uit. Sb008 (overleg) 12 mrt 2020 10:00 (CET)

Excuses, gecorrigeerd. De bedoeling is om Lintfouten te corrigeren, zo mogelijk met behoud van de (waarschijnlijke) bedoeling van de auteur. –bdijkstra (overleg) 12 mrt 2020 10:13 (CET)
En wat is de Lintfout? Je verwijdert het "small" template dat je nota bene zelf hebt gecreeerd. En waarom kunnen "nowrap" en "small" niet genest worden? Sb008 (overleg) 12 mrt 2020 10:20 (CET)
De Lintfout die ik daar corrigeerde is div-span-flip. Vaak werd <small> gebruikt als blokelement (met meerregelige tekst), terwijl het een inline-element is; dat veroorzaakte de Lintfout misnested-tag (elementen die elkaar niet compleet insluiten). Ik heb {{small}} gecreëerd om ook meerregelige tekst gemakkelijk kleiner te kunnen maken zonder Lintfouten te introduceren. Maar {{nowrap}} is een inline-element; als je een blokelement nest binnen een inline-element dan kan je div-span-flip krijgen. Andersom, d.w.z. met {{nowrap}} binnen <small> of {{small}} is er geen enkel probleem. –bdijkstra (overleg) 12 mrt 2020 10:42 (CET)
Dus e.g. {{small|{{nowrap|21 mrt}}}} is geen probleem? Sb008 (overleg) 12 mrt 2020 10:52 (CET)
Inderdaad. Het produceert correcte HTML-code en het geeft geen Lintfouten. Net als <small>21&nbsp;mrt</small>. –bdijkstra (overleg) 12 mrt 2020 11:00 (CET)
Dat laatste was me meteen duidelijk, voor de rest thx. Sb008 (overleg) 12 mrt 2020 11:04 (CET)

CursiefBewerken

Dag, Bdijkstra, ik zag net deze bewerking van je. Tot mijn verbazing levert ook dit een pagina met een cursieve titel op. Is dat nieuw? En is het te verkiezen boven de bekende methode, waarbij de titel tussen de gebruikelijke dubbele aanhalingstekens achter "titelweergave=" wordt gezet? 77.164.133.132 17 mrt 2020 19:14 (CET)

Nieuw sinds een jaar ongeveer. Bij geslachten komt het regelmatig voor dat er haakjes achter de titel komen en bij soorten komt het wel eens voor dat ze in een ander geslacht worden ingedeeld. Vaak wordt dan nagelaten om de titelweergave aan te passen en komt zo'n artikel in de categorie:Wikipedia:Pagina's met genegeerde titelweergaven terecht. Dus ik zou zeggen dat het te verkiezen is, zolang er geen "subsp." of andere complicerende factor is. –bdijkstra (overleg) 17 mrt 2020 21:14 (CET)

En eenzelfde vraag over je vervanging van "commons=Category:" door "commonscat=". In de brontekst van het sjabloon taxobox kom ik nergens de parameter commonscat tegen, dus hoe komt het dan in godsnaam dat dit een zinvol resultaat oplevert? Overigens exact hetzelfde resultaat als met de vervangen constructie. 77.164.133.132 17 mrt 2020 20:24 (CET)

Verrek inderdaad. Ik zou toch zweren dat ik het iemand anders heb zien doen, maar waarschijnlijk was dat een ander sjabloon. Als de parameter niet is ingevuld worden gegevens van Wikidata gebruikt, dus vandaar meestal toch een zinvol resultaat. Er zijn er 36 met deze fout, zal ik morgen oplossen. –bdijkstra (overleg) 17 mrt 2020 21:14 (CET)
Helder. Dank voor je toelichting. 77.164.133.132 17 mrt 2020 21:30 (CET)

TerugdraaiingBewerken

Hallo,

Ik zag dat je mijn bewerking terug had gedraaid op een sjabloon. Sjablonen zijn nou niet echt mijn expertise dus ik heb geen idee hoe ik de sjabloonaanroepen moet aanpassen. Groet «BKannen» 21 mrt 2020 13:45 (CET)

Vraag 1 is of peri- en apoapsis ook echt fout zijn, of dat peri- en apofocus simpelweg geprefereerde termen zijn. –bdijkstra (overleg) 21 mrt 2020 16:07 (CET)
Je bedoelt het denk ik omgekeerd. Peri- en apofocus zijn niet per se verkeerd maar het is qua uniformiteit denk ik te prefereren om overal dezelfde term te gebruiken, om verwarring te voorkomen. Nu staat er bvb in infoboxen periapsis en perifocus door elkaar, onwenselijk lijkt me. In de vakliteratuur (Engels) kom je eigenlijk alleen maar de term -apsis tegen in plaats van -focus. Groet «BKannen» 21 mrt 2020 16:27 (CET)
Inderdaad, ik bedoelde het omgekeerd, ik keek per ongeluk naar m'n eigen wijziging i.p.v. de jouwe. Aangezien het dus niet verkeerd is hoeven de sjabloonparameter dus niet te worden veranderd: deze komen niet in de artikeltekst. Ik heb het sjabloon nu gewijzigd zodat in de infoboxen nu overal -apsis staat. –bdijkstra (overleg) 21 mrt 2020 16:48 (CET)

Grootbritannië en Noord-IerlandBewerken

Zo heet het echt hoor. Sinds 1927. Zie ik nu goed dat jij het veranderd had in Grootbritannië Ierland? Gerard von Hebel (overleg) 21 mrt 2020 23:43 (CET)

Excuses. Je hebt gelijk. Ik keek niet goed. Ik moet hier wel bij opmerken dat GB&I dezelfde staat is gebleven toen het werd omgedoopt in GB&NI. Eigenlijk is de voorgangerrstaat dus het Koninkrijk Grootbrittannie (1707-1801). Gerard von Hebel (overleg) 21 mrt 2020 23:50 (CET)

Toen het werd omgedoopt in 1927 bleef het inderdaad dezelfde staat, maar in 1922 was er een splitsing, en dat spreken we hier op Wikipedia over een "andere" staat. Dit mede vanwege de infobox met voorgaande en opvolgende staten. De infobox voor een huidig land heeft geen parameters voor afgesplitste staten, die van een historisch land wel. –bdijkstra (overleg) 22 mrt 2020 03:30 (CET)
OK.Dat zijn dan de eigenaardigeden van deze infoboxen. Echt onafhankelijk werden de Britse dominions (waaronder Ierland) pas in 1931 met het Statuut van Westminster. Dat was al vooronderhandeld in 1927 toen door Balfour (de minister van buitenlandse zaken met een intentieverklaring daarover kwam. Gerard von Hebel (overleg) 26 mrt 2020 22:03 (CET)

Onjuist opgegeven opties mediabestandBewerken

Beste Bdijkstra. Naar aanleiding van deze bewerkingen: In de bewerkingssamenvatting bij deze bewerking wordt gesteld dat het "onjuist opgegeven opties mediabestand" zou betreffen. Ik ben het met u eens dat thumb niet in een <gallery></gallery> thuishoort, maar opties als thumbtime, start en end werken wel degelijk, en voorzover ik weet ook binnen een gallery. Kunt u toelichten waarom u deze opties heeft verwijderd? Met vriendelijke groet, 它是我 (overleg) 23 mrt 2020 22:29 (CET)

Hmm, ik ging er stomweg vanuit dat geen enkele optie daar werkte. Waar is dat gedocumenteerd? –bdijkstra (overleg) 23 mrt 2020 23:34 (CET)
Ik zou het niet weten. Ik heb het via 'trial and error' uitgevonden. 它是我 (overleg) 23 mrt 2020 23:36 (CET)
Ik denk ook dat dat geen toeval of 'ongelukje' is. Soms is alleen een bepaald fragment van een fimpje relevant voor een lemma. Het is dan erg belangrijk dat ook in een gallery of sjabloon deze start en end opties blijven werken, zodat ook alleen het bewuste filmfragment wordt getoond. 它是我 (overleg) 23 mrt 2020 23:49 (CET)
Hoe dan ook, als die opties werken (en dat doen ze) dan horen ze niet weggehaald te worden. Ik zal morgen kijken of en hoe ik de gemaakte schade kan herstellen. –bdijkstra (overleg) 23 mrt 2020 23:55 (CET)
Bedankt 👍🏻. 它是我 (overleg) 23 mrt 2020 23:58 (CET)

Sjabloon:Infobox luchthavenBewerken

Waarom geef je geen antwoord? Vliegveld Paris-Charles de Gaulle is in 1974 geopend, niet opgericht. ChristiaanPR (overleg) 10 apr 2020 21:35 (CEST)

  • dag bdijkstra, Ik heb het overal ingevoerd, maar weet niet dat er boven 10 velden mogen staan. Het kan worden teruggezet voor het geval dat het op mijn manier niet gaat. groeten ChristiaanPR (overleg) 10 apr 2020 21:55 (CEST)
  • De twee termen lijken mij hetzelfde te betekenen. Zo niet, dan dient te worden uitgelegd wat het verschil is. En als een vliegveld niet wordt opgericht, dan dient die parameter uitgefaseerd te worden. Het gemakkelijkste is om de parameter te behouden en het label daarvan te veranderen. –bdijkstra (overleg) 11 apr 2020 09:33 (CEST)
    • Mij werd niks gevraagd, maar toch mijn mening: de openingsdatum lijkt mij zinvol in de infobox op te nemen. De oprichting, zoal die a bestaat, is meer een politiek/bestuurlijk trajekt dat daarmee lastiger aan een datum te koppelen valt, en mogelijk als lastiger bebrond is. Dat zou ik in de lopende tekst verwerken als dat aan de orde is. Edoderoo (overleg) 11 apr 2020 09:37 (CEST)

Verwijderen van submoduleBewerken

Bedankt voor het verwijderen van Module:Wd/aliasesP. Zou Module:WD/aliasesP ook verwijderd kunnen worden (die is een beetje nutteloos nu)? Volgende keer zal ik de andere procedure gebruiken. Alvast bedankt! Thayts (overleg) 19 apr 2020 22:23 (CEST)

Ook   Uitgevoerd. –bdijkstra (overleg) 20 apr 2020 11:30 (CEST)

HulpBewerken

Jouw hulp is nodig (al je er tijd voor en zin aan hebt) voor een aantal gevallen op Speciaal:GevraagdeCategorieën, namelijk "Pagina's die verouderde source labels gebruiken", "Pages that use a deprecated format of the math tags" en mogelijk ook "Wikipedia:Wikiproject Erfgoed". Mijn onkunde speelt me parten om dit zelf op te lossen. Wat er na de volgende update nog staat komt vanzelf aan de beurt. Alvast veel dank! VanBuren (overleg) 21 apr 2020 16:37 (CEST)

Die eerste heb ik hernoemd naar Categorie:Wikipedia:Pagina's die verouderde source-labels gebruiken, hopelijk zorgt Xqbot dat ie bij de volgende update leeg is (en dus niet verschijnt bij GevraagdeCategorieën). Die tweede was een glitch, opgelost met een null-edit. Die derde, tsja, als Multichill denkt dat die categorie bestaansrecht heeft moet ie 'm aanmaken en vullen met voldoende inhoud, vind ik; voor nu verwijderd. –bdijkstra (overleg) 21 apr 2020 16:56 (CEST)
Weer een paar: [1] en [2]. VanBuren (overleg) 4 mei 2020 16:27 (CEST)
Opgelost. –bdijkstra (overleg) 4 mei 2020 16:37 (CEST)

Te beoordelen sjablonen (week 13)Bewerken

Weet jij of er al een beslissing was genomen over de te beoordelen sjablonen van week 13? --Strepulah (overleg) 27 apr 2020 17:53 (CEST)

Zo te zien niet. –bdijkstra (overleg) 27 apr 2020 18:20 (CEST)
Oké, want ik had namelijk aangeboden het voorbereidende opruimwerk te doen en ik was bang dat er misschien iemand nou op mij zat te wachten. Maar dat zal wel niet dan. --Strepulah (overleg) 27 apr 2020 18:47 (CEST)

TerugkijkenBewerken

In de 7de kolom van mijn opsomming van bijdragen staat de grootte van die bijdragen. Is er een query mogelijk om van al mijn bijdragen, die groter zijn dan een in te vullen getal, bijvoorbeeld 500, een lijst te maken? VanBuren (overleg) 11 mei 2020 21:36 (CEST)

Ja dat kan. Wat de handigste manier is om die lijst te maken hangt er een beetje vanaf welke gegevens je nodig hebt, hoe ver je terug wilt gaan en hoe vaak die lijst moet worden bijgewerkt. –bdijkstra (overleg) 11 mei 2020 22:09 (CEST)
Veel collega's houden bij welke artikelen ze over de jaren hebben aangemaakt of bewerkt. Ik heb geen behoefte om dat zo regelmatig of intensief te doen, maar ben toch wel een keer nieuwsgierig hoe ik er voorsta qua bijdragen na zoveel jaren, als eenmalige exercitie. Het is maar een gedachte dat eem opsomming van alle bijdragen van bijv. over 500 bytes wel een voldoende beeld geven. VanBuren (overleg) 11 mei 2020 23:21 (CEST)
Ach, het is niet zo belangrijk. Excuses voor het lastigvallen. VanBuren (overleg) 12 mei 2020 11:52 (CEST)
Ik vermoed dat iemand die handig is met sql-queries op de toolserver wel zoiets kan maken (en zoiets is vast al eens gemaakt ;-) om zo een lijstje artikelen op te hoesten. Met quarry kun je verbazingwekkend snel resultaat krijgen, als je er handig mee bent. Edoderoo (overleg) 12 mei 2020 12:25 (CEST)
Blijkbaar ben ik niet handig genoeg. –bdijkstra (overleg) 12 mei 2020 12:34 (CEST)
Ik zag het. Misschien dat gebruiker:Multichill weet hoe je dat doet. Die heeft voor mij eerder quarries gemaakt, die op mijn RPi een volle dag draaiden, en met quarry in een minuut resultaat gaven. Edoderoo (overleg) 12 mei 2020 12:46 (CEST)
O, ik had niet gezien dat je al iets had uitgevonden. Werkt het niet? Ik weet niet hoe ik die quarry-query zou kunnen uitproberen. VanBuren (overleg) 12 mei 2020 13:56 (CEST)
Ik had er een beetje mee gespeeld maar de query duurde te lang en werd na een half uur afgebroken. Dus ik denk dat de web-API handiger zal zijn. –bdijkstra (overleg) 12 mei 2020 14:52 (CEST)
Ik kan dit wel met een spreadsheet realiseren, mits ik een doorlopende bijdragenlijst heb, dus vanaf 10 december 2006 tot heden in één pagina. Hoe realiseer je zo'n doorlopende lijst? Voor mijn eigen bijdragen zit ik met dezelfde vraag — bertux 14 mei 2020 23:51 (CEST)

@VanBuren, wat nieuwe pagina's betreft: je kunt hier (duurt even) bij Pages created doorklikken naar hier, waar je wat de artikelnaamruimte betreft wordt geleid naar hier. Ook van de pagina's in de artikelnaamruimte die je het vaakst bewerkt hebt kun je daar een overzicht krijgen, mits je kiest voor opt in, zie hier. Een en ander is ook mogelijk met de andere naamruimtes. Dat moet al met al wel een aardig idee geven.
@Bertux: zelfde verhaal, maar dan via hier (duurt ook even), hier, hier en (dankzij opt in) hier.
Wutsje 15 mei 2020 03:37 (CEST)

Wutsje, dank voor de links. Voor de nieuw aangemaakte pagina's werken die goed, maar voor mensen zoals VanBuren en ik, en bijvoorbeeld ook ErikvanB, die vooral redactie- en naloopwerk doen, geeft dat niet zo'n boeiend beeld. Zoals ik VanBurens vraag opvat, wil hij alle bewerkingen boven de 500 tekens zien. Wat ikzelf nodig heb is een lijst van al mijn 15.142 bewerkingen sinds 2007 in de artikelruimte, inclusief wijzigingslinks. Gewoon wat de bijdragenlijst biedt dus, alleen in één lange lijst. Vroeger kon je daarvan de url manipuleren zo dat je er 3000 tegelijk kon zien, maar tegenwoordig blijft het op 500 steken. Misschien hangt het af van de bezettingsgraad van de server, want een paar dagen geleden lukte het eenmalig weer wel om er voor iemand anders 3000 op te vragen. Bij VanBuren en mij kun je dan met zes keer kopiëren en plakken het gewenste spreadsheet vullen, wat te overzien is. Bij ErikvanB, met 462.463 bewerkingen, moet je alsnog 153 keer heen en weer sjouwen. Bij hem loopt XTools trouwens vast: User has made too many edits! (Maximum 400,000). Showing Simple Counter instead. — bertux 15 mei 2020 09:26 (CEST) 
Dan is de API handiger; kan je in een scriptje met een lus 500 (of 5000) per keer opvragen: [3]. –bdijkstra (overleg) 15 mei 2020 10:00 (CEST)
Ik heb geen idee wat een API is. Hoe en waar kan ik zo'n script met een fleurig strikje ter uitvoering aanbieden? Hoe en waar kan ik de uitvoer verwachten? Moet ik zo'n script in mijn common.js-pagina zetten? En waar zit dan de aan/uit-knop? Wordt de uitvoer een html-pagina? Een tekstbestand dat ik kan downloaden? Op https://nl.wikipedia.org/w/api.php staan links naar FAQ en documentatie, maar die zijn duidelijk bedoeld voor mensen die de ingang al gevonden hebben.
Conversie, filtering en sortering van resultaten kan ik zelf makkelijk en flexibel regelen in een spreadsheet, maar hoe kom ik aan de invoer voor dat spreadsheet. Hier, op Google Sheets heb ik de filtering al gedaan voor de laatste 500 van VanBuren, zie kolom E. Het scriptje van bdijkstra geeft ook de revisienummers, dus dat zou wel een veel betere invoer opleveren, daar kan ik de wijzigingslinks makkelijk mee reconstrueren in de spreadsheets — bertux 15 mei 2020 11:00 (CEST)

Dank Wutsje en Bertus, ik zie toch maar af van verder zoeken naar details uit mijn verleden. Beter optimistisch vooruit kijken :). VanBuren (overleg) 15 mei 2020 12:21 (CEST)

@VanBuren: Voor mezelf hoop ik dat er een bruikbaar scriptje komt; dat lijkt me een doodsimpele wens; ik kan me zelfs nauwelijks voorstellen dat dit nog niet bestond, maar op Wikipedia:Scriptbibliotheek en Category:All snippets vind ik niets. Zelf schrijf ik dan wel de filter- en sorteeropties, zoals op datum, artikelnaam, naamruimte, grootte en bewerkingssamenvatting. Als ik iets heb dat ook voor anderen bruikbaar is, laat ik het hier wel weten. Terugkijken kan ik veilig, want optimisme is mijn tweede natuur (ook mijn eerste trouwens) en wat pessimisme en stilstaan bij het memento mori zal me alleen maar goed doen — bertux 15 mei 2020 12:48 (CEST)

Beveiliging Zwarte Dood?Bewerken

Hoi bdijkstra. Een maand geleden voegde je een melding van een beveiliging toe. Het betreffende artikel heeft echter geen slotje en ik kon in de logboeken ook niets vinden. Ik weet niet of je op dit moment een beveiliging alsnog nodig vindt? Groet, Apdency (overleg) 14 mei 2020 17:40 (CEST)

Ik geloof dat ik vanaf de beveiligingsinstellingen naar de meldpagina ben gegaan en daarna ben vergeten om de beveiliging daadwerkelijk in te stellen. De bezoekersaantallen zijn inmiddels bijna op het oude niveau en het vandalisme valt wel mee, dus een beveiliging lijkt me op dit moment niet nodig. –bdijkstra (overleg) 14 mei 2020 19:14 (CEST)
OK, wat je wilt. Ik zal niettemin af en toe kijken naar het verloop. De versoepeling van de coronamaatregelen in het onderwijs zijn natuurlijk ook weer een (risico)factor. Apdency (overleg) 14 mei 2020 19:49 (CEST)
We zullen zien. –bdijkstra (overleg) 14 mei 2020 20:13 (CEST)
Dat is wel een klassieker: eerst afvinken, dan vergeten. Daar ben ik ook wel eens ingetuind. In een ziekenhuis krijg je daarvoor ongenadig op je lazer. :-)   Wutsje 14 mei 2020 19:55 (CEST)

Jij weet nog wel eens ietsBewerken

Hoi, weet jij of er een manier is om een URL als deze: https://www.handbal.nl/uitslagen-standen/#poules:standen:%20:27097 in Way Back Machine te saven? -- Sb008 (overleg) 10 jun 2020 02:42 (CEST)

Hopelijk met permissie: als het om een actuele versie van een al vaker gearchiveerde pagina gaat, ga je normaal gesproken naar https://archive.org/web/ en daar naar het vakje Save page now, daar vul je de url in en klik je op Save Page. In dit geval lukt dat om de een of andere reden niet. De spatie in de url vervangen door een underscore of door %20 helpt niet, het resultaat daarvan is slechts dit. Wat ook niet werkt, is de url met een underscore of %20 in archive.today prakken. Dan krijg je slechts dit resp. dit. In de broncode van de pagina kan ik zo gauw niet een deep link naar het xlsx-bestand vinden. Lastig, deze. Ik ben inmiddels ook wel benieuwd. Wutsje 10 jun 2020 03:51 (CEST)
Tja als je de internetstandaarden schendt door content te serveren aan de hand van wat achter de # staat, dan kan je dit soort problemen verwachten. Soms kan je in de HTML-code nog verborgen URLs vinden, maar die zag ik ook niet. –bdijkstra (overleg) 10 jun 2020 09:32 (CEST)
Het is geen URL die door hunzelf wordt gepropageerd. Onderhuids wordt o.a. PHP scripts aangeroepen. Wat er feitelijk gebeurt, is:
curl -s -X POST -d "page=poules&tab=standen&params[]=&params[]=27097" "https://www.handbal.nl/wp-content/themes/searchuser/assets/php/sportlink.php" waar in werkelijk bij de eerste "params[]=" een hele lange string staat die alleen gebruikt wordt als "display"-waarde. Misschien kan je er iets mee op basis van het curl commando. Het is dus een POST request, alleen kan je dat bij mijn weten niet in een browser-URL aangeven. -- Sb008 (overleg) 11 jun 2020 16:48 (CEST)
Inderdaad, een browser-URL met http of https wordt altijd een GET. Sommige scripts reageren hetzelfde op een POST als een GET, maar deze niet. Het enige wat je er van buitenaf aan kan doen is zelf een website beginnen die POSTs doet naar handbal.nl en daaruit pagina's genereert die via een GET zijn op te vragen. –bdijkstra (overleg) 11 jun 2020 17:14 (CEST)
Dat doe ik al met de Wiki pagina's die over de handbalcompetities gaan. Om het ook naar eigen site te doen, levert m.i. geen bron op. Het probleem met handbal.nl is dat je er alleen de actuele seizoenen kan zien, vandaar dat ik ze graag archiveerde. Maar zo te zien kan ik dat vergeten. In ieder geval bedankt voor het meedenken. -- Sb008 (overleg) 11 jun 2020 22:49 (CEST)
Ik vermoed dat dit bericht voor mij was bedoeld. Voor https://www.handbal.nl/uitslagen-standen/#poules:uitslagen:%20:27097 werkt het wel op archive.today. Zie archive. Op de plek van "uitslagen" (net voor :%20) kan ook "matrix", "standen" of "programma" staan. Wat me interesseert is "standen" en "matrix", maar "uitslagen" is een goed alternatief voor "matrix". -- Sb008 (overleg) 12 jun 2020 00:28 (CEST)
Dat bericht helpt je niet verder dacht ik. Zoals je hier kan zien kan archive.today "standen" niet correct archiveren. –bdijkstra (overleg) 12 jun 2020 09:22 (CEST)

Icoontjes interprojectlinksBewerken

Het was je misschien al wel opgevallen dat de icoontjes bij de interprojectlinks in de zijbalk onbedoeld herhaald worden. Ik denk dat je in deze bewerking per ongeluk twee puntjes teveel hebt weggehaald. Kan jij die terugzetten? Want ik kan dat niet. Alvast bedankt. Met vriendelijke groet, --Strepulah (overleg) 17 jun 2020 18:38 (CEST)

Die bewerking deed ik juist in een poging de herhaalde pictogrammen op te lossen. De puntjes terugzetten hielp niet, dus er moet denk ik nog iets als dit gebeuren. –bdijkstra (overleg) 17 jun 2020 19:05 (CEST)
Ik zat ook al in de codes te graven. Het valt me op dat in die MediaWiki:Gadget-InterProjectLinks.css bovenaan en onderaan regels voor de li's staan, en het ziet er bovendien naar uit dat de oorzaak van de lange selector-regel (met de Zweedse opmerking) in het 'te algemeen' gestelde .portlet .wb-otherproject-link ligt. Gecombineerd met de gewijzigde algemene css van de menu's, kunnen we volgens mij volstaan met:
#p-wikibase-otherprojects li.interProject,
#p-wikibase-otherprojects li.wb-otherproject-link { 
    background-repeat: no-repeat;
    background-position: left center;
    margin-left: -18px;
    padding-left: 18px;
}
De negatieve margin-left dus om de icoontjes weer 'in' de kantlijn te plaatsen. (De regels onderaan, gemarkeerd met "T190636", moeten weg.)
Met vriendelijke groeten — Mar(c). [O] 17 jun 2020 19:19 (CEST)
Dank, bij mij werkt het nu. –bdijkstra (overleg) 17 jun 2020 19:24 (CEST)
Yep, hier ook. De wijzing van de js op svwiki lijkt te maken te hebben met dat het menu tegenwoordig altijd op de pagina zou staan, maar met 'emptyPortlet' onzichtbaar gemaakt wordt indien deze leeg is. In willekeurige artikelen zonder zusterprojectlinks kan ik echter geen p-wikibase-otherprojects bespeuren. (Misschien maak ik ergens een denkfout.) — Mar(c). [O] 17 jun 2020 19:40 (CEST)
O ja, die drie bovenste regels van de li-styling (li.interProject, .portlet .wb-otherproject-link, /* specifikt för Vector; ovanstående "tar" inte av någon anledning */) kunnen dus weg; dat wordt door bovenstaand geheel afgevangen. Met vriendelijke groeten — Mar(c). [O] 17 jun 2020 19:49 (CEST)
Bedoel je dat die drie CSS-regels worden afgevangen door de nieuwe JS-code? –bdijkstra (overleg) 17 jun 2020 20:46 (CEST)
Ah nee, dat had niets met de JS te maken. Ik bedoelde dat de huidige regels 9 t/m 11 bij voorkeur weggehaald kunnen worden. Gezien de Zweedse opmerking werkten de selector-regels 9 en 10 niet 'om een of andere reden' ("av någon anledning") en waren daarom de twee onder de opmerking toegevoegd. De reden waarom ze niet werkten is dat ze te algemeen gesteld zijn (waardoor ze overruled worden door de algemene stijlregels voor de menu's); bovenstaande snippet was daarom ter vervanging van de gehele stijldefinitie (regels 9 t/m 18) bedoeld. — Mar(c). [O] 17 jun 2020 21:51 (CEST)
En zo te zien – als we met andere skins rekening willen houden (monobook, modern, timeless) – zou de negatieve margin-left alleen voor Vector moeten gelden:
#p-wikibase-otherprojects li.interProject,
#p-wikibase-otherprojects li.wb-otherproject-link { 
    background-repeat: no-repeat;
    background-position: left center;
    padding-left: 18px;
}
body.skin-vector #p-wikibase-otherprojects li.interProject,
body.skin-vector #p-wikibase-otherprojects li.wb-otherproject-link { 
    margin-left: -18px;
}
Excuses voor de onduidelijkheid en de spam! — Mar(c). [O] 17 jun 2020 22:00 (CEST)
Geen probleem, ik ben blij dat ik niet meer hoef te graven. –bdijkstra (overleg) 18 jun 2020 12:39 (CEST)
In de Lijst van plaatsen in Estland staat links onder "In andere projecten" nog steeds een hele rij icoontjes. Ik zie ze in Firefox, in Chrome en in Internet Explorer. Is dit hetzelfde (of een verwant) probleem? Sijtze Reurich (overleg) 18 jun 2020 20:38 (CEST)
Bij mij (chromebook) ziet die pagina er prima uit. Paginacache verversen? Ctrl+F5 of Ctrl+Shift+R, afhankelijk van de browser. Een loze bewerking doen, spatie erbij of eraf, helpt ook — bertux 18 jun 2020 21:27 (CEST)
Welke skin gebruik je, bertux? Ik zie het ook met Vector. –bdijkstra (overleg) 18 jun 2020 21:29 (CEST)
Ik gok dat dit is waarom de Zweden ook de JS-code veranderd hebben. En ik vermoed dat Sjabloon:InterProject ook bijgewerkt moet worden. –bdijkstra (overleg) 18 jun 2020 21:29 (CEST)

Volgens mij gaat het meer om het <nav>-element eromheen. De ene keer staan de links in een <nav id="p-wikibase-otherprojects" /> (werkt wel) en de andere keer in een <nav id="p-project" /> (werkt niet).
Helpt het als je in Gadget-IProject.js, p-project vervangt door p-wikibase-otherprojects? En waarom werkt het eigenlijk op de ene pagina anders dan op de ander? --Strepulah (overleg) 18 jun 2020 21:44 (CEST)

Sommige links komen van Wikidata en sommige van een sjabloon, vandaar het verschil. –bdijkstra (overleg) 18 jun 2020 21:46 (CEST)
Geen idee wat je gedaan hebt, maar het probleem met de Lijst van plaatsen in Estland is verholpen. Bedankt! Sijtze Reurich (overleg) 18 jun 2020 21:48 (CEST)
Ik heb niks gedaan, en ik zie ook geen relevante wijzigingen in m'n volglijst. –bdijkstra (overleg) 18 jun 2020 23:12 (CEST)
Ah, oké. Vandaar. Maar voor p-project werkt het nou in ieder geval niet meer. Volgens mij kun je ofwel p-project hernoemen naar p-wikibase-otherprojects, danwel zo aanpassen in de CSS dat de opmaak binnen p-project ook werkt. --Strepulah (overleg) 18 jun 2020 22:17 (CEST)
MediaWiki:Gadget-IProject.js wordt niet meer gebruikt. Misschien beter verwijderen? –bdijkstra (overleg) 18 jun 2020 23:11 (CEST)
O. Ja, als die niet gebruikt wordt dan verwijder maar. Dat <nav>-element wordt dan natuurlijk aangemaakt in Gadget-InterProjectLinks.js. Dan zou het daar aangepast kunnen worden. --Strepulah (overleg) 18 jun 2020 23:35 (CEST)

Bdijkstra, ik gebruik gewoon Vector. Heb eventjes een herhaalreeks gehad, maar minstens sinds woensdagavond ziet het er prima uit, elk project met een eigen fleurig icoontje — bertux 19 jun 2020 00:46 (CEST)

Er zijn nog een paar plekken waar het fout gaat, bijvoorbeeld op Archifoneem. Er kan anders (minder ingrijpend) ook een aanpassing gedaan worden in Gadget-InterProjectLinks.css:

#p-project li.interProject, /* <-- Toevoegen */
#p-wikibase-otherprojects li.interProject,
#p-wikibase-otherprojects li.wb-otherproject-link { 
    ...
}
body.skin-vector #p-project li.interProject, /* <-- Toevoegen */
body.skin-vector #p-wikibase-otherprojects li.interProject,
body.skin-vector #p-wikibase-otherprojects li.wb-otherproject-link { 
    ...
}

Volgens mij werkt dat ook. --Strepulah (overleg) 19 jun 2020 14:43 (CEST)

Het werkt weer. Dankjewel. --Strepulah (overleg) 20 jun 2020 13:26 (CEST)

Website suggereertBewerken

Als een link dood is, is het gebruikelijk dat we naar web.archive.org linken, als die nog wel iets heeft. Nu ga jij in je eentje bepalen dat we lezers ook die mogelijkheid ontnemen. Waarom? Waarom is helemaal niks beter dan het webarchief? Met jouw argumentatie moeten we het hele webarchief links laten liggen. Ik snap hier echt helemaal niks van, en ik vind dat je hiermee kennis aan het verwijderen bent, in plaats van kennis delen. En kennis delen is het hoogste doel op dit project. Edoderoo (overleg) 2 jul 2020 10:05 (CEST)

Rustig aan, er wordt helemaal niks ontnomen en er wordt geen kennis verwijderd. Als er geen levende website is dan haal ik deze weg uit de infobox en zorg ik dat een (archief)link staat bij 'Externe links'. –bdijkstra (overleg) 2 jul 2020 10:28 (CEST)
Ah, dat heb ik over het hoofd gezien. In dat licht bezien hebben je opmerkingen inderdaad meer zin. Dan ga ik inderdaad even rustig aan doen, en je niet meer voor de voeten lopen! Edoderoo (overleg) 2 jul 2020 10:42 (CEST)

Update 2.0Bewerken

Goedenavond Bdijkstra

Zou ik je deze vraag nog eens opnieuw mogen stellen? Deze keer niet anoniem natuurlijk.

Zou je Help:Veelvoorkomende spelfouten met Bitbotje nog eens kunnen updaten?

Groetjes JP001 (Overleg)   3 jul 2020 20:26 (CEST)

Bdijkstra? JP001 (Overleg)   7 jul 2020 14:31 (CEST)
Eigenlijk niet. Een zoekopdracht met alleen insource:/.../ creëert nogal een belasting op de server en wordt ook afgeraden, en die pagina bevat er honderden. Bovendien staat mijn vraag op Overleg help:Veelvoorkomende spelfouten#Te doorzoeken naamruimten nog steeds open. –bdijkstra (overleg) 7 jul 2020 15:26 (CEST)

BeveiligingBewerken

Beste Bdijkstra, vandaag is door u het artikel Israëlische nederzetting beveiligd na een bewerkingsoorlog. Begrijpelijk, soms is dat nodig. Maar toch voel ik me nu wat onheus bejegend, niet door u overigens. Maar omdat ik oprecht van mening ben dat dit artikel meer in balans komt door geweld van beide kanten te belichten. Dat is toch de basis van Wikipedia. U stelt dat de gebruikers tot een consensus moeten komen. Ik snap dat, echter eerdere discussies gaven geen enkele opening. Ik heb namelijk een paragraaf toegevoegd waarin geweld tegen kolonisten wordt omschreven nadat er al een paragraaf bestond over geweld door kolonisten. Ik heb de paragraaf aangepast aan de kritiek dat er geen context zou zijn, met dien verstande dat een losse paragraaf niet de hele context kan weergeven. Dat doen de andere paragrafen in het artikel namelijk ook niet. Ik wil niet zo flauw zijn door ook gedeelten te verwijderen maar andersom gebeurd het wel. Het lijkt me onmogelijk hierin tot een consensus te komen. De gebruiker die bezwaar maakt lijkt ook niet neutraal getuige het in het verleden aanmaken van een artikel als Apartheidsstaat Israël en lijkt de paragraaf niet te dulden in het artikel. De Engelse, Duitse en Franse Wikipedia's kennen echter wel een dergelijke paragraaf. Wat is raadzaam hierin? Ik verwacht dat de gemeenschap in zijn geheel hierin een wat meer constructieve houding heeft. Zijn er mogelijkheden om deze kwestie voor te leggen aan een neutrale commissie binnen Wikipedia? Alvast hartelijk dank. Stipenstoer (overleg) 9 jul 2020 15:47 (CEST)

De pagina is beveiligd, maar de overlegpagina is dat niet. Daar kun je je punten uiteenzetten. Vaak helpt het om om meer meningen te vragen via WP:OG (overleg gewenst), die pagina hebben veel gebruikers op hun volglijst staan. Veel gebruikers komen vaak wel tot consensus, als het dan niet lukt, dan ligt het ofwel aan jou (daar heb ik zelf ook nog wel eens last van ;-) of je hebt pech (maar dan moet je je er toch bij neerleggen). Edoderoo (overleg) 9 jul 2020 17:18 (CEST)
Procedureel: zelfs als je gelijk hebt, en (vrijwel) iedereen het met je eens is, dan nog is dat geen reden om een bewerkingsoorlog te voeren. Eerst consensus behalen, of eventueel een probleemgebruiker laten blokkeren. En als het onmogelijk is om tot een consensus te komen, dan geldt de status quo.
Inhoudelijk: is het neutraal om het conflict te bekijken door de polarisatiebril van beide kampen? Het is prima om de verschillende beweegredenen te belichten, maar geweld is geweld. Zijn er geen bronnen die het geweld in een bredere context plaatsen? –bdijkstra (overleg) 9 jul 2020 18:05 (CEST)
Neutraal is vaak niet te behalen, omdat het bronmateriaal dat je moet gebruiken in ons taalgebied zelden neutraal is (behalve als je goed in Engelstalige bronnen ingevoerd bent, dan kun je nog wel ver komen). De Nederlandstalige Wikipedia heeft nu eenmaal een flinke bias/vooringenomenheid vanwege onze culturele insteek. Precies om die reden vindt niemand het 8-uur journaal neutraal, de een vindt ze linkse kerk, de ander rechts gebral, en toch doen de journalisten hun best het neutraal te brengen. Edoderoo (overleg) 9 jul 2020 18:12 (CEST)
Ik bedoel te zeggen dat het de neutraliteit niet bevordert door te zeggen: "ja maar hullie zijn ook stout!" –bdijkstra (overleg) 9 jul 2020 18:40 (CEST)
Inderdaad is het vinden van een neutrale bron lastig. Dan kom je bij het CIDI of Christenen voor Israel. Dat wil ik voorkomen. Maar dat er nu uitgebreid wordt stilgestaan bij vernielde olijfboomgaarden, maar dodelijke aanslagen niet vermeld mogen worden voelt als censuur. Bedankt voor de tip WP:OG (overleg gewenst). Het lijkt me dat bij dit onderwerp met meerdere partijen toch wel een bepaalde consensus bereikt kan worden. Vriendelijke groeten, Stipenstoer (overleg) 9 jul 2020 19:00 (CEST)
Het moet wel gezegd worden, dat het vooral de Israëlische propagandamachine is, die gewonde Israëliërs prominent onder de aandacht brengt en Palestijns geweld uitgebreid beschrijft, maar voorbijgaat aan de daden van de eigen militairen, die vaak opereren op plekken waar ze volgens het internationaal recht niet mogen zijn — bertux 9 jul 2020 19:42 (CEST)
Wie denkt dat het CIDI en Christenen voor Israel neutraal zijn, mist ook wel een beetje common sense. Dat zijn twee belangenverenigingen, die toch behoorlijk pro-Joods en pro-Israel zijn. Sowieso kan geen enkele kerkelijke organisatie neutraal genoemd worden. Ze kunnen prima bronmateriaal aanleveren dat gebruikt kan worden, maar zeggen dat publicaties van die twee verenigingen de maatstaf voor neutraliteit zijn, zijn tegen mijn zere been. Edoderoo (overleg) 9 jul 2020 20:08 (CEST)
Bertux, dat moet toch weerlegd worden. Als ik kijk naar de Westelijke Jordaanoever zijn vele malen meer bronnen te vinden over geweld door kolonisten dan andersom. Echt enorm veel meer. En dat terwijl er toch heel wat dodelijke aanvallen zijn geweest op de nederzettingen. Ik schat in meer dan andersom, maar dat kan ik niet staven. Dit fenomeen kan waarschijnlijk verklaard worden doordat de heersende opinie zoiets heeft van ‘eigen schuld’. Eenzelfde reflex als bij de verdrijving van Duitsers na de Tweede Wereldoorlog uit Oost-Europese landen. Veel leed, veel doden, maar ‘ze hadden het aan zichzelf te danken’. Bij de erfaanvallen in Zuid-Afrika zie je die reflex ook wel. Ik begrijp het wel, maar het mag wel omschreven worden. Stipenstoer (overleg) 10 jul 2020 08:51 (CEST)
We gaan bij Wikipedia dan wel uit van degelijk bronmateriaal, niet van dat moet toch wel, maar dat kan ik niet staven. Als het bronmateriaal er niet is, of tekort schiet, dan is het voor Wikipedia pech, maar past het niet in de encyclopedie. Wikipedia geeft een weergave van de maatschappij aan de hand van bronnen, dus Wikipedia is geen weergave van de werkelijkheid, ongeacht door wie die werkelijkheid gezien wordt. Houdt er ook rekening mee dat de werkelijkheid niet bestaat, iedere werkelijkheid is de beleving van een individu. Blijkbaar weerspiegelt het artikel nu niet jouw werkelijkheid, maar hebben anderen er blijkbaar minder moeite mee. Edoderoo (overleg) 10 jul 2020 09:10 (CEST)
Nu praten we een beetje langs elkaar heen. Het is geen wedstrijd wie het meeste geweld pleegt. Dat hoeft ook niet in Wikipedia. Maar dat er ook geweld tegen de kolonisten voorkomt is evident, getuige de neutrale bronnen over de aanslagen en aanvallen. Nu komt het helemaal niet in het artikel voor. En dat is m.i. niet neutraal. Stipenstoer (overleg) 10 jul 2020 10:03 (CEST)
Pak dan die bronnen er bij, schrijf een voorstel op de overlegpagina (omdat het artikel beveiligd is), en wie weet ... Edoderoo (overleg) 10 jul 2020 10:25 (CEST)
Stipenstoer, dat weerlegt helemaal niets. De Israëlische propagandamachine, waartoe ik het CIDI uitdrukkelijk reken, heeft veel meer macht, financiële middelen en toegang tot bronnen dan de Palestijnen. Logisch dat er meer berichten zijn die in hun straatje te pas komen. Je kunt beter kijken naar bronnen die het aantal doden en gewonden tellen, dan zie je een heel ander plaatje. Israëlische bronnen hebben er een handje van om twee gewonden aan hun kant bovenaan in een bericht te zetten en in de voorlaatste alinea terloops te vermelden dat er een Palestijn om het leven is gekomen; die wordt dan gewoonlijk als aanvaller of terrorist aangeduid, terwijl de echte agressors de kolonisten zijn, die Palestijns gebied bezetten met goedvinden van Netanyahu — bertux 10 jul 2020 11:26 (CEST)
Mijn opvattingen hierover zijn bekend, zie ook deze permalink van Overleg gebruiker:MWAK#Zesdaagse oorlog, waar ik het wat pittiger verwoord heb — bertux 10 jul 2020 12:13 (CEST)

Als iemand CIDI en Christenen voor Israel als neutrale bronnen beschouwt weten we genoeg. Maar waarom start Stip en stoer een parallelle discussie op een gebruikerspagina (eerder ook al op die van mij), i.p.v waar die thuis hoort? Wickey (overleg) 10 jul 2020 13:02 (CEST)

Wie beschouwt het CIDI en Christenen voor Israel dan als neutrale bron? Stipenstoer (overleg) 10 jul 2020 14:02 (CEST)
Je ambivalente opmerking hierboven is i.i.g. zo opgevat, maar misschien bedoel je precies het tegenovergestelde. Wickey (overleg) 10 jul 2020 14:07 (CEST)
Precies. Stipenstoer (overleg) 10 jul 2020 14:48 (CEST)
Ik las in je bovenstaande bijdrage inderdaad al dat je het CIDI en Christenen voor Israel juist geen neutrale bronnen vindt. Dat gezegd hebbende denk ik dat jouw paragraaf over het geweld tegen de kolonisten in zijn huidige vorm het lemma wel degelijk flink uit balans trekt. Deze discussie kan echter, zoals Wickey ook al zei, beter gevoerd worden op de overlegpagina van het lemma zelf, dus ik heb mijn uiteraard zeer bescheiden bijdrage dan ook aldaar geleverd. — Matroos Vos (overleg) 10 jul 2020 15:54 (CEST)

Infobox plantageBewerken

Dag Bdijkstra. Of wat vriendelijker: Dag B.! Misschien lukt het jou ervoor te zorgen dat op {{Infobox plantage}} de font-size 85% wordt, zoals in elke infobox. Het huidige sjabloon ziet er niet uit als een infobox met die grote letters en regelhoogte. Tot nu toe zie ik ook geen effect in artikelen nadat ik dit heb gedaan (dan past het beter), maar misschien duurt het even. Vriendelijke groet, ErikvanB (overleg) 24 jul 2020 18:05 (CEST)

  Uitgevoerd. Wel apart dat {{Infobox plantage}} de CSS-klasse "infobox" gebruikt maar {{Infobox generiek}} niet. Om te experimenteren met eenvoudige wijzigingen aan sjablonen gebruik ik meestal Speciaal:SjablonenSubstitueren, hiermee vervuil je geen volglijsten en het is minder bewerkelijk dan het kopiëren naar de eigen naamruimte. En om het effect van wijzigingen aan sjablonen te kunnen zien kan je de gadget "Extra link in de taakbalk om de paginacache te verversen" inschakelen in je voorkeuren. –bdijkstra (overleg) 24 jul 2020 18:26 (CEST)
Hartelijk dank, en ook hartelijk dank voor de tips, die ik op me in ga laten werken. Fijne dag, ErikvanB (overleg) 24 jul 2020 19:12 (CEST)

LegendaBewerken

Goedemorgen Bdijkstra,

Goed dat je me bewust maakte van de gevolgen. Die opmaak met inline-block-spans had ik in april vorig jaar op dat andere artikel geïntroduceerd. Wat ik me nu afvraag: hebben de <p>-tags van Sjabloon:Legenda (voor mijn aanpassing van eergisteren) al die tijd geen lint-fouten veroorzaakt op die twee artikelen?

Ik dacht trouwens dat ik {{legenda}} net als {{legenda-lijn}} van een parameter 'inline' had voorzien (waarmee een nettere broncode voor die twee artikelen mogelijk is). Ik zal eens gaan graven in mijn openstaande tabs. Laat maar weten als ik iets over het hoofd zie!

Met vriendelijke groeten — Mar(c).[overleg] 3 aug 2020 11:15 (CEST)

Nee, p binnen span geeft geen lint-fouten, zelfs niet van lage prioriteit. De parser laat zulke constructies ook in stand. –bdijkstra (overleg) 3 aug 2020 11:24 (CEST)
Ah, bijzonder, aangezien het wel een block-element is (dat daar binnen een inline-element stond).
Ik zie nu dat ik verdere aanpassingen van {{legenda-lijn}} ook nog niet opgeslagen heb. Blijkbaar was het laat.  
Met vriendelijke groeten — Mar(c).[overleg] 3 aug 2020 12:25 (CEST)
De sjabloon {{legenda-lijn}} heb ik nu aangepast. Dezelfde constructie met 'inline' heb ik voor {{legenda}} klaarstaan. Aangezien die sjabloon op 'ietsje' meer artikelen wordt toegepast: zie je mogelijke problemen? — Mar(c).[overleg] 3 aug 2020 13:26 (CEST)
Prima zo, en geen nieuwe lint-fouten op die pagina's. –bdijkstra (overleg) 3 aug 2020 13:41 (CEST)
  Uitgevoerd, en voor zover ik zie waren dat de enige twee pagina's met een html-tag om de legenda-items. Mochten er andere onvoorziene (ongewenste) effecten aan de sjabloon-aanpassingen kleven, dan kijk ik daar graag naar. Met vriendelijke groeten — Mar(c).[overleg] 3 aug 2020 14:51 (CEST)