Wikipedia:SHEIC

Onderwerp toevoegen
Uit Wikipedia, de vrije encyclopedie
Zie WP:ICT
SHEIC
SHEIC
SHEIC

Dit is een overlegruimte voor mensen die op de Nederlandstalige Wikipedia tijd willen besteden aan informatica, automatisering, andere technische zaken van de wiki (zoals sjablonen) en verwante onderwerpen. Dit is tevens een centrale plaats ter bespreking en afstemming van artikelen, categorieën, portalen, lijsten en andere zaken met betrekking tot informatica, automatisering en wat dies meer zij. Let op dat er een zekere overlap is met de Helpdesk, stel voor dringende zaken je vraag ook daar.


Naar inhoud   Naar onder   Nieuw onderwerp toevoegen   Archief   Beheerpagina's


Semi-automatische controle op plagiaat[bewerken | brontekst bewerken]

Ik begeleid wekelijks nieuwe gebruikers, en ik moet hen telkens (streng) waarschuwen voor plagiaat. Eenvoudige plagiaatcontrole die beschikbaar is voor iedereen zou het leven van Wikipedianen (en mezelf als lesgever) eenvoudiger maken. Ik vind de copyvio-tool heel handig, maar dit blijft omslachtig om te gebruiken. Deze optie kan via een enkele "Common" CSS instructie heel eenvoudig worden geactiveerd. Het is dan via de "Geschiedenis" van de artikelen beschikbaar. Op de Franstalige Wikipedia is dit standaard beschikbaar voor alle gebruikers, zelfs bij anoniem lezen. Maar het is niet standaard aanwezig op de Nederlandstalige Wikipedia. Dit werkt overigens in alle naamruimten (ook in de gebruikers-pagina waar vaak lemma's worden voorbereid). Een bijkomend voordeel is dat ook pagina-statistieken beschikbaar zijn. Het volstaat om de volgende lijn toe te voegen in Common.css:

#history-toolbox { display: block !important; }

Geertivp (overleg) 21 mrt 2024 22:42 (CET)Reageren

Tech News: 2024-13[bewerken | brontekst bewerken]

MediaWiki message delivery 25 mrt 2024 19:53 (CET)Reageren

Accountaanmakers[bewerken | brontekst bewerken]

Beste collega's

Enkele medegebruikers hebben account creator rechten op deze wiki. Dis een zeer kleine groep gebruikers (die regelmatig helpen bij schrijfevenementen etc.) die dit recht gekregen hebben om het aanmaken van accounts voor bv. schrijfevenementen te vereenvoudigen. Onlangs was er een schrijfevenement waarbij er enkele problemen optraden, die dringend een oplossing behoefden. Tijdens het evenement bleek dat de IP's onder een van de vele blokkades voor open proxies vielen. Daardoor waren er problemen om voor nieuwe gebruikers accounts aan te maken op nlwiki (merk op dat ook gebruikers die al bekend waren bij de Engelse wiki... niet konden inloggen bij ons). De problemen zijn toen opgelost geraakt omdat er toevallig een mod gevonden werd die een en ander kon rechttrekken. Om dit euvel te verhelpen, zou ik voorstellen om accountaanmakers voortaan toe te laten om zelf dit soort problemen op te lossen. Concreet zou ik voorstellen om hen volgende mogelijkheden te geven:

  • ipblock-exempt - zorgt ervoor dat deze gebruikers sneller hulp kunnen inseinen indien zou blijken dat de locatie van het event bv. achter een harde proxyblok zit. Ik merk hierbij terloops op dat de huidige accountaanmakers bijna allemaal dit recht al via een andere weg hebben verkregen en dat de drempel voor zo'n exempt lager ligt dan voor het bitje van accountaanmaker.
  • centralauth-createlocal - met dit recht kunnen de accountaanmakers eenvoudig accounts toevoegen op nlwiki (van mensen die bijvoorbeeld eerst elders een account hadden aangemaakt - dit bleek tijdens een vorig schrijfevenement problematisch, daarom dit voorstel om deze mogelijkheid toe te voegen, zodat er niet altijd een mod nodig is).
  • oathauth-enable - hen de mogelijkheid geven om 2FA in te schakelen. Indien dit recht toegevoegd zou worden, zal dit leiden tot een verhoogde veiligheid van de betreffende accounts.

Ik hoor graag de visie van andere gebruikers aangaande dit voorstel. Daniuu (overleg) 26 mrt 2024 19:20 (CET)Reageren

Steun Steun - Ik was die ene mod waar Daniuu het over heeft en heb het probleem samen met ThamaraGroenleer opgelost. Als accountaanmaker, zou ze mij – of welke mod dan ook – hiervoor niet nodig moeten hebben, daarom steun ik dit voorstel van harte. Drummingman (overleg) 26 mrt 2024 19:47 (CET)Reageren

Ik vind het prima hoor.... maar is het niet veel eenvoudiger om de proxyblokkade tijdelijk op te heffen tijdens zo een schrijfbijeenkomst? Ik hoor niet bij dit selecte clubje, en heb toen ik er mee te maken had de proxy een aantal uurtjes gedeblokkeerd (terwijl ik dat eigenlijk niet mocht doen als checkuser), kreeg toen wel een "standje" .. maar het lijkt mij wel een logischer oplossing. Hoewel je dan wel tegen het maximaal aan te maken accounts kan aanlopen, maar in elk geval voorkom je dat mensen niet kunnen inloggen terwijl ze al een account hebben op een ander project. Groet, Elly Sta jij al hier? (Overleg) 26 mrt 2024 19:47 (CET)

Je hebt dan kans dat 5 minuten na het opheffen de blokkade al weer terug is, omdat er vandalisme gepleegd wordt vanaf dat ip-adres. Mbch331 (overleg) 26 mrt 2024 19:56 (CET)Reageren
(bwc met Akoopal) Of een ander IP, als er sprake is van ranges. Soms worden die blokkades ook opgelegd omdat er om de haverklap van IP gewisseld wordt. Daniuu (overleg) 26 mrt 2024 20:06 (CET)Reageren
Zou het niet handig zijn als deze accountaanmakers ook een ipblock-exempt kunnen toekennen voor maximaal een dag? Dan kunnen ze ook in een geval van een hardblock dingen oplossen zonder een mod. In principe is een ipblock-exempt geen big deal, de gebruiker is bekend en zeker in dit geval zijn de gebruikers bekend bij de accountaanmaker. Akoopal overleg. 26 mrt 2024 20:06 (CET)Reageren
@Akoopal dat zou inderdaad handig zijn. Alleen is het denk ik niet mogelijk om de duur softwarematig in te stellen (al denk ik wel dat we de accountaanmakers kunnen vertrouwen dat ze zich aan een beleidsmatige beperking houden). Daniuu (overleg) 26 mrt 2024 20:08 (CET)Reageren
Ik meende dat een beperking van de termijn technisch mogelijk was. Er even ingedoken en dat niet kunnen vinden helaas. Het zal dus inderdaad procedureel vastgelegd moeten worden. Akoopal overleg. 27 mrt 2024 09:50 (CET)Reageren
Hallo allemaal, vooraf aan de bijeenkomst van afgelopen 8 maart heb ik de IP-range opgevraagd bij de organisatie met het verzoek aan @Drummingman om de blokkade tijdelijk op te heffen. Vrij snel werd er vanaf die range weer vandalisme gepleegd waardoor het IP-adres geblokkeerd is tijdens de bijeenkomst zelf. Er zijn naast de accounts die Drummingman heeft aangemaakt, ook nog 5 accounts door mij aangemaakt middels accountaanmaak rechten. Kortom, van de 18 deelnemers waren er 12 die hulp nodig hadden met het aanmaken van een gebruikersnaam. Thamara Groenleer - Wikimedia Nederland (overleg) 26 mrt 2024 21:41 (CET)Reageren
Steun Steun lost een concreet probleem op dat een hoog afbreukrisico met zich meebrengt. Goed initiatief dit. Dat er nog andere problemen spelen klop, maar dit kunnen we makkelijk oplossen, dat andere minder makkelijk. Natuur12 (overleg) 26 mrt 2024 21:41 (CET)Reageren
Het lijkt me verstandig dit even op overleg gewenst te melden en dan na een redelijke termijn consensus te verklaren (of niet natuurlijk) en bij consensus de devs te vragen om te implementeren. Akoopal overleg. 27 mrt 2024 09:52 (CET)Reageren

Tech News: 2024-14[bewerken | brontekst bewerken]

MediaWiki message delivery 2 apr 2024 05:33 (CEST)Reageren

Frontend voor aanmaak kaartbestanden op Commons[bewerken | brontekst bewerken]

Hai, ik was de laatste tijd met GeoJSON bestanden op Commons aan het spelen, en het viel me op dat het maken daarvan iets gebruikelijkersvriendelijker zou kunnen. Ik probeer al een soort handleiding te maken, maar op dit ogenblik moet je nog met Notepad++ in XML bestanden knoeien, en URLs hacken om makkelijk je bestand op de juiste plek op Commons te krijgen. Dat kan denk ik makkelijker. Ik heb wat ideeën over hoe een wizard voor het maken van GeoJSON bestanden er uit zou moeten zien. Iemand ideeën over hoe dit verder aan te pakken? Andere input? Milliped (overleg) 7 apr 2024 23:33 (CEST)Reageren

Tech News: 2024-15[bewerken | brontekst bewerken]

MediaWiki message delivery 9 apr 2024 01:34 (CEST)Reageren

Tech News: 2024-16[bewerken | brontekst bewerken]

MediaWiki message delivery 16 apr 2024 01:26 (CEST)Reageren

Tech News: 2024-17[bewerken | brontekst bewerken]

MediaWiki message delivery 22 apr 2024 22:25 (CEST)Reageren

Tech News: 2024-18[bewerken | brontekst bewerken]

MediaWiki message delivery 30 apr 2024 05:30 (CEST)Reageren

Vervangen kaart op sjabloon:Infobox weg Nederland N-weg door Maplink[bewerken | brontekst bewerken]

Hai, de kaartjes die gebruikt worden worden op {{Infobox weg Nederland N-weg}} zijn png bestanden die gemaakt zijn aan de hand van OpenStreetMap gegevens. De kaartjes zijn vaak niet heel erg up-to-date, en we hebben tegenwoordig de mogelijkheid om kaartgegevens direct uit OSM op te halen met behulp van het sjaboon {{maplink}}. In het geval van de N-wegen in Nederland lijkt het me behoorlijk zeker dat alle wegen een correct werkende link hebben, dus mijn voorstel zou zijn de kaart te vervangen door het maplink-sjabloon. Een voorbeeld even hier. In het voorbeeld zit nu een melding in over een bestand, ([[Bestand:|262px|center|Provinciale weg 223]]) waarvan ik niet helemaal doorheb waar deze vandaan komt, en er zit een kader in dat wellicht weg kan en een uitlijning die misschien iets beter kan. Zou iemand kunnen kijken of dit aan te passen is? Milliped (overleg) 30 apr 2024 19:17 (CEST)Reageren

Ping @Bdijkstra en @Bertux. Milliped (overleg) 30 apr 2024 19:25 (CEST)Reageren
Het komt in ieder geval uit {{Sjabloon:Infobox generiek weg}} waarin dit staat: [[Bestand:{{{kaart}}}|{{#expr:{{{breedte|{{Infobox/breedte}}}}}-8}}px|center|{{{kop1|}}}]] ∼ Wimmel (overleg) 30 apr 2024 19:32 (CEST)Reageren
Inderdaad, het generieke sjabloon verwacht voor de parameter kaart een bestandsnaam. Misschien gewoon een standaard maplink tonen als er maplink=ja is ingevuld? Alle huidige wegen hebben wellicht een correct werkende link, maar er kunnen ook pagina's zijn over voormalige wegen en geplande wegen, en {{Maplink}} toont een lelijke rode foutmelding als er geen gegevens zijn. –bdijkstra (overleg) 30 apr 2024 20:18 (CEST)Reageren
Die rode foutmelding hoeft geen probleem te zijn als je de zaak even voorbereidt buiten de artikelruimte. Je maakt eerst voor alle wegen een afzonderlijk maplink-sjabloon, alles op 1 pagina, zoals hieronder. De foutmeldingen haal je er met de hand uit, van de rest maak je een lijstje dat je aan een bot kunt voeren.
Bijkomstig:
De gemaakte lijst kun je meteen gebruiken voor een kaart van alle snelwegen in Nederland. Je kunt 1 overzichtskaart maken door met de zoek- en vervangfunctie de tussendelen {{maplink|type=map|palin=yes en }} te verwijderen. Je houdt dan 1 werkend sjabloon over. Eventueel als apart sjabloon opslaan, analoog aan {{Sjabloon:Maplink stadspoorten van Haarlem}}
{{maplink|frame=yes|plain=yes
|id=Q99999999|type=line
}}
{{maplink|frame=yes|plain=yes
|id-Q9999999999999999|.............
}}
 →bertux 30 apr 2024 21:41 (CEST)Reageren
@Bdijkstra Ik heb me afgevraagd of dat te ondervangen is door een soort switch als OpenStreetMap-identificatiecode voor relatie (P402) bestaat voor het item op WD, laat dan maplink zien, maar doe niets als P402 leeg is. Dat is niet perfect (ik ben zelf erg slordig met het toevoegen van P402 als ik op OSM iets aanpas), maar ik weet dat het voor bijvoorbeeld de wegen meestens netjes toegevoegd is. Milliped (overleg) 30 apr 2024 22:50 (CEST)Reageren
Nog een paar aanvullende gedachten:
  • De foutmelding die je krijgt bij een ontbrekend item lijkt me mee te vallen, je krijgt een leeg wereldkaartje en geen rode letters.
  • Ik heb even gekeken met PEtscan, maar ik krijg de query niet helemaal goed, ik zoek naar items met het sjabloon {{Infobox generiek weg}} en OpenStreetMap-identificatiecode voor relatie (P402), maar krijg als ik voor het wikidata item "none" of "no statements" aanvink geen resultaten, terwijl ik met een steekproef wel een paar gevallen ben tegengekomen.
  • De gevallen met een missende P402 die ik tot dusver heb gezien vallen in een paar categorieën:
    • OSM relatie ID bestaat, maar is nog niet toegevoegd. (redelijk makkelijk te verhelpen)
    • OSM relatie bestaat niet, maar zou wel binnen OSM scope vallen (meer werk, maar op te lossen door de OSM relatie te maken
    • OSM relatie bestaat niet, maar out of scope voor het OSM project (ben ik eigenlijk nog niet tegengekomen, maar is van toepassing op verdwenen of toekomstige wegen, en wat vage wegdefinities. Hier kan met geojson iets aan gedaan worden. Wel leuk om te doen, maar bewerkelijk.
Ik heb doordat ik die petscan query nog niet helemaal door wat de aantallen zijn (anders dan dat er op nl-wiki 6416 artikelen zijn die op het sjabloon infobox generiek weg leunen), als iemand daarnaar zou kijken heb ik al wat meer beeld. Milliped (overleg) 2 mei 2024 13:31 (CEST)Reageren
Het lijkt mij het beste als er géén botrun gedaan wordt, maar dat de maplink in Infobox generiek weg zelf wordt ingevoegd en zo automatisch op alle artikelen getoond wordt. Dit reduceert onnodige code in artikelen. Indien in bepaalde artikelen dit nog niet voorhanden is, lijkt het me goed als dat dan voor die artikelen ook opgevraagd kan worden. Met een parameter maplink=nee kan dit in een artikel eventueel uitgeschakeld worden, maar dan alleen bij wijze van uitzondering. Romaine (overleg) 2 mei 2024 13:38 (CEST)Reageren
Mee eens. Het lijkt me dat het percentage artikelen mwaar maplink niet op werkend te krijgen is zo klein is, dat dit haalbaar is. (ik zou wel graag weten welke artiklen dit zijn. Hulp met die Petscan query dus nog steeds welkom). Milliped (overleg) 2 mei 2024 13:47 (CEST)Reageren