overleg gebruiker:bdijkstra

Uit Wikipedia, de vrije encyclopedie
Naar navigatie springen Jump to search

Linken[bewerken]

Dag, Bdijkstra. Hiermee ga ik akkoord, hoor. Maar had je het dossier, het overleg bij The Banner en blokverzoek gezien? Dit ter info. Hartelijke groeten, ErikvanB (overleg) 3 jan 2018 14:08 (CET)

Het dossier had ik een week geleden gezien, de huidige versie en de rest nu net bekeken. Het is inderdaad een gebruiker die zich wel wat mag leren in te houden. –bdijkstra (overleg) 3 jan 2018 14:34 (CET)
Bedankt. ErikvanB (overleg) 3 jan 2018 14:37 (CET)

Vlaggen[bewerken]

Dag Bdijkstra, gewoon uit nieuwsgierigheid: ik zie dat je met enige regelmaat doubluremeldingen oplost bij de sjablonen voor vlaggen. Wat mij betreft was er geen enkele reden om die als doublures op te vatten omdat bij het sjabloon met de iso-code de volledige landsnaam bij de vlag wordt getoond, en in het andere geval de code van het IOC; de sjablonen hebben een volstrekt andere functie. Ik zie nu dat ze in januari 2017 allemaal door één gebruiker, Liuxinyu970226, als doublures zijn gemarkeerd. Is het nou zo dat we moeten vaststellen dat die dat onterecht deed, en met een gebrek aan inzicht? Want als dat laatste het geval is, dan kan dat deel van de lijst volgens mij in rap tempo worden afgehandeld. Hartelijke groet, WIKIKLAAS overleg 5 jan 2018 14:02 (CET)

In sommige gevallen is er geen enkel conflict, en in alle andere gevallen tot nu toe gaat het om sjablonen die alleen op zhwiki een doublure zijn. In deze gevallen moet in ieder geval de zhwiki-sitelink op de IOC-sjablonen verwijderd worden. Verder zal het de bedoeling van Liuxinyu970226 zijn geweest dat er ook iets op zhwiki gebeurt, maar daar is de Wikidata-doublure niet voor bedoeld. Het markeren gebeurde dus op de verkeerde manier, door waarschijnlijk een gebrek aan inzicht. En inderdaad kan het in rap tempo, maar ik heb geen haast. –bdijkstra (overleg) 5 jan 2018 15:31 (CET)
Ik had gezien dat je indien aanwezig ook de link naar zh-wiki verwijderde. Op dat project wordt immer niet de IOC-code getoond, maar een naam in het Chinees. WIKIKLAAS overleg 5 jan 2018 18:03 (CET)
Na een paar gevallen aangepakt te hebben: het probleem zit inderdaad op de Chinese Wikipedia, waar ze in diverse gevallen sjablonen met exact dezelfde functie (vlag met landnaam tonen) onder verschillende namen hebben, en er dan één linken aan de sjablonen die bedoeld zijn voor de vlag met IOC-code. Dat moeten ze inderdaad lokaal oplossen met een redirect of samenvoegen. Met het "in rap tempo afhandelen" bedoelde ik overigens niet om jou tot meer vaart aan te zetten. Ik vroeg me meer af of de kust voor mij vrij was om even de handen uit de mouwen te steken. WIKIKLAAS overleg 5 jan 2018 19:48 (CET)
En opgeruimd. Dat maakt nu ook de lijst een stuk overzichtelijker. WIKIKLAAS overleg 6 jan 2018 13:15 (CET)
Zeker! Bedankt. –bdijkstra (overleg) 6 jan 2018 13:36 (CET)
Had ik al eens gezegd dat ik de samenwerking met jou als bijzonder prettig ervaar? Je brengt een grote hoeveelheid technische kennis mee die echt ten dienste komt van het oplossen van problemen, en laat vervolgens anderen de ruimte om die problemen mee aan te pakken. Het op deze manier werken is wat mij betreft buitengewoon vruchtbaar. WIKIKLAAS overleg 7 jan 2018 03:04 (CET)
Je had dat al een beetje laten doorschemeren, maar nog nooit expliciet gezegd. Een mooi compliment. Hoewel ik ook een aantal hulppagina's heb waar van vruchtbaarheid nog niet echt sprake is, is het voor mij vanzelfsprekend om op deze manier te werken. Dit is tenslotte een samenwerkingsproject. –bdijkstra (overleg) 18 jan 2018 09:35 (CET)

Verwijdering versie 50786048 van 81.246.254.63 (vanaf nu met gebruikersaccount: Nps434)[bewerken]

(huidig | vorige) 16 jan 2018 17:44‎ Bdijkstra (overleg | bijdragen)‎ . . (175.090 bytes) (+92)‎ . . (Versie 50786048 van 81.246.254.63 (overleg) ongedaan gemaakt.) (ongedaan maken | bedanken) (Label: Ongedaan maken)

Waarom werd deze wijziging zonder enige vermelding van reden ongedaan gemaakt? Nps434 (overleg) 16 jan 2018 23:43 (CET)

Met die wijziging werden een heel aantal handige wikilinks verwijderd en werd in veel gevallen een spelling gebruikt die in strijd is met de richtlijn Wikipedia:Buitenlandse geografische namen. –bdijkstra (overleg) 17 jan 2018 09:43 (CET)

Verwijdering versie 50787670 van 81.246.254.63 (vanaf nu met gebruikersaccount: Nps434)[bewerken]

(huidig | vorige) 16 jan 2018 22:45‎ Bdijkstra (overleg | bijdragen)‎ . . (1.531 bytes) (-21.906)‎ . . (Zo werkt dat niet. Versie 50787670 van 81.246.254.63 (overleg) ongedaan gemaakt.) (ongedaan maken | bedanken) (Labels: Vervangen, Ongedaan maken)

Waarom werd deze wijziging/aanvulling ongedaan gemaakt? De nieuwe info komt trouwens van een zeer betrouwbare bron die ook vermeld wordt in mijn samenvatting. Nps434 (overleg) 16 jan 2018 23:48 (CET)

Met die wijziging voegde je informatie toe op een pagina die daarvoor niet bedoeld is. Om de inhoud hanteerbaar te houden is ooit besloten om de eigenlijke gegevens te verspreiden over subpagina's A t/m Z. Nu blijkt dat de Visuele Tekstverwerker daar niet erg elegant mee omgaat; ik heb zojuist een waarschuwing in de pagina gezet om herhaling te voorkomen. Overigens fijn dat je nu een gebruikersnaam hebt, dat scheelt een hoop controlewerk. –bdijkstra (overleg) 17 jan 2018 10:00 (CET)

Ik begrijp dat u de inhoud hanteerbaar wil houden, maar het is niet handig om te werken met een lijst die niet up-to-date is. Ik wil/kan aan deze lijst bijdragen om deze te vervolledigen voor verschillende landen, maar hoe kan ik dan best te werk gaan? Met de Visuele Tekstverwerker was dit handig voor mij, maar op een andere wijze zie ik dit niet onmiddellijk zitten. Kan ik mijn bestanden (per land) ergens doorsturen? Elke bijdrage tot Wikipedia is toch handig zowel voor mij, als voor anderen. Nps434 (overleg) 17 jan 2018 20:57 (CET)

Geen probleem, de subpagina's zijn prima met de Visuele Tekstverwerker te bewerken. Zie hieronder een overzicht. –bdijkstra (overleg) 17 jan 2018 21:02 (CET)

Ik heb om te beginnen een update gemaakt voor Indonesië met IATA-code beginnend met A. Bedankt om dit eens te controleren. Als er nog iets mis is hoor ik het wel.Nps434 (overleg) 17 jan 2018 21:43 (CET)

Ja, er was nog iets mis: weer die ontbrekende wikilinks. De derde kolom ("luchthaven") hoort een wikilink te bevatten naar het artikel over het vliegveld en de vierde kolom ("stad") hoort een wikilink te bevatten naar het artikel over de stad die de luchthaven bedient. –bdijkstra (overleg) 17 jan 2018 22:03 (CET)

Met uw tips inachtgenomen nu update gemaakt voor Indonesië met B. Hopelijk is dit al wat correcter. Aldoende leert men hé. Voldoet dit niet laat het mij weten, dat apprecieer ik.Nps434 (overleg) 17 jan 2018 22:47 (CET)

Helaas zie ik eigenlijk totaal geen verbetering wat betreft de wikilinks. Je maakte zelfs een link naar Soa, waarmee je liet blijken dat je je links niet controleert. Ook maakte je een link naar Sultan M. Salahuddin, wat de naam van een persoon is. Blijkbaar heb je de bestaande links niet bestudeerd, want dan zou je weten dat vrijwel elke link naar een luchthaven ofwel eindigt met "Airport" of begint met "Luchthaven". Dit alles wekt geen vertrouwen in de correctheid van een link als bv. Berau. Op de Indonesische Wikipedia is Berau een doorverwijspagina, en geen van de genoemde artikelen lijkt naar een stad te verwijzen. –bdijkstra (overleg) 17 jan 2018 23:10 (CET)

Op naar Indonesië met C: ik heb nu wel degelijk mijn links gecontroleerd. Hoop dat dit een verbetering geeft. Hou me op de hoogte.Nps434 (overleg) 17 jan 2018 23:39 (CET)

Dat was helaas absoluut niet acceptabel. Misschien eerst maar eens Help:Gebruik van links lezen. Ook zie ik graag nog een reactie van je omtrent Berau. –bdijkstra (overleg) 17 jan 2018 23:56 (CET)

Omtrent Berau: Berau is inderdaad géén stad, maar een district/regentschap, maar Tanjung Redeb (wat er oorspronkelijk stond) is de hoofdstad van het district Berau. Misschien dan best wijzigen naar Tanjung Redeb, Berau met link Tanjung Redeb, Berau (de pagina bestaat niet)? Wat betreft de links: ik heb de pagina 'Help: Gebruik van links' eens doorgenomen. Wat ik hieruit versta is als er géén link in de Nederlandse Wikipedia bestaat, je best een 'rode' link maakt met (de pagina bestaat niet). Van hieruit kan men dan verder controleren naar anderstalige Wikipedia's. Of moet je nog ergens noteren dat er een anderstalige Wikipedia bestaat, bv Cakrabhuwana Airport (Artikel in Indonesische Wikipedia)? Bij externe links (buiten Wikipedia) kan een externe koppeling gebruikt worden in de Visuele Tekstverwerker, maar dit moet zoveel mogelijk beperkt worden. De 'blauwe' link is een link die beschikbaar is in de Nederlandse Wikipedia. Sorry, maar het is allemaal niet zo simpel uitgelegd voor een leek op Wikipedia. – De voorgaande bijdrage werd geplaatst door Nps434 (overleg · bijdragen) 18 jan 2018 01:24‎ (CET)

Er is maar één Tanjung Redeb, dus Tanjung Redeb volstaat. Soms is het nuttig om via een voetnoot te verwijzen naar een anderstalige Wikipedia, maar dat is in deze tabel niet echt van toepassing. Zijn er nog meer wijzigingen die je gedaan hebt in de vierde kolom die niet naar een stad verwijzen? Zo ja, dan graag weer terugzetten. –bdijkstra (overleg) 18 jan 2018 10:07 (CET)

Er zijn géén andere wijzigingen meer uitgevoerd in de vierde kolom. Ik heb ook Berau terug aangepast naar Tanjung Redeb.Nps434 (overleg) 18 jan 2018 20:35 (CET)

Fijn! Zie overigens hier een lijstje met Indonesische luchthavens met valide namen van artikelen over de luchthavens en over de steden. –bdijkstra (overleg) 18 jan 2018 21:04 (CET)

Jubileumster 10 jaar[bewerken]

Voor mensen die zich al 10 jaar of langer inzetten voor Wikipedia. Aangezien u nog altijd actief bent, dan is deze ster hier wel op zijn plaats. Rode raaf (overleg) 28 jan 2018 17:18 (CET)

Harten[bewerken]

Beste,

doe nou even rustig aan, svp. Ik ben nog bezig. Bedankt. --Dick Bos (overleg) 19 feb 2018 11:39 (CET)

Sorry maar voor elk probleem dat ik opmerk ga ik niet kijken of er iemand mee bezig is, dit ergens noteren zodat ik het niet vergeet, en vervolgens later kijken of het al is opgelost. Je had het gewoon beter in een andere volgorde kunnen doen. –bdijkstra (overleg) 19 feb 2018 11:48 (CET)
Neem me niet kwalijk..... Maar hoe ik het beter zou kunnen doen, bepaal ik eerlijk gezegd liever zelf. Hartelijke groet. --Dick Bos (overleg) 19 feb 2018 12:08 (CET)
Uiteraard. Ik gaf alleen mijn mening. Doe ermee wat je wilt. –bdijkstra (overleg) 19 feb 2018 12:14 (CET)

Markeren[bewerken]

Beste Bdijkstra,

Op 26 februari om 22:15 veranderde een niet-ingelogde gebruiker op Lijst van landen naar bbp per hoofd van de bevolking het gemiddelde inkomen voor Noorwegen. Een minuut later heb jij deze bewerking als gecontroleerd gemarkeerd. Bij de pagina wordt een bron genoemd: IMF. Ik heb deze bron erbij gepakt en bij Norway staat 79,085.001. De bewerker had dus, al dan niet bewust, de informatie in het artikel foutief aangepast. De bijdrage is alsnog gecontroleerd en ongedaan gemaakt. Met vriendelijke groet, RonnieV (overleg) 27 feb 2018 00:45 (CET)

Ik had het gemarkeerd met de intentie om direct nog eens bij de IMF te kijken of ze al nieuwere cijfers hadden. Helaas raakte ik afgeleid. Beter niet direct markeren, dus. –bdijkstra (overleg) 27 feb 2018 09:46 (CET)
Kan gebeuren. Met vriendelijke groet, RonnieV (overleg) 27 feb 2018 11:07 (CET)

Bewerkingssamenvatting Bitbotje[bewerken]

Hallo Bdijkstra,

Wil je proberen de bewerkingssamenvattingen van Bitbotje zo correct mogelijk te maken? In bijvoorbeeld deze en deze bewerking doet de bot veel meer dan alleen het weghalen van dubbele lidwoorden. En hier zelfs iets heel anders. Met vriendelijke groet, RonnieV (overleg) 28 feb 2018 11:57 (CET)

In het 1e geval werden er op het lidwoord na alleen 'general fixes' toegepast, die hier geen visuele verandering tot gevolg hadden; AWB kan hiervoor geen samenvatting maken. In het 2e geval zou ik inderdaad het maalteken kunnen vernoemen; de nbsp is ook weer 'general fixes' en heeft alleen een effect op de regelafbreking. In het 3e geval gebeurde er juist niets anders dan het corrigeren van een dubbel lidwoord. Enfin, ik heb nu de optie "Add replacements to edit summary" ingeschakeld, die ik meestal uit heb staan omdat dit meestal meer verwarring oplevert dan verduidelijking bij complexe expressies. Voldoet dat aan je wens? –bdijkstra (overleg) 28 feb 2018 12:25 (CET)
Bedankt voor je antwoord, en de verduidelijking. De 'general fixes' staan geheel los van 'dubbel lidwoord', alleen kom je er toevallig toe omdat er ergens op die pagina sprake was van een dubbel lidwoord. Bij Hardin liet je niet zo maar een dubbel lidwoord vervallen, maar verving je dat (overigens terecht) door een ander woord. Met vriendelijke groet, RonnieV (overleg) 28 feb 2018 12:35 (CET)
Maar vind je het beter met de meer uitgebreide bewerkingssamenvatting? –bdijkstra (overleg) 28 feb 2018 13:28 (CET)

Compliment[bewerken]

Zojuist zag ik via mijn volglijst deze bewerking. Vaak belooft de samenvatting dat er een dubbel woord is verwijderd niet veel goeds, dus ik keek even. En tot mijn grote tevredenheid zag ik dat de botbestuurder de tekst ook echt had gelezen en begrepen, en een fout had omgezet in de bedoelde zinvolle mededeling. Ik had dat kunnen vermoeden als ik wist wie de bestuurder van Bitbotje was, maar tot op heden wist ik dat niet. Hartelijke groet, WIKIKLAAS overleg 28 feb 2018 20:10 (CET)

Haha, grappig dat je er nu net een hele lastige uitpikt. Meestal heb ik aan vijf woorden wel genoeg, maar hier moest ik de hele paragraaf lezen om zeker te zijn. Dank & groet, –bdijkstra (overleg) 28 feb 2018 20:37 (CET)

Longhua of Lunghua[bewerken]

Beste bdijkstra,

Onbekend met je bijdrage hier heb ik gisteren het artikel Kamp Lunghua geplaatst. Ik wil onmiddellijk aannemen dat je gelijk hebt dat dit Longhua moet zijn. Het punt is echter dat ik zeker tien Engelstalige bronnen hebt geraadpleegd, waarvan negen het als Lunghua schrijven en slechts een als Longhua. Ook de interwiki's schrijven het als Lunghua. Het kan mogelijk zijn, dat er voor het Nederlands een specifieke reden is dat het Longhua moet zijn of dat al die Engelstalige bronnen het fout hebben. Ik zou echter graag nog even een reactie van je willen zien. Met vriendelijke groet, Renevs (overleg) 7 mrt 2018 12:20 (CET)

Engelstalige bronnen noemen Poetin ook Putin en dat is in het Engels ook niet fout. Het kamp is vernoemd naar een Chinees woord. Als je uitgaat van dat woord en Wikipedia:Transliteratie- en transcriptiegids#Chinees gebruikt, kom je op Longhua. –bdijkstra (overleg) 7 mrt 2018 13:09 (CET)
Mijn dank voor je reactie. Ik vind een eventuele vergelijking tussen enerzijds Poetin-Putin en anderzijds Lunghua-Longhua overigens irrelevant. Ik accepteer echter de rest van je uitleg en heb het inmiddels gewijzigd. Met dank, Renevs (overleg) 7 mrt 2018 20:02 (CET)

Python[bewerken]

Leuk dat je met python-scripts bezig bent/begonnen bent. Ik heb van mij enkele scripts ter lering ende vermaak op d:User:Edoderoobot en User:Edoderoobot staan. En wat links naar documentatie/boeken/etc. Edoderoo (overleg) 13 mrt 2018 21:15 (CET)

Bedankt! Daar zal wel iets nuttigs tussen zitten, is het niet voor nu dan wellicht voor het volgende script. –bdijkstra (overleg) 13 mrt 2018 22:14 (CET)
Toen ik drie jaar geleden er mee begon waren er haast geen goede voorbeelden, al helemaal niet voor WikiData. Hopelijk kun je hier een hoop puzzeltijd mee besparen. Edoderoo (overleg) 13 mrt 2018 22:18 (CET)

Hongaars[bewerken]

Mijn wijziging was in de hoop op minder fouten. Dat was dus ijdele hoop. Sorry. PAvdK (overleg) 23 mrt 2018 09:06 (CET)

In mijn ervaring met lint-fouten heb ik gemerkt dat het vaker fout gaat met HTML-tags dan met wiki-opmaak. Bovendien stond er op die regel geen lint-fout. Dus zelfs als je het correct had omgezet, was het een ongewenste wijziging. –bdijkstra (overleg) 23 mrt 2018 10:02 (CET)

Vet! (maar niet heus)[bewerken]

Dag Bdijkstra, na deze wijzigingen van jouw hand aan het sjabloon appendix, werden de links die erin als referentie werden opgegeven vet afgebeeld. De bedoeling was uiteraard dat slechts het kopje "bronvermelding" of welke kop ook maar gekozen werd, vet werd gezet, niet de inhoud van het sjabloon. Ik heb de wijzigingen daarom vooreerst helemaal ongedaangemaakt, me realiserend dat er dan een ongewenste situatie ontstaat met betrekking tot de houdbaarheid van de code. Er zal dus nader naar gekeken moeten worden, waarbij het doel is om een kopje vet weer te geven, maar de links die eronder worden geplaatst beslist niet. WIKIKLAAS overleg 3 apr 2018 01:20 (CEST)

Inderdaad, parameter 1 is alleen bedoeld voor het kopje. Na mijn wijziging ontdekte ik dat het in de praktijk lastig is om onjuist gebruik in de wikicode te vinden, dus ik heb dan wel een paar honderd gevallen verbeterd, maar ik kon niet echt een goed beeld krijgen van de omvang van het probleem. Dan is het inderdaad beter om even terug te draaien. –bdijkstra (overleg) 3 apr 2018 09:35 (CEST)
@Wikiklaas: Ik heb het sterke vermoeden dat bitbotje nu langs is geweest op de artikelen waar jij het fout zag gaan. –bdijkstra (overleg) 1 mei 2018 13:25 (CEST)
Dank voor het zoekwerk. Ik had me niet gerealiseerd dat het probleem in het onjuist gebruik van het sjabloon zat, en dat er dus in een serie artikelen iets moest veranderen. Ik weet jammer genoeg niet meer waar ik het begin vorige maand fout zag gaan. WIKIKLAAS overleg 1 mei 2018 15:05 (CEST)

Kladblok Laurier 'zijbalk Seksuele diversiteit'[bewerken]

Hoi Bdijkstra, waarom heb je mijn eigen kladblokje gewijzigd? Laurier (overleg) 4 apr 2018 08:52 (CEST)

Omdat je kladblok in categorieën stond die alleen bestemd zijn voor sjablonen in de sjabloonnaamruimte. –bdijkstra (overleg) 4 apr 2018 10:28 (CEST)
Ah, okee, bedankt dan! Laurier (overleg) 4 apr 2018 12:02 (CEST)

Bitbotje[bewerken]

Dag Bdijkstra, je bitbotje is de opmaak aan het veranderen, bijvoorbeeld bij Jan Lievens, Höfði en Hirschsprungske Samling. Misschien is dat nodig, ik weet dat niet, maar kun je me uitleggen waarom? Dankjewel, Hartenhof (overleg) 5 apr 2018 13:08 (CEST)

In principe verander ik niet de (bedoelde) opmaak, alleen de onderliggende opmaakcode. De in de bewerkingssamenvatting gelinkte categorie lintfouten geeft opmaakcode aan die in sommige gevallen twijfelachtig is en in sommige gevallen ronduit fout. Doorgaans is het resultaat toch oké vanwege speciale truken in de parser. Ik verander code die eigenlijk niet hoort te werken, naar code die wel hoort te werken. Dit maakt de opmaakcode in principe beter leesbaar, beter onderhoudbaar en gemakkelijker over te zetten naar andere parsers (bv. op andere wiki's). –bdijkstra (overleg) 5 apr 2018 13:40 (CEST)
OK, dank je wel voor de uitleg. Ik prefereerde kleinere letters voor foto-onderschriften, omdat die soms erg ver doorlopen naar onderen. Maar heel erg belangrijk is het niet. Met groet, Hartenhof (overleg) 5 apr 2018 13:48 (CEST)
Zoals ik al zei is het niet mijn bedoeling om het (bedoelde) opmaakresultaat te veranderen. Echter, na nog eens goed kijken in verschillende browsers zie ik nu tot mijn schrik dat Internet Explorer een andere interpretatie heeft van font-size:smaller dan de andere populaire browsers. De letters zijn wel iets kleiner dan normale tekst, maar duidelijk groter dan wat <small> doet. Zo te zien had ik beter font-size:85% kunnen gebruiken zodat het resultaat overal hetzelfde is. –bdijkstra (overleg) 5 apr 2018 14:53 (CEST)
Ik ziet het nu bij Leiden Collection, met goed resultaat. Dank je wel, met groet, Hartenhof (overleg) 5 apr 2018 16:29 (CEST)
Fijn. Dan zal ik het vanaf nu op die manier doen en later de bestaande gevallen corrigeren. –bdijkstra (overleg) 5 apr 2018 16:32 (CEST)
Uitgevoerd Uitgevoerdbdijkstra (overleg) 17 apr 2018 11:07 (CEST)
Dankjewel! Hartenhof (overleg) 17 apr 2018 12:05 (CEST)

Nieuwe knopjes[bewerken]

Gelukgewenst, Bdijkstra, met je nieuwe knopjes. Ik wens je wijsheid bij hun gebruik.

Met collegiale groet, Magere Hein (overleg) 6 apr 2018 17:22 (CEST)

Gefeliciteerd met het door de gemeenschap verleende vertrouwen.. Veel succes gewenst. Tulp8 (overleg) 6 apr 2018 17:35 (CEST)
Hey bdijkstra,
Hartstikke gefeliciteerd met je benoeming tot moderator. Om op start te komen kan je de moderatorhandeleiding doorlezen en bij vragen kan je altijd bij een van je collega-moderatoren terecht. Vergeet niet om een mailtje te sturen naar Gebruiker:Postmaster om ingeschreven te worden voor de modmail. In ieder geval veel plezier en succes gewenst als moderator!
Met vriendelijke groet, Kippenvlees (overleg‽) 6 apr 2018 17:37 (CEST)
Drie maal dank. Inmiddels ben ik ingeschreven. –bdijkstra (overleg) 6 apr 2018 19:35 (CEST)
Gefeliciteerd en succes! Trijnstel (overleg) 6 apr 2018 19:36 (CEST)
Gefeliciteerd. En meteen maar wat belangrijk voedsel meegenomen. Je kan geen moderator werk verrichten op een lege maag.
Stroopwafels.jpg
Mbch331 (Overleg) 6 apr 2018 19:44 (CEST)

Vast wel[bewerken]

Dit zul jij vast wel weten. Pagina's zoals [Gebruiker:Naam/Kladblok] zijn blijkbaar automatisch voorzien van een onzichtbaar sjabloon o.i.d. want ik zie als categorie "Wikipedia:Niet te indexeren pagina's". Echter bij pagina's zoals [Gebruiker:Naam/Kladblok/Item] zie ik die categorie niet. Die worden dus wel geïndexeerd? VanBuren (overleg) 9 apr 2018 21:13 (CEST)

Bij mijn kladblok is dat niet zo, dus dat moet een zichtbaar sjabloon zijn. Bij welke pagina('s) zie je die categorie? –bdijkstra (overleg) 9 apr 2018 21:30 (CEST)
Bij mijn eigen staat het onderaan als een "verborgen categorie". Ik zie "Verborgen categorieën weergeven" omdat ik dit in mijn "Voorkeuren/Uiterlijk/Geavanceerde instellingen" heb aangevinkt. De vraag hierboven ook voor andere varianten zoals [Gebruiker:Naam/Klad] of [Gebruiker:Naam/Klad23]. Ik vraag dit vooral omdat heel veel mensen artikel aanmaken op een "klad"pagina waarvan de inhoud niet vindbaar zou moeten zijn totdat het artikel is goedgekeurd. VanBuren (overleg) 9 apr 2018 21:47 (CEST)
Gebruiker:VanBuren: Je gebruikt op je kladblok: {{Hoofding gebruikerskladblok}}, waarin die Categorie waarschijnlijk wordt opgeroepen door het gebruik van __NOINDEX__ die in dat sjabloon verwerkt zit.
Ik vermoed (maar dat kan Romaine of zo wel bevestigen of ontkrachten) dat in de Wiki-css/js dit zo is ingesteld.  •   Rodejong   ✉️ 👀 → 🕘  9 apr 2018 21:58 (CEST)
@Romaine: Zou jij dit kunnen bevestigen dan wel ontkrachten?  •   Rodejong   ✉️ 👀 → 🕘  9 apr 2018 22:00 (CEST)
Wiki-css/js heeft daar niks mee te maken. __NOINDEX__ is een ingebouwd magisch woord dat die categorie invoegt. –bdijkstra (overleg) 9 apr 2018 22:03 (CEST)
Ah, kijk. Dan weten we dat ook weer. (Overigens is het aan te raden om geen zelfsluitende tags meer te gebruiken, daar binnenkort het gebruik daarvan in de mediawikiprogrammatuur wordt uitgeschakeld door Mediawiki. Zie TechNews.  •   Rodejong   ✉️ 👀 → 🕘  9 apr 2018 22:07 (CEST)
Praat alsjeblieft niet zo'n onzin Rodejong. De meeste zelfsluitende tags zijn prima, alleen sommige niet. Zie mw:Help:Extension:Linter/self-closed-tag voor wat wel en wat niet. –bdijkstra (overleg) 9 apr 2018 22:12 (CEST)
Sorry als ik op je tenen getrapt heb. Ik zei enkel wat mij eerder was uitgelegd. Als ik iets verkeerd begrepen heb, dan spijt me dat, maar daar hoef je niet mijn hoofd vor af te bijten hoor :)  •   Rodejong   ✉️ 👀 → 🕘  9 apr 2018 23:33 (CEST)
Voor de duidelijkheid: html kende in het verleden twee soorten tags: degene die alleen in paren voorkwamen, zoals <div>...</div>, en degene die solo werden gebruikt, zoals <br>. Op zeker moment kwam er een nieuwe specificatie (ik weet niet meer uit m'n hoofd of dat xhtml was, of html4) waarin werd geregeld dat ALLE tags in het vervolg gesloten moesten worden. Voor de gepaarde tags veranderde er niks; tags als de break moesten voortaan zelfsluitende tags worden in de vorm van <br />. Nu wijst het zich verder vanzelf: zelfsluitende tags als <br />, <br/> zijn prima; maar de sluittags van de gepaarde mogen niet op die manier in de code staan. Dus </div> is een correcte sluittage, maar <div/> is een fout: die laatste veronderstelt een zelfsluitende tag te zijn, maar een zelfsluitende div heeft helemaal geen betekenis, en is dus zowel logisch als syntactisch fout. De nieuwe software is op dit punt terecht niet meer vergevingsgezind, en deze foute zelfsluitende tags moeten dus gecorrigeerd worden. Dat corrigeren houdt onder meer in dat er gecontroleerd moet worden of de fout afgesloten div eigenlijk wel ergens geopend werd. De tag moet er immers een zijn van een paar. WIKIKLAAS overleg 10 apr 2018 01:18 (CEST)
@Rodejong: excuses aanvaard. Misschien was je verkeerd geïnformeerd, dat kan, maar als je iemand de les wil lezen kan je maar beter zorgen dat je informatie correct is (geverifieerd hebt) en zelf ook snapt. Wat je denk ik niet wist, is dat ik het afgelopen half jaar veel bezig ben geweest met zelfsluitende tags en vele andere Lintfouten. Ook als je over css/js begint terwijl dat helemaal niet in the picture is, dan komt dat helemaal niemand ten goede. –bdijkstra (overleg) 10 apr 2018 09:44 (CEST)

Dit gaat fout. Mijn vraag nogmaals: zijn deze pagina's [Gebruiker:Naam/Kladblok] automatisch voorzien van "noindex", of worden die wel door googles en bings opgenomen in de zoekresultaten? VanBuren (overleg) 9 apr 2018 22:27 (CEST)

Zoals impliciet al gezegd: niet automatisch, maar wel handmatig door sjabloon:Hoofding gebruikerskladblok. –bdijkstra (overleg) 9 apr 2018 22:39 (CEST)

Nog eens: zelfsluitende tags[bewerken]

Dag bdijkstra, deze vraag moet een kolfje naar jouw hand zijn. Bij de introductie van de zelfsluitende tags werd geadviseerd om ze te noteren met een spatie voor de slash, dus <br /> in plaats van <br/>. Weet jij of dat advies nog steeds van kracht is, met andere woorden, of het een vorm van zindelijk coderen is om die spatie nog te plaatsen, of is het advies bij jouw weten inmiddels achterhaald? Hartelijke groet, WIKIKLAAS overleg 17 apr 2018 22:48 (CEST)

Geen idee waar dat advies vandaan kwam of wat de achterliggende reden was. Ikzelf vind met spatie iets beter leesbaar op lange regels. –bdijkstra (overleg) 17 apr 2018 23:01 (CEST)
De achterliggende reden was indertijd dat sommige "interpreters" moeite hadden met de code zonder de spatie. Netjes coderen (met spatie) betekende dus dat je rekening hield met interpreters die de code zonder de spatie niet goed aankonden (het was uiteraard vooral "netjes" coderen omdat er een advies lag om dat zo te doen). Ik begrijp uit je antwoord dat er bij jouw weten geen nieuw "advies" is om de spatie achterwege te laten, maar dat het eerdere advies je ook onbekend was. Ik vroeg ernaar omdat ik geneigd ben om in zelfsluitende tags zonder spatie de spatie toe te voegen op basis van het mij bekende advies. Als het heel dringend wordt (lees: iemand doet een beroep op BTNI), duik ik er nog wel een keer dieper in. WIKIKLAAS overleg 18 apr 2018 00:37 (CEST)
Ik meen mij te herinneren dat Romaine ooit iets van die strekking heeft gezegd, maar volgens mij zonder een bron te geven. Sinds 2012 is HTML5 de norm en daarin zijn <br>, <br/> en <br /> allemaal correct en gelijkwaardig (wat niets zegt over de leesbaarheid van de wikicode). –bdijkstra (overleg) 18 apr 2018 08:54 (CEST)

Ik weet niet...[bewerken]

Hoi. Voor de duidelijkheid: ik weet niet is bedoeld als een vriendelijke manier om te zeggen ik weet wel of ik vermoed sterk. Knipogende smiley Bedankt voor je linkspecificatie op de Zeuspagina. Groet. — Zanaq (?) 19 apr 2018 11:39 (CEST)

Module:Wd bewerkingen[bewerken]

Hoi, ik zag je bewerkingen m.b.t. de coordinates precision op Module:Wd. Heb je misschien een voorbeeld van waar het mis gaat? Alvast bedankt. Thayts (overleg) 24 apr 2018 18:54 (CEST)

Oh, en in wat voor browsers werkt font-size:smaller niet naar behoren? Thayts (overleg) 24 apr 2018 18:56 (CEST)

Op District Revdinski gaat het mis met de coördinaten. Vóór mijn work-around stond er in de infobox een rode foutmelding. Wat er nu staat is niet veel beter, en ik heb geen idee waar die "nff" vandaan komt.
Zie hier een overzichtje met een aantal browser(engine)s. Zoals je ziet is in ieder geval IE problematisch. Het verschil met gewone tekst is veel te klein. –bdijkstra (overleg) 24 apr 2018 19:26 (CEST)
Ik heb het probleem gedebugged en het blijkt dat in dit geval de precisie "ongespecificeerd" is oftewel 0. Hierdoor werd er gedeeld door 0, wat zorgde voor een 'inf' (infinity) resultaat, wat deels de "nff" verklaart. Ik heb het nu opgelost door een check uit te voeren of de precisie 0 is en in dat geval 1/3600 te zetten (een boogseconde), waar Wikidata ook op terugvalt. Thayts (overleg) 25 apr 2018 21:23 (CEST)
Fijn! Dat lijkt me inderdaad de beste oplossing. –bdijkstra (overleg) 25 apr 2018 21:32 (CEST)

Minteken[bewerken]

Hallo Bdijkstra. Hartelijk dank voor je recente hulp op Waterstofchloride. Ik zie dat je een ander minteken gebruikt dan ik. Ik gebruik "gewoon" het minteken op mijn toetsenbord, waar vind ik het minteken dat jij gebruikt? Is dat een speciale ASCII-code? Ik zie dat teken vaker, vooral als koppelteken tussen geboorte- en sterfdata van personen, en vroeg me al een tijdje af waar ik het kon vinden. Met vriendelijke groet, JanCK Sinnbild Radfahrer, StVO 1992.svg (overleg) 2 mei 2018 10:14 (CEST)

Op je toetsenbord zit wat officieel "koppelteken/minteken" heet (U+002D). Tenzij echt een koppelteken bedoeld wordt, vermijd ik het liever, omdat het eruit ziet als een koppelteken en omdat het 'echte' minteken even lang is als het plusteken. In ASCII zit geen minteken, maar in Unicode wel: U+2212 "−" minteken, te vinden in wikitekst-editor onder Speciale tekens – Symbolen (tussen "±" en "×"). In datzelfde blok, tussen "m³" en "—" vind je ook U+2013 "–" half kastlijntje, wat o.a. gebruikt wordt tussen data. Met een proportioneel lettertype dat groot genoeg is, zie je dat het kastlijntje iets dunner is en lager dan het minteken: –−+. Ook spraaksoftware reageert anders op de verschillende streepjes. –bdijkstra (overleg) 2 mei 2018 10:36 (CEST)
Bedankt voor je duidelijke en uitgebreide uitleg. Het was dus nog ingewikkelder dan ik dacht. Ik heb de tekens even gekopieerd naar Word en flink opgeblazen en dan zie je inderdaad duidelijk het verschil. Met vriendelijke groet, JanCK Sinnbild Radfahrer, StVO 1992.svg (overleg) 2 mei 2018 11:28 (CEST)
Ik voer een half kastlijntje in met Alt-0150 (alt-toets ingedrukt houden, 0150 intoetsen op het numerieke deel van je toetsenbord). Ik doe dat zo vaak dat ik de code kan onthouden. WIKIKLAAS overleg 2 mei 2018 19:47 (CEST)

Sjabloon:Infobox beeld[bewerken]

Beste Bdijkstra, ik merk dat er door jouw wijzigingen in de infobox een probleem ontstaan is met de hoogtecoördinaten. Een komma wordt niet meer herkend en dat geeft foutmeldingen, zie o.a. William the Hippopotamus. Ik kan niet meteen zien hoe dit moet opgelost worden. Kijk jij dit even na? KroySquare.jpgDirkVE overleg 5 mei 2018 09:12 (CEST)

Opgelost. De wikisoftware werkt met een decimale punt, ik had geen rekening gehouden met fracties. –bdijkstra (overleg) 5 mei 2018 12:06 (CEST)
Duim omhoog Bedankt! KroySquare.jpgDirkVE overleg 6 mei 2018 09:12 (CEST)

Andes[bewerken]

Hoi Bdijkstra, zo net zie ik dat de wijzigingen die ik had aangebracht op de pagina over de Andes zijn terug gedraaid. De reden is niet duidelijk. Ik heb gisteren ook een bericht achtergelaten op de overleg pagina met de suggestie dat deze lijst van bergen zijn eigen pagina verdient. Het is te groot om makkelijk te bewerken en het voldoet om als lijst apart weergegeven te worden. mvg Arnoud van Dillewijn (overleg) 6 mei 2018 17:26 (CEST)

Hoi Arnoud, in mijn bewerkingssamenvatting schreef ik hiermee creëerde je ongeldige bestandsverwijzingen. Je had achter elk getal een 'm' gezet, inclusief de getallen in de bestandsnamen van de afbeeldingen. Blijkbaar heb je voor het opslaan niet even snel de lijst doorgekeken, anders had je wel gezien dat sommige plaatjes waren vervangen door rode tekst. En blijkbaar heb je na het opslaan ook niet even gecontroleerd op verborgen categorieën. Oppassen dus wanneer je tekst vervangt. Helaas was het niet mogelijk om die ene wijziging van 3 ongedaan te maken. Het lijkt me overigens prima om de lijst een eigen pagina geven. –bdijkstra (overleg) 6 mei 2018 20:24 (CEST)
Het is een beest van een lijst. Lastig te controleren of alles goed gaat. Ik zal kijken naar de mogelijkheden voor een aparte pagina voor de lijst. Ik zit te denken om de lijst op te breken in verschillende hoogtes en om andere pagina's te maken per land. Dat zou voldoende moeten zijn. Arnoud van Dillewijn (overleg) 6 mei 2018 23:37 (CEST)
Het is gelukt om de hele lijst te verplaatsen. Als er dingen zijn die beter kunnen dan hoor ik dat graag. Arnoud van Dillewijn (overleg) 18 mei 2018 16:53 (CEST)
Fijn, een stuk beter hanteerbaar nu dat ie ook is opgeknipt. –bdijkstra (overleg) 18 mei 2018 17:07 (CEST)
775 bergen.. dat zijn er wel veel. Er zouden er nog wel een aantal bij kunnen komen of juist minder. Er zitten best veel fouten nog in. Goed dat je de namen vertaald hebt. Het is letterlijk de lijst van de Engelse pagina. Wat opvalt is dat er veel meer bergen van Peru in staan en er zijn minder vierduizenders dan vijfduizenders. Maar daar ga ik niet te veel tijd aan besteden. Ik kijk wel naar de andere lijsten die gemaakt heb per land. Een aantal bergen mist nog een link met deze lijst. De bergen die geen eigen pagina hebben, ga ik niet toevoegen aan de landen lijsten. Dan wordt zo'n lijst juist onhandelbaar en onoverzichtelijk. En hetzelfde geld voor de verschillende hoogtes. De bergen met pagina krijgen hierin voorrang. Arnoud van Dillewijn (overleg) 18 mei 2018 17:34 (CEST)
775 is nog niks. Ik heb even op Wikidata gekeken, daar staan er 12783 bergen in de Andes van 4000m of hoger, waarvan iets van 750 met zowel coördinaten als een plaatje. –bdijkstra (overleg) 18 mei 2018 19:12 (CEST)

Scheldetol[bewerken]

Beste BDIJKSTRA, De link bestaat wel als doorverwijzing, maar de pagina waar hij naar verwijst ('Sluiting' van de Schelde) heeft niets met de Scheldetol te maken. De Scheldetol was de historische Zeeuwse tol die vanaf de middeleeuwen tot 1863 in verschillende vormen op verschillende plaatsen werd geheven. Dat hij een onderdeel zou zijn de 'sluiting' van de Schelde is een misverstand. Hij bestond al daarvoor en ook nog daarna. Misschien kan iemand die het eens goed wil uitzoeken er een (aparte) pagina van maken. De link met 'Sluiting' van de Schelde kan dus beter verwijderd worden; ze geeft alleen verwarring.TolmaPolla (overleg) 10 mei 2018 20:25 (CEST)

Kort geleden stond er nog een hoofdstuk "Scheldetol" in sluiting van de Schelde. Kan je die verwijderde tekst niet gewoon op Scheldetol plaatsen? Zo nee, dan kan die redirect beter verwijderd. –bdijkstra (overleg) 10 mei 2018 20:43 (CEST)

Eurovisiesongfestival 2019[bewerken]

Hey,

Ik vind het absoluut niet kunnen, dat je de pagina Eurovisiesongfestival 2019 beveiligd terwijl ik hem heb aangemaakt. Ik had deze pagina aangemaakt en ik beslis de regels over mijn aangemaakte pagina! Dat is echt frustrerend!!!!
Bovenstaande, niet middels vier tildes (vier keer '~') ondertekende opmerking is geplaatst door FamilieFan2018 op 13 mei 2018 om 18:02 uur.

Geachte FamilieFan, een kleine grammaticale opmerking: in deze zin moet 'beveiligt' eindigen op een t, het is immers derde persoon enkelvoud en niet een voltooid deelwoord. Met vriendelijke groet, Bob.v.R (overleg) 13 mei 2018 18:09 (CEST)
Beste FamilieFan2018, blijkbaar heb je een verkeerd beeld over Wikipedia. Ik kan me voorstellen dat dit frustraties oplevert. Misschien kan je beter eerst de informatie raadplegen die op je overlegpagina is geplaatst, voordat je tegen nog meer frustraties oploopt. –bdijkstra (overleg) 13 mei 2018 18:28 (CEST)

Aangepaste kleuren in diffs (was: "Engelse komma")[bewerken]

Dag bdijkstra,

Ik zag bij toeval dat je in een artikel een "Engelse komma" (bekend als "Oxford Comma" of "serial comma") verwijderd lijkt te hebben. Ik kon echter (zelfs in de betreffende diff) niet vinden welke komma nou waar precies verwijderd is, maar wilde je zekerheidshalve toch even laten weten dat volgens http://taaladvies.net/taal/advies/vraag/467/komma_voor_en/ deze komma (tegenwoordig) niet (meer) per se fout en wordt bij lange opsommingen of ter verduidelijking gewoon goed gerekend wordt, vooral als hierdoor een verkeerde interpretatie mee wordt vermeden (zoals in deze wellicht befaamde casus) en in het Nederlands in het algemeen steeds vaker gebruikt wordt. Dit voor het geval dit je nog niet bekend was; het is dus géén uitspraak of betwisting door mij of de komma waar het hier om gaat nou wel of niet terecht is verwijderd (om de doodeenvoudige reden dat ik kennelijk te kippig ben om te zien welke waar is weggehaald) en ik heb je ook nooit eerder verkeerde wijzigingen zien maken, maar wilde je – wellicht geheel overbodig als het je al bekend is, en met de beste bedoelingen – toch even op die link van taaladvies.net wijzen. Met vriendelijke groet -- martix (overleg) 21 mei 2018 14:19 (CEST) N.B.: ik kan het niet uitstaan dat ik niet kan zien/vinden om welke komma het gaat (welke is weggehaald); zou je me wat nader kunnen duiden om welke zin het precies gaat (terwijl ik mijn ogen laat opmeten bij de opticien)? -- martix (overleg) 21 mei 2018 14:19 (CEST)

Hoi martix, ik heb geen oxfordkomma verwijderd, maar een komma na een werkwoord die niet een deelzin afbakende, wat in het Engels regelmatig voorkomt. Het betrof hier de komma na "noordelijke staten waren". Overigens speur ik zelf ook wel eens naar leestekens in het verschil. Misschien een idee om een rand toe te voegen in de persoonlijke CSS:
standaard: noordelijke staten waren, volgens de federale wetten verplicht ontsnapte slaven uit
te leveren en [[premiejagers]] toe te laten om ontsnapte slaven op te sporen.
extra rand: noordelijke staten waren, volgens de federale wetten verplicht ontsnapte slaven uit
te leveren en [[premiejagers]] toe te laten om ontsnapte slaven op te sporen.
bdijkstra (overleg) 21 mei 2018 15:02 (CEST)
Dank je, nu zie ik 'm ook! (Als het een tussen-zin of bijvoeglijke bepaling zou zijn geweest tusssen twee komma's dan zou het wel geoorloofd zijn geloof ik). Het probleem met het 'spotten' is vooral de lichte, zachtgele kleur aan "min-kant"; als dat (net als in de hovers/floats (als je die instelling aan hebt staan) boven de diffs – waar ik het overigens deze keer ook niet zag omdat überhaupt het te klein was – een zacht-rode/half transparant-rode kleur zou zijn, zou het – ook bij smalle tekens – beter opvallen dan het lichte zachtgeel dat het nu is. Ik denk dat die randen in het voorbeeld hierboven bij elk verschilletje me te druk worden; zou misschien de kleur die aan de linkerkant gebruikt persoonlijk in te stellen zijn? Hoe dan ook, hartelijk dank (weer) voor de toelichting! -- martix (overleg) 21 mei 2018 15:37 (CEST)
Ja, net als het toevoegen van randen kan je ook de gebruikte kleuren overschrijven. Bv. met
.diff-deletedline .diffchange {
    background: #fe7768;
}
(niet getest). –bdijkstra (overleg) 21 mei 2018 16:02 (CEST)
Wow, dat werkt als een naaimachientje, al heb ik er wel #ffcdb2 can gemaakt, (een paar slagen lichter omdat anders het (verwijderde) leesteken weer zo lastig te zien was, maar deze kleur heeft aanmerkelijk meer contrast met het wit dan het standaard zachtgeel en maakt kleine (verwijderde) tekens/letters stukken gemakkelijker te spotten, zeer bedankt! (Ik heb het aangebracht in de (hiervoor nog lege) "Gedeelde CSS/JSON/JavaScript voor elke vormgeving" common.css (de middelste keuze in de bovenste sectie van het "Uiterlijk"-tabblad), niet de onderste voor alle wiki's), ik ga ervan uit dat dit een tweak is *bovenop* al mijn andere instellingen die met knopjes en vinkjes zijn aangepast, (dus een aanvulling en geen vervanging?) en dat ik niet óók nog een standaard css template erin moet zetten, en dat het feit dat de common.css nu verder geen andere instellingen/preferences bevat, daarmee niet allerlei andere instellingen ongedaan zijn gemaakt/zijn uitgeschakeld? (ik ben weliswaar IT-er, maar in de hoek van IT-infrastructuur, op en boven HTML-niveau houdt het bij mij snel op namelijk). Nogmaals hartelijk dank voor de tip! -- martix (overleg) 21 mei 2018 17:59 (CEST)
Graag gedaan. Je persoonlijke CSS wordt als laatste geladen, dus bovenop eerder geladen modules. Het is een aanvulling van de totale CSS-code, waarmee je een enkele waarde vervangt. –bdijkstra (overleg) 21 mei 2018 18:20 (CEST)
Ik zag dit overleg doordat ik deze pagina nog op mijn volglijst had staan vanwege eerder overleg (en ik blijf 'm volgen ook: weer een geweldige tip! Bedankt bdijkstra). Ik heb "stiekem" even gekeken in je persoonlijke CSS, martix, en de inhoud gekopieerd naar de mijne. Ik hou me veel bezig met vandalismebestrijding en anoniemencontrole en zit dus vaak naar diffs te kijken. Wat werkt dit dan prettig, zeg. Nogmaals dank voor de tip. Met vriendelijke groet, JanCK Sinnbild Radfahrer, StVO 1992.svg (overleg) 22 mei 2018 13:32 (CEST)
Ik vind het (ten opzichte van het slechte contrast van het zachtgeel met wit (bij smalle tekens)) zelfs zó'n enorme verbetering dat het eigenlijk zonde is wanneer dit juweeltje van een tip beperkt blijft op deze OP; is er niet een algemene(re) pagina met "tips & tricks" of zo waar deze tip/suggestie opgenomen kan worden, of kan misschien ergens de suggestue gedaan worden dat het zelfs dat het de de standaard kleur wordt (in diffs) achter de tekst die weggehaald is? -- Met vriendelijke groet -- martix (overleg) 22 mei 2018 19:47 (CEST)
Als je nog een kleurwaarde verzint voor .diff-addedline kan je de code ergens toevoegen in de scriptbibliotheek en vervolgens eventueel er de aandacht op vestigen in de kroeg. Na een stemming kan het worden toegevoegd aan MediaWiki:Common.css. –bdijkstra (overleg) 22 mei 2018 23:25 (CEST)
Ah, (ik gebruik deze ruimte heel even als notitieblokje) wat mij betreft voldoet de huidige kleur voor "added-line" wel, maar dat blijkt (na sampling) #cfe7ff te zijn; deze kleur blijkt een luminance van 90% te hebben. De zacht-rode kleur waar ik (visueel) op uit was gekomen (#ffcdb2) blijkt een luminance van 86% te hebben, als die corrigeer om ook 90% te zijn (net als de standaard zacht-blauwe kleur achter added-lines), dan komt de gecorrigeerde waarde daarvan uit op #ffd8bb (i.p.v. #ffcdb2); het scheelt slechts 4% maar op die manier is er wel consistentie natuurlijk in de luminance van beide achtergrondkleuren. Ik probeer het dadelijk nog even uit of de 4% lichtere kleur nog voldoende contrast oplevert (zoals in de bewerkingsgeschiedenis van mijn common.css te zien valt, leverde een eerdere "verlichtingsslag" (een relatieve verhoging) van 25% – visueel/op het oog – een té lichte kleur op om voldoende contrast te tonen (bij smalle tekens), zodat het alsnog lastig werd de dunne tekens te spotten, en daarom veranderde ik die laatste relatieve verlichting van 25% naar 10%; ik moet dus even bekijken wat deze absolute verlichting van 4% gaat opleveren.
Ik zal daarna je advies opvolgen om het aan die bibliotheek toe te voegen. Ik probeer eigenlijk echter als het even kan uit "De Kroeg" weg te blijven, kan ik het niet aankaarten in "Het Redactiekanaal? Moet het echt per se in de Kroeg? Alvast weer bedankt voor je antwoord, en met vriendelijke groet -- martix (overleg) 23 mei 2018 17:29 (CEST)

──────────────────────────────────────────────────────────────────────────────────────────────────── (Excuses voor het gebruik van al deze ruimte op je OP, maar:) nu kan ik eigenlijk niet kiezen tussen met luminance 86%:

https://1drv.ms/u/s!AoYOgJGbDKORmGdmSeU2jszwzXdG

en deze met luminance 90%:

https://1drv.ms/u/s!AoYOgJGbDKORmGbbLk3rJg88dqmv ;

@bdijkstra, @JanCK Fietser: mag ik jullie vragen om een oordeel welke van de twee duidelijker/beter is (ook met inachtname van de (standaard)kleur voor added-lines)? (ik had als inline image willen toevoegen, maar wist niet welke commonscat te gebruiken voor (voorbeeld)afbeeldingen die beperkt blijven in GNR/hoe of waar ik de afbeeldingen lokaal op alleen nl.wikipedia.org kon uploaden, vandaar deze links naar een viewer die het waarschinlijk wel groter dan op 100% laat zien). Alvast bedankt, -- martix (overleg) 23 mei 2018 18:18 (CEST)

Dat verschil is inderdaad heel subtiel. Als (met de nadruk op als) ik zou moeten kiezen, heeft de eerste, iets donkerder kleur, mijn voorkeur, maar dat zeg ik alleen maar omdat ik ze door snel heen-en-weer te klikken met elkaar kan vergelijken. Als je me alleen de laatste optie had gegeven, had ik waarschijnlijk geroepen: prima. Groet, JanCK Sinnbild Radfahrer, StVO 1992.svg (overleg) 23 mei 2018 18:22 (CEST)
Hoe dit soort kleine verschillen eruit zien, hangt heel erg af van iemands ogen, het display en de instellingen daarvan. Er is geen perfecte kleurwaarde, en dat is nou juist het fijne van deze mogelijkheid voor individuele gebruikers om zelf een waarde te kiezen. Het enige dat w.m.b. van belang is voor in de scriptbibliotheek, is dat de voorbeeldwaarde duidelijk donkerder is dan de standaardwaarde. –bdijkstra (overleg) 28 mei 2018 09:18 (CEST)
Dat is ook zonder minder waar – hoewel ik uiteindelijk persoonlijk tot dezelfde conclusie kwam als Jan CK Fietser, dat de nét iets donkere tint, met name bij tekens als punten, apostrofs en komma's beter leek en ik overweeg het blauw ook wat donkerder te maken (naar lum. 86%), maar – zodra je de helderheid en contrast van de monitor verandert, verandert de effectiviteit van de instellingen navenant mee. En volgens mij is ook nog nooit vastgesteld dat verschillende mensen altijd dezelfde perceptie van dezelfde kleur hebben, en dan zijn er mensen – zoals ook in de uitleg in de scriptbibliotheek genoemd – die bijvoorbeeld rood- of blauwtinten (of beiden) niet kunnen zien, voor wie andere kleuren (en contrastwaarden) weer beter zijn, en dat zal voor elk persoon een andere combinatie van kleuren en intensiteit/luniniscentie zijn.
(Wederom) dank voor het bondiger maken van de tekst die ik had geplaatst in de scriptbibliotheek, ik weet dat ik eigenlijk zelf vóór publicatie eerst al een keer moet herlezen en schrappen en daarna alsnog iemand anders de kam erdoorheen moet laten halen want ik kan erg lang van stof zijn in de "eerste versie". Maar dat is nu dan aangepast en duidelijker gemaakt ná publicatie, en het is het resultaat dat telt. Nogmaals dank! -- martix (overleg) 28 mei 2018 13:44 (CEST)

Beveiligde pagina's[bewerken]

Hoi Bdijkstra, je hebt recent het artikel Stemming van Pythagoras voor de periode van 1 maand beveiligd maar dat zo te zien nog niet gemeld op Wikipedia:Beveiligde pagina's. Je bent nog niet zo lang moderator dus ik neem aan dat je niet gerealiseerd had dat het de bedoeling is dergelijke beveiligingen daar te melden. Als ik vroeger zo'n omissie zag paste ik dat zelf aan maar omdat ik geen moderator meer ben kan ik je daar niet meer bij helpen. - Robotje (overleg) 27 mei 2018 15:33 (CEST)

Bedankt! Ik heb ook gelijk een aantal andere beveiligingen toegevoegd die nog niet verlopen waren. –bdijkstra (overleg) 27 mei 2018 15:52 (CEST)
Jij ook bedankt. - Robotje (overleg) 27 mei 2018 17:10 (CEST)

Lint[bewerken]

Hoi Bdijkstra, volgens Rodejong worden alle lintfouten op Speciaal:LintErrors/bogus-image-options een problemen bij overstap van Tidy naar RemexHtml. De technici van Mediawiki hebben met Parsing/Replacing Tidy#Detailed information about what to fix aangegeven wat er aangepast moet worden als je van Tidy overstapt op RemexHtml. Daarbij staan tabellen met in de rechterkolom een 'Linter category'. De Linter categorie 'bogus-image-options' komt daarin niet voor. Rodejong weet zeker dat al die fouten in die categorie een probleem worden maar kan mij niet uitleggen waar ik meer kan vinden over de denkfout bij de technici van Mediawiki. Kun jij eens reageren bij Wikipedia:SHEIC#Lint. Hopelijk wordt het dan duidelijker. - Robotje (overleg) 1 jun 2018 16:56 (CEST)

Break-tag[bewerken]

Hallo Bdijkstra. Ping werkt bij mij niet doordat ik een sjabloonhandtekening gebruik, dus maar even op deze manier. Ik heb je ooit iets zien opmerken over </br> vs <br />. Een soortgelijke vraag werd op deze overlegpagina gesteld. Ben je in de gelegenheid daar te reageren? Hartelijk dank en met vriendelijke groet, JanCK Sinnbild Radfahrer, StVO 1992.svg (overleg) 15 jun 2018 12:14 (CEST)

Weet je het zeker?[bewerken]

Hallo Bdijkstra, bij de laatste versie (die stond nog in mijn scherm) stond onderin toch echt een toegevoegd kopje. Wil je dit nog eens nakijken? Mvg, Richard kiwi Overleg 21 jun 2018 16:51 (CEST)

Dat kopje stond er inderdaad, maar dat had die gebruiker niet toegevoegd. We kunnen niet met zekerheid zeggen dat diegene dat onderste kopje gezien heeft. –bdijkstra (overleg) 21 jun 2018 17:02 (CEST)