Overleg gebruiker:Jay D. Easy

Bewerkingen in de sjabloonruimte

Hoi Jay D. Easy,

Ik zie dat je de laatste tijd best wel wat bewerkingen in de sjabloonnaamruimte hebt gedaan.

Je hebt een Br gescheiden items aangemaakt, waarmee een aantal apart opgegeven waarden over verschillende regels verdeeld kunnen worden. Ik zie daar op zich best het nut van in, bijvoorbeeld bij het vertonen van de verenigingen voor welke een sporter is uitgekomen. In de documentatie ontbreekt uitleg over het maximale aantal parameters dat kan worden opgegeven (ook als dat schijnbaar onbeperkt is, is het goed om dat te documenteren).

Waar dit sjabloon minder goed tot zijn recht komt, is bij de infoboxen van personen. Het scheidingsteken dat gebruikt wordt in sjablonen (de pijplijn) botst in dit geval met het teken dat in condities gebruikt wordt (eveneens een pipeline). Hierdoor gaat er onder meer in een aantal sjablonen wat fout met de overlijdensdatum van personen (misschien heb je het niet voldoende getest?). Daarnaast is het natuurlijk een persoonlijke voorkeur of je de gegevens wil zien als:

Geboren: 13 mei 1945
Amsterdam, Nederland

Of als:

Geboren op: 13 mei 1945
Geboren in: Amsterdam, Nederland

Een wijziging in een sjabloon kan in heel veel pagina's doorwerken. Het is dan ook zeker aan te bevelen om, voordat je dit soort wijzigingen doorvoert, overleg met de gemeenschap te voeren.

Een tweede puntje is dat je geheel onnodig doorverwijzingen en korte namen introduceert. Als je een sjabloon als Begin- en einddatum maakt, is het normaal om in de documentatie van die functie gebruik te maken van de betreffende sjabloonnaam. Het aanmaken van Sjabloon:beed, enkel als doorverwijzing daarheen, is niet nodig. Dat geldt ook voor sjablonen als Jmd, Dat en Nowr.

Het sjabloon Huidig seizoen motorsport, door jou ook beschikbaar gesteld als hsm is inhoudelijk fout. Daarnaast denk ik dat heel veel gebruikers niet gecharmeerd zijn van de afbeelding die, opduikt bij gebruik van dit sjabloon, zoals Formule 1 (onderin de infobox).

Tot slot nog een opmerking: we zitten op de Nederlandse Wikipedia. De namen van artikelen hier zijn waar mogelijk in het Nederlands. Probeer te voorkomen dat je allerlei Engelstalige termen als naam van sjablonen gaat introduceren, dat is helemaal niet nodig. Met vriendelijke groet, RonnieV (overleg) 26 feb 2019 16:40 (CET)

Nog even terugkomen op het sjabloon Huidig seizoen motorsport, dit sjabloon maakt totaal zijn naam niet waar. Het enige dat dit sjabloon doet, is de afbeelding ergens neerzetten. Met vriendelijke groet, RonnieV (overleg) 26 feb 2019 16:55 (CET)

Hey Ronnie, thanks dat je me even op deze manier benadert. Ik zal per onderdeel reageren.

In de documentatie ontbreekt uitleg over het maximale aantal parameters dat kan worden opgegeven (ook als dat schijnbaar onbeperkt is, is het goed om dat te documenteren).

Ben ik met je eens. Ik zal één dezer dagen de documentatie uitwerken.

Waar dit sjabloon minder goed tot zijn recht komt, is bij de infoboxen van personen.

Ben ik niet helemaal met je eens, maar dat komt inderdaad aan op voorkeur. Het tweede voorbeeld dat je geeft is dan ook waar mijn voorkeur naar uitgaat. Waarom gebruiken we twee labels voor iets dat met één label gezegd kan worden? Een consensus-peiling vooraf was misschien op z'n plaats geweest, klopt. Veel kans van slagen geef ik dat echter nooit, aangezien voor mijn gevoel nlwiki weigert om mee te gaan op gebied van vernieuwing en men vaak krampachtig vast blijft houden aan de status quo — althans, vanuit mijn beleving.

Een tweede puntje is dat je geheel onnodig doorverwijzingen en korte namen introduceert.

Ook niet helemaal mee eens. Het is misschien niet nodig, maar ik ben een voorstander van schone, duidelijke en beknopte code. Het gemak van sjabloon shortcuts dragen hier aan bij. Ieder die een sjabloon wil oproepen door deze voluit te schrijven kan dat uiteraard ook gewoon doen.

... is het normaal om in de documentatie van die functie gebruik te maken van de betreffende sjabloonnaam.

Yes, komt in orde.

hsm is inhoudelijk fout.

Wat klopt er niet?

Daarnaast denk ik dat heel veel gebruikers niet gecharmeerd zijn van de afbeelding die, opduikt bij gebruik van dit sjabloon, zoals Formule 1.

Formule 1&diff=next&oldid=53258120

Probeer te voorkomen dat je allerlei Engelstalige termen als naam van sjablonen gaat introduceren

Puur omdat ik wel vaker artikelen of gedeeltes van artikelen tegenkom die van de Engelstalige Wikipedia gelift zijn. Het zijn (als het goed is) slechts redirects en alternatieven, opdat de sjablooncode op z'n minst werkt wanneer iets gelift wordt. Mijn voorkeur gaat ook uit naar vernederlandsing.

Met vriendelijke groet, Jay D. Easy (overleg) 26 feb 2019 17:24 (CET)

Hey Jay D. Easy, Vaak werkt een persoonlijke overlegpagina uitstekend, zeker als je (zoals ik nu deed) iets algemener op zaken wil ingaan.

De infobox over personen

Het klopt dat je soms een beetje doortastend moet zijn om iets in beweging te krijgen. En soms is VJVEGJG ook een heel goed uitgangspunt. Maar, zoals je (hopelijk) bekend is, werkt een verandering in een sjabloon als infobox acteur direct door in heel veel pagina's. Dat betekent dat je heel goed moet weten wat je doet. Dat ging volgens mij op twee punten fout:

• De steun van de gemeenschap voor de gewijzigde opmaak ontbreekt: niet iedereen vindt het logisch dat achter 'geboren' een of meer van de volgende gegevens komen te staan: geboortenaam, geboortedatum, geboorteplaats. Ik kan me daar wel iets bij voorstellen, we presteren deze gegevens normaliter als drie afzonderlijke entiteiten, en dat zijn het ook. Je had kunnen overwegen om het voorstel daarna aan de gemeenschap voor te leggen
• Met {{br gescheiden items|{{{overleden|}}}|{{{overleden|{{{sterfdatum|}}}}}}|{{{overlijdensplaats|{{{sterfplaats|}}}}}}}} zorgde je ervoor dat de overlijdensdatum twee keer getoond werd. Dit had je eenvoudig voor kunnen zijn door je wijziging te testen. Sjabloonpagina's hebben bij het bewerken een speciale optie waarmee je direct het resultaat van je bezigheden in een pagina kan zien. Je had dan vast zelf ook gezien dat de overlijdensdatum (indien ingevuld bij de parameter overleden) twee keer in beeld verschijnt.

Voor minder ingewijde meelezers:

{{br gescheiden items|{{{overleden|}}}|{{{overleden|{{{sterfdatum|}}}}}}|{{{overlijdensplaats|{{{sterfplaats|}}}}}}}}

valt uiteen in

{{br gescheiden items|

{{{overleden|}}}| geeft, als deze ingevuld is, de parameter 'overleden' door, anders niets.

{{{overleden|{{{sterfdatum|}}}}}}| geeft, als deze ingevuld is, de parameter 'overleden' door, anders als de parameter 'sterfdatum' is ingevuld die en anders niets.

{{{overlijdensplaats|{{{sterfplaats|}}}}} geeft, als deze ingevuld is, de parameter 'overlijdensplaats' door, anders als de parameter 'sterfplaats' is ingevuld die en anders niets.

}}}

De parameters 'sterfdatum' en 'sterfplaats' komen niet voor in het originele sjabloon. Het toevoegen is onnodig en brengt mensen ook in verwarring. Bovendien kan het bijeffecten hebben; als er bij iemand 'sterfplaats' was opgegeven, komt die ineens in beeld, terwijl deze parameter voorheen genegeerd werd.

Jouw persoonlijke voorkeur voor schone code zal op weinig weerstand stuiten. 'Beknopt' en 'duidelijk' willen nog wel eens botsen. Waar staat een variabele als 'p' (in de module) voor, waar staat hsm voor, waar staat beed voor. En is 'nowr' nu echt nodig naast 'nowrap'? Of staat het voor 'noordoostwestelijke richting' of 'niet onderweg rommelen'? We werken hier met duizenden vrijwilligers, en daar komen iedere maand weer nieuwe mensen bij. Volledige namen vertellen waar het sjabloon voor staat en voorkomen ook dat je namen 'claimt' om ze daarmee te blokkeren voor dingen die misschien wel veel logischer zijn.

hsm is inhoudelijk fout

Hint: kijk eens naar de betekenis van de eerste letter en van de laatste letter. (Misschien toch handiger om het sjabloon bij de volledige naam te noemen?)

Ik zie dat het sjabloon daar gebruikt wordt om dezelfde afbeelding te laten zien als eerder. Dat had ik inderdaad nog niet gezien. En uit de geschiedenis blijkt dat die afbeelding, met flink meer dan de normale regelhoogte, er al langer staat. Trek ik dat punt in.

Engelse namen: Flatlist kwam je net zelf tegen. If empty, Sdash en Endplainlist (alsmede Eindeplainlist) zijn niet echt Nederlands.

En over Sdash, het gebruik ervan in de niet-sorteerbare puntentabel van de F1 komt over als een vlag op een modderschuit. Je voegt code toe in de code van de pagina, nog veel in de getoonde pagina, en het verlengt een streepje? Of zie ik iets over het hoofd?

Ander puntje: ik weet dat de visuele editor alleen ingevulde parameters opslaat. Ik vind dat zelf, als 'klassieke' bewerker, een groot verlies. Ik moet dan gaan nadenken of ik bij het overlijden van iemand voor 'sterfdatum' of 'overlijdensdatum' of 'overleden' of ... moet gaan. Dat hoeft niet als die veldnamen gewoon behouden blijven. Met vriendelijke groet, RonnieV (overleg) 26 feb 2019 19:10 (CET)

Hey Ronnie, thanks voor je reply.

Dat betekent dat je heel goed moet weten wat je doet.

Uiteraard. Over het algemeen weet ik wat ik doe. Dat het in {{infobox acteur}} even fout ging is gewoon te wijten aan gebrek aan concentratie en onoplettendheid van mijn kant. Bij dezen ook excuses dat ik m'n kop er even niet bij had. Bekijk bijvoorbeeld de bron van infobox militair persoon – werkt perfect.

Niet iedereen vindt het logisch dat achter geboren [...]

De verandering mag dan zonder consensus zijn gedaan, maar wat je zegt klopt niet. Je presenteert een aanname als feit. Feit is dat de Engelstalige Wikipedia birth_name, birth_date, birth_place bij Infobox person tot dusver nog steeds onder hetzelfde label schaart zonder dat er verwarring onstaat (of ik moet beter zoeken). Een snelle zoekopdracht in de discussiearchieven toont dat sommigen zo nu en dan liever zien dat birth_name een apart label krijgt, maar vooralsnog lijkt in die gevallen het voorkomen van potentiële verwarring niet de motivatie te zijn. Het is naar mijn mening dan ook een veilige constatering dat het plaatsen van geboortedatum en geboorteplaats (en sterf-) onder elkaar bij hetzelfde label ook op de Nederlandstalige Wikipedia niet tot verwarring zal moeten leiden, gezien het feit dit in de praktijk op de Engelstalige Wikipedia daar evenmin voor zorgt. En hoewel de Nederlandsetalige Wikipedia niet de Engelstalige Wikipedia is (en terecht), is er qua denkwijze onder Nederlands- en Engelstaligen weinig verschil, hetgeen mij versterkt in mijn gevoel dat dit nou niet bepaald onduidelijkheden met zich mee zal brengen.

De parameters 'sterfdatum' en 'sterfplaats' komen niet voor in het originele sjabloon

Dat klopt. Wat juist wél voor verwarring zorgt zijn geboren en gestorven, omdat de functie van deze vrij te interpreteren is. Geboorte- en sterfdatum en geboorte- en sterfplaats zijn juist bedoelt om deze verwarring aan banden te leggen. Enkele voorbeelden: Ron Livingston maakt slechts gebruik van geboren voor zowel de geboortedatum als geboorteplaats. Dit zorgt an sich niet voor heel veel verwarring in de sjabloon output, maar stemt wel voort uit onjuist gebruik – voortkomend uit verwarring – van de parameter(s). Soledad Miranda en Jesús Franco doen het net andersom, met eerst de geboorteplaats en daarna de geboortedatum. Wat ook opvalt bij deze drie voorbeelden is dat allen slechts de plaatsnaam tonen; vermoedelijk om ruimte te besparen? Het liefst zou je ook de staat of provincie en als het even kan ook het land – zonder onnodige link, natuurlijk – hier willen tonen, aangezien ik veronderstel dat de info in infobox toch ergens voor staat. Nog twee voorbeelden: Tom Hanks komt uit het land Concord, Californië en Damian Lewis komt uit het land St John's Wood, Westminster. Ik veronderstel dat ook deze fouten voortkomen uit verwarring over het gebruik van de op dit moment beschikbare parameters.

Als er bij iemand 'sterfplaats' was opgegeven, komt die ineens in beeld, terwijl deze parameter voorheen genegeerd werd

Als ik je goed begrijp ben je in de veronderstelling dat ik een nieuw label had gemaakt met "Sterfplaats"? Dat is niet zo. Het enige dat ik aan de labels heb aangepast is alle drie (of zes, eigenlijk) de data parameters respectievelijk onder de "Geboren" of "Overleden" scharen. sterfplaats fungeerde slechts als alternatief voor de langere overlijdensplaats parameter. Hoewel het inderaad misschien niet geheel nodig was, zie ik geen probleem met het aanbieden van een korter alternatief. Bovendien, wanneer een alternatief als {{{overlijdensplaats|{{{sterfplaats|}}}}}} wordt aangeboden, en zowel overlijdensplaats als sterfplaats in de sjabloon gebruikt worden, dan zal alsnog alleen overlijdensplaats zichtbaar zijn, omdat deze voorrang heeft op sterfplaats. Kort gezegd, wanneer men in de praktijk op wonderbaarlijke wijze toch in de veronderstelling is dat beide parameters gebruikt moeten worden – hoewel ik het me niet kan voorstellen – dan leidt dit niet tot een infobox met twee sterfplaatsen. Zorgen om niks, dus.

Beknopt en duidelijk willen nog wel eens botsen

Dat ziet ik niet direct als probleem. Zo zijn er meer afkortingen voor termen of namen die wellicht ook vragen oproepen wanneer men ze voor het eerst ziet. Dat zal iedereen wel eens meemaken. Je doet het immers net zelf nog met VJVEGJG. Geen idee waar het voor stond, dus heb ik het opgezocht. Het is te begrijpen dat je het liefst nieuwelingen een hand boven het hoofd zou willen houden, en een sjabloon oproepen door deze voluit te schrijven is misschien één manier om dat te doen. Anderzijds heeft het denk ik weinig invloed op iemand's kennis van een sjabloon en hoe deze fungeert. Het gebruik van de meeste sjablonen spreekt immers voor zich wanneer wanneer de pagina bron wordt blootgelegd. De functie van een sjabloon als {{hsm}} is uit de afkorting dan misschien niet meteen duidelijk, maar dat zou vrij snel duidelijk moeten zijn als je bekijkt dat het voor [[Formule 1 in {{CURRENTYEAR}} staat en je vervolgens ziet dat in de infobox op de pagina zelf een afbeelding van een helmpje zichtbaar is voor die link. Wanneer Sjabloon:hsm wordt opgezocht zal het bovendien ook snel duidelijk moeten zijn (mits ik de documentatie nog uitwerk, haha).

Dat je namen 'claimt' om ze daarmee te blokkeren voor dingen die misschien wel veel logischer zijn

Yes, dat zou kunnen gebeuren. Maar hoe vaak is dat tot nu toe voorgekomen? Ik heb het gevoel dat het al voor een langere tijd behoorlijk gestagneerd is op het gebied van vernieuwing en opmaak op de Nederlandstalige Wikipedia (onder andere door de valkuil die BTNI heet) en verwacht dan ook niet dat er maandelijks zoveel sjablonen bij komen dat er een schaarste op drieletterige afkortingen heerst.

Hint: kijk eens naar de betekenis van de eerste letter en van de laatste letter (hsm)

Huidig seizoen Motorsport? Ik volg je nog steeds niet, sorry.

Engelse namen

Hoewel ik zoals eerder gezegd over het algemeen ook pleit voor vernederlandsing, doel ik voornamelijk op wat er voor de doorsnee lezer zichtbaar is. Ik vind dan ook dat we niet te moeilijk moeten doen over de namen van hulpmiddelen die we onder de motorkap gebruiken. Sjablonen worden nu éénmaal van de Engelstalige Wikipedia gelift – zeker door mij, maar dat mocht duidelijk zijn. Het goed laten functioneren van een sjabloon staat voorop. Het vertalen van eventuele output volgt snel daarop. Indien gewenst kunnen sommige sjablonen daarna hernoemd worden. Ik ben bijvoorbeeld niet van plan om {{if empty}} een andere naam te geven – het spreekt voor zich dat het een parserfunctie in een sjabloonjasje betreft. {{sdash}} kan eventueel hernoemd worden (naar sterke kastlijn?—brrr) en {{endplainlist}} is het tot voorkort ontbrekende alternatief dat gebruikt kan worden om {{plainlist}} te sluiten.

En over Sdash [...] Of zie ik iets over het hoofd?

Nee, je slaat de spijker op z'n kop. Excuses, ik begrijp ook niet echt welk punt je wilt maken.

Ander puntje [...] nadenken of ik [voor] 'sterfdatum' of 'overlijdensdatum' of 'overleden' of ... moet gaan

Zoals eerder besproken houdt dit argument geen steek, aangezien overleden nooit is verdwenen. (Overigens begrijp ik dat je overlijdensplaats bedoelt in plaats van overlijdensdatum, want deze heeft tot dusver nooit bestaan.) Kijk voor de grap even met me mee naar de volgende voorbeelden:

Jay D. Easy
Algemene informatie
Geboren	Peter Repelsteeltje de Vries Ergns in 't 'noardn
Overleden	Mariana Trench, western Pacific
Land	Nederland
Werk
Jaren actief	Langer dan je denkt

{{Gebruiker:Jay D. Easy/Kladblok/vb
 |naam              = Jay D. Easy
 |geboortenaam      = Peter Repelsteeltje de Vries
 |geboren           = <!--{{datum|-1|12|25}}-->
 |geboortedatum     = Wordt nu niet getoond
 |geboorteplaats    = Ergns in 't 'noardn
 |overleden         = <!--{{datum|2019|02|27}}-->
 |sterfdatum        = Wordt nu niet getoond
 |overlijdensplaats = Mariana Trench, western Pacific
 |sterfplaats       = Wordt nu niet getoond
 |land              = Nederland
 |jaren-actief      = Langer dan je denkt
}}

Hoe mooi het had kunnen zijn.

Jay D. Easy
Algemene informatie
Geboren	Peter Repelsteeltje de Vries Ergns in 't 'noardn
Overleden	Mariana Trench, western Pacific
Land	Nederland
Werk
Jaren actief	Langer dan je denkt

{{Gebruiker:Jay D. Easy/Kladblok/vb
 |naam              = Jay D. Easy
 |geboortenaam      = Peter Repelsteeltje de Vries
 |geboortedatum     = <!--{{datum|-1|12|25}}-->
 |geboorteplaats    = Ergns in 't 'noardn
 |sterfdatum        = <!--{{datum|2019|02|27}}-->
 |sterfplaats       = Mariana Trench, western Pacific
 |land              = Nederland
 |jaren-actief      = Langer dan je denkt
}}

Zie vervolgens het betreffende gedeelte van de sjablooncode.

 |head1_2 = Geboren
 |item1_2 = {{br gescheiden items|{{{geboortenaam|}}}|{{{geboren|{{{geboortedatum|}}}}}}|{{{geboorteplaats|}}}}}
 |head1_3 = Overleden
 |item1_3 = {{br gescheiden items|{{{overleden|{{{sterfdatum|}}}}}}|{{{overlijdensplaats|{{{sterfplaats|}}}}}}}}

En zie ten slotte hoe alle oude vertrouwde parameters hieronder daarboven zijn opgenomen (en voorrang hebben op alternatieven).

| head1_2 = Geboortenaam      | item1_2 = {{{geboortenaam|}}}
| head1_3 = Geboren           | item1_3 = {{{geboren|}}}
| head1_4 = Geboorteplaats    | item1_4 = {{{geboorteplaats|}}}
| head1_5 = Overleden         | item1_5 = {{{overleden|}}}
| head1_6 = Overlijdensplaats | item1_6 = {{{overlijdensplaats|}}}

Tevens excuses voor m'n ietwat uitgebreide reply, haha. Ik hoor graag van je terug. Jay D. Easy (overleg) 28 feb 2019 00:51 (CET)

• Ping @RonnieV: Jay D. Easy (overleg) 3 mrt 2019 02:10 (CET)

Sterfdatum en leeftijd sjabloon

Inzake lemma Tede Beets: Als het tonen van de leeftijd in een infobox niet wenselijk is, pas dan het sjabloon aan. Indien dat in veel lemma's voor een probleem zou zorgen, vraag dan of iemand er een script in kan plaatsen. Op zijn minst kan je toch de toelichting bij het sjabloon aanpassen? Groet, oSeveno (overleg) 2 mrt 2019 20:10 (CET)

Ik heb het sjabloon inmiddels al laten verwijderen. Daarnaast begrijp ik ook niet hoe het volgens jou aangepast had moeten worden. Wat voor script heb je het over? Het sjabloon zelf was immers al een script. Bovendien lijkt mij het gebruik van een sjabloon genaamd sterfdatum en leeftijd zonder vertoning van leeftijd nogal loos. Dan kan je {{datum}} beter gebruiken. Jay D. Easy (overleg) 3 mrt 2019 02:06 (CET)

Dat is ook prima. Bedankt. oSeveno (overleg) 5 mrt 2019 12:02 (CET)

@OSeveno: mocht het nog niet duidelijk zijn, ik verwijs naar Wikipedia:Stemlokaal/Leeftijd weergeven in infoboxen. Ik heb het sjabloon wel bewaard, mocht de conventie ooit aangepast worden. Met vriendelijke groet, Jay D. Easy (overleg) 5 mrt 2019 14:16 (CET)

Geboorteplaats Lodewijk van Heiden

Hoewel er (verouderde) bronnen zijn die Zuidlaren als zijn geboorteplaats noemen wordt door Nederlands Instituut voor Kunstgeschiedenis in navolging van andere publicaties Den Haag als zijn geboorteplaats genoemd. Dat correspondeert ook met zijn doop, die eveneens in Den Haag plaatsvond in de Waalsche Kerk aldaar (zie doopboek). Het één en ander was al met een noot toegelicht, waarbij tevens de oude vermelding van Zuidlaren werd genoemd. Met vr. groet Gouwenaar (overleg) 8 jan 2022 22:12 (CET)