Wikipedia:De kroeg/Archief 20090309

Ik heb de categorie MediaWiki aangemaakt met het idee om alle 500 mediawiki: paginas hierin te zetten. Dit om een beter overzicht te creeren. Ik weet dat het nogal nutteloos is, maar ik vind het op sommige momenten (als ik naar mediawikis zoek) storend dat deze categorie er niet is. Bij deze zou ik graag om input willen vragen, voordat ik een botverzoek plaats. Ik heb <noinclude>[[Categorie:MediaWiki]]</noinclude> voor het moment in 2 mediawiki paginas gezet als voorbeeld. Als dit idee al eens besproken is in het verleden of als ik iets over het hoofd zie, laat het me weten. Misschien zien andere mensen liever een andere invulling van deze categorie. Met vriendelijke groet, Taketa (overleg) 27 feb 2009 15:05 (CET)[reageer]

Mij lijkt het wel een goed idee, al zal het pas na een zinnige onderverdeling in subcategorieën iets bruikbaars opleveren - Quistnix 27 feb 2009 15:10 (CET)[reageer]
Ik ben bang dat er onverwachte effecten gaan optreden, bijvoorbeeld op MediaWiki:Sidebar. Ik stel voor dat dit eerst uitgetest wordt op een testwiki, alvorens hier een botverzoek te doen voor alle mediawiki pagina's. HenkvD 27 feb 2009 19:37 (CET)[reageer]
Ik zie ook niet direct een noodzaak om eerlijk te zijn. Volgens mij volstaat Speciaal:Alleberichten om alle Mediawiki-teksten op één overzicht te krijgen. Daarnaast hebben we ook nog speciaal:voorvoegselindex met een bondig overzicht van alle mediawiki pagina's.
Om nou alle pagina's in een bepaalde naamruimte in een gelijknamige categorie te zetten is werk dubbel doen, want uiteindelijk krijg je er geen extra overzicht door. nl:Mark W (Mwpnl) ¦ talk 27 feb 2009 19:43 (CET)[reageer]
@Quistnix, subcategorien zouden inderdaad een optie zijn. Het probleem is dan natuurlijk, hoe wil je het indelen.
@Henkvd, met noinclude verwacht ik geen onverwachte effect , maar testen kan geen kwaad.
@Mark, die eerste pagina is te groot voor mijn pc, maar die tweede is inderdaad nuttig. Dan blijft enkel het gemak over dat je bij categorien direct van een mediawiki pagina naar het overzicht kunt doorklikken. Verder zou je kunnen denken aan subcategorien, hoewel dat wat meer planning vergt. Taketa (overleg) 28 feb 2009 10:47 (CET)[reageer]
We hebben het nu ineens over het aanmaken van een categorie-boom speciaal voor de MediaWiki-naamruimte, dat komt mij vreemd over, want: Wat is het probleem? Taketa deponeerde het probleem dat hij het overzicht mist als hij zoekt naar MediaWiki-berichten. Dat overzicht is er echter wél (Speciaal:Alleberichten en speciaal:voorvoegselindex). Daarmee is volgens mij het probleem opgelost en is de categorie dus volkomen overbodig. Sterker nog, zo'n categorie heeft een ongewenst bijeffect: Alleen vertaalde MediaWiki-berichten staan er in. Berichten die via translatewiki binnenkomen zouden niet eens in een categorieoverzicht staan (want: ze hebben geen pagina), terwijl ze wel op Speciaal:Alleberichten staan. Een ander voordeel van Speciaal:Alleberichten is overigens dat de inhoud van de berichten er ook staat, waardoor het zoeken een stuk makkelijker wordt.
Kortom: Alsjeblieft geen overbodige categorie-indeling als dat een probleem oplost wat er helemaal niet is. nl:Mark W (Mwpnl) ¦ talk 28 feb 2009 18:03 (CET)[reageer]
Absoluut overbodige categorie en zeker niet een wenselijke categorie. Zie ook de uitleg van MarkW. Als je niet weet welke MediaWiki-pagina je wilt aanpassen (of niet vinden kunt): doe het dan niet. Daarnaast is terughoudendheid in het aanpassen van deze pagina's noodzakelijk vanwege hun functie. Daarnaast zou het toevoegen van categorieën aan MediaWiki-pagina's tot ongewenste effecten kunnen leiden, zelfs met noinclude, omdat die pagina's op andere wijze in het systeem geïmplementeerd worden dan simpele sjablonen. Groetjes - Romaine (overleg) 3 mrt 2009 23:56 (CET)[reageer]

Welkomst bot bewerken

Naar het zich laat aanzien heeft Gebruiker:Wikiliam vandaag een bot in gebruik genomen welke iedere anonieme gebruiker na zijn/haar eerste bewerking op de overlegpagina welkom heet middels het plaatsen van het Sjabloon:welkomstbericht (zie Speciaal:Bijdragen/Wikiliam). Op zich is daar niks mis mee, ware het niet dat er niet wordt gekeken of het een zinnige dan wel vandalistische bijdrage betreft. Ik heb dit aangekaart op de overlegpagina van Wikiliam, maar nog geen reactie mogen ontvangen. Is er een mogelijkheid deze bot te stoppen tot er duidelijkheid is of deze actie op deze manier al dan niet gewenst is ? --RenéV 2 mrt 2009 19:58 (CET)[reageer]

Een bot zonder bitje mag toch ook niet meer dan 1 bewerking per minuut doen? Deze bot houdt zich hier niet altijd aan. brimz 2 mrt 2009 20:21 (CET)[reageer]
Mag er dan geen {{welkom}} staan bij een {{ws}} of {{zb}}? Fenke 2 mrt 2009 21:07 (CET)[reageer]
Er is zo te zien reeds geantwoord door Wikiliam op diens OP. Verder heeft Brimz gelijk, zonder botbit is er een limiet van 1 botbewerking per minuut. Taketa (overleg) 2 mrt 2009 21:14 (CET)[reageer]
De bot, als het al een bot was, is gestopt en de gebruiker heeft gereageerd op zijn overlegpagina. --RenéV 2 mrt 2009 21:23 (CET)[reageer]

Siebrand had toch al zo'n bot lopen? Wammes Waggel 2 mrt 2009 21:56 (CET)[reageer]

Die (en anderen) is/was/zijn/waren voor "geregistreerde gebruikers". Niels? 2 mrt 2009 23:37 (CET)[reageer]
Deze bot gaat volledig in tegen de gedachte achter de gebruikerspagina. Als we een welkomstbericht willen bieden na de eerste edit kan dit automatisch gebeuren, bij de edit. De Gebruikerspagina is bedoeld voor intermenselijke communicatie. Een plek waar je iemand kunt begroeten, met of zonder sjabloon, en waar je iemand kunt aanspreken. Deze bot, evenals de bot die gebruikers begroet gaat volstrekt in tegen dit idee van een gebruikerspagina. Mig de Jong 3 mrt 2009 13:26 (CET)[reageer]
Inderdaad. Nu krijgen de zelfpromotor en de ingelogde vandaal een automatisch welkom in plaats van een persoonlijke tekst waarin hen wordt gewezen op het doel van wikipedia. Niet echt iets dat ik prettig vind. Sommige dingen moeten in handen blijven van menselijke gebruikers - Quistnix 3 mrt 2009 13:59 (CET)[reageer]
Zeer irritant zulke bots (die van Siebrand inderdaad ook en er is ook iemand anders wel eens op die manier bezig geweest). Zo'n bot zou eigenlijk pas 1 uur na de eerste bijdrage moeten kijken of de overlegpagina nog leeg is. Dan heeft iemand tenminste de tijd kunnen hebben om een welkom neer te zetten. PatrickVanM / overleg 3 mrt 2009 14:30 (CET)[reageer]
De afspraak met Siebrands bot was dat deze tot 10 minuten na de eerste edit wachten zou, alvorens te verwelkomen. De reden dat ano's niet automatisch verwelkomd worden/werden, is de rode link naar de overlegpagina (wat als teken van newbie opgevat kan worden: een reden om de edits extra goed en extra snel te bekijken). Ciell 3 mrt 2009 22:37 (CET)[reageer]
Zo maakte ik inderdaad ook gebruik van deze rode links. Misschien dat ik er daardoor een beetje geïrriteerd door ben geraakt en het hier heb aangekaart. --RenéV 3 mrt 2009 23:17 (CET)[reageer]

Ook lastig (niet alleen voor beginnende gebruiker) bewerken

Ik kwam net het artikeltje Megawatt tegen, de inhoud daarvan bleek grotendeels uit een sjabloon te komen (dat dus zowel een openingszin als een tabel genereert), het ziet er op het scherm misschien mooi uit, maar hoe moet je dan die eerste zin ooit kunnen bewerken? Na enig zoeken kwam ik er wel achter hoe ik de foute links naar watt kon verbeteren (extra argument in het sjabloon), maar makkelijk te bewerken is dit zo niet. - T Houdijk 3 mrt 2009 12:32 (CET)[reageer]

Die eerste zin is te bewerken in {{SI-eenheid}}, maar dan wijzig je die zin ook in 22 gelijksoortige lemma's. --LexTH 3 mrt 2009 13:25 (CET)[reageer]
Copy-paste, of een sjabloon dat omgezet wordt in echte tekst lijkt me in dit geval beter. Het betreft maar 22 lemmata. Mig de Jong 3 mrt 2009 13:27 (CET)[reageer]
Dit lijkt me nu een typisch voorbeeld van hoe het niet moet. Ik heb de bewerking ongedaan gemaakt, maar blijkbaar zijn er dus meer artikelen die zo beginnen. Ik roep hierbij iedereen op, om zonder overleg dat sjabloon op deze manier niet weer terug te zetten, hier is niet echt consensus over bereikt lijkt mij. M.vr.gr. brimz 3 mrt 2009 13:32 (CET)[reageer]
Je hebt geen bewerking ongedaan gemaakt, je hebt de tabel eruit gesloopt. Het is in ieder geval een illustratie van de stelling dat alles wat niet platte tekst is in een sjabloon stoppen niet de oplossing is. Dan zou dit dus de normale gang van zaken worden, en wordt het ene probleem ingeruild voor het andere. --LexTH 3 mrt 2009 13:34 (CET)[reageer]
Daar ben ik het geheel niet mee eens. Dit is juist een illustratie van platte tekst vervangen door een sjabloon en dat is inderdaad niet de oplossing. M.vr.gr. brimz 3 mrt 2009 13:42 (CET)[reageer]
Brimz heeft met zijn actie het kind met het badwater weggegooid. Het belangrijke onderdeel, de verwijstabel, heeft hij weggedaan omdat hij de opmaak wat lastig vond. Dit is heel wat erger dan een voor bewerking wat moeilijk te vinden openingszin. --LexTH 3 mrt 2009 13:44 (CET)[reageer]
(na bwc)Je kunt ook stellen, dat het sjabloon verkeerd was opgebouwd, door zowel een tabel áls de openingszin te bevatten. De keuze voor mij was: een moeilijk te bewerken openingszin behouden of een tabel weggooien. Ik heb gekozen voor het laatste. In mijn optiek is niet de tabel het kind wat ik met sjabloon (badwater) heb weggegooid, maar dreigde het kind (de openingszin) de verdrinken in teveel badwater (lees te moeilijk sjabloon). M.vr.gr. brimz 3 mrt 2009 14:16 (CET)[reageer]
Deze aanpak hoort niet op wikipedia thuis. De introzin moet op zijn minst bewerkbaar zijn en niet uit een sjabloon worden gegoocheld. Michiel1972 3 mrt 2009 13:46 (CET)[reageer]
Als je die platte tekst wilt vervangen moet je de inhoud van {{SI-eenheid}} op de megawatt-pagina zetten. Inclusief de sjabloon {{SI-eenheden}}, die de tabel opbouwt. --LexTH 3 mrt 2009 13:48 (CET)[reageer]

Heel jammer dat ondanks niet bereikte consensus mijn bewerking is gerevert. Om een oorlog te vermijden, zal ik niet terugreverten, maar vraag bij deze of iemand anders in naam van de vrije en eenvoudige bewerkbaarheid van wikipedia dit te doen. Alvast bedankt, m.vr.gr. brimz 3 mrt 2009 14:26 (CET)[reageer]

Het is niet kies om te zeggen dat je een oorlog wilt vermijden, en tegelijkertijd anderen op te roepen die oorlog wel te voeren. --LexTH 3 mrt 2009 21:21 (CET)[reageer]
Voor tekst is subst wel degelijk een goed alternatief. Voor echte nuttige sjablonen niet natuurlijk. Mig de Jong 3 mrt 2009 14:27 (CET)[reageer]
Het Sjabloon:SI-eenheid dient voor eenheden waarover weinig meer te vertellen is dan dat het een veelvoud is van een andere eenheid. Aanvankelijk had ik het gedacht voor alle soorten zinloze en zinvolle combinaties, van yottaseconde tot yoctoseconde en van yottafarad tot yoctofarad. Daar ben ik van afgestapt, maar er zijn nog genoeg eenheden die wel zinvol zijn maar waarover niet zo veel te vertellen is.
Wat Brimz heeft gedaan met Megawatt is op zich niet verkeerd, maar het is jammer dat hij de aanroep van Sjabloon:SI-eenheden ook verwijderd heeft, en daarvoor kreeg hij terecht commentaar van Lex.
Handige Harrie 3 mrt 2009 14:33 (CET)[reageer]
Ik zie ook zeker de meerwaarde van die tabel. De complexe sjabloon (waarbij sjabloon in sjabloon) maakte het voor mij onoverzichtelijk, zodat ik niet alle consequenties van het verwijderen ervan heb kunnen overzien. Je kunt mij daarvan beschuldigen, maar de complexheid van de sjabloon is m.i. daar ook deels debet aan. M.vr.gr. brimz 3 mrt 2009 14:56 (CET)[reageer]

Er is ooit jaaaaaaaren geleden eens afgesproken dat we geen teksten zoals openingszinnen en dergelijken in sjablonen zouden gebruiken. Tekst moet gewoon voor iedereen bewerkbaar zijn! Wae®thtm©2009 | overleg 3 mrt 2009 15:12 (CET)[reageer]

Tsja, you can edit this page now is een van die kreten uit de begintijd die inmiddels behoorlijk naar de achtergrond zijn gedrongen. Waar staat die afspraak, Waerth? Fransvannes 3 mrt 2009 16:20 (CET)[reageer]
Ehhh...de openingszin in een sjabloon? Da's - op zijn zachtst gezegd - nogal onhandig. Zoiets sticht verwarring bij vrijwel iedere gebruiker die een artikel wil bewerken. Bovendien zijn geneste sjablonen nogal lastig te volgen - Quistnix 3 mrt 2009 16:36 (CET)[reageer]
Tsja Frans dit is zo een kwestie van ik weet zeker dat het ooit besproken was. Iemand had een sjabloon VK aangemaakt zodat ie niet elke keer verenigd koninkrijk met een link erin naar GB hoefde te tikken ... en dat is toen neergeschoten. Toen is die afspraak gemaakt. Maar waar ik die kan vinden .... pffff Wae®thtm©2009 | overleg 3 mrt 2009 16:50 (CET)[reageer]
Bij gebrek aan adequate archivering heb je hier een olifantengegeheugen nodig. Niet zozeer omdat je de afspraken zelf moet onthouden, maar omdat je moet onthouden waar ze staan... Fransvannes 3 mrt 2009 17:01 (CET)[reageer]
Het is niet de eerste keer dat iemand lappen tekst in sjablonen wil plaatsen. Het is hetzelfde met categorien daarvan hebben we ook ooit afgesproken die niet in sjablonen op te nemen. Maar dat wordt ook al links en rechts weer gedaan :( Wae®thtm©2009 | overleg 3 mrt 2009 17:21 (CET)[reageer]
Nu hebben we het toch wel over verschillende dingen:
  1. Het vervangen van een veel voorkomend stukje tekst door een korte aanroep (VK)
  2. Het vervangen van een openingszin door een sjabloon.
  3. Het vervangen van een lange tekst door een sjabloon.
  4. Het centraal redigeren van een reeks overeenkomstige korte artikelen (hier).
Met elk kun je het eens zijn of niet, maar het is niet juist van het een te zeggen dat het ongewenst is omdat voor het ander is afgesproken het niet te doen. De eigenlijke opzet van {{SI-eenheid}} is een compleet kort artikeltje te maken. Omdat je hierbij moet oppassen je niet te vergissen met de grote getallen is een sjabloon waarin dit geregeld wordt handig. Tegenover het nadeel van het niet onmiddellijk redigeerbaar zijn van de zin in elk artikel staat het voordeel dat je de zin, die overal gelijk is op de eenheid na, centraal kunt redigeren. In het onderhavige geval is daar nog een zin aan toegevoegd, zodat het artikeltje gereduceerd is tot openingszin. Voor alle duidelijkheid: ik heb niets van doen met {{SI-eenheid}}, wel met {{SI-eenheden}}. --LexTH 3 mrt 2009 17:25 (CET)[reageer]
Bedenk je goed, dat je op die manier bezig bent met een onbewerkbare encyclopedie. Ik snap je intentie heel goed en het ziet er mooi uit, zo'n vast stramien voor die kleine artikeltjes die allemaal qua inhoud sterk op elkaar lijken. Zoiets zou heel mooi staan in geredigeerde encyclopedie, als de Brittanica, of de Winkler Prins, of zelfs Citizendium. Daar werken immers een selecte groep redacteuren met een hoge mate van professionaliteit aan de artikelen. Nieuwe redacteuren kun je trainen in hoe bepaalde opbouwzaken gaan. Dit is echter de Wikipedia; iedereen moet kunnen bijdragen aan dit project. Niet alleen zij die verstand hebben van programmataal, waarin we de sjablonen schrijven. Want, immers, alles wat jij als de meest logische manier van opschrijven vindt, kan voor een digibeet als volstrekte wartaal overkomen. Moeten we dan helemaal geen codes meer gebruiken? Natuurlijk niet. Sjablonen, codes en andere mooie scripts kunnen prima op de achtergrond draaien om het uiterlijk van onze teksten nog mooier te presenteren. Maar we zullen ze niet in moeten zetten om onze teksten te produceren. M.vr.gr. brimz 3 mrt 2009 20:01 (CET)[reageer]
Natuurlijk is het niet de bedoeling om de teksten op te delen in allemaal stukjes die over diverse sjablonen verdeeld worden. Maar je moet ook geen dogma maken van de regel dat tekst die niet binnen de lijntjes van een infobox of andere tabel staat niet uit een sjabloon mag komen. Als er een goede reden voor is, en die is er hier, moet dat m.i. wel mogen. Het is een kleinigheid om de tekst die door {{SI-eenheid}} wordt geproduceerd in een kader te zetten. Ik vind het niet mooi, maar het kan. En dan voldoet het wel aan deze norm. Aangezien de zin niet meer doet dan in klare tekst de verhouding tot de hoofdeenheid geven is er geen noodzaak de zin in individuele artikelen te wijzigen. Dat ik hierboven waarschuwde was omdat je er natuurlijk geen woorden in moet zetten die specifiek op de megawatt slaan. --LexTH 3 mrt 2009 21:21 (CET)[reageer]
Argh, je moet geen dogma maken van dat lopende tekst niet middels een sjabloon moet worden aangemaakt? Heb je wel iets begrepen van wat Wikipedia is? Het bewerkbaar zijn van tekst is geen dogma, het is heilig! ♣ Troefkaart 3 mrt 2009 22:24 (CET)[reageer]
Het is niet alleen heilig. Het is dé reden waarom jij en ik aan dit project mee mógen doen! M.vr.gr. brimz 3 mrt 2009 23:54 (CET)[reageer]
O ja? Dan moeten jullie vooral eens bovenaan deze pagina kijken: daar staat {{Wikipedia:De kroeg/hoofding}}, en dat levert een lopende tekst op. Bovendien doet Troefkaart net of de tekst niet meer bewerkbaar is als hij in een sjabloon staat. Hij is weliswaar wat lastiger te bereiken, maar is wel degelijk bewerkbaar. En als daar een belangrijk voordeel tegenover staat moet het m.i. niet dogmatisch afgewezen worden. --LexTH 4 mrt 2009 00:34 (CET)[reageer]

Nog eens de beginnende gebruiker bewerken

Het bovenstaande bracht mij ineens op een gedachte die al een tijdje heb. Ik begin mij namelijk in toenemende mate te verbazen over alle code die in onze artikelen aan het verschijnen is. Nu zal dat allemaal wel nodig zijn voor opmaak enzo, maar het bewerkvenster van een artikel wordt voor een beginnende gebruiker een niet te overziene brij van tekens en codes. Met name sommige infoboxen zijn zo groot, dat ze wel twee pagina's tekst bevatten! Is het een idee (als het technisch al mogelijk is), om deze infoboxen, net als alle andere code vwb categoriën, navigatiesjablonen en dergelijke, ook onder de broodtekst van het artikel te plaatsen? Het bewerkvenster van een artikel begint dan direct met de artikeltekst en dat is (zeker voor de nieuwe gebruiker) wel zo overzichtelijk. M.vr.gr. brimz 28 feb 2009 14:38 (CET)[reageer]

Broodtekst? aleichem 28 feb 2009 14:52 (CET)[reageer]
Toegegeven, afgekeken (afgeluisterd) van Bessel. Hier alvast een beginnetje. brimz 28 feb 2009 15:15 (CET)[reageer]
Ik heb het net even (snel) getest, volgens mij is het mogelijk een sjabloon op een subpagina te zetten en hem dan te laten includen. Bijvoorbeeld : Je hebt het lemma Soep, en daarin kan je bovenaan zetten {{Soep/infobox}}. Dan pakt ie datgenen wat in Soep/infobox staat en include het op de pagina. Zo maak je het voor de niet - techneuten misschien gemakkelijker, ja aleichem 28 feb 2009 15:23 (CET)[reageer]
Dat is al een begin en/of een soort middenweg. Het liefst zou ik alle opmaakgerelateerde teksten en codes aan het eind van een artikel zien. Ook bijvoorbeeld de wrapper heeft een bepaalde codering, die voor een nieuwe gebruiker ondoorzichtig is, waardoor hij daar niet zo goed mee uit de voeten kan. Die wrapper zou je natuurlijk inderdaad ook op de subpagina kunnen zetten. Het zal wel de nodige voeten in aarde hebben, om zoiets ingevoerd te krijgen ben ik bang. Daarom een stelling:
Broodtekst is de tekst waarmee de schrijvende redacteur zijn brood verdient (i.t.t. een kop, intro, of bijschrift). Het is het grootste deel van de tekst van een artikel. Siebrand 1 mrt 2009 19:32 (CET)[reageer]

Opmaakcodes als infoboxen en wrappers maken een bewerktekst (voor een beginnend gebruiker) onoverzichtelijk en zouden daarom niet aan het begin van die tekst te zien moeten zijn. brimz 28 feb 2009 15:34 (CET)[reageer]

@ brimz: is dit niet eigenlijk de vraag naar een wysiwyg-editor? Alle beetjes helpen, maar als je soms ziet wat er in de eerste regel van de "broodtekst" al aan code verstopt zit...
@ aleichem, het idee klopt als een bus, maar bij nader inzien is het precies hetzelfde wat gedaan wordt op de Hoofdpagina. Een beginnend bewerker moet nu in plaats van platte tekst een sjabloontekst bewerken en ik weet niet of dat makkelijker is. Voor het mij lukte om een wistjedatje of nieuwsfeit in de Hoofdpagina in te voeren was ik ook anderhalf jaar verder. - Art Unbound 28 feb 2009 18:30 (CET)[reageer]
Misschien is het ook geen goed idee als beginnende gebruikers sjabloonteksten gaan bewerken? aleichem 28 feb 2009 21:11 (CET)[reageer]
Het probleem is mijns inziens dan ook niet zozeer het bewerken van de broodtekst, maar veeleer het bewerken van tekst die in infoboxen en wat dies meer zij staat. Als je die dan ook nog wegstopt, raak je nog verder van huis. Wat je zou willen verbeteren, is dan niet te vinden. Fransvannes 28 feb 2009 18:47 (CET)[reageer]
Wat misschien een verbetering zou zijn is het verplaatsen van alle index-info (categorisatie, interwiilinks) naar een nieuw te maken naamruimte, "achter" de pagina zelf, zoals iedere pagina een bijbehorende overlegpagina heeft. Dat zou het ook mogelijk maken om interwikibots uit de volglijsten te laten blijven en de categorisatie en interwikilinks bij te houden van pagina's die "op slot staan". De beginnende gebruiker hoeft dan ook al die "rommel" niet te zien en maakt het ook niet per ongeluk stuk - Quistnix 28 feb 2009 18:59 (CET)[reageer]
Tsja, dat is inderdaad de andere kant van de medaille. Of je bent beducht dat beginners iets kapotmaken (en dat stop je dan maar weg) of je bent beducht dat inhoudelijke fouten blijven staan (omdat degene die de fout ontdekt niet weet hoe hij hersteld moet worden). Ik behoor tot de school die vindt dat Wikipedia zo eenvoudig mogelijk te bewerken moet blijven. Daarmee is het groot geworden. Fransvannes 28 feb 2009 19:36 (CET)[reageer]
Tijden veranderen. Ik wil het niet wegstoppen, maar duidelijk scheiden van de inhoud, met daarbij de bijkomende voordelen die ik hierboven noemde. Verder heb ik een vraag: wat is makkelijker voor de beginnende gebruiker: een infobox kopiëren van een ander artikel en zelf alles invullen, of uit het blote hoofd lopende zinnen met de nodige wikilinks erin typen? Bovendien zou ik graag de nieuwe gebruikers zelf aan het woord laten. Het lijkt wel alsof de oude knarren doodsbang zijn voor veranderingen en voor de meningen van nieuwe gebruikers. Van alle uitspraken over waar nieuwe gebruikers tegenaan lopen zie ik nauwelijks eentje uit de eerste hand van een echt nieuwe gebruiker - Quistnix 28 feb 2009 19:53 (CET)[reageer]
Ik ben dan geen "nieuwe gebruiker", maar van al die infoboxen heb ik geen kaas gegeten. Als ik in een artikel iets wil aanpassen, en ik zie in het bewerkveld een enorme lap onbegrijpelijks staan, dan laat ik het vaak maar. Wat mij betreft die infoboxen en andere zaken via eerder genoemde methode ({{Brood/infoboxtekst}} in een subpagina van het artikel plaatsen. Als je dan wat in dat sjabloon wilt wijzigen moet je iets beter je best doen om het te vinden (ook niet zó moeilijk), maar kan je in de bewerkvelden van zowel het artikel zelf als van de infobox-subpagina alles makkelijker vinden. Helemaal voor! - QuicHot 28 feb 2009 21:44 (CET)[reageer]

Helemaal eens met Quichot. Ik doe al meer dan een jaar mee, en nu pas begin ik te begrijpen wat al die codes inhouden. Bovendien is de reden dat categorieën en links naar anderstalige wiki's onderaan staan precies waar het hier om gaat: gebruiksvriendelijkheid voor beginners c.q. goede pr om mee te doen. Mark Coenraats 28 feb 2009 21:51 (CET)[reageer]

Ik ben ook al lang geen nieuwe gebruiker meer, maar ik kan mij herinneren, dat ik in het begin erg veel moeite had om te doorgronden waar al die extra tekens voor staan. Ik kan nu zelfs nog niet foutloos een tabel produceren. brimz 28 feb 2009 22:24 (CET)[reageer]
Dat is iets heel anders dan een infoboxje, hoor. Zie bijv. Sjabloon:Infobox watertoren en het gebruik ervan. Ik kan mij niet voorstellen dat zoiets onbegrijpelijk is - Quistnix 1 mrt 2009 00:22 (CET)[reageer]
Hoe daadwerkelijk lastig een infobox voor de gebruiker is zal voor een groot deel van het gebruik in de praktijk afhangen. Op zich is een Sjabloon:Infobox watertoren best begrijpelijk (afgezien dan van de fout met de afbeelding, maar als het in de praktijk zo gebruikt wordt, dan is het wel onnodig lastig (pure gewichtigdoenerij). Ik heb er ook als eens opgewezen dat de infobox in Amsterdam ook een goed voorbeeld is van onnodig moeilijk doen (vergelijk hier). Dus er is al veel te winnen als de gevestigde gebruikers minder wikipediaans zouden doen en meer recht-toe-recht-aan zouden handelen. - Brya 1 mrt 2009 07:02 (CET)[reageer]
Het is geen gewichtigdoenerij, maar een middel om binnen een project automatisch bij te houden welke gegevens over welke watertorens nog ontbreken. Het voordeel van een sjabloon daarbij is dat wanneer je met meerdere mensen aan een project werkt, iedereen zelfstandig kan werken, terwijl er zo min mogelijk dubbel wordt gedaan - Quistnix 1 mrt 2009 07:17 (CET)[reageer]
Ja, wikipediaans. - Brya 1 mrt 2009 07:22 (CET)[reageer]
Ik begrijp eerlijk gezegd het probleem niet. Wat is er precies ingewikkeld aan die Amsterdamse infobox? b222  ?!bertux 1 mrt 2009 09:28 (CET)[reageer]
Och, zie boven: "Het bovenstaande bracht mij ineens op een gedachte die al een tijdje heb. Ik begin mij namelijk in toenemende mate te verbazen over alle code die in onze artikelen aan het verschijnen is. Nu zal dat allemaal wel nodig zijn voor opmaak enzo, maar het bewerkvenster van een artikel wordt voor een beginnende gebruiker een niet te overziene brij van tekens en codes. Met name sommige infoboxen zijn zo groot, dat ze wel twee pagina's tekst bevatten!" Amsterdam is echt een mooi voorbeeld van volkomen overbodig moeilijk doen: met een paar kleine ingrepen is de ellende tot circa de helft terug te brengen. - Brya 1 mrt 2009 10:41 (CET)[reageer]
En het gaat mij niet eens zozeer om een 'beginnende medewerker'; De opzet van Jimbo Wales was toch een Encyclopedie die iedereen kan bewerken te maken? (Ik kan de kreet noet zo snel terugvinden). De Medewerker die zich uitsluitend op inhoud wil richten wordt meer en meer tegengewerkt door conservatieve (al 100 jaar moderator zijnde) techneuten. – De voorgaande bijdrage werd geplaatst door Aleichem (overleg · bijdragen)
@Bertux, bedenk je heel goed, dat zaken die voor jouw als volstrekt logisch en bekend voorkomen, voor een ander als ultieme algebra kunnen overkomen. De onlogica van een infobox kan voor iemand bijvoorbeeld bestaan uit het feit dat er heel veel tekens, maar ook leesbare tekst instaat, die je niet direct in het uiteindelijke artikel tegenkomt. Je kunt het je bijna niet voorstellen, maar het komt zeker voor en het zou jammer zijn, als dat nieuwe gebruikers (anoniem, of nog maar net ingelogd) daardoor worden ontmoedigd. M.vr.gr. brimz 1 mrt 2009 22:09 (CET)[reageer]
Tja, toen ik de eerste keer zoiets tegenkwam, heb ik van schrik het bewerkvenster meteen weer gesloten, bang dat ik iets fout gedaan had of zou gaan doen. Maar als je eenmaal geaccepteerd hebt dat bovenaan ieder artikel wartaal staat, maakt het toch niet uit of dat drie regels, twintig regels of drie pagina's is? Je slaat het gewoon over in de hoop het ooit te zullen begrijpen, en je bewerkt alleen leesbare tekst. Prima wat mij betreft. b222  ?!bertux 2 mrt 2009 00:56 (CET)[reageer]
Tja, voor de gebruikere die een typefout wil corrigeren ("leesbare tekst") is het toch frustrerend als hij die niet kan vinden in het moeras. Over de vraag of size matters ("drie regels, twintig regels of drie pagina's") bestaan nogal uitgesproken meningen: veelal geldt dat het er wel toe doet. - Brya 2 mrt 2009 06:58 (CET)[reageer]

Ik heb het voorstel van brimz neergelegd bij de developers op [1]. Laten we hopen dat ze de handschoen oppakken of (nog liever) vertellen dat zoiets gewoon al mogelijk is. - André Engels 2 mrt 2009 15:53 (CET)[reageer]

Van een aantal nieuwe gebruikers heb ik echter begrepen dat zij de infoboxen zelf een gemakkelijk onderdeel vonden om aan te passen. Sterker nog, ze begonnen ooit met spelfouten en het bewerken van de info in infoboxen en zijn pas veel later met de rest van de wikisyntax aan de slag gegaan. Dus waarop is deze hele discussie gebaseerd? Het lijkt er op dat deze hele discussie gebaseerd lijkt te zijn op aannames van een aantal gebruikers en niet op wat nieuwe gebruikers zelf moeilijk vinden. Want als het echt zo is dat nieuwe gebruikers moeite hebben met de infoboxen bovenaan, dan zal dat met alle gemak uit een enquete blijken. Er zijn vast wel enquetes geweest, iemand? Speculatie dient uit artikelen te worden verwijderd, hier ook maar. Groetjes - Romaine (overleg) 4 mrt 2009 00:56 (CET)[reageer]
Een beetje jammer dat brimz de draad zo expliciet is opgestart voor de "beginnende gebruiker". Hierdoor lijken de gesignaleerde moeilijkheden neer te komen op speculaties of wat oude herinneringen. Toch is hier al herhaaldelijk aangeduid dat ook ervaren gebruikers problemen ondervinden, in deze discussie bijvoorbeeld nog door Quichot [2], Mark Coenraats [3] en Brya [4]. Bij die laatste opmerking van Brya wil ik me trouwens aansluiten. En, om even op de suggesties van Wickey en Tjako van 2 mrt terug te komen : waarom kan een kleurtje niet? Vriendelijke groeten,-rikipedia 4 mrt 2009 10:55 (CET)[reageer]
Ik ben het met je eens, dat ik het wat anders had kunnen verwoorden. Ik liep min of meer zelf tegen het probleem aan, maar dacht dat in een bredere context te gieten, door het te projecteren op de beginnende gebruiker. Naar nu blijkt, zijn er toch ook wel meer ervaren gebruikers, die mijn ervaringen delen. Dat stemt me goed, maar geeft wel aan, dat de noodzaak om er iets aan te doen, echt aanwezig is. M.vr.gr. brimz 4 mrt 2009 11:10 (CET)[reageer]

Resumé bewerken

Er blijken een aantal mensen te vinden, dat bij voorkeur de eerste tekst in een bewerkvenster niet bevuild zou moeten worden door opmaakgerelateerde codes, als infoboxen, wrappers en dergelijke, dit om het voor nieuwe gebruikers niet onnodig moeilijk te willen maken. Er is ook een groep mensen, die twijfelt of er überhaupt wel een probleem is. Anderen denken al verder en zijn bang dat eventuele oplossingen juist averechts zouden werken.

Ik denk dat het een goed idee is, om er soort van projectje van te maken en dit stap voor stap aan te pakken. Ik zou het volgende willen voorstellen:

  1. Uiteenzetten van de probleemstelling (zodat we het allemaal over hetzelfde hebben)
  2. Data verzamelen (door bijvoorbeeld nieuwe gebruikers om hun mening te vragen)
  3. Naar aanleiding van de data bepalen of er een probleem is en oplossingen uitwerken (de hierboven genoemde twee, wellicht komen er meer bij)
  4. Oplossingen toetsen naar haalbaarheid (zodat we bij een eventuele stemming een haalbare oplossing kunnen bieden)
  5. Overleggen en eventueel peilen welke oplossing de voorkeur geniet
  6. Opzetten stemming op basis van het gestelde probleem met één aangedragen oplossing
  7. Implementatie

Dit klinkt allemaal wat formeel en abstract, maar is meer om een overzichtje te bieden hoe we zo iets zouden kunnen aanpakken. De eventuele stappen kunnen natuurlijk ook aangepast worden, gelang het project vordert. Misschien is het een idee om een project-pagina op te zetten, bijvoorbeeld op wikipedia:Gebruiksgemak voor nieuwe gebruikers? Ik wil dit echter niet alleen doen. Is er iemand die mij wil helpen? brimz 2 mrt 2009 01:00 (CET)[reageer]

  • Het idee om nieuwe gebruikers zeg na een maandje 'lidmaatschap' een enquetetje te laten invullen over e.e.a. spreekt me wel aan. In zo'n enquete kan je ook vragen of ze naast gebruikersgemak (het editten etc) ook zaken missen of toegevoegd zouden willen zien, en hun 'beleving' kunnen inventariseren met bijvoorbeeld een rapportcijfer. Mogelijke vragen zouden ook betrekking kunnen hebben op ervaringen met medegebruikers, welkomstsjablonen, of hulp goed te vinden en adequaat was etc. Tjako overleg 2 mrt 2009 01:14 (CET)[reageer]
Je kan ook wat praktischer zijn en direct het probleem aanpakken, bijvoorbeeld door wrappers op te gaan ruimen waar ze niet nodig zijn, en nee, ik heb nog nooit een wrapper gezien die echt nodig was: in alle gevallen die ik gezien heb ligt een schonere (en gebruikervriendelijke) oplossing voor de hand.
        Eerlijk gezegd ben ik nogal bang van evaluatieformulieren, projecten, etc. Dat leidt makkelijk tot meer red tape en meer onontwarbare pagina's. Het kost veel tijd, energie en vaardigheid om dat goed te doen, en nog meer om dan om eventuele resultaten te gaan implementeren. - Brya 2 mrt 2009 06:46 (CET)[reageer]
Ik denk dat heel veel sjablonen gemakkelijk zo aangepast kunnen worden dat ze altijd bovenaan kunnen verschijnen, ongeacht de plek in het artikel waar ze aangeroepen worden. Je kunt ze dan onderin aanroepen. Voor infoboxen zou dit al afdoende zijn, voor andere sjablonen zou een extra parameter, iets als show = dit kunnen regelen, waarbij je kunt invullen: linksboven, of rechtsonder. Subpagina's kunnen een goed idee zijn, al zou dat op technische moeilijkheden kunnen stuiten.
Veel beter dan mijn bovenstaande suggesties lijkt me echter om de invulling van een sjabloon te verbergen in het normale bewerkingsscherm, zodat je daar alleen leest {{Sjabloon Infobox Amsterdam}}. Dit lijkt me veel beter dan een verplaatsing naar een andere plek waar het op zijn best iets minder in de weg staat.
@Bria:
  • Tybvouten niet kunnen vinden? Zijn er dan mensen die de functie Ctrl-F niet kennen? Daarmee zoek je een tekst binnen de huidige pagina. Andere browsers dan IE hebben vaak ook Ctrl-F, of anders toch een vergelijkbare functie. Het lijkt me bijzonder frustrerend om op WP te werken zonder die functie. Zoek alhier maar eens op "ybvou"
  • Wrapper voorkomt dat foto's bij de geringste tekstverandering de grote witte gaten in de tekst veroorzaken waar Wikipedia berucht om is. Enkele keren heb ik zelfs gedacht het hele artikel gelezen te hebben, terwijl er nog een heel stuk (buiten beeld) volgde. Belangrijker is, dat de Opera-browser een knoeiboel schijnt te maken van artikelen met veel wrapperloze foto's. Ook voorkomt wrapper dat foto's (ook een vorm van codetekst) schijnbaar willekeurig in het artikel rondzwerven, iets wat ik veel storender vind dan bovenin of onderin.
Dat brengt me op het volgende: vele malen erger dan al het voorgaande vind ik de <ref>dkjaiofjiqi4 http://ww fjiee9309 lees hier een GIGantisch lange voetnoot</ref> ref-tags met hun inhoud die de broodtekst vaak volslagen onleesbaar maken. Het erge is, dat hier een oplossing voor bestaat (die ik pas sinds kort ontdekt heb), maar die blijkbaar onbekend of onbegrepen is. De refs kun je niet missen, maar wel inkorten door (voor dit voorbeeld) {{ref|GIG}} te gebruiken. Onderaan je tekst neem je dan een lijst op van alles wat in de voetnoten moet staan, door middel van een keurig lijstje {{noot|verkorte tekst}}-sjabloonaanroepen, waaronder {{noot|GIG}}. Voorbij dat alles komt het bron-, appendix- of references-sjabloon. Zie het artikel zeekomma's voor een voorbeeld. b222  ?!bertux 2 mrt 2009 08:47 (CET)[reageer]
Het staat me bij dat er aan een Amerikaanse universiteit een onderzoek bezig is om de wiki gebruikersvriendelijker te maken. Weet iemand hier meer van? aleichem 2 mrt 2009 09:24 (CET)[reageer]
https://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers aleichem 2 mrt 2009 09:31 (CET)[reageer]
Welke informatie essentieel voor gebruikers missen we op onze help-pagina's die in de manual staan? Op Wikipedia werken leer je door te doenen te proberen, en niet door een manual. Alleen door het te doen kun je er ervaring mee opbouwen en die ervaring gebruiken in de toekomst bij andere bewerkingen. Romaine (overleg) 4 mrt 2009 01:16 (CET)[reageer]
Ja, dat een "Wrapper voorkomt dat foto's bij de geringste tekstverandering de grote witte gaten in de tekst veroorzaken waar Wikipedia berucht om is." is dan wel waar, maar laat onvermeld dat dit de houtje-touwtje-laten-we-er-vooral-niet-over-nadenken oplossing is, terwijl het veel netter kan.
        Hoeveel van de gebruikers niet bekend zijn met Ctrl-F zou ik niet durven zeggen, maar wel dat deze oververtegenwoordigd zullen zijn in de bedoelde groep. - Brya 2 mrt 2009 09:44 (CET)[reageer]
En dat is nu juist de groep waar ik het over heb. We moeten erg waken voor onze beroepsblindheid. Wij werken soms al jaren met dit product en weten vaak van de hoed en de rand. Daardoor zien we sommige onvolkomenheden snel over het hoofd; wij zijn er immers aan gewend, dan kan iemand anders dat toch ook?
@Bertux: Dat van die referenties is een geweldig idee, wat eigenlijk direct wiki-breed ingevoerd moet worden. Het lost namelijk precies het probleem van onleesbare teksten én onvindbare referenties op. De links staan dan in de bewerkttekst op de plaats waar je ze verwacht, namelijk dezelfde plaats als waar ze in het artikel ook staan. Op overleg:zeekomma's staat echter wel een opmerking van iemand bij wie het allemaal niet zo werkte. Is dat inmiddels verholpen? Zo ja, dan pleit ik voor een directe invoering en een aanpassing van help-pagina over referenties. M.vr.gr. brimz 2 mrt 2009 10:17 (CET)[reageer]
Zie ook en:Help:Wikipedia: The Missing Manual. Waar zou dit ingepast kunnen worden? Of is er een liefhebber die dit wil vertalen? aleichem 2 mrt 2009 10:20 (CET)[reageer]
@Bria: Ik geloof onmiddellijk dat het beter kan. Practische suggesties? (Lees ook mijn opm. hieronder aan Brimz voor zo'n suggestie).
@Brimz & de anderen: De tekst van Emiel-bij-wie-de-refjes-niet-werkten lijkt erop te duiden dat (zucht) hij dit systeem niet begreep, dus ideaal krijgen we het niet. Vragen kunnen we het waarschijnlijk niet, want hij is al ruim een half jaar inactief.
Dan het goede nieuws: Nu ik erover nadenk zou iets analoog aan die fijne {{ref}}-nootjes de oplossing voor gigantisch veel problemen kunnen zijn: een sjabloon {{hier}}. Zo dus, voor het artikel Wikipedia zonder fratsen:

{{hier:infobox}}
platte tekst
{{hier:Afb 1}}
platte tekst
{{hier:Afb 2}}
platte tekst
{{hier:ref1}}
platte tekst
{{hier:tabel1}}
platte tekst

In de subpagina Wikipedia zonder fratsen/de fratsen neem je dan de inhoud van al die zooi op.
Terzijde: Wat mij betreft mogen de codes, zolang het artikel redelijk intensief bewerkt wordt, wel in de hoofdpagina blijven staan, wat tijdens het bewerken soms prettig is. Met een vrij eenvoudig botje kan de code uit een gestabiliseerd artikel naar de subpagina's geheveld worden. Eventueel zou er ook een terugbotje kunnen zijn dat de code tijdelijk weer terugplaatst in de hoofdpagina. Maar het idee zou ik zeker steunen, ook als er geen geautomatiseerde terugzooiing komt. b222  ?!bertux 2 mrt 2009 11:01 (CET)[reageer]
(na bwc) Dit lijkt mij een heel goede opzet en voortborduring op een al bestaand idee (de refs). Wat mij betreft zouden de "fratsen" niet eens in een aparte subpagina te hoeven staan, maar zouden ze zelfs onderaan de pagina kunnen komen (net als bij de refs nu). Op de bewerkpagina kan dan een <-- Sjablonen hieronder --> komen, waar de gebruikte sjablonen als {{infobox}}, {{afbeelding}}, etc. in dezelfde volgorde (ivm terugvindbaarheid) als in de platte tekst komen te staan. Ik verwacht enige weerstand als die sjablonen op een aparte subpagina terechtkomen. Wellicht kan niet iedereen ze dan terugvinden, of mist men het overzicht. M.vr.gr. brimz 2 mrt 2009 11:16 (CET)[reageer]
Het bewerkvenster zou al een stuk overzichtelijker zijn als alle codes als <ref> en {{hier}} in een kleurtje zouden worden weergegeven, zoals in een HTML-pagina.--Wickey-nl 2 mrt 2009 11:10 (CET)[reageer]
Nou ja, voor wat betreft wrappers: voor Amsterdam is dit een wrapperloze aanpak van de infobox. Niet zo moeilijk, lijkt me (alleen dan dat gedoe met de afbeeldingen nog verbeteren). Voor andere situaties, zie deze eerdere discussie. - Brya 2 mrt 2009 11:30 (CET)[reageer]
Heb geen tijd meer; als er vanavond geen bezwaren zijn gerezen zal ik eens gaan kijken naar een sjabloon hier en de consequenties daarvan. Wat de wrapper betreft: ik begrijp dat vooral de studie die het invullen vergt een probleem is. Dat moet eigenlijk zo op te lossen zijn, hoewel ik zelf altijd even naar de wrapper-pagina ga en het voorbeeld copypaste. Dan zie je meteen hoe het ingevuld moet worden. Het lijkt wel beter te kunnen. Eens uitzoeken wie dat zou kunnen doen. Tot vanaavond. b222  ?!bertux 2 mrt 2009 12:38 (CET)[reageer]
  • Wat is in vredesnaam een "platte tekst" (anders dan een laag-bij-de-grond(s) product) of een "broodtekst" als dit al geen voedselgaring is ..?? Zelfs met "infoboxen" raak ik nog de weg hier kwijt, laat staan dat ik een "wrapper" moet ontleden. Is dat soms "kletskoek" ..?? - Met vriendelijke groet: D.A. Borgdorff via het fijne n° 86.83.155.44 2 mrt 2009 13:34 (CET)[reageer]
Zie Platte tekst. --LexTH 2 mrt 2009 14:47 (CET)[reageer]
Ofwel ik heb het niet begrepen, of Brimz en Bertux hebben niet begrepen hoe het bij de notes werkt: Bij de notes wordt hier gepropageerd om de tekst te verplaatsen naar de plaats waar hij werkelijk getoond wordt. Als je echter ergens {{hier:infobox}} of {{hier:Afb 1}} plaatst wordt daar een sjabloon geplaatst, dat is de hier nogal verguisde methode van de engelstalige WP. Je moet dan voor elke pagina een aantal sjablonen maken, bij voorkeur onder de namen {{paginanaam/infobox}} en <{{paginanaam/Afb 1}} enz. Je maakt het de mensen die de platte tekst willen bewerken dan wel makkelijker, maar voor de mensen die iets willen veranderen in de infobox enz. maak je het wel een stuk moeilijker, want die moeten voor elke wijziging eerst de betreffende sjabloonpagina opzoeken, en die kun je in de te bewerken tekst niet aanklikken. Je moet dan eerst helemaal onderaan de bewerkpagina de sjabloon aanklikken, en vervolgens bewerken, om in het bewerkveld te komen. Bovendien heb je voor elk onderdeel een aparte sjabloon, dus wat eerst een aantal bewerkingen in één pagina is, wordt nu een bewerking van evenzovele verschillende pagina's. Ik heb al klachten gezien over het bewerken van een reeks paginaonderdelen, i.p.v. alle bewerkingen in een keer op de hele pagina doen.
Misschien is er iets te doen met {{anker}}, maar ik weet niets van html, en dus ook niet of je bij een <span id="plaatje1"></span> het elders gedefinieerde plaatje op die plaats kunt zetten, of dat het misschien met een andere tag mogelijk is. --LexTH 2 mrt 2009 15:30 (CET)[reageer]
Beste Lex, het merendeel van je betoog begrijp ik, maar een ding begrijp ik weer niet: in het bewerkingsveld valt niets aan te klikken, dus "onderaan de bewerkpagina de sjabloon aanklikken, en vervolgens bewerken" kan dan niet. Wat ik wel regelmatig doe: in het bewerkveld een sjabloon opzoeken en de naam ervan kopiëren, bewerkveld sluiten, via de zoekfunctie {{Sjabloon:tekst]] invoeren, bij het gevonden sjabloon op bewerk klikken en het sjabloon bewerken. Nu is de vraag of dat makkelijker of moeilijker kan.
Zoals wikipedia nu werkt: wil je iets wijzigen in de gewone tekst, zul je je leesbril moeten opzetten, alles passeren wat tussen {{ }} haken staat, en bij alles wat tussen < > </> haken of [[ ]] haken staat moeten opletten dat je daar niet per ongeluk tussendoor typt. Dat kan best, al is het niet heel handig. Voor beginnende gebruikers betekent dat: Let op bij <>, [[]] en {{}}. - Art Unbound 2 mrt 2009 22:33 (CET)[reageer]
Wat Lex bedoelt is niet dat je in het bewerkingsveld iets aan kunt klikken, maar dat je helemaal onder het bewerkingsveld, zelfs onder alle vreemde tekens die je in kunt voeren en zelfs onder de GDFL voorwaarden (dus echt helemaal onderaan de pagina) een lijst krijgt met alle sjablonen die op de pagina worden gebruikt. Achter de naam van het sjabloon staat tussen haakjes (bewerken) zodat je meteen het sjabloon kunt bewerken. Miho 3 mrt 2009 00:48 (CET)[reageer]
Dat ís toch al zo? valhallasw 3 mrt 2009 01:13 (CET)[reageer]
Het zou al helpen als het editortje de tags met kleur zou afbeelden, of wanneer de muis over een sjabloon of tag of link gaat even een popupje toont met 'bewerkbaar' o.i.d. Iets voor versie 'proxima volta'? (Net als de taalselectie bij bijv. Notepad++, waarin alle 'soorten' tekst in de 'body' gekleurd kunnen worden.) Tjako overleg 2 mrt 2009 22:57 (CET)[reageer]
Miho geeft precies aan wat ik bedoelde. Ik vergiste me door te schrijven dat je eerst de sjabloon moet aanklikken, en vervolgens bewerken. Dat kan idd in een keer. Maar het blijft wel lastig. Vooral omdat wijzigingen veelal zullen samenhangen met de tekst die in de buurt van het object staat. Nu moet je een heel eind heen- en weer scrollen. Er komt nog bij dat de sjablonenlijst alleen getoond wordt als je een volledige pagina bewerkt, niet als je een gedeelte bewerkt. --LexTH 3 mrt 2009 01:17 (CET)[reageer]
Aangezien dit het sub-sjabloon draadje is, de originele Guildwars Wiki gebruikt al een paar jaar een systeem met sjablonen waarbij het sjabloon een linkje biedt waarmee het direct vanuit het artikel bewerkt kan worden. Zie bijvoorbeeld "Mantra of Concentration". We kunnen wel uitzoeken hoe dat werkt, als er interesse voor is. Fenke 4 mrt 2009 09:30 (CET)[reageer]

Mogelijke oplossing bewerken

Is dit wat? hoewel ik de commotie eigenlijk niet begrijp: is een lijst parameter=waarde-items echt zo angstaanjagend?valhallasw 2 mrt 2009 21:36 (CET)[reageer]

Kan je de truck uitleggen? Ik ging eerst kijken of sjabloon:Amsterdam bestond (niet dus), toen bleek de infobox onderaan te staan maar wordt bovenaan getoond. Wel even wennen (zou het niet meer problemen oproepen dan oplossen, wysiwyg geldt niet meer)? Michiel1972 2 mrt 2009 21:43 (CET)[reageer]
Het sjabloon {{:Amsterdam}} is de pagina Amsterdam, waarvan alleen het blok tussen <onlyinclude> ge-included wordt en waar het blok tussen <includeonly - hetzelfde blok dus - niet wordt getoond bij het normaal bekijken van de pagina. In feite zet je dus het <includeonly><onlyinclude>-blok waar nu {{:Amsterdam}} staat. Welke WYSIWYG, trouwens? Nooit zoveel van gemerkt ;) valhallasw 2 mrt 2009 21:46 (CET)[reageer]
Het is wel een erg intelligente truc. Dank daarvoor. brimz 2 mrt 2009 21:49 (CET)[reageer]
Mooi bedacht, ja. Daar zou mee te werken zijn. - André Engels 3 mrt 2009 12:46 (CET)[reageer]
Leuk bedacht, maar het resultaat is nóg meer onbegrijpelijke code op een pagina die bovendien overbodig is! Kom eerst maar eens met een enquete/onderzoek waaruit blijkt dat nieuwe gebruikers moeite hebben met infoboxen en parameters bovenaan de pagina en dat scrollen voor hen te moeilijk is. Want daar gaat het over, we achten schijnbaar nieuwe gebruikers niet in staat te scrollen (voorbij een simpele rij met ingevulde info) naar de sectie waar de aanpassing gewenst is. Tjonge, dan is die WYSIWYG-editor wel heel erg noodzakelijk, want dan hoeven we slechts te klikken op de plek waar we iets willen aanpassen en dan staat de cursor daar automatisch dat je direct kan bewerken. Tjonge, scrollen is toch zo ontzettend moeilijk... Romaine (overleg) 4 mrt 2009 01:03 (CET)[reageer]
Ik heb eigenlijk nog niemand horen zeggen dat de lijst met parameters als een echt probleem gezien wordt. Wel de hoeveelheid code. In en rond de infobox van Amsterdam zit een heleboel code, zodat het in de verste verte géén lijst met parameters sec is. Er kan 30% (of meer) van die rommel weg zonder dat daarbij ook maar één parameter aangeraakt wordt. Ik betwijfel met Romaine of het invoegen van nog meer code de goede weg is. - Brya 4 mrt 2009 07:11 (CET)[reageer]
In de hele discussie gaat er al over dat de code-brei aan het begin van artikelen als een probleem wordt gezien, en nou zeg jij dat niemand het als een echt probleem ziet? Nou, kijk er zelf eens naar, die lijst met parameters op eerdere versies van Amsterdam ziet er behoorlijk onoverzichtelijk en afschrikwekkend uit en ik kan me wel voorstellen dat iemand die hier niet in thuis is er voor terugdeinst. Het stukje <onlyinclude> en <includeonly> dat het mogelijk maakt die onverzichtelijke sjabloon aanroep naar het einde van het artikel te verplaatsen maakt de tekst van het artikel overzichtelijker zonder dat daar de code nou echt moeilijker van wordt. Fenke 4 mrt 2009 08:27 (CET)[reageer]
Wel zuiver blijven! Er wordt geklaagd dat er aan het begin van artikelen "een niet te overziene brij van tekens en codes" staat. Diverse gebruikers die de status quo verdedigen doen het voorkomen of de lijst met parameters het probleem is, maar dat heeft niemand gezegd: dat is enkel een truc. Dat er veel gebruikers zijn die heel licht denken over het toevoegen van code en dan vinden "dat daar de code nou [niet] echt moeilijker van wordt." is nu juist het probleem. - Brya 4 mrt 2009 08:39 (CET)[reageer]
@Romaine; de code wordt niet verplaatst naar een andere (onnodige) pagina, maar naar de onderkant van de alreeds bestaande pagina. Toegegeven er wordt iets meer code toegevoegd, met als winst, dat er heel groot gedeelte van die code nu ietwat uit zicht staat. Ik ben ook nog steeds voorstander van het idee, om nieuwe gebruikers middels een onderzoekje naar hun mening te vragen. Harde data helpt meer, dan vermoedens.
@Brya en Fenke; ik heb het idee, dat jullie langs elkaar heen praten en hetzelfde bedoelen? M.vr.gr. brimz 4 mrt 2009 09:01 (CET)[reageer]
(bwc) Brya, deze hele draad is gestart, en aangevuld, vanwege de 'brei aan code' en daarbij ging het volgens mij niet om de interwikilinks die aan het einde van artikelen te vinden zijn, maar om de infoboxbrei aan het begin, want dat is wat je te zien krijgt nadat je bewerken hebt geklikt. Zelfs als je de parameteraanroep opschoont hou je nog een onoverzichtelijke en tamelijk moeilijk te begrijpen lap tekst over. Het is wat gebruikersvriendelijker om die naar het einde te verplaatsen. Fenke 4 mrt 2009 09:12 (CET) (edit 4 mrt 2009 09:17 (CET))[reageer]
Er is nergens gezegd dat in de 'brei aan code' de parameters nu een rol van betekenis spelen. Uiteraard geldt wel: "korter is overzichtelijker" en zou het helpen lege parameter-velden weg te laten, maar het probleem zit toch vooral in de 'code'. Het aanroepen van een afbeelding via een link is nergens voor nodig. Het is heel goed mogelijk om direct het plaatje aan te roepen, en dat scheelt een stuk in de gebruikersvriendelijkheid. Het weglaten van een wrapper scheelt echt heel veel zinloze code. Dan roept Amsterdam in het begin ook nog eens twee sjablonen aan wat de overzichtelijkheid ook niet helpt. - Brya 4 mrt 2009 12:24 (CET)[reageer]

Theorie bewerken

Misschien toepasselijk in het jaar van Charles Darwin, maar helaas zijn er ook artikelen die minder handig geformuleerd zijn dan de inleiding van het artikel over de evolutietheorie. Ik kijk vnl. naar artikelen over taal, mythologie en geschiedenis en kom vrij regelmatig erg controversiele theorien tegen die gepresenteerd worden als feiten (zie bijvoorbeeld Moedergodincultus of het artikel over de Kelten), zonder dat daarbij bronvermeldingen staan of dat er vermeld wordt waar de theorie vandaan komt.
Anderzijds lijken me opmerkingen zoals die bij het lemma chakra nogal overbodig als in het begin van het artikel de context gedefinieerd wordt.
Het artikel over Matriarchaat lijkt me daarentegen juist een voorbeeld van hoe een controversiele theorie wel handig beschreven kan worden (er zitten nog wat gekke dingen in, maar het bevat iig info over waar de theorie vandaan komt). Bedwyr 4 mrt 2009 08:50 (CET)[reageer]