Wikipedia:De kroeg/Archief/20190209

Afgeschrikte bewerker

Ik behandelde net een OTRS-mail van iemand die veel over molens weet en een correctie voorstelde voor een artikel over de molen in de Polder Arkemheen. Mijn reactie was dat ik het niet aan kon passen (er stonden nog 20 mails in de wachtrij die ik af wilde handelen), maar ik gaf hem instructies over de eerste stappen op Wikipedia mee.
Na 2 uur kwam er een mail terug: Dhr had op bewerk geklikt en gekeken, maar al die verwarrende codes: dat ging hem echt niet lukken!

Ik vind het zo jammer dat we nieuwe gebruikers met kennis afschrikken door onze wikicodes, dus ik wil graag terugkomen op mijn eerdere peiling over het aanzetten van de visuele bewerker. Ik kan uit die peiling opmaken dat er geen consensus is voor het aanzetten van de VE als default. Wel is er een mooie meerderheid die een tweede tabje geen probleem zou vinden. Je krijgt dan een tabje met "bewerken" en "brontekst bewerken" en hebt de keuze tussen een of ander. De VE werkt nu alleen bij artikelen, niet op overlegpagina's of op projectpagina's zoals bijvoorbeeld de Kroeg. Je moét het niet gebruiken, maar het mág. Het zal je verder niet in de weg staan!

En om Akoopal te citeren vanaf de overlegpagina van de peiling: " In de huidige situatie kan een 'anoniem' de visual editor niet gebruiken, omdat hij het simpelweg niet kan instellen, om de visual editor te gebruiken moet je registeren en dan de beta aanzetten. Alhoewel ik zelf VE weinig gebruikt, denk ik dat het voor de gemiddelde anoniem die misschien alleen een spelfout wil verbeteren zeker wel een verbetering is." Ciell 19 jan 2019 19:00 (CET)

Ik ben voor. Ik had de peiling gemist. De Visuele Editor werkt erg goed, juist voor het aanbrengen van kleine of grote correcties in de tekst. Ik verwacht een toename in het aantal kleine hulpvaardige bijdragen. --Frank Geerlings (overleg) 19 jan 2019 19:12 (CET)

Ik ben ook voor. Het eerste wat ik doe als ik een nieuweling help, is laten zien hoe de visuele editor kan worden aangezet. Ja, ik moest ook wennen toen we van WP5.1 naar Word overgingen, maar ik ben als een kind zo blij dat de codes niet meer te zien zijn. #Moetjenietwillen... Elly (overleg) 19 jan 2019 20:07 (CET)

Nou nee, ik zette die ooit een keer aan en snapte er niets van en ik werk al 30 jaar met computers. Nu is er de keuze. Als ik vergeten ben dat ik uitgelogd ben dan komt de optie voor de visuele tekstverwerker in beeld. Ik druk meteen op ESC want ik wil geen visuele tekstverwerker. Welke verwarrende codes dan? Ik denk dat het zo'n lijst is van molens (net als van monumenten e.d.), daar moet iedereen aan wennen, maar dat blijft dus toch lastig of je het nu zo bewerkt of met die visuele editor (lijkt mij) .. - Inertia6084 - Overleg 19 jan 2019 20:09 (CET)

Ik had die peiling wel gezien. Ik twijfelde echter wat en de stemperiode was vrij recent begonnen. Dus ik wilde een beetje wachten met stemmen. Daarna heb ik dat wat uit het oog verloren waardoor ik uiteindelijk niet gestemd heb, maar ik ben voor de optie met VE als tweede tabje. Daarmee bedoel ik dus wel dat ik de VE niet als standaard wil, maar de broncode. (in tegenstelling tot de eerste stemcommentaar bij de optie "Tegen, maar voor bij twee tabjes") Mvg, TheDragonhunter | Vragen? 19 jan 2019 20:14 (CET)

Merk op dat er waarschijnlijk allerlei scriptjes te schrijven zijn waardoor je persoonlijke indeling van de tabjes kan worden aangepast. Het gaat hier eigenlijk vooral om de indeling die we nieuwe gebruikers standaard voorschotelen. Effeietsanders 19 jan 2019 20:27 (CET)

Zoals ik zei, ik ben voor twee tabjes, maar broncode moet wel wat mij betreft standaard blijven. Een andere gebruiker heeft dat ook expliciet aangegeven in die peiling toen hem/haar gevraagd werd om eventueel zijn/haar tegenstem te verplaatsen naar "Tegen, maar voor bij twee tabjes" wegens die stemcommentaar. De VE staat nu nogal verstopt (en is alleen voor geregistreerde gebruikers beschikbaar). De VE wat zichtbaarder maken dmv 2 tabjes is wat mij betreft prima, maar standaard gaat me te ver. Op de Franse en Spaanse Wikipedia waar er 2 tabjes zijn, kom je via "Bewerken" (in Frans/Spaans dan) terecht bij de VE. Via het tweede tabje kom je bij de broncode terecht. Daar stoor ik me wel eens aan. Verder gaat dat tweede tabje met de VE er wrsl niet in de sjabloonnaamruimte komen. Dan heb je daar maar 1 tabje. Het lijkt me wat raar om in de hoofdnaamruimte de tabjes "Bewerken" (VE) en "Bewerken in broncode" te hebben en in de sjabloonnaamruimte dan "Bewerken" (broncode, maar in de hoofdnaamruimte is dat dan VE) of "Bewerken in broncode" (terwijl dat het enige tabje is...). Liever wat consequent. "Bewerken" = broncode, tweede tabje "Bewerken in visuele tekstverwerker". Dat tweede tabje is dan wrsl niet aanwezig in de sjabloonnaamruimte.Mvg, TheDragonhunter | Vragen? 19 jan 2019 22:49 (CET)

Ik ben ook voor. Veel oudgedienden hier zijn heel handig met al die wikicodes, maar de gemiddelde nieuweling snapt er denk ik maar weinig van en kan er inderdaad door afgeschrikt raken. Marrakech (overleg) 19 jan 2019 20:34 (CET)

Gewoon een paar codes... wie wil dat nu, het is nog moeilijker dan gewoon html.... Elly (overleg) 19 jan 2019 20:44 (CET)

{{wrapper}} |[[Bestand:Vermeer Lady Maidservant Holding Letter.jpg|{{largethumb}}|''[[Dame en dienstbode]]'', ± 1666-1667]] |- |[[Bestand:DublinVermeer.jpg|{{largethumb}}|''[[Schrijvende vrouw met dienstbode]]'', ± 1670-1671]] |- [[Bestand:Girl with a Pearl Earring.jpg|{{largethumb}}|''[[Meisje met de parel]]'', ± 1665-1667]] |} {| cellpadding="1" cellspacing="0" class="toccolours" |- ! | Datering ! | Titel ! | Eigendom, tentoonstelling ! | Formaat<span style="font-weight:normal"> (cm)</span> |- |style="text-align:right"| gesigneerd, ± 1653-1656 |  [[Diana en haar Nimfen (Vermeer)|Diana en haar gezelschap]] | [[Mauritshuis]], Den Haag |style="text-align:right"| 98,5 × 105 |-

Dit is dan ook niet de gebruikelijke "code" gebruikt bij wikipedia. The Banner Overleg 19 jan 2019 21:07 (CET)

Alsnog snap ik dat een (al dan niet onervaren) gebruiker voor een aanpassing in deze lijst liever de visuele bewerker gebruikt. Is iets meer klikken en wat minder code schrijven, voor mensen zonder veel computer(code-)ervaring kan dat best prettig zijn. Encycloon (overleg) 19 jan 2019 21:35 (CET)

Alsnog? Marrakech (overleg) 19 jan 2019 21:46 (CET)

Na de toelichting hieronder gelezen te hebben: 'alsnog' is op te vatten als 'ook in vaker voorkomende gevallen'. Encycloon (overleg) 19 jan 2019 22:18 (CET)

Het is in feite een niet-standaard verticale gallery van Johannes Vermeer. Bepaalt geen standaard codering dus om dit te presenteren als "Gewoon een paar codes" is niet juist. The Banner Overleg 19 jan 2019 21:45 (CET)

Ik heb niet lang gezocht naar rare codes. Ze zijn overal. Vermeer is gewoon een artikel op mijn volglijst. Ik denk dat het veel gelezen en veel bewerkt wordt. Elly (overleg) 19 jan 2019 22:05 (CET)

Misschien dat er wel consensus is voor de optie met de twee tabjes? Een deel lijkt voor te zijn omdat ze geloven dat de VE laagdrempelige/beter geschikt is voor nieuwe bewerkers. Nou, het achterliggende doel daarvan bereik je ook met twee tabjes. Een deel is voor die twee tabjes. Een deel is tegen omdat ze de VE prut vinden. Goed, dat kan. Maar binnen dat kamp is vooral een sterk bezwaar tegen het opleggen van de VE aan nieuwe gebruikers. Dan zou ook voor die gebruikers de twee tabjes geen bezwaar moeten zijn. En tot slot is het voor een enkeling een princiepenstrijd. Die mensen kan je tijdens het consensproces gewoon negeren. Tegen zijn om het tegen zijn is geen argument en die groep mensen aanvaard toch geen enkel compromis. Natuur12 (overleg) 19 jan 2019 22:19 (CET)

Persoonlijk vind ik VE een draak maar wie ben ik om andere mensen de mogelijkheid te onthouden? Niet alle mensen zijn gelijk. En daarom zijn meerdere werkopties een goed plan. The Banner Overleg 19 jan 2019 22:38 (CET)

Die peiling was een peiling. En de meerderheid wees de vraagstelling af. Het staat conform de regels eenieder vrij een nieuwe peiling te beginnen, zes maanden na de vorige, met dezelfde vraagstelling of een andere. En bij zoiets ingrijpend als het willen invoeren van de VE, is na een peiling een stemming gewenst. Het gaat verder niet alleen om het invoeren van de VE, maar ook om de plaats van het tabje: na de enige nu of ervoor, en ook over de naamgeving. Ik acht het niet de bedoeling om in De Kroeg een dergelijk ingrijpende wijziging erdoor te drukken nu er al een peiling is geweest, waarbij het voorstel werd afgeschoten en velen hier nooit komen. mvg. HT (overleg) 19 jan 2019 23:58 (CET)

Dat van die 6 maanden geldt alleen bij stemmingen. (Wikipedia:Stemprocedure) Peilingen zijn niet conform de stemprocedure. Zo mogen bv. anoniemen wel stemmen bij peilingen.Mvg, TheDragonhunter | Vragen? 20 jan 2019 00:14 (CET)

Als dat zo is, dan des te beter en kan er meteen begonnen worden met het opzetten van een nieuwe peiling. Bedankt voor de tip. HT (overleg) 20 jan 2019 00:21 (CET)

De voorgaande peiling ging niet over de vervanging van het tabje "bewerken" door twee tabjes. De peiling ging over het aanbieden van de visuele tekstverwerker als standaard. Dat is toch een heel ander voorstel? Bij die peiling waren er trouwens al veel mensen die pleitten voor twee tabjes als aanvaardbaar alternatief. Sijtze Reurich (overleg) 20 jan 2019 09:26 (CET)

SvenDK gaf bij de peiling aan dat er nog veel aan de visuele textverwerker zou haperen. Volgens hem werkt de VE niet degelijk op Safari en Edge (hier). Volgens Effeietsanders zijn sommige sjablonen met de VE lastig te bewerken, ook naar voren gebracht tijdens de peiling (hier). Het lijkt mij om in elk geval eerst eventuele gebreken te analyseren en na te gaan of ze kunnen worden opgelost. mvg. HT (overleg) 20 jan 2019 11:04 (CET)

Mijn opmerking was gebaseerd op ervaring van ongeveer 6 maand geleden. Ik heb gisteren zowel Safari op mijn iPad met iOS 12 en op mijn nieuwe PC Windows 10 met Microsoft Edge 42.17134.1.0. Bij beiden heb ik niet meer de basisproblemen die ik vroeger had (wijzigingen niet kunnen opslaan): SvenDK (overleg) 22 jan 2019 07:09 (CET)

Sjablonen die lastig te bewerken zijn, blijf je altijd houden. Dat hoeft op zich geen obstakel te zijn, zoals ook al elders gemeld: zolang je maar eenvoudig kunt terugschakelen naar de brontekst bewerker. Tegenwoordig wordt dan ook de rest van je bewerking behouden, en kun je dus zonder problemen schakelen in het midden van je bewerking (of dat de andere kant op ook gaat, weet ik overigens niet zeker). Deels kun je het aantal sjablonen dat problemen oplevert overigens wel verminderen door de sjabloondocumentatie te verbeteren. Dat is iets waar we op nlwiki wat achterlopen vergeleken met andere talen (heb ik me laten vertellen). Waarschijnlijk zijn er nog wel meer keuzes die we bij het ontwerpen van sjablonen beter kunnen maken. Misschien een idee om Wikipedia:Sjablonen te herzien met het oog op de visual editor en een schoonmaakactie te houden. Effeietsanders 20 jan 2019 21:01 (CET)

Ik ben blij hier al enige mate van overeenstemming te lezen!

@HT: inderdaad moeten de Safari en Edge problemen opgelost worden. Ik denk verder dat we niet kunnen verwachten dat VE alle Nederlandse sjablonen zal kunnen hanteren en dat hoeft ook niet nmm: voor ingewikkeldere sjablonen kunnen gebruikers weer terugschakelen naar de broncode. Mensen die daarmee aan het werk zijn, zullen over het algemeen ook een voorkeur hebben voor werken in code, in mijn persoonlijke aanname.

@SvenDK: Wil je mij (liefst via mail) laten weten welke problemen jij nog ondervindt in Safari en Edge? Dan kan ik zien of ik de problemen kan aankaarten bij de ontwikkelaars, voordat we overgaan naar een volgende peiling of stemming. Ciell 20 jan 2019 16:28 (CET)

Een van de voornaamste problemen waardoor in de eerdere peiling tegen invoering van de VE werd gestemd is nog steeds een issue. Het gaat hierbij om afbeeldingen die ingesteld zijn op de breedte van de infobox (largethumb) en de VE kan hier niet goed mee overweg. Het gevolg is dat er hierdoor een heleboel witruimte bovenaan artikelen wordt gegenereerd met het bewerken in de VE, waardoor bewerkers de neiging krijgen om die witregels te verwijderen, waarmee onzichtbaar een hele serie afbeeldingen uit een artikel verwijderd worden, zonder dat dat de bedoeling is.

Tijdens een conferentie heb ik met ontwikkelaars gesproken over dit technische probleem. Terwijl het voor ons als bewerkers iets simpels lijkt, grijpt dit heel diep in de software van MediaWiki. Zij zien dan ook geen reële mogelijkheid om hier in de VE rekening mee te houden. Wel hebben ze een andere oplossing aangedragen. De breedte van de standaardbreedte thumb van afbeeldingen is op nl-wiki best klein ingesteld (wat voor gebruikers o.a. reden is om largethumb ook te gebruiken). De ontwikkelaars stelden voor dat we de standaardbreedte van de thumb gelijk maken aan die van infoboxen (40px meer), waardoor largethumb niet meer nodig is en afbeeldingen in principe altijd netjes uitgelijnd onder infoboxen staan. Voor wie toch smallere afbeeldingen wil kan dit in de eigen voorkeuren instellen, maar nog groter instellen is ook mogelijk. De standaardgrootte van thumb met 40px vergroten lost enerzijds het probleem op dat afbeeldingen vaak wat te klein worden getoond, dat er minder ingesteld hoeft te worden, dat de VE er mee overweg kan en dat er geen opstapeling van witregels bovenaan artikelen ontstaat waardoor onterecht afbeeldingen verdwijnen. Romaine (overleg) 20 jan 2019 16:55 (CET)

Helder, gewoon doen dus. Edoderoo (overleg) 20 jan 2019 20:54 (CET)

Voorstel van Romaine vind ik oké. Verder wil ik omwille van digibeten wel voor twee bewerkingsknoppen stemmen: visueel en code. Dan heeft eigenlijk iedereen zijn ding. Op de Franse doen ze het ook zo. Ymnes (overleg) 21 jan 2019 20:45 (CET)

Mijn opmerking was gebaseerd op ervaring van ongeveer 6 maand geleden. Ik heb gisteren zowel Safari op mijn iPad met iOS 12 en op mijn nieuwe PC Windows 10 met Microsoft Edge 42.17134.1.0. Bij beiden heb ik niet meer de basisproblemen die ik vroeger had (wijzigingen niet kunnen opslaan): SvenDK (overleg) 22 jan 2019 07:09 (CET)

Dus dan is het probleem dat je aangaf ten tijde van de peiling opgelost, blijft alleen nog het probleem thumb vs largethumb in sjablonen.

@Romaine: Wat is er voor nodig om dit op te lossen? Zijn er daarbij problemen die je voorziet (die ik niet lees in je toelichting?), of heb je hulp nodig om dit uit te voeren? Ciell 22 jan 2019 17:13 (CET)

@Romaine: Zou je hier nog eens naar willen kijken? Ciell 24 jan 2019 19:21 (CET)

@Romaine: Heb je het misschien al aangepast? Ciell 26 jan 2019 11:57 (CET)

@Ciell & allen: Mijn excuses voor de vertraging, ziekte en te veel verplichtingen zaten in de weg.

Wat er moet gebeuren met de standaardgrootte is dat die vergroot wordt en dat dient plaats te vinden met een verzoek op Phabricator. De systeemontwikkelaars hebben daarbij altijd de procedure dat er draagvlak moet blijken vanaf de wiki waarvoor zo'n verzoek ingediend wordt. Op zich zou deze discussie voldoende kunnen zijn. Ik heb zojuist het verzoek ingediend, zie: phab:T215106. Romaine (overleg) 2 feb 2019 17:25 (CET)

Onbedoelde indirecte beloning van vandalisme

Als men 'het' artikel over het onderwerp 'kinderpardon' opvraagt, krijgt men de historie van vandalisme te zien:

Deze pagina is verwijderd. Ter informatie wordt het verwijderingslogboek, het beveiligingslogboek en het hernoemingslogboek van deze pagina hieronder weergegeven.

15 mei 2014 14:19 MoiraMoira (overleg | bijdragen) heeft de pagina Kinderpardon verwijderd (De inhoud was: "poep" (95.97.13.98 was de enige auteur)) (bedanken) 15 mei 2014 13:45 Ronn (overleg | bijdragen) heeft de pagina Kinderpardon verwijderd (Geen zinvolle inhoud: De inhoud was: "poep" (95.97.13.98 was de enige auteur)) (bedanken) 30 mrt 2012 01:15 Kattenkruid (overleg | bijdragen) heeft de pagina Kinderpardon verwijderd (Schending auteursrechten, link: http://www.radio1.nl/items/43490-er-moet-een-kinderpardon-komen) (bedanken)

Dit lijkt me onwenselijk - het 'werk' van de vandaal is prominent te zien en de gewone gebruiker van wikipedia zou hier niet mee geconfronteerd mogen worden. Carol (overleg) 31 jan 2019 05:18 (CET)

Een goed artikel over het onderwerp zou overigens best een aardig idee zijn. Het is nogal in het nieuws de laatste tijd. Om meteen maar de onvermijdelijke vraag te beantwoorden: nee, ik ga het niet schrijven. Ik voel me niet voldoende thuis op dit terrein. Sijtze Reurich (overleg) 31 jan 2019 11:51 (CET)

Voor al dit soort "wensonderwerpen" is er eigenlijk de Wikipedia:Hotlist gewenste artikelen, maar daar lijkt tegenwoordig nauwelijks nog enige belangstelling voor te zijn. De Wikischim (overleg) 31 jan 2019 11:57 (CET)

Eens met Carol dat het verbergen van de bewerkingssamenvatting een te overwegen optie is in deze gevallen. Dat heb ik voor de nieuwste twee gedaan, bij de derde zie ik daar geen reden voor. Ook eens met Sijtze Reurich dat een artikel over dit regelmatig in het nieuws zijnde onderwerp op zijn plaats is. Met vriendelijke groet, RonnieV (overleg) 31 jan 2019 12:08 (CET)

De gemiddelde lezer komt niet eens op deze manier op Wikipedia terecht, deze komt namelijk binnen via Google. Schade lijkt mij beperkt. Sjoerd de Bruin (overleg) 31 jan 2019 20:41 (CET)

De gemiddelde lezer zal ook niet aan het vieze stinktafeltje achterin de hoek van het restaurant gaan zitten, dat lijkt me geen reden, daar niets aan te doen. Mensen die een nieuw artikel willen opstarten, worden door dit soort onnodige onzin vaak hiervan weerhouden, althans, dat is een vermoeden gebaseerd op de ervaringen van ondergetekende. Carol (overleg) 2 feb 2019 13:11 (CET)