Wikipedia:De kroeg/Archief/20150430

Verschillende versies van een artikel

Hey allemaal,

Het systeem van Wikipedia gaat zo in z'n werk dat werkelijk élke versie van élke pagina tot in de eeuwigheid bewaard wordt (ik hoop dat ik dat goed zeg). Op termijn moet dat een gigantische serverruimte in beslag nemen, dacht ik dan, en die ruimte kan onmogelijk kleiner worden. Ik vroeg mij af of dat niet eenvoudiger kan, zonder daarbij ook maar één iets aan informatie te verliezen. Zo bijvoorbeeld Sjabloon:Eenedit: wanneer dit van toepassing is, is het dan niet mogelijk om al die bewerkingen van die gebruiker samen te voegen tot één paginaversie? Anderzijds, een vandalistische bewerking die door de gebruiker zelf wordt teruggedraaid, is het nodig dat dat bewaard blijft en kan dat niet gewoon uit de geschiedenis gehaald worden? En dan bedoel ik niet een onzichtbare paginaversie, maar gewoon weg. Kortom, alleen de versies van het artikel bewaren die effectief iets veranderen aan de inhoud en informatie in het artikel, of toch meer in die richting. (ik bedoel dan uiteraard wel met de goedkeuring van de gebruiker die de bewerking heeft uitgevoerd). Ik weet dat dit tegen de structuur en werkwijze van wikipedia is, maar ik vroeg me af wat anderen hun meningen hierover zijn.

Groeten, Rickie97 (overleg) 21 apr 2015 21:51 (CEST)

Belangrijke vraag: Is jouw wens wel mogelijk conform de huidige licentie? Anders komt er niet alleen een stuk programmeerwerk bij kijken, maar ook een andere licentie. En dan is het maar de vraag of er een vrije licentie bestaat waarbinnen dit mogelijk is. Als die niet bestaat is jouw wens zelfs onmogelijk tot er ooit een licentie komt die het wel toestaat. En opslagmedia worden tegenwoordig fysiek steeds kleiner met steeds meer capaciteit, dus komt er wel een tekort aan serverruimte? Mbch331 (Overleg) 21 apr 2015 22:01 (CEST)

Serverruimte is vaak relatief goedkoop, vooral wanneer die versies toch nooit worden opgevraagd. Bandbreedte en rekentijd zijn duur. Het automatisch verwijderen van een exact teruggedraaide bewerking is geen optie: veel terugdraaiingen worden door 'gewone' bewerkers uitgevoerd en moeten vindbaar blijven (bijvoorbeeld als de pleuris uitbreekt over zo'n revert). Maar overleg en goedkeuring, en iedere handmatige wijziging of samenvoeging, kosten tijd en 'energie'. Netto wordt er dan eigenlijk niets bespaard door het samenvoegen of verwijderen van tussentijdse versies, en zeker niet op de 'hulpbron' die het meest schaars is: de tijd van vrijwilligers. Paul B (overleg) 21 apr 2015 22:02 (CEST)

Ik heb de technische staf ergens een geruststellende tekst zien gebruiken in de trant van "het is onmogelijk dat jullie iets doen wat de serverruimte in gevaar brengt". Toch is aanspreken van een collega met ((eenedit)) of, in het geval van een ervaren collega, in je eigen woorden, altijd een goede optie. We vergeten het namelijk allemaal wel eens denk ik. Sander1453 (overleg) 21 apr 2015 22:07 (CEST)

(na bwc) Met 'kleiner' bedoelde ik de hoeveelheid opgeslagen informatie, die dus steeds blijft groeien. Maar dat terzijde. Wat ik eigenlijk wou zeggen: als ik nu pakweg vijf maal na elkaar in een artikel een spelfout aanpas, telkens in een andere zin, is dat dan werkelijk nodig dat per edit een aparte paginaversie wordt opgeslagen? Als ik nu zelf zou kunnen aanklikken: "voeg bewerkingen samen", wordt dat dus gewoon één nieuwe paginaversie. En als ik dat dan zelf kan doen, komen er ook geen derden aan te pas, dus de tijd van vrijwilligers is dan ook geen probleem, en extra energie ook niet bepaald.
Nog even voor de duidelijkheid, mijn doel is hierover een constructieve discussie te hebben, niet noodzakelijk dit in te voeren. Ik vroeg me af of ik de enige was die daar weleens over nadacht als ik mijn eigen naam meermaals na elkaar in de bewerkingsgeschiedenis van een artikel zie staan ;-) Dus ook met het oog op een ietwat overzichtelijke bewerkingsgeschiedenis, of dat was toch mijn oergedachte hieromtrent. Niet zozeer de serverruimte, al heeft het er uiteindelijk ook wel mee te maken natuurlijk, maar da's niet zo'n probleem.
Groeten, Rickie97 (overleg) 21 apr 2015 22:16 (CEST)

Ik ken het gevoel ook. Alleen is het nooit in me opgekomen om dit hier aan te kaarten. Wmb ook overduidelijk vandalisme weghalen uit de geschiedenis. Wikiwerner (overleg) 21 apr 2015 22:22 (CEST)

Dat vandalisme weghalen was zo een zijsprong die in me opkwam tijdens het typen, oorspronkelijk was dat niet het idee dat ik hier wou beschrijven :-P Let wel dat ik het hier heb over 'vandalisme' dat door de vandaal zélf terug is weggehaald, dan is het toch helemaal niet nodig dat het zichtbaar blijft dat die persoon eens heeft 'getest' hoe wikipedia werkt dacht ik. Rickie97 (overleg) 21 apr 2015 22:25 (CEST)

Volgens mij is automatisch verbergen of samenvoegen van dergelijke versies erg lastig. Probeer maar eens criteria te verzinnen om bepaalde bewerkingen wel of niet te 'behouden' in de bewerkingsgeschiedenis, en dan wel criteria die altijd opgaan en die niet om de zoveel tijd een onwenselijke actie opleveren. Het alternatief, handmatig verbergen na verzoek en/of overleg heeft dat nadeel niet, maar dat is ook het paard achter de wagen spannen: het kost tijd en moeite die beter aan inhoudelijke dingen kan worden besteed. Wat {{eenedit}} betreft: het helpt iedereen als gebruikers niet twintig minibewerkingen na elkaar doen, maar als er zojuist twintig minibewerkingen zijn gedaan, is het 'kwaad' al geschied en is het meestal verspilling van tijd om dan handmatig die spullen nog eens te gaan samenvoegen of verbergen (laat staan om daarvoor de functionaliteit nu nog eens te gaan implementeren). Paul B (overleg) 21 apr 2015 23:15 (CEST)

Er is niet zoveel opslagruimte nodig als je misschien denkt. Als je de dt-fout corrigeert in een bestaande tekst, dan hoeft de computer alleen te onthouden:

• artikelnummer (welke tekst)
• datum (wanneer)
• usernummer (wie)
• postitie van de wijziging (waar in de tekst)
• aantal gewijzigde tekens (wat-oud)
• wijziging (wat-nieuw)

Dat past allemaal in ongeveer 1 regel tekst. Als het gewijzigde artikel opgevraagd wordt, kan de computer dat genereren uit de laatste complete tekst en de wijzigingen sindsdien. Of omgekeerd, de computer bewaard de nieuwste versie en kan oudere versies "terugrekenen". Met comprimeringstechnieken kan de benodigde ruimte nog verder verkleind worden. Het principe wordt gebruikt in veel software. Zwitser123 (overleg) 22 apr 2015 08:02 (CEST)

Precies. Het uploaden van een hoge resolutie foto (graag blijven doen) kost minstens zo veel serverruimte als duizenden kleine edits. Om over een filmpje nog maar te zwijgen. Het nut van {tl|eenedit}} is dat veel kleine edits de geschiedenis van een pagina voor (menselijke) gebruikers onoverzichtelijk maakt. De server heeft er echt geen problemen mee. CaAl (overleg) 22 apr 2015 08:59 (CEST)

@Zwitser123. Wikipedia slaat wel degelijk elke versie van elke pagina volledig op in de database (gecomprimeerd, dat wel). Zie hier. Waarschijnlijk zou het reconstrueren van de huidige versie uit de eerste versie en alle veranderingen gewoon te veel tijd kosten, en is opslagruimte goedkoper dan rekenkracht. Zo heel groot is het nou ook weer niet, een paar Terabyte voor alle artikelen van de Engelse WP, inclusief de geschiedenis. Voor een normale moderne database geen heel groot probleem. Hoopje (overleg) 22 apr 2015 23:09 (CEST)

Vergeet wat ik zei over opslagruimte. Louter voor de overzichtelijkheid van de paginageschiedenis dan... :P Rickie97 (overleg) 22 apr 2015 11:37 (CEST)

Dan blijft nog steeds de vraag of het wel mag volgens de licentie. Mbch331 (Overleg) 22 apr 2015 12:11 (CEST)

In veel gevallen wel, lijkt me. Het samenvoegen van opeenvolgende bewerkingen van één auteur lijkt me licentietechnisch geen probleem: het resultaat van die bewerkingen wordt immers keurig toegeschreven aan die auteur. Het verwijderen van teruggedraaide onzin uit de geschiedenis is ook al geen probleem: de onzin is immers helemaal niet meer publiek in te zien, dus er is niets in enige versie van het artikel dat aan de vandaal hoeft te worden toegeschreven. Paul B (overleg) 22 apr 2015 12:18 (CEST)

Op dit moment is de ruimte voor de Samenvatting beperkt. Als iemand vijf wijzigingen doet met een wat langere tekst in de samenvatting (bijvoorbeeld de bronvermelding) dan kan die in de huidige database-configuratie niet bewaard blijven bij het samenvoegen van die vijf wijzigingen. Ook zou de software dan de samenvoeging goed moeten doen: wat als je een 'linkfix' doet, een 'typo' hersteld, een 'linkfix' doorvoert, een 'grammaticale fout' hersteld en nog een 'typo' hersteld, dan wordt de ideale samenvatting 'linkfixes, typo's, grammaticale fout'. Of de rekenkracht om dat te genereren en de vier tussenliggende wijzigingen samen te voegen of te verwijderen opweegt tegen de voordelen in de opslagruimte, ik weet het niet.

Als je zelfhersteld vandalisme volledig verwijdert, is later ook niet meer te zien dat die gebruiker vandalisme hersteld heeft. Sommigen vinden het belangrijk om te weten dat een bepaalde gebruiker tien keer verstandig is geweest en zijn eigen bijdrage ongedaan heeft gemaakt. Onderscheid tussen vandalisme en gewone fout zal de software maar gedeeltelijk kunnen maken.

Ik ben het wel met Rickie97 eens dat het soms erg onprettig is hoe sommige (ook ervaren!) gebruikers een reeks edits nodig lijken te hebben om een simpele wijziging door te voeren (en ja, ik druk ook wel eens te vroeg op de knop Pagina opslaan ;-) ), waar Toon bewerking ter controle toch echt wat versies zou kunnen besparen. Maar ja, bij een ervaren gebruiker mag je dat {{eenedit}}-sjabloon niet plaatsen... Met vriendelijke groet, RonnieV (overleg) 22 apr 2015 18:47 (CEST)

In principe komt het er bij 'samenvoegen' van pakweg vijf bewerkingen na elkaar door dezelfde gebruiker gewoon op neer de eerste vier te verwijderen uit de geschiedenis, als je dan de oorspronkelijke versie vergelijkt met de pagina na de vijfde bewerking, staan alle wijzigingen erin. Maar nogmaals, mijn bedoeling is dat de gebruiker die de bewerkingen doet dit zelf kan kiezen Eventueel zoiets: je bewerkt een artikel waarvan de laatste versie reeds van jou was, en dat was minder dan X uur geleden, komt er na "dit is een kleine wijziging" en "deze pagina volgen" een derde aanvinkvakje "samenvoegen met vorige bewerking onder één paginaversie" of iets dergelijks. Dat kost dus geen extra tijd, en als de gebruiker het niet wil, vinkt hij het ook niet aan. De beperkte samenvatting kan dan nog wel een probleem vormen, maar dat is in mijn ogen dan ook het enige struikelblok, niet? Of zie ik nog iets over het hoofd? :) Dat zou dus een manier kunnen zijn om in de toekomst zo'n waslijsten te vermijden in de paginageschiedenissen. Groeten, Rickie97 (overleg) 22 apr 2015 19:31 (CEST)

Ja, we zien nog iets over het hoofd: in de tussentijd kan er iemand een link naar de tussenliggende versie ergens geplaatst hebben (of daarmee bezig zijn). Als ik zeg dat jij in versie 3 (van de 5) een dt-fout hebt gemaakt en link naar die specifieke versie, dan bestaat die opeens niet meer. Best kans dat jij die al zelf hersteld hebt, bijvoorbeeld in versie 4, terwijl ik mijn berichtje aan het tikken was...
Wat misschien wel een goede zou zijn, is als je de mogelijkheid krijgt om bij het bekijken van de paginageschiedenis aan te geven dat je achtereenvolgende wijzigingen door één gebruiker in 1 bewerking wil zien. Dat maakt de lijst wat korter. Maar of dat opweegt tegen alles wat wij hier met elkaar aan data creëren....
De complete geschiedenis van nl-wiki past nu nog in 22.2 GB (All pages with complete page edit history (.bz2)). Ik weet eigenlijk wel zeker dat die van Common daar niet in past (en die van en-wiki ook niet). Met vriendelijke groet, RonnieV (overleg) 22 apr 2015 19:51 (CEST)

Het linken naar een bewerking kan in dat geval inderdaad een probleem zijn. Spijtig, da's een fout in mijn plan :P Rickie97 (overleg) 23 apr 2015 17:19 (CEST)

OMT LIVE

Jan-Bart de Vreede, voorzitter van de Board of Trustees van de WMF, is vanavond te gast bij OMT LIVE. Meer informatie hier. Sjoerd de Bruin (overleg) 22 apr 2015 17:12 (CEST)

Leuk. Dank voor het bericht. Mvg, Taketa (overleg) 22 apr 2015 18:51 (CEST)

Linkje is dood, nu te zien op Youtube. Multichill (overleg) 23 apr 2015 15:42 (CEST)