Overleg gebruiker:RonnieV/Sjablonen inzonders Tabel hitnotatie

(Afgesplitst van Overleg_gebruiker:RonnieV) RonnieV 15 dec 2010 00:35 (CET)

Sjablonen (inzonders Tabel hitnotatie)

Hallo RonnieV, Ik zie dat je vandaag een hele serie sjablonen hebt aangemaakt. Ik zag eerder dat je op mijn overlegpagina een bericht had achtergelaten, maar door drukte ben ik er niet toegekomen daar eerder gehoor aan te geven. De sjablonenbrei die je gecreëerd hebt is absoluut niet geschikt voor Wikipedia en zal ik nomineren voor verwijdering. Sjablonen dienen onderhouden te kunnen worden door meerdere gebruikers, waarbij het noodzakelijk is dat sjablonen relatief eenvoudig zijn zodat gebruikers met gemiddelde tabelkennis er mee om kunnen gaan. Tevens zijn allerlei lagen geneste sjablonen zéér ongewenst, omdat ze het onderhoud zeer onoverzichtelijk maken, en dat onderhoud is iets wat op gezette tijden terugkomt en nooit en te nimmer afhankelijk mag zijn van een enkeling die een uitermate complex sjabloon heeft gebouwd. Er hoeft maar één update in de Mediawiki-software plaats te vinden en op een enkeling na kan niemand de problemen dan verhelpen. Hetzelfde geldt voor een foutje ergens of een wens tot aanpassing van iets, en dan dient dat niet een uitgebreide sjablonenbrei te zijn die slechts voor een enkeling te verhelpen is. De kern is een samenwerkingsproject waarop gebruikers met gemiddelde tabelkennis problemen in sjablonen moeten kunnen verhelpen, omdat een project als Wikipedia nooit door slechts één persoon gebouwd kan worden en het dus nooit van slechts een enkeling afhankelijk mag zijn. Tevens zie ik dat er een enorme hoeveelheid parserfuncties gebruikt zijn. Het is voor veel gebruikers niet bekend, maar er bij een te grote hoeveelheid parserfuncties kunnen pagina's erg langzaam geladen worden voor gebruikers, alsmede dat het systeem van Mediawiki een te grote hoeveelheid parserfuncties op een artikel op een gegeven moment niet aankan. In het verleden zijn er diverse complexe sjablonen om dezelfde redenen genomineerd en verwijderd, omdat ze voor Wikipedia veel te complex zijn en onnodig uitgebreid en moeilijk zijn. Het gaat hier om eenvoudige tabellen die bij problemen door iedereen met een beetje tabelkennis onderhouden en en aangepast kunnen worden, een simpele tabel volstaat gewoon hiervoor. Het spijt me als ik je teleurstel en ik het had wellicht handiger geweest als ik je dit eerder al had aangegeven, maar dit gaat echt te ver. Groetjes - Romaine (overleg) 19 nov 2010 20:10 (CET)

Beste Romaine, Je stelt me inderdaad erg teleur met deze reactie. De presentatie van de hitnoteringen is, bij nog genoteerd staande nummers, iets dat iedere week verandert. Daarbij is het wenselijk dat een aantal dingen die wekelijks kunnen veranderen, zoals de hoogst bereikte notering, automatisch meegenomen kunnen worden. Dit sjabloon kan dat inmiddels allemaal aan. Er is een hoop gesteggel geweest over het gebruik van tabellen en sjablonen, en dat leek een uitzichtloze situatie, waarbij twee gebruikers elkaar geregeld in de haren gevlogen zijn, en ook al enkele malen geblokkeerd zijn wegens reverts.

Ik heb een aantal weken geleden aangegeven dat ik hiermee bezig was, en heb van Goudsbloem een aanmoedigende reactie gekregen. Ik heb de beide kemphanen in deze materie, Erik Baas en Mager, benaderd. Erik gaf aan het voor hem maximaal haalbare gegeven te hebben. Met Mager heb ik nog eens goed naar de werking gekeken, en dat heeft een aantal verbeteringen opgeleverd. Ik heb jou om een reactie gevraagd, omdat jij je vaker inlaat met sjablonen. Nu ik niets van jou hoorde, heb ik de sjablonen neergezet, en ik ben van plan deze vanavond op de pagina's die gebruik maken van het al bestaande sjabloon 'Tabel hitnotatie', in te zetten.

Ik realiseer me dat het niet iedereen gegeven zal zijn om deze sjablonen aan te passen. Dat is doordat ik een balans heb moeten zoeken tussen de beperkingen die Wikipedia stelt enerzijds en de gewenste functionaliteit anderzijds. Als een recursieve functie toegestaan was, had ik al vier sjablonen kunnen schrappen... Een for- of while-lus had nog meer gescheeld... Helaas moet ik het doen met de bestaande parserfuncties. Ik realiseer me dat het gebruik van een (groot aantal) parserfuncties een zeker beroep doet op de server bij het genereren van de uiteindelijke output van een pagina. Op mijn eigen testpagina gebruik ik een keer of 20 dit sjabloon, en deels alle beschikbare mogelijkheden, en daar is het merkbaar. In de praktijk wordt het tot drie keer op een pagina gebruikt, en met de daarbij bekeken pagina's zag ik geen merkbaar verschil. In een aantal gevallen zal optimalisatie van het gebruik mogelijk zijn, door de waarden voor breedte en hoogte als parameter mee te geven bij het sjabloon. Dan hoeven deze niet berekend te worden. Dit kan in ieder geval bij het bereiken van de eerste plaats of als een hit uit de notering verdwenen is. Eventueel kan de berekening van de hoogte, best een lastige met al die Min-functies, vervallen en kan hiervoor een parameter gebruikt worden.

Ik ben zonder meer bereid om, zoals al een klein beetje gebeurd is, de werking van het sjabloon uit te leggen. Om te vertellen wat ieder stukje doet, en hoe het is opgezet. En als jij ideeën hebt hoe ik -met behoud van functionaliteit- deze verzameling sjablonen overzichtelijker kan maken, dan wil ik daar natuurlijk graag aan meewerken!

Ik zal erg teleurgesteld zijn als deze oplossing voor een hoog opgelopen vete verworpen wordt, en ook als alle erin gestoken tijd, hoe leuk en leerzaam soms ook, voor niets geweest is. Vriendelijke groetjes, RonnieV 19 nov 2010 23:10 (CET)

Hoi Ronnie!

Eerst en vooral: wat Romaine vergeten is om te vermelden is dat het feit dat je bereid bent mee te denken over een mogelijke oplossing van dit probleem zeer lovenswaardig is.

De strijdende partijen, die onderdeel van het probleem zijn, komen er niet uit. Wij willen hier alle drie onderdeel van de oplossing zijn, en dus is het belangrijk om niet in de valkuil te trappen om ook onderling te gaan strijden. Ik kan me het gevoel van teleurstelling goed indenken. Romaine verwoord het bericht anders dan ik dat zou doen, maar heeft wel veel verstand van sjablonen op Wikipedia en de techniek daarachter. Het zou zonde zijn als het schip hier zou stranden, we hebben immers een gezamelijk doel voor ogen (het vinden van de optimale oplossing), en dus zou ik je willen vragen of je bereid bent mee te denken over een alternatieve methode, met wat technische verbeteringen, hoewel het door de browser weergegeven resultaat er sterk op zal lijken.

Met vriendelijke groet, Kwiki overleg 20 nov 2010 23:56 (CET)

Hoi Kwiki,

Allereerst bedankt voor je reactie.

Ja, ik ben zeker bereid om mee te denken over een alternatieve methode. Van mijn sjablonen kan ik bijvoorbeeld HNToonDatum opnemen in HNKop. Dan staat er alleen vijf keer dezelfde code. Programmeertechnisch een blunder, maar als dat het parsen vermakkelijkt, doe ik dat. Zo kan ook HNHoogste weg, als we die parameter als gegeven veronderstellen. Daarmee vervallen HNMin en HNM ook. Ook over iets anders wil ik nadenken, waarbij een sjabloon wel mijn voorkeur heeft.

Goed om in ieder geval voor ogen te houden dat wij een gezamenlijk doel hebben, en dat het niet de bedoeling is om hier een (extra) strijd om te gaan krijgen. Het doel is een goede presentatie van deze gegevens, die zo makkelijk mogelijk is voor de gebruikers.

Met vriendelijke groet, RonnieV 21 nov 2010 15:29 (CET)

Hoi Romaine en Kwiki,

Ik wil graag verder met deze uitdaging en tot een bevredigende oplossing komen. Bevredigend voor de gebruikers, en als het een beetje zou kunnen, ook voor jullie en mij ;) Globaal zie ik vier richtingen:

1. Ik (we) gaan dit nieuwe sjabloon ongewijzigd inzetten (overzetten naar Sjabloon:Tabel hitnotatie (case-sensitive) en de pagina's waarop het gebruikt wordt waar nodig aanpassen);
2. Ik verzorg een stuk aanvullende informatie en daarna zet ik/zetten we deze sjablonen in (heb hier al iets in gedaan);
3. We optimaliseren deze sjablonen voor Wikipedia (m.n. de server) en zetten ze dan in;
4. We gooien deze sjablonen weg en kijken wel wat er gebeurt...

Het mag duidelijk zijn dat mijn voorkeur uitgaat naar een van de eerste drie opties. Ik vind het jammer dat het stil blijft van jullie kant, terwijl ik graag verder wil.

Met vriendelijke groeten, RonnieV 23 nov 2010 17:35 (CET)

Hallo RonnieV, Romaine en Kwiki. Hoop dat er snel een goed werkend sjabloon komt. RonnieV ga vooral door. Romaine help ons a.u.b. Hopelijk komt er een oplossing. Met vriendelijke groeten Mager112001 23 nov 2010 21:09 (CET)

Ronnie, ook van mij nog een goed woordje. Je bent goed bezig met de hitnotatie-tabel. Wat Romaine wil zeggen is dat het zo simpel mogelijk moet zijn om de sjabloon te gaan gebruiken én te bewerken. Ik hoop dat het je lukt om een zo goed (en simpel) mogelijk sjabloon te maken. Niet opgeven, je kan het! Goudsbloem 23 nov 2010 22:07 (CET)

Dank jullie... Ik probeer in contact te komen met Romaine, want ik wil graag van hem horen of de ideeën die ik heb voldoende zijn om het alsnog 'goedgekeurd' te krijgen. Volgens mij is de gebruikerskant wel in orde (daar hoor ik Romaine in ieder geval niet over), maar moeten we kijken hoe we de 'achterkant' kunnen optimaliseren, zodat de server ermee uit de voeten kan. Mocht je nog ideeën hebben voor de voor- of de achterkant, dan hoor ik dat graag! Met vriendelijke groet, RonnieV 23 nov 2010 22:15 (CET)

Sorry voor de vertraging, maar het is momenteel even topdrukte om alles gedaan te krijgen. Ik hoop dat dat zich gauw normaliseert.

Er is al in het begin van de discussie weken terug duidelijk aangegeven dat een sjabloon niet 100% haalbaar is, gezien de beperkingen en mogelijkheden die we hebben in de Mediawiki-software en gezien de eisen die we op dit project aan sjablonen stellen. Ik had wellicht vaker/eerder kunnen reageren, maar de tijdnood van de laatste weken maakt dat erg lastig en dan blijven er dingen liggen. Er kwam na de discussie een duidelijke conclusie: een goed onderhoudbaar sjabloon die aan alle eisen en wensen voldoet is niet haalbaar. Als experts op het gebied van sjablonen dat vaststellen, dan kun je toch iets proberen, maar zinvol is het dan zeker niet. Dat is misschien heel teleurstellend, dat voel ik duidelijk aan, maar dan staat het antwoord allang vast.

Van de situatie waar het hier om gaat ben ik al vanaf het prille begin op de hoogte en ik heb volledig meegekregen waar het om gaat. Het probleem was niet dat er iets niet ging, het probleem was hoe men met elkaar en elkaars bijdragen om ging en of men wel samen tot een oplossing wilde komen. Wanneer alle problemen op een rij gezet werden was de oplossing heel simpel: een simpele eenvoudige tabel waarin de gebruikte code zodanig toegepast is dat die op orde is. Tabellen zijn zeer variabel en op maat gemaakt aan te passen. De tabellen waar het om ging variëren continu in breedte, continu in het aantal cellen, etc, belangrijk is dus te realiseren dat ze zeer variabel zijn afhankelijk van de pagina in kwestie. Hét kernpunt van sjablonen daarentegen is dat ze juist een vaste basis hebben, met slechts een beperkt aantal variabele zaken, waarbij de nadruk zeer duidelijk ligt bij het constante. Samengevat betekent dit dat als je zéér flexibele tabellen wilt hebben (zoals bij hitnotatie), dit niet eenvoudig en simpel te regelen valt via een sjabloon. Voor de tabellen van de hitnotatie is een sjabloon in essentie niet geschikt, tenzij je via een heleboel kronkels, heleboel parserfuncties en een heleboel code zo'n eenvoudige tabel opbouwt, en dat terwijl er prima volstaan kan met eenvoudige tabelcode! Met andere woorden, waar het eenvoudig kan, doen we het ook eenvoudig, en gaan we geen uitgebreid sjablonenstelsel ontwerpen omdat dat nergens toe dient. Ik heb gemerkt dat bouwers van dat soort complexe sjablonenstelsels in het verleden met regelmaat blijk hebben gegeven dat zij niet kunnen begrijpen waarom we het KISS-principe hanteren met sjablonen, maar ik hoop dat jij het wel begrijpt. De nominatie en verwijdering van zo'n uitgebreid sjablonenstelsel is onvermijdelijk, hoe teleurstellend dat ook kan zijn voor de bouwer. Een heel belangrijk aspect van sjablonen is dat ze onderhouden kunnen worden door een vrij ruime groep aan gebruikers. Door de jaren heen hebben we gezien dat er steeds weer gebruikers afhaken, waaronder ook complexe sjablonenbouwers, met als gevolg dat sjablonen met een complex ontwerp een tikkende tijdbom vormen voor de gemeenschap. In de voorbije jaren zijn er verschillende updates geweest (maandelijks/meer worden er updates uitgevoerd) in de Mediawiki-software waarbij er voor gebruikers in artikelen zelf meestal weinig veranderd is, maar in sjablonen die sowieso al erg gevoelig zijn, met dat soort updates zeer kwetsbaar zijn en heel erg gauw fouten gaan vertonen. Sjablonen moeten daarom onderhoudbaar zijn voor gebruikers met gemiddelde tabelkennis, zodat het nooit en te nimmer afhankelijk is van één persoon of een paar personen, maar dat een groot deel van de gemeenschap in staat is aanpassingen te kunnen doen bij problemen. "Anyone can edit" is een basisbeginsel die voor de wiki geldt, en die wordt te sterk aangetast door uitgebreide complexe sjablonenstelsels. (zo ook bij Hitnotatie) En dan werkt documentatie niet als oplossing, want de structuur is te uitgebreid en te complex zodat het overzicht te gauw verloren is door alle gebruikte code (terwijl bij dit sjablonenstelsel een eenvoudige simpele tabel volstaat!). Om die reden zijn geneste sjablonen en vele lagen van geneste parserfuncties taboe op nl-wiki en zijn er om die redenen in het verleden diverse complexe sjablonenstelsels verwijderd. Je zegt dat je de balans hebt lopen zoeken, maar je hebt belangrijke aspecten gemist die we aan sjablonen stellen, en die stellen we niet voor niets, met als gevolg dat de balans in het door jou opgezette sjablonenstelsel zoek is. Het toepassen van dit sjabloon op artikelen is daarom niet wenselijk. Techniek is nooit een oplossing. Een sjabloon heeft hier absoluut geen meerwaarde, maar alleen maar problemen en beperkingen die niet eens nodig zijn omdat met een eenvoudige tabel op artikelen kan worden volstaan zoals reeds tijden het geval is.

De essentie van de situatie is dat er reeds een oplossing voor handen is zonder enig sjabloon, en die oplossing wordt naar verwacht nog dit jaar overal op al die duizenden artikelen doorgevoerd met bots. Enkel door tijdgebrek is die nog niet uitgevoerd, maar dat zal zeker gaan gebeuren.

Ik ben misschien onhandig in mijn woorden, maar ik krijg de indruk dat de boodschap met informatie nog steeds niet is doorgekomen: een sjabloon dat aan alle eisen en wensen voldoet is niet haalbaar, zoals reeds eerder vastgesteld, een tabel echter wel. Waar we kunnen volstaan met een eenvoudige tabel, kunnen we volstaan met een eenvoudige tabel, en dat is hier het geval, en daar zijn complexe sjablonenstelsels niet bij nodig en bovendien ook ongewenst. Het zou voor mij veel leuker zijn om goed nieuws te brengen, maar dit is wel de situatie zoals die er ligt en niet om heen kunnen. Slecht nieuws is nooit leuk, niet om te brengen, noch te ontvangen, daar heeft Kwiki gelijk in, en laat ik daarom eindigen met goed nieuws (al is dat al lang bekend): er is een eenvoudige oplossing en die wordt binnen de komende weken overal toegepast. Groetjes - Romaine (overleg) 23 nov 2010 22:17 (CET)

Beste Romaine, Bedankt voor je uitgebreide reactie.

Vooraleer ik inhoudelijk ga reageren, wil ik even zeggen dat het voor mij een hoop wrevel had gescheeld als ik eerder had gehoord dat je wel wilt reageren op mijn vragen en opmerkingen, en niet iemand volledig in het ongewisse laat. Te meer omdat ik zie dat je wel actief bent, wel op andere punten reageert, kreeg ik de indruk dat je niet wilde reageren. Gelukkig ten onrechte, maar dat blijkt pas na verloop van tijd.

Dat gezegd hebbende, terug naar het probleem en een/de oplossing. Ik zal ongetwijfeld iets gemist hebben, maar ik kan me niet herinneren ergens gelezen te hebben dat een sjabloon technisch onmogelijk zou zijn. Daarnaast vormt dat dan een uitdaging, en in alle bescheidenheid denk ik dat mijn sjabloon heel goed de wensen van de gebruikers afvangt (zie de reacties hierboven van twee fanatieke gebruikers). Dat er vanuit de beheerszijde bezwaren bestaan, is in mijn ogen iets dat we binnen Wikipedia.nl moeten oplossen, met de gebruikers die dat kunnen. Ik heb een aantal voorstellen gedaan om zaken te vereenvoudigen, en ik zou jou graag willen vragen daarin mee te denken. Daarbij denk ik dat een stuk documentatie over de werking en samenhang wel degelijk kan bijdragen aan de onderhoudbaarheid, omdat iemand die er met deze handleiding naar kijkt, relatief snel de werking doorgrondt.

Anders dan jij denk ik dat eenvoudige tabelcode niet de handigste oplossing is voor de notering van hits die nog genoteerd staan. Zeker met de gewenste variabele breedte van de tabel (bij mij ook nog niet volledig doorgevoerd, maar eenvoudig te realiseren door de aanwezigheid van de parameter breedte), betekent dat dat er geregeld cellen opnieuw verdeeld moeten worden over verschillende rijen. Aangezien je met twee samenhangende rijen zit, (weken en posities) is dat niet optimaal. Dat geldt ook voor de vetmarkeringen van de hoogste bereikte positie, die nog wel eens wil veranderen. Dat was voor mij reden om er een parameter van te maken, en ik zag het als een uitdaging om die te berekenen. Het weglaten van die berekening scheelt al aardig in de hoeveelheid uit te voeren code.

Ik ben bekend met het KISS-principe en begrijp dat wij dat op Wikipedia willen nastreven. Eenvoud siert de mens. Alleen gaat eenvoudig voor de gebruiker en eenvoudig voor de beheerder niet altijd hand in hand. In mijn werk analyseer ik problemen van gebruikers en bouw daar oplossingen voor, veelal met gebruik van databases. Het is werk om dat op te zetten, maar daarna eenvoudig voor de gebruiker. Dat is dit sjabloon ook.

Dat de Mediawiki-software zo vaak wordt bijgewerkt, heb ik me niet gerealiseerd. Ik kan me daar wel iets bij voorstellen. En als dat risico's met zich mee brengt voor bestaande sjablonen, moeten we streven naar een zo solide mogelijke oplossing. Ik wil me daar best verder in verdiepen, en kijken wat ik kan doen voor Wikipedia. Ik loop al een tijdje rond op Wikipedia (niet zo lang als jij), en ben wel eens op zoek geweest, maar echt veel documentatie over sjablonen (en vooral over de door jou hierboven geschetste beperkingen) heb ik niet kunnen vinden. Ligt dat aan mijn zoeken, of zijn dit meer losse stukjes in allerlei archieven en hoofden?

Jouw verhaal lezend, ontkom ik niet aan de indruk dat er al een beslissing genomen is. Ik vind het jammer dat daarmee eigenlijk vooraf al de deur is dichtgegooid voor mijn oplossing. Misschien nog wel meer jammer is het dat dit niet duidelijk is aangegeven op diverse plaatsen. Dat had zeker kunnen schelen in conflicten tussen Mager en ErikBaas, conflicten die al enkele keren geleid hebben tot blokkades.

Vriendelijke groeten, RonnieV 23 nov 2010 23:14 (CET)

Ronnie, na het bovenstaande gelezen te hebben van Romaine, is het misschien niet mogelijk voor jou om op een simpele manier het huidige Sjabloon:Tabel hitnotatie zo aan te passen dat de weeknummering niet doorloopt boven lege vakjes als een plaat/album 'uit' gaat en later weer in de hitlijst komt? Dat was de enige échte fout die dat sjabloon nog had. De vele lege cellen op sommige artikelen verdienen niet de schoonheidsprijs, maar waren niet fout. Het was al eerder aan Erik Baas gevraagd om er nog eens naar te kijken, maar die heeft zijn buik er een beetje aan vol zei hij. Dus mijn vraag aan jou Ronnie, of je nog eens kunt kijken of je dat probleem simpel kunt oplossen in dat sjabloon. Misschien komen we er op die manier toch nog uit.... Goudsbloem 23 nov 2010 22:45 (CET)

Hoi Goudsbloem, Ik ben zeker bereid om te kijken of we het sjabloon van Erik in die richting kunnen uitbreiden, of dat ik mijn sjablonen zo kan aanpassen, dat deze eenvoudiger worden qua code en dan wel dit effect kunnen opleveren. Duidelijk is (in ieder geval voor mij) dat het niet kan met één enkel sjabloon, als er verschillende 'uit's ondervangen moeten kunnen worden. Ik krijg alleen de indruk uit het verhaal van Romaine dat 'men' niet aan een sjabloon wil, en terug wil vallen op tabellen. Ik zie daarin een aantal onderhoudsbezwaren aan de kant van de 'gewone gebruiker', die er veel minder zijn met een sjabloon. Ik wil de komende dagen wel 'even' kijken wat ik kan doen, maar liefst pas als ik weet dat het een zinvolle exercitie kan zijn... Vriendelijke groeten, RonnieV 23 nov 2010 23:22 (CET)

In mijn ogen ben je met een zinvolle exercitie bezig indien we door een goed en simpel sjabloon al het gelul rondom die hitnotaties (die in mijn optiek zeer gewenst zijn) kwijt zijn... Doe je best en laat je hersenen kraken!! Vriendelijke groet, Goudsbloem 23 nov 2010 23:33 (CET)

Uitdagingen zijn er om aan te nemen ;) Maar vanavond niet meer... RonnieV 23 nov 2010 23:37 (CET)

Mijn idee...weltrusten. Goudsbloem 23 nov 2010 23:39 (CET)

Jij ook een goede nachtrust... En bedankt voor je meedenken hier en elders op Wikipedia! RonnieV 23 nov 2010 23:42 (CET)

Het lijkt er op dat jullie een belangrijk stuk van de discussie gemist hebben: de kern van de hele discussie, inclusief de daarbij horende oplossing. Waar het probleem tussen de betrokken gebruikers ontstond was het artikel California Gurls waar beide erg onhandig op elkaar inspeelden met een editwar als resultaat. De essentie is dat er in de tabelcode fouten en onhandigheden zitten die er uit dienen te gaan. De oplossing hiervoor is dat ik op korte termijn met mijn bot die fouten er uit ga halen zodat het probleem op eenvoudige wijze is opgelost. Zoals je ziet, een simpele tabel die hier voldoet, waarbij alleen de code op al die duizenden artikelen daarop aangepast moet worden. Dat is de oplossing die eenvoudig is en volstaat voor dit doel, zonder allerlei moeilijke sjabloonconstructies, KISS is een van de belangrijkste uitgangspunten op het project. Groetjes - Romaine (overleg) 24 nov 2010 02:07 (CET)

Ik weet het Romaine, ik zat er vanaf het begin bovenop als je de discussies op hun OP's gevolgd heb. Erik vond die fouten storend, en wilde een oplossing in de vorm van een sjabloon. Prima gedachte, want als er dan iets veranderd moet worden, hoef je niet steeds duizenden artikelen aan te passen, maar kun je dat doen d.m.v. één sjabloon. Enig minpunt was het feit dat de weken doorliepen bij een tussentijdse 'uit'. Indien Ronnie dat nu op een simpele manier zou weten op te lossen, dan is dat toch de kortste klap, met name voor de toekomst? Op dit moment die duizenden artikelen aanpassen is prima, elke fout weg is een verbetering. En Mager kan (omdat hij de hitnotaties elke week bijwerkt) dan langzaam die tabellen gaan vervangen voor dat sjabloon. Dat is naar mijn mening de mooiste oplossing. Vriendelijke groet, Goudsbloem 24 nov 2010 09:07 (CET)

Door met een bot al die tabelfouten op te sporen en te verhelpen zijn we ook in één keer van de problemen af. Met het oplossen van de tabelfouten wordt de kern van dit conflict aangepakt. Ik denk dat die oplossing nog veel makkelijker te realiseren is dan een sjabloon waar Erik Baas, Mager112001, Romaine én anderen zich in kunnen vinden. Het is op zich prima om in de tussentijd na te denken over een nieuw of verbeterd sjabloon om de hitnoteringen te vermelden, maar voorlopig is er geen noodzaak voor zo'n sjabloon en kan met het tackelen van de tabelfouten volstaan worden. Met andere woorden, de oplossing is heel simpel en bovendien spoedig realiseerbaar. Ik denk dat het voor de overzichtelijkheid handig zou zijn als we het overleg over een eventueel sjabloon onder een ander kopje voortzetten. Zijn jullie het met mij eens dat het een goed idee is om Romaine en zijn bot aan het werk te zetten? Met vriendelijke groet, Mathonius 24 nov 2010 09:44 (CET)

Hoi Mathonius, Ik ben het met je eens dat het goed is om de discussie over de vorming van een nieuw sjabloon ergens anders te voeren. Dat kan bijvoorbeeld op Overleg_sjabloon:Tabel_Hitnotatie of op Overleg_sjabloon:Tabel_hitnotatie. Het klinkt mij als dubbel in de oren om de komende weken alle tabellen op te sporen (kan dat echt automatisch?) en hiervan de HTML-code aan te passen, om later alles weer om te zetten naar sjablonen. Toegegeven, het sjabloon Tabel hitnotatie wordt op nog geen 200 pagina's gebruikt, maar het lijkt mij makkelijker om het sjabloon om te bouwen naar het definitieve beoogde resultaat en dan de rest ook daarheen te brengen.

Vaak worden onder druk goede resultaten bereikt, en ik ben bang dat als er nu besloten wordt alles om te zetten naar tabellen, het nog meer moeite gaat kosten om mensen hierbij te betrekken en te activeren om een sjabloon te beoordelen en in te gaan zetten. Ik vrees dat we dan opeens weer een hele tijd verder zijn.

Als er de mogelijkheid bestaat om een sjabloon te gaan gebruiken hiervoor, zou het mijn voorkeur hebben om dat zo snel mogelijk te doen. Maar waar jij en Goudsbloem aangeven dat er wel een mogelijkheid is om een sjabloon in te gaan zetten, hoor ik van Romaine een ander geluid. Ik weet niet wat de beste plek is om die discussie te voeren, maar ik zou die graag eerst bespreken. Met vriendelijke groeten, RonnieV 24 nov 2010 23:22 (CET)

Romaine is volgens mij niet tegen het gebruik van een sjabloon, maar wel tegen het gebruik van een ingewikkeld/complex sjabloon. Daarom was ook mijn vraag aan jou, Ronnie, of jij het huidige sjabloon hitnotatie (die Erik Baas dus is begonnen) zo kan aanpassen dat het probleem met de verkeerde weekweergave indien een plaat tussentijds 'uit' is geweest wordt opgelost zónder dat het sjabloon ingewikkeld wordt en serverruimte gaat vreten... Goudsbloem 24 nov 2010 23:44 (CET)

Ik heb op zich geen enkel probleem met sjablonen, ik werk er veelvuldig mee en sjablonen kunnen prima werk doen. Maar ik kijk wel heel erg praktisch: wat is er mogelijk binnen de huidige situatie, en dan rekening houdend met alle eisen, gebruiken enzovoorts, maar ook wat het oplevert. Als er een eenvoudiger alternatief bestaat (wat dat ook is) dan is een complexere variant onnodig. En als er geen relatief eenvoudige variant mogelijk is, dan moet er serieus afgevraagd worden of een uitgebreid complexe sjablonenstelsel wel wenselijk is, omdat het tornt aan basisbeginselen van dit project en belangrijke principes ondermijnt. Ik heb van Erik Baas begrepen dat hij bezig is geweest om met een beperkte hoeveelheid code een sjabloon vorm te geven die aan alle wensen zou voldoen, maar hij heeft aangegeven dat na diverse testen dat onmogelijk bleek. Wat hem wel lukte is een sjabloon dat niet aan die wensen voldoet, en dus niet echt geschikt is en er bezwaar tegen is. Het is dus duidelijk dat een sjabloon niet haalbaar is, terwijl er wel al jaren volstaat wordt met gewone eenvoudige tabellen. Op zich is er niets mis met tabellen, de hele wiki staat vol met tabellen en die werken prima. Het enige probleem dat er aangekaart is is dat er onderhuids problemen in de code zijn die aangepast dienen te worden, ook al zijn ze aan het oppervlak niet zichtbaar. Deze html-fouten komen niet alleen in de tabellen voor hitnotatie voor, maar in heel erg veel artikelen met vele andere tabellen. Al die tabelfouten zouden een keer opgelost moeten worden, en dat is prima mogelijk met een bot.

Voor de helderheid, het gaat om duizenden artikelen waar deze tabelfouten in te vinden zijn, alleen al voor de hitnotatie, en het gaat om nog eens duizenden artikelen waar andere tabellen in gebruik zijn met nog meer tabelfouten. De klus is zo groot dat het niet mogelijk is om dat echt allemaal met de hand te doen. Die fouten zijn niet op te lossen met een normaal sjabloon, waarbij ook nog eens in ogenschouw genomen moet worden dat het gebruiken van een sjabloon voor alleen maar meer fouten op artikelen kan zorgen. De Mediawiki-software is zo opgebouwd dat de tabellen die we gebruiken heel goed tegen een stootje kunnen en wanneer er problemen voordoen die niet of nauwelijks merkbaar zijn in de meeste gevallen bij het lezen van artikelen. Als er ook maar een spatie verkeerd staat, of iets anders futiels, gaat het op artikelen bij sjablonen meteen goed grondig mis. Door de jaren heen heb ik heel erg veel fouten uit de wiki gehaald, zowel in tabellen als sjablonen, waarbij duidelijk merkbaar is dat tabellen in Mediawiki heel erg veel kunnen hebben en ook heel erg eenvoudig te corrigeren zijn, terwijl het met sjablonen heel snel fout gaat en voor de meeste gebruikers het erg gauw te moeilijk wordt bij problemen. Echter is dat aanpassen van html-fouten wel prima te doen met een bot, omdat de gebruikte code universeel is en rechtstreeks een afgeleide is van html. Het omzetten van tabellen naar een sjabloon is voor mijn bot ook niet te doen. Het gaat hier in deze om duizenden artikelen die een aantal html-problemen hebben die opgelost dienen te worden en ik zie de bui dan al hangen, aangezien html-problemen relatief eenvoudig op te sporen zijn dan als je kijkt naar de fouten die massaal in sjablonen gemaakt worden, dan kunnen tabellen veel meer hebben en is het ook veel eenvoudiger op te lossen. Op vrijwel alle artikelen staat nu een tabel, als dat op al die artikelen een sjabloon moet worden, betekent dat gigantisch veel handwerk, dat bovendien nergens toe dient, omdat met eenvoudige tabellen, die op de hele wiki overal worden gebruikt (en bovendien beter tegen eventuele fouten kunnen), prima volstaan kan worden, die bovendien wél met mijn bot prima foutloos te maken zijn. Die tabelfouten zijn de kern van het probleem waarvoor een oplossing gewenst is en die oplossing kan relatief snel worden toegepast. Heel praktisch gezien is het corrigeren van die tabelfouten op al die duizenden artikelen wél eenvoudig te doen met een bot en daar kan ik morgen mee beginnen. Groetjes - Romaine (overleg) 26 nov 2010 14:17 (CET)

Beste Romaine, Bedankt voor je antwoord. Het lijkt me sowieso handig om een keer alle fouten uit alle tabellen te halen, zoals alle fouten eigenlijk uit alle pagina's gehaald zouden moeten worden. Nu kunnen dat allerlei fouten zijn, van allerlei soort, dus is het verstandig om met technisch oplosbare fouten te beginnen. Dat is werk dat mogelijk door een bot gedaan kan worden. Ik ben (nog) niet zo thuis in de mogelijkheden en onmogelijkheden van bots, maar begrijp dat die erg krachtig gemaakt kunnen worden (en dat ook mogen zijn). Of alles geautomatiseerd opgelost kan worden, zal de toekomst ons leren. Misschien is het een idee om te beginnen met een aantal artikelen en afhankelijk van de bevindingen of de bot aan te passen, of een grotere groep te pakken. In ieder geval goed om te horen dat jouw bot morgen al aan het werk zou kunnen.

Ik realiseer me heel goed dat code heel gevoelig is, en dat dat bij sjablonen op Wikipedia eens zo erg is doordat sjablonen amper of niet getest kunnen worden voordat een gebruiker er iets van merkt. In dat opzicht is het gelukkig dat ik mijn sjabloon geheel naast de bestaande gebouwd heb, en (nog) niets overschreven heb. Ook heb ik zelf een testpagina gerealiseerd in mijn gebruikersomgeving, en die werkt naar tevredenheid.

Ik ben bereid om, zoals door Goudsbloem gevraagd, tijd te steken in het onderzoeken van een integratiemogelijkheid van 'mijn' systeem van weeknummering in het sjabloon van ErikBaas, om zo in ieder geval dat bezwaar te ondervangen. Zou jij het gebruik van een dergelijk sjabloon wel steunen?

Een heel ander idee is misschien het handhaven van mijn sjabloon in een aparte omgeving (Gebruikersruimte?), en de uitvoer aan te passen zodat daar een goed werkende tabel uit komt. Op die manier kan een stuk invoer dan eenmalig omgezet worden naar een goedwerkende tabel. Maar dat is eigenlijk vooral interessant voor hits uit het verleden, die nu niet meer genoteerd staan. - Vriendelijke groetjes, RonnieV 26 nov 2010 18:01 (CET)

Ik heb er een hard hoofd in. De sjabloon laat op zich wachten, en de (al twee maanden geleden) aangekondigde bot-actie blijft ook nog steeds uit. Dat laatste zal ook niet simpel zijn, als het al mogelijk is (en daar begin ik steeds meer aan te twijfelen, het soort fouten in de tabellen is erg vreemd en onvoorspelbaar). Verder zul je elke week alle bijdragen van mager moeten nalopen op nieuw geïntroduceerde fouten, zoals hier en hier. - Erik Baas 28 nov 2010 21:38 (CET)

Hallo Erik, Bedankt voor je reactie.

Ik ben even druk bezig geweest met wat andere dingen, buiten Wikipedia is er nog een leven voor me, maar heb zojuist het volgende sjabloon aangemaakt: Gebruiker:RonnieV/Hitnotatie2. Willen jullie allen eens kijken of dat voldoende balans biedt tussen enerzijds gebruikersgemak, anderzijds technische eenvoud? Vriendelijke groeten, RonnieV 28 nov 2010 23:33 (CET)

• Overigens vind ik het niet netjes dat je hier op de man speelt. Er zijn meer gebruikers van Wikipedia die moeite hebben met het verzorgen van de lay-out van tabellen (of van pagina's in het algemeen). In feite zou een dergelijke bot iedere pagina waarin tabellen gebruikt worden moeten controleren na iedere wijziging. Verstandig is het om pakweg een uur te wachten, zodat de gebruiker zelf ook nog even de tijd heeft om eigen invoerfouten te herstellen, omdat hij deze direct ziet of nog aan het stoeien is, en om zo allerlei bwc's te voorkomen. RonnieV 1 dec 2010 12:21 (CET)

Qua uitvoering vind ik het goed, de fout met de tussentijdse 'uit' is weg. Over de technische kant kan ik niets zeggen, ik denk dat of Erik Baas of Romaine of een andere sjablonenkenner daar beter een mening over kan geven... Goudsbloem 29 nov 2010 00:08 (CET)

Hallo allemaal. Volgens mij zijn de sjablonen {{Tabel hitnotatie 10}}, {{Tabel hitnotatie 11}}, {{Tabel hitnotatie 12}} ect. met aanpassingen van de tussentijdse 'uit' nog niet zo gek. Om alle hitnotaties mogelijk te maken heb je dan ongeveer 10 sjabloons nodig. Als de tabel vol is geeft hij automatische aan dat je een andere (en ook welke andere) sjabloon je moet gebruiken. Je hoeft dan alleen het getal in de link te veranderen. Geen overbodige lege cellen en geen HTML fouten. Met vriendelijke groeten Mager112001 29 nov 2010 23:15 (CET)

Hier, hier, hier en hier zie je enkele voorbeelden waar de sjablonen reeds gebruikt worden. Mager112001 29 nov 2010 23:25 (CET)

Beste Mager, De door jou voorgestelde sjablonen zouden in mijn ogen ook gebruikt kunnen worden, maar ik zie twee bezwaren: (1) de breedte van de tabellen varieert. Dit is wellicht op te lossen door te stoeien met de breedte van kolommen en zo, om tot een vaste tabelbreedte te komen. Dat is zeker zo prettig als er meerdere tabellen onder elkaar verschijnen. (2) Er is sprake van een groter aantal sjablonen. Tot welke diepte ga je de verschillende vormen uitwerken (2, 3, 4, 5 regels)? En is het intuïtief voor een gebruiker om hiertussen te switchen met de tabelnaam? Of kiezen we dan voor één universeel sjabloon, waarbij je de breedte als parameter doorgeeft, waarbij het sjabloon op basis van de breedte één van de mogelijke beschikbare breedtes aanroept?

Mij maakt het persoonlijk niet zo heel veel uit wat er precies gebruikt gaat worden, als we maar een beslissing nemen en iets in gang gaan zetten, waar iedereen mee uit de voeten kan. Dit probleem mag in mijn ogen niet onopgelost blijven liggen, met de volgende ruzie weer op de loer... Vriendelijke groeten, RonnieV 30 nov 2010 11:24 (CET)

In juli 2010 werd er door een gebruiker een probleem geconstateerd in de html van verschillende tabellen. Door miscommunicatie lukte het niet om daar samen uit te komen, ook al was de oplossing zeer simpel: het corrigeren van de html-fouten. Door miscommunicatie, geharrewar en alle gedoe die hierop is gevolgd is er blijkbaar een hele discussie ontsponnen, maar de kern van het probleem wordt nog steeds gemist. Zoals ik hierboven al vaker heb aangegeven is een sjabloon geen realistische oplossing voor het probleem en creëert alleen maar meer mogelijke problemen en staat lijnrecht tegenover basisprincipes die we in sjablonen gebruiken. De kern van het probleem is dat er een paar gebruikers zijn die blijkbaar niet in staat zijn om door normale communicatie te gebruiken en elkaar te respecteren er samen uit te komen. De enige en bovendien simpele oplossing is gewoon die html-fouten er uit te halen en daar wordt aan gewerkt. Groetjes - Romaine (overleg) 1 dec 2010 01:21 (CET)

Gezien de vele fouten die er kennelijk toch insluipen bij het gebruik van tabellen, vraag ik me af of tabellen wel de ideale oplossing zijn. Misschien moeten we constateren dat er geen ideale oplossing mogelijk is, en moeten we kijken wat het best haalbare is. Vanuit de gebruikers lijkt er in ieder geval bij een groep een voorkeur te zijn voor een sjabloon (even in het midden latend welk), vanuit de beheerders wil men liever een tabel. Een sjabloon lijkt minder kansen te bieden op invoerfouten, een tabel levert minder risico op bij wijzigingen in de onderliggende software.

Het oplossen van de tabelfouten met een bot is al een tijd onderwerp van gesprek, maar het lijkt erop dat dit nogal wat voeten in aarde heeft. Gezien het grote aantal wijzigingen in tabellen voor hitnotaties en een aantal specifieke wensen met betrekking tot tabellen voor deze noteringen lijkt dit ook een wekelijks terugkerend 'risico' te zijn. Over de rest van de tabellen op Wikipedia heb ik het dan nog niet. De meeste daarvan zijn gelukkig aan minder wijzingen onderhevig. Vriendelijke groetjes, RonnieV 1 dec 2010 12:21 (CET)

Romaine geeft zelf al aan dat tabellen gevoelig zijn voor fouten, en dat in de praktijk gebleken is dat veel mensen er moeite mee hebben. Dat was precies mijn gedachtegang toen ik de sjabloon maakte, en IMO is een sjabloon nog steeds de beste oplossing. Tenzij één gebruiker blijft volharden in een oneigenlijk gebruik daarvan, namelijk door meer dan een periode van noteringen in een tabel te willen proppen - dat is m.i. het enige wat er aan {Tabel hitnotatie} schort, en ik heb al in een vroeg stadium aangegeven dat dat toch al een onjuiste weergave van de gegevens is.

De bot blijkt inmiddels al nuttige bewerkingen te doen, fijn dat er nu eindelijk gewerkt wordt aan het opruimen van de rommel. Ik wil er wel nogmaals op wijzen dat de bot wekelijks alle bewerkingen op artikelen met zulke tabellen zal moeten herhalen, m.n. met zaken als "colspan" en het afsluiten van tabellen worden veel fouten gemaakt. En omdat bestaande pagina's vaak als voorbeeld gebruikt worden, en nieuwe artikelen vaak door copy/paste vanuit bestaande pagina's tot stand komen, zullen fouten zich als een olievlek blijven verspreiden. - Erik Baas 2 dec 2010 00:18 (CET)

Beste RonnieV. Voor mij hoefde een sjabloon in eerste instantie ook niet. De Wikitabel werkte prima, zeker bij het tijdelijk verdwijnen van een album/single uit een lijst. Ook is het aanpassen van de tabel op het juist aantal weken gemakkelijker. Bij het sjabloon komen bij sommige hitnotaties gewoon veel teveel lege cellen voor als een album/single kort in de lijst heeft gestaan. De lezer kan denken, de tabel is nog niet af, in die lege cellen moeten nog getallen komen te staan. Toen Erik Baas de eerste maal de HTML-fouten uit een van die tabellen haalde was ik me van geen kwaad bewust en paste de gegevens naar mijn mening weer aan zoals ze ook in alle andere hitnotatietabellen staan. Als Erik Baas me direct had verteld wat er precies fout aan de tabel was, had ik de tabel zeker niet gewijzigd. Hij beschuldigde me (op zijn bekende manier) van knoeiwerk en vroeg meteen een regblok aan. Als hij gewoon op mijn OP had verteld wat er aan de hand was en wat er veranderd moest worden had ik met alle plezier alle hitnotaties vervangen met de juiste codes. Hierna ging Erik Baas een sjabloon ontwerpen. Ik vertelde hem dat ik het een tijd geleden ook al eens geprobeerd had maar dat het een hele opgave was omdat geen enkele hitnotatie hetzelfde is. Hij schreef: "ik verander er niets aan, de bedoeling is juist het uiterlijk ongewijzigd te laten". Toch werd het uiterlijk anders en klopte sommige noteringen gewoon niet. Hij bleef het sjabloon overal toepassen terwijl ik het idee had dat hij niet eens wist wat een hitnotatie inhield. Toen hij me ook nog ging beschuldigen dat ik extra HTML-fouten in Wikipedia ging brengen bij ook al de tabellen voor de hitlijsten van albums en singles besloot ik er mee testoppen. Bij elke aanpassing van mij had hij wel een opmerking. Toen ik na 2 maanden weer terug keerde en verschillende sjabloons introduceerde begon het weer. Na een stemming over het wel of niet gebruiken van het sjabloon met de lege cellen, koos de meerderheid voor een tabel zonder lege cellen. Het sjabloon werd niet meer toegepast en de normale Wikitabel werd weer gebruikt. Hierna begon Erik Baas over de nullen voor de 1 t/m 9. Deze stonden in de tijd dat hij voor de eerste keer de HTML-fouten uit de tabel haalde ook al in de tabel. Waarom haalde hij ze er toen al niet uit? Deze nullen stonden er om alle cellen even breed temaken. Daarom was het vreemd dat Erik Baas deze uit de tabellen wilde hebben zodat de tabellen niet meer even breed werden wat in zijn sjabloon wel het geval was en zijn voorkeur had. Een hitnotatie is nu eenmaal verschillend. Als in de ene lijst een single 4 weken is genoteerd en in een andere lijst 28 weken is het nu eenmaal moeilijk 2 tabellen tekrijgen van gelijke breedte. Toen jij met een nieuwe tabel kwam was ik razend enthousiast. Alles wat in de tabel hoorde zat er in. Juist aantal weken, begin datum, eind datum, "uit", hitlijst naam ect. Te mooi om waar tezijn....en dat was het ook. Jammer, erg jammer. We zijn vandaag dus eigenlijk weer op het punt van waar alles begon. De HTML-fouten zijn (worden) eruit gehaald en de hitnotaties worden weer op de oude manier toegevoegd. Hopelijk kan ik (en vele andere hitlijst medewerkers) vanaf nu weer rustig de hitnotaties bijhouden. Met vriendelijke groeten Mager112001 1 dec 2010 21:26 (CET)

Hoi Mager!

Goed dit te lezen, en ik heb goed nieuws voor je! Op dit moment kunnen jij en alle anderen gewoon rustig de hitnotaties bijhouden. Het technische gebeuren met tabellen wordt botmatig geregeld, dus dat hoef je niet meer handmatig te doen. Ik hoop dat het probleem nu opgelost is. Je bent uiteraard welkom om feedback en feature requests te geven. Met vriendelijke groet, Kwiki overleg 2 dec 2010 03:22 (CET)

Hoi Mager!

Ik hoop ook dat iedereen nu weer gewoon aan de slag gaat met wat we eigenlijk willen doen: zo veel mogelijk en zo goed mogelijk informatie verzamelen en geven. De hele discussie over de vormgeving heeft er veel tijd en energie gekost van heel veel mensen. Ik zou me sterk vergissen als het niet zo zou zijn dat velen die tijd en energie liever en beter anders kunnen besteden... Over het laatste probleempje (breedte van de cellen) gaan we nog even denken, daar vinden we vast ook wel iets op. Bedankt voor al je inbreng, en je complimenten over mijn sjabloon. Vriendelijke groet, RonnieV 2 dec 2010 23:14 (CET)

Een bewerkingscommentaar als "HTML- en CSS-fouten gefixt" is voor iedereen (behalve jou dus) volkomen duidelijk, maar jij koos ervoor dat gewoon te negeren, ze botweg weer terug te zetten, en - godbetert! - als vandalisme te betitelen. Wat je zegt over de voorloopnullen is niet waar (in mijn sjabloon was dat ook al opgelost), dat ik niet zou weten wat een hitnotatie is slaat helemaal bergens op, gelijke breedte voor alle tabellen is m.i. gewoon netter. Verder ga ik maar niet in op je zoveelste klaagzang, je blijft toch de vermoorde onschuld uithangen... Alleen nog dit: zolang je geen nieuwe fouten introduceert kun je je gang gaan, wat dat betreft is er niets nieuws onder de zon. - Erik Baas 2 dec 2010 00:09 (CET)

Hoi Erik!

Je schreef: "botweg weer terug te zetten", en dat is ook wat er nu gebeurt, maar ditmaal worden de HTML/CSS fouten allemaal netjes verbeterd naar w3 valide HTML & CSS! Ik hoop dat het probleem nu opgelost is. Je hoeft de HTML/CSS fouten niet meer te fixen want dat doet de bot automagisch. Je bent uiteraard welkom om feedback en feature requests te geven. Met vriendelijke groet, Kwiki overleg 2 dec 2010 03:22 (CET)

Ik ben blij dat er nu schot in de zaak zit, nog een klein beetje "fine-tuning" voor de bot, en dan komt het allemaal goed. Als mager dat nou maar niet gaat opvatten als een vrijbrief om fouten te blijven produceren... - Erik Baas 2 dec 2010 13:39 (CET)

Hoi Ronnie! Ik hoop van harte dat alle partijen zich in dit systeem kunnen vinden. Hopelijk zijn aan de bezwaren van alle kanten tegemoetgekomen, terwijl toch niemand precies heeft wat ie voor ogen had. Je bent zeer welkom om feedback en feature requests te geven. Met vriendelijke groet, Kwiki overleg 2 dec 2010 03:41 (CET)

Hoi Kwiki, Het heeft even geduurd, maar dan krijg je ook wel wat! Ik kan me prima vinden in deze oplossing, en vertrouw erop dat we nu iets hebben waar we nog lang van kunnen genieten. Volgens mij zit dat wel goed... Vriendelijke groeten, RonnieV 2 dec 2010 23:14 (CET)

Dat zie je verkeerd: als de fouten opgelost worden ben ik zonder meer tevreden. Dat het op een omslachtige en zeer arbeidsintensieve manier gaat is jammer, maar niet mijn probleem. Het kan een probleem worden als de bot - om welke reden dan ook - zou ophouden, vooral als dat gebeurt op een tijdstip in de toekomst wanneer niemand meer precies weet waar het om draaide. Enfin, dat zien we dan wel weer. - Erik Baas 2 dec 2010 13:41 (CET)