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


Categorie "Lagekostenmaatschappij"[bewerken]

Op de Overlegpagina van categorie "Lagekostenmaatschappij" heb ik al het volgende gevraagd/voorgesteld:

"Zou deze categorie niet beter "Lagekostenluchtvaartmaatschappij" genoemd kunnen worden, analoog aan het artikel "Lagekostenluchtvaartmaatschappij", en bovendien de logische uitkomst van 'categorie-ketting/-boom', waarvan nu een tak of verwijzing 'Luchtvaartmaatschappij' --> 'lagekostenmaatschappij' er wat inconsistent uitziet (en idem voor alle sub-categorieën van deze categorie?

Niet dat de kilometervreter 'lagekostenluchtvaartmaatschappij' of een subcategorie met de naam 'Noord-Amerikaanse lagekostenluchtvaartmaatschappij' nou zo gemakkelijk van de tong rolt, maar consistentie is met de huidige (sub)categorienamen nu niet optimaal, en de betekenis/context met de luchtvaart is 'opeens' ook zomaar verdwenen uit de categorienaam?"

Het leek me hier de juiste plek om daar de aandacht voor te vragen.. Met vriendelijke groet -- martix (overleg) 9 jun 2018 21:09 (CEST)

"Voordeelvliegfirma"? Glimlach In elk geval is de huidige benaming inderdaad te weinig specifiek. Jürgen Eissink (overleg) 9 jun 2018 21:37 (CEST).
(na bwc) En dat kan er inderdaad voor zorgen dat deze categorie of diens subcategorieën door goed-bedoelende gebruikers in artikelen terecht komt van andere maatschappijen (met een budget-formule) maar die niets met luchtvaart te maken hebben (bijvoorbeeld in artikelen over onderwerpen als de Action-keten of confectie-bedrijven ofzo) -- martix (overleg) 9 jun 2018 21:51 (CEST)
De Van Dale kent in ieder geval de (nogal lange) "bud­get­lucht­vaart­maat­schap­pij" (en de lagekostenmaatschappij, low­cost­maat­schap­pij en lowcoster maar die hebben alle het al geschetste probleem). Wellicht is dus bud­get­lucht­vaart­maat­schap­pij een optie? Paul B (overleg) 9 jun 2018 21:49 (CEST)
Volgens mij hebben "luchtvaartmaatschappij" en "vliegmaatschappij" dezelfde betekenis, dat scheelt ook al wat letters.... -- martix (overleg) 9 jun 2018 21:55 (CEST)
Goed, ik weet dat de pagina "Wikipedia:Te beoordelen categorieën" bedoeld is om het hernoemen van categorieën te laten afhandelen, maar ik kan daar nog geen voorstel of verzoek plaatsen als we het niet eens zijn. Héél erg dat een categorienaam lang wordt is het ook weer niet, alleen in dit geval valt het bijzonder op omdat de categorienaam dan uit één woord bestaat (net als het gelijknamige lemma) "Lagekostenluchtvaartmaatschappij" (of eventueel korter, "lagekostenvliegmaatschappij" of "budgetvliegmaatschappij". Maar er zijn natuurlijk in feite al categorienamen met véél langere namen doordat de categorienaam een complete zin of omschrijving (woordgroep) is, zoals "Bekende acteurs die tussen 1930 en 1040 vlinderdasjes droegen en zelf konden strikken" (ok ik overdrijf een beetje maar er zitten er wel een paar tussen die veel langer zijn dan dat deze categorienaam dan zou worden, en ook nog langer dan hoe de sub-categorienamen zouden worden (zoals "Noord-Amerikaanse lagekostenluchtvaartmaatschappij").

Consistentie lijkt me het belangrijkst. Als we hier naar kortere namen toe willen (bijvoorbeeld categorie "budgetvliegmaatschappij" dan lijkt het me evident dat het artikel "Lagekostenluchtvaartmaatschappij" ook omgedoopt moet worden naar "budgetvliegmaatschappij", waarna vervolgens de categorie in kwestie en alle subcategorieën ("Noord-Geofrafische [....]maatschappij" of "[....]maatschappij in Geografische Naam" e.d. kunnen worden omgedoopd.

Een kortere naam is een "nice to have", maar de consistentie in de namen is een "must have" lijkt me en heeft hogere prioriteit/is urgenter (en het artikel "Lagekostenluchtvaartmaatschappij" is er nu eenmaal ook al. (En uiteindelijk worden de (volledige) namen van de categorieën nu eenmaal weinig in de spreektaal gebruikt, hier op Wikipedia gaat het voor zover ik kan overzien erom dat:

  1. het beestje een naam heeft;
  2. dat de vlag de lading dekt; en
  3. dat er zoveel mogelijk consistentie is tussen de (verwante (child of parent) categorienamen én eventueel gelijkluidende artikelen met dezelfde naam als een categorie (wat nu niet het geval is).

Zal ik maar gewoon op de pagina "Wikipedia:Te beoordelen categorieën" een verzoek inschieten om de categorie als volgt om te dopen:

Van: Naar:
"Categorie:Lagekostenmaatschappij" "Categorie:Lagekostenluchtvaartmaatschappij"

alsmede voor alle (gelijknamige/gelijkluidende subcategorieën die eronder vallen (zoals, maar niet uitsluitend:

Van: Naar:
"Categorie:Noord-Amerikaanse lagekostenmaatschappij" "Categorie:Noord-Amerikaanse lagekostenluchtvaartmaatschappij"
"Categorie:Zuid-Amerikaanse lagekostenmaatschappij" "Categorie:Zuid-Amerikaanse lagekostenluchtvaartmaatschappij"
"Categorie:Europese lagekostenmaatschappij" "Categorie:Europese lagekostenluchtvaartmaatschappij"
"Categorie:..... lagekostenmaatschappij" "Categorie:..... lagekostenluchtvaartmaatschappij"

enzovoorts?)

(Zou het verwijzen naar gelijknamige subcategorieën voldoende zijn, of moet elke subcategorie waarin dan "(...) lagekostenmaatschappij" hernoemd zal moeten worden naar "(...) lagekostenluchtvaartmaatschappij" apart genoemd/"genomineerd" moeten worden op die TBC-pagina?

met vriendelijke groet, -- martix (overleg) 12 jun 2018 04:39 (CEST)

Met 'lagekostenmaatschappij' of 'lowcostmaatschappij' wordt volgens de Van Dale uitsluitend gedoeld op budgetluchtvaartmaatschappijen, dus ik zie niet in waarom dat zou moeten worden veranderd in 'lagekostenluchtvaartmaatschappij'. Dat de term te weinig specifiek is klopt niet, want het gebruik ervan beperkt zich kennelijk tot de luchtvaartsector. (Bovendien staat deze subcategorie in de categorie 'Luchtvaartmaatschappij'.) Je kan beter het artikel hernoemen als je consistentie echt belangrijk vindt. Jeroen N (overleg) 17 jun 2018 16:13 (CEST)
Staat het woord in de vijftiende editie van Van Dale? Dat verbaast mij. Jürgen Eissink (overleg) 17 jun 2018 17:20 (CEST).
De Van Dale mag er dan misschien een ondubbelzinnige betekenis aan verbinden/over definiëren, maar (lang) niet elke lezer heeft die kennis en/of de Van Dale paraat/ter beschikking. Wat is er op tegen om de ondubbelzinnigheid en context – dat het dus uitsluitend betrekking heeft op luchtvaartmaatschappijen – meteen te laten blijken door de categorienaam als dat kan? Er zijn uiteindelijk wel langere categorienamen. -- martix (overleg) 17 jun 2018 17:23 (CEST)
Dit loopt nu al langer dan een week, ik zou maar eens een knoop doorhakken en een verzoek indienen, als ik jou was. De moderator van dienst zal het dan, beargumenteerd, afhandelen. Afwachten tot de een hier ja en de ander nee zegt heeft geen enkele zin. Jürgen Eissink (overleg) 17 jun 2018 17:29 (CEST).
Een week is helemaal niet lang. Is hier haast geboden? Vergeet ook niet dat maar weinig mensen bekend zijn met het 'redactielokaal'. Jeroen N (overleg) 17 jun 2018 18:43 (CEST)
Des te meer reden om de discussie naar elders te verplaatsen. En ik verzoek je je toon iets te temperen, want het is ietwat vervreemdend om me door jou uit te zien maken voor snotneus. Jürgen Eissink (overleg) 17 jun 2018 19:08 (CEST).
Misschien zou het niet zo bevreemdend zijn als je niet zo snel al was vergeten dat jij mij een wijsneus noemde. Jeroen N (overleg) 17 jun 2018 19:13 (CEST)
Als reactie op jouw opmerking in de bewerkingssamenvatting, ja. Jürgen Eissink (overleg) 17 jun 2018 19:15 (CEST).
Ja, dat woord staat in de vijftiende editie van de Van Dale. Als een lezer niet weet wat 'lagekostenmaatschappij' betekent moet hij een woordenboek aanschaffen. Het lijkt me niet de bedoeling om bij de keuze van categorienamen af te wijken van gangbare bewoordingen met het doel om niet zo snuggere lezers te onderwijzen. Jeroen N (overleg) 17 jun 2018 18:19 (CEST)
Als het tussenvoegen van het woord(deel) 'luchtvaart' de context verduidelijkt, en daarmee dan een nog steeds correct Nederlandstalig woord wordt gebruikt, én daarmee dan bovendien de kennis en/of inzichten van de (door jou genoemde "niet zo snuggere gebruikers" – die kwalificatie laat ik geheel voor jouw eigen rekening) lezers vergroot, of anders gezegd, "hen onderwijst", dat lijkt me dat een uitstekende reden om het juist wél op voorgestelde wijze te doen. Dit is immers een encyclopedie met als één van de doelen dat leers en gebruikers kennis en informatie kunnen opdoen, en als de contextuele kennis dan door één oogopslag kan worden vergroot bij één of meer lezers is dat (ook) winst, terwijl er – behalve dat er dan iets langere woorden en dus categorienamen ontstaan – geen andere inhoudelijke bezwaren zijn aangevoerd dan dat jij erop tegen bent, omdat de Van Dale zegt dat 'lagekostenmaatschappij' ook goed is). Bovendien zie ik het niet als afwijken van een benaming of norm (welke dan?), maar simpelweg wijzigen naar een andere naam die ook in de woordenlijst staat. Waar zouden we van afwijken met de voorgestelde hernoeming?
Gesterkt door Jürgen Eissinks suggestie hierboven zal ik morgen dan ook één of meerdere verzoeken (zoveel als nodig blijkt) zoals voorgesteld op de daartoe aangewezen plek (TBC) binnen Wikipedia plaatsen, zodat dan en daar de discussie zo nodig kan worden voortgezet, en t.z.t. een moderator een besluit kan nemen en eventueel uitvoeren. -- martix (overleg) 18 jun 2018 03:20 (CEST)
1rightarrow blue.svg Zie ook de nominatie WP:TBC 18 juni 2018 -- martix (overleg) 18 jun 2018 07:01 (CEST)
Dit is inmiddels alweer even terug Uitgevoerd Uitgevoerd doorKippenvlees1, waarvoor dank -- martix (overleg) 1 dec 2018 10:51 (CET)

Harde spatie in referentie[bewerken]

In deze wijziging wordt 17 keer een harde spatie toegevoegd in referenties en voetnoten. Daarmee worden taalelementen bijeen gehouden, zoals "p. 125" (pagina), "Willen II", "100 000" (spatie = ISO-norm). Is dat wenselijk, of zelfs zeer wenselijk, of juist niet? We willen in de hoofdnaamruimte zo min mogelijk codes, maar bij de referenties is dat misschien net anders. En argument is dat afkortingen in referenties vaak wenselijk zijn wegens ruimtegebrek en het bewaren van overzicht, duidelijkheid of uniformiteit. Jasper Kloekmoed  [!?]  20 okt 2018 22:41 (CEST)

@Jasper Kloekmoed: Een wat late reactie: in een enkel geval is de no-break space/non-breaking space (" ") prima, maar in het algemeen verdient het de voorkeur om het sjabloon {{nowrap|Willem II}} te gebruiken, omdat dat de wiki(bron)tekst dan (meestal) beter te lezen is, en je dan gewoon gebruik kan maken van normale spaties in de brontekst, en het (zo effectief mogelijk) parsen ervan aan de server-zijde overlaat. Het is wel zo dat de html-code ( ) 6 karakters in beslag neemt (per 'no-break space'), tegen tenminste 11 (4 accolades (2x '{' en 2x '}'), de pipe ('|') en het woord 'nowrap') wanneer het {{nowrap}}-sjabloon gebruikt wordt; bij 2 of meer spaties is het daarmee wel al efficiënter. Ik heb wel gemerkt dat het nowrap-sjabloon op sommige plekken niet of niet goed werkt (ik meen binnen sommige andere andere sjablonen; ik heb geen voorbeeld voor handen, maar ik meen dat in sommige infobox- of citeer/citaat-sjablonen niet (altijd) werkt zoals verwacht/geen effect heeft of tot merkwaardige resultaten leidt; in die gevallen kan men terugvallen op de html-code voor de 'harde spatie'. In enkele zeldzame gevallen kan het ook voorkomen dat het {{nowrap}}-sjabloon binnen andere sjablonen de brontekst juist minder makkelijk leesbaar maakt (maar hangt meestal samen met het gebruik van spatiëring en regelafbreking binnen sjablonen tussen de parameters en de '=' en '|' karakters (regelafbreking achter elke parameter maakt ingevulde sjablonen beter leesbaar, maar maakt de brontekst weer 'langer' en dan is minder duidelijk welke alinea's en paragrafen wel en niet bij elkaar horen, etc.). Groeten -- martix (overleg) 7 dec 2018 11:43 (CET)
@martix Dankjewel voor je uitleg. Het hele {{nowrap}}-sjabloon kende ik niet. Maar blijkbaar wordt de "vaste spatie" op Wikipedia waar wenselijk ook gefaciliteerd op onze eigen manier. En ja, werkt dat niet goed, dan kies je de beste uit de overige opties. Jasper Kloekmoed  [!?]  8 dec 2018 18:20 (CET)
@Jasper Kloekmoed: (voor dat '@<gebruikersnaam>' hebben we overigens ook het {{ping|gebruikersnaam}}-sjabloon Glimlach), nog even terugkomend op de bewerking waarnaar je in de eerste zin naar verwees: in dat geval denk ik dat het vanwege de meerdere spaties in groep van bij elkaar horende tekens/gegevens, het wel wenselijk is om – voor zover/alleen indien het daar werkt – dáár wel wenselijk is om het {{nowrap}}-sjabloon te gebruiken. In infoboxen is het soms (wanneer je bij een veld meerdere namen/gegevens wilt opgeven, of niet ontkomt aan lange zinnen) aan te raden om van geforceerde regelafbreking (<cr />) en harde spaties te gebruiken (hetzij met nowrap, hetzij met de html-code), om te leesbaarheid en het effect te bekijken, bij voorkeur bij verschillende schermresoluties en zoom factors om te zien of en hoe het er met die verschillende (scherm=-/browser)instellingen uitziet zonder en met geforceerde opmaak. Datzelfde geldt voor captions/onderschriften en zoals je al opmerkte, ook bij referenties. Het is wel zo dat als je gebruik gaat maken van {{Citeer web}} en andere citeer-sjablonen, en daarin veel parameters invult (lees: de lezer van meer informatie over de bron voorziet), een referentie al snel niet meer op één regel past en je niet ontkomt aan een regelafbreking (en daarmee ook de noodzaak voor harde spaties, in welke vorm dan ook, wenselijk kan zijn). Soms kun je (zie info- en taxoboxen) invulling van sjablonen leesbaarder maken door elke parameter op een nieuwe regel te beginnen; ik doe het met uitvoerig ingevulde {citeer}-sjablonen wel eens, maar dat kan wel eens vragen of verwondering oproepen. Je kan bij/binnen de parameters infoboxen eventueel ook gebruik maken van <div> en </div>-tags (zie bijvoorbeeld het artikel Spirit Airlines, waar ik dat heb gedaan – probeer maar eens met een bewerkingsvoorbeeld (alleen) de (regels met de) div's en /div's weg te halen voor het effect) om meerdere waarden te groeperen tot 1 html-entity als parameter; dat soort dingen blijven volgens mij altijd 'stuivertje wisselen' t.a.v. het uiteindelijke effect bij de lezers (onder verschillende scherm(resolutie)-, browser-, en zoom-instellingen) en/of de leesbaarheid en schrijfgemak van wiki-brontekst. Dat alles speelt natuurlijk in de VE een stuk minder.
Tot slot: "100 000" mag dan wel een ISO-standaard zijn, maar omdat het een Nederlandstalige Wikipedia is, is er helemaal niets op tegen om ook de cijfer- en getallennotatie (alsmede datum- en tijdnotatie) zoals voorgeschreven door de Taalunie of (wanneer deze niet voorziet), advies van Genootschap Onze Taal te gebruiken; De computer- of software-instellingen geven weliswaar de mogelijkheid om taal- en regio-instellingen los van elkaar (en zijn dus niet onlosmakelijk met elkaar verbonden) in te stellen, maar volgens mij voorzien de taalregels van het (standaard)Nederlands alleen in een Nederlandstalige notatie (en staan die regels ISO-notaties aanvullend, maar niet noodzakelijk met preferentie, toe). De vraag is of en waar dat zinvol is en/of de voorkeur heeft. Groeten, -- martix (overleg) 8 dec 2018 22:36 (CET)
Insomnia update, 9 dec 2018 04:07 (CET) @Jasper Kloekmoed: N.B.: Met behulp van harde spaties/non-breaking space kun je ook overigens ook (zeker bij beperkte horizontale ruimte, of eigenlijk het altijd wel gewenste fenomeen) van een soort "weduwen- en wezen"-bescherming (maar dan meer op 'woord'- niveau i.p.v. regelniveau) forceren/simuleren door voor de allerlaatste spatie in een paragraaf of alinea altijd een harde spatie te gebruiken (of de laatste twee woorden of de laatste woordgroep – zeker bij vaste verbindingen – te groeperen in een {{nowrap}}-sjabloon. Ik heb dat bijvoorbeeld in de tabel in dit kopje gedaan (omdat in de praktijk in de opmaak relatief vaak het laatste woord van een passage of de zin(nen) in een tabelcel als een enkel woord zielig alleen op de laatste regel kwam te staan (als een soort woord-hoerenjong. Veelal is dat een optie in tekstverwerkers die je aan of uit kan zetten, en voorkomt de software dan dat een enkel (het laatste) woord op een nieuwe regel komt. Strikt genomen verwijzen 'weeskind', "weduwe' en/of "hoerenjong" naar begrippen die op de eerste of laatste zinnen betrekking hebben – in relatie tot pagina's –, maar je kunt je de context, op woord-niveau – in relatie tot regels – ook wel voorstellen (al zal dat mogelijk anders heten; als het een (andere) naam heeft, ken ik het (nog) niet in die context (en ik verkeerde altijd in de veronderstelling dat het verschijnsel dezelfde naam heeft, maar er wordt in onze artikelen niet over gerept).
Het is goed mogelijk dat er (net als in tekstverwerker-software) tweaks, tags, andere sjablonen of gebruikers instellingen in Wikipedia zoiets automatisch kunnen voorkomen, maar (zoals hieronder ook blijkt), weet ik niet overal alles van, en ken ook beslist niet alle mogelijke sjablonen en/of aan te vinken features en instellingen van Wikipedia, en leer ook nog dagelijks bij. Groeten -- martix (overleg) 9 dec 2018 04:07 (CET)
De Taalunie stelt hier als bijzonderheid: Getallen en bedragen mogen niet worden afgebroken. Om te voorkomen dat dat bij het gebruik van spaties toch gebeurt, is het raadzaam in computerbestanden gebruik te maken van zogeheten 'harde spaties'. Mvg, Trewal 8 dec 2018 22:49 (CET)
@Trewal: kijk, dat wist ik dan weer niet, en dat is weer het nieuwe feitje voor vandaag Glimlach – dank voor de verwijzing! (Eerlijk gezegd verbaast het me een beetje dat de Taalunie zo courant is hiermee). Maar is het dan/toch niet zo dat een punt als scheidingsteken voor duizendtallen nog voorkeur heeft in de voorschriften of taaladviezen? (Volgens mij zal een punt – er even vanuit gaande dat deze (met of zonder prevalentie) nog is toegestaan als scheidingsteken van duizendtallen – in het gemeen immers ook niet zal leiden tot regelafbreking, vermits alle cijfers, de decimale komma en de punt ('.') als het scheidingsteken volledig aan elkaar geschreven zijn, en er voldoende horizontale ruimte is? (Bij gebrek aan horizontale ruimte kan afbreking op onverwachte plekken geschieden natuurlijk, of mogelijk zal zelfs "de zin het beeld uitlopen", afhankelijk van de – interpretatie van de – interface). Of heeft geen van tweeën voorkeur over de ander? (In feite is dan natuurlijk sprake van de harde spatie als scheidingsteken van duizendtallen; schrijft de ISO-standaard eigenlijk al niet specifiek de non-breaking space voor, of wordt de vorm van de (horizontale) spatie in het midden gelaten? Groeten -- martix (overleg) 8 dec 2018 23:41 (CET)
De Taalunie schrijft expliciet dat getallen en bedragen niet mogen worden afgebroken. Of ISO er ook wat van zegt is dan irrelevant. Mvg, Trewal 9 dec 2018 00:20 (CET)

────────────────────────────────────────────────────────────────────────────────────────────────────Dat is niet helemaal een antwoord op mijn (waarschijnlijk te vaag/te omslachtig geformuleerde) vraag ("Welk teken/karakter wordt geprefereerd als scheidingsteken voor duizendtallen?"). Dat (regel)afbreking van getallen niet mag en voorkomen dient te worden is (immers) de aanleiding van de oorspronkelijke vraag hier. Maar ik heb het antwoord/advies van de Taalunie inmiddels in hetzelfde taaladvies gevonden. Groeten -- martix (overleg) 9 dec 2018 01:11 (CET)

Resumerend kun je in elk gevallen stellen dat de "vaste spatie" in courante tekst wel eens wenslijk kan zijn olgens de Talunnie, en dus hier ook gebruikt zou kunnen worden in hoofdnaamruimte, met waar mogelijk een wikisjabloon dat gebruikers met enige ervaring wel begrijpen of op kunnen zoeken voor uitleg. Ik zal er iets scheutiger mee zijn, en ik blij met de helderheid en nieuwe "feitjes". Jasper Kloekmoed  [!?]  9 dec 2018 13:22 (CET)
@Jasper Kloekmoed: Klopt helemaal; over het {{nowrap}}-sjabloon valt overigens verder nog wel op te merken dat het op alle karakters binnen het sjabloon werkt, dus ook op (afbreek)streepjes/koppeltekens, het karakter "-" dus, die zonder ingrijpen ook tot een regelafbreking na het streepje kunnen leiden(!). Het alternatief daarvoor (i.p.v. het nowrap-sjabloon) is de 'non-breaking hyphen' ('‑'): html-codes &#8209; (decimaal) of &#x2011; (hexadecimaal), of via directe invoer onder Windows ALT+2011 (of SHIFT+CTRL+U <loslaten> 2011 <spatie> onder de meeste linux/*nix consoles en desktops). Niet gecodeerde invoer van de NBSP kan met ALT+000A0 (Windows), SHIFT+CTRL+U, 00A0, <spatie> (op linux/unix platforms; de terminating space (<ENTER>, werkt meestal ook, maar kan problemen opleveren bij invoervelden) is om het einde van de (hexadecimale) cijferreeks te markeren, waarna het teken verschijnt). Het nadeel van directe ingave van deze karakters in de wiki-brontekst is dat dat visueel het verschil tussen de reguliere en non-breaking varianten niet (altijd) (gemakkelijk) zichtbaar is). -- martix (overleg) 9 dec 2018 18:07 (CET)

Titels Handschriftpagina's[bewerken]

De onlangs door studenten te Utrecht aangemaakte artikelen over handschriften in de collectie van de Universiteit Utrecht hadden titels conform de officiële citeertitels, bijv. Universiteitsbibliotheek Utrecht HS. 51, maar The Banner heeft ze stuk voor stuk gewijzigd naar bijv. Handschrift 51. Nu zijn er talloze handschriften bekend als 'Handschrift 51', ook al omdat het Duitse woord identiek is, dus ik zie niet in waarom de titelwijzigingen een verbetering zouden zijn. Op mijn reactie op de zijn/haar overlegpagina heeft hij/zij niet geantwoord, dus ik breng het hier maar aan de orde. De wijzigingsmotivatie "betere titel conform WP:BENOEM" begrijp ik niet en ik vind het treurig dat een The Banner Wikipedia in een slecht daglicht zet door wetenschappelijke citeertitels gewoon te negeren. Jürgen Eissink (overleg) 15 nov 2018 19:42 (CET).

Of dit Wikipedia echt in een kwaad daglicht stelt lijkt me niet iets wat onmiddellijk voor de hand ligt, maar dat enig overleg vooraf hier wel zeer wenselijk ware geweest, daar sta ik volkomen achter. Ik zou dan ook het liefst zien dat The Banner deze wat al te gehaaste acties eventjes zelf terugdraaide. De Wikischim (overleg) 15 nov 2018 21:08 (CET)
Heb jij ooit gehoord van WP:BENOEM, met name het principe Gebruik een eenvoudige titel. Een titel als Hs. 396 (Universiteitsbibliotheek Utrecht) zegt helemaal niets en heeft ook een toevoeging tussen haakjes die niets toevoegt. Citeertitels zeggen verder weinig. The Banner Overleg 15 nov 2018 21:56 (CET)
Ow, Jürgen Eissink, de schrijvers van de bewuste artikelen hebben de citeertitels ook al genegeerd, dus waarom ik die moet respecteren is mij duister. Daarnaast heb ik de handschriften nu onder één vorm van de naam gebracht, in plaats van ik meen zes verschillende naamvormen. The Banner Overleg 15 nov 2018 22:00 (CET)
Mij lijkt Eenduidigheid gaat boven eenvoud. Wanneer een woord of uitdrukking verschillende betekenissen heeft, benoem je pagina dan zo exact mogelijk. hier eigenlijk meer van toepassing. Encycloon (overleg) 15 nov 2018 22:06 (CET)
WP:BENOEM zegt ook "Eenduidigheid gaat boven eenvoud", en eenduidigheid stopt niet bij de grens van Wikipedia, al is dat voor jou misschien moeilijk voor te stellen. De nieuwste artikel waren wel degelijk aangemaakt als 'Universiteitsbibliotheek Utrecht HS. XX', conform de citeertitels dus. De versie met UBU tussen haakjes zijn in elk geval niet mis te verstaan. "Citeertitels zeggen verder weinig" – waarom heb je de titels dan niet, nog korter, gewijzigd in Oud papier 51? Het maakt jou toch allemaal geen ene aardappel uit, als je maar een regeltje hebt gevonden om je aan vast te klampen. Misschien moet je bijvoorbeeld dit eens lezen, om te beginnen, en dan eens verder kijken waarom collecties worden beschreven met titels die verwarringen uitsluiten. Jürgen Eissink (overleg) 15 nov 2018 22:15 (CET).
Hs. 96 (Universiteitsbibliotheek Utrecht), Hs.1023 (Universiteitsbibliotheek Utrecht), HS. 162 (Universiteitsbibliotheek Utrecht) en Hs. 710. Vier naamsvarianten waarvan er geen een de citeertitel volgt.
En om antwoord te geven op deze vraag: waarom heb je de titels dan niet, nog korter, gewijzigd in Oud papier 51. Dat is simpel: omdat ik de encyclopedie serieus neem en artikelen een duidelijke titel moeten hebben. Met een (citeer-)titel als "Universiteitsbibliotheek Utrecht HS. 162 (4 H 14)" is volstrekt onduidelijk waar het artikel over gaat. The Banner Overleg 15 nov 2018 22:33 (CET)
Ow, en ik miste Hs.236 (3 E 13) (Universiteitsbibliotheek Utrecht), een vijfde variant. The Banner Overleg 15 nov 2018 22:41 (CET)
Als je werkelijk duidelijke titels wilt, had je de oorspronkelijke titels ook net zo goed kunnen laten zoals ze waren. De Wikischim (overleg) 15 nov 2018 23:02 (CET)
Eenheid van titels en verwijderen overbodige toevoegingen tussen haakjes lijken mij voldoende redenen voor de ingreep. The Banner Overleg 15 nov 2018 23:17 (CET)

Verbetering van artikelen (i.h.b. Gel)[bewerken]

Goedemorgen,

Om men de 'vraag achter de vraag' te beginnen: ik heb artikel "Gel" opgenomen in "Wikipedia:Dit kan beter/Wetenschap & Technologie", om de redenen die daar en op de "Overleg Pagina" van Gel zijn uiteengezet.

Maar ik vraag me – mede hierdoor en afkijken bij de buren op EN-WP – al enige tijd af of er binnen de nl-wiki (relatief kleine/genuanceerde) sjablonen (al dan niet in veschillende varianten, zoals men dat op de EN-WP kent) bestaan waarin een "Oproep tot verbetering" staat, die boven het gehele, of alleen in/bij sommige secties en kopjes van artikelen worden geplaatst, zonder dat de pagina daarmee direct wordt gelinkt met/genomineerd op de TBP? Maag die door zulke sjablonen daardoor wél worden opgenomen in (de categorie of lijsten) "Pagina's waar iets mee is", of verwijzen naar de WP:DKB (i.p.v. de TBP).
De (recente) activiteit op WP:DKB speelt zich voornamelijk alleen nog af in de secties "Te veel nadruk op Nederland" en "Te veel nadruk op België", de andere secties zijn welhaast onzichtbaar (geworden), en er wordt nog weinig aandacht aan besteed (zo is althans mijn indruk)?

(Misschien kan (en zal) ik de bovenstaande ook of beter in de helpdesk plaatsen al vermoed ik dat het daar nagenoeg dezelfde lezers bereikt als hier?). Groeten -- martix (overleg) 1 dec 2018 11:12 (CET)

Goede vraag, waar best verder over nagedacht mag worden (zie bijvoorbeeld ook deze recente Kroegdiscussie). Het verbeteren van artikelen lijkt niet iets te zijn waar veel gebruikers zich (structureel) mee bezighouden. Ik denk dat een sjabloon niet meteen voor zo'n cultuuromslag zal gaan zorgen. Behalve de inactiviteit van WP:DKB worden ook de op te knappen artikelen van de dag die in de kroeg staan nauwelijks opgeknapt. Het voorstel van The Banner (en eerder iets soortgelijks van Renevs) om er een soort themaweek over te hebben lijkt me dan ook een zinvoller idee om in ieder geval de aandacht voor dit (belangrijke) onderdeel van Wikipedia te vergroten.
Deze kwestie lijkt me trouwens niet zo geschikt om op de Helpdesk te starten, lijkt me beter om het op deze pagina te houden. Encycloon (overleg) 1 dec 2018 11:34 (CET)
@Encycloon: Dank voor je snelle reactie (en het invullen van de titel – dat had ik niet meegekopieerd nadat ik het dit kopje in eerste instantie wel op de Helpdesk was gestart). Ik houd het overleg dan vooralsnog ook hier, en zal alleen – wanneer reactie of verbeteringen na een weekje nog zijn uitgebleven – op WP:OG vermelden, mogelijk in het wetenschapscafé. Ik had eerder wel eerder (ook via The Banner) vernomen van de WP:AD, maar het dringt nu pas tot me door dat het daar om twee verschillende selecties van artikelen gaat (die voor op de hoofdpagina, en die voor artikel die daar beslist niet geschik voor zijn en in meer of mindere mate verbetering nodig hebben. Vooralsnog wacht ik even af. Groeten -- martix (overleg) 1 dec 2018 12:45 (CET)
N.B.: Het blijft me verbazen hoe weinig activiteit er toch is op de DKB, zeker waneer dat vergeleken wordt met die op de TBD. Wellicht heeft het met de onoverzichtelijke structuur te maken (hetgen ook gezegd kan worden van WP:Gewenste artikelen). Persoonlijk ben ik van mening dat bijvoorbeeld een 'wiu'-artikel best wat langer (dan twee weken) de tijd mag krijgen om verbeterd te worden, voordat er over het lot van de pagina wordt beslist. Of 'verbeternominaties- of verzoeken' die na een bepaalde tijd nog geen effect gesorteerd hebben, kan (in plaats van verwijderen) misschien ook worden gedacht aan het verhuizen van het artikel vanuit de HNR naar een – daarvoor in het leven te roepen – WIU:- of "Opknap:"-naamruimte? Mvg, -- martix (overleg) 1 dec 2018 12:45 (CET)
N.B2.: Overigens neem ik vrijwel nooit deel aan de discussies in de Kroeg en lees ik er zelden; ik heb er altijd sterk de indruk dat de bijzaken de hoofdzaken aan het oog onttrekken, en het gaat er niet zelden een stuk minder gemoedelijk aan toe dan op de andere, specifieke café's en zoals hier – nog los van de enorme hoeveelheid leesvoer... Ik weet dat ik daardoor soms misschien wat actuele onderwerpen mis, maar het is een weloverwogen keuze. Groeten -- martix (overleg) 1 dec 2018 12:50 (CET)

Encyclopedie versus woordenboek[bewerken]

Ik zag in de discussie over de Letterknecht de volgende stellingen voorbijkomen:
Afgezien van een voorbeeld van letterknechterij in de praktijk gaat het artikel niet over het fenomeen zelf, maar over het woord dat ernaar verwijst. Marrakech (overleg) 7 dec 2018 13:13 (CET)

Een encyclopedie behandelt per artikel een fenomeen. Het woord dat voor dat fenomeen bestaat dient er alleen maar toe om ernaar te verwijzen. Een woordenboek behandelt in één lemma juist alle verschillende betekenissen van een woord. Dat is een wezenlijk verschillende aanpak. Marrakech (overleg) 8 dec 2018 15:11 (CET)
(na bwc) Het verschil tussen een woordenboek en een encyclopedie is nu juist dat een woordenboek alle betekenissen van een woord in één lemma behandelt, terwijl in een encyclopedie al die betekenissen ieder hun eigen lemma krijgen. In mijn Dikke Van Dale staan het insect en de Duitse volksbolide dus gebroederlijk bijeen in één lemma, terwijl alle betekenissen van 'kever' hier op Wikipedia over meerdere lemma's verdeeld zijn. Bovendien, er is al de kritiek dat dit lemma slechts een woordenboekdefinitie zou zijn, en wanneer je dan ook nog eens de verschillende betekenissen van 'letterknecht' in één lemma zou behandelen, vrees ik dat je deur alleen maar verder openzet voor de kritiek dat dit lemma eerder thuishoort in een woordenboek dan in een encyclopedie. Mij lijkt het dus onverstandig om dat te doen. Matroos Vos (overleg) 8 dec 2018 15:34 (CET)

Die gaan mij boven de pet en leg ze hier maar eens voor. Mij lijkt dat het om een fundamentele discussie gaat en daarmee niet bij het lemma thuishoort. Als het niet de juiste plaats is, zag ik graag dat de deskundige de discussie verplaatst naar waar die dan wel hoort. @Marrakech:, @Matroos Vos: Stunteltje (overleg) 9 dec 2018 09:59 (CET)

Tango (drank)[bewerken]

Ik lees het artikel Tango (drank) en heb toch een beetje het idee dat hier verschillende onderwerpen door elkaar lopen (mix met grenadine, maar ook mixen met Sprite of 7Up). Daarnaast twijfel ik door het ontbreken van bronnen aan de authenticiteit van de term. Wat nu? - ArjanHoverleg 12 dec 2018 13:47 (CET)

ß of ss?[bewerken]

Ik weet niet of ik hier goed ben, en ook niet of dit wellicht al eens is besproken: maar hanteren we op Wikipedia ß of ss? Trijnstel (overleg) 14 dec 2018 00:52 (CET)

Ik zag in de archieven van het Taalcafé dat dit al meerdere keren is langsgekomen; volgens mij is deze discussie ongeveer de recentste. Als ik het goed begrijp, kwam daaruit dat we het donorprincipe gebruiken tenzij er een Nederlands equivalent voor bestaat. Mvg, Encycloon (overleg) 14 dec 2018 09:22 (CET)

"Conserven", "Conserveren (voedsel)" en "Eten uit blik"[bewerken]

Goedendag,

Ik heb op 'Overlegpagina' van het artikel "Conserven" een (paar) voorstel(len) beschreven onder het kopje "Voorstel samenvoegen 2 of 3 verwante artikelen" – tevens bedoeld als de OP voor het centraal overleg – m.b.t. de afzonderlijke artikelen "Conserveren (voedsel)", "Eten uit blik" en "Conserven"; in mijn perceptie kan het laatstgenoemde artikel "Conserven" (dat m.i. half 'woordenboekdefinitie', en half 'doorverwijspagina' is (naar "Eten uit blik" en "Wecken", maar bijvoorbeeld weer niet naar "Confijten" of "Pekelen"), dan wel het 't midden daartussen houdt) met één van de (of mogelijk zelfs met beide) artikelen "Conserveren (voedsel) en/of "Eten uit blik" (artikelen die beide aanmerkelijk meer inhoud becatten) zou kunnen samen- of ingevoegd gevoegd, om vervolgens verder te gaan onder de titel "Conserveren" (dat mij een geschikte (paraplu)term lijkt voor het artikel dat overblijft na in- of samenvoegen.
Ik ben bekend met de sjablonen {{Samenvoegen naar}} en {{Samenvoegen van}}, maar wilde eerst even de voelsprieten uitsteken/via het 'klankbord' alhier vernemen of anderen dat ook een verbetering zouden vinden (en zo ja, welke in- of samenvoegingsvariant(en) dan de voorkeur(en) hebben) of mogelijk nog andere/betere voorstellen kunnen aandragen – of weet hebben van andere verwante maar structuurloze artikelen – (of mogelijk leidt het oriënterend overleg er zelfs toe dat consensus uitwijst dat het prima kan blijven zoals het thans is), voordat ik de betreffende artikelen ga 'ontsieren' met voornoemde sjablonen.
Het artikel "Eten uit blik" is al eens genomineerd voor verwijdering, ik wil expliciet benadrukken dat bij welke vorm van in- of samenvoeging dan ook, de inhoud van dat artikel grotendeels of integraal behouden blijft – hoewel mogelijk het 'diepvries'-kopje beter elders ondergebracht kan of zou moeten worden (past meer bij "Conserveren (voedsel)" –, maar er alleen maar meer inhoud vanuit een 'samenvoegen van' artikel bij komt, en dan de (mogelijk de passendere) titel 'Conserven' zou gaan dragen.
Volgens mij zouden na een enkele of gehele samenvoeging – naast een passendere titel bij de inhoud van het resultaat en ook een structureler totaalresultaat – ook de inter-wikilinks gemakkelijker, logischer en/of intuïtiever zijn, dan wel beter aansluiten bij de structuur van de artikelen van de anderstalige Wikipedia's.
Op de overlegpagina's van "Conserveren (voedsel)" respectievelijk "Eten uit blik" wordt ook verwezen naar het voorstel en de 'centrale overlegplaats'" bij het artikel "Conserven"; daar is denk ik ook een beter gestructureerde en een beter begrijpelijke opsomming/beschrijving van de voorstellen uiteengezet (dan dat uit bovenstaande tekst-brei valt op te maken). Graag jullie visies en terugkoppeling. Met vriendelijke groet -- martix (overleg) 4 jan 2019 10:07 (CET)

Conserven zou ik zeker niet gaan samenvoegen met Conserveren (voedsel), Voedsel en Eten zijn immers ook niet één artikel. Misschien is er wel iets voor te zeggen om Eten uit blik samen te voegen met Conserven. De Wikischim (overleg) 4 jan 2019 10:24 (CET)
Misschien dat diverse zaken opknippen of niet integraal in te voegen bij andere artikelen ook bekeken kunnen worden. Zou lijkt mij de verwijzing 'wecken' (nu in artikel conserven) wel prima passen in "Conserveren (voedsel)", maar niet of minder bij 'conserven' thuishoren. Door 'conserven' en 'eten uit blik' samen te voegen, en het resultaat 'conserven' te noemen (in plaats van 'eten uit blik') kan er ook mere gezegd worden over pot-conserven(?) -- martix (overleg) 4 jan 2019 12:36 (CET)

Externe link in "Zeepalingen"[bewerken]

Kopje gekopieerd vanuit het Biologiecafé waar reactie nog is uitgebleven (ook bedoeld als een vraag in het algemeen over het nut m.b.t. archieflinks bedoeld voor afbeeldingen, die in het internetarchief niet meegekopieerd worden en hoe daarmee om te gaan):

In het artikel "Zeepalingen" staat een externe link naar 'Alle soorten zeepalingen met foto's, maar de (oorspronkelijke) link is offline, zodat er nu gelinkt wordt naar een Wayback Machine snapshot, helaas zonder de afbeeldingen. Ik heb zelf al even gezocht naar een alternatief (mét afbeeldingen/foto's), tot nu toe zonder resultaat. Misschien dat iemand anders wel een mirror met afbeeldingen – of een alternatief online foto-overzicht – vinden, zo niet dan is het verwijderen van de link misschien beter? (Omdat de soorten ook al in het artikel zelf staan?) Met vriendelijke groet -- martix (overleg) 7 jan 2019 20:02 (CET)

Is bijvoorbeeld deze pagina op Flickr een geschikt alternatief? (Ik heb te weinig kennis over het onderwerp/de diersoort om dat te beoordelen). -- martix (overleg) 7 jan 2019 20:24 (CET)

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)

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)