Overleg Wikipedia:Wikiproject/Check Wikipedia

Onder "HTML List elements" staat iets wat niet helemaal waar is: in sommige gevallen is het nodig om HTML te gebruiken omdat de wiki-syntax een bepaalde mogelijkheid ontbeert. Zie b.v. de tabel "Bestuurlijke indeling" op Changwat Kamphaeng Phet, waar de nummering van de list-items in de tweede kolom moet aansluiten op de eerste. - Erik Baas 6 sep 2008 13:57 (CEST)

Plaats van dit project

Hoe zeer ik dit project ook toejuich, ik zie liever dat er een link vanuit de pagina Wikipedia:Wikiproject hierheen wordt gelegd en dat de tekst in het Nederlands vertaald wordt. dit alles i.v.m. vebetering van de kwaliteit - ook voor wikiprojecten zie ik liefst kwaliteitseisen - Quistnix 6 sep 2008 14:06 (CEST)

Hello, can you translate this in german or english. This could help. -- Stefan Kühn 6 sep 2008 14:13 (CEST)

I said that translating the project page could help, and, what is more important: a link from the community's project page to this project. It is not a good practice to start projects in a foreign language on a local wiki without following the procedures set by the local community. Thank you - Quistnix 6 sep 2008 14:17 (CEST)

Obviously you can't do that, so we'll just have to do it ourselves and send you the translation. Anyone willing to help at Gebruiker:Erwin/Klad1 Wikipedia:Wikiproject/Check Wikipedia/Vertaling? --Erwin(85) 6 sep 2008 14:18 (CEST)

At the moment it is an Alphatest. If it works stable than we can translate the projectpage. At the moment I have english description in all languages. -- sk 6 sep 2008 14:20 (CEST)

Starting projects like this without consensus is a bad idea. Please stop and discuss the whole idea before continuing - Quistnix 6 sep 2008 14:22 (CEST)

Why it is a bad idea. I have create a project like this in de de:Wikipedia:Personendaten/Wartung/Fehlerliste and it has very good resonance. So I work the last weeks very hard vor this new project "Check Wikipedia". And I think it will be a very good idea. -- sk 6 sep 2008 14:26 (CEST)

You have to read more carefully, we're not saying the project itself is a bad idea, the way you're starting it is bad. Multichill 6 sep 2008 14:30 (CEST)

Please continue and leave this local matter to us. I'm sure that there are users who do appreciate your work, including me, and we'll make sure that there'll be a nice Dutch description. (Edit conflict: Maybe he should have started it differently, but why don't we help him with that instead of attacking him for trying to help us! en:Wikipedia:Assume good faith!) --Erwin(85) 6 sep 2008 14:33 (CEST)

We are not attacking anyone - we are just doing our part of the necessary quality control. It is not so that anyone can start any project and place it in the wikipedia namespace, without discussing it first. No projects should be started out of the blue - Quistnix 6 sep 2008 14:36 (CEST)

Ok, sorry for my misstake. I had hope that I can give your nl.wikipedia this page and some wikipedian from nl can integret this page in your website. I can not read nl and so I don't know how to open a new project. Sorry for this. I think :"Just do it". -- sk 6 sep 2008 14:37 (CEST)

No problem. "Just do it" comes really close to our motto "Voel je vrij en ga je gang". We'll just fine tune your work such that it fits in better with the way the nl-wiki is organised. But it might have been better if you've asked for help/translation in our village pump before you started it. I do like this project though, although not all "errors" mentioned give need to intervention (see below). CaAl 6 sep 2008 14:42 (CEST)

Lowest priority

Heeft het wel zin om die "fouten" te corrigeren? Het is inderdaad netter als het gedaan wordt zoals staat aangegeven, maar het werkt ook op de foute manier. Zo maakt MediaWiki zelf <br /> van <br> en kun je gerust meerdere categorieën op een regel plaatsen. --Erwin(85) 6 sep 2008 14:12 (CEST)

Idd, en ook de fout dat de categorienaam met een kleine letter begint, of dat de cat dubbel is, wordt automatisch gefixt. De [...]] fouten zijn wel handig. CaAl 6 sep 2008 14:19 (CEST)

Verbeteren moest je er toevallig zijn, zou ik zeggen. Anders laten staan. Ik laat mijn bot deze dingen ook verbeteren, als extra aanpassingen wanneer de bot op een pagina moet zijn. --Tuvic 7 sep 2008 16:01 (CEST)

Ik heb de kleine letters > hoofdletters fout in de categorieën verwijderd. Problemen die er niet zijn hoeven we ook niet op te lossen. Jacob _overleg 3 nov 2008 21:03 (CET)

Voor overijverige lezers: Ik zie de "fout" <br /> niet meer terug in de lijst, en gelukkig maar. Dit is namelijk de juiste tag volgens de huidige HTML-normen. Die schrijven namelijk voor dat elke tag tweedelig is: een begintag en een eindtag. In dit geval, en enkele soortgelijke, leidt dat tot <br></br>. Om deze absurditeit te voorkomen, is het toegestaan de eindtag meteen aan de begintag toe te voegen. <br /> of <br/> zijn dus de juiste weergaven. Wanneer deze syntaxis verwijderd is, moet hij bij voorkeur weer teruggezet worden.

Vertaling

Zullen we eerst maar eens beginnen met de boel naar het Nederlands te vertalen? Op Wikipedia:Wikiproject/Check Wikipedia/Vertaling staat een plek om dat te doen. Multichill 6 sep 2008 14:51 (CEST)

Ik heb het grotendeels vertaald. Sommige dingen heb ik weggelaten, omdat ik dat niet belangrijk vond. Wat vinden jullie ervan? We moeten er gewoon een bot op los laten die de lijst steeds bijwerkt met behulp van subpagina's of enkel de data overschrijft. Dat kan makkelijk. --Erwin(85) 7 sep 2008 14:06 (CEST)

De complete pagina vertalen lijkt mij wel zo prettig. Bovendien zou ik graag even willen discussiëren over de (on)wenselijkheid van bepaalde bewerkingen en de wenselijkheid van andere. Het corrigeren van onbalans in het aantal "=" tekens in een kop bijv. lijkt mij een nuttige funcite. Andere functies met een lage prioriteit lijken mij te onbelangrijk om een bot op los te laten. Als de MediaWiki-software het probleem zelf oplost, hoeven we niet in te grijpen, lijkt mij. Ik xou ook graag willen zien wie aan het project deelnemen. Als er geen enkele deelnemer bij zit die Nederlands spreekt, lijkt het mij ook beter om er niet mee door te gaan. - Quistnix 7 sep 2008 20:28 (CEST)

Wat is nu de bedoeling van de vertaling? Gewoon op die pagina die staat aangegeven, de Engelse tekst vervangen door Nederlandse? Want het was al vertaald (wat Edwin hierboven zegt), maar dat is daarna weer vervangen door Engelse tekst. Peti ... 3 nov 2008 16:59 (CET)

Behoefte?

Is er wel behoefte aan deze uitgebreide lijst? Er staan zaken op die te onbelangrijk zijn om iets aan te doen en ik zie nog steeds geen deelnemers aan het project die Nederlands spreken - Quistnix 13 sep 2008 10:08 (CEST)

Automatisch corrigeren?

Het grootste deel van de geanalyseerde problemen op deze pagina kunnen botmatig worden opgelost. Ik ben niet genoeg ervaren met Python, maar wellicht kan de tijd die aan dit project besteed wordt beter gestoken worden in de ontwikkeling van een syntaxiscorrectie-script, zodat het niet bij analyse blijft. Voor sommige problemen bestaan al scripts (bijvoorbeeld noreferences.py voor lijst 3.1), die zouden misschien samengevoegd en uitgebreid kunnen worden. Vriendelijke groet, --Maurits 25 okt 2008 13:15 (CEST)

Ik las zojuist dat Davin al een soortgelijk verzoek op Wikipedia:Verzoekpagina voor bots#Syntaxfouten heeft geplaatst. Overleg kan het beste daar worden gecentraliseerd. Vriendelijke groet, --Maurits 25 okt 2008 13:37 (CEST)

If you want write a bot for the correction of an error then you can use this full-error-list (update daily). -- sk 27 okt 2008 06:00 (CET)

On the Dutch Wikipedia they don't want the low priority issues to be fixed via a bot. I programmed a javabot yesterday for this purpose but was kicked offline because edits were done to fast and were controversial. It's oke to fix a low priority issuesbut only if other more improvements are made to an article. They high and medium priority issues are however too difficult to fix botwise. I thought we could reduce this list to zero in a few days, but that's not possible and maybe impossible forever. Rudolphous 28 okt 2008 18:23 (CET)

Met behulp van de volgende regexes kan je 2.3 derdegraadkoppen verhelpen:

te zoeken: ([\n\r]{1,}) *={3,3}(=*) *([^=]{1,}) *(=*)={3,3}

te vervangen door: $1==$2 $3 $4==

Ik heb er nog wel wat andere reguliere expressies, voor andere minder dringende dingen, maar dit is de bron. Ik kan het zelf niet afmaken, maar voor de volledigheid staat op Gebruiker:Annabel/Default.xml de default.xml met de instellingen die ik voor AWB gebruik (wel elke wijziging nakijken en gebruiksnaam aanpassen).

Annabel_(overleg) 28 okt 2008 21:37 (CET)

Sommige zaken zijn bugs

..Headline should end with "=":..

Als er een ref ingevoegd wordt in een kop werken de "=" aan het eind niet meer

Jcwf 27 okt 2008 06:28 (CET)

Heb ik gemeld op de OP van sk. Wammes Waggel 2 nov 2008 20:55 (CET)

Andere zaken zijn meer een politieke agenda

..The article has an image without a description. In order to provide good accessibility for everyone (e.g. blind people) a description for every image is needed...

Eh, staat dat in de grondwet of zo? Voor veel afbeeldingen is dat echt een onmogelijke zaak. Neem chemische reacties: je kunt die heel moeilijk als tekst inbrengen. De wiki software stelt je namelijk niet in staat een chemische structuurformule neer te poten. Dus dan maar met veel gedoe een plaatje maken met alle malle auterusrechtbureaucratie van dien en nu komt een andere bureaucratie ons vertellen dat het toch in tekst weergegeven moet worden? Het spijt me maar discriminatie van chemici is ook niet redelijk. Jcwf 27 okt 2008 06:36 (CET)

Als een plaatje een omschrijving heeft krijg je deze ook te zien als je met je muis erboven zweeft. Ik denk dat voor de meeste plaatjes heel eenvoudig een omschrijving is toe te voegen. Groet, Rudolphous 27 okt 2008 08:37 (CET)

Het is misschien wenselijk, maar om het een error te noemen wanneer het niet gebeurt, gaat me veel te ver (zoals trouwens bij het merendeel van de warnings van dit project). CaAl 27 okt 2008 09:04 (CET)

Er kunnen wel degelijk beschrijvingen bij afbeeldingen of chemische onderwerpen gegeven worden. Een vaakgebruikte is Structuurformule van .... Je kan ook Reactie van ... met ..., Voorbeeld van een ... reactie, ...poeder (met ... de naam van het product), etc. gebruiken. Een fout is het niet echt te noemen, maar tekstgebaseerde browsers worden nog altijd gebruikt. HTML en XML standaard verwachten ook een beschrijving bij een figuur, bijvoorbeeld zodat deze getoond kan worden, wanneer de internetverbinding instabiel is en de figuur niet geladen kan worden. Annabel_(overleg) 27 okt 2008 10:17 (CET)

Wellicht een bug (het werkt in ieder geval niet helemaal juist), maar het past denk ik meer bij dit tussenkopje: in de afdeling afbeeldingen-zonder-bijschrift staan ook afbeeldingen die in een infobox staan. In sommige gevallen kan daar eigenlijk geen bijschrift bij, in andere gevallen staat het er met een kleine omweg bij (zoals hier). Hoe is dit op te lossen? --Peti ... 3 nov 2008 00:34 (CET)

Een & nbsp; als beschrijving opnemen? Wutsje 3 nov 2008 01:07 (CET)

Wat betreft "Headline hierarchy": daar zie ik niet per se iets fouts in. Ik kies er soms om opmaaktechnische redenen doelbewust voor om level 2 over te slaan (level 2-kopjes krijgen door hun lettergrootte en vettigheid te veel nadruk t.o.v. level 1-kopjes, vind ik). "Correcties" daarvan, zoals bv. op It Fryske Boek, zal ik dan ook weer terugdraaien. Wutsje 4 nov 2008 23:38 (CET)

HTML zaken

Weet iemand hoe die HTML zaken op te lossen zijn? Rudolphous 2 nov 2008 09:28 (CET)

De p tags kunnen gewoon weggehaald worden, de i en de b-tags kunnen door een simpele zoek- en vervangopdracht aangepakt worden. Bij de onderlijntag u daarentegen moet je per keer bekijken of er geen alternatief is (staat typografisch niet zo mooi, dikwijls is cursief ook OK), maar eerlijk gezegd zie ik dit niet als fout. Een aanzienlijk deel van de meldingen is echter afkomstif van font-tags, bijvoorbeeld om de kleur van tekst aan te passen. Dit kan niet veralgemeend worden met het oog op het botmatig aan te pakken. Je zou het eventueel kunnen oplossen door de div-tag of ev. class-tag te gebruiken en de kleur (en ev. andere dingen) via de style= parameter aan te passen. Annabel_(overleg) 2 nov 2008 09:44 (CET)

Ik heb er weer een aantal kunnen doen. Enige idee hoe we met met de hitlijsten om moeten gaan? Rudolphous 2 nov 2008 13:17 (CET)

Ik begrijp je vraag niet zo goed. Bedoel je zoiets als "| Hitlijsten = <ul> <li>#1 ". De HTML opsommingen omzetten naar wiki-code: "< ul >" en "< /ul >" weghalen en de "< li >" en "< /li >" vervangen door *. Iets anders dat misschien aangepakt kan worden is < font size="-1" > en sluitingstag vervangen door < small > en < /small > (telkens zonder spaties). Annabel_(overleg) 2 nov 2008 13:58 (CET)

Ik bedoel inderdaad de edit die je laat zien. Kan je een voorbeeld laten zien hoe dit werkt? Ik krijg het niet goed voor elkaar. De Bullet veranderd namelijk in een asteriks. Rudolphous 2 nov 2008 14:00 (CET)

Wanneer je in een tabel een opsomming wil plaatsen, moet je op een nieuwe lijn beginnen. Wanneer het sterretje net na de wiki-code voor een nieuwe cel komt, dan krijg je ook in de uiteindelijke opmaak een sterretje. Daarom heb ik deze wijziging gemaakt in het sjabloon {{Infobox single}}. Bij het wikificeren doe je dan bijvoorbeeld dit. Annabel_(overleg) 2 nov 2008 14:33 (CET)

Ik heb alle hitlijst problemen opgelost. Groet, Rudolphous 8 nov 2008 09:50 (CET)

Annabel, weet je waarom dit niet werkt? http://nl.wikipedia.org/w/index.php?title=Life_In_Cartoon_Motion&action=history. Alvast bedankt. Rudolphous 9 nov 2008 09:04 (CET)

Bij Russische artikelen wordt de underline gebruikt om aan te geven waar de klemtoon ligt in het Russisch; een redelijk essentieel begrip in het Russisch, en dus absoluut geen fout. Errabee 3 nov 2008 17:03 (CET)

Dank je. Dat wist ik niet. In zo'n gevallen is het uiteraard foutief om veranderingen te doen. Om eerlijk te zijn beschouwde ik dit zelf niet als een fout, enkel wat minder gepast in Nederlandstalige teksten. Annabel_(overleg) 3 nov 2008 17:05 (CET)

Opmaak

Hoe zullen we de maandartikelen gaan doen:

1. December 2002 (zonder hoofdkop)
2. November 2002 (met hoofdkop)

Rudolphous 2 nov 2008 20:13 (CET)

Hmm, bij zulke opsommingen vind ik mét hoofdkop mooier. Dat is natuurlijk puur een kwestie van smaak... --Peti ... 2 nov 2008 22:54 (CET)

Tuurlijk is het een kwestie van smaak, maar ik vind wel dat er één lijn getrokken moet worden. Mijns inziens moet je de weg van de minste weerstand nemen, dus de meest voorkomende en de andere aanpassen. Zo snel als ik gekeken heb naar meerdere maandpagina's van jaren, vind ik er meer met 2e graads koppen als met 3e graads, maar dit jaar (2008) juist weer 3e graads. Kijk maar, als ze allemaal maar hetzelfde worden, dat is beter voor de uniformiteit van wikipedia. - Goudsbloem 3 nov 2008 00:42 (CET)

True, ik bedoelde alleen maar dat mijn mening hierover smaak is, niet dat we dit niet moeten uniformiseren :) --Peti ... 3 nov 2008 00:53 (CET)

Dat bedoelde ik eigenlijk ook te zeggen, maar tipte ook even de uniformiteit aan. (ik lul gewoon te veel, daarom staan er steeds zoveel woorden bij mijn commentaar/opmerkingen) ← kijk, daar doe ik het weer! 🙂 Goudsbloem 3 nov 2008 00:57 (CET)

Tekst bij foto's

Het is een aardig klusje om alle foto's van een tekst te voorzien. Als iemand zin heeft een handje te helpen..... Rudolphous 5 nov 2008 18:51 (CET)

Ik doe er ook regelmatig een paar :) --Peti ... 5 nov 2008 19:42 (CET)

Waarvoor dank! Nog een kleine 300 te doen momenteel. Misschien dat ook iemand met verstand van scheikunde / natuurkunde even kan kijken naar de plaatjes. Er zijn er een aantal met scheikundige formules. Rudolphous 29 nov 2008 17:04 (CET)

Verwijdernominatie van deze pagina

Ik heb overwogen deze check pagina voor verwijdering voor te dragen. De reden is dat deze opsomming van futiliteiten geen bijdrage levert aan verbetering van wikipedia, maar wel hele volglijsten verstoort en zo mogelijk vandalisme toedekt onder een laag botbewerkingen. Uiteindelijk toch maar niet gedaan, maar ik roep de actieve gebruikers hier op eens te overwegen of het allemaal wel zin heeft. Het écht verbeteren van artikelen of het schrijven van nieuwe artikelen heeft een hoge prioriteit. De opsomming op de checkpagina mijn inziens helemaal niet. Jacob _overleg 6 nov 2008 08:45 (CET)

Het verbeteren van deze ogenschijnlijk onbenullige syntaxfouten kan wel degelijk van belang zijn. Ik denk aan het feit dat wanneer er een papieren versie gedrukt zou worden dergelijke syntaxfouten voor grote (ja zelfs onoverkomelijke) problemen zorgen bij het maken van een PDF of boek. Wanneer de syntax overal goed gevolgd zou worden, zou de software ook veel efficiënter gemaakt kunnen worden. Maar echt fout zijn het openen van tags die niet gesloten worden. Ik denk ondermeer aan de code tags en commentaartags die niet afgesloten worden. In dat geval heb je zowieso ofwel een verkeerde layout ofwel tekst die onnodig verborgen blijft. Ik denk ook aan slecht opgemaakte HTML tabellen. Daar heb je dikwijls een rommeltje, een foutief gebruik van de tags. In wikicode, is het veel eenvoudiger om deze tabellen goed te krijgen kwa layout en ze ook aan te passen. Zelf kijk ik dan ook verder dan hetgeen puur gerapporteerd wordt. Groet, Annabel_(overleg) 6 nov 2008 08:52 (CET)

PS: er zijn inderdaad een aantal rubrieken waar niet overgegaan moet/mag worden, bv. meerdere cats op een lijn (dit wordt zelf automatisch gedaan wanneer een bot met andere nuttigere bewerkingen langskomt, hetzij een bot op pywikipedia, hetzij met AWB)

Jacob, rudolphousbot heeft de eerste lading punten opgepakt. In praktijk heeft RudolphousBot de laatste dagen niet zo heel veel gedaan. Het restant aan punten kan namelijk volgens mij voor het grootste gedeelte niet met een bot opgepakt worden. Bij "eerste letter categorie met kleine letter" (nu de grootste categorie) was namelijk de algemeen geldende mening dat dit niet als afzonderlijke bewerking mocht. Nu wordt er elke dag een paar honderd punten opgelost. Van volglijstvervuiling is mijn ogen allang geen sprake meer. Ik vind de lijst heel nuttig (en meerdere mensen met mij, die niet altijd reageren in kroegdiscussies, etc). Zo zijn er gisteravond ook weer zo'n 20 foute links opgelost, missende referenties geplaatst en defaultsort problemen opgelost. Van mij mag je de pagina nomineren, misschien dat het dan duidelijk wordt dat meerdere mensen deze lijst wel nuttig vinden. Rudolphous 6 nov 2008 09:59 (CET)

PS: Als die categorieën met hoofdletter worden, bv: Categorie: Vaste plant, dan de C van Categorie met hoofdletter, V van Vaste plant met hoofdletter, en géén spatie tussen de categorienaam en de dubbele punt. Romaine (overleg) 9 nov 2008 23:24 (CET)

PS2: Er zijn nog twee andere projecten: Links naar doorverwijspagina's en Ontbreken van links naar weespagina's. Daar is er ook een achterstand. Romaine (overleg) 9 nov 2008 23:54 (CET)

Die bewerkingen op categoriën zijn m.i. volstrekt overbodig. Het argument van de papieren editie lijkt mij hierbiij ook niet aan de orde. Categoriën lijkt mij en concept dat in een papieren uitgave geen enkele meerwaarde kan hebben, doorklikken lijkt mij namelijk vrij lastig op papier. Peter b 14 nov 2008 00:47 (CET)

wees terughoudend met de kopfix

Al drie keer is het nu voorgekomen dat een zogenaamde kopfix werd uitgevoerd op een pagina waarbij ik bewust voor die opmaak heb gekozen. De laatste 2x was allebei op DNA. Gelieve de opmaakkeuzes van de redacteurs te respecteren. Vriendelijke groet, Josq 11 nov 2008 16:42 (CET)

Dit is dan iets wat je met de css van deze site moet oplossen, niet door een revert! Lettertypegroote en andere -kenmerken kunnen (nee moeten!) via de css aangepast worden ... Annabel_(overleg) 11 nov 2008 16:45 (CET)

Dat is compleet nieuw voor me, en dat zal het ook wel voor meer dan 90% van de lezers zijn. Moeten is een erg groot woord dat ik in de context van kleine opmaakwijzigingen niet graag hoor. Vriendelijke groet, Josq 11 nov 2008 16:55 (CET)

Deze opmaakvolgorde is normaal, ik snap niet wat daar tegen is. Zo blijf je de subkopjes ook in de inhoudsopgave zien. Je kunt daarom niet met ; of vet gaan werken, want dan vallen de kopjes weg uit de inhoudsopgave, maar dat geeft qua beeld praktisch hetzelfde gezicht als 4 of 5x = . Mvg. --algont_overleg 12 nov 2008 21:13 (CET)

Headline hierarchy

Zoals ik elders hierboven ook al schreef: om opmaaktechnische redenen kies ik er soms voor om level 2-kopjes niet te gebruiken, omdat die door hun lettergrootte en vettigheid naar mijn smaak teveel nadruk leggen op de onder dat kopje opgenomen tekst. Nu doet zich de situatie voor, dat één persoon dit fout vindt (After a headline of level 1 (==) should not be a headline of level 3 (====)) en daarom een bot op nl:wiki heeft losgelaten teneinde alle lemmata waarin dit is gebeurd op te sporen, zodat deze kunnen worden "verbeterd". Een dergelijke "verbetering" tast in mijn ogen in sommige gevallen echter de structuur van het lemma in kwestie aan. Graag zou ik een link zien naar de pagina op nl:wiki waarop brede overeenstemming is bereikt over het feit dat het hier daadwerkelijk om een fout gaat. Wutsje 11 nov 2008 17:06 (CET)

Het is heel duidelijk: de MediaWiki-software werkt met logische opmaak. Na een level-1 volgt /dus/ een level-2. Dat zegt in principe niets over de opmaak, alleen over de structuur van het lemma. De opmaak van een level-2-kopje is geen reden om dan maar een level-3-kopje te gebruiken. Als je de fysieke of visuele opmaak wilt veranderen, kan dat via je eigen instellingen/css/whatever. (En ja, ik vind die level-2-koppen ook onredelijk dik en vet) Paul B 11 nov 2008 17:26 (CET)

Het gaat erom hoe iedere lezer de (structuur van) een artikel - de inhoud daarvan dus - te zien krijgt. Dat is niet te beïnvloeden door mijn "eigen instellingen/css/whatever" te veranderen. Wutsje 11 nov 2008 17:32 (CET)

Touché. Dan is één probleem dus dat de level-2-kopjes standaard worden weergegeven op een manier die ze (inderdaad) te veel nadruk geeft t.o.v. de level-1-kopjes. Een ander probleem is dat dezelfde structuur zonder onderscheid wordt opgelegd aan artikelen van tien regels en van tien pagina's. Als ik een artikel van twintig regels maak met twee onderdelen, waarbinnen ik dan paragraafjes van vif regels maak, is het inderdaad een beetje vreemd om die dan een level-2-kopje te geven: dat is veel te nadrukkelijk en te vet voor een onderdeel van vijf regels. In die zin moet ik je gelijk geven. Paul B 11 nov 2008 17:42 (CET)

Bijna overbodig om het op te merken, maar dit sluit natuurlijk perfect aan bij mijn opmerking hierboven. Lijkt me een extra bevestiging dat de medewerkers aan dit project niet blind moeten gaan 'kopfixen'. Overigens wil ik wel mijn waardering uitspreken voor het werk dat hier gedaan wordt. Josq 12 nov 2008 20:39 (CET)

Misschien kan het verhelderend werken om het artikel Cascading Style Sheets eens door te nemen. Voor een grote site als wikipedia is het van groot belang dat de opmaak er uniform uiziet en ook als je de ingebrachte informatie op een andere manier wil gaan gebruiken. Cascading styule sheets zijn juist ontworpen voor het scheiden van opmaak van de technische kant van een website. Als je een goede site wil bouwen moet je beide niet gaan mengen en dat is wat je doet door derdegraadskopjes te gaan prefereren omdat ze er "mooie" uitzien dan tweedegraadskopjes. Nogmaals als er een probleem is, moet je de css van de hoofdsite aanpakken. Als je er als individuele gebruiker moeilijkheden mee hebt, dan kan je je eigen monobook.css aanpassen. Als je wil kan ik voor een voorbeeld zorgen opdat je ziet wat ik bedoel en hoe je de aanpassing voor de opmaak kan doen, zonder het veranderen naar een derdegraadskopje. Groet, Annabel_(overleg) 12 nov 2008 21:00 (CET)

Aan kennis over css ontbreekt het me niet, Annabel. Mijn punt is echter: waar jij het over opmaak hebt, heb ik het over de structuur van een artikel - over inhoud dus. En ik vind het echt te ver gaan, dat zonder nader onderzoek zomaar opeens door iemand die niet eens Nederlands spreekt mag worden besloten dat de structuur van een artikel op nl:wiki fout is. Wutsje 12 nov 2008 22:52 (CET)

Kennis aan CSS is wat anders dan kennis over structuur en inhoud. Het lijkt me handig om bij het woord structuur voortaan te hebben over tweede- of derdegraagds kopjes, dat is de structuur, dat er na een h1 een h2 komt. Dat heeft vervolgens helemaal niets met de inhoud te maken, en ook niet met - wat jij volgens mij eigenlijk met inhoud bedoelt - het uiterlijk/opmaak. Waarbij de laatste (uiterlijk/opmaak) aangepast hoort te worden met CSS, en niet door kopjes van niveau te veranderen. Ik denk dat het heel belangrijk is om de structuur (kop niveau) te scheiden van het uiterlijk/opmaak.

Deze niet Nederlandse persoon heeft volgens mij niet in zijn eentje besloten hoe het hier op nl wiki moet. Eerder is er een persoon (met instemming?) die beslist over dit project wat door alle (niet allen nl in ieder geval neem ik aan?) sites wordt overgenomen.

Maar goed, los daarvan, als het uiterlijk wilt aanpassen moet je niet het niveau van de kopjes gaan aanpassen en die discussie ook niet op deze plek voeren :) --løde 13 nov 2008 00:39 (CET)

De keuze voor een kopje met een bepaald gewicht heeft wel degelijk te maken met de structuur van een tekst: de vraag is welke nadruk de auteur aan een bepaalde passage binnen het geheel van een artikel wil toekennen. Soms is dat niet het gewicht van chocoladeletters. Zoals ik bovenaan ook al heb gevraagd: graag zie ik een linkje naar de overlegpagina waarop consensus is bereikt over het feit dat auteurs op nl:wiki niet het recht hebben om in dat verband vrij te kiezen. Wutsje 13 nov 2008 00:50 (CET)

Daar is geen overleg of consensus voor nodig, h4 (subparagraaf) na h2 (hoofdstuk) is semantisch gewoon fout. - Berkoet (voorheen Dammit) 14 nov 2008 01:05 (CET)

Primair is nl:wiki een encyclopedie die wordt geschreven, niet geprogrammeerd. Als langs een achterdeur iets dat aan het begrip auteursvrijheid raakt door een handjevol mensen de facto onmogelijk wordt gemaakt, iets dat eerder nooit op bezwaren stuitte en dat bovendien door meerdere auteurs wordt benut, dan lijkt het me wel degelijk wenselijk om daarover vooraf consensus te bereiken. Overigens wordt zo her en der op de wiki inmiddels wel duidelijk, dat dit project in meerdere opzichten niet bij iedereen op instemming kan rekenen. Wutsje 14 nov 2008 01:31 (CET)

Die semantiek heeft weinig met programmeren te maken, in een andere tekst zou je ook niet de auteursvrijheid hebben om na een hoofdstukkopje een subparagraafkopje te plaatsen. Het stuitte waarschijnlijk nooit eerder op bezwaren omdat de omvang niet bekend was. Dat het project niet op instemming kan rekenen van enkelen ligt meer aan de manier waarop met de fouten omgegaan wordt bij het oplossen, voor elk van de problemen zijn zinnige argumenten te geven waarom ze een bepaalde prioriteit hebben. Ook wordt er te veel met de lage prioriteits problemen gedaan, terwijl hier eigenlijk pas aan begonnen zou moeten worden wanneer er geen problemen meer zijn met de hoge en middelmatige prioriteit. - Berkoet (voorheen Dammit) 14 nov 2008 09:21 (CET)

En wat als je in kleine artikeltjes er voor kies om enkel h3 te gebruiken? Dat wordt ook gepropageerd als fout zijnde, en helaas door niet nadenkende pedianen die de bots blindelings volgen gewoon gedaan omdat het aangegeven staat als fout zijnde. Helaas lijken collega's op no-wiki - en nu ook dus hier - door dit opgedrongen projectje compleet geassimileerd en hun vermogen tot zelfstandig nadenken kwijt te zijn. Wat is nou eigenlijk belangrijker? Het inhoud en de leesbaarheid ervan - of dat bots er goed mee om kunnen gaan? Noorse 15 nov 2008 03:52 (CET)

Jammer dat je op deze manier gaat reageren als je je gelijk van medegebruikers niet krijgt over wat in jou ogen zou moeten kunnen blijven. Misschien is dit nieuwe informatie, maar het kan ook gewoon zijn dat medegebruikers gewoon een andere mening hebben dan jij. Het is gewoon absurd dat je ze daarom maar moet gaan beledigen over hun verstandelijke vermogens. Dat zegt eerder iets over jou dan over die medegebruikers. Jammer! - Romaine (overleg) 15 nov 2008 04:01 (CET)

Ok, nu heb jij op mij als persoon gereageerd - nu graag jouw reactie op de twee vragen die ik stelde: Wat is nou eigenlijk belangrijker? Het inhoud en de leesbaarheid ervan - of dat bots er goed mee om kunnen gaan? Noorse 15 nov 2008 04:20 (CET)

Nu doe je al een aanname. Jij hebt voor iedereen naar het schijnt bepaald wat leesbaar is, en je vindt dus dat andere gebruikers geen eigen mening mogen hebben over wat zij leesbaar vinden. Zoals ik in mijn vorige bericht reeds schreef: andere gebruikers kunnen een andere mening hebben, een andere mening over wat zij leesbaar vinden, en ook een andere mening over tal van andere zaken. Vraagje voor jou: Vind jij jou eigen mening boven die van een ander staan? Oftewel, vind je dat je met jou mening meer gelijk hebt dan een ander die er anders over denkt? - Groetjes - Romaine (overleg) 15 nov 2008 04:32 (CET)

Hmm, ik heb inmiddels ondermeer even jouw op doorgelezen, en ik denk dat ik het hierbij laat :) Goedennacht! Noorse 15 nov 2008 04:39 (CET)

Hallo! For the headline hierarchy you should know: The W3-Consortium say here: Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example.". -- sk 15 nov 2008 14:40 (CET)

Then the wikimedia-software should make it more easy to create font effects in headings. As long as that is not the case, I think it is very justified to neglect the recommendations of an external consortium. Moreover, we are not 'content developers' in the first place but redactors of an encyclopedia. Josq 15 nov 2008 14:48 (CET)

Hello Josq, this is not an external consortium. It is the consortium for the Web. This consortium define the standards of HTML and XHTML. Wikipedia is a big XHTML. You can show this fact if you download [ https://dumps.wikimedia.org/nlwiki/ here] the file "pages-articles.xml.bz2". And yes we are the 'content developers'. We create this big document with all this great content. And we want that everyone can use our content (not only at the website). For example for blind people or for project like a book or a Wikipedia-DVD. Therefore we need a clean and correct syntax. --

Correct syntax is to be created by the Mediawiki software and *not* by the users of the project. If the Mediawiki software creates (X)HTML with errors, that's what has to be sorted out instead of making correction in the pages - because users will continue to make those "mistakes" (the software allows them to make them).

Ergo: this is not a problem to be solved induvidualy, but something that needs to be solved inside the Mediawiki software. Ergo: Don't bother us with syntax-errors. nl:Mark W (Mwpnl) ¦ talk 15 nov 2008 15:33 (CET)

False. If the input is wrong than the output can only be wrong. Never a software can fix a wrong formatted input text in a well formatted text. Also the Mediawiki-Software can't do this. You only see this errors not inside the website of wikipedia, because they will not displayed. But if you use an other output of the wikipedia-data you will see the problems. -- sk 15 nov 2008 16:07 (CET)

You make the false assumption that the input is wrong, while it isn't. Users do not care about correct syntax. If their input is tranformed to a valid output (and that's what Mediawiki does) they are happy. If the input is incorrect: the mediawiki software should reject the input ór correct the input. You now make the incorrect statement that software can't fix wrong formatted input text: it can in the same way as your bot creates this controversial list. The only problem is: Mediawiki doesn't check the input. Ergo: Change the Mediawiki software and not the users. Because: Users may leave the project, the Mediawiki software stays. nl:Mark W (Mwpnl) ¦ talk 15 nov 2008 16:14 (CET)

I will not change the user. I will change the data into data with correct syntax. That's all. -- sk 15 nov 2008 16:28 (CET)

Even worse! Point 1: The syntax is correct, since the Mediawiki software can interper it. Point 2: Users will continue too add new data with the - according to you - incorrect syntax, so this 'project' will never be done. So people/bots will continue to make minor, unnessecary edits. Following from point 1: If the Mediawiki outputs incorrect (X)HTML, the Mediawiki software should be changed, nót the user/input data. Following point 2: The project is useless unless the Mediawiki software is adapted. nl:Mark W (Mwpnl) ¦ talk 15 nov 2008 16:32 (CET)

Maybe you can change the mediawiki-Software, but I can't do this. I can only use the xml-data. If I want write a parser for the wikipedia-data I will not interpret this [[Link|Text1|Text2]]. It is a wrong link. And it will be not better, only because mediawiki ignore this. There are many other projects without mediawiki-Software (de:Wikipedia:DVD, Wikipedia:TomeRaider database, de:Wikipedia:Einbänder, ... ). -- sk 15 nov 2008 16:49 (CET)

Frankly my dear, if you can't interper [[Link|Text1|Text2]] - or any other Mediawiki-thing - than that's a problem with your parser. If you create a bot to run on MediaWiki wiki's your parser should work exactly the same as the MediaWiki parser... if not, your bot will make mistake after mistake just because you have a different vision then the Mediawiki-writers.

How dare you to bother us, users, with a problem your parser has? Who do you think you are to change the way nl-Wikipedia-users user the software, just because you don't want to change your bot to adopt a Mediawiki-like parser? nl:Mark W (Mwpnl) ¦ talk 15 nov 2008 17:04 (CET)

I'm sorry MarkW, but I guess that you are confusing a few things. Wat sk is talking about is not the syntax that the mediawiki parser should interprete. Is is about HTML/XHTML that can be entered in the edit box to add some more stuff to the documents on this wiki. However, sometimes this HTML input is incorrect. The other thing is incorrect mediawiki systax, such as tables that do not have a closing tag, etc. That is a totally different thing. Errors should be corrected. I guess that you are referring to the issues at the bottom of the page, such as categories whithout a capital which are named an error. You are true that this should not be named an error, but please do not confuse this with real issues, such as tags that do not have a closing tags. Annabel_(overleg) 15 nov 2008 17:11 (CET)

BTW: something like [[Link|Text1|Text2]] can be an error or not. A syntax checker (as sk wrote) just needs to report this, because such a construction which is invalid from a mediawiki point of view, might be a typing mistake, just some nonsense or whatever. In such an occasion, we should now, that it is invalid and if necessary, we need to remove the nonsense, or correct the typographic error, so that we have the correct link. Regards, Annabel_(overleg) 15 nov 2008 17:14 (CET)

Ah, thanks Annabel. I was indeed jumbeling up different things, just to make sure we're talking about the same things:

• Errors based on unclosed HTML-tags in articles should indeed be correct. No closing tags etcetera should be corrected indeed;
• Errors based on good Mediawiki-syntax but with a bad HTML output (such as using '===' instead of '==') should be corrected inside the MediaWiki code, for example by creating a <h2>-tag with the same style as a H3-tag or if that's impossible just by automaticly converting them to H2 (or just stick to the status quo).
• Good Mediawiki-syntax resulting in bot-errors (such as a space after [[Category: are a defect in de bot-parser and should not be corrected in articles but by adapting the botparser.

Thanks again Annabel. nl:Mark W (Mwpnl) ¦ talk 15 nov 2008 17:19 (CET)

"as a space after [[Category: " > I would not call that wrong input, if such an "issue" causes the software to render incorrect output or if it causes bots to hang, that is a bad habit of programming or incomplete/inacccurate software. Off course when other true issues are corrected, we could try to alter them in more readable mediawiki code or code that might be easier to be processed, but that should not be a priority nor it should distract us from our main goal (creating a high qualitative encyclopedia). Annabel_(overleg) 15 nov 2008 17:28 (CET)

PS: in this specific case, I would correct it when performing other edits, because I consider an extra space which does not have a purpose, as garbage

Kan er ondertussen even een vertaalbotje langskomen? Peter b 15 nov 2008 17:31 (CET)

Ja, dat zou handig zijn. ;) Yes a translation bot would be handy. ;) Annabel_(overleg) 15 nov 2008 17:33 (CET)

Argumenten voor en tegen het wijzigen van kopniveau

Voor	Tegen
Verkeerde headings zorgen voor incorrecte html en een semantisch incorrecte structuur Het gedrag van de parser kan in de toekomst veranderen Kopjes worden gebruikt bij de indexering Het uiterlijk van h3 kan makkelijk aangepast worden, zowel over de hele site als in één artikel (mocht daar steun voor zijn)	h3 is op Wikipedia te opvallend/dik tegenover de andere headings In de inhoudsopgave staat het niveau wel goed, dit lijkt een min of meer bewuste keuze van de developers.

Ik heb hier maar even een overzichtje van de argumenten neergezet, om te voorkomen dat het persoonlijk wordt. Voel je vrij er toe te voegen of ze te ontkrachten als ik er een vergeten ben/er eentje niet klopt. - Berkoet (voorheen Dammit) 16 nov 2008 12:04 (CET)

Volledig akkoord met wat MarkW zegt: men gaat hierbij altijd van de veronderstelling uit dat de gebruiker fout is; terwijl dat niet altijd zo is. Er zijn ettelijke redenen waarom er een bepaalde hiërarchie is gekozen. Ikzelf heb nog relatief weinig "afwijkende" hiërarchieën moeten toepassen voor zover ik mij herinner, maar ik kom ze wel eens tegen. Ik probeer er enkele heel algemeen te schetsen hieronder, gebaseerd op zgn. "afwijkende" gevallen die ik in het verleden wel eens ben tegengekomen. Wees zo vrij om nog algemene gevallen te vermelden als men er kent.

1. Puur typografische redenen. Dit is wat ik al verschillende gebruikers heb zien aanhalen, waaronder Gebruiker:Wutsje en enkele anderen.. Sowieso wordt HTML al niet meer gebruikt als strikt gestructureerde taal (al was het ooit de bedoeling), de wiki-syntax is dat ook niet altijd, en de manier waarop wikipedia ondertussen werkt evenmin.
2. Tussenliggende niveau's kunnen ergens doelbewust van tussenuit gelaten zijn. Zie hieronder voor een fictief voorbeeld als illustratie.
3. Sommigen hebben misschien vijf jaar liggen slapen, maar sinds jaar en dag beginnen wikipedia-artikelen zonder kopje ;-) Dat betekent dat je sowieso een soort "intro"-stuk hebt (wat doelbewust kort of lang kan gehouden zijn door de schrijvers), waar je meteen al met een ander concept van "niveau" zit.

Puntje 2. : even een (bewust) fictief voorbeeld.
Stel iemand schrijft een toeristisch overzicht van de Benelux (ik zei het al: fictief, ik veronderstel niet dat zoiets werkelijk op wikipedia staat). Het overzicht is gegroepeerd per provincie. Per provincie heb je een stukje "Geografie" en "Bezienswaardigheden" en "Praktisch". De structuur is als volgt (ik plaats overal voor de duidelijkheid tekstueel het Kop-niveau bij):

• == Kop2: Land ==
• === Kop3: Provincie ===
• ==== Kop4: Thema ====

Dan krijg je dus een dergelijk opgebouwd artikel:

== Kop2: België ==

=== Kop3: Provincie Antwerpen ===

==== Kop4: Geografie ====

==== Kop4: Bezienswaardigheden ====

==== Kop4: Praktisch ====

=== Kop3: Provincie Henegouwen ===

==== Kop4: Geografie ====

==== Kop4: Bezienswaardigheden ====

==== Kop4: Praktisch ====

.

.

== Kop2: Nederland ==

=== Kop3: Provincie Drenthe ===

==== Kop4: Geografie ====

==== Kop4: Bezienswaardigheden ====

==== Kop4: Praktisch ====

=== Kop3: Provincie Flevoland ===

==== Kop4: Geografie ====

==== Kop4: Bezienswaardigheden ====

==== Kop4: Praktisch ====

.

.

(en nu komt het:)

== Kop2: Groot Hertogdom Luxemburg ==

==== Kop4: Geografie ====

==== Kop4: Bezienswaardigheden ====

==== Kop4: Praktisch ====

Bij Luxemburg wordt geen onderverdeling gebruikt: er zijn geen provincies, en lagere bestuurlijke niveaus zijn hier niet gewenst of van toepassing. Dus: Er bestaat geen Kop3 ! Omwille van de consistentie en visuele duidelijkheid geeft men de thema's gewoon een kop4. Bewust gekozen. Moet er dan een (enig!) nutteloos tussenkopje worden in gevoegd ? Neen, is niemand gebaat bij; en wordt ook in echte documenten en brochures gewoon niet gedaan. Wat maken bots daarvan? Jawel, die gaan zitten rammelen in de niveaus van Luxemburg; ze gaan bv. plots de subkopjes een niveau hoger duwen.

Dergelijke dingen merk ik vooral wel eens aan bij lange overzichtspagina, waar veel lijsten en tabellen in staan, en die erg gestructureerd dingen proberen op een rijtje te zetten. Daar kiest men vaak doelbewust voor het wel of niet plaatsen van bepaalde (tussen)niveaus.

Puntje 3. nog even. Als in de eerste sectie (dus vóór het eerste kopje 2) een ===niveau 3=== kopje zit, dan is het vaak doelbewust gekozen dat dat een onderverdeling is die niet op hetzelfde niveau staat als de ==niveau 2== kopjes verderop. Als je dus van die niveau-3 -> niveau-2 maakt, dan splits je dus eigenlijk de eerste sectie: de eerste helft wordt dan de nieuwe kortere "intro-sectie"; de tweede helft wordt prompt gebombardeerd tot een nieuw afgezonderde niveau-2-sectie, terwijl het expliciet de bedoeling was dat deze een lager niveau had.

Stel weer een volgend fictief voorbeeld: in plaats van 1 artikel met toeristische info schrijft men een apart artikel per provincie. Op ==Niveau 2== komen enkel ==Bezienswaardigheden== en ==Praktisch==, en verder ==Referenties== en ==Externe links==. Om een of andere reden blijken de secties "Geografie" meestal erg beknopt en algemeen, dus hanteert men ze maar als intro-sectie v/h artikel. We beginnen immers meestal geen artikelen met een kopje, weet je wel. Dus

een of meer intro-alinea's met algemene beschrijving

==Kop2: Bezienswaardigheden==

==Kop2: Praktisch==

==Kop2: Referenties==

==Kop2: Externe links==

Stél dat in een specifiek artikel er toch wat extra duiding nodig is binnen die introsectie. Bijvoorbeeld: men besluit ipv de Belgische provincies Vlaams- en Waals-Brabant apart te beschouwen (het zijn aparte provincies), ze toch samen als het artikel "Brabant" te behandelen. Maar dan wil men in de intro eventjes wat opnemen om deze situatie te verhelderen. Omdat het te lang wordt, besluit de maker maar een ===Kop3: tussenkopje=== aan te leggen.
Immers, het hóórt in de intro, consistent met de andere artikelen. Het is een subkopje, maar het is géén ==Kop 2==. Waarom niet? Omdat je anders plots dat stuk van die intro afsplitst, en promoveert naar hetzelfde niveau van ==Bezienswaardigheden==, ==Referenties== en ==Externe links==. En dat was blijkbaar niet de bedoeling niet.

De introsectie is dan wel niet gevat onder een ==Kop2== kopjes, maar misschien is die conceptueel wel te zien als een sectie op ==Kop2== niveau ??

Vergelijk: een boek of artikel telt hoofdstuk 1, hoofdstuk 2, etc... Echter, er is vaak ook een inleiding en een voorwoord, die niet genummerd zijn. Toch gebeurt het wel eens dat je binnen de inleiding al een paar subkopjes hebt. Dat zijn echter subkopjes op een lager niveau dan de Hoofdstuk-nummering. Als je plots middenin je inleiding een subkopje gaat promoveren (zoals botjes nu dus durven doen), dan krijg je prompt een nieuw eerste hoofdstuk (die introtekst bevat), en schuift al de rest op. Dat kan niet de bedoeling geweest zijn.

Dergelijke fenomeen tref ik wel eens bij bepaalde dp's aan, waar de maker blijkbaar doelbewust voor zo'n indeling heeft gekozen.

Samengevat: waarom nu zo'n lang betoog over iets zo onnozel als die kopjes ;-) ?
In 95% of meer van de gevallen denk ik dat het effectief om slordigheden in de artikelen gaat, en doet de bot gewoon goed werk. Punt.
MAAR:

1. Houd er rekening mee dat auteurs vaak doelbewust voor bepaalde kopjes kiezen, puur en alleen voor hun uiterlijk
2. Houd er rekening mee dat zelfs als je erg gestructureerd gaat denken, er gevallen zijn waar kopjes op een verkeerd niveau lijken te staan, maar waar er wel degelijk een logica achter zit.
3. Het denken dat je de wiki-syntax 100% kunt gebruiken om structuur vast te leggen (helaas?) een utopie is, zoals dit ook met HTML vaak niet meer gebeurt. Niet enkel om de syntax op zich, maar ook om de manier waarop we onze artikelen opbouwen (bv introsecties zonder kopjes, bepaalde sjablonen die eigenlijk ook ergens binnen een hiërarchie zouden passen).

Ik vrees dat StefanKühn met zijn rigoureuze uitspraak hierboven zichzelf wat voorbijloopt ;-) en 100% rigoureus structuur pogen te brengen in iets dat er zich niet toe leent, met middelen die er niet helemaal voor geschikt zijn, dat zal niet lukken vrees ik ;-) Ik hoop dat men ook eens probeert stil te staan bij de reden dat op bepaalde plaatsen bepaalde kopjes werden gekozen - al dan niet terecht -. Ik zou zeggen, fix gerust kopniveaus, maar houd wel de editoriale overwegingen in het achterhoofd, en niet bepaalde structurele idealen die toch nooit helemaal kunnen lukken ;-)

Tot zover deze (veel te lange) lezing ;-) --LimoWreck 16 nov 2008 21:04 (CET)

Ik geef toe, in je voorbeelden zit er logica achter de keuze van de niveau's van de kopjes. Het zijn echter inderdaad fictieve voorbeelden. In een artikel als Koninklijk Huisarchief speelt die situatie helemaal niet en lijkt het zuiver te gaan om het visuele aspect. Ook gebruiken we geen HTML meer, maar XHTML waar de strikte structuur met elke versie weer meer terugkomt.

Stellen dat de gebruiker goed zit en de parser zich maar moet aanpassen is ook wel erg kortzichtig. Zoals ik in de lijst van argumenten heb aangegeven, het gedrag van de Mediawiki-parser kan veranderen (en heeft dat in het verleden ook al gedaan). Verder zijn we toch bezig een encyclopedie te maken die geschikt is voor hergebruikt, door mensen, maar ook door computerprogramma's en papieren uitgaven. Als je dan probeert te zorgen dat die allemaal zo min mogelijk moeite hoeven te doen bij de interpretatie is dat toch voor iedereen het beste?

Verder wordt er door de tegenstanders van het veranderen ook wel erg lichtvaardig gedaan over de mening van W3 vind ik, terwijl dat consortium toch dè autoriteit is op dit gebied. - Berkoet (voorheen Dammit) 16 nov 2008 21:23 (CET)

Heb je al eens de HTML van Koninklijk Huisarchief bekeken ;-) ? Na het openen van de <body>-tag komt er nooit <h1>-tag voor. Meer nog, vóór het eerste structurerende kopje, een <h2>-kopje (die dient voor de TOC, dit terzijde), komt er al heel wat informatie voor. Oók artikeltekst. Hier wordt serieus gezondigd tegen de hiërachie dus, nochtans is dit de meeste normale structuur van een wikipedia-artikel.

Als men zo rigoureus HTML willen volgen, dan moet je OOK de introsectie met een <h1>-kopje beginnen, en van daaruit verder bouwen. Ik wil gewoon maar aangeven: men poogt teveel een structurele systematiek toe te passen, waar dit instrument er zich niet altijd voor leent. Er bestaat bv. helemaal niet iets als "Preface" of "Frontmatter" of dergelijke die in andere talen wel bestaat, dus inherent zijn er tekortkomingen aan de taal om zijn model zomaar toe te kunnen passen op de manier waarop wikipedia-artikelen zijn opgebouwd ;-)

Nogmaals: ik wil zeker niet aangeven dat die kopfixes fout zijn; 95% van alle correcties die ik al heb zien passeren is gewoon goed hoor ! ;-) Ik stel gewoon dat men met zo'n strikte structuur als uitgangspunt veel te kort door de bocht gaat, of zichzelf helemaal voorbijloopt ;-) --LimoWreck 16 nov 2008 21:44 (CET)

Info

Hello, for your info. I have deactivated "4.1 Categorieën beginnend met kleine letter" and "4.6 Symbol for dead" for the nlwiki. Also I deactivated "4.3 HTML text style underline" for all wikipedias, but this has nothing to do with nlwiki. This part will not be inside in the text after the next automatic run in 24 hours. -- sk 15 nov 2008 21:40 (CET)

I have include the template Template:Bron in my script. Now my script will not include in "Article with <ref> and no <references />" article with this template. In the past I exclude only the template "refs" and "referenties". -- sk 16 nov 2008 08:45 (CET)

My apologises. I was wrong with the template {{Bron}}. After a second check, I noticed that this template does not include the references. Instead several inclusions of this template need to corrected on this wiki (in few cases, the behaviour of <references /> seems to have been emulated with numbered enumerations). The following templates are used as an alternative of <references /> and should be excluded:

{{referenties}} (already included)

{{noot label}}

{{noot}}

{{fnb}}

Thanks for your effort.

Annabel_(overleg) 16 nov 2008 09:48 (CET)

Ok, I have delete bron and exclude the other templates. -- sk 16 nov 2008 11:15 (CET)

Did you switch of the errorcategories by editing the file local on the server? I don't see changes in Wikipedia:Wikiproject/Check_Wikipedia/Vertaling and I would like to fix some translation errors as well. Can you make sure this page is up-to-date? Rudolphous 16 nov 2008 09:53 (CET)

Yesterday, I have run the script local at the toolserver, because there was a problem with the new dump of nlwiki and than I don´t copy the files in the output-folder. My change of the script was late in the evening, so that the normal run yesterday include all errors. Today the next run at nearly 16:00 UTC will not include the problem errors. -- sk 16 nov 2008 11:15 (CET)

For the translation: you can find here the latest version. -- sk 16 nov 2008 11:17 (CET)

Thanks for your answers. Now I understand better why yesterday a lot of new problems were detected. I can see the new dumpfile on: [1]. By the way, I made some improvements on the translationpage here today: http://nl.wikipedia.org/w/index.php?title=Wikipedia%3AWikiproject%2FCheck_Wikipedia%2FVertaling&diff=14550600&oldid=14497218. I translated more items to Dutch and switch of the same categories you mention (underscores, deadsymbol, categories with small letter). Does your perl script automatically download this version? Rudolphous 16 nov 2008 11:32 (CET)

Yes, my script check this site and will use your updates. -- sk 16 nov 2008 17:10 (CET)

I found another template which includes the references-tag: {{references}}. Annabel_(overleg) 16 nov 2008 15:17 (CET)

Ok, I add this, but it will be used tomorrow first, because the script is running now. -- sk 16 nov 2008 17:10 (CET)

@Rudolphous: Can you also translate the "Project description in english". In all other languages the user translate it too. It help to understand the project for all users in your language. Thanks. -- sk 16 nov 2008 22:12 (CET)

Verwijdernominatie

Graag zou ik een poging willen doen om de discussie rond dit project een beetje open te trekken. Kan iemand aangeven waar juist de gevoeligheden liggen bij de huidige stand van het Check wikipedia project? Wat is er tegen tegen de verschillende onderdelen? Er is namelijk al het één en ander verandert rond dit project sinds het tot stand kwam. Is het misschien een oplossing om af te spreken dat er voorlopig niet naar bepaalde punten gekeken wordt, zoals ik reeds vroeg met betrekking tot de kopjes? Wat is er behalve het botmatige wijzigen van kopjes en het ongepast wijzigen van de beginletter categorienamen foutgelopen en hoe kan het eventueel beter? Dit zijn enkele vragen die nu in me opkomen en het zou tof zijn als beide kampen (sorry van dit woordgebruik) rond dit project hierop in zouden kunnen gaan. Annabel_(overleg) 18 nov 2008 21:40 (CET)

Een aantal dingen, lijst is niet volledig:

1. een flinke groep gebruikers ergert zich in het algemeen aan nutteloze edits. Dat kan men irrationeel vinden, en dat is het misschien ook wel, maar het is evengoed een feit om rekening mee te houden. Als ik op mijn werk de hele tijd op tafel loop te trommelen, kan ik ook wel zeggen dat mijn kamergenoot zich daaraan niet hoeft te ergeren, dat-ie gewoon door kan werken zonder erop te letten, dat-ie dus een zeur is, maar zo werkt het natuurlijk niet. Of dit een vergelijkbaar ergernisniveau zou moeten opwekken, is natuurlijk vers 2.
2. een deel van de edits wordt irritant en kwestieus gevonden. Dat geldt vooral wanneer de "fix" ingaat tegen een welbewuste overweging van de auteur, zie bijvoorbeeld de klachten van Waerth en Wutsje over de kopjes. Hetzelfde geldt voor het per se willen toevoegen van een zichtbaar onderschrift bij plaatjes, iets wat voor het "project" niet eens als "fout" is gedefinieerd, zolang een alternatieve tekst beschikbaar is (dit ivm toegankelijkheid voor visueel gehandicapten etc.).
3. wat we nu zien, is onder andere dat gebruikers die geen enkele inhoudelijke affiniteit met een artikel hebben, het nochtans wel menen te kunnen gaan "fixen". Daar komen soms ook gedeeltelijk inhoudelijke beslissingen aan te pas, en dat gaat niet altijd goed. Vooral wanneer men denkt aan bezwaar 1. tegemoet te komen door er ook iets inhoudelijks bij te "fixen" gaat het geregeld fout.
4. sommigen ergeren zich aan de houding die volgens hen uit dit project lijkt te spreken, nl. dat standaardisatie per definitie goed is, en dat de auteur geen gebruik mag maken van bepaalde mogelijkheden van de MediaWikisoftware als dit niet binnen een bepaalde definitie van "standaard" of "syntactisch correct" valt.

Paul B 18 nov 2008 21:54 (CET)

(na bwc:) @Annabel: Er zijn een aantal redenen waardoor dit project controversieel is geworden, hoewel ik wel overtuigd ben van het nut van delen van het project. Als ik naar mijzelf persoonlijk kijk de volgende zaken: het project is zonder enige vorm van overleg door buitenstaander "over de schutting gegooid", met zaken waarvan het "fout" zijn twijfelachtig c.q. gewoon POV is (hoofdletter categorieën, meerdere categorieën op een regel, niveau kopjes, etc.). Deze zaken zijn er deels later uitgehaald, maar niet na veel irritatie en discussie, en toen waren er veel van die controversiële wijzigingen al botmatig doorgevoerd.... Met name ook het "blind" navolgen van die lijst door enige botoperators die vonden dat al die wijzigingen goedschiks of kwaadschiks doorgevoerd moesten worden en niet of nauwelijks voor overleg open stonden heeft in grote mate bijgedragen aan (in ieder geval mijn) irritatie.

Wat mij betreft hoeft het project niet per-se weg, maar wel graag a) voorlopig even stilleggen en graag consensus bereiken over welke zaken nou wel en niet gewijzigd moeten worden (en vervolgens alleen nog die zaken melden op de projectpagina waar consensus over is!), en b) graag wat meer inlevingsvermogen over en weer over de gevoeligheden die dit soort grootschalige wijzigingen met zich meebrengt.

Ad a): Wat mij betreft wel te wijzigen, mag botmatig: foute links, references. Alleen te wijzigen indien tegelijkertijd ook andere serieuze zaken worden gefixed (want de wiki-parser heeft er geen serieuze problemen mee): niet afgesloten tabellen, template programming, html, categorie-zaken (hoofdletters, cats op 1 regel), html. Wat mij betreft beslist niet te wijzigen: niveau's van kopjes.

Annabel, bedankt voor je poging om zaken vlot te trekken, hopelijk kan mijn reactie daar ook iets in betekenen. Tjipke de Vries 18 nov 2008 22:00 (CET)

Wat ik juist wil betrachten is irriterende bijdragen achterwege te laten. Hoe je het ook draait of keert, er is verkeerd omgesprongen met dit project. Laten we bepaalde discussies achterwege laten. De kopjesdiscussies is nog niet beslecht, maar waar zijn we het over eens? (lijstje is mijn POV)

1. De hoofdletters zijn uit het project gesloopt, gelukkig, wat betekent dat we er ook iets aan kunnen doen.
2. Voor zover ik kan overzien is men gemiddeld gesproken het er ook over eens dat meerdere categorieën op een aparte regel zetten niet kan als aparte bewerking. Als dit dan toch gebeurt zou dat niet gericht maar tesamen met andere nuttige botbewerkingen moeten kunnen gebeuren.

Misschien is het beter dat er ook niet met bots in dit project gewerkt wordt? Is dit nog wel relevant voor de items die nog op de lijst staan? Volgens mij is verder alles met de hand te doen. Tabellen waarvan de opmaak verkeerd loopt wegens niet afgesloten tags is niet echt iets voor een bot (die kan daar wel bij helpen, maar uiteindelijk is het manueel werken).

(@PaulB) Vergeef me, maar ik vermoed dat een deel irritatie onnodig ontstaan is, omdat er niet voldoende uitleg is gegeven. Ik denk daarbij bijvoorbeeld aan de beschrijvingen bij afbeeldingen. Op zich is dit wellicht vrij nutteloos als alles werkt. Het is echter ook onderdeel van de standaarden op het web (HTML, XHTML, etc.). Deze zijn zo ontworpen dat alle documenten op alle systemen identiek wordt weergegeven en tot deze standaarden behoort ook de uiteindelijke documentaal (XHTML) die door de mediawiki-engine geproduceerd wordt. Als je van standaarden te veel gaat afwijken kun je problemen krijgen (ik refereer naar browser-specifieke tags bij Internet Explorer, waardoor Microsoft nu veel moeite had om ondersteuning voor alle IE specifieke websites te blijven houden in zijn browser). Door het volgen van de HTML- en XHTML-standaarden is het juist mogelijk dat het internet werkt. Niet dat ik hier een pro-discussie wil afsteken, alleen tracht ik hier het andere standpunt weer te geven. Het is zo dat als we standaardiseren we moeten uitkijken hoe dat gedaan wordt en of het nodig is. "Per definitie" lijkt me dan niet de weg om verder te bewandelen, maar hoe kijk je daar zelf tegenaan? Als je het hebt over het syntactisch correct zijn, gaat het dan over de items in de sectie lage prioriteit, over de n-de-graadskopjes, of over nog iets anders?

Alvast dank voor de reacties; hoe meer, hoe beter dit afgehandelt kan worden naar ieders tevredenheid.

Annabel_(overleg) 18 nov 2008 22:32 (CET)

Ik ben zeer vergevingsgezind, Annabel ;) Van die vier punten weet ik zelf ook niet helemaal in hoeverre ze mij irriteren, dus voel je vrij mij daarover aan de tand te voelen. Wat de kopjes betreft (want daar heb ik het inderdaad voornamelijk over): ik wil hier natuurlijk niet beweren dat ik het beter weet dan de standaarden, maar er is één punt waarop dingen soms de mist in lijken te gaan: het star opleggen van deze standaarden op dezelfde wijze aan alle artikelen, groot of klein. Er ontbreekt een bepaalde flexibiliteit: voor een artikel van 10 regels gebruiken we dezelfde structuur als voor een artikel van 10 pagina's. Dat wringt af en toe. Het gebruik van level-2 kopjes in artikelen van 7 regels komt potsierlijk over, en ik kan het bijv. in css niet wijzigen zonder dat de kopjes in artikelen van 10 pagina's belachelijk klein worden. Het is bij strikte toepassing van de "standaarden" bijv. ook niet mogelijk om (zoals Waerth opmerkte) tussenkopjes in een inleidende paragraaf te gebruiken, tenzij we expliciet "inleiding" in vette letters boven die paragraaf zetten. We lopen hier dus wmb een beetje aan tegen de grenzen van de standaardisering. De MediaWiki-software biedt echter een zekere "flexibiliteit", of "tolerantie" zo je wil, en auteurs maken daar gebruik van om het document te structureren op een manier die hun zinvol voorkomt. We moeten heel erg uitkijken dat we niet de syntactische structuur bovenaan stellen in plaats van de inhoudelijke structuur. Wij zijn een encyclopedie en geen gestructureerde database; een kopje heeft een bepaald "niveau" omdat de informatie die eronder valt een bepaald "niveau" heeft, niet omdat het kopje nu eenmaal op niveau X zit in een boomstructuur. Het verschil tussen implementatie van proprietary tags en een ietwat flexibele omgang met de kopjeshierarchie lijkt me verder evident. Paul B 18 nov 2008 22:52 (CET)

Het lijkt er eerder op dat auteurs soms de koppen die ze gebruiken af stemmen op hoe het er volgens hun uit moet zien als om een artikel te structureren. Fenke 22 nov 2008 03:05 (CET)

Volgens mij hebben we drie groepen:

1. groep die tegen deze pagina hoe dan ook is
2. groep die tegen sommige categorien is
3. groep die alle categorie wil doorvoeren

Tjipke de Vries beschrijft een soort van middenweg.

Allicht handig om de categorieën waar groep 2 en 3 het over eens is, als eerste door te voeren.

We kunnen dan later kijken hoe we met de categorieën omgaan, bijvoorbeeld:

• peiling
• afspreken dat deze alleen worden doorgevoerd met andere nuttige bewerkingen
• gewoon niet doorvoeren
• verder discussiëren en bepalen wat we doen

Het lijkt me verder nuttig als we op een bepaalde manier syntaxfouten die definitief geen probleem zijn, ook definitief van deze lijst kunnen schrappen. Misschien kunnen we deze opnemen op een bepaalde pagina, die de Checkwikipedia-parser dan weer voor elke run uitleest, of een {{sjabloon:nobots|checkwikipedia}} op dit soort artikelen. Rudolphous 18 nov 2008 22:45 (CET)

Discussieversnippering, niet erg handig.. Thoth 21 nov 2008 15:03 (CET)

De discussie over de verwijdering loopt op de lijst met te verwijderen pagina's. Wanneer er verbetervoorstellen komen, dan wil ik in eerste instantie een verbetering op het vlak van communicatie zien in dit project. Op dit moment wordt de projectpagina door een bot in alfaversie volgeplempt met allerhande te wijzigen artikelen met telkens nieuwe "fouten". Discussie daarover gebeurt achteraf in een andere taal op een overlegpagina van een gebruiker die geen Nederlands spreekt. Op zo'n manier zet je geen wikiproject op. Wie voorstander is van zulk gepruts, heeft geen oog voor kwaliteit. Wanneer er een goed plan tot het ombouwen van dit project naar een levensvatbaar project is, dan zie ik dat graag verschijnen. Wie denkt dat we er met enkele wijzigingen op details wel komen, kan beter ophouden: de hele opzet van dit project deugt niet - Quistnix 21 nov 2008 17:48 (CET)

Lijst van controversiële "kopfixes"

Hieronder een lijst van artikelen die niet conform Check Wikipedia zijn (of waren) en waarbij kopfixes ter discussie gesteld worden. Graag zou ik iedereen bij deze willen oproepen de lijst uit te breiden met concrete voorbeelden:

• Baas Boppe Baas (Wutsje)
• Eeltsje Hettinga (Wutsje)
• Faeröerse Volkshogeschool (Wutsje)
• Gavdopoula (Wutsje)
• Helena de Boer (Wutsje)
• Hylkje Goïnga (Wutsje)
• It Fryske Boek (Wutsje)
• Jetske Bilker (Wutsje)
• Jorge Semprún (Wutsje)
• Keyshia Cole (Wutsje)
• Koninklijk Huisarchief (Wutsje)
• Leonardo Padura Fuentes (Wutsje)
• Lucas-Ooms Fonds (Wutsje)
• Meindert Bylsma (Wutsje)
• Wetterskip Fryslân (Wutsje)
• Diffusie (Josq)
• DNA (Josq)
• Stopplaats Amsterdam Petroleumhaven (Paul B)
• Koppelteken in afleidingen (Paul B)
• Lijst van Groninger kerken (Paul B)
• Lijst van Filipijnse senatoren (Magalhães)
• Overzicht van ingehouden winsten (Mwpnl)

Rudolphous 18 nov 2008 23:08 (CET), bijgewerkt Josq 18 nov 2008 23:20 (CET) — bijgewerkt nl:Mark W (Mwpnl) ¦ talk 21 nov 2008 17:13 (CET).

Ik mag trouwens hopen dat deze lijst enkel als illustratie dient, en niet als een verkapte opt-out waardoor alle andere artikelen "vogelvrij" zijn. Ik heb niet zo'n zin in "kopjesreservaten" waar men zich moet aanmelden omdat anders de bots uw artikel komen assimileren :( Paul B 21 nov 2008 17:16 (CET)

In dat licht zou ik het botmatig aanpassen van artikelen vanwege kopfixes niet te honoreren en aanpassingen handmatig mét reden uit te voeren. Men mag er toch vanuit gaan dat subkopjes met een goede reden gekozen zijn. Ongedaan maken mag daarom — wat mij betreft — alleen met goede reden geschieden. nl:Mark W (Mwpnl) ¦ talk 21 nov 2008 17:29 (CET)

In een willekeurige selectie van artikelen ("It Fryske Boek", "DNA" en "Meindert Bylsma") zag ik geen enkele reden om de 'structuur' waarin ze zijn geplaatst te behouden. 22 nov 2008 03:15 (CET)

Afbeelding zonder omschrijving

Op de lijst "Afbeelding zonder omschrijving" komen veel afbeeldingen van logo's voor. Het is onnodig die te ondertitelen, zullen we die gewoon van de lijst afhalen? Ik weet alleen niet hoe dat moet, zonder dat ze steeds weer terugkomen. Weet iemand dat? Ilonamay 20 nov 2008 12:29 (CET)

Zet er gecheckt achter. Evenals bij andere 'fouten' die helemaal geen fouten zijn. Josq 20 nov 2008 12:31 (CET)

Het project heeft manco's. De persoon die ons dit project heeft opgedrongen spreekt geen Nederlands en weigert in te gaan op redelijke bezwaren die in het Engels met hem worden gecommuniceerd. Dit project heeft in de huidige vorm wat mij betreft geen toekomst - Quistnix 20 nov 2008 12:43 (CET)

@Hello Ilonamay: All pictures should have a description. For example blind person need this description. Also images with logos should have a description. -- sk 20 nov 2008 21:58 (CET)

I agree with that. The question then is whether to make the text visible. In the cases that Ilonamay mentions, it might be an idea to not make the text visible, as in the figure below. Paul B 20 nov 2008 22:12 (CET)

Ik ben het daar mee eens. De vraag is dan wel of we de tekst zichtbaar moeten maken. In de gevallen die Ilonamay noemt, zou het een idee kunnen zijn om de tekst niet zichtbaar te maken zoals in de figuur hieronder. Paul B 20 nov 2008 22:21 (CET)

Goed idee, Paul! Josq 20 nov 2008 22:16 (CET)

Zou inderdaad en prima oplossing zijn! Als dit ook werkt voor blinden... Ilonamay 20 nov 2008 23:20 (CET)

@Stefan, would this be enough for blind people to know what the picture is about? You mentioned a blind person as an example, what others need a description? Ilonamay 20 nov 2008 23:20 (CET)

Yes, this is enough. I want only that every image has an alternativ text. Blind people or image search machines (for example [2]) need this image description.-- sk 21 nov 2008 08:58 (CET)

Als iemand hier in het Engels gaat zeggen dat All ... should.. dan kan ik het slechts volledig met Quistnix eens zijn, nooit meer een project toelaten voordat dit besproken en goedbevonden is. Peter b 21 nov 2008 00:49 (CET)

Nee, dat gaat te ver, dat verlamd de gemeenschap en maakt innovatie bijna onmogelijk. We zullen echt ons gezonde verstand moeten blijven gebruiken. Josq 21 nov 2008 01:35 (CET)

Het is helemaal NIET nodig om daar overal een "onderschrift" bij te hebben. Je moet er dus niet overal noodzakelijk "frame" of "thumb" van maken. Dat kan om diverse redenen onnodig zijn, vb logo's, zoals al aangehaald, of om andere stilistische redenen. Neem nu de lijsten van windmolens, met tientallen afbeeldingen in tabellen. Daar doe je dat toch ook niet ?!. Slechtzienden hebben daar ook niet noodzakelijk wat aan, aan die thumb of dat frame. Dus ga aub niet zomaar afbeeldingen die niet in een frame of thumb zitten er nodeloos induwen als men dat misschien om goede redenen niet gekozen heeft.

Wat wel altijd aan te raden is, is toch een afbeeldingsbeschrijving toe te voegen, zoals Paul B hierboven toont. Ik veronderstelde dat mensen die met dit "project" bezig waren dat wisten... niet dus ? (des te meer een teken dat dit slecht georganiseerd is; sommigen weten maar half wat ze aan het doen zijn en waarom? Dus de opmerkingen van Quistnix zijn dan wel terecht natuurlijk). Wanneer je zo de beschrijving toevoegt, dan komt die tekst in het artikel inderdaad niet onder de afbeeldingen zoals Paul toont. Maar dan komt het wel in de gegenereerde HTML in de het alt-attribuut. <img src="..." alt="...">. Maar waarom is daar een wiki-project voor nodig? Dat wordt toch al jaar en dag zo aangeraden het zo te doen ? Die inhoud van die alt-attribuut wordt vaak getoond door tekstuele browsers, en ik dacht dus ook browserhulpmiddelen voor slechtzienden. Ook in onze gekende browsers: als de browser (dus niet de wikisoftware) de afbeelding niet vindt, dan verschijnt een kader/icoon/... (naargelang implementatie) met die alt-text indien aanwezig. Of indien je in je browseropties het laden/weergeven van afbeeldingen uitschakelt, krijg je die alt-text. (Probeer maar eens in Firefox of IE, het staat wel ergens in de opties). Dus dat is voor iedereen handig. (Zie https://www.xs4all.nl/~sbpoley/webmatters/alt.html ) Maar dat betekent dus helemaal niet dat je afbeeldingen per se in frames/thumb moet gaan duwen. --LimoWreck 21 nov 2008 01:46 (CET)

Onafgemaakte Wikiprojecten worden hier gedumpt door niet-Nederlandssprekenden

Het kan toch niet zo zijn dat iedere willekeurige gebruiker vanuit een andere wiki ons zijn POV oplegt zonder dat we met hem kunnen communiceren? Op Wikipedia:Wikiproject/Check Wikipedia wordt ons verteld wat er allemaal niet deugt aan onze wiki: meerdere categorieën op 1 regel: schande! Categorieën niet met een hoofdletter gelinkt vanuit het artikel: vreselijk! En als er al wordt gereageerd op commentaar is het: "ach, dit is maar een alfa-versie". Alsof nl.wikipedia een speeltuin is!Ik stel voor om geen wikiprojecten toe te laten zonder dat er een Nederlandssprekende gebruiker als aanspreekpunt is aangewezen. Overleg op Overleg Wikipedia:Wikiproject/Check Wikipedia - Quistnix 21 nov 2008 00:45 (CET)

POV? Wat heeft dat er mee te maken, het gaat om schoonheidsfoutjes in artikelen. Benoem je nu alles wat jou tegenstaat als POV? Fenke 21 nov 2008 09:25 (CET)

Als je zo nodig een Nederlandssprekend aanspreekpunt wilt, wil ik me wel beschikbaar stellen hoor. - Berkoet (voorheen Dammit) 21 nov 2008 09:32 (CET)

Ik stel voor dat we op Overleg Wikipedia:Wikiproject/Check Wikipedia hierover verder praten - Quistnix 21 nov 2008 09:37 (CET)

(na BC) @Fenke: Zie mijn voorbeelden. Alles wat de MediaWiki-software begrijpt, is niet fout. Dat iemand het niet mooi vindt, dat is POV. Moeten we ons daardoor laten leiden? Er bestaan dingen als "overleg" en "consensus". Jij gebruikt precies dezelfde redenering om mijn opmerking POV te noemen als die ik gebruik om het hele project POV te noemen. Maar goed, wanneer jij je oren wilt laten hangen naar de mening van de eerste de beste dan staat dat jou vrij. Zo lang IK dat maar niet hoef te doen - Quistnix 21 nov 2008 09:35 (CET)

Je hebt daar wel een punt, Quistnix. De Nederlandstalige Wikipedia moet zichzelf autonoom beheren. Tenslotte gaan wij ook niet op vreemde wiki's zeggen wat zij daar moeten doen. - Vriendelijke groeten, Ben Pirard 21 nov 2008 09:53 (CET)

Hemel! Ik dacht toch echt dat wij zelf 'verbeteraars' genoeg hadden. beetjedwars 21 nov 2008 10:23 (CET)

Ik benoem jouw opmerking helemaal niet als POV, Quistnix, ik stel juist dat POV er niets mee te maken heeft. Je gebruik van de term POV is misplaatst, NPOV (en daarmee verbonden het begrip POV) is een wikipedia richtlijn met betrekking tot de inhoud van artikelen in de hoofdnaamruimte. Door toepassing van dat begrip in deze context geef je je bezwaar meer belang dan het toekomt - en tegelijkertijd devalueer je de richtlijn.

Overigens is niet alles wat mediawiki software begrijpt automatisch 'niet-fout', je kunt totaal onleesbare artikelen schrijven die de software prima kan verwerken. Fenke 21 nov 2008 15:16 (CET)

Dit hele project is gebaseerd op het leesbaar maken van Wikipedia-artikelen voor slecht geprogrammeerde bots. De problemen liggen in hoofdzaak bij die bots die totaal geen deel uitmaken van het Wikimedia-project. Het is onzin om onze artikelen daar op af te stemmen. Wanneer je er anders over denkt, is die denkwijze POV. Wanneer je vervolgens probeert een hele gemeenschap te mobiliseren om de bewerkingen voor je uit te voeren, ben je m.i. verkeerd bezig. Wie erop ingaat, denkt m.i. niet na ov er datgene wat hij aan het doen is. Dat is mijn mening - Quistnix 21 nov 2008 16:54 (CET)

Als je meent dat je die bots beter kunt programmeren, dan ga je gang. Zo niet, of wanneer je - zoals ik vermoedt - niet eens kunt programmeren dan dien je je in te houden met het beoordelen van programma's.

Je bevestigd wat ik al dacht; als iemand 'er anders over denkt' dan is dat voor jou POV. Daarnaast lijk je van mening te zijn dat jij kunt bepalen hoe een anderen wel of niet mogen bijdragen - en zeker niet op een manier die jij niet zinvol vindt. Ik vraag me af wat schadelijker is, jouw houding of een lijstje met schoonheidsfoutjes. Fenke 22 nov 2008 03:00 (CET)

Ik ga niet in op je lage opmerkingen. Als dat de enige manier is om dit project te cverdedigen, is het ten dode gedoemd en hoef ik alleen maar de tijd af te wachten totdat verstandige mensen weer de overhand krijgen en de rotzooi gaan opruimen die nu ontstaat - Quistnix 22 nov 2008 12:21 (CET)

Het zou inderdaad een goede zaak zijn als je even afwacht hoe het zich ontwikkelt. Fenke 22 nov 2008 17:25 (CET)

Dag Quistnix, zou je even je mening hierboven kunnen geven bij het kopje Verwijdernominatie? Ik zou dit bijzonder appreciëren. Annabel_(overleg) 21 nov 2008 11:47 (CET)

Ik dacht dat ik daar niets meer aan toe te voegen had. Er spelen wat mij betreft twee zaken: ten eerste het opstarten van dit onzinnige project en ten tweede in het algemeen het dumpen van slecht voorbereide ("dit is slechts een alfa-versie") projecten op nl.wikipedia door mensen die het Nederlands niet machtig zijn en ook weigeren normale discussies te voeren omtrent hun projectjes. nl.wikipedia is geen speeltuin! Wanneer iemand zo nodig een project hier wil lanceren, zou er m.i. een Nederlandssprekend contactpersoon moeten zijn met wie problemen kunnen worden besproken en wel voordat de zaak volledig uit de hand loopt. - Quistnix 21 nov 2008 17:00 (CET)

Ik dacht het wel. Ik heb nog geen reacties ten gronde van je gezien. Je mening over de totstandkoming van het project heb je geventileerd en hoe er mee omgesprongen werd, maar hoe we tot een oplossing komen die voor ieder aanvaardbaar is ... Annabel_(overleg) 22 nov 2008 09:44 (CET)

Quistnix heeft goede redenen dit aan de orde te stellen. Er is hier in de VS sinds de Clinton-dagen van 'politieke correctheid' een peperdure overdrijving aan de gang, waarbij bijvoorbeeld allerlei zaken omgebouwd moeten worden om alles toegankelijk te maken voor gehandicapten. Op zich natuurlijk een goede zaak dat daar (eindelijk) aandacht aan geschonken wordt maar hier in de VS is het vaak ofwel jaaaren lang stilstaan ofwel zo hard hollen dat je op je snufferd gaat. Er worden dus miljoen uitgegeven aan het anleggen van allerlei hellingen waar zelden of nooit iemand gebruik van maakt. Alle redelijkheid is volledig zoek. En geld om redelijke en nodige zaken te bekostigen is nu goed op.

Er schijnt zo dus ook een of andere ambtenaar bedacht te hebben dat het een goed idee zou zijn alle afbeeldingen op het internet van een onderschrift te voorzien. Uiteraard zonder zich af te vragen of dat altijd wel mogelijk of zelfs nuttig is. Hier op wiki zijn er veel diagrammen enz die juist gemaakt worden omdat het moeilijk is iets in woorden duidelijk te maken. Maar die ambtenaar in Washington DC heeft bedacht dat dat toch moet en dus moeten wij dat nu ook. Slechte zaak, dat. Ja dat is mijn POV, maar de vraag is of er niet meer mensen een probleem hebben met dit soort onredelijk geringeloor. Het probleem is dat als je daar een keer aan toegeeft dat het steeds erger wordt. Jcwf 22 nov 2008 03:16 (CET)

Mh, je bent dan zeker ook van mening dat die klikkende uitbreidingen van verkeerslichten ten behoeve van blinden en slechtzienden overbodig zijn, of die geribbelde tegels op stations en bij trappen. Fenke 22 nov 2008 17:25 (CET)

Voorstel

Dit is een goed project, op deze manier worden fouten getraceerd en kunnen ze sneller verbeterd worden. We hoeven alleen te bekijken welke van de "fouten" wij ook daadwerkelijk willen veranderen. Voorstel: laat alleen de volgende prioriteiten staan en haal de andere van deze lijst. Het blokkeren van steeds terugkomende items moet mogelijk zijn.

* Afbeelding zonder omschrijving 
* Foute links 
* Fouten in de referenties
* Tabellen zonder juist eind 
* HTML gebruik

In overleg kan daar nog iets aan toegevoegd worden. En we laten de rangorde in koppen voor wat ie is, want dat genereert de meeste irritatie. Ilonamay 23 nov 2008 15:00 (CET)

Dat lijkt mij een heel goede start. Ik ben alleen bang dat zowel de fervente voorstanders als de fervente tegenstanders zich wellicht te diep hebben ingegraven in hun respectievelijke loopgraven. Maar mijn goedkeuring zou zoiets zeker kunnen wegdragen. Paul B 23 nov 2008 16:12 (CET)

Ik denk dat dat de belangrijkste 'fouten' zijn (de laatste is niet direct fout; gewoon html-code ipv wikicode. Zolang er geen fout in de html-code zit dan is het goed :D) Sum U ^?rai8^{? Need a tool?}- 24 nov 2008 09:06 (CET)

Ik kan mij hierin vinden, mits:

1. er eenduidig een Nederlandssprekende persoon wordt aangewezen (eventueel met plaatsvervanger) voor de communicatie over dit project;
2. er geen nieuwe al dan niet vermeende soorten fouten in de lijst worden opgenomen zonder overleg vooraf.

Quistnix 24 nov 2008 10:49 (CET)

Heb de pagina behouden vandaag, maar de laag en middelmatige prioriteit (fraaie aanduiding, middelmatig) geschrapt. Kan iemand er voor zorgdragen dat deze niet opnieuw geintroduceerd worden? Jacob _overleg 28 nov 2008 09:24 (CET)

Niet zo'n gelukkige keuze, zo is "ref's zonder references" zeker nuttig en wijst het vrijwel altijd op een fout. Html hoort vermeden te worden waar mogelijk en waar dit niet gebeurt mag zeker op die lijst.

Er zijn meer mensen tegen verwijderen dan voor, dus die 'heb de pagina behouden vandaag' is volstrekt misplaatst. Laat alles er even op staan dan kan iedereen alle onderdelen zelf beoordelen. Fenke 28 nov 2008 11:59 (CET)

Dat laatste blijkt dus sowieso niet mogelijk, men "fixt" blijkbaar gewoon wat er op de lijst staat zonder zelf na te denken of het wel nodig/wenselijk is. De "refs zonder references" mogen er van mij meteen weer op, want dat is een bijzonder nuttig deel van deze lijst. Paul B 28 nov 2008 12:22 (CET)

Kennelijk is het voorstel niet serieus: men doet gewoon alsof zijn neus bloedt en gaat op de oude voet door. Er blijkt uit de peiling op de verwijderlijst zowel onder de voor- als tegenstanders een wens tot verbetering van het project. Wanneer er niets verandert, blijft dit een ongewenst project en moet het middels een peiling of stemming worden opgedoekt - Quistnix 28 nov 2008 15:15 (CET)

Wie gaat er op oude voet verder? Rudolphous 28 nov 2008 15:19 (CET)

Ik néém aan dat de routine wordt aangepast zodat de minder belangrijke issues niet terugkomen. Dat is het compromis tussen voor- en tegenstanders. Jacob _overleg 28 nov 2008 15:22 (CET)

Prima, ik wacht het uitgewerkte compromis af. Mijn vorige commentaar is alleen maar relevant wanneer uitwerking van het compromis uitblijft - Quistnix 28 nov 2008 15:32 (CET)

Sowieso Jacob, wie heeft jou het recht gegeven die "keuze" maar even te maken? Weer je eigen interpretatie van de verwijderlijst? De uitkomst kwam niet overeen met jouw mening dus ga je zelf nog wat dingetjes doen? Zo werkt dat niet he, jij bepaald niet zomaar wat er wel en niet uit kan, weer een puntje op je lijst van onverantwoordelijke bijdragen. Thoth 28 nov 2008 15:38 (CET)

Zo komen we nooit ergens. Er kan JacobH niets verweten worden, als dit project op de verwijderlijst wordt gezet is het aan de moderator "van dienst" een beslissing te nemen. @Rudolphous ik denk dat Quistnix mij bedoelt met op de oude voet verder, ik heb voorzichtig geprobeerd een paar tweede graads koppen te "herstellen" ik blijf er verder vanaf. Ik denk dat jij de aangewezen persoon bent om genoemd compromis uit te werken, als moderator beschik je over meer mogelijkheden en jij hebt de meeste tijd erin gestoken. Wat vind je van mijn oorspronkelijke voorstel? Ilonamay 28 nov 2008 17:55 (CET)

Er waren geen voorwaarden gekoppeld aan het behoud van de pagina en zoals hij het stelt lijkt het daar wel op. Vervolgens snijdt hij rigoreus vanalles weg uit de

Verder kan er wel wat voorgesteld worden, maar daaraan kunnen verder geen rechten ontleent worden, kan er geen compromis mee worden afgedwongen, en kunnen ze anderen niet beperken in hun bewerkingen. Je kunt op geen enkele wijze eisen dat iemand niet de koppen structuur aanpast, of html vervangt door wiki code. Fenke 29 nov 2008 03:41 (CET)

Dank voor je uitermate cooperatieve opstelling. Precies wat we op dit moment nodig hebben. Paul B 29 nov 2008 05:20 (CET)

Mooi. Ik ga een stemming over dit project voorbereiden - Quistnix 29 nov 2008 09:51 (CET)

Spijkers met koppen! Dat hebben we nodig:-) Ilonamay 29 nov 2008 13:50 (CET)

Dank je, je zou er van kunnen leren, tenslotte lijkt dit project bedoelt om Wikipedia te verbeteren. Fenke 30 nov 2008 00:43 (CET)

Helaas trek je er zelf geen lering uit, anders zou je verstandiger opmerkingen hebben gemaakt. Met dit project legt 1 persoon de gehele gemeenschap zijn wil op. Dit heeft meer met dictatuur te maken dan met een gemeenschapsproject - Quistnix 30 nov 2008 22:16 (CET)

Wat een drama maak je er van, behalve jij is er hier niemand die een ander zijn wil probeert op te leggen. Dit project maakt wat lijstjes met fouten en onvolkomenheden in artikelen, meer niet, en of iemand daar vervolgens wat mee doet is hun zaak, niet de jouwe. Fenke 1 dec 2008 09:00 (CET)

Ik zie geen enkele poging om tot onderling overleg te komen. Nogmaals: dit is een gemeenschapsproject en dit soort individuele acties zonder communicatie met anderen ondermijnt de kern van Wikipedia. Ik ga door met het opzetten van een stemming om ofwel commuinicatie op gang te brengen, ofwel dit ongewenste project te stoppen - Quistnix 6 dec 2008 13:17 (CET)

Iedereen kan en mag artikelen schrijven en projecten starten, ook zonder dat jij daar toestemming voor geeft. Er is een stemming geweest, de pagina kan blijven. Als er iets ondemijnend voor Wikipedia is, dan is het wel alle overbodige drama waar jij mee komt. Zeg gewoon wat je hebt te zeggen en blaas het niet allemaal zo op. Fenke 6 dec 2008 15:38 (CET)

Even het volgende:

Iedereen kan en mag artikelen schrijven en projecten starten, ook zonder dat jij daar toestemming voor geeft.

Correct, maar de basis van Wikipedia is en blijft consensus. Quistnix is lang niet de enige die problemen heeft met dit project, met specifieke onderdelen daarvan en met de manier waarop dit project is opgezet en wordt uitgewerkt.

Er is een stemming geweest, de pagina kan blijven.

Nee, dat was geen stemming, maar een raadgevende peiling, op basis waarvan de behandelende moderator een beslissing heeft genomen. Het geheel verwijderen van de pagina is in principe niet de beste optie, omdat er ook veel op staat dat wel zonder meer aangepast kan worden. Maar het probleem dat er ook veel op staat dat wel aanleiding geeft tot problemen, blijft staan. Een gedetailleerde afstemming is niet iets wat een moderator n.a.v. een verwijderingsnominatie even kan doen.

Zeg gewoon wat je hebt te zeggen en blaas het niet allemaal zo op.

Volgens mij is dat precies wat Quistnix en anderen doen, maar dit lijkt in enkele gevallen stelselmatig genegeerd te worden. Voorzover de problemen van de kant van de "tegenstanders" worden opgeblazen, worden zij net zo goed door voorstanders gebagatelliseerd.

Voor de rest zou ik willen zeggen: centraal overleg is zeker niet altijd nodig (liever niet zelfs, dat leidt meestal alleen maar tot bureaucratie), maar in dit geval lijkt het me onvermijdelijk. Zowel voor- als tegenstanders van bepaalde onderdelen zijn nogal koppig (en ikzelf ga daarin zeker niet vrijuit). Ik denk dat het praktische voorstel hieronder naar iets zinvols aan het convergeren is, maar ik had liever gezien dat vooraf bedacht was welke wijzigingen überhaupt nuttig en noodzakelijk waren, voordat iedereen zich in dit project stortte. Paul B 6 dec 2008 15:55 (CET)

Voorstel 2

Ik stel voor dat we als volgt gaan werken: Voor meer tekstuele uitleg over categorieën: Wikipedia:Wikiproject/Check Wikipedia/Vertaling

Prio High

Nr	Prio nu->gewenst	Omschrijving	Voorstel werkwijze
003	M->H	Article with <ref> and no <references />	Mag zonder meer worden opgelost
005	H	Comment not correct	Mag zonder meer worden opgelost
006	M->H	DEFAULTSORT with special letters	Mag zonder meer worden opgelost
008	H	Headline should end with "="	Mag zonder meer worden opgelost (liefst niet, te veel discussie over. Ook vals positieven aanwezig. Annabel(overleg) 1 dec 2008 21:56 (CET))
010	H	Square brackets not correct	Mag zonder meer worden opgelost
013	H	Math not correct	Mag zonder meer worden opgelost
014	H	Source not correct	Mag zonder meer worden opgelost
015	H	Code not correct	Mag zonder meer worden opgelost
019	H	Headlines start with one "="	Mag zonder meer worden opgelost (liefst niet, te veel discussie over. Annabel(overleg) 1 dec 2008 21:56 (CET))
023	H	Nowiki not correct	Mag zonder meer worden opgelost
024	H	Pre not correct	Alleen oplossen als het artikel wordt verbeterd
028	H	Table not correct	Mag zonder meer worden opgelost
032	H	Double pipe in one link	Mag zonder meer worden opgelost
034	H	Template programming element	Mag zonder meer worden opgelost
035	H	Gallery without description	Mag zonder meer worden opgelost
036	L->H	Redirect not correct	Alleen oplossen als het artikel wordt verbeterd

Prio Medium

Nr	Prio nu->gewenst	Omschrijving	Voorstel werkwijze
004	M	Weblinks zonder kopje	Mag zonder meer worden opgelost
007	H->M	Headlines start with three "="	Mag worden opgelost, indien geen bewuste keuze door auteur
017	M	Category double	Mag zonder meer worden opgelost
029	H->M	Gallery not correct	Mag zonder meer worden opgelost
030	H->M	Image without description	Mag zonder meer worden opgelost
037	L->M	Title with special letters and no DEFAULTSORT	Nieuwe test, misschien naar M? Jelte 1 dec 2008 21:32 (CET)

Prio Low

Nr	Prio nu->gewenst	Omschrijving	Voorstel werkwijze
002	H->L	Article with false <br/>	Mag zonder meer worden opgelost
009	L	Categories more at one line	Alleen oplossen als het artikel wordt verbeterd
012	L	HTML List elements	Alleen oplossen als het artikel wordt verbeterd
021	L	Category is english	Alleen oplossen als het artikel wordt verbeterd
022	L	Category with space	Alleen oplossen als het artikel wordt verbeterd
025	M->L	Headline hierarchy	Alleen oplossen als het artikel wordt verbeterd
031	M->L	HTML table element	Alleen oplossen als het artikel wordt verbeterd

Prio 0 -> niet belangrijke wordt niet getoond

Nr	Prio nu->gewenst	Omschrijving	Voorstel werkwijze
001	0	No fat title	Vaak lijsten en overzichten. Jelte 1 dec 2008 21:32 (CET)
011	0	Curly brackets not correct	Test werkt momenteel niet volledig correct Jelte 1 dec 2008 21:32 (CET)
016	0	Line very long	Meestal fout positief Jelte 1 dec 2008 21:32 (CET)
018	0(->L?)	Category first letter small	Misschien naar L? Jelte 1 dec 2008 21:32 (CET)
020	L->0	Symbol for dead	Niet oplossen!
026	L->0	HTML text style element <b>	Alleen oplossen als het artikel wordt verbeterd
027	0	Long line	Meestal fout positief Jelte 1 dec 2008 21:32 (CET)
033	0(->L?)	HTML text style underline	Misschien naar L? Jelte 1 dec 2008 21:32 (CET)
038	L->0	HTML text style element <i>	Alleen oplossen als het artikel wordt verbeterd
039	L->0	HTML text style element <p>	Alleen oplossen als het artikel wordt verbeterd
040	L->0	HTML text style element <font>	Alleen oplossen als het artikel wordt verbeterd
041	L->0	HTML text style element <big>	Alleen oplossen als het artikel wordt verbeterd
042	L->0	HTML text style element <small>	Alleen oplossen als het artikel wordt verbeterd

Kortom:

• H = Mag zonder meer worden opgelost
• M = Alleen oplossen als het artikel wordt verbeterd
• L = Alleen oplossen als het artikel wordt verbeterd, en bij voorkeur als alle M gedaan zijn

Rudolphous 29 nov 2008 10:40 (CET)

Ziet er okee uit, met twee opmerkingen:

• Ook voor de "headline hierarchy" geldt dat het een keuze van een of meer auteurs van het lemma kan zijn, en dat het dus niet zonder meer "opgelost" moet worden, ook niet als andere zaken in het lemma woren aangepast.
• Voor de plaatjes zonder bijschrift zal de "fixer" moeten proberen in te schatten of er een expliciet zichtbaar bijschrift bij moet komen of dat kan worden volstaan met een normaliter niet zichtbare "alternatieve tekst" die dan wel gebruikt kan worden door visueel gehandicapten of gebruikers die geen plaatjes willen/kunnen laden.

Paul B 29 nov 2008 13:39 (CET)

"Pre not correct" kan wat mij betreft naar de hoogste prioriteit. Jelte 30 nov 2008 21:38 (CET)

En voor "Redirect not correct" geldt hetzelfde. Ook heb ik de tabel aangevuld met ontbrekende en nieuwe tests (inclusief commentaar). Jelte 1 dec 2008 21:32 (CET)

En "Gallery without description" hoort denk ik bij M (ongeveer gelijk als "Image without description"), en "Category double" hoort denk ik bij H, omdat vreemde situaties kan opleveren (zoals met degenstrijdige sortering en als je de categorie probeert te wijzingen) Jelte 1 dec 2008 21:47 (CET)

En nu ik toch bezig ben: "Article with false <br/>" kan wel naar L, want in de XHTML-uitvoer wordt het al gefixt door de parser, dus hoort deze test eigenlijk bij de andere broncode-schoonheidsfoutjes. Jelte 1 dec 2008 21:57 (CET)

Goed voorstel. Aan het toevoegen van beschrijvingen bij afbeeldingen zou ik wel willen toegen om er niet per se "thumb" van te maken zodat de afbeeldingsbeschrijving direct onder de afbeelding komt (moet geval per geval bekeken worden, dunkt me. Groet, Annabel_(overleg) 1 dec 2008 22:00 (CET)

@Annabel: "Headline should end with "="" gaat over niet goed afgesloten kopjes, zoals == Geschiedenis = of == Toekomst. Jelte 1 dec 2008 22:18 (CET)

Zoiets zou gefixt moeten worden, maar kan ook weer een vals positieve zijn (als er een sjabloon of ref-tag op de lijn voorkomt. "Headlines start with one "="" betreft artikels in de vorm = Toekomst =. Deze vallen mijns inziens onder dezelfde vlag als fout 007 ("Headlines start with three "="")Annabel_(overleg) 1 dec 2008 22:22 (CET)

Het voorstel is doorgevoerd met deze wijziging op de translatie pagina: [3]. De tabel hierboven is bijgewerkt met het eindresultaat. Dat wil zeggen elke fout staat onder het kopje waaronder het nu geconfigureerd is. Rudolphous 6 dec 2008 14:18 (CET)

Geactualiseerd met nieuwe categorieën die default op low geconfigureerd staan. Rudolphous 6 dec 2008 21:29 (CET)

Die HTML tags worden helaas nog altijd getoond. Als deze moeten worden verbeterd als het artikel wordt verbeterd, dan wordt dit hier beter niet getoond. Geen kat die op basis van deze lijst gaat werken en wanneer de check wikipedia pagina bewerkt of geladen moet worden, duurt het alleen veel langer. Als er al iets gedaan moet worden, dan is het dat bots dit bij veel nuttigere bewerkingen tesamen afhandelen (maar dus dit enkel als tweede bewerking). Annabel_(overleg) 6 dec 2008 21:35 (CET)

Annabel, als ik het goed begrijp pleit jij voor het niet tonen (en dus prio 0 maken) van 026, 038, 039, 040, 041, 042? Rudolphous 6 dec 2008 21:45 (CET)

Zeer zeker. Annabel_(overleg) 6 dec 2008 21:57 (CET)

Oke, staan nu uit. Ook het overzicht hierboven bijgewerkt en de data op de projectpagina ververst. Rudolphous 6 dec 2008 23:02 (CET)

Ndash en Mdash

CheckWikipedia is door Stefan uitgebreid met een aantal nieuwe fouten, waaronder: de ndash en mdash.

De omschrijving luidt:

• The article had a dash. Write for –; better "–" or —; better "—".
• This error was found 4382 times. - This output was limited to 200 article.

Ik ben erg benieuwd naar jullie mening over deze bevinding. M. vr. gr, Rudolphous 15 mrt 2009 19:02 (CET)

Write for –; better "–" or —; better "—".

(Zien er zo hetzelfde uit bij mij.)

Op Sjabloon:Leestekens staan: weglatingsstreepje, koppelteken, gedachtestreepjes.

Vragen:

Waarom zijn die tussen "–" en "—" (dus tussen de dubbele ' ) beter?

Kijk eens naar de artikelen Liggend streepje in de Nederlandse spelling en Kastlijntje. En ook en:Dash: er zijn nog veel meer varianten dan n- en m-dash.

Wat zijn de "betekenissen" van de streepjes, dashes, oftewel, wanneer gebruik je welk streepje of dash? Ik kan dat wel nazoeken, maar gaat een willekeurige medewerker dat doen. Ik denk het niet. Dus het onderhoud blijft oneindig voortduren. En ook de ruzies erover. Hoe dit op te lossen?

--VanBuren 15 mrt 2009 20:36 (CET)

Hallo VanBuren, het gaat niet zozeer of een "-", "–" of "—" gebruikt wordt, maar hoe deze wordt opgeschreven in de brontekst. Sommige mensen gebruiken "&ndash;" of "&mdash;" in de wikitekst en andere gebruiken het letterlijke teken. Hebben we op de Nederlandse wiki een voorkeur? Zo ja, waarom? Of maakt het ons niet uit? Rudolphous 15 mrt 2009 20:43 (CET)

(na bwc)Waar het volgens mij om gaat, is dat Stefan vindt dat we in plaats van &ndash; en &mdash; eigenlijk resp. – en — moeten gebruiken; zie Wikipedia:Wikiproject/Check Wikipedia/Vertaling, alwaar we vinden:

The article had a dash. Write for  – better "–" or — better "—".

Maar zoals uit de copy-paste van Rudolphous al blijkt, maakt dat voor de Wikimedia-software geen bal uit. Paul B 15 mrt 2009 20:46 (CET)

Ik vind dat dit hele project een beetje draait om hoe de bewerkingspagina eruitziet. Oke, de hoge prioriteit-dingen zijn echte fouten die ook te zien zijn in het lees-gedeelte, maar bijna alle andere 'fouten' zijn wel fouten, maar alleen te zien op de bewerkingspagina, voor het lees-gedeelte maakt het vaak niets uit. Sommigen die tegen dit project ageren, vinden dat die fouten op de bewerkingspagina geen fouten zijn. Ik ben van mening dat dat wél fouten zijn, omdat het het bewerken moeilijker maakt. Waarom &ndash; schrijven terwijl je – kunt schrijven, en waarom category i.p.v. categorie, waarom {{PAGENAME}} i.p.v. gewoon de titel voluit te schrijven? etc.etc.etc. Indien die kleine 'foutjes' niet meer aanwezig zijn, is de bewerkingspagina veel gemakkelijker te lezen/gebruiken, en daardoor zal het de incidentele bezoeker meer aanzetten tot het verbeteren van die pagina, dan dat hij vreemde talen/codes tegenkomt waar hij niks van begrijpt en die verbetering maar achterwege laat. Maar goed, dit is mijn bescheiden mening.
Vriendelijke groet, Goudsbloem 15 mrt 2009 22:47 (CET)

@Paul, als het geen bal uitmaakt waarom wordt het dan wel gedaan. Ik zie allemaal zinloze bewerkingen op mijn volgpagina langskomen en dacht al, er is zeker weer een nieuw onderwerp aan deze lijst toegevoegd. Wanneer houdt dit een keer op? Peter b 17 mrt 2009 07:38 (CET)

@Peter b: dat moet je niet aan mij vragen. Ik vraag mij al tijden af wat precies de zin is van bepaalde onderdelen van dit project, en wanneer dit project (dat per definitie een tijdelijk karakter moet hebben) is afgelopen. Paul B 17 mrt 2009 11:32 (CET)

Ik heb besloten om de wijziging toch door te voeren om de bewerkbaarheid van de artikelen te vergroten. Een teken in de tekst is makkelijker te begrijpen dan een ndash / mdash. Rudolphous 17 mrt 2009 18:50 (CET)

"Ik heb besloten"??? ik dacht dat het hier een gemeenschapsprojekt betrof, onzinnige acties kun je ook ergens anders doen. Peter b 17 mrt 2009 18:55 (CET)

@Peter, vraag jij voor elke edit toestemming? Als je denkt dat je iets kan verbeteren en je laat het niet bij die gedachte dan 'besluit' je dus om dat te verbeteren. Maar nu terug naar de kern. De ene of andere variant, dat maakt inderdaad "voor de Wikimedia-software geen bal uit." Dergelijke HTML-codes betreffen geen wiki-syntax en worden dus door de Wikimedia-software genegeerd en als je de Wikipedia-pagina met je browser (zoals Internet Explorer, Firefox, enzovoorts) bekijkt dan zet die dat wel om want die is er voor gemaakt om HTML-codes goed te verwerken. Maar maken we Wikipedia om alleen via internet te bekijken? Voor velen zal dat wel het geval zijn, maar dat was niet de basisgedachte van Wikipedia. Hoewel in 2003 [4] al was aangekondigd dat de Nederlandse Wikipedia zou overstappen op UTF-8 zou het nog tot de zomer van 2005 duren voor we op de Nederlandstalige Wikipedia ook echt zouden overstappen. In de bron van het artikel over de Poolse vakbond Solidarność kwamen toen zinnen voor als

"[[Lech Walesa|Lech Wa&#322;&#281;sa]] was de aanvoerder van de partij .."

en

"In mei [[1981]] werd Solidarno&#347;&#263; gelegaliseerd en ontstond er een plattelandsafdeling van Solidarno&#347;&#263; waarin boeren zich organiseerden." [5]

Gelukkig hoeft dat nu niet meer zo omslachtig omdat we 'Solidarność' momenteel gewoon als 'Solidarność' kunnen schrijven en we kunnen nu ook meteen linken naar Lech Wałęsa. Die HTML-trucjes zoals &ndash; zijn sinds we UTF-8 kunnen gebruiken niet meer nodig; sterker nog, het vermijden van die HTML-codes komt de leesbaarheid van de bron van het artikel ten goede en als de tekst nog eens wilt gebruiken in een situatie waarbij je geen browser gebruikt om het artikel te lezen, dan gaat het automatisch goed want er staat geen HTML meer in de bron van het artikel. Kortom, het omzetten heeft wel degelijk voordelen. - Robotje 17 mrt 2009 19:11 (CET)

Kortom, de pagina's zijn nu makkelijker te bewerken zonder HTML kennis. Met een woord als onzin ben ik het dan ook niet eens. Rudolphous 17 mrt 2009 19:22 (CET)

Ik heb elders al eens proberen uit te leggen dat ik het zelf erg vervelend vind om uit het lijstje met Speciale tekens onder het bewerkingsscherm karaktertjes te moeten zoeken en aanklikken, terwijl ik die codes gewoon uit mijn hoofd weet en ze zo in kan typen (de ergste is wel & middot; - daar heb je echt een leesbril bij nodig). Ik begrijp werkelijk niet waarom deze voorkeur als "fout" zou moeten worden gekwalificeerd. Wat betreft het einde van dit project: daar wil ik ook wel eens meer over horen, want van meet af aan was het tijdelijk bedoeld, zie hier. Wutsje 17 mrt 2009 19:22 (CET)

Over het tijdelijke aard. Gezien het aantal wikipedianen die aan dit project bijdragen, zou het goed zijn om hier een definitief project van te maken. Geen idee wat de procedure hiertoe is. Iemand een idee? Rudolphous 17 mrt 2009 19:36 (CET)

Je kunt net zo goed stellen: gezien het aantal wikipedianen dat er bezwaar tegen heeft, zou het goed zijn om er geen definitief project van te maken. Overigens zou ik een reactie op mijn andere opmerking wel op prijs stellen. Wutsje 17 mrt 2009 19:39 (CET)

Ik geef toe dat het inbrengen van deze tekens wat minder makkelijk is. Maar dat geldt toch ook voor ö, α, ß, â, etc? ALT+0150 of ALT+0151 werkt echter wel, of een copy paste vanaf een ander document. Rudolphous 17 mrt 2009 19:56 (CET)

@Robotje, voor inhoudelijke toevoegingen zal ik geen toestemming vragen, voor botachtige wijzigingen met op het oog geen nut die voorzienbaar tot irritatie leiden wel. Ik heb de laatste dagen tig lemma's op mijn volglijst voorbij zien komen, ik pleeg dan ook steeds de wijzigingen na te lopen, daar is die volgpagina voor, als ik da op dit soort verbeteringen stuit dan zou ik zeggen, ja, het is aan te bevelen dit pas te doen nadat er instemming voor is gebleken. Peter b 17 mrt 2009 19:59 (CET)

@Wutsje en alle andere tegenstanders van dit project: Een van de redenen dat er laatst geld is opgehaald, is om een wysiwyg-bewerkingswijze dichterbij te krijgen op wikipedia, en naar mijn mening is de overgrote meerderheid van de wikipedianen het daarmee eens. Wat wij (diegenen die via dit project bewerkingen maken) doen, is volgens mij niets minder dan dichter naar dat doel te werken: gewoon neerzetten wat er staat, dus niet ndash of mdash of nbsp of category en ga zo maar door, gewoon dat wat er hoort te staan, dat er ook neerzetten. De meerderheid van de bewerkingen die via dit project gedaan worden vind ik zinvolle bewerkingen, net zo belangrijk als bijvoorbeeld taalfouten corrigeren. Echte fouten zijn het natuurlijk niet, dat weet ik ook wel, maar ik vind het heel belangrijk dat als je op 'bewerken' drukt, dat elke pagina hetzelfde is als opbouw, en dat is ook wat er bereikt wordt met die kleine verbeteringen. Het maakt alles een stuk makkelijker te bewerken, want ik zeg je dat de zeer ruime meerderheid van de mensen die achter de computer zitten, NIET de codes weten voor ndash etc.etc.etc. En natuurlijk probeer ik altijd dingen te combineren, kijk ik even over de gehele pagina of er niet nog wat anders aan ontbreekt/fout is, en dat pik ik natuurlijk mee dan. Voordeel van dit project is zodoende ook dat je op veel pagina's komt waar langere tijd niemand is geweest, waardoor soms ook updates van lemma's ontstaan, die anders niet of veel later opgepikt zouden zijn. Wat mij betreft wordt dit een definitief project, al hoop ik natuurlijk dat niemand meer iets verkeerds neerzet, zodat dit project helemaal niet nodig zou zijn, maar dat is helaas een utopie.
Vriendelijke groet, Goudsbloem 17 mrt 2009 20:01 (CET)

Voor die mensen die "steeds lemma's voorbij zien komen", zoals Peterb: ik zie maar vier namen van geregistreerde gebruikers die met plezier dit "saaie" werk doen, en die herken je toch zo als betrouwbaar :). --VanBuren 17 mrt 2009 20:39 (CET)

Het centrale probleem met dit project is, dat het weliswaar onmiskenbaar nuttige aspecten heeft, maar dat enkele onderdelen ervan van meet af aan niet op brede instemming konden rekenen. Desondanks werden die gewoon doorgedrukt. Ook hier is dat weer het geval: ene Stephan Kühn besluit in z'n uppie dat wikiwijd alle n- en mdashes moeten verdwijnen, lokale volgelingen pikken dat op ("Ik heb besloten om (...)") - en de resultaten komen vervolgens op de volglijsten terecht. Dit alles gebeurt zonder enige vorm van overleg - laat staan consensus - en in weerwil van her en der geleverde kritiek. Vervolgens krijg je dan ook nog, betrouwbare gebruiker of niet, met gepruts als dit te maken. Tegen die achtergrond kan het toch niet verbazing wekken dat een en ander ergernis oproept. Wutsje 17 mrt 2009 21:01 (CET)

Artikelen met de letter A gingen verkeerd en moesten een aantal maal overnieuw. Excuses voor dit ongemak. Uiteindelijk heb ik alles correct kunnen doorvoeren en bij veel artikelen meerdere zaken in 1 keer kunnen aanpassen. Er moet me nog wel van het hart dat ik het jammer vind dat je dit hebt teruggedraaid zonder dit bij me te melden. Heb je een voorstel ten aanzien van de consensus? Rudolphous 17 mrt 2009 21:54 (CET)

De korte versie: project in fatsoenlijke peiling voorleggen aan gemeenschap; ieder onderdeel apart bespreken en prioriteren, tot daarover consensus is; daarna geen nieuwe "errors" bedenken en aanpakken zonder expliciete en voorafgaande instemming van de gemeenschap (dus ook: loskoppelen van Herr Kühn). Wutsje 19 mrt 2009 04:32 (CET)

Opmerkelijk dat na anderhalve week nog altijd niemand hierop heeft gereageerd. Wutsje 28 mrt 2009 13:40 (CET)

@VanBuren:ik weet niet waar jij je volglijst voor gebruikt, ik gebruik die om lemma's te volgen, daarbij kijk ik niet of de wijziging door een vertrouwde of een onbekende gebruiker is gedaan, ik kijk alleen naar de wijziging. En om eerlijk te zijn, ook gebruikers die ik al heel lang ken doen op de lemma's op mijn volglijst wel eens wijzigingen die ik aanpas. Peter b 17 mrt 2009 22:17 (CET)

Net als hierboven door anderen al gemeld heb ik ook op meerdere plaatsen meerdere verbeteringen heb kunnen doen in artikel. Een aantal malen kwam ik een categorie tegen bovenin een artikel, waarschijnlijk niet opgemerkt door iemand die er op een later tijdstip enkele onderaan heeft geplaatst. @Peterb, ik vind het altijd weer boeiend wanneer anderen mijn aanpassingen op hun manier verbeteren :). --VanBuren 17 mrt 2009 23:08 (CET)

br's

Doet het er nu echt toe of je <br>,of <br/>, of <br /> gebruikt? Hierboven staat er wel iets over maar in het kader van wikiopmaak, met een set instructies die een stuk eenvoudiger zijn dan HTML, zou dan het gebruik van alleen de simpelste versie, namelijk <br> niet de meest logische zijn? HTML lijkt dat goed te accepteren. --VanBuren 20 mrt 2009 13:50 (CET)

De <br> tag zonder sluit teken is geen valide XHTML. De andere twee voorbeelden zijn wel XHTML-compliant. De wikimedia software zorgt er voor als er in de brontekst een <br> wordt gebruikt, dit automatisch wordt omgezet naar een <br />. Rudolphousbot heeft een voorkeur voor <br />, maar zal dit alleen doorvoeren als er ook andere zaken in een artikel worden verbeterd. Rudolphous 20 mrt 2009 14:21 (CET)

Dit is overigens precies de wijziging die laatst de infobox op het artikel over de provincie Friesland heeft vernield. Ik geef toe dat het een wat rare constructie was daar, maar dat is dus wel het gevaar van botmatig "fixen" van dat soort dingen: even nakijken of er niets vreemds is gebeurd, kan er meestal niet meer vanaf, en dit was een prachtig voorbeeld van hoe twee "technocratische" constructies niet compatibel waren met elkaar. paul b 9 apr 2009 22:02 (CEST)

Hallo Paul, welke wijziging bedoel je precies? Rudolphous 9 apr 2009 22:27 (CEST)

Het ligt voor de hand dat dat deze is: [6]. Wat daar misgaat, is dat de <br> in de titel van het sjabloon wordt veranderd in een <br />. Dat werkt dan weer niet goed samen met het Sjabloon:Inwonertallen Nederlandse provincies, waar "Friesland <br>Provinsje Fryslân" stond. Datzelfde gold ook voor alle andere statistieklijsten waar de provincie in voorkwam, en leidde tot de bekende foutmeldingen van het genre . paul b 9 apr 2009 22:44 (CEST)

Code 061: Reference with punctuation

Wat vinden jullie van deze error/aanbeveling ? Ik vraag me af of dit fout is. Het lijkt me als de ref voor de punt staat, dat deze terugslaat op de huidige zin. Rudolphous 2 apr 2009 22:38 (CEST)

Ik vind het zeer zeker netter staan om de punt voor de ref te plaatsen, kijk maar naar de 50 'fouten' die er staan, dan denk ik dat je het wel met me eens bent (het kan bijvoorbeeld gebeuren dat er 2 of meerdere refs geplaatst worden aan het einde van een zin, en dan staat die punt wel erg ver weg...). Het enige wat wel moet gebeuren dan, is dat je de punt plaatst, en zonder spatie de ref er direct achterplaatst. Wat ik wel wil opmerken, is dat ik vind dat dit niet de enige verbetering aan een lemma moet zijn, maar dat het meegepikt kan worden, indien er ook iets anders aan dat lemma wordt verbeterd.
Goudsbloem 3 apr 2009 00:39 (CEST)

Eens met Goudsbloem. Voor een komma is het een ander verhaal, maar als een noot op de hele tekstregel slaat is het volgens mij achter de punt (ook volgens dit boek over rapporteren). Echter hier wordt dit weer betwist. en:Wikipedia:Footnotes#Ref_tags_and_punctuation geeft een aantal bronnen voor achter de punt, waarop deze code 061 waarschijnlijk is gebaseerd. Maar ook daar staat dat er uitzonderingen zijn en dat er geen bepaalde schrijfwijze moet worden opgedrongen (drie shortcuts verwijzen hierheen - het lijkt dus een veelbesproken element). Misschien beter om dit eerst eens in het taalcafé aan de orde te stellen en er een brede discussie over te voeren, want toepassing hiervan gaat anders gegarandeerd gezeur opleveren en als blijkt dat beide mogelijk zijn (wat ik vermoed), kan deze foutcode zelfs doorgestreept. --hardscarf 3 apr 2009 13:26 (CEST)

Ik heb de discussie hierover gestart in het taalcafé, zie hier. Goudsbloem 3 apr 2009 14:42 (CEST)

Commentaar van mij aldaar. Bessel Dekker 3 apr 2009 23:07 (CEST)

Als ik het goed begrijp kan het beide goed zijn. Deze fout dan maar verwijderen van de lijts? Rudolphous 8 apr 2009 20:11 (CEST)

Wat mij betreft kan die gedeactiveerd worden, ik ben ook voor het deactiveren van fout 62, 63 en 66, het zijn te vergezochte fouten. Ik hoor het wel wat jullie menig is over die laatste 3. Goudsbloem 8 apr 2009 20:19 (CEST)

62 vind ik inderdaad ook overbodig. 63 en 66 vind ik nog wel nuttig een imagetekst is al small en als er dan nog eens toevoeging small bij komt te staan is dit overbodig of de lettertjes gaan te klein worden. Rudolphous 8 apr 2009 21:56 (CEST)

Code 61 (Referentie met punt) en 62 (Alleenstaande kop) heb ik alvast gedeactiveerd. Rudolphous 10 apr 2009 13:20 (CEST)

New errors

Hello, in nlwiki the error 11, 16, 27 is deactivated. I have change the script for this errors and search there for new errors. Please activate this three errors, translate the new description and test it. -- sk 16 apr 2009 10:10 (CEST)

Consensus

Nog altijd is geen enkele poging ondernomen om de Nederlandstalige wikigemeenschap te vragen wat ze eigenlijk van dit project vindt. Zoals bekend was er vanaf het begin tamelijk veel kritiek op. De vraag hoe over dit project tot consensus te komen, zowel wat betreft de uitgangspunten als met betrekking tot de verschillende onderdelen, kwam hierboven al eens aan de orde, maar de discussie bloedde al heel snel dood, want geen van de participanten in dit project nam de moeite er serieus op in te gaan. Ondertussen blijft één persoon (!) steeds weer nieuwe "errors" toevoegen en lijkt het erop dat dit acht maanden geleden als "tijdelijk" gepresenteerde project stiekempjes door een handjevol mensen langs een achterdeurtje geïnstitutionaliseerd wordt ("57339 'problemen' erbij, daar zijn we nog wel even zoet mee"). Het spijt me dat ik het zeggen moet en ik bedoel het zeker niet persoonlijk, maar de manier waarop een en ander in zijn werk gaat vind ik eigenlijk gewoon schijnheilig. Wutsje 7 mei 2009 10:29 (CEST)

Ik ben het slechts ten dele met je conclusies eens. Ten eerste is het als tijdelijk presenteren meer een gevolg van het feit dat niet voorzien is in permanente projecten op deze Wiki. Kwaliteitsgerelateerde projecten zijn eigenlijk per definitie permanent, en zijn eigenlijk broodnodig voor een encyclopedie van deze omvang. Ten tweede is het niet slechts één persoon die nieuwe errors toevoegt, maar worden door andere taalgebieden blijkbaar ook verzoeken gedaan voor het introduceren van nieuwe controles. Wel vind ik het jammer dat de discussie hierboven verzandt in de loopgraven, en zou ik iedereen aanmoedigen om die discussie voort te zetten en wel tot een conclusie en procedure omtrent nieuwe fouten te komen. Om het huidige proces schijnheilig te noemen gaat me weer te ver.

Persoonlijk vind ik de lijst bijzonder handig om te controleren waar storende fouten (bv foute blokhaken) in de artikelen zitten. Andere "fouten" vind ik minder belangrijk en zal ik niet bijwerken (ik doe toch al niet zoveel). En als er mensen zijn die plezier hebben in het corrigeren van deze dingen, zonder dat de inhoud van de artikelen daarmee schade oploopt (!!!!), zie ik het kwaad er niet van in. Ik heb geen problemen met mijn volglijst, die wordt toch al volgepropt met allerlei andere botmatige verwerkingen als interwiki's, verwijderde of juist gesplitste categorieen e.d. Mijns inziens is het nut van dit project vele malen groter dan de hinder die sommige gebruikers ervan ondervinden. Errabee 7 mei 2009 17:33 (CEST)

Kleine aanvulling: Ik kom bijvoorbeeld ook met regelmaat dit soort wijzigingen tegen (en ik heb hier met opzet een wijziging gekozen van een door mij gerespecteerde medewerker, dus aub niet persoonlijk opvatten). Op zich is het niet schadelijk, maar met evenveel moeite had gewoon een goede categorie toegevoegd kunnen worden; dat was niet moeilijk te vinden. Moeten we deze medewerkers dan ook een tik op de vingers geven, want het is een wijziging van exact dezelfde soort? En het gaat nog verder, omdat dit artikel dus twee keer gewijzigd moet worden. Errabee 7 mei 2009 18:54 (CEST)

Begrijp me goed: ik zie het nut van een groot aantal aspecten van dit project wel degelijk - daar heb ik eerder bij verschillende gelegenheden al op gewezen - en mensen tikken op de vingers geven is ook niet mijn bedoeling. Mijn punt is: dit is allemaal begonnnen met één persoon, die deze wens had: "I want use the data from the wikipedia for other project without the mediawiki" ([7]). Vervolgens is een aantal mensen aan de slag gegaan - maar concrete inhoudelijke afspraken over de gang van zaken binnen dit project zijn ondanks herhaaldelijk aandringen van meerdere zijden nooit gemaakt. Ik vind dat zulks wel zou moeten gebeuren. Als een van de deelnemers vraagt hoe die consensus zou moeten worden bereikt en er wordt gezwegen wanneer daarop een antwoord komt, maar vervolgens wordt wél rustig verder gegaan met "fouten" verbeteren ("ik heb besloten" (!) - zo gaan we op Wikipedia toch niet met elkaar om?), dan wekt dat op mij de indruk dat het kennelijk helemaal niet de bedoeling is dat over die consensus wordt gediscussieerd. Bij controversiële onderwerpen vind ik dat in een samenwerkingsproject ongewenst. Ik heb er geen bezwaar tegen als dit project een permanente status krijgt - maar dan niet stilletjes via de achterdeur. Wutsje 7 mei 2009 21:16 (CEST)

Goed dat je de discussie over consensus nog een keer start. Ik vraag me nog steeds af welke vervolgstap wenselijk is. Vorige keer schreef je: "De korte versie: project in fatsoenlijke peiling voorleggen aan gemeenschap; ieder onderdeel apart bespreken en prioriteren, tot daarover consensus is; daarna geen nieuwe "errors" bedenken en aanpakken zonder expliciete en voorafgaande instemming van de gemeenschap (dus ook: loskoppelen van Herr Kühn).".

Op de pagina om een stemming te organiseren staat echter: "Wikipedia is een gemeenschapsproject en kent een democratische traditie waarin in principe niemand de baas is en er zoveel mogelijk gezocht wordt naar consensus. Alleen in gevallen waarin geen consensus lijkt te ontstaan kan het zinnig zijn om daarover een stemming te houden. Het zoeken naar consensus verdient steeds de grote voorkeur!" Zelf schrijf je "Begrijp me goed: ik zie het nut van een groot aantal aspecten van dit project wel degelijk". Is er volgens jou consensus over het bestaansrecht van dit project an sich of moeten we dit nog via een peiling aan de gemeenschap vragen?" Als het project doorgaat ben ik met je eens dat het niet via een tijdelijke pagina moet (wat het kennelijk nu [het geval is]). Wat er voor nodig is om er een permanente pagina van te maken is met niet helder. Met vriendelijke groeten, Rudolphous 7 mei 2009 22:15 (CEST)

Over het feit dat duidelijke en échte fouten verbetering behoeven bestaat ongetwijfeld brede consensus, tenminste: dat mag ik hopen. Het woord "stemming" heb ik overigens niet gebruikt en van mij hoeft het ook niet zo ver te komen, er wordt hier al genoeg gepeild en gestemd. Een fatsoenlijke discussie over dit project zou echter wel mooi zijn. Het zou in mijn ogen aanbeveling verdienen om die hele lijst met "fouten" langs te lopen en vast te stellen welke daarvan nou werkelijk belangrijk zijn en welke niet - en de dingen die dat niet of onvoldoende blijken te zijn dan ook daadwerkelijk af te voeren en er niet verder over te harrewarren, zoals nu regelmatig gebeurt. Verder zou een toestand moeten intreden waarin iedereen (dus ook Herr Kühn) hooguit voorstellen tot "verbeteringen" kan doen (zeker indien het grootschalige onderdelen betreft), die dan netjes worden aangekondigd op een daarvoor bestemde pagina en waarover door de nl:wiki-gemeenschap vervolgens wordt gesproken en besloten, in plaats van die eerst op eigen gezag te implementeren en dan de eventuele reacties maar af te wachten. Wutsje 7 mei 2009 22:43 (CEST)

Wutsje, een tijdje geleden was er al sprake van dat aantallen nieuwe artikelen een steeds minder stijgende lijn laten zien. Er is ook al lange tijd sprake van opmerkingen over de "kwaliteit" van artikelen, inhoudelijke kwaliteit of hoeveelheid informatie (begjes). Het lijkt erop dat het tweede feit (kwaliteit) in elk geval meer aandacht krijgt. Terecht toch? Ik begrijp je bezwaar niet tegen deze "check wikipedia" activiteiten. Er zijn m.i. veel onzinniger wijzigingen in artikelen (bv. [8]), of de ellenlange discussies op overlegpagina's. Maar blijkbaar zijn er mensen die dat belangrijk vinden. Ik begrijp niet waarom je deze "methode" van het verbeteren van artikelen zo formeel wilt benaderen. Of zie je het als verslechtering en wil je dat een halt toeroepen? Wat voordien een heel erg willekeurig proces was, hier een komma erbij, daar een hoofdletter minder, etc. is nu een systematische werkwijze die m.i. overzichtelijker en doelgerichter is. Zo'n werkwijze bevalt misschien niet iedereen maar we komen wel verder, en sommige mensen vinden het prettig om zo te werken. --VanBuren 8 mei 2009 09:29 (CEST)

Er is uiteraard een verschil tussen kwaliteitsbewaking en overduidelijke muggenzifterij. De lezer van Wikipedia merkt van de meeste in het kader van dit project aangebrachte wijzigingen helemaal niets. Om dan over "kwaliteit" te beginnen, komt op mij wat vreemd over. Dat er veel onzinniger wijzigingen zijn, zal ik niet ontkennen, maar ook dat is een drogreden: het zegt uiteindelijk niets over hoe zinnig de wijzigingen in het kader van dit project zijn. Met dit project worden alleen op mechanische wijze vast te stellen afwijkingen van de "norm" gevonden, die dan op quasi-mechanische wijze worden aangepast. Ik geloof niet dat ik in het kader van dit project ooit een hoofdletter verwijderd heb zien worden of een komma toegevoegd heb zien worden (nu ja, samen met een "DEFAULTSORT" i.v.m. diakritische tekens, dat dan weer wel). Het is nu nl. in een stadium beland dat een groot deel van de opgespoorde "fouten" helemaal niet zichtbaar is voor de lezer!

Dat gezegd hebbende: het is een perfect verdedigbaar standpunt dat het een goed idee zou zijn als de broncode van de artikelen zoveel mogelijk uniform wordt. Maar laten we de juiste woorden gebruiken om de discussie daarover te voeren; het is in dat geval de "broncode" die wordt verbeterd, niet de artikelen. Er zijn in dit project wel degelijk enkele onderdelen die wel door de lezer op te merken zijn of die de code duidelijk beter onderhoudbaar maken, en daartegen heb ik meestal ook geen enkel bezwaar. paul b 8 mei 2009 10:12 (CEST)

@VanBuren: De "systematische werkwijze" behelst nu dat één persoon met programmeursogen ("You can trust my there are so many problems inside the wikipedia articles, that every programmer get a crisis.") bepaalt wat "fout" is en vervolgens zijn mening daaromtrent eenvoudigweg op andere wiki's dumpt. Ik vind dat nl:wiki zélf moet bepalen welke onderdelen van de broncodes worden aangepakt en welke niet. Dat lijkt me gewoon een kwestie van autonomie en wat daar formeel aan is zie ik niet. (En inderdaad, het gaat hier niet om verbetering van de kwaliteit van de inhoud van de encyclopedie. Geen wonder: Kühn spreekt geen Nederlands.) Wutsje 8 mei 2009 12:57 (CEST)

Je bent wel erg, excuseer de opmerking, gefixeerd op deze persoon:Kühn, en wat jij blijkbaar ervaart als een aanval op jouw idee van autonomie. Jouw goed recht. Aan jouw gevoelens torn ik niet. Maar wanneer je die fixatie terzijde zet kun je dan de merites van dit project wel herkennen? En misschien zijn er gradaties in hoe "erg" sommige wikikwalen zijn, zijn ze als geheel genomen, gemiddeld, misschien toch wel de moeite waard om op te ruimen? Sommige wel, sommige minder, maar het is toch wel een goed idee om mensen, die het wel leuk vinden (of misschien: niet erg vinden) die taak uit te voeren, hun gang te laten gaan, zonder allerlei stem- of peilacties? Jij vindt dat nl:wiki zelf moet bepalen wat aangepakt moet worden. Ok, maar waarom zou dat een collectieve beslissing moeten zijn terwijl het hele bijdragen aan wikipedia gebaseerd is op individuele participatie. De mensen die het "werk" uitvoeren kunnen w.m.b. zelf prima beslissen aan welke "verbeteringen" ze willen werken. Als je daar allerlei regeltjes aan verbindt zadel je ook anderen weer op om dan als politie/controleur op te treden. Je weet wat er dan gebeurt: weer ellenlange discussies op overlegpagina's, enz.. --VanBuren 8 mei 2009 13:35 (CEST)

Ook mij bevalt de motivatie van de heer Kühn niet, maar het is uiteindelijk niet de heer Kühn die hier beslist wat er verder met zijn data gebeurt, dat zijn de gebruikers die delen van dit "project" uitvoeren, en die kunnen dat uiteraard best zelf beslissen (al heb ik de indruk dat ze zich nogal onkritisch opstellen naar de input van de heer Kühn toe, maar dat is een inhoudelijk verschil van mening). Niettemin: ook de mensen die het inhoudelijke "werk" aan de artikelen hebben verricht, kunnen doorgaans prima zelf beslissen welke ingrepen daarin noodzakelijk of gewenst zijn. Het is prima (en een van de pijlers van Wikipedia) om mensen hun gang te laten gaan, maar als de vrijheid van bewerken die de uitvoerders van dit project hebben, botst met de vrijheid van bewerken die anderen hebben, dan is er reden voor overleg. Gezien de frequentie waarmee die botsingen plaats vinden, lijkt het mij toch noodzakelijk om dat enigszins te formaliseren. paul b 9 mei 2009 14:38 (CEST)

Mijn ervaring is dat een aantal zaken die als fout wordt aangemerkt op de lijst nogal subjectief is. Zodra de flavour of the month verandert, heeft een andere syntaxis de voorkeur. En vervolgens zie ik die bot weer voorbijkomen waar ik mij aan kan ergeren, al zou ik dat niet moeten doen uiteraard. Maar bij dit soort edits vraag ik mij echt af of men wel begrepen heeft hoe de prioriteiten liggen. BoH 18 mei 2009 00:03 (CEST)

Ik sluit me volkomen aan bij BoH en Wutsje. Ergeren is vaak inderdaad niet nodig, hoewel er soms juist tenenkrommende fouten geïntroduceerd worden. Maar er lijkt weinig tegen te doen. Jacob _overleg 28 mei 2009 07:48 (CEST)

Technisch gesproken is er heel eenvoudig wat aan te doen, maar de wil ontbreekt. Dit project wordt ons door een enkeling opgedrongen en er is nauwelijks overleg over de zaken die als fout worden aangemerkt: de opzetter vindt dat iets fout is en het moet meteen maar op alle wiki's waar dit project wordt getolereerd, worden uitgevoerd. Dat heeft mij sinds de eerste dag al dwarsgezeten. Sommige dingen, zoals fouten in de wiki-syntax waardoor pagina's niet goed worden weergegeven, moeten verbeterd en daarvoor is een project als dit prima. Andere dingen zijn een kwestie van smaak en moeten niet worden opgedrongen - Quistnix 28 mei 2009 08:24 (CEST)

Is het misschien een idee om alle nieuwe soorten fouten hier eerst ter goedkeuring als 'fout' voor te leggen en even een berichtje te plaatsen op WP:OG? Dan kunnen geïnteresseerden zich erover uitspreken of het 1) een te corrigeren fout is, 2) een niet schadelijke kwestie van 'smaak' is die meegenomen mag worden als ook andere dingen aan een artikel worden veranderd (aanvullingen, spellingsfouten etc.) of 3) een niet gewenste wijziging is die dient te worden uitgeschakeld. Van de bestaande 67 ingeschakelde foutmeldingen (van de 83) kan dit uiteraard dan ook worden aangekaart (en van de 16 uitgeschakelde of ze misschien juist wel ingesteld zouden moeten worden - maar waarschijnlijk zijn ze niet voor niets uitgeschakeld). Op deze wijze wordt elke nieuwe stap in het proces gecontroleerd voor toepassing. --hardscarf 28 mei 2009 10:06 (CEST)

Ik vind het een goed idee. Rudolphous 7 jun 2009 16:59 (CEST)

Fouten langs volglijst/categorieboom leggen

Zou er misschien een optie zijn om de lijsten met artikelen met fouten (semi-)automatisch langs je volglijst of langs een categorieboom te leggen? Dan kan je opsporen welke artikelen die jij interessant vindt nog fouten bevatten. Nu is het zo dat veel van de kleine fouten honderden of duizenden keren voorkomen en daar is geen beginnen aan. Daarentegen zullen mensen wel gemotiveerd zijn om hun favoriete artikelen te perfectioneren. --Kafir 19 mei 2009 15:44 (CEST)

ISBN-fout in Huismerk (heraldiek) gecorrigeerd

Bij het kopje Code 072: ISBN checksum fout bij ISBN-10 heb ik de fout in Huismerk (heraldiek) gecorrigeerd. Zolang ik geen betere manier weet om dit te melden, meld ik dergelijke activiteiten op deze OP. Met vriendelijke groet, ^{b222  ?!}bertux 21 mei 2009 12:29 (CEST)

Bedankt voor je verbetering. Er zijn meerdere manieren om aan een kloppende ISBN te komen:

1. Kijken op website van de Koninklijke Bibliotheek: www.kb.nl
2. Wereldwijd zoeken naar boeken: www.worldcat.org
3. Kijken op anderstalige wikipedia (bijvoorbeeld Duitse / Engelse)
4. Gebruik maken van google. Zoeken op titel + jaartal. Zoeken op alleen het isbn nummer, etc.
5. Toevoegen van 978 of juist verwijderen 978 bij respectievelijk een foutief ISBN-10 of ISBN-13 getal.
6. Afleiden uit andere boeken van dezelfde schrijver. Sommige schrijvers vragen een serie van ISBN nummers aan a.d.h.v. andere boeken kan dan toch een kloppend nummer worden gemaakt.

Via optie 1 vond ik gelijk een kloppende ISBN-nummer, namelijk:

• http://sru.kb.nl/sru/stylesheets/kbhome/?query=Noord-Nederlandse%20heraldiek%2C

Rudolphous 23 mei 2009 20:43 (CEST)

Ja, ja, maar dat was de vraag niet. De vraag was: waar en hoe kan ik afvinken dat ik de zaak gecorrigeerd heb? Natuurlijk kan dat via deze overlegpagina, maar dat is vreselijk omslachtig. Had ik ook gewoon op Wikipedia:Wikiproject/Check Wikipedia een vinkje achter huismerk kunnen zetten? Zo'n pagina moet toch een terugmeldmogelijkheid hebben die ook voor toevallige passanten (zoals ik) duidelijk is?

Om toch even op je antwoord in te gaan: je mogelijkheid nr. 1 heb ik gebruikt, maar deze is niet onfeilbaar. De KB geeft zelf aan dat ze eerder een foutief nummer gepubliceerd hadden; de aanmaker van huismerk had het foutieve nr. vermoedelijk correct overgenomen. Overigens blijkt bij foute nrs. van de KB de bron van de fout meestal bij de uitgever te liggen, die het boek heeft uitgegeven met ongeldig ISBN.

In je antwoord mis ik een zevende optie: via de eenvoudige systematiek van het ISBN zelf berekenen wat het juiste nummer kan zijn; weliswaar weet je dan niet of het nr. zelf of het controlegetal fout is, maar dat kun je googlen. Voor meelezers: je mogelijkheid 5 houdt in dat bij tien cijfers die 978 er vóór gezet moet worden. Om iets te hebben aan die alternatieve zoekopdracht moet je de dertien cijfers aan elkaar schrijven, zonder scheidingstekens zoals spaties of streepjes. Google behandelt scheidingstekens (bijvoorbeeld het streepje) precies zoals spaties. Mét streepje wordt 978 gewoon als een extra 'woord' in je zoekopdracht beschouwd, een extra woord dat niets toevoegt. Zie overigens het artikel ISBN en merk op dat binnenkort ook de prefix 979 gebruikt gaat worden. En oude ISBN's hebben een geheel andere systematiek.

Met vriendelijke groet, ^{b222  ?!}bertux 24 mei 2009 00:01 (CEST)

Het beste kan je het werk wat gedaan is verwijderen van de pagina. Als een hele groep gedaan is (alles onder 1 kopje), dan mag het hele kopje verwijderd worden. Op deze manier wordt de pagina langzaam kleiner en wordt snel duidelijk wat er nog gedaan kan worden. Een kloppend ISBN nummer uitrekenen behoort inderdaad ook tot mogelijkheden. Aangezien meestal niet duidelijk is welk getal precies fout, zijn er vaak meerdere kloppende ISBN-nummers van te maken met 1 getalswijziging. Als een ISBN nummer fout is uitgegeven kan je ook gebruik maken van het Sjabloon:ISBN-fout. Dit sjabloon wordt nu alleen bij [9] gebruikt. Bij het googlen moeten inderdaad de streepjes veelal verwijderd worden, of het ISBN nummers tussen dubbele quotes geplaatst worden. Rudolphous 24 mei 2009 01:22 (CEST)

Html-code "shy"

Ter info: ik heb zojuist het {{shy}} aangemaakt, in plaats van de "& shy;"-code (zonder spatie dan). Nu hoeft hij niet meer weggehaald te worden, maar kan hij vervangen worden, als iemand er eentje tegenkomt. Met vriendelijke groet, Davin 7 jun 2009 08:11 (CEST)

Volgens de XML dump van 31 mei 2009 bevatten de volgende artikelen een shy html-tag:

• 1 scanid=5511 Dalai lama
• 2 scanid=8655 Neologisme
• 3 scanid=13645 Loofwerk
• 4 scanid=25562 Gaziantep (stad)
• 5 scanid=27162 Silicaat
• 6 scanid=31452 Thomas Kuhn
• 7 scanid=44794 Vervangende infinitief
• 8 scanid=48212 Scooter (vervoermiddel)
• 9 scanid=64108 Parabel
• 10 scanid=70641 Spoortunnel Delft
• 11 scanid=78351 Blauwestad (project)
• 12 scanid=91955 Deontologie
• 13 scanid=126498 Lemele
• 14 scanid=142956 Fiscale zegel
• 15 scanid=178501 Lijst van aanslagen in Libanon
• 16 scanid=193458 Leermiddel
• 17 scanid=297908 Wet op het financieel toezicht
• 18 scanid=305856 Dissimilatie (taalkunde)
• 19 scanid=336268 Ontlening (taalkunde)
• 20 scanid=355559 Fulltime
• 21 scanid=369007 Tibet (gebied)
• 22 scanid=387644 Unicaat
• 23 scanid=436312 Mon (heraldiek)
• 24 scanid=520538 Ramon Magsaysay (president)
• 25 scanid=591250 Exantheem
• 26 scanid=620520 MediaWiki:Gadget-popups.js
• 27 scanid=703482 Aanval op konvooi Hadassah
• 28 scanid=703916 Walter Van Assche
• 29 scanid=714058 Hubert Minnebo
• 30 scanid=726121 Willy Bosschem
• 31 scanid=730972 Tibetaanse cultuur
• 32 scanid=749023 Commuun genus
• 33 scanid=750159 Roodborstzonnebaars
• 34 scanid=756632 Bataviaasch Nieuwsblad
• 35 scanid=758015 Sedenion
• 36 scanid=763575 Feline infectueuze peritonitis
• 37 scanid=764478 Waag (Schoonhoven)
• 38 scanid=765805 Reader-response theory
• 39 scanid=766389 Postmortale fotografie
• 40 scanid=767407 Iconiciteit
• 41 scanid=774163 Portaal:Onderwijs/Uitgelicht
• 42 scanid=774854 Portaal:Onderwijs/Wetgeving
• 43 scanid=777706 Catch-22 (roman)
• 44 scanid=778944 Autoklaas
• 45 scanid=780322 Onderwijsstructuur (Vlaanderen en Nederland)
• 46 scanid=791169 Tegengestelde (taalkunde)
• 47 scanid=796841 Vrijheid van onderwijs
• 48 scanid=807886 Wet van Muphry
• 49 scanid=810334 Metanalyse
• 50 scanid=826652 Portaal:Himalaya/Overig
• 51 scanid=830041 Molla Nasreddin (Azerbeidzjan)
• 52 scanid=833325 Hipgnosis
• 53 scanid=835039 Alan Dawa Dolma
• 54 scanid=835782 Jampa Tsering
• 55 scanid=845291 Lal Bahadur Shastri
• 56 scanid=847479 Panchen lama
• 57 scanid=850035 Tibetaans leger
• 58 scanid=851112 Joglo
• 59 scanid=855311 Khenchen Pälden Sherab
• 60 scanid=857994 Hunsur
• 61 scanid=858704 Camp Hale
• 62 scanid=859723 Naropa-universiteit
• 63 scanid=865210 Modal
• 64 scanid=866424 Lijst van Tibetaanse namen
• 65 scanid=866827 Dolma Kyab
• 66 scanid=868110 Tibet sinds 1950
• 67 scanid=869709 Halmeag
• 68 scanid=876271 Geschiedenis van Tibet (1912-1949)

Ik ben eigenlijk tegen het gebruik van de shy tag. De shy tag dient ervoor om aan te geven waar in een woord een afbreekstreepje zou mogen komen (als het bijvoorbeeld niet op het scherm of in een tabel past). Het feit dat wikimedia software een woord voor de helft kleurt als er een shytag in het midden staat is volgens mij een bug en mogelijk geen blijvend werkende constructie. Pagina's baseren op een bug lijkt me geen goed principe en bovendien zijn dit soort constructies moeilijk te begrijpen voor een gemiddelde wikipediaan. Rudolphous 7 jun 2009 09:29 (CEST)

Zo moeilijk lijkt me de shy-functie niet. Ik vind het juist een verbetering voor de lezer. Ik heb er ook eerst in de kroeg over gehad en daar kwam deze oplossing naar voren. Davin 7 jun 2009 10:42 (CEST)

Veelvoorkomende fouten sorteren op aantal?

Sommige fouten komen erg vaak voor. Veel van die fouten zijn ook niet makkelijk botmatig op te lossen. Denk hierbij bijvoorbeeld aan Code 030: Afbeelding zonder omschrijving die zo'n 50.000 keer voorkomt. Zou het niet een idee zijn om in plaats van 50 willekeurige artikelen als voorbeeld weer te geven, de 50 artikelen met de meeste plaatjes zonder omschrijving weer te geven. Op die manier kan je makkelijker met een bewerking meerdere fouten oplossen en worden de artikelen met waar de fout het vaakst voorkomt (meestal) als eerst opgelost. Uiteraard kan je dit doortrekken naar andere foutcodes met veelvoorkomende fouten. Is dit technisch mogelijk? --Kafir 7 jun 2009 16:16 (CEST)

Ik heb twee weken terug botmatig zo'n 4000 correcties doorgevoerd mbt 030: Afbeelding zonder omschrijving (waaronder vlaggen van Franse gemeenten), maar heb het idee dat het totaal aantal van meer dan 50.000 'fouten' niet is afgenomen, maar zelfs is gestegen! Dat lijkt niet te kloppen. Hoe is dit verklaarbaar? Michiel1972 7 jun 2009 16:20 (CEST)

Michiel, elke dag wordt een gedeelte gescanned (alleen de eerste 50 fouten van een bepaald type en ca 5000 artikelen totaal) en periodiek (als er een actuele dump is en genoeg rekentijd) worden alle artikelen gescanned (540.000). Ik denk dat jouw verbeteringen zichtbaar worden in de statistieken zodra de totale dump gescanned wordt. Rudolphous

@Kafir: Ik denk dat je deze vraag het beste aan Stefan zelf kan voorleggen. Rudolphous 7 jun 2009 16:58 (CEST)

Ik heb de vraag inderdaad aan Stefan zelf voorgelegd. Daarnaast, bedankt voor de informatie over hoe dit project werkt. Ook ik ga wel eens artikelen verbeteren die buiten de eerste vijftig vallen en het was mij ook opgevallen dat die niet elke keer bijgewerkt worden. --Kafir 7 jun 2009 18:01 (CEST)

Helaas is het sorteren op frequentie niet mogelijk. Wel is het mogelijk met uitgebreidere foutenpagina's een beter beeld te krijgen van waar de fout voorkomt en hoe vaak. Wat mij betreft zou vooral code 84 daarvan kunnen profiteren. Al die jaartallen (met lege kopjes voor geborenen en overledenen) hebben wat mij betreft minder prioriteit dan de meeste andere lege kopjes en echte opmaakfouten zoals bv. ==Groepsfase== gevolgd door ==Groep A== wat ik nog wel eens bij een artikel over een sporttoernooi ben tegengekomen. Als je een voorkeur hebt voor een errorpagina met uitgebreidere beschrijving is dit misschien het moment om dat te melden. :-) --Kafir 8 jun 2009 21:37 (CEST)

Op basis daarvan had ik al uitgevonden dat de afbeeldingbeschrijving vaak ontbreekt in infoboxen, bij locatiekaarten, vlaggen en wapenschilden. Die kunnen gelukkig vrij simpel botmatig worden gecorrigeerd, met enige aandacht. Michiel1972 8 jun 2009 21:40 (CEST)

Een van de redenen dat ik de frequentie wilde hebben is dat bij sommige sportartikelen consequent [Bestand:Flag of the Netherlands|20px] wordt gebruikt in plaats van het veel kortere en mooiere {{NL-VLAG}}. Artikelen die die fout maken komen bij sorteren op aantal keer al snel bovendrijven en dat kan soms veel schelen. Het zou prettig zijn als er botmatig een begin wordt gemaakt want 50.000 is handmatig nogal een ontmoedigend aantal. --Kafir 8 jun 2009 21:48 (CEST)

Ik zie trouwens in jouw bewerking dat je een vlag met breedte 18 omzet naar de default breedte. Hoe groot is de defaultbreedte? Rudolphous 8 jun 2009 22:35 (CEST)

De standaard {{NL-VLAG}}-vlaggetjes zijn allemaal 20px breed. In dat artikel werden 18 en 20 al door elkaar gebruikt en ik kan me niet zo goed voorstellen dat mensen een hele goede reden hebben om 18px door te drukken ten opzichte van een mooi sjabloontje van 20px. De voordelen van het gebruik van sjablonen zijn dat je altijd een afbeeldingsomschrijving en een border hebt, bovendien is het korter in de code en is een beetje unificatie nooit slecht. --Kafir 9 jun 2009 02:29 (CEST)

Aan Rudolphous of wie het dan ook weet, wanneer is voor het laatst de hele nl-wikipedia gescand? Enig idee wanneer er weer veel tijd vrij komt en de hele wiki weer doorgelopen kan worden? --Kafir 12 jun 2009 19:24 (CEST)

Ik denk dat dit 7 juni 2009 was. Zie ook http://nl.wikipedia.org/w/index.php?title=Wikipedia:Wikiproject/Check_Wikipedia&oldid=17128607. Rudolphous 12 jun 2009 22:41 (CEST)

With the last scan the script checked 7125 articles. is volgens mij niet uitzonderlijk. --Kafir 12 jun 2009 22:50 (CEST)

Defaultsorterrors

Onlangs zijn er een paar errors met betrekking tot defaultsorts aan de lijst toegevoegd. De software maakt blijkbaar onderscheid in hoofdletters en kleine letters. In de meeste gevallen maakt dit helemaal niet uit volgens mij en staan die kleine letters ergens achterin of worden ze heel consequent gebruikt bij alle artikelen met een soortgelijke naamgeving. Is er niet een methode denkbaar om te kijken waar dit belangrijk is. Bijvoorbeeld door te kijken waar het artikel of een defaultsort een kleine letter heeft in (pak 'm beet) de eerste vijf tekens? --Kafir 12 jun 2009 19:24 (CEST)

In principe is alleen de eerste letter een hoofdletter. Andere letterposities in een woord zijn normaliter kleine letter, anders krijg je een vreemde sortering. Er wordt geen onderscheid gemaakt tussen hoofd- en kleine letters volgens de Taalunie bij het alfabetiseren, dus na de hoofdletter zouden altijd kleine letters volgen anders zou bv de IJ voor de Ie worden gesorteerd. Romaine (overleg) 15 jun 2009 19:11 (CEST)

Ja dat is mij duidelijk, maar nu komen alle pagina's die bijvoorbeeld Lijst van [iets-met-diakriet] heten en een {{DEFAULTSORT:Lijst van [zelfde-titel-zonder-diakriet]}} hebben op die error te staan, terwijl dat geen problemen geeft zolang overal netjes van en niet Van gebruikt wordt. Het is een beetje omslachtig om alle Lijst vans met een defaultsort aan te passen. --Kafir 16 jun 2009 16:56 (CEST)

Twee nachten geen dump

Op de toolserver staat nog steeds de lijst van woensdagavond. Jammer, gaat er vanavond wel weer gescand worden? --Kafir 13 jun 2009 11:51 (CEST)

Hoi Kafir, dat is mij ook opgevallen. Is er een bepaalde fouttype die je geactualiseerd wilt zien. Dat kan ik namelijk wel even doen. Rudolphous 13 jun 2009 13:29 (CEST)

Niet echt specifiek ééntje. Liefst gewoon weer de hele lijst. Er waren best wel wat fouten die met behoorlijk wat moeite van véél naar weinig waren teruggebracht (55, 63, 66, 80, 81, 83) en graag zou ik eens kijken of die afgerond zouden kunnen worden. Daarnaast vind ik het wel een geruststellend idee dat als iemand verkeerde code, eerstegraads koppen of andere fouten maakt dat die redelijk snel verbeterd kunnen worden. Het huidige minilijstje vind ik een beetje een valse hoop geven. --Kafir 14 jun 2009 01:57 (CEST)

Stefan heeft problemen met het cpu-gebruik van zijn script. Zie ook het bericht op [10]. Hij is nu zijn script aan herschrijven, wat nog wel even op zich laat wachten. Ik heb het script gedraaid en de data output hier gefreshed. Als ik alle fouten opnieuw laat scannen krijg ik echter een "out-of-memory" error (mijn PC heeft 2Gb memory). Daarom alle fouten >= 80 voor nu even verwijderd. Rudolphous 15 jun 2009 19:07 (CEST)

Is het misschien een beter idee om (in afwachting van het verbeterde script van Stefan) de fouten die we wel controleren een beetje te rouleren? Of om bv. alleen de high-priority te doen? Of alleen diegenen te doen die min of meer uitgebannen waren? Alles vanaf 80 niet meer checken lijkt me zo arbitrair. --Kafir 16 jun 2009 17:01 (CEST)

Ik heb gisteren met een nieuw script de lijst kunnen verversen. Niet alle artikelen zijn hierdoor gescanned, maar wel de top 50 van elke categorie. Rudolphous 17 jun 2009 08:16 (CEST)

Code 068 vs. code 082

Code 068: link naar anderstalige wikipedia (nu 1241 keer)
Code 082: Link to other wikiproject (nu 1329 hits)
Links van het type [[w:en:Engelse pagina]] worden nu gevonden op code 082, maar zouden eigenlijk onder code 068 moeten vallen. Dat zou vermoedelijk het aantal foutmeldingen' in code 082 flink verlagen en het aanmoedigen om die (bv. met behulp van sjablonen) op te lossen. --Kafir 23 jun 2009 21:17 (CEST)

New interface

New interface -- sk 1 sep 2009 09:01 (CEST) Of voor de NL-Wiki: hier. Fenke 26 nov 2009 22:56 (CET)

Activiteit

Is hier nog iemand actief, aangezien het laatste overleg in 2009 heeft plaatsgevonden SomeoneNL (overleg) 13 dec 2011 03:50 (CET)

De gebruikers zijn niet hier actief maar op de toolserver. Deze pagina is gewoon een inleiding tot Check Wikipedia. - Foxie001 13 dec 2011 18:55 (CET)

Het is inderdaad een beetje lastig om wijzigingen in het kader van dit project te herkennen, omdat ze over alle pagina's in de hoofdnaamruimte verdeeld worden. - Kafir (overleg) 15 dec 2011 17:35 (CET)

Via botaccount

Besten,

ik vroeg me af of je tijdens het gebruik ook je botaccount mag gebruiken voor de wijzigingen. Sorry als deze vraag al gesteld is maar de overlegpagina is net iets te lang om het helemaal door te lezen.

Mvg, Kippenvlees (overleg‽) 17 jun 2012 19:57 (CEST)

Enkel voor de Bot-Tools. Je kunt dit zien in de bewerkingssamenvatting, er staat versie 1.27b en geen versie 1.27. Gr, Diamant | ? 22 mei 2013 15:34 (CEST)

Delete template Bronvermelding_anderstalige_Wikipedia

Sorry I speak no Dutch and this is obviously not the right place for this comment... Move it where appropriate.

Please delete the template Bronvermelding_anderstalige_Wikipedia. These are stale Interlanguage links, eg on Archimedes:

* {{Bronvermelding anderstalige Wikipedia|taal=de|titel=Archimedes|datum=20140414}}
* {{Bronvermelding anderstalige Wikipedia|taal=en|titel=Archimedes|datum=20140414}}

Since Wikidata provides a whole bunch more links on the left, I don't see how these are useful.

They make trouble on DBpedia. Because of this stupid mapping: http://mappings.dbpedia.org/index.php/Mapping_nl:Bronvermelding_anderstalige_Wikipedia, Archimedes is declared to be an Article.

I'll remove the mapping and add it to ignorelist_nl

See issue 341 Vladimir Alexiev (overleg) 25 feb 2015 03:48 (CET)

Hi Vladimir, thanks for your message. I've moved it to this talk page. The template is used to comply with the terms and conditions of the Creative Commons license (CCBYSA). Articles can be (partly or fully) translated from other Wikipedia projects, but only if the creators of the original article are credited. We do this by referring to the edit history of the original articles, using {{Bronvermelding anderstalige Wikipedia}}. In this case, 'Cite' may be a more appropriate translation of "Bronvermelding" than 'Source'. Please let me know if you have any further questions or concerns. Kind regards, Mathonius 25 feb 2015 04:33 (CET)

Niet elke verbetering is een verbetering

Met uw welnemen, ik vond dit geen verbetering. ErikvanB (overleg) 25 apr 2016 18:52 (CEST)

Beste Erik, hoewel ik bij deze bewerking geensdeels betrokken ben, was of ben geweest, begrijp ik wel waar het over gaat. De verschillenweergave van Wikipedia geeft aan dat er een verschil is, maar je ziet geen verschil. Rara. Tip: ga naar de 16 januari-versie van dit artikel, open die versie voor bewerken, en kopieer de tekst van de Iraanse kalender naar Windows Kladblok. Dan zie je dat op ieder van de gevlagde regels, net links van ", 31 dagen" (dan wel 30 of 29) een tekentje staat dat eruitziet als een rechtsafslaan-pijltje. Dat valse teken is door RallyKat weggehaald. Wat mij betreft: terecht; want het teken is, hoewel onzichtbaar in de browser, wel aanwezig, en zit bijvoorbeeld in de weg bij een zoekopdracht. Groetjes, Vinkje83 (overleg) 25 apr 2016 19:40 (CEST)

Ik zie wel een verschil, in Chromium-gebaseerde browsers en in een oude versie van Firefox. In deze browsers zorgde dit tekentje ervoor dat de haakjes en cijfers op de juiste plek komen te staan. Dit tekentje zal dan waarschijnlijk een links-naar-rechts-teken (left-right mark, LRM, U+200E) zijn geweest. Ik zie geen verschil in moderne Firefox, IE of Edge, dus denk ik dat het geen kwaad kan. Misschien kan de versie zonder LRM tussen <!-- en --> geplaatst worden voor zoekopdrachten. --bdijkstra (overleg) 13 aug 2017 10:52 (CEST)

Aanvulling: misschien een sjabloon aanmaken dat dit tekentje invoegt zodat het zowel duidelijk is in de wikitekst alswel geen foutmelding geeft in CW? --bdijkstra (overleg) 14 aug 2017 18:58 (CEST)

 Uitgevoerd sjabloon:lrm aangemaakt. --bdijkstra (overleg) 28 aug 2017 18:42 (CEST)

Andere checks

Op dit moment lijkt dit Wikiproject volledig gericht te zijn op het checkwiki-script, terwijl de doelstelling veel algemener is. Zo staan er ook syntaxproblemen in Categorie:Wikipedia:Pagina's waar iets mee is en natuurlijk Speciaal:LintErrors. Deze beide kunnen wel wat meer aandacht gebruiken maar hebben volgens mij geen Wikiproject of andere pagina in de Wikipedia-naamruimte om kennis hierover te delen en eventueel zaken af te stemmen. Is er een bezwaar om de scope van dit project met deze 'checks' uit te breiden? Zo nee, dan zal ik deelnemer worden. –bdijkstra (overleg) 8 feb 2018 18:46 (CET)

 Steun Is altijd goed voor de afwisseling en net zo nuttig. Wikiwerner (overleg) 8 feb 2018 21:08 (CET)

Wat is het probleem HTML named entities?

Waarom moeten HTML named entities zonodig vervangen worden? Op een pagina waar "dash", "minus" en "ndash" allemaal voorkomen, is het niet prettig wanneer deze in de wiki code als "-", "−" en "–" zijn opgenomen. Zeker het verschil tussen de "minus" en "ndash" is amper te zien. Mensen die de pagina maar incidenteel bijwerken, gebruiken dan ook steevast het verkeerde teken. De "&minus;" en "&ndash" vermijden dit probleem en zijn niet voor niets als zodanig gedefinieerd. En dit geldt niet alleen voor de nu door mij genoemde HTML named entries. Sb008 (overleg) 14 mei 2018 01:07 (CEST)

Eens met bovenstaande. (Maar, het gaat om entity's, niet entries.) Ofwel uitzonderingen maken voor bepaalde tekens, ofwel check #11 uitschakelen (zoals ze op enwiki hebben gedaan). –bdijkstra (overleg) 14 mei 2018 17:34 (CEST)

Zijn idd entities, misschien het tijdstip dat ik entries gebruikte. En het is idd check 11. Wat ik het erge vind, is dat degene die gemeend heeft hier wel blind op te moeten acteren, niet eens het fatsoen heeft om op deze zelfde vraag (inmiddels bijna 3 dagen geleden) te antwoorden. Maar ondertussen wel de tijd heeft om vele andere wijzigingen uit te voeren. Daarmee is het voor mij geen goedbedoelde aanpassing meer, maar puur vandalisme. We doen allemaal wel eens iets te snel, of maken fouten. Daar kan ik mee leven. Maar zwijgen als het graf wanneer je dan vragen gesteld worden en geen actie ondernemen om eea recht te zetten, getuigt van weinig fatsoen. En met zulk gedrag schiet dit project zijn doel voorbij. Sb008 (overleg) 14 mei 2018 18:15 (CEST)

Ehm. Bedankt voor uw mening, nu die van mij. Ik vul regelmatig – in. Ik was me niet erg bewust van het bestaan van check #11 maar ik prefereer "-", "−" en "–" boven "dash", "minus" en "ndash" net zo goed als ik "ë" boven "euml" prefereer. Ik vind persoonlijk dat u zich nogal ongenuanceerd uitlaat en de arrogantie al binnen 3 dagen antwoord te verwachten belachelijk. U zit er zowel met de inhoud als de vorm van uw bijdragen naast. Dit hierbij ter kennisgeving, ik ga er niet verder over discussiëren. –Frank Geerlings (overleg) 14 mei 2018 19:55 (CEST)

@Frank Geerlings: Ik weet niet hoe zorgvuldig je hebt gelezen, maar in mijn vorige reactie stond "Maar ondertussen wel de tijd heeft om vele andere wijzigingen uit te voeren." Ik verwacht in beginsel niet dat iemand binnen 3 dagen reageert. Iemand hoeft immers binnen die tijd in zijn geheel niet online te zijn. Echter wanneer iemand in die periode wel in staat is om 150-200 andere bewerking uit te voeren en niet reageert op een bericht, dan zie ik dat als een uiting van totale desinteresse (mijn subjectieve mening). Het effect van het gebruik van de "-", "−" en "–" in de Wiki code, zoals de praktijk leert, is binnen no time te merken. Binnen de kortste tijd staan er nagenoeg alleen nog -'s (dashes) op de pagina. Tenminste daar waar het dynamische pagina's betreft, zoals sportpagina's met standen, uitslagen, positieve en negatieve waarden, oftewel waar het gebruikte teken van belang is. Op statische pagina's met e.g. tekst zal het niet snel tot fouten leiden wanneer de "ë" ipv de "&euml;" wordt gebruikt. Omwille van foutpreventie heb ik dan ook een zeer duidelijke voorkeur voor HTML named entities. Dat jouw voorkeur anders is, is evident. Maar het is in zijn geheel niet relevant wat jouw of mijn voorkeur is. Feit is, er is niets fout aan het gebruik van HTML named entities. Deze vervangen onder het mom van "fout" is derhalve bogus. Zoals je ziet motiveer ik mijn mening. Jij komt niet verder dan te zeggen dat ik op zowel inhoud als vorm ernaast zit. Dit zonder enige motivatie, hetzij jouw preferentie<punt> is een motivatie. Laat mij dan maar arrogant en ongenuanceerd zijn. Ik zou zeggen; wie de schoen past trekke hem aan.Sb008 (overleg) 14 mei 2018 23:22 (CEST)

Pierre Devaux

Op basis van wat is de categorie Belgisch olympisch deelnemer bij deze atleet geschrapt? Volgens de bestaande bronnen heeft hij in 1920 deelgenomen aan de 10.000 m. Akadunzio (overleg) 23 jul 2022 13:25 (CEST)

Kijk eens goed naar de oude versie. –bdijkstra (overleg) 23 jul 2022 15:53 (CEST)

Ik had dus niet goed gekeken. Het was dubbel. Akadunzio (overleg) 23 jul 2022 18:32 (CEST)