Wikipedia:Redactielokaal

Uit Wikipedia, de vrije encyclopedie
Naar navigatie springen Naar zoeken springen

Sedert 3 maart 2011

Overzicht beheerpagina's
Zie WP:rl


Inhoud | Archief | Naar onder | Een nieuw onderwerp toevoegen

Welkom in Redactielokaal De Burelen,
In dit werklokaal kunnen alle zaken besproken worden die handelen over de redactie van encyclopedische artikelen.
Handig hulpmiddel:
Taaladvies van de Nederlandse Taalunie


Plaats en/of volgorde verschillende sjablonen[bewerken]

Goedendag,

Omdat ik het in het hulportaal niet boven water kreeg, stel ik de vraag hier maar:

Is er een zekere conventie (geschreven of ongeschreven) voor de plaats en volgorde van sjablonen als:

  1. {{Wiktionary}}
  2. {{Wikt klein}}
  3. {{Commonscat}}
  4. {{Commonscatklein}}
  5. {{Link portaal}}
  6. {{Navigatie}} (en verwante sjablonen, die som relatief veel ruimte kunnen innemen, zeker wanneer er meerdere onder elkaar staat die allen van toepassing zijn)
  7. {{DEFAULTSORT}}
  8. {{Coor title dms}}
    • Met name ten opzichte van het sjabloon:
  9. {{Appendix}}


  • Op DP-pagina's zet ik het {{Wikt klein}} sjabloon nog wel eens bovenaan/bovenin het artikel, waar in de regel rechtsbovenin voldoende ruimte is/in de praktijk in DP-pagina's een groot onbenut witvlak staat;
  • Eén of meerdere {{Link portaal}}-sjablonen neem ik (wanneer er geen infobox in het artikel staat, of de infobox niet genoeg velden biedt voor alle van toepassing zijnde portalen) die wel eens op binnen het {{Appendix}}-sjabloon omdat het er dan (zeker bij meer dan één portaal-link rustiger uitziet dan buiten het Appendix-frame.
    • (Hetzelfde doe ik soms voor een enkele {{commonscatklein}}) en het {{Wikt klein}}-sjabloon (wanneer het een niet-DP pagina betreft), die ik dan ook 'binnen het kader van de appendix' plaats.
  • Bij het vergelijken van verschillende artikelen waarin navigatie- en commonscat-sjablonen worden gebruikt, wisselt het in de huidige praktijk per artikel sterk of die bóven of ónder het {{Appendix}}-sjabloon zijn opgenpomen.
    • Zelf zet ik vrijwel zonder uitzondering het {{Appendix}}-sjabloon altijd als eerste sjabloon onder de laatste zin(nen) van de lopende tekst of onder het allerlaatste (externe links-/literatuur-/publicatie-)kopje dat in het artikel staat/dat tot de inhoud van het artikel behoort; d.i. eigenlijk analoog als wanneer niet gekozen is voor een appendix, maar voor een kopje == [Bronnen en] Referenties == waar alle bronnen, noten en referenties met het {{References}}-sjabloon worden opgenomen, zodat alle andere sjablonen (navigatie en commonscat) er (zo vermoed ik) eigenlijk onder horen.

Maar met deze beredenering (die natuurlijk onjuist kan zijn, of simpelweg niet rijmt met conventies of goed gebruik), is de volgorde van de andere sjablonen ook nog niet vastgesteld. Het gaat hier uiteraard om sjablonen die visueel in het artikel worden getoond, en ook in de volgorde waarin ze in de wiki-brontekst zijn opgenomen; voor sjablonen (zoals "DEFAULTSORT") en categorie-links die qua volgorde visueel niet terug te vinden zijn of hun plek geen effect hebben hoe het in het artikel wordt weergegeven (maar effect hebben op andere lijsten en (categorie)navigatiepagina's) maakt het uiteraard niet uit en worden i.h.a. naar goed gebruik helemaal onder alle sjablonen, links en tags gezien die wel een effect op de gegenereerde artikel-tekst, -volgorde en -opmaak hebben.

  • Vermocht er ergens gewoon een een conventie of handvest hiervoor beschreven zijn/bestaan, dat verneem ik graag (een wikilinksje naar) waar dat beschreven staat.
  • Indien er ongeschreven richtlijnen/conventies zijn die om verschillende redenen (en/of logica, of historisch zo gegroeid zijn) in de praktijk het beste werken, dat laat ik me die ook graag uitleggen.

Alvast bedankt voor enige toelichting en vriendelijke groeten, -- martix (overleg) 13 jan 2019 17:36 (CET)

Schematisch overzicht van de
volgorde van onderdelen in een artikel
  Inleiding
 
  Hoofdtekst
 
 
 
  Zie ook
  Externe links
  Bronvermelding - Voetnoten - Referenties
  Opvolgingssjabloon
  Navigatiesjabloon
  Sjablonen voor links naar andere Wikimedia-projecten
  Categorieën
Een conventie? Het staat inderdaad een beetje op Wikipedia:Conventies (de afbeelding met "schematisch overzicht van ..." en onderaan bij "Gebruik van sjablonen"). Ze staan er wel niet allemaal. Ook staat er af en toe op de sjabloonpagina zelf waar het hoort te staan (bv. Sjabloon:Zie_artikel#Doel). Ik verwijs nu vooral naar de afbeelding (allez in feite is het een sjabloon, maar het lijkt wat op een afbeelding) op WP:C. Ik zet het ook even hier rechts. Het sjabloon Appendix (9) valt onder bronvermelding. Navigatiesjablonen (6) staan er ook. De sjablonen 1-4 vallen onder "sjablonen voor links naar andere Wikimedia-projecten". Dan blijft nog 5,7,8 over die daar niet expliciet staan. Daar zijn bij mijn weten geen expliciete conventies over. Defaultsort (7) staat bij mijn weten gewoonlijk vlak boven de cats (die helemaal onderaan staan, ook conform de conventies). Link portaal (5) staat bij mijn weten ofwel rechtsbovenaan in het artikel ofwel rechtsonderaan bij externe links (ook vrij gebruikelijk op en.wiki dacht ik) of in de appendix. Je hebt ook portaallinks in de infobox. Coor title dms (8) heeft geen vaste plaats bij mijn weten. Staat wel gewoonlijk onderaan (wel boven de cats, zie ook de sjabloonpagina) , maar de volgorde hangt ervan af. Ik denk dat gewoonlijk tussen "links naar andere wikimediaprojecten" (commonscat, zusterproject,...) en DEFAULTSORT staat, maar daar twijfel ik wat over. Nu ja, de plaats van coor title dms is wat minder relevant aangezien het niet zichtbaar is op de plaats waar je het zet, maar gewoon rechtsboven in het artikel. Bij appendix en commonscat is de volgorde die je gebruikt, wel zichtbaar op het artikel.Mvg, Flag of Belgium (civil).svg TheDragonhunter | Vragen? 13 jan 2019 19:15 (CET)
@TheDragonhunter: Ah, dat schemaatje was ik (zelf zoeken en navigatie ten spijt, dus) nog niet tegengekomen, en is zowel beknopt (in tegenstelling tot mijn uitvoere vraagstelling) als bijzonder verhelderend (waarvoor dank); het gros van de vragen is ermee beantwoord en biedt me nu houvast voor eigen artikelen. Maar ik kom ook geregeld artikelen tegen waar bijvoorbeeld de navigatie- (en opvolgingssjablonen – die laatste beschouw ik eigenlijk als een variant-navigatiesjabloon – boven de {{Appendix}} staan. Ik weet nu dat ik die dus gewoon kan verhuizen naar onder de appendix, zonder dat ik daarmee een 'BTNI-overteding' bega. Nogmaals dank -- martix (overleg) 13 jan 2019 20:43 (CET)
Allen, @TheDragonhunter: zoals ik het zelf ook interpreteerde, lijk je/lijkt men 'commons' en daarmee het {{Commonscat}}-sjabloon bij/onder de zusterprojecten te te scharen. Daar is echter (ook bij mij) wel verwarring en onduidelijkheid over, en daardoor de vervolgvraag om bevestiging of duiding daarover. Of liever nog, dat het commonscat-sjabloon expliciet in het blokschema wordt opgenomen. Want omdat in "Commonscat" het woord(deel) "cat[egorie]" feitelijk letterlijk in de sjabloon-naam terugkomt, kan dat ook leiden tot de conclusie dat het (dus helemaal) onderin bij de categorieën geschaard dient te worden (ik meen dat het parsen van wiki-brontekst alle categorie-links – ongeacht waar die in het artikel staan – hoe dan ook onderaan in het artikel komen, in volgorde waarin ze in de brontekst staan. In het geval dat commonscat een 'categorie' is, komt het daarmee helemaal onderaan, maar nog wel net boven de categorielinks).
In het hierboven gelinkte overleg met Antoine.01 is ook (door mij) geopperd dat de aard van het artikel mogelijk ook een factor kan zijn in 'het gewicht/het belang (en daarmee de plaats)' van de commonscat waardoor het wellicht afhankelijk van het artikelonderwerp wenselijker is om het hoger dan wel lager te plaatsen, (wellicht te bepalen door een stroomdiagram, of door uitzonderingen op de regel).
Ten slotte (wanneer eenduidigheid is bereikt, of misschien wel voordat daartoe wordt overgegaan) is m.i. ook het inschatten van hoe belangrijk de plek van het commonscat-sjabloon is (op zich is een niet-ambigue/niet-ambivalente eenduidigheid, consistentie en uniformiteit binnen een artikel, en vervolgens tussen artikelen onderling wel (erg) belangrijk, maar we moeten natuurlijk niet verzanden in een extreem fijnmazig systeem over heel veel details); wat ik daarmee bedoel is, zijn dingen die wanneer ze niet (strikt) aan het bovenstaande blokschema voldoen, ook wenselijk om (massaal en/of door scripts/robots [als enige wijziging]) 'verbeterd mogen worden' (dus mag er 'op gejaagd worden' en is de verkeerde of een onconventionele plek van een sjabloon alléén al voldoende grond om het conform conventies te maken, of is het een 'correctie' die alleen gedaan hoeft te worden als het artikel om andere redenen toch al bewerkt moet worden? Groeten -- martix (overleg) 19 feb 2019 01:37 (CET)
Je vroeg hierboven eerder of er een conventie is voor deze sjablonen. Daar had ik je op gewezen. Dit aspect heb ik inderdaad niet toegelicht, maar staat toch vermeld op WP:C. Het heeft ook wat te maken met de "cultuur" op nlwiki. WP:C is eigenlijk gewoon de standaardopmaak voor een Wikipedia-artikel. Het is een richtlijn, maar er staat wel niet het sjabloon van een richtlijn boven (zoals boven WP:BENOEM, De tekst is algemeen aanvaard onder gebruikers en het is de bedoeling dat iedereen zich eraan houdt...). In de plaats ervan staat er bovenaan een soort verwijzing naar VJVEGJG (nu ja, soort herinnering, maar toch zegt die zin dat er bepaalde conventies zijn waar je aan moet voldoen). Vervolgens staat er nogmaals in de inleiding: Onderstaande conventies zijn weliswaar geen wetten van Meden en Perzen, maar... Het is naar mijn mening dus niet een richtlijn die je zo strikt moet volgen als WP:GOO ofzo. WP:C is voor een standaardopmaak ook vrij beknopt. Je zou kunnen zeggen dat zo'n beknopte standaardopmaak, die verwijzing naar VJVEGJG (+ dat van geen wetten van Meden en Perzen) nog redelijk wat ruimte openlaat voor een persoonlijke voorkeur. Echter was er in het verleden een gebruiker die wat te ver ging met overal dingen in zijn/haar persoonlijke voorkeur te wijzigen wat leidde tot de richtlijn BTNI. Nu ja, als je zoveel persoonlijke voorkeur toelaat, is zoiets als BTNI soms wel nodig. BTNI-politie moet je er maar bij pakken. Op enwiki bestaat BTNI niet. Zij hebben daar nu eenmaal geen nood aan. De pagina die wij WP:C noemen, is daar veel uitgebreider (ook meerdere pagina's trouwens) en heet WP:MoS. Hierdoor is er veel minder ruimte voor een persoonlijke voorkeur en is zoiets als BTNI niet nodig. De MoS-politie moet je er dan wel bij pakken. Zelf vind ik de situatie op nlwiki prettiger. 1 van de nadelen daarvan zijn echter wel zulke situaties (deze discussie bv).
Dat schemaatje dat ik hierboven zette (uit WP:C), wordt gewoonlijk wel min of meer gevolgd (het schema komt ook voor een groot deel overeen met de tekst van WP:C zelf). Enkel die donkergrijze blok (Bronvermelding - sjablonen voor zusterprojecten) wordt regelmatig niet gevolgd. Of dat zo erg is? De inleiding van WP:C (zie ook eerder) vind ik wat dat betreft duidelijk genoeg. Zoveel kwaad kan het niet. Er is wel een regel voor, maar die hoeft in dit geval niet per se zo strikt gevolgd te worden. Wat betreft commonscat, op WP:C staat ook een alinea over categorieën en een vermelding in vet dat ze onderaan staan. Uit de context aldaar blijkt naar mijn mening wel dat het niet om commonscat gaat. Er staat ook letterlijk in het schema "sjablonen voor links naar andere Wikimedia-projecten". Commonscat is een sjabloon dat verwijst naar een ander Wikimedia-project. Het is ook (voor zover ik het tegenkom) het meestgebruikte sjabloon voor links naar andere Wikimedia-projecten (ik zie op de meeste artikelen die ik lees, wel een commonscat, maar als je vergelijkt met wikiquote,wikibooks,...). Soms gebruik ik wel {{Zusterproject}} om meerdere van zulke sjablonen op 1 pagina samen te voegen. Op dat sjabloon staat trouwens ook "Op andere Wikimedia-projecten:" en een lijstje. Er zijn er meer (zie ook {{Zusterprojecten}}, maar naar die anderen linken we niet zoals wikidata, meta en incubator.Mvg, Flag of Belgium (civil).svg TheDragonhunter | Vragen? 19 feb 2019 21:07 (CET)
TheDragonhunter: Dank voor je nadere toelichting; ik neem het ter kennisgeving aan en zal dan ook niet meer sleutelen aan volgordes van de sjablonen (in beginsel deed ik het zo en zo – een (m.i. gerechtvaardoigde) uitzondering daargelaten[sjabloonvolgorde 1] – niet als enige bewerking op een artikel). Ik gebruik vanaf nu het stramien/het blokschema bij het schrijven van artikelen, en verander (commonscat- en/of andere) sjablonen voortaan alleen wanneer ze in een artikel afwijken van de gehanteerde volgorde in vergelijkbare artikelen (zoals bij burgemeesters, ministers, enzovoorts), ongeacht of die volgorde dan wel of niet rijmt met de conventie. Een stramien om te volgen ervaar ik zelf als een fijne houvast (zelfs als het een richtlijn/conventie is die niet mijn voorkeur zou hebben), want 'eenduidigheid gaat voor eenvoud (en andere argumenten). Wel vind ik het (persoonlijk) een beetje gek dat daardoor de situatie ontstaat/is ontstaan dat een bewerking van een bestaand artikel waardoor het het artikel (meer) met de conventies overeenkomt, dan als een onwenselijke bewerking kan worden beschouwd. Het sop is me echter de kool niet waard om daar verhit over te discussiëren; die tijd en energie steek ik liever in het maken van onomstreden bewerkingen en schrijven van nieuwe artikelen (en ik hoop dat anderen dat ook vinden), en neem het aldus ter kennisgeving aan; want ook ik zie wel in dat in sommige artikelen over bepaalde onderwerpen of thema's, een andere volgorde wenselijker kan zijn.[sjabloonvolgorde 2]. Eventueel verdere toelichtingen, die niet hier in het "Redactielokaal" breed gevoerd hoeven te worden, kan eventueel beter buiten het spotlicht hier op mijn OP plaatsvinden. Dank voor de toelichting en m.v.g. -- martix (overleg) 2 mrt 2019 23:58 (CET)
Noten en referenties bij Plaats en/of volgorde verschillende sjablonen
  1. (Dit betrof het herstellen van een volgordewijziging die aanvankelijk wel, maar na de bewerking ervoor niet meer in de conventie-volgorde stond).
  2. '"En bijvoorbeeld een sjabloon als {{Wikt klein}} op DP-pagina's gemakkelijk in de lege ruimte rechtsboven in de pagina past – en mogelijk daar zelfs wenselijker is.

Maja de Bij, maar daarnaast geen verwante artikelen die er eigenlijk zouden moeten zijn[bewerken]

Er is een (bronloos) artikel over de bij Maja, maar in werkelijkheid is het juist de vraag of een artikel als dit per se wenselijk is. In plaats daarvan zou er natuurlijk een artikel moeten komen over de schrijver, over het oorspronkelijke boek, en ten slotte over de animatieserie die later werd gemaakt. Alle drie hebben momenteel nog geen eigen artikel. De Wikischim (overleg) 10 feb 2019 18:06 (CET)

VJVEGJG Hans Erren (overleg) 10 feb 2019 21:42 (CET)
(Na bwc:) Dat er alleen (nog) een artikel over de animatieserie is, is op zich niet verwonderlijk; ik ken het zelf (van 35+ jaar geleden) eigenlijk ook alleen maar als (Nederlandse) tekenfilmserie, en verneem vandaag voor het eerst dat het van oorsprong een (Duits) boek is. Het artikel dateert ook uit 2010 toen de bronwens ook minder sterk was (en de bronplicht is er volgens mij formeel ook nog niet). Hoe dan ook, het artikel dat er nu is heeft volgens mij alle bestaansrecht (in huidige vorm, hoewel er zoals altijd bronwensen bestaan), en is mijn opvatting niet dat dit artikel 'ongewenst is omdat er nog geen artikel over het boek en diens auteur is'.
Dat neemt niet weg dat ik met je eens ben dat het wenselijk is om ook (een) artikel(en) in het leven te roepen voor (vooral) de schrijver (alwaar Maja dan in de bibliografie kan prijken). De 'noodzaak' of wens voor een artikel over het boek is er toch een van geringere mate dan van de schrijver (als het boek eenmaal vermeld staat op het artikel over de schrijver). Maar het oproepen/verzoeken tot schrijven van gewenste artikelen lijkt me vooral zinvol op 'WP:Gewenste artikelen', waarbij er dan hier in het redactielokaal de aandacht op gevestigd kan worden – maar dat hoe dan ook t.z.t. weg-gearchiveerd zal worden – maar op de G.A. lijst blijft het staan totdat het is aangemaakt. Of zoals Hans Erren al opmerkt, kun je die ook zelf schrijven of beginnen.
Samengevat: eens met de wens aan artikel over auteur (en eventueel het boek); en t.z.t. kan de titel van het huidige artikel dan worden omgedoopt naar "... (tekenfilmserie)", maar vind niet dat het bestaande artikel nu onwenselijk is (laat staan dat het verwijderd zou moeten worden totdat de artikelen over het boek en de auteur zijn geschreven). Mvg -- martix (overleg) 10 feb 2019 21:54 (CET)
Wikipedia is nooit af. Er zullen altijd wel artikels missen. Die leemte vul je niet op korte tijd op. Overigens 2 animatieseries. De oorspronkelijke animatieserie (traditionele) uit de jaren 70 en die recente computeranimatieserie van Studio 100 van 5-6 jaar geleden. De eerste film heeft overigens wel al een artikel. De tweede die vorig jaar uitkwam (d:Q50049127) nog niet. Misschien is er nog meer. Ik zie op enwiki nog iets van een film uit 1924 en op dewiki nog iets van een stripreeks (als ik het goed begrijp). Daar kan je iets aan doen, maar er is nog genoeg ander werk te doen hier. Er is tenminste al wel een artikel over "Maja de Bij" (helaas bronloos, maar tja).Mvg, Flag of Belgium (civil).svg TheDragonhunter | Vragen? 10 feb 2019 23:29 (CET)
Het artikel gaat zowel over de hoofdfiguur, het boek als de tekenfilmserie. Daar zie ik geen probleem in, het zijn immers duidelijk samenhangende onderwerpen. Het artikel is wel voor verbetering vatbaar: er is nauwelijks een beschrijving van personages (alleen de beginzin en een kritische opmerking over de wijze waarop de bijen zijn afgebeeld) en onderwerp. Ook is de infobox verwarrend omdat deze al rechtsbovenin begint terwijl hij alleen over de tekenfilm gaat. Maar in het algemeen zie ik niet waarom een dergelijk artikel per se opgesplitst zou moeten worden, als dat is wat hier beoogd wordt. Ook verschillende andere taalversies omschrijven Maja de Bij allereerst als personage en bespreken daarna pas de afzonderlijke werken die haar naam dragen. Bever (overleg) 19 mrt 2019 23:05 (CET)

Infobox(en) OV-lijnen en -netten[bewerken]

Allen,

Op zoek naar de mogelijke of volgens richtlijnen te gebruiken sjablonen voor entiteiten als bus-, tram-, metro- en spoorweg-lijnen en -netwerk/-infrastructuur, kwam ik bij toeval de volgende merkwaardige situatie tegen:

"Speciaal:VerwijzingenNaarHier/Sjabloon:Infobox_spoorlijn_Nederland"

Na wat onder- en verder zoeken kwam ik tot de aanname/veronderstelling dat het de bedoeling is om dit sjabloon geheel uit te faseren, niet meer te gebruiken en in paats daarvan de {{SP}}-, 'PrettyTable- en aanverwante sjablonen in een keten/ketting-combinatie te worden gebruikt en zodoende met grote flexibiliteit een een passende 'infobox op maat' kan worden gebouwd, met behoud van stijl en context.
De oorspronkelijke, achterliggende vraag hoef ik niet meer te stellen, omdat ik verwacht zelf in Wikipedia:Spoorlijnsjablonen de antwoorden zal kunnen vinden (sjablonen met velden m.b.t. elektrificatie en de kwalificaties en kwantificaties dooromheen), maar het lijkt me wel dat uit [[[Speciaal:VerwijzingenNaarHier/Sjabloon:Infobox_spoorlijn_Nederland|de eerst genoemde link]] genoemde artikelen "Las Vegas and Tonopah Railroad" en "Ferrovia Circumetnea" nog 'omgebpouwd' moeten worden naar 'spoorlijnsjablonen nieuwe stijl' (al was het alleen maar wegens het feit dat de lijnen niet in Nederland liggen maar het gebruikte infobox-sjabloon wel deze benaming heeft)?
Ik plaats de oproep hiertoe eerst hier, in de hoop dat iemand die de {{SP}}- en aanverwante sjablonen eerder (van de grond af aan) heeft gebruikt om infoboxen te bouwen, en dat in de vingers heeft, terwijl het voor mij nog nieuwe materie is. Dit neemt overigens niet weg dat ik – nadat ik de ('nieuwe') spoorlijnen-sjablonen en conventies wat beter ken – ik het wel zal oppakken als het zo tegen die tijd nog niet is aangepast; maar ik weet niet hoe lang dat kan duren, dus als er iemand is die tijd, gelegenheid en kunde heeft om het op kortere termijn in de twee genoemde artikelen om te bouwen, wil ik die graag en vriendelijk verzoeken het op te pakken. Als mijn bevindingen en veronderstellingen onjuist zijn, verneem ik dat natuurlijk ook graag. Met vriendelijke groet -- martix (overleg) 13 feb 2019 03:08 (CET)

PTC - PTCC[bewerken]

Het lijkt me verstandig dit op te splitsen naar twee aparte artikelen. Klopt dat? Encycloon (overleg) 16 feb 2019 22:00 (CET)

Hernoemen naar PTCC zou ook kunnen trouwens, met PTC als voorgeschiedenis. Encycloon (overleg) 16 feb 2019 22:01 (CET)

Vraag t.a.v. (extra/custom) functionaliteit in 'floating en/of popup-menu's[bewerken]

Allen, (en/of) @Bdijkstra: (Bij voorbaat excuses -- mijn vraag met uiteenzetting is weer eens langer dan voorzien en bedoeld, ik hoop niet dat het daardoor mensen wegens TLDR afschrikt). Ik heb ik het verleden van deze en gene fantastische tips gekregen (zoals de mogelijkheid om de achtergrond bij 'verdwenen tekst' in diffs niet lichtgeel maar een opvallendere (en donkere) kleur rood achter zulke tekst en tekens te laten kleuren t.b.v. de zichtbaarheid/gemakkelijker opsporen. Weer anderen (volgens mij onder meer collega Rodejong heeft me getoond en uitgelegd hoe ik allerhande toeters en bellen in mijn voorkeuren kan aanzetten, waardoor ik o.a. een 'peek-preview' te zien krijg in een klein floating (zwevend) windowtje (of wellicht is de formele term 'popup-windowtje), wanneer ik met de muiscursor over een (interne) wikilink zweef (hover). Daarin kan ik dan – zonder perse de link te hoeven volgen/de pagina achter de URL te hoeven openen) veelal al een oordeel vormen of hetgeen dat ik dan zie 'in orde' is, of dat het 'foute boel' is. Deze floats-on-hover-window'tjes bieden – zoals jullie waarschijnlijk allemaal zelf wel weten – ook met een kleine selectie aan opties (direct aan te klikken omdat er hyperlinks in het schermpje staan, maar ook verscheidene (uitklap)menuutjes die nog meer functionaliteit bieden zodat, zonder de link helemaal te moeten volgen en de pagina erachter volledig te laden, veel handige functies en handelingen direct vanuit het float-/hover-window uitgevoerd kunnen worden: buitengewoon handige, krachtige en tijdbesparende functie(s) (zoals bijv. repaeren van (DP)-links via popups en meer van dat).
Ik weet niet in hoeverre de functionaliteit en inrichting van deze prqaachtige "floating functionality windows" lokaal zijn aan te passen met persoonlijke instellingen, html(5), java(script) en wat er zo al meer kan worden aangewend, maar ik zou willen opperen om – als het mogelijk is (NLWP-wijd of alleen in eigen instellingen wanneer het wordt ingeschakeld door een individuele gebruiker, maar mij lijken andere handige opties om eveneens op te nemen, onder meer de volgende:

  1. Markeren als gecontroleerd (bij het zweven boven een 'wijz' (diff) link;
  2. Een optie om direct naar een revert/ongedaanmaken-scherm te navigeren;
    1. N.B.: Het is niet de bedoeling dat zo'n functie direct de revert doet én wegschrijft, maar de gebruiker gewoon direct naar hetzelfde edit-window zou brengen wanneer éérst de 'wijz'/'diff'-link wordt geklikt en geladen, en daarna nogmaals op de ongedaan-maken functie moet klikken. De laatste stap – het daadwerkelijk uitvoeren/opslaan van de revert – zou (uiteraard) nog steeds een bevestiging vereisen (maar het scheelt wel twee stappen vanuit de volglijst, de lijst met 'recente wijzigingen' en/of andere plekken waar over een 'wijz'/'diff'-link gehoverd kan worden. (Dit met in het achterhoofd voor hen die geen rollbacker zijn).
  3. (Met inachtneming van het feit dat ik geen VE gebruik en de wikibrontekst prefereer): is het wellicht mogelijk om in een artikel in 'read-mode' een woord of zinsdeel te selecteren (met de muis), waarna dan via een float of popup een wikilink aan de geselecteerde tekst toe te kennen (zonder de wikitekst editor in te gaan?
    1. N.B.: Zo'n functie uiteraard eveneens gevolgd door een bevestigings-procedure (net zoals bij de optie wanneer je een DP-link wilt wijzigen naar een andere link die in de DP zijn opgenomen en in het float-window als groene keuzelinks worden getoond: ook dan moet de gebruiker nog steeds via het editscherm een controle en een opslag-handeling uitvoeren, maar het kan veel tijd besparen (doordat je met de 'peek ahead' zo prettig 'vooruit kan kijken' zonder de links te volgen.
  4. Ook valt te denken aan functies als:
    1. een {{hola}}(-variant), {{zb}}, {{ws}} of {{brp}} en/of (als door de peek-ahead op de 'wijz'/'diff' link blijkt dat het een ongewenste bewerking is), het via hetzelfde float/popup-menu een 'ds' (datum-tijd-stempel) die betrekking heeft op de beoordeelde bewerking (datum, tijd, artikel, bewerkte pagina en soort ongewenste bewerking) toe te voegen aan de overlegpagina van de bewerker (deze optie kan eventueel alleen worden ontsloten wanneer de betreffende gebruiker al een zb/ws/brp sjabloon heeft ontvangen)
  5. Wanneer bij controle blijkt dat er door een bewerking privacy-schending of copyvio is gepleegd, zou wellicht vanuit dit menu de bewerking meteen in de correcte 'moderator verzoeken'-queue worden aangemeld;
  6. Een optie in zo'n menu kan ook zijn om het artikel bijna automatisch in andere verzoek-pagina's voor moderatoren worden opgenomen (bijv. beveiligingsverzoek etc.) -- veel stappen kunnen worden 'geautomagiseerd', maar uiteraard blijft de laatste handeling nog altijd een handmatige bevestiging van het daadwerkelijk opslaan van de aangepaste wikibrontekst in dergelijke doelpagina's.
  7. ... en zo kan ik wel meer gemaksfuncties bedenken die het leven gemakkelijker en vooral minder tijdrovend maken bij het controleren/corrigeren van bewerkingen en de doorgaans uitgevoerde vervolgacties waar nodig.

Ik wil daar echter niet al te veel tijd aan besteden als ik met dit lijstje 'nice-to-haves' in de peek-ahead float-/popup-menu's niet (gemakkelijk) te maken zijn, en echt in de (core van de) wikisoftware aangepast moet worden. Ik weet ook niet of ik in het bovenstaande verhaal voldoende duidelijk heb kunnen maken welke bestaande functionaliteiten ik bedoel, en welke uitbreidingen of toevoegingen ik daar graag ook in zou zien. Maar als me dat hierboven wel gelukt is, en er mogelijkheden zijn om dit lokaal op nl-wiki (dan wel individueel m.b.v. een gros html(5)/java(script)-stanza's) te implementeren valt, dan wil ik er graag tijd in steken om duidelijker te beschrijven (m.b.v. screenshots en andere ondersteunende illustraties). Ik voorzie (of eigenlijk 'heb ik het gevoel de functionaliteit die ik in betreffende floats/popups graag zou hebben, nu ontbreken') dat deze bijzonder veel tijd en handelingen besparen in vooral de overzichten van de (persoonlijke) volglijsten, recente wijzigingen (de go-to plek om te monitoren op vandalisme) en in mindere mate in de bewerkingsgeschiedenis van artikelen. Nogmaals, ik hoop dat ik enigszins betrouwbaar heb kunnen overbrengen welke huidige functionaliteit ik bedoel, en welke nieuwe, extra opties ik daar graag ook op zou zien; Omdat deze windows die verschijnen als je met de muiscursor over (bepaalde) (interne) links zweeft, al uitgerust zijn met verschillende directe actie-keuzes, alsook dieper gelegen functionaliteit door uitklap-menu's of een snellere navigatie in user-end generated objects/menu's dan in server-side generated markup & menus, ben ik geneigd te denken dat het mogelijk zelfs individueel (per persoon) van allerhande gewenste toeters en bellen kan worden voorzien – of is mijn indruk en veronderstelling erg ver weg van de mogelijkheden en/die de wiki-engines bieden aan client-side? Hoe dan ook, als het voortzetten van dit overpeinzen hier niet zo zinvol is, kan er natuurlijk ook op mijn OP verder gegaan worden met brainstormen, of is eventueel dit hele kopje naar mijn OP te verplaatsen wanneer het hier in het "Redactielokaal" teveel clutter oplevert. (Volgens mij komt de werk[st]er hier niet zo vaak langs als in de andere cafés Glimlach. Groeten, -- martix (overleg) 5 mrt 2019 09:17 (CET)

Je hebt het over Help:Pop-ups? Dit project wordt beheerd via de Engelstalige Wikipedia. –bdijkstra (overleg) 5 mrt 2019 10:32 (CET)
Ik kan uit dit enorm wollige verhaal niet opmaken of je dit wil bouwen of dat je mensen wil bewegen dit voor jou en ons allemaal te bouwen. Maar als je het wil bouwen: VJV&GJG, je kan gewoon op Special:MyPage/common.js beginnen, de features die je voorstelt klinken best nuttig, als ik er even vlug doorheenlees. --Frank Geerlings (overleg) 5 mrt 2019 11:25 (CET)
Nogmaals excuus voor het lange en daardoor wollig/hier en daar onnavolgbare formuleringen. Ik denk dat ik het moet zoeken/kan vinden in de richting van Geerling's tip/aanwijzing, zo nodig kan of zal ik (op een ander tijdstip dan nu) kort en bondig specifieke vragen formuleren , -- maar dat zal dan zijn op een ander tijdstip gebeurden dan nu Glimlach. In elk geval dank voor de respons tot nu toe. Groeten -- martix (overleg) 6 mrt 2019 04:23 (CET)

Foto toevoegen lukt niet (Constantinianum op Lijst van rijksmonumenten in Amersfoort (stad))[bewerken]

L.S.,
Ik heb net het rijksmonument Constantinianum toegevoegd aan de Lijst van rijksmonumenten in Amersfoort (stad), maar een foto toevoegen lukt mij niet. Na enkele pogingen ben ik maar gestopt.
Wil iemand dit doen?
Bedankt, JoostB (overleg) 6 mrt 2019 10:50 (CET)

Uitgevoerd. Encycloon (overleg) 6 mrt 2019 10:57 (CET)
PS: Er staat in de inleiding De stad Amersfoort telt 440 inschrijvingen in het rijksmonumentenregister. Hieronder een compleet overzicht. Die tekst stond er al voor de toevoeging van Constantinianum, maar of er op dit moment alle 440 monumenten genoemd worden vraag ik me af. Encycloon (overleg) 6 mrt 2019 11:01 (CET)

Aanpassingen referenties en linkonderhoud[bewerken]

Goede(morgen|middag|avond),

De volgende vraag hangt samen met of komt off-topic voort uit dit verzoek en mijn inspanningen die daarmee verband houden (of aan voorafgingen):

Wordt het 'omschrijven' (in de zin van aanpassen/transformeren, niet in de betekenis van 'beschrijven) van bronvermeldingen naar citeer-sjablonen eigenlijk in beginsel beschouwd als een BTNI of een verbetering? (Bij pagina's (artikelen) waarbij het bronoverzicht (de bronnen- en referentielijst) een ratjetoe, een lege beschrijving met alleen een externe-link-pijl of alleen (de volledig zichtbare) URL is, of als de externe link een dode link is en sowieso aangepast moet worden, beschouw ik het zelf als voldoende verbetering om daar (fatsoenlijke) titels, consistentie en/of uniformiteit aan te brengen. Ook bij links waarvan het te verwachten is dat die niet altijd zal blijven bestaan ('vluchtige' links), zet ik vaak pro-actief alvast een (al dan niet door een geforceerde snapshot) archiefurl klaar (met 'dodeurl=nee'). Het wordt (voor mij) een grijzer gebied wanneer de externe link wel een titel heeft maar verder geen enkele informatie over datum, auteur en/of uitgever vermeldt; in de CC-licentie is attribution (naamsvermelding) natuurlijk wel een groot goed, dus persoonlijk vind ik dergelijke toevoegingen/aanpassingen van de bronvermeldingen meer dan rechtvaardig (en dat gaat imho in consistente en structurele zin wel vrij gemakkelijk door bronnen en referenties om te zetten naar citeer-sjablonen), maar ik weet niet hoe anderen erover denken (en of daarmee ook het 'omkatten' naar een citeer-sjabloon als verbetering wordt gezien, of dat de keuze van de bewerker behouden moet blijven).
De eerlijkheid gebied me om op te merken dat ik lang weerstand heb gehad tegen citeer-sjablonen (en ik de opmaak/vermeldingen zoals ze in de referentie-lijst eruit kwamen te zien, op 'handmatige wijze' van zulke opmaak en vermeldingen probeerde te laten verschijnen. Maar nu ik aardig behendig ben in/met het gebruik van deze sjablonen, ben ik ook meer voorstander geworden van het gebruik ervan (en gebruik voor bronnen die ik zelf toevoeg niet anders meer), vooral omdat het ook opsporing-, bot- en script-handelingen/aanpassingen vergemakkelijkt.
Maar ik weet dus niet of er geschreven of ongeschreven regels zijn die voorschrijven dat het niet altijd geoorloofd of zelfs een BTNI is om bestaande bronvermeldingen met louter <ref [name="..."]>-tags, die er op zich prima of behoorlijk, en consistent uitzien in Appendix of ==Referenties==, (als dat de enige bewerking is).

Alvast bedankt voor jullie reacties, antwoorden en/of visies. Groeten -- martix (overleg) 19 mrt 2019 21:06 (CET)

Wat mij betreft mag er best een opmaakbot optreden die de referenties uniform maakt, ik zie dat niet als BTNI, sommige artikelbazen wel, maar daar hoef je je niets van aan te trekken, vjvegjg. Hans Erren (overleg) 19 mrt 2019 21:21 (CET)
Omschrijven is an sich geen verbetering. In beginsel moet je je afvragen wat het de lezer en/of de Wikipediaan oplevert. Als je nuttige informatie toevoegt over een bron, met of zonder citeersjabloon, dan is het uiteraard een verbetering. –bdijkstra (overleg) 19 mrt 2019 21:24 (CET)
Dat laatste is – ook in de bewerkingen waar ik aanvankelijk over twijfelde, twijfel die aanleiding was voor deze vraag – in het algemeen vrijwel altijd het geval: datums, auteurs, uitgever, (hoofstuk, pagina['s], sectie, enz.) en ook bij ([alleen] proactief) klaarzetten van een archieflink (met name voor bronnen/urls waarbij de ervaring is dat die relatief snel onbereikbaar worden/geen 'eeuweige' deep- of perma-link zijn), levert dat ook visueel een toevoeging "Gearchiveerd van origineel op {datm}." op, waarbij dat eigenlijk ook alleen maar met een citeersjabloon kan, en als voordeel heeft de lezer óók al een werkend alternatief te bieden vóórdat IABot de linkrot heeft gedetecteerd (en de parameter |dodeurl= ..   van "nee" naar "ja" heeft omgezet). Ik concludeer eigenlijk uit de twee bovenstaande reacties dat het daarom feitelijk altijd als een verbetering kan worden gezien (want als een bronvermelding/referentie eigenlijk al die informatie al vermeld, heb ik immers ook geen reden om de bron(opmaak) te bewerken/kan ik geen informatie toevoegen. Hartelijk dank voor de feedback tot dusverre. Mvg -- martix (overleg) 20 mrt 2019 14:43 (CET)

"De Dood": personage vs. personificatie[bewerken]

Om wat sneller respons te oogsten leek het me wenselijk om (mede namens collega Bever) hier in het Redactielokaal te verwijzen naar de vraagstelling die door collega Bever en mijzelf op de Overleg:De Dood (personage)-overlegpagina uiteengezet is. (Zodoende komt dat overleg denk ik wat eerder op gang dan dat er eerst enkele dagen tot een week voorbij moet gaan voordat er via Overleg Gewenst aandacht op gevestigd mag worden).
Het gaat dus om de vraag of het artikel dat over een specifiek personage van één auteur wel 'passend' is onder de nu tamelijk algemene – en daardoor wellicht misleidende – titel. (Waarbij opgemerkt moet worden dat er ook een #redirect-pagina "Dood (personificatie)" (daar zonder lidwoord) bestaat die wel verwijst naar het personage "De Dood" in algemene zin. -- martix (overleg) 19 mrt 2019 22:53 (CET)

Met de huidige inhoud op De Dood (personage) zou ik het lemma hernoemen naar De Dood (Schijfwereld), De Dood (personage) vervolgens een redirect naar Magere Hein maken en de paragraaf "Andere versies van De Dood" overhevelen naar Magere Hein. Hans Erren (overleg) 20 mrt 2019 21:56 (CET)
Ik kan me daar heel goed in vinden/lijkt me (qua methode) de beste aanpak om dit te 'ontwarren'. Er leefde bij mij in eerste instantie (vóórdat ik het artikel nog eens goed las, en voordat) wel wat twijfel/verwarring over de toevoeging "(Schrijfwereld)", omdat ik dat aanvankelijk ook als een algemene term/begrip interpreteerde (en geen acht had geslagen op de hoofdletter-S).
(Pas) in het artikel blijkt dan dat "Schrijfwereld" in deze context het 'universum' van diverse boeken van Terry Pratchett is (en realiseerde me dat pas weer na opnieuw lezen).
Maar het betekent volgens mij wel dat mensen die niet bekend zijn met dat werk van Pratchett, de naam "Schrijfwereld" door hen ook opgevat kan worden als een algemene term en er misschien nog een klein restje verwarring in de titel overblijft (dat pas wordt weggenomen wanneer men het artikel leest).
Is misschien de toevoeging "(Schrijfwereld-reeks)" – of "(Schrijfwereld-universum)" – nog net iets wenselijker om titel-verwarring geheel (of nog meer) te elimineren? Of weegt dat niet op tegen het 'nadeel' van een lange titel? Groeten -- martix (overleg) 21 mrt 2019 12:40 (CET)
(Met zeven kleuren schaamrood op de wangen): De verwarring ontstond bij mij dus omdat ik niet kennelijk niet kan lezen (of te vluchtig gelezen heb)... Schijfwereld is net zoiets als "Platland" of zo? -- martix (overleg) 21 mrt 2019 13:07 (CET)
Met enige aarzeling meng ik me in dit overleg. Het voorstel om artikel De Dood (personage) te verhernoemen naar De Dood (Schijfwereld) lijkt me juist. Omwille van ijdelheid lijkt me de titel van artikel Magere Hein geheel correct en zou De Dood (personage) een redirect naar dat artikel moeten zijn. Ten slotte wijs ik Martix er op dat de romanreeks van Pratchett waarin De Dood als antropomorfe personificatie een hoofdrol speelt Schijfwereld heet, en niet Schrijfwereld. Met vriendelijke groet, Magere Hein (overleg) 21 mrt 2019 13:00 (CET)
@Magere Hein: zoals uit het doorstrepen van de tekst, en de ingevoegde verklaring hierboven met bijgaand schaamrood en boetekleed was me dat inmiddels (na een waardevolle tip) ook duidelijk geworden (ik was en ben ook totaal niet bekend met de boeken van Pratchett, maar desondanks ben niet onbekend met een andere schijfwereld). Maar concluderend is er dus niets aan te merken op het voorstel van Hans Erren; er is dus (overigens) al een doorverwijspagina "Dood (personificatie)", maar het lijkt me zonder meer logischer dat het achtervoegsel '(personage)' ook naar het artikel "Magere Hein" zou moeten leiden. Het lijkt me overigens niet onwaarschijnlijk dat er tussen alle links naar het (huidige) artikel "De Dood (personage)" er een aantal tussen zitten die nu abusievelijk naar het personage uit "Schijfwereld" verwijst, maar ook vast weer niet allemaal. Die zullen handmatig langsgelopen worden vermoed ik? -- martix (overleg) 21 mrt 2019 18:50 (CET)
De links zullen allemaal nagelopen moeten worden. Hans Erren (overleg) 21 mrt 2019 18:53 (CET)
Uitgevoerd Uitgevoerd Koppelingen nog nalopen, doorverwijspagina ook nog aanpassen. Hans Erren (overleg) 21 mrt 2019 21:32 (CET)
ook Uitgevoerd Uitgevoerd Hans Erren (overleg) 21 mrt 2019 22:15 (CET)
@Hans Erren: Hulde en veel dank! -- martix (overleg)

Fijn dat de aanzet op de artikeloverlegpagina zo snel is opgepakt, dat is het mooie van een samenwerkingsproject. In het kopje hier lijkt er een tegenstelling tussen de kwalificaties 'personage' en 'personificatie', maar het lijkt me dat er voldoende overlap is om beide in één artikel te behandelen. Wanneer de Dood als personage in een verhaal optreedt, is hij eigenlijk ook altijd een personificatie van dit natuurverschijnsel.

Omgekeerd kun je zeggen dat er verschillende manieren zijn om een personificatie te gebruiken: als stijlfiguur in dichterlijk taalgebruik (dat is de betekenis die in ons artikel personificatie vooropstaat evenals in het Algemeen letterkundig lexicon), als afbeelding maar ook als personage, zoals in allegorische toneelstukken, in de oudste opera, in sprookjes en in romans. Hoewel schrijfdocent Thérèse Major onderscheid maakt tussen 'personage' en 'personificatie' als nevenschikkende begrippen, schrijft B.A.M. Ramakers in een artikel over allegorisch toneel letterlijk: "Een personificatie is immers een personage dat een begrip of instantie letterlijk tot leven brengt". Julie Stokx citeert in haar afstudeerscriptie (2 MB) diverse critici sinds de 18e eeuw die "een onderscheid [maken] tussen personificatie als retorische versiering en personificaties die echte personages zijn". Bever (overleg) 22 mrt 2019 00:40 (CET)

Het bovenstaande is misschien meer relevant voor het artikel personificatie, maar ook in het artikel over de Dood zouden deze verschillende vormen aan bod kunnen komen. Minpunt aan de titel Magere Hein vind ik dat die naam naar mijn idee vooral verwijst naar de man met de zeis en niet naar andere vormen zoals de Engel des doods, de godheid Thanatos en niet-westerse versies. De Dood (personificatie) zou daarom mijn voorkeur hebben, al is het in dat geval wel lastig een goede beginzin te schrijven. Bever (overleg) 22 mrt 2019 00:48 (CET)
Ik vraag me af of het wenselijk is om een #doorverwijzing-pagina "Dood (personificatie)" én een andere (artikel-)pagina "De Dood (personificatie)" naast elkaar te hebben, waarbij de laatste over een wezenlijk ander onderwerp (ongeacht overlap en dezelfde thematiek) te hebben. Eigenlijk is het m.i. eerder wenselijk om (voorlopig) ook voor(/van) "De Dood (personificatie)" een #redirect te maken naar "Magere Hein", hoewel ook valt te denken aan 'volwaardigere' DP-pagina's. (Op de NL-WP is er soms wat verwarring met het door elkaar gebruiken van "DP/doorverwijspagina" (eigenlijk "disambiguatie-pagina" (maar heeft dezelfde afkorting) en "#doorverwijs"- of "#redirect"-pagina's), maar dat terzijde). Mvg -- martix (overleg) 22 mrt 2019 13:28 (CET)
Vooralsnog heb ik zojuist ook de #DOORVERWIJZING-pagina "De Dood (personificatie)" aangemaakt die nu redirect naar "Magere Hein". Ik denk dat ik later vandaag nog de disambiguatie-pagina (DP) "De Dood" zal uitbreiden met een opsomming van meer verwante dan die er thans nog in staan, naar (echte) artikelen (van fysiologisch/biologisch dood, hersendood, Magere Hein, De Dood (schijfwereld) en wat ik nog meer kan vinden (aan mythologische, essentieel andere personificaties van De Dood (in verscheidene cultueren en/of (oudere) beschavingen, andere boeken, en eventueel zeer verschillende maar verwante, ruime 'zie ook'-begrippen of -personages" (bijv. == Zie ook == : Zwarte Dood, euthanasie, ..., etcetera). Groeten -- martix (overleg) 22 mrt 2019 13:49 (CET)
Uitgevoerd Uitgevoerd Meer dood-gerelateerde onderwerpen (voor zover Hans Erren dat nog niet had gedaan) toegevoegd, en waar nodig in de skip-pagina opgenomen. -- martix (overleg) 22 mrt 2019 18:36 (CET)

'Tegenwoordig' en terugdraaien (gerechtvaardigde) botbewerkingen[bewerken]

(Deze 'post' is al langer geworden dan ik zou willen/aanvankelijk voor ogen had – waarvoor mijn verontschuldigingen – maar het is zelfs nog een ingekorte versie; in de voorlaatste versie stonden bijvoorbeeld op voorhand allerhande tegenargumenten, om argumenten te pareren die mogelijk niet eens ter tafel komen; die zullen zo nodig wel ter tafel komen wanneer ze nodig zijn. N.B.: de gebruikers RobotE (en diens beheerder) en Brya zijn bedoeld als illustraties, er zijn meerdere gebruikers aan beide zijden van het argument, de bedoeling is om een breed overleg aan te gaan, uitdrukkelijk niet om bij naam genoemde collega's persoonlijk aan te vallen.)

Al een tijdje gaat RobotE de artikelen af om de vage, onbepaalde tijdaanduiding(en) als "Tegenwoordig (..)"[tw 1] te taggen met het {{Wanneer?}} sjabloon; dit om de (mede)auteurs (en zo mogelijk ook anderen) op te roepen dit nader of duidelijker te beschijven met een zodanige bepaalde aanduiding die daardoor tijdloos is en de lezers dan bovendien zo nauwkeurig mogelijk informeert over wanneer de bewerking een feit werd of is geworden.

Een gedegen encyclopedisch artikel maakt melding van zo nauwkeurig mogelijk vastgestelde plaats- en tijdsaanduidingen. Zo'n tijdsaanduiding is wellicht niet altijd tot op de seconde, dag, jaar, decennium of eeuw nauwkeurig bekend, maar als de schrijver er enige moeite in steekt, is altijd wel een punt in de tijd te beschrijven vanaf wanneer de bewering zeker waar werd, was of is; in het ongunstigste scenario is dan mogelijk niet met zekerheid bekend of het vóór moment X in de tijd-/jaarrekening ook al een feit was, maar wel kan (altijd) geduid worden dat de bewering tenminste vanaf dat moment X feitelijk juist was. Ter illustratie, is dit slechts één van de manieren waarop een formulering met 'tegenwoordig' verbeterd en vooral toekomstbestendig ('tijdloos') geschreven of verbeterd kan worden.

Als de bepaling "Tegenwoordig" of "heden" gehandhaafd blijft in een artikel, dan schuift die onzekere bepaling bij het verstrijken van de dagen en jaren mee op, dat kan tot ver in de toekomst onbepaald blijven, en de onzekerheid van het wanneer neemt in de artikeltekst navenant mee toe (de lezers zouden niet de bewerkingsgeschiedenis van een artikel moeten raadplegen om zelf op te kunnen maken/te beredeneren sinds wanneer dat "Tegenwoordig", "Nu", "Heden", "Vandaag de dag", "Momenteel", enzovoorts dan is begonnen.

Onder meer – maar niet alleen – collega Brya lijkt echter [bij regelmaat deze sjablonen te verwijderen] met bewerkingsomnschrijving(en als)) "Nu", of in dit specifieke geval, waar ik de bewerking ongedaan had gemaakt om de sjablonen weer te tonen [tw 2] met als (meer een ongestaafde bewering dan een) argument:

Aanhalingsteken openen

"tegenwoordig" is een ordentelijk nederlands woord dat in een encyclopedie perfect gebruikt kan worden waar het toepasselijk is. Daarentegen zal valse precisie de lezer op het verkeerde been zetten, en is dus ongewenst.

Aanhalingsteken sluiten

Ik kan mij daar niet in vinden; bovendien zou het betekenen dat (dan juist) RobotE massale ongewenste bewerkingen zou maken. Als dat zo zou zijn, dan waren al die bot-bewerkingen al lang teruggedraaid en die robot een halt toegeroepen.

Ik stel mij op het standpunt dat {gebruiker} met het (weer) verwijderen van de {{wanneer?}}-sjablonen ongewenste bewerkingen verricht. Naar mijn inschatting/mening worden deze (onbepaalde/onzekere) tijdsaanduidingen (zoals "Tegenwoordig" en vergelijkbare termen) terecht gemarkeerd (en daardoor gelouterd): zulke aanduidingen dienen zoveel mogelijk door concretere duidingen worden vervangen – of anders moet het anders geformuleerd worden – en totdat dat is gedaan, wordt de lezer van het artikel met deze sjablonen gewezen op de onzekerheid die met de bewering gepaard gaat. Met het verwijderen van deze sjablonen wordt (al dan niet opzettelijk, en al dan niet om die reden) de onvolkomenheden in het artikel weer gemaskeerd. Het is misschien niet fraai als zulke sjablonen, op- en aanmerkingen – al dan niet in zelf (mee)geschreven artikelen – in een artikel staan, en daarmee het artikel wat ontsieren, maar de oplossing daarvoor is om (bron)onderzoek te doen en een zo nauwkeurig mogelijk "vanaf"-moment aan te duiden, de oplossing ligt niet in het verwijderen van deze sjablonen omdat die niet naar je zin zijn. Recapitulerend: de oplossing of de enige legitieme reden/bewerking die het verwijderen van het sjabloon rechtvaardigt, is het vinden en benoemen van een zo nauwkeurig mogelijke tijdsaanduiding wanneer de gerelateerde bewering waar was/is geworden, niet door de sjablonen die de onvolkomenheden aanduidt weg te poetsen met reden "Nu". Juist door het plaatsen (en behouden) van deze sjablonen attendeert de lezer dat er een mate van onzekerheid in acht genomen moet worden, anderzijds zou het (mede)schrijvers moeten uitnodigen om te proberen de onvolkomenheden, ook al zijn ze nog zo klein, proberen op te lossen; het is een signaal naar de auteurs én een (belangrijk) signaal voor de lezer dan m.i. niet onvermeld mag blijven.[tw 3]

Omdat met het (vele malen) over en weer ongedaan maken van elkaars bewerkingen er niet inhoudelijk en op basis van argumenten en met wederzijds respect wordt overlegd, maar alleen maar bwo's ontstaan – waarbij niet zelden emoties hoog oplopen en het dan totaal niet meer over het onderwerp, de inhoud en de (vermeende of naar oprechte overtuiging veronderstelde) gebreken van het artikel gaat, heb ik niet nogmaals de bewerking teruggedraaid, maar zoek ik hierbij het overleg op om:

  1. In het algemeen te informeren naar richtlijnen t.a.v. onbepaalde tijdaanduidingen als "tegenwoordig", "heden [ten dage]", "op dit moment", etcetera;
  2. Mede-wikipedianen – de wikipedia-gemeenschap – te vragen naar de visies, voor zover richtlijnen daarover geen duidelijkheid verschaffen of daarin voorzien;
  3. In het bijzonder t.a.v. het artikel "ijzergaren" in deze kwestie[tw 4] om advies in te winnen, dan wel consensus te bereiken over welke van de (twee) beschouwingen/standpunten 'juist' is, of de meeste steun geniet om daarmee concrete duidelijkheid te verkrijgen of in dit artikel het {{Wanneer?}}-sjabloon (waneer er geen preciezere tijdsbepaling wordt aangevoerd) behouden dient te worden, dan wel of deze in dit artikel weggehaald kunnen worden.[tw 5]
  4. Algemener, of dezelfde (in bovenstaand punt #3) gemaakte afwegingen, oordeel en/of bereikte consensus (welke dat ook moge zijn) eveneens van toepassing zijn op alle andere de door RobotE met het "wanneer?"-sjabloon aangemerkte onbepaalde tijdsaanduidingen, en eventuele daaropvolgende verwijderingen van die sjablonen door Brya (of welke andere gebruiker dan ook) ook van toepassing zijn;
    1. Waarbij moet worden aangemerkt dat, als de door RobotE met sjabloon gemarkeerde bepalingen i.h.a. dan als ongewenst worden beschouwd, ze dan waarschijnlijk grootdeels tot allemaal verwijderd zouden moeten worden;
    2. En anderzijds, als door toepassing van richtlijnen of consensus de "wanneer"-sjablonen gehandhaafd zouden moeten blijven (wanneer er géén bewerking is gepleegd die een specifieke(re) tijdsaanduiding aanvoert), zouden de bewerkingen waarbij die sjablonen dan onterecht zijn verwijderd, weer teruggeplaatst moeten worden.

Samengevat: M.i. is het verwijderen van de door RobotE geplaatste wanneer-sjablonen alleen geoorloofd als de formulering wordt aangepast zodat woorden als 'tegenwoordig', 'heden' etcetera zoveel mogelijk opgespoord blijven om te kunnen vervangen, en is het verwijderen van die sjablonen zonder wezenlijke aanpassing ongewenst, en verzoek iedereen om dat niet meer te doen (alleen het weghalen van het sjabloon met omschrijving "Nu"). Het argument van 'valse precisie' is weliswaar genoemd, maar niet aangetoond, waar één voorbeeld daarvoor zou voldoen. Maar zelfs zo'n voorbeeld sluit niet uit dat met een andere formulering die 'valse precisie' kan worden weggenomen.

Graag jullie visies, (inhoudelijke) argumenten, pointers naar eventuele beschreven richtlijnen en conventies die hieromtrent uitsluitsel geven, (eventueel interpretaties daarvan als er meerdere mogelijk zijn), adviezen – vanzelfsprekend in goed overlegd met wederzijds respect – en hopelijk een uitkomst, consensus of compromis waar zoveel mogelijk (en bij voorkeur iedereen) zich in kan vinden. -- martix (overleg) 21 mrt 2019 22:23 (CET)

Ten eerste: had je al op de overlegpagina van de boteigenaar gekeken? -- Encycloon (overleg) 2 apr 2019 23:26 (CEST)
Jawel, en ook (bij toeval gelijktijdig) ook off-wiki in overleg geraakt, maar het is m.i. wenselijker om de discussie centraler te voeren dan (off-wiki of) op de OP van een artikel of gebruiker/botbeheerder. M.v.g. -- martix (overleg) 2 apr 2019 23:54 (CEST)
Ten tweede: in het kort is mijn visie dat we een tijdsneutraal standpunt innemen. Iets wat tegenwoordig zo is, kan morgen, over twee jaar of over een decennium heel anders zijn. Daarom is het m.i. in de meeste gevallen ongewenst om te kiezen voor een dergelijke aanduiding die snel verouderd kan zijn.
Mvg, Encycloon (overleg) 2 apr 2019 23:26 (CEST)
Dat is ook (zoals hierboven duidelijk zo moeten zijn -- nogmaals excuses voor de lengte) mijn visie. Met betrekking tot het artikel "IJzergaren": het is bepaald niet een van de kroonjuweeltjes van nl-wiki, dat artikel kan op veel punten verbeteringen gebruiken, en zou in huidige staat eerder meer op- en aanmerkingssjablonen verdienen dan minder. Maar beurtelings (alleen) het {{Wanneer?}}-sjabloon verwijderen en toevoegen, daar wordt het artikel niet beter van. Door het sjabloon te laten staan, is de kans groter dat het in het vizier komt van iemand met kennis over het onderwerp en het van kop tot staart opknapt. Mvg -- martix (overleg) 3 apr 2019 00:07 (CEST)
Off-topic. Dat artikel was mij ook als een doorn in het oog gesprongen door de sjablonentoestand. Het artikel is verbeterd, zodat termen als "nu" en "tegenwoordig" er niet meer in voorkomen. Die woorden waren m.i. een teken van een slechte schrijfstijl in dit geval. Elly (overleg) 3 apr 2019 00:58 (CEST)
Het lijkt erop dat martix de stelling "Een gedegen encyclopedisch artikel maakt melding van zo nauwkeurig mogelijk vastgestelde plaats- en tijdsaanduidingen" bedoelt als "zo gedetaileerd mogelijk", net zoals overigens Elly. "Nauwkeurig" is iets anders als "gedetaileerd": nauwkeurig houdt in dat de lezer na lezing met juiste informatie verder gaat, gedetaileerd betekent "met namen en rugnummers".
        Ontelbare keren heb ik meegemaakt dat een gebruiker een perfect nauwkeurige, algemeen gestelde zin verving door een gedetaileerde en gigantisch foute zin, onder het motto van "nauwkeurigheid". In werkelijkheid is dit angst om ook maar een klein beetje na te denken, waarbij de betreffende gebruiker onbepaaldheid intern omzet naar "onzekerheid" (ook wel bekend als horror vacui). De encyclopedie hoort deze gebruikers juist op te voeden, en uit te leggen dat dit geen goede redactie is.
        Zoals ik al eerder zei: ""tegenwoordig" is een ordentelijk nederlands woord dat in een encyclopedie perfect gebruikt kan worden waar het toepasselijk is." In een encyclopedie is "tegenwoordig" toepasselijk in korte pagina's als gedoeld wordt op iets dat niet gedetaileerd tijdsbepaald is, dus als het niet aankomt op een decennium of wat (en dus ook niet in de komende decennia gaat veranderen). In langere pagina's waar alles omstandig wordt uitgelegd zal het geen plaats hebben, maar in een korte pagina waarin kort een algemene schets wordt neergezet zeker wel. Om te beoordelen waar dit wel of niet juist zal zijn is een bot volkomen ongeschikt (bots zijn er voor bewerkingen die niet omstreden zijn, niet voor zoiets). - Brya (overleg) 3 apr 2019 05:29 (CEST)
De wanneerbot kan deze subtiliteiten niet herkennen daarom moet die worden uitgezet. Ik vind het een pedante bot. Hans Erren (overleg) 3 apr 2019 06:56 (CEST)
@Brya: Kun je een (of liefst meer) concrete voorbeelden geven van zo'n 'herformulering die leidde tot een valse precisie', of valse indruk van die formuleringen (waardoor zo'n bewerking geen verbetering maar een evidente verslechtering was, leidde of (meer) ruimte bood tot een verkeerde interpretatie en/of de betreffende tijdsaanduiding alleen maar leidde tot meer ambivalentie en/of de ambiguïteit van die bepaling, of zelfs een verkeerde, foute of ongewenste tijdsaanduiding of bepaling ontstond?
@Ellywa: Het is misschien ook mogelijk om de 'bot' RobotE géén wijzigingen in de betreffende artikelenb/oagina's maakt (daar geen {{Wanneer?}}-sjablonen invoegt, maar in plaats daarvan onder de WP:-naamruimte centrale overzichtslijsten genereert met daarin de namen van pagina's/artikelen waarin de "onbepaalde tijdsaanduidingen" zijn gevonden, met ernaast de (gehele) frases die gevonden zijn (en de woorden in kwestie in vet of onderstreept, indien mogelijk (en van toepassing) in welk kopje en regelnummers, en – ik denk dus in beginsel aan het genereren van systematische tabellen – kolommen en cellen die ruimte bieden om bevindingen/cognitieve beoordeling door anderen die de gevonden hits nalopen, en daarin aangeven of het om false positieves gaat, dan wel of de formulering redelijkerwijs niet aangepast kunnen worden, of dat de tijdsaanduiding in de betgreffende artikelen anders geformuleerd zijn (met daarbij ruimte voor een peer-review (beoordeling van de wjjziging door anderen.[tw 6]
Dus eigenlijk een beetje zoals de (lijst)pagina Help:Veel voorkomende spelfouten wordt gegenereerd en gebruikt, maar met een iets strakkere/structurele(re) opmaak in tabel-vorm, die voor mens en robot/script gemakkelijk gelezen en geparsed worden. (een andere optie is wellicht om in die pagina's waar RobotE 'hits'/matches detecteerd, een onzichtbaar sjabloon te plaatsen zodat de lijsten op die manier gegenereerd kunnen worden, maar 'lelijke' klaag-sjablonen uitblijven, maar persoonlijk zou ik meer zien in een structureel gegenereerde tabel(-lijst) volgens een eenduiding stramien. Als mensen menen dat een (n.a.v. een vermelding van (een passage of zin in) een artikel kunnen verbeteren door de tijdsaanduiding anders te formuleren, treedt daarna immers gewoon de normale beoordelingsprocedures in werking (collega's die real time, of recente bewerkingen of bewerkingen via hun volglijst beoordelen en die zo'n herformulering dan alsnog ongedaan kunnen maken als daardoor het probleem dat collega Brya schetst inderdaad aan de orde is, en de bewerking(/andere formulering) gewoon weer ongedaan gemaakt kan worden (en wanneer daardoor dan verschil in inzichten ontstaat, staat zoals altijd de weg naar het overleg – via OP (van het artikel, op de OP van de bewerker, op de OP van die gegenereerde lijsten/tabellen (zoals ik die hierboven schetste), de robot-OP en/of overleg op centrale plekken – nog altijd open.
Het is zomaar een idee, mogelijk zijn er nog andere oplossingen die er wel toe leiden dat dergelijke bepalingen (waarvan m.i. de meerderheid door andere formulering verbeterd kunnen worden zonder een onjuiste precisie of een vals gevoel daarvan ontstaat), zonder artikelen te 'ontsieren' waar het desondanks een prima tijdsaanduiding is en waarbij het echt niet mogelijk is om die accurater of met concreter te formuleren of er geen reden of methode is om de formulering aan te passen zodat het een verbetering is. Mvg -- martix (overleg) 6 apr 2019 09:33 (CEST)
@Martix:Ik hanteer bij het toevoegen van een "wanneer"-sjabloon dat een tekst op Wikipedia over 100 jaar nog steeds juist moet zijn. Het sjabloon "wanneer" heeft twee doelstellingen: 1. Het attendeert de lezer van onze artikelen er op dat er een vaagheid in het artikel is geslopen. 2. Het attendeert de schrijver of de volger van het artikel erop dat de tekst verbeterd kan worden. Ik denk dat jouw idee niet tegemoet komt aan deze doelstellingen. Bovendien wordt het sjabloon neergezet bij de tijdsaanduidingen die vaag zijn, waardoor zowel de lezer als de bewerker precies weten wat er aan de hand is. Hetzelfde geldt overigens voor het "bron" sjabloon. Maar ik heb geen bezwaar als artikelen via het wanneer-sjabloon in een categorie worden gezet. Ik vraag mij wel af of het werkt. De artikelen met een beg-sjabloon staan ook in een categorie, dat zijn er duizenden. Hoeveel worden er daarvan uitgebreid per jaar? Elly (overleg) 6 apr 2019 20:32 (CEST)

Zoals Brya hierboven zeer terecht opmerkt: Om te beoordelen waar dit wel of niet juist zal zijn is een bot volkomen ongeschikt (bots zijn er voor bewerkingen die niet omstreden zijn, niet voor zoiets). Het gebruik van het woord “tegenwoordig” of “nu” in de encyclopedie is niet persé fout.

De bot wordt momenteel op een onwenselijke manier gebruikt en leidt tot plaatsing van een hoop onterechte “wanneer” sjablonen in de encyclopedie.

Het streven van Ellywa tot perfectie van de encyclopedie steun ik, echter dit is niet de manier om dit te bereiken. (Vergelijk: we kunnen ook wel een botrun gaan doen om bij elk gebruik van het woord “waarschijnlijk/volgens velen/volgens sommigen” een “twijfel” sjabloon te plakken. Wordt de encyclopedie daar beter van?)

Daarom, liever deze bot stilleggen en handmatig dergelijke bewerkingen doen. Vr groet Saschaporsche (overleg) 23 apr 2019 06:33 (CEST)

Het is een misverstand dat met WP:AWB niet handmatig is. Dat is wel een handmatige edit, de AWB zoekt alleen de woorden op en doet een suggestie voor de verbetering. Als de operator (in dit geval Ellywa) het niet met de wijziging eens is, wordt die niet doorgezet. Een aantal voorbeelden waarbij het gebruik van het woord tegenwoordig ongewenst is:
Kortom, de geplaatste sjablonen, ondersteund met AWB, zijn zinvol en stimuleren schrijvers om de encyclopedie te verbeteren, of attenderen de lezers op vaagheden of zelfs onjuistheden. Elly (overleg) 23 apr 2019 15:15 (CEST)

Goed, dus de bewerkingen die ik zie zijn handmatig ingevoerd? Waarom zie ik dan deze bewerking waarbij een citaat van van de Heuvel onnodig gecorrigeerd wordt? (ik heb het inmiddels teruggedraaid...)

Kortom: de bewerkingen van de "bot" zijn niet alle nuttig, soms volledig onjuist. Saschaporsche (overleg) 23 apr 2019 17:32 (CEST)

Waarom? Omdat juist een mens soms fouten maakt. Bots maken minder fouten. Bedankt voor het terugdraaien. Elly (overleg) 23 apr 2019 17:36 (CEST)
Nee hoor bots maken niet minder fouten, ze maken automatisch veel dezelfde fout. Hans Erren (overleg) 23 apr 2019 18:16 (CEST)

Opmerking Opmerking: Mag ik een dringend verzoek doen om de werkzaamheden van de bot stil te zetten? Ik heb inmiddels +/- 150 bewerkingen van de bot handmatig gecorrigeerd (en het eind is nog niet in zicht.....). Het is redelijk frustrerend om te moeten constateren dat bijna alle bewerkingen die door de bot zijn uitgevoerd alsnog gecorrigeerd of gerevert moeten worden. Het kan en mag toch niet zo zijn dat de bewerkingen van een bot bijna allemaal alsnog moeten worden gecorrigeerd? vr groet Saschaporsche (overleg) 23 apr 2019 23:20 (CEST)

Bijzonder te waarderen! Ik zie dat je heel wat van zulke aanduidingen hebt weten te vervangen door concretere tekst. Het is niet de bedoeling stress te veroorzaken bij wie dan ook. Ik zal voorlopig stoppen met Robot E op dit specifieke punt van tijdsbepalingen. Elly (overleg) 24 apr 2019 09:05 (CEST)
Dank je. vr groet Saschaporsche (overleg) 24 apr 2019 09:44 (CEST)
Beste Saschaporsche, ik wordt niet bepaald enthousiast van veel van je correcties. Het woord tegenwoordig heeft wel een functie in de tekst: het geeft aan dat een situatie sinds een bepaald moment/jaar/decennium anders is dan daarvoor. Het simpelweg uit een tekst verwijderen van het woord tegenwoordig is bepaald geen verbetering aangezien dat onderscheid tussen voorheen en de huidige situatie verdwijnt. En "tegenwoordig" vervangen door "anno 2019" legt nadruk op het jaartal 2019, terwijl het vaak niets met de veranderde situatie of het gestelde te maken heeft. Ik had gisteren al wat aangepassingen gedaan:
  1. Ferdinand Porsche: 2019 is geen markering in de (naam)geschiedenis van Maffersdorf/Vratislavice (aangepast).
  2. Kwaliteitskrant: 2019 is geen belangrijk jaar in de overstap naar tabloidformaat, die overstap was voornamelijk rond 2004–2005 (aangepast).
  3. Noodstroomvoeding: "hedendaags" is net zo weinig informatief als "tot op heden", kan verwijderd worden (aangepast, meer wijzigingen).
  4. Enschede: De Museumfabriek is er niet sinds (kort na) 1907 gehuisvest, maar sinds 2008 (aangepast).
  5. Pornografie: "(tot) nu" had je terecht verwijderd, maar daarmee te veel weggehaald (aangepast).
  6. Hartkatheterisatie: hier gewoon "tegenwoordig" weghalen verminkt de tekst; er kan meer duiding gegeven worden, en die oproep heb ik vervolgens in de {{wanneer?}}-sjablonen duidelijker aangegeven. Om een jaartal-specificatie wordt niet gevraagd; gelieve de sjablonen niet zomaar weg te halen.
Bij je eerste ~20 aangepakte artikelen heb ik de volgende opmerkingen:
  1. Sinds wanneer (jaar) gaat de koers onderlangs de heuvel? "Heden ten dage" heeft dezelfde betekenis; de wanneer-sjabloon is dan nog steeds op z'n plaats.
  2. Sinds wanneer (jaar) werkt De Tünel met een enkel spoor?
  3. In de loop van welke periode zijn de stroopfabrieken verdwenen?
  4. Wanneer (jaar/jaren) is Independence Hall gerestaureerd tot zijn oorspronkelijke uiterlijk?
  5. Sinds wanneer (jaar) is dit wettelijk vastgelegd?
  6. Deze aanpassing impliceert dat de teller van het aantal covers in 2019 op 200 staat (dit was al door GeeJee gecorrigeerd).
  7. Sinds wanneer (welke periode/decennium) wonen er veel Ait Wayagher in de genoemde plaatsen?
  8. Dit zijn goede aanpassingen, al zou ik hier het woord "tegenwoordig" gewoon in de inleiding laten staan. Onder het kopje Geschiedenis kan echter nog heel wat meer tijdduiding toegevoegd worden, getuige ook het Engelstalige artikel. (aanpassing)
  9. Hier is "Tegenwoordig" prima op z'n plaats.
  10. Sinds wanneer (welke periode/decennium) wordt elastisch kunststof gebruikt?
  11. Wanneer (jaar) is de vernoeming gedaan?
  12. Hier zou ik gewoon "Tegenwoordig[wanneer?]" laten staan: het artikel heeft sowieso meer redactie nodig dan slechts die woorden.
  13. Sinds wanneer (jaar) is de dierentuin er gevestigd?
  14. Sinds wanneer (welke eeuw?) wordt de kikkererwt in veel subtropische gebieden geteeld?
Je mag vanalles van de sjablonen vinden, maar vriendelijk doch dringend verzoek om met dit soort correcties te stoppen, en je constructiever op te stellen. Het doel van {{wanneer?}} is niet om aan te geven dat de artikelen zo snel mogelijk aangepast moeten worden, maar om aan te geven waar de artikelen verbeterd kunnen worden.
En @Ellywa: de sjabloon is een goed middel om aan te geven dat er vaagheid in de artikeltekst staat, maar zou je er een motivatie zoals "Sinds wanneer (jaar)?" of "Sinds wanneer (decennium/periode)?" of "In de loop van welke periode ...?" in kunnen vermelden?
Met vriendelijke groeten — Mar(c). [O] 25 apr 2019 12:37 (CEST)
Beste Mar(c), dank voor je reactie. Naar mijn mening heeft het plaatsten van de sjablonen door de bot weinig zin. Bovendien ontsiert het de encyclopedie al die sjablonen (kijk naar de :en Wikipedia). Een zinsdeel als “tegenwoordig” (of iets dergelijks) prima in een encyclopedie, de lezer alhier is niet achterlijk en kan best inschatten/rekening houden met het feit dat de encyclopedie niet tijdloos geschreven is. Als we bij elk woord dat niet precies de tijd aanduidt (vroeger, nu, huidig, in het verleden, in de toekomst, heden ten dage, sinds geruime tijd etc.) een “wanneer” sjabloon gaan plakken staat de encyclopedie straks vol met sjablonen. (Net zoals we niet bij elke bewering/feit hier een bronsjabloon plakken. Dat zou de encyclopedie ook ontsieren.)
Slechts bij sterke twijfel over een bewering zou een “wanneer” of “bron” sjabloon op zijn plaats zijn. Vr groet Saschaporsche (overleg) 25 apr 2019 21:51 (CEST)
Goedenavond Saschaporsche, jij ook bedankt voor de reactie. 'Ontsiert' is subjectief, niet alleen qua lay-out of (tekst)beeld. Juist voor het duidelijk aanwijzen van teksten die verbeterd kunnen worden, zou het de Nederlandse WP naar mijn mening 'sieren' om dit soort sjablonen meer in te zetten. We moeten niet te bang zijn om, als project, de eigen zwakke plekken aan te wijzen, en liever een paar {{wanneer?}}-sjablonen meer dan daar deze vaagheden kritiekloos te laten staan. Zo betrekken we bovendien meer mensen bij het schrijven/verbeteren (zie ook mijn reactie hieronder). Lezers zijn inderdaad niet 'achterlijke' (zie tweede bullet in mijn reactie hieronder), maar het gaat om verduidelijking en aanvulling van informatie waar dat goed mogelijk is.
Inderdaad is bij sterke twijfel over een bewering een {{bron?}}-sjabloon op z'n plaats – maar net zo goed is bij een duidelijk datering-wezelwoord een {{wanneer?}}-sjabloon op z'n plaats. Met de selectie hierboven wil ik aangeven dat zo'n datering-wezelwoord vaker wel dan niet door een concretere formulering vervangen kan worden, dat de sjabloon dus vaak wel terecht is, en dat het simpelweg verwijderen van zo'n (taalkundig wel functioneel) woord of door het te vervangen door "anno 2019" een verslechtering inhoudt. Let wel: bij "tegenwoordig" gaat het voornamelijk om het 'aanvangsmoment' van de periode die ermee bedoeld wordt, niet zozeer met de mogelijkheid dat het einde van die periode (de 'heden'-kant van 'tegenwoordig') op een zeker moment in de toekomst gepasseerd kan worden waarmee het beweerde dan verouderd zal zijn (zie de beide bullets). Met het vervangen van "tegenwoordig" door "anno 2019" lijk je je vooral op die 'heden'-kant te focussen (al schrijven we inderdaad niet tijdloos, en weten lezers dat ook).
Misschien is niet alles (meer) zo exact te achterhalen als dat ik hierboven aangeef met "Sinds wanneer (jaar)" e.d., maar iets als een aangepaste route van de koers Parijs-Roubaix, de vernoeming van een onderdeeltje ervan naar een legendarische wielrenner, een restauratie van Independence Hall, een wettelijk vastlegging, en de vestiging van een museum of een dierentuin – daar is toch genoeg informatie over te vinden om de tijdvaagheid weg te nemen?
Met vriendelijke groeten — Mar(c). [O] 26 apr 2019 01:37 (CEST)
Ofschoon ik een voorstander ben van de oplossing met "anno (jaartal)" zie ik nu ook wel het nadeel dat die oplossing in zijn simpelste vorm en toepassing vanuit de schrijver/redactuer van het artikel is geredeneerd. Hoewel die oplossing gemakkelijk en eenvoudig de gemelde problemen zou kunnen oplossen kan die dus ook leiden tot verwarring. Als het belangrijk is dat er toch een melding gemaakt moet worden dat, ten tijde van het schrijven van de tekst, de datum of het tijdstip van een feit wordt vastgelegd dan zou dit kunnen met het toevoegen van een voetnoot, met in de voetnoot de waarschuwing dat "de melding van het jaartal een tijdsopname is en ondertussen kan zijn veranderd". Trouwens kan het gebruik van zo'n melding in een voetnoot ook het lelijke [wanneer] in de tekst vervangen. VanBuren (overleg) 25 apr 2019 13:47 (CEST)
Tja, lelijk; fraai is «[wanneer?]» inderdaad niet, maar subtiel genoeg, en ook nodig. Het heeft vergelijkbare functies als «[bron?]» – de lezers (en schrijver) attenderen op een mogelijke onjuistheid/vaagheid in de tekst, en hen motiveren om de tekst te verbeteren/verduidelijken. Geheel passend binnen het project: samenwerken, uitnodigen om bij te dragen. De onderhoudssjablonen (erg veel hebben we er niet) zijn m.i. juist waardevol voor het project; je kunt ze als ontsierend beschouwen, maar ze geven wel nadrukkelijk aan dat geconstateerd is dat de betreffende tekst nog niet 'af' is. Door de sjablonen te weren, verdwijnt de uitnodiging om de tekst op een specifiek punt te verbeteren.
"Tegenwoordig" vervangen door "anno [huidige jaartal]" omdat het beschrevene toevallig de huidige situatie is, is inderdaad vaak niet een verbetering, aangezien het de verkeerde kant van een (on)zekere periode aanpakt:
  • Met termen als "tegenwoordig", "momenteel" en "heden ten dage" (en soms ook "nu") gaat het vaak om een verandering – bijvoorbeeld ten gevolge van een technologische of sociologische ontwikkeling – die op een moment (of rond een periode) in het verleden heeft plaatsgevonden. Een vervanging van zo'n term door "sinds" of "vanaf" en een zekere tijdsaanduiding (jaartal, "[de/begin/midden/eind] jaren X", "[de/begin/midden/eind] Ye eeuw"), of een aanpassing van de zin zodat met "in" of "rond" plus zo'n tijdsaanduiding de verandering zelf meer centraal gesteld wordt, haalt die onduidelijkheid/vaagheid uit de tekst.
  • Een tekst als "anno [jaartal]" betreft een geheel andere onzekerheidsfactor – is een tekst dat op een zeker moment ("anno nu") aan de encyclopedie toegevoegd wordt, over een jaar/decennium/eeuw nog wel van toepassing? – waar we niet te krampachtig over moeten doen. Uiteraard moeten termen als "dit jaar" vermeden worden, en moeten veranderlijke dingen zo min mogelijk met "nu", "momenteel" en "tot op heden" beschreven worden, maar feit is wel dat dit een levende encylopedie is: er zijn continu ontwikkelingen en veranderingen die een tekst achterhaald maken, zodat deze een update behoeft. Levende personen beschrijven we in de tegenwoordige tijd, na een overlijden veranderen we dit in verleden tijd. Een staatshoofd of politiek leider is, totdat hij/zij was en er een opvolger is. Een acteur kan prima "1960–heden" als 'jaren actief' hebben; zodra duidelijk is dat de acteur niet meer actief is, kan dat aangepast worden. Een evenement kan "elk jaar" plaatsvinden, totdat de organisatie besluit ermee te stoppen. We beschrijven zowel het verleden als de huidige toestand van allerlei zaken in wereld; alles vanuit een terugblikkend oogpunt beschrijven is zowel ondoenlijk als onrealistisch en ongeloofwaardig. Dit is een levende encyclopedie – wij weten dat, de lezers weten dat.
Een voetnoot met de datum van schrijven/toevoegen lijkt me dubbelop (daarvoor zijn de bewerkingsgeschiedenissen) en een waarschuwing als "kan ondertussen zijn veranderd" lijkt me overbodig (dat volgt al uit de aard van het project). Voor erg veranderlijke statistieken (zoals inwonersaantallen, en standen en ranglijstposities in de sportwereld) is het echter wel goed om dit met een jaartal of een "standen bijgewerkt t/m [datum]" te duiden, zoals al veel gedaan wordt.
Met vriendelijke groeten — Mar(c). [O] 25 apr 2019 16:22 (CEST)
Los van de discussie over het door bots markeren van vage tijdsaanduidingen: voor zover ik weet zijn er twee toepassingen van een tekst als "anno [jaartal]":
  • Er staat iets als "In [jaartal] is [onderwerp] [functie] bij [organisatie]." Ik zie geregeld dat soort jaartallen gewijzigd worden van vroeger naar het huidige jaar. Dit is niet te onderscheiden van "Tegenwoordig is [onderwerp] [functie] bij [organisatie]". Mij lijkt dat ongewenst en ik vervang zulke teksten met enige regelmaat door: "[onderwerp] is [functie] bij [organisatie]." Minder dan volmaakt, maar als [onderwerp] er mee ophoudt moet het in alle gevallen gewijzigd worden en niet elk jaar.
  • Er staat iets als "Sinds [jaartal] is [onderwerp] [functie] bij [organisatie]." Dit is, denk ik, volstrekt aanvaardbaar.
Het woordje 'anno' vind ik niet de beste woordkeus, maar dat is niet het onderwerp. Met vriendelijke groet, Magere Hein (overleg) 25 apr 2019 18:27 (CEST)

@Saschaporsche: zou je nog willen reageren op de lijst met opmerkingen hierboven? Ik zal later eens kijken of het toevoegen van "decennium" etc niet netzoveel werk is als het helemaal oplossen. Puur de hoeveelheid van vage aanduidingen maakt het zo een rijstebrijberg voor één persoon. Vandaar dat ik als hulpmiddel AWB gebruik. Elly (overleg) 3 mei 2019 08:05 (CEST)

Sjabloon Link waarneming.nl[bewerken]

Hallo medebewerkers,

Omdat er geen sjablooncafé is maak ik deze opmerking hier. Als iemand denkt dat dit beter ergens anders kan staan, hoor ik dat graag.

Op pagina Peper-en-zoutvlinder kwam ik er achter dat {{Link waarneming.nl}} stuk is, naar ik vermoed door verherbouwing van de webstek waarneming.nl. Het sjabloon verwijst in het voorbeeld naar https://waarneming.nl/soort/maps/8396 - die pagina is volstrekt 404-compatibel. Die kaarten bestaan nog wel, onder URL https://waarneming.nl/species/8396/maps/ . Die url geeft trouwens een akelig zoom-niveau. Iets dergelijks is aan de hand met de URL voor België, maar die heb ik verder niet onderzocht.

Nu heb ik geen bijzonder verstand van sjablonen en ik ben bang dat ik dingen ondoordacht stuk maak. Graag advies of hulp.

Met vriendelijke groet, Magere Hein (overleg) 8 apr 2019 12:04 (CEST)

Volgens de inleiding is het ICT-café ook bedoeld als sjablonencafé. Encycloon (overleg) 8 apr 2019 12:42 (CEST)
Ik heb dit bericht ook daar geplaatst. Het is niet onopgemerkt gebleven. Groet, Magere Hein (overleg) 8 apr 2019 13:18 (CEST)

Doorverwijspagina-sjablonen[bewerken]

Hallo,

(Ik stel de vraag of probleemstelling eerst in dit redactiekanaal, want afhankelijk van de uitkomst zal het probleem moeten worden aangekaart op een OP. een ander café, of op een verzoekpagina.)

Ik heb vastgesteld vastgesteld dat de sjablonen {{dpintro}} en {{dp}} – als er géén parameters worden meegegeven – blijkbaar (nog) niet zo 'slim' zijn dat zij de naamruimte (of prefix-path, zo je wilt) van de paginanaam 'strippen', en ook niet het achtervoegsel " (doorverwijspagina)" (inclusief scheidende spatie) verwijderen. Dat kan dan leiden tot vreemde effecten, in dit concrete voorbeeld (waarbij in {{dpintro}} wel van een parameter was voorzien, maar in het afsluitende sjabloon {{dp}} dus niet) leidt dit tot de zin:

"Bekijk alle artikelen waarvan de titel begint met Staart (doorverwijspagina) of met Staart (doorverwijspagina) in de titel."

In dit specifieke geval heb ik ook in het afsluitende dpintro een (correcte) parameter ingevoerd, maar ik weet niet of en zo ja bij welke doorverwijspagina's die " (doorverwijspagina)" in de paginanaam hebben staan dit probleem zich ook voordoet (d.w.z., met mijn (speciale) zoekpogingen heb ik er nog geen kunnen vinden, maar dat betekent niet dat ze niet bestaan – ik kan me niet voorstellen dat het bovengenoemde voorbeeld dat ik bij toeval tegenkwam de enige dp-pagina is waar dit 'fout gaat'.

Volgens mij is dit – als structurele aanpak nodig wordt geacht – op twee manieren op te lossen:

  1. Botmatig:
    1. Ik kan een bot-verzoek indienen om pagina's in de HNR op te sporen die het achtervoegsel " (doorverwijspagina)" in de naam hebben (en eventueel een prefix-path) op te sporen, en een lijst te genereren met artikelen waar de {dp*}-sjablonen worden gebruikt zonder parameter(s), hetgeen een inventarisatie geeft;
    2. Al dan niet, afhankelijk van het (aantal) resulta(a)t(en), deze handmatig of bot-matig met slimme regexp-/vervangingsstrategieën aan te passen waar dat nodig is.
  2. Systematischer en structureler zouden echter de sjablonen {{dpintro}} en het afsluitende {{dp}} slimmer gemaakt worden (m.b.v. een ander sjabloon en/of query functie, die een eventuele prefix en het letterlijke achtervoegsel " (doorverwijspagina) on-the-fly wegknippen/strippen van de paginanaam wanneer er geen expliciete parameter(s) zijn meegegeven.

Dat laatste is structureler en toekomstbestendig, maar zal wel een zwaardere belasting zijn tijdens het parsen. Zo'n bot-verzoek of -zoektocht (inventarisatie met eventueel automagische correcties) moet dan wel periodiek opnieuw worden uitgevoerd.

Afhankelijk van de respons/overeenstemming in overleg alhier zal dus een bot-verzoek ingediend moeten worden (voor aanpak #1), dan wel een verzoek worden gedaan (in ICT-café of op de OP van de beide sjablonen) om het sjabloon 'slimmer' te maken (voor aanpak #2), vooropgesteld dat het probleem zoals ik heb ervaren en hier heb geschetst zich daadwerkelijk (in hoge aantallen) voordoet, en dat iedereen dat ook opgelost wil zien.
Graag jullie visies/constateringen/suggesties (misschien dat iemand met AWK (waar ik zelf tijdelijk niet de beschikking over heb) wel alvast een inventarisatie kan of een zuivere inschatting kan maken van het aantal pagina's waar dit mogelijk speelt (er is een limiet – ik meen 10.000 – aan het aantal resultaten zit wanneer er via een (geavanceerde) zoekfunctie via de wiki-interface wordt gezocht. Mvg -- martix (overleg) 18 apr 2019 02:11 (CEST)

Ik vind dat het niet nodig zou moeten zijn om de parameter op te geven bij titels die eindigen op (doorverwijspagina). Het is niet moeilijk om te maken en de parser-belasting is niet significant, want dp's worden niet veel bewerkt en we hebben er maar 80 duizend. In de meest recente dump vond ik er 50 waarbij het fout gaat. –bdijkstra (overleg) 18 apr 2019 09:52 (CEST)
@Bdijkstra: Dank voor de reactie alsook meteen een relatief betrouwbare hit-count; het euvel doet zich dus slechts in circa 0,0625% van de gevallen voor, dat zijn er gelukkig niet heel veel (nagenoeg verwaarloosbaar) die desnoods nog correctief handmatig kunnen worden aangepast (aan de hand van een courante lijst), maar omwille van de toekomstbestendigheid lijkt mij een 'slimmer gedrag' van het sjabloon ook wenselijk(er).
Er zullen trouwens wellicht ook DP's zijn die (desondanks nog) geen dp[intro]-sjablonen gebruiken: ik heb er zelf ooit eens 1 of 2 aangemaakt (niet noodzakelijkerwijs met achtervoegsel " (doorverwijzing)") toen ik nog niet gewis was van de parameter-mogelijkheden, waarbij ik een van de {{dp}} of (vaker/waarschijnlijker zelfs) {{dpintro}} sjablonen 'handmatig heb uitgeschreven'. Of anders gezegd, er zijn mogelijk/waarschijnlijk ook doorverwijspagina's, die niet als zodanig aan de titel te herkennen zijn (en/of ook niet in de dp-categorie staan), (omdat) die nog geen sjablonen (of maar 1 van de 2 sjablonen) gebruiken. Een zoekopdracht naar het kenmerkende "kan verwijzen naar" en/of "zoek (..)" om te controleren of ze er zijn en hoeveel is misschien ook zinvol?
Met betrekking tot het eerst aangekaarte verschijnsel (waarbij het sjabloon het achtervoegsel niet stript):
  • zou voor een sjabloon-verbetering dan even een prefixed path (of naamruimte) ook gestript dienen te worden, of zijn er (naamruimte-redenen) om dat deel wel te behouden?
  • is het nu nog nodig om op de OP van de sjablonen of in het ICT-café het verzoek tot aanpassingen te doen, of kan ik dit (door de melding hier) nu al beschouwen als 'wordt (t.z.t.) opgepakt'?
Een algemenere vraag die mij later te binnen schoot n.a.v. dit verschijnsel: is of bestaat er eigenlijk al een sjabloon (met/of een query), of een magic word die de (huidge) pagina-naam (al dan niet gestript of ontdaan van delen van de naam) weergeeft na parsen? Mvg -- martix (overleg) 18 apr 2019 14:34 (CEST)
Met "kan verwijzen naar" vond ik 12 semi-dp's, lijkt me niet echt de moeite waard. Wellicht kan je beter je eigen bijdragen nalopen. Er is maar 1 'echte' dp buiten de hoofdnaamruimte, dus ook een non-issue. Het zou goed kunnen dat ik er dit weekeinde mee bezig ga, maar als het te lang duurt is het goed om alsnog een verzoek te doen. Afhankelijk van wat je precies bedoelt met "pagina-naam" en waar je het voor wilt gebruiken zijn er verschillende magische woorden, zie mw:Help:Magic words#Page names. Een aantal hiervan worden ook gebruikt op {{dp}}. –bdijkstra (overleg) 18 apr 2019 16:00 (CEST)
Weinig gedaan dit weekeinde, maar vandaag wel vijf dp's gevonden die {{dp}} niet gebruikten: 1 2 3 4 5. –bdijkstra (overleg) 23 apr 2019 22:37 (CEST)

Notatie van rangtelwoorden[bewerken]

L.S.,
Ik zag net deze wijziging met als commentaar o.a. rangtelwoorden niet met superscript. Nu schrijf ik bijvoorbeeld zelf liever 16e in plaats van 16e. Staat een bepaalde notatievorm voor Wikipedia-artikelen ergens beschreven in een richtlijn? Zo ja, waar?
Met vriendelijke groet, JoostB (overleg) 2 mei 2019 18:35 (CEST)

Ik dacht eigenlijk dat dat BTNI zou zijn, maar de Taalunie meldt in dit advies dat de achtervoegsels op dezelfde hoogte staan met de getallen: [1]. Meestal volgen we de Taalunie in spellingzaken (al is dat mogelijk niet heel hard vastgelegd). Nu kun je natuurlijk zeggen dat dit niet de spelling betreft maar uitsluitend de typografie, en dan valt dit advies niet onder het gebruikelijke volgen van de Nederlandse Taalunie. Paul B (overleg) 2 mei 2019 18:46 (CEST)
P.S. Mogelijk is dit ook iets voor het Wikipedia:Taalcafé. Wellicht kan daar worden verwezen naar deze discussie. Paul B (overleg) 2 mei 2019 18:47 (CEST)
Dat is inderdaad het taaladvies waar ik me op baseer. Ik zal die link erbij noemen als ik zoiets weer wijzig. 'Vroeger' was ik ook gewend om een superscript-e te schrijven (met de hand), maar blijkbaar is het niet (meer) gebruikelijk om het zo te doen. Ik kom ze overigens niet vaak tegen; sinds afgelopen oktober (een reeks artikelen over biljarters) slechts een handvol keer. Met vriendelijke groeten — Mar(c). [O] 3 mei 2019 08:03 (CEST)

Infobox land plus (sjabloon) foutmelding(en)[bewerken]

Deze kwestie t.a.v. de foutmelding is uiteengezet in "De Nulmeridiaan" (Geografie-café).
Graag aldaar eventuele reacties plaatsen/meediscussiëren, en hier geen bijdragen plaatsen. Groeten -- martix (overleg) 10 mei 2019 15:30 (CEST)

Kleurenboxen[bewerken]

Heeft iemand een idee hoe ik dit werkend krijg op de NL-wikipedia? Het geheel moet liefst ook in een uitklapbare tabel te verwerken zijn. Ik zou er erg mee geholpen zijn. -B kimmel (overleg) 21 mei 2019 19:02 (CEST) PS: een link geven naar een artikel met dergelijke boxen mag ook hoor.

Misschien {{Legenda}}? Mvg, Flag of Belgium (civil).svg TheDragonhunter | Vragen? 21 mei 2019 20:10 (CEST)
Bedankt, die kende ik nog niet! Groet, -B kimmel (overleg) 22 mei 2019 07:32 (CEST)

Links naar het verkeerde hertogdom Lauenburg in sjablonen[bewerken]

Door het aanmaken van het artikel Hertogdom Lauenburg(1815-1876) moesten alle verwijzingen naar het Hertogdom Saksen-Lauenburg uit de periode tussen 1815 en 1876 wat mij betreft naar het nieuwe artikel verwijzen. Dit leek mij het makkelijkst door de links in de navigatiesjablonen duitse Bond en het Duitse keizerrijk, waarin alle lidstaten van de Duitse bond en het Duitse keizerrijk staan, te wijzigen. Nadat ik de wijzigingen in de twee navigatiesjablonen had doorgevoerd bekkeek ik de speciale pagina met links naar de pagina hertogdom Saksen-Lauenburg en daar stonden alle alle artikelen die in die twee sjablonen vermeld staan waar ik niks van begrijp omdat in de lopende tekst van die zestig artikelen geen link naar Lauenburg of Saksen-Lauenburg zag staan. Er staan ook verwijzingen tussen naar pagina’s waar het zijbalk met artikelen over de Sleeswijk-Holsteinsekwestie gevoerd wordt en ook de link naar Lauenburg op dit sjabloon heb ik aangepast maar de pagina’s staan tot mijn verbazing nog steeds op de lijst met artikelen die verwijzen naar het hertogdom Saksen-Lauenburg. Nu vraag ik me af of iemand dit kan aanpassen waardoor de links in de artikelen die de periode van 1815 tot 1876 beschrijven zo kan aanpassen dat ze niet meer naar het in 1803 opgeheven hertogdom Saksen-Lauenburg verwijzen. Met vriedelijke groet, Bean 19 (overleg) 3 jul 2019 16:28 (CEST)

Het kan even duren voordat die speciale pagina is bijgewerkt, soms wel meer dan 10 minuten. –bdijkstra (overleg) 3 jul 2019 16:36 (CEST)
Het gaat om bewerkingen die ik op 10 juni en op 15 juni heb gedaan dus dat is langer dan tien Minuten geleden. Bean 19 (overleg) 3 jul 2019 17:14 (CEST)
Vorige maand waren er wat problemen met de wikisoftware waardoor de linktabellen niet goed werden bijgewerkt. Dit is per pagina te repareren met een null-edit (pagina bewerken en opslaan zonder wijzigingen), wat handmatig kan of met een bot. –bdijkstra (overleg) 3 jul 2019 17:48 (CEST)
Die bewerking heeft inderdaad het gewenste resultaat opgeleverd waardoor er ongeveer honderd links van de lijst met verwijzingen af zijn gegaan. Bedankt, Bean 19 (overleg) 3 jul 2019 20:50 (CEST)