Overleg sjabloon:Citeer web

Parameter 'Taal' in Sjabloon:Citeer boek

Kan iemand deze parameter op dezelfde plek zetten als in sjabloon:Voetnoot web? Verder komen de uitgever en plaats niet te voorschijn. Kan iemand helpen deze template te verbeteren? Wiki 15 mei 2007 06:17 (CEST)

Dit is inmiddels opgelost. Wiki 18 mei 2007 18:13 (CEST)

Zwevende taalaanduiding

Tot nu toe werd als taalaanduiding de tekst getoond zoals die in de parameter wordt opgegeven. Bijv. (en). Ik heb de standaardmethode toegevoegd dat als je met de cursor wijst er "Taal: Engels" verschijnt. De oude methode is echter gehandhaafd voor het geval iemand een taalaanduiding zou opgeven waarvoor geen sjabloon bestaat. Is dit nodig, of is het beter te vereenvoudigen en de oude methode te laten vervallen, zodat er een foutmelding komt als iemand iets anders opgeeft dan een bestaande taalcode? --LexTH 28 mrt 2009 14:01 (CET)

Als iemand een taalcode opgeeft die niet bestaat, en er wordt gebruik gemaakt van de normale sjablonen voor taalaanduidingen, dan komt daar een foutmelding van en maak ik die taalaanduiding aan of pas ik het aan zodat de goede bedoeld wordt. Groetjes - Romaine (overleg) 28 mrt 2009 14:50 (CET)

Het probleem is dat in de gebruiksaanwijzing als voorbeeld werd gegeven om "French" in te vullen, dus voluit. Ik weet niet hoevelen dit voorbeeld gevolgd hebben. --LexTH 28 mrt 2009 15:21 (CET)

Idem voor {{subst:LOCALDAY}} {{subst:LOCALMONTHNAME}} {{subst:LOCALYEAR}} die op deze manier niet met succes ingevoegd kunnen worden binnen een referentie, haalde ik er gisteren uit toen iemand daar melding van maakte. Ik merk vrij vaak, en niet alleen bij beginnende gebruikers, dat ook al geeft het sjabloon een foutmelding omdat het niet juist of niet volledig is ingevuld, dat men het dan niet opmerkt of niet aanpast maar zo laat staan, terwijl het eenvoudig aanpasbaar is. Misschien moet er in de tekst van iedere foutmelding een leeg sjabloon opgenomen worden tussen includeonly-tags om te kunnen achterhalen waar het niet goed ingevuld staat. Hoe dat op te lossen is met French, ik denk dat dat alleen botmatig kan. Dat er een bot langs gaat lopen die deze check (eenmalig?) uitvoert (check op wijze van invullen parameter). Groetjes - Romaine (overleg) 28 mrt 2009 16:01 (CET)

Bezochtdata linken

Zoals door Romaine boven werd beschreven, heb ik ook mezelf gevonden in een positie waarin ik zonder verdere gedachte de sjabloon-code van deze pagina overneem en invul. In dit geval ging het over de bezochtdatum. Deze is standaard gelinkt, en dat is al zo sinds 2006 (zie geschiedenis). Door een bewerking van Glatisant hier bedacht ik me dat ik het wel met hem/haar eens ben. Het linken van deze data lijkt mij tamelijk zinloos en/of onrelevant. Wat denken anderen hierover ? –Krinkle 12 apr 2009 18:55 (CEST)

Mee eens, de bezoekdatum geeft geen historische context. Fenke 12 apr 2009 21:20 (CEST)

Inderdaad, waarom zou deze datum gelinkt moeten worden? Toen ik hier een paar jaar geleden voor het eerst kwam was het nog behoorlijk gebruikelijk om op Wikipedia alle mogelijke data te linken. Nu neemt dat gebruik (gelukkig) af; teveel linken is storend bij het lezen. Glatisant 12 apr 2009 21:34 (CEST) (PS. Ik ben een hij)

Oke, dan ga ik het aanpassen. Mocht iemand bezwaar hebben kan hierover altijd nog een (korte) discussie gevoerd worden, al dan niet met een peiling. –Krinkle 12 apr 2009 22:12 (CEST)

Haal het linken van de datum er gerust uit, is hier overbodig. Romaine (overleg) 12 apr 2009 22:12 (CEST)

Sorry, ik heb geen tijd om het terug te vinden, maar misschien herinnert iemand anders zich voldoende door de volgende, wat kortaffe opmerking. Op en.wiki wordt het volgens mij gebruikt om de datum weer te geven volgens Speciaal:Voorkeuren. Erik Warmelink 15 apr 2009 15:48 (CEST)

Die opmerking begrijp ik niet, kun je het uitleggen? 'Herinnert iemand anders zich voldoende'?? Glatisant 15 apr 2009 17:06 (CEST)

Ik weet dat ergens wordt aangeraden om data altijd te linken. Dit zou nuttig zijn voor blinden die met een speciale browser lezen. Ik kan het helaas niet terugvinden. Het zou in een Engelstalige tekst kunnen zijn. -- LexTH overleg  15 apr 2009 17:59 (CEST)

Ja, maar dit gaat om de datum waarop een boek of tijdschrift als referentie geraadpleegd is, in een voetnoot. Dat is wel een heel 'far cry' van een datum die enig belang heeft of ergens mee vergeleken moet worden. Glatisant 15 apr 2009 18:28 (CEST)

't Is lastig uit te leggen. Ik denk dat ik ooit een goede reden heb gehoord en hoop voldoende hints te geven zodat anderen een/de URL terug kunnen vinden waarin uitgelegd wordt waarom het een goed idee is. Maar jullie mogen best twee eeuwen achterlopen met jullie datumnotatie. Erik Warmelink 16 apr 2009 00:20 (CEST)

Dank je wel, daar hebben we tenminste iets aan. Glatisant 16 apr 2009 02:24 (CEST)

Lettertype bezochtdata klein maken

Kan de tekst "bezochtdata" klein? Is mooier. --BlueKnight 27 apr 2009 21:25 (CEST)

Lijkt mij ook. Gedaan. -- LexTH overleg  28 apr 2009 00:06 (CEST)

Thx :) --BlueKnight 28 apr 2009 21:35 (CEST)

Het is acht jaar na dato, maar ik heb dit ongedaan gemaakt. Het is op zichzelf al niet netjes tegenover de lezer om de tekst te verkleinen, en het appendix-sjabloon (dat om de een of andere reden nog altijd door veel mensen gebruikt wordt) maakt de tekst ook al kleiner, zodat de 'bezochtdatum' volstrekt onleesbaar was. Woody_|(?) 9 okt 2017 01:39 (CEST)

Ik heb het nog nooit ervaren dat de "bezochtdatum" 'volstrekt onleesbaar' werd (en dat ik bijvoorbeeld moest inzoomen om het te kunnen lezen): in géén van de browsers die ik gebruik, noch met wat voor instellingen dan ook. Ik ben het dan ook volledig eens met Gebruiker:Blueknight die het aanvanklijk voorstelde, dat 'het mooier oogt'. (Mogelijk speelt dit (alleen) via mobiele browsers op smartphones, kan ik alleen maar gissen?)

Het argument dat het "niet netjes tegenover de lezer" zou zijn om de tekst te verkleinen zie ik graag nader verklaard. Ik blijf er voorstander van om dat deel (de bezochtdatum) van het sjabloon in een kleiner lettertype weer te geven, zodat e.e.a. nog enigszins compact blijft, en regelmatig daardoor zelfs nog bij één regel in de appendix (of onder de {{references}} blijft, en niet meerdere regels gaat bestrijken – soms dan zelfs maar met enkele woorden op de volgende regel. Een ander (naar mijn bescheiden mening) mogelijk voordeel is dat daardoor visueel in één oogopslag verschillende vormen van informatie (en het belang ervan) te onderscheiden is. Maar ik onderken dat het misschien meer een kwestie van smaak/persoonlijke voorkeur is. Wel denk ik dat overleg hierover vóóraf (zoals hierboven ook gedaan is voordat het zo ingesteld werd) misschien wel zo zuiver zou zijn geweest. - martix (overleg) 18 dec 2017 18:22 (CET)

Dat jij het zelf allemaal prima kan lezen kan natuurlijk nooit een reden zijn om geen rekening te houden met mensen die daar misschien wat weer moeite mee hebben. Als opgemerkt wordt de tekst door het appendix-sjabloon al kleiner weergegeven. Ik ken geen enkel serieus medium waarin naast het in kleiner lettertype weergeven van de voetnoten ten opzichte van de lopende tekst een deel van die voetnoot zelf ook nog eens extra klein wordt weergegeven ten opzichte van de rest van de noot. Niet zo gek, want daar is geen enkele goede reden voor te bedenken. Waarom zou een voetnoot bijvoorbeeld niet meer dan één regel mogen beslaan? (En ligt dat niet ook aan je schermresolutie?) En hoezo zou het een voordeel zijn om de raadpleegdatum in één opslag van de rest van de noot te kunnen onderscheiden? En hoezo zou dat voordeel dermate groot zijn dat we dan maar op de koop toe moeten nemen dat een deel van de lezers die informatie helemaal niet meer kan lezen? Het komt erop neer dat je het vooral mooier vindt, en dat is zoals je zelf al opmerkt een kwestie van smaak. Zelf vind ik het niet om aan te zien. Woody_|(?) 18 dec 2017 19:40 (CET)

Anders omgaan met archiefurl/archiefdatum

Indien o.m. archiefurl= gebruikt wordt is het naar mijn mening beter om die als hoofd-link (voor titel=) te gebruiken, en url= pas daarna te noemen als het origineel. Met andere woorden, zoals dit op de Engelstalige Wikipedia gebeurt. Het gros van de bezoekers klikt de titel= hoofd-link en komt vervolgens naar alle waarschijnlijkheid - archiefurl= wordt immers zelden toegevoegd als url= werkt - op een niet meer bestaande pagina terecht. Ik vind het ietwat vreemd dat ik dit als niet-frequente bezoeker moet melden. Genoeg actieve editors moeten dit toch hebben opgemerkt, en het sjabloon kan vrij gemakkelijk gewijzigd worden... 82.170.113.123 28 jul 2013 12:16 (CEST)

Het komt sowieso vaak voor dat die parameter (archiefurl) niet wordt gebruikt, maar gewoon de link wordt vervangen. Ik vindt dit persoonlijk ook niet prettig. Sjoerd de Bruin (overleg) 7 aug 2013 18:00 (CEST)

VisualEditor

Vanaf heden, mede met dank aan gebruiker:Sjoerddebruin te gebruiken met VisualEditor. Het toevoegen van bronnen is vandaag dus heel gemakkelijk geworden voor degenen die VisualEditor gebruiken. Het team ontwikkelaars staat open voor feedback! Ad Huikeshoven (overleg) 22 mei 2014 21:37 (CEST)

Haakjes

Wat is de reden dat dit sjabloon de datum van een krantenartikel tussen haakjes zet? Volgens mij doen we dat normaal niet.

• handmatig: Vlagtwedder Grensbode, 31 februari 2076
• sjabloon: Vlagtwedder Grensbode (31 februari 2076)

Wanneer nu op een pagina zowel het sjabloon wordt gebruikt als handmatig een referentie wordt toegevoegd ziet dat er rommelig en inconsequent uit. Muijz (overleg) 8 aug 2015 09:54 (CEST)

Ik vind het persoonlijk nog vervelender dat in de voorbeelden datums als July 6, Mei en 2006-05-16 gegeven worden. Nou is dat laatste volgens de ISO 8601-standaard en daar is iets voor te zeggen, maar consistentie in datumformaat en taal (6 juli, mei, 16 mei 2006) is ook wat waard. Sowieso is het belangrijkste bestaansrecht van deze sjabloon (en een aantal vergelijkbare) het uniform weergeven van referenties. Worden er in een artikel al twintig referenties gegeven zónder een dergelijke sjabloon, zou ik de 21e ook zelf intikken. Andersom ook trouwens. Richard 10 aug 2015 11:17 (CEST)

Ergernissen

Ik erger me al jaren groen en geel aan dit sjabloon, waarop beweerd wordt dat de volledige datum van de publicatie het liefst moet worden ingevuld in het formaat YYYY-MM-DD, met als een van de voorbeelden "Geraadpleegd op 2005-07-06", een datumnotering die ik dag in dag uit, jaar in jaar uit moet aanpassen. Wikipedia is geen softwareprogramma waarin je YYYY-MM-DD schrijft, Wikipedia is een encyclopedie die gelezen wordt. Het liefst nomineer ik dit sjabloon, maar dat kan niet, want het wordt overal gebruikt. Gebeurt er nu weer tien jaar lang niets als ik dit opschrijf? Ik hoop van wel. ErikvanB (overleg) 1 sep 2015 19:01 (CEST)

Het irritante is dat de visuele tekstverwerker de datum op die manier invult. Ik heb ook liever de voorkeur voor de volledige data, mits machines deze kunnen begrijpen en de visuele tekstverwerker het ook op die manier moet doen. Sjoerd de Bruin (overleg) 1 sep 2015 19:03 (CEST)

Lettertype auteur

Het lettertype (spacing?) wijkt af van het lettertype in "citeer boek", of "citeer-journal". In deze schablonen wordt de auteur geformatteerd volgens het schabloon Aut. Mijn vraag: kan dit rechtgetrokken worden ? Clpippel (overleg) 22 nov 2015 20:24 (CET)

Ik zou er zelf niet per definitie op tegen zijn, maar zou wel even afwachten hoe anderen hierover denken. Richard 23 nov 2015 17:39 (CET)

Archiefurl + dode-url

Zojuist heb ik dit sjabloon aangepast op het volgende.

• Als er een archiefurl is toegevoegd en | dode-url = ja of | dead-url = yes wordt in plaats van de url de archiefurl gelinkt.
• Als er een archiefurl is toegevoegd en | dode-url = is leeg of iets anders dan ja/yes, wordt de url gelinkt.

Dit zowel op verzoek hier als hier. Romaine (overleg) 30 jun 2017 20:00 (CEST)

hoofdletters in een parameter

Ik leg de vraag hier maar even neer, omdat Wikiklaas (overleg · bijdragen) dat niet lijkt te hebben gedaan: is het wenselijk dat parameters in het sjabloon ook met een hoofdletter aangeroepen kunnen worden? Bijvoorbeeld "Dode-url" naast "dode-url"? Persoonlijk maakt het me niet zoveel uit, al kan ik me voorstellen dat het de efficiëntie en leesbaarheid van de code nadelig beinvloedt. Effeietsanders 8 jul 2017 23:39 (CEST)

Hallo Effeietsanders, Dank voor je vraag. In vrijwel alle sjablonen op nl-wiki is het niet gangbaar dat er parameters met hoofdletters worden gebruikt. Vrijwel overal zijn de parameters met kleine letters geschreven, mede ook omdat het gebruik van hoofdletters in het Nederlands niet worden toegepast.

Per sjabloon kunnen dat we 50 extra schrijfvarianten zijn aan extra parameters en die helpen gebruikers niet om een sjabloon een beetje te snappen. En ook wordt inderdaad de leesbaarheid van een sjabloon aangetast, en ik heb ook diverse fouten uit sjablonen als deze gehaald omdat er een overdosis aan parameters in stond, dat helpt ook niet.

De citeersjablonen hebben in de basis twee sets aan parameters: de Nederlandstalige benaming en de Engelstalige benaming om het invoegen van een bron uit en-wiki makkelijk te maken. Om dan nog een hele set aan parameters toe te voegen, maakt het onnodig complex en gaat ook in tegen het gebruik op nl-wiki om vrijwel overal alleen parameters te gebruiken met kleine letters. Door de tijd heen heb ik gemerkt dat allerlei variaties in parameternamen vaak voor verwarring en fouten zorgen. Niet voor niets is er sinds 2008 door diverse gebruikers geprobeerd om de parameters te harmoniseren, zodat er minder verwarring bestaat, er minder fouten ontstaan en dat voor iedereen de parameters goed werken. Romaine (overleg) 8 jul 2017 23:48 (CEST)

Vierkant haakje

Ik heb opgemerkt dat er een haakje zichtbaar is als ik een web citeer via Visueel bewerken > Handmatig > Website. Mijn referentiecode is als volgt:

<ref>{{Citeer web|url=http://www.fragmentaentomol.org/index.php/fragmenta/article/download/161/138|titel=Revision of Malayia Malloch, with the first reports of Rhinophoridae from India and Indonesia (Diptera: Oestroidea)|bezochtdatum=1 april 2018|auteur=GL Giudice|achternaam=|voornaam=|datum=30 juni 2016|uitgever=|taal=en}}</ref>

Deze referentie, en dus ook het zichtbare haakje kun je vinden in dit artikel: Malayia LukaBE (overleg) 1 apr 2018 13:33 (CEST)

Dag Luka, dit werd veroorzaakt door de aanwezigheid van enters in de code. Als die door de visuele tekstverwerker worden toegevoegd is dat natuurlijk een probleem. Misschien kan dat beter worden aangekaart op mw:VisualEditor/Feedback. Ik heb de enters in ieder geval verwijderd. Mvg, Jeroen N (overleg) 1 apr 2018 13:40 (CEST)

Beste Jeroen, bedankt voor het antwoord. Volgens mij lag het gewoon aan mij, want ik heb diezelfde link nog eens geprobeerd en toen kwam het haakje niet meer. Er zal dus geen probleem zijn met citatie in de visuele bewerker. Met vriendelijke groeten LukaBE (overleg) 1 apr 2018 16:34 (CEST)

NRC als uitgever?

Waarom wordt NRC Handelsblad meermalen als voorbeeld van een uitgever beschouwd? Het is zeker de uitgever van een aantal werken, maar meestal wordt toch de krant bedoeld, en die is een Werk. Dat laatste veld maakt de titel cursief, zoals bij kranten toch de bedoeling is. Mag dit veranderd worden? FNAS (overleg) 16 okt 2018 10:00 (CEST)

Ik lees deze pagina voor het eerst, en voel me enigszins 'betrapt'; ik doe dit altijd, maar realiseer me nu dat het inderdaad niet klopt! Het komt waarschijnlijk omdat ik het sjabloon eerst alleen met 'uitgever' kende, en daar alle uitgevers/kranten/tijdschriften/websites dan maar onder schaarde. Ik ga mijn leven beteren! Laurier (overleg) 10 jun 2021 09:02 (CEST)

Hehehe, je bent niet de eerste hoor ;-) En an sich is het ook weer niet zo'n ramp. Edoderoo (overleg) 10 jun 2021 09:11 (CEST)

Bedankt! :-) Laurier (overleg) 10 jun 2021 13:17 (CEST)

En bedankt voor de zoeklink... Daar zítten inderdaad ook pagina's bij die niet door mij bewerkt zijn...! Laurier (overleg) 10 jun 2021 15:13 (CEST)

Is het een idee om deze botmatig om te zetten? Heeft dat überhaupt een toegevoegde waarde? Dajasj (overleg) 10 jun 2021 15:29 (CEST)

Ik zou het lekker laten staan, want zowel uitgever als werk zien er in de {{Appendix}} hetzelfde uit, dus het is een beetje lood om oud ijzer. Edoderoo (overleg) 10 jun 2021 16:00 (CEST)

@FNAS, Laurier, Edoderoo: Het zou natuurlijk kunnen dat mensen het gebruiken omdat het in de visual editor expliciet als voorbeeld wordt genoemd: "uitgever, bijvoorbeeld: NRC Handelsblad". (probeer maar eens :) ) -- Effeietsanders (overleg) 10 jun 2021 18:38 (CEST)

Dat is nu opgelost. Staat nu bij werk vermeld en niet meer bij uitgever. Mbch331 (overleg) 10 jun 2021 21:23 (CEST)

Super! Dat helpt denk ik echt! Ik heb nu de 'gewone' uitlegtekst gelijkgetrokken met de tekst in de tabel onderaan de pagina over het sjabloon. Waarom zijn die er eigenlijk allebei, is dat niet dubbelop? Laurier (overleg) 11 jun 2021 07:37 (CEST)

Die tabel is een weergave van de informatie die is ingevuld voor de templatedata die gebruikt wordt voor de visuele tekstverwerker. De tekst is van voor de tijd van de visuele tekstverwerker. Alleen is die tekst overzichtelijker als je het sjabloon zo wilt gebruiken zonder de visuele tekstverwerker, maar de visuele tekstverwerker kan daar weer niet mee overweg. Die moet de informatie op een gestructureerde manier kunnen raadplegen. Daarvoor wordt onderhuids de JSON notatie gebruikt, maar dat leest niet fijn voor de meeste mensen, dus vertalen ze het naar een tabel, zodat het overzichtelijker is. Mocht je een manier weten waarop je een van de twee overbodig kan maken, zonder dat dit gevolgen heeft voor de a-technische mensen (die de gewone tekst versie gebruiken) en de visuele tekstverwerker (die de gestructureerde JSON informatie nodig heeft), dan implementeer dat of leer de developers van WMF hoe ze dat kunnen. Tot die tijd zit je met beide varianten opgezadeld. Mbch331 (overleg) 11 jun 2021 08:10 (CEST)

Zou het kopje 'werk' dan ook als 'aangeraden' variabele aangezet kunnen worden bij de sjabloondocumentatie? Mij lukt het niet helemaal goed. Crazyphunk 14 aug 2021 12:49 (CEST)

Inmiddels heb ik dat nu zelf gedaan via deze bewerking. Met vriendelijke groeten, Crazyphunk 30 nov 2021 11:14 (CET)

Mag de pagina-aanduiding weer weg?

Nadat vele verwijzingen zijn aangemaakt met "| pagina = p. 7 |" voegt het sjabloon sinds 5 maart "p." toe. Dat is niet handig om twee redenen. Er staat nu dus heel vaak twee maal "p.". Daarnaast zijn webpagina's meestal niet onderverdeeld in alweer pagina's. Soms wel kopjes, paragrafen of andere structuurelememten. In die gevallen zie je nu in de verwijzing staan: "p. paragraaf 2.3" of iets dergelijks. Wellicht is het een beter idee om de instructie aan te passen?

Graag zie ik de automatische tekst "p." weer verdwijnen! Vriendelijke groeten van Marten de Vries (overleg) 4 jun 2019 23:51 (CEST)

• De mogelijk om een pagina weer te geven zou ik zeker behouden. Soms is de "web-pagina " een pdf van meer dan honderd bladzijden en dan is het voor de verificateur of geïnteresseerde gemakkelijker om direct naar de juiste pagina te gaan. Ik voegde vroeger zelf een "p" toe omdat dit duidelijker was in de weergave. Zonder is verwarrend. Ik denk ook dat de automatische P best kan verwijderd worden en dan kan de instructie in Sjabloon:Citeer web verder gebruikt worden zoals die nu is. Met vriendelijke groeten,(Leonasimov (overleg) 5 jun 2019 08:15 (CEST))

•  Uitgevoerd Teruggezet. Was een ietwat ondoordachte actie van RonnieV. –bdijkstra (overleg) 5 jun 2019 09:47 (CEST)

Taallocalisatiecodes

Er blijkt minstens één bot te zijn die taallocalisaties in het taalveld stript tot de overkoepelende taal. Ik kan iets gemist hebben, maar nergens vond ik overleg waarin is afgesproken dat in dit veld enkel twee- en drieletterige ISO 639-taalcodes mogen worden gebruikt. Waarom zouden meer nauwkeurige - en de lezer dus meer informatie biedende - taallocalisaties onwenselijk zijn? Een code als "ar-AE" is veel specifieker dan "ar", "ar-AE" en "ar-MA"-sprekers kunnen elkaar amper begrijpen. Zwitserduits ("de-CH") is voor veel "de"-sprekers nauwelijks te behappen, "pt-PT" en "pt-BR" verschillen ook nogal van elkaar. Er kunnen goede argumenten zijn om dit voorschrift te handhaven, die hoor ik dan graag, maar anders stel ik voor het los te laten. Wutsje 26 dec 2019 05:14 (CET)

De visuele bewerker voegt automatisch die lokalisaties toe, en ik herinner me dat het wat mensen irriteert. Als ze het graag willen weghalen vind ik dat zonde, net als jij, maar tegelijk zal ik er ook niet van wakker liggen. Ik heb nooit een echte afspraak gezien, voor zover ik kan beoordelen is het puur zo gegaan vanwege de wet van de langste adem (maar ik kan iets gemist hebben). Effeietsanders 26 dec 2019 06:42 (CET)

Als ik een weblink probeer in te voegen met de VE, dan moet ik handmatig de taalcode intikken. Waar/wanneer/hoe worden die automatisch toegevoegd? –bdijkstra (overleg) 26 dec 2019 07:05 (CET)

Dat iets mág worden gebruikt, wil niet zeggen dat het kán worden gebruikt. De beperking is vanwege technische redenen. Zoals het sjabloon nu werkt, is er een sjabloon nodig voor elke taalvariant, bv. {{ar-AE}}, {{ar-MA}}, {{pt-PT}}, {{pt-BR}}; de meeste van die sjablonen bestaan niet. In theorie zijn er meer dan honderdduizend varianten mogelijk, hoe ga je daarmee om? Tot dusver is er niemand geweest met een plan. –bdijkstra (overleg) 26 dec 2019 06:55 (CET)

zie kopje "de standaarden toepassen" bij ISO 639(Leonasimov (overleg) 26 dec 2019 08:18 (CET))

Okee, duidelijk, dank voor jullie reacties. Ook al zouden we dat willen c.q. zinvol vinden, niemand gaat nog al die varianten aanmaken. Interessant opstel trouwens (nooit gezien, als ik een taalcode wil weten kijk ik op sil.org). Als het inderdaad zo is dat de VE taallocalisatiecodes automatisch toevoegt, dan lijkt me dat iets om voortaan te verijdelen. Wutsje 26 dec 2019 16:38 (CET)

Is er een reden dat dat sjabloon precies zo werkt? Voor zover ik kan zien, vervullen die sjablonen de volgende functies:

• Geef de eerste twee karakters weer als (en) in een bepaalde layout
• geef een mouse-over met "Taal: Engels" enz

Dat eerste kun je volgens mij bereiken met {{#invoke:String|sub|en-UK|1|2}}, bijv voor "en-UK" krijg je dan: en. Het tweede moet volgens mij ook kunnen met een dictionary/switch? Effeietsanders 26 dec 2019 23:34 (CET)

De reden is volgens mij simpelweg omdat iemand een beginnetje heeft gemaakt en omdat niemand het heeft afgemaakt. Er zijn ook taalcodes met meer letters, het tweede deel is niet altijd een landcode en UK is geen toegewezen landcode, maar inderdaad kan het op een dergelijke manier. –bdijkstra (overleg) 27 dec 2019 00:33 (CET)

Sure, om het robust te maken wil je waarschijnlijk een andere code gebruiken. Ik beeld me in dat je twee scenarios accepteert: 1) een twee of drielettercode op zichzelf of 2) een twee- of drielettercode, gevolgd door een liggend streepje en een langere string. Met een match-statement gecombineerd met een if-statement, lengths-statement en substring uit module:String moet je denk ik een heel eind komen? En dan zou je zelfs op case-by-case basis kunnen besluiten om bepaalde dialecten weer wel anders weer te geven. Effeietsanders 27 dec 2019 00:39 (CET)

japans: taal=ja

@Mbch331: Toevallig was ik bezig met een artikel met Japanse bronnen. Nu blijkt dat die bronnen in het Japans geschreven zijn, en dat je dan "taal=ja-JP" krijgt. Dit wordt vereenvoudigd tot

{{ja}}

( Ja). Dat lijkt me niet helemaal de bedoeling. Kan iemand het sjabloon dusdanig aanpassen dat als een bron de parameter 'taal=ja' meekrijgt, dat er netjes '(ja)' voor de bron verschijnt, in plaats van een stemsjabloon? :) Ik verzuip een beetje in deze code... Effeietsanders 1 sep 2020 07:27 (CEST)

Het enige wat de code op dit moment doet is het deel vanaf het streepje negeren (scheelt al een hoop "foute" taalcodes). Om ook nog te controleren op de taalcode ja, is een stuk lastiger met de inderdaad ingewikkelde code. Zeker niets om even op een dinsdagochtend even aan te passen. Zal daar rustig voor moeten zitten. (Mocht iemand anders eerder een oplossing weten, pas het gerust toe) Mbch331 (overleg) 1 sep 2020 07:40 (CEST)

Neem je tijd - de fout zit er al een tijd in en loopt niet weg. Ik wilde niet suggereren dat jij de fout had aangebracht, alleen dat jij misschien een oplossing zou weten :) Effeietsanders 1 sep 2020 09:26 (CEST)

Het is mijn "schuld" dat ja-JP {{ja}} wordt (ik heb de code toegevoegd die alles na het streepje weghaalt, wat voor alle talen behalve Japans een verbetering is). Als iemand alleen ja invult, dan speelde het probleem ook al voorheen. Mbch331 (overleg) 1 sep 2020 10:28 (CEST)

@Mbch331: Een idee hoe we dit kunnen omzeilen? Een if-statement lijkt een makkelijke omweg, maar aangezien dit sjabloon zoveel gebruikt wordt, misschien niet gewenst? Een andere route die ik kan zien, is om bij alle talen een redirectsjabloon te maken op

{{taal-xx}}

en daarnaar te linken? Misschien sowieso handig om die aanvliegroute van afknippen nog eens te bezien, want de documentatie zegt dat we ook drieletterige codes accepteren, terwijl de code een tweeletterige code aanneemt. Een andere manier om hetzelfde te bereiken, is door te kijken of er een liggend streepje in de parameter zit, en dan daarop te splitsen? Effeietsanders 14 sep 2020 20:30 (CEST)

Welke code neemt een tweeletterige code aan? Niet die van dit sjabloon. –bdijkstra (overleg) 14 sep 2020 21:52 (CEST)

Oeps, my bad - negeer dat deel maar (no pun intended). Duidelijk verkeerd onthouden van een ander sjabloon... Effeietsanders 14 sep 2020 22:45 (CEST)

fix

@Bdijkstra, Mbch331: Mijn voorstel zou zijn:

• alle twee- en drieletterige taalsjablonen verplaatsen van sjabloon:aa naar sjabloon:taal-aa met achterlating van redirect.
• deze wijziging doorvoeren

Dit zou ook gelijk alle toekomstige gevallen ondervangen waarbij een taalafkorting samenvalt met een bestaand sjabloon (hetzelfde probleem speelt bijvoorbeeld bij de taal isiNdebele met de afkorting

{{nd}}

en het Waals met

{{wa}}

. Een soort if-statement zou om die reden wellicht minder gewenst zijn. Zien jullie mogelijke problemen die ik mis? -- Effeietsanders (overleg) 22 mei 2021 02:10 (CEST)

Lijkt me goed, dus  Voor. –bdijkstra (overleg) 22 mei 2021 18:50 (CEST)

Lijkt mij ook een goed idee. Mbch331 (overleg) 22 mei 2021 20:25 (CEST)

OK, dank voor de bevestiging. Ik heb de eerste vier sjablonen verplaatst, even anderen de gelegenheid geven om te zien of ik iets over het hoofd zie. Categorisatie gaat automatisch goed. Als dit geen problemen blijkt op te leveren, zal ik ook de andere sjablonen verplaatsen, en daarna dit citeer web aanpassen. -- Effeietsanders (overleg) 25 mei 2021 06:47 (CEST)

Alles is nu doorgevoerd. Volgens mij is het enige dat eventueel nog gedaan kan worden, het aanmaken van 'meer' taal-sjablonen. Er was een extra edit voor nodig dan voorzien, maar dat was geen groot probleem. Japans wordt nu goed weergegeven! -- Effeietsanders (overleg) 27 mei 2021 22:31 (CEST)

Twee puntjes bij citaat

Als ik een citaat toevoeg aan het (geweldige!) sjabloon, krijg ik twee puntjes tussen de bezochtdatum en het citaat. Voorbeelden zijn te vinden op toeslagenaffaire, maar het ziet er zo uit:

Geraadpleegd op 8 februari 2021.. "De fiscus wil 150.000 euro van de ouders ontvangen. Dat geld is er natuurlijk niet en dus ook niet inbaar"

Dit lijkt me een beetje lelijk, hoe kan ik dit voorkomen? Dajasj (overleg) 8 feb 2021 15:42 (CET)

Het sjabloon was zo gecodeerd dat er na de geraadpleegd-op-datum (of een eerder argument) een punt kwam en ook dat er vlak voor een citaat (indien ingevuld) een punt kwam. Die laatste heb ik weggehaald. –bdijkstra (overleg) 8 feb 2021 19:24 (CET)

Leestijd

Steeds vaker vind ik bij bronnen vermeld wat de leestijd in minuten is, en vaak geeft dat ook de lengte (en dan indirect het belang) van de bron aan. Een interview met een leestijd van 2 minuten is toch minder diepgaand dan een van 15 minuten, dus het zou handig kunnen zijn om dat te kunnen vermelden. Kunnen we dat toevoegen? Edoderoo (overleg) 5 mrt 2021 07:22 (CET)

Hmm, interessante gedachte. Er zijn allerlei praktische hordes om te nemen, maar misschien eerst even verduidelijken wat je in gedachten hebt: Gaat het je om leestijd van de hele bron, of het gedeelte waarnaar gerefereerd wordt? Als een paginanummer bijvoorbeeld wordt genoemd, gaat het dan om het hele boek, hoofdstuk, pagina, of de relevante paragraaf? Gaat het je om objectief vastgestelde leestijd (of lengte), of een inschatting van een vrijwilliger? Gaat het om de leestijd ten tijde van raadplegen, of publicatie? Of moet die bijgewerkt worden? (overigens spelen die zaken allemaal veel minder bij een kopje als "verder lezen" of "externe links") -- Effeietsanders (overleg) 5 mrt 2021 08:08 (CET)

Voor heel veel bronnen zal deze parameter geen zin hebben, en ik zou ook zeker niet zelf met een stopwatch gaan zitten lezen, maar het overnemen als het al vermeld is vanuit de link naar de bron die je zelf hebt gevonden bij het toevoegen. Voor een passage uit een boek doe je dat niet, maar bij een artikel van NU.nl, Trouw, Volkskrant, etc, geeft het de lezer toch extra informatie. Ik kwam vanmorgen een interview tegen met een leestijd van 15 minuten, dat is veel diepgaander dan een artikeltje dat je in 2 minuten weg leest. Vroeger kreeg je die leestijd sowieso nergens te zien, maar de laatste twee jaar zie ik het steeds vaker, en ik vind het zelf best informatief, daarom denk ik dat het ook voor anderen soms een handig weetje zal zijn. Edoderoo (overleg) 5 mrt 2021 09:22 (CET)

archive-url

Op enwiki is men parameters gaan aanpassen van bijvoorbeeld archiveurl naar archive-url, (en wil men ondertussen de eerste variant helemaal gaan verwijderen). InternetArchiveBot doet daar vrolijk aan mee, ook hier. Wij ondersteunen alleen archiefurl en archiveurl. Het gevolg is bijvoorbeeld dat op Schotland, referentie 13 (Scottish Renewables) niet werkt (Error 404), terwijl er wel een archiefurl beschikbaar is. Ondertussen zijn er naar schatting zo'n 1000 pagina's waar dit het geval is. De meest simpele oplossing lijkt dan om hier ook maar archive-url erbij te gaan ondersteunen. Dit geldt ook voor andere parameters zoals access-date en archive-date. Tevens zou dit op de andere Citeer sjablonen ook moeten gebeuren. Of het gewenst is dat een bot bepaald welke parameters we moeten ondersteunen, laat ik in het midden. Heeft iemand hier opmerkingen over? ∼ Wimmel (overleg) 27 mrt 2021 11:46 (CET)

Dit zijn enkele voorbeelden waar het nu mis gaat:

pagina	issue
Schotland	Geen archief url (archive-url icm archive-date)(+access-date)
Ivoy	Foutmelding (archive-url icm archiefdatum)(+archiefurl=leeg)
Wereldkampioenschap voetbal 2022 (kwalificatie AFC)	Foutmelding (archiveurl icm archive-date)
Avidemux	Foutmelding, via wikidata

∼ Wimmel (overleg) 4 apr 2021 22:49 (CEST)

Aangepast door {{{archiveurl|}}} te veranderen in {{{archiveurl|{{{archive-url|}}}}}}, en hetzelfde voor archivedate en accessdate. Alleen voor Avidemux is het daarmee nog niet opgelost, dat vergt nog wat uitzoekwerk wat er exact misgaat. ∼ Wimmel (overleg) 4 apr 2021 23:40 (CEST)

Dat zit in een van de automatisch ingevulde parameters van de {{Infobox software}}. Een lege {{Infobox software}} geeft nog steeds een foutmelding, een infobox haalt de melding weg. Edoderoo (overleg) 5 apr 2021 08:20 (CEST)

Ik heb even kortstondig het sjabloon gesubst, het blijkt in parameter4 - laatste release-datum fout te gaan. Waarom precies laat ik aan een expert over. Edoderoo (overleg) 5 apr 2021 08:31 (CEST)

Lijkt me vrij duidelijk wat er bij Avidemux misgaat: in Wikidata is er namelijk wel een archief-URL beschikbaar maar geen archiveerdatum. –bdijkstra (overleg) 5 apr 2021 23:24 (CEST)

De simpelste oplossing zou dan zijn om de foutmelding gewoon weg te halen en te accepteren dat een archief-URL bestaat zonder archief-datum. Maar ik heb toch nog iets verder gezocht, en ik vind dat eigenlijk toch geen goed idee. Ten eerste bestaat op wikidata geen property die overeenkomt met dodeurl=ja, het voorstel daarvoor is afgewezen. Dus dat archief-URL zal nooit gebruikt worden. Het lijkt me beter om daar eerst een oplossing voor te zoeken. Ten tweede, in dit specifieke geval is er iets veel belangrijkers dat verkeerd gaat. {{Infobox software}} laat de meest recente versie van Avidemux zien, tenminste dat is de bedoeling. In werkelijkheid wordt de oudste versie getoond. Als de juiste versie getoond wordt, is er geen archief-URL meer, en verdwijnt de foutmelding dus. ∼ Wimmel (overleg) 11 apr 2021 14:23 (CEST)

Het probleem was dat het sjabloon zocht naar versietype (P548)=stabiele versie (Q2804309). Ten eerste kennen de releases van Avidemux geen indicatie van versietype of supportperiode, dus heb ik die qualifiers weggehaald. Ten tweede wordt het versietype niet ingevuld door Github-wiki-bot, dus heb ik die vereiste weggehaald. –bdijkstra (overleg) 11 apr 2021 17:08 (CEST)

Datumnotatie

Als de datum jjjj-mm-dd geformateerd wordt dan kan het sjabloon dit zelf omzetten naar "25 juli 2021". Dit heeft opzich de voorkeur aangezien het ook makkelijker uit te lezen is door computers. Dit is echter niet het voorbeeld wat de documentatie op dit moment geeft. Bij deze het voorstel dit aan te passen. Vera ^(talk) 25 jul 2021 17:49 (CEST)

Voor de duidelijkheid: 2021-07-25 in de brontekst wordt gerenderd als 25 juli 2021  →bertux 25 jul 2021 21:32 (CEST)

Wellicht interessant om ook nog even de opmerking van ErikvanB hierover mee te nemen (Overleg_sjabloon:Citeer_web#Ergernissen). Crazyphunk 26 jul 2021 15:06 (CEST)

Toen (in 2015) was het sjabloon nog zo uitgevoerd dat de datum getoond werd zoals je hem invoerde. Dat is nu veranderd, hij toont bij juiste invoer een keurig uitgeschreven datum. Dat komt minstens deels tegemoet aan de opmerking van ErikvanB. De huidige versie rendert de datum overeenkomstig de taalinstellingen van de computer en browser, bij ingelogde gebruikers overeenkomstig de opgegeven voorkeuren  →bertux 26 jul 2021 15:16 (CEST)

variabele "via"

Op de Engelstalige Wikipedia heeft en:Template:Cite Web de variabele "via". Deze wordt gebruikt voor de 'content deliverer', waar daar het voorbeeld NewsBank en newspaper.com genoemd wordt. Op de Nederlandstalige Wikipedia zal dat vooral Delpher zijn. Graag zou ik ook op de Nederlandstalige Wikipedia gebruik kunnen maken van deze variabele. Vera ^(talk) 25 jul 2021 21:10 (CEST)

@1Veertje: op zich niks op tegen, maar kun je een kopie maken van het sjabloon in een kladblok, en in een diff laten zien welke wijziging je precies voor ogen hebt? Het sjabloon wordt nogal veel gebruikt, dus even testen kan geen kwaad. -- Effeietsanders (overleg) 26 jul 2021 00:50 (CEST)

Ik moet er even een moment voor vinden dit te doen, heb wat veel dingen door elkaar lopen. Vera ^(talk) 1 aug 2021 14:57 (CEST)

@Effeietsanders: Zie mijn implementaties en voorbeeld Vera ^(talk) 8 aug 2021 14:45 (CEST)

Ik ben voor, hier kan ik het namelijk regelmatig gebruiken voor gearchiveerde pagina's, die toon je dan via Web Archive/WayBack Machine. Dqfn13 (overleg) 11 aug 2021 19:55 (CEST)

In dat geval zou je toch eigenlijk van de "archiefurl" gebruik moeten maken. Als ook |dodeurl=ja wordt toegevoegd wordt die als hoodlink gegeven. Ik zie dat het voorbeeld hiervan wel erg afwijkt van de Engelstalige Wikipedia: daar wordt dit duidelijker aangegeven als gearchiveerde link en krijg je de oorspronkelijke link nog met het label "original" erachteraan, zeg maar het omgekeerde als |dodeurl=ja ontbreekt.

ik heb de "via" variabele al toegevoegd aan mijn versie en de handleiding wat bijgewerkt (voorbeelden gebruiken https, darumnotatie is jjjj-mm-dd). Vind iemand het nodig hier nog naar te kijken voordat ik dit veelgebruikte sjabloon bijwerk? Vera ^(talk) 11 aug 2021 21:11 (CEST)

Je bedoelt iets als deze twee?

• <ref>{{cite news | last = | first = | title = | date = | accessdate = | url = http://www.highbeam.com/doc/... | publisher = ... via [[HighBeam Research]] }} {{Subscription required}}</ref>
• <ref>{{cite news | last = | first = | title = | date = | accessdate = | url = http://http://www.questia.com/library/... | publisher = ... via [[Questia]] }} {{Subscription required}}</ref>

The Banner Overleg‍ 11 aug 2021 21:13 (CEST)

Ik gebruik ook archiefurl= dan. Ik heb een beter voorbeeld dat wel toepasselijk is: de site van Oud Hoorn heeft (met toestemming) van plaatselijke kranten hier oude artikelen op hun site geplaatst en dat kan dan wel via |via= geplaatst worden. Dqfn13 (overleg) 11 aug 2021 22:18 (CEST)

HighBeam Research en Questia zouden idd goede kandidaten voor de "via" zijn. Die beide websites zijn offline en zouden daarom waarschijnlijk ook een archiedurl wellicht nodig hebben. Geen idee hoe relevant dat is voor een website waar je voor moest betalen. Dat je voor een website moet inloggen kan je ook netjes aangeven met de |url-access= variabele op de Engelstalige Wikipedia. Sowieso heeft het sjabloon veel meer functionaliteit. De code voor het sjabloon is erg anders opgebouwd dan hier. Eigenlijk is dat script overnemen en uitbreiden met Nederlandse synoniemen wel interessant. Dat zou wel ook betekenen dat er opgezocht zou moeten worden waar de variabele "pagina's" wordt gebruikt want die komt niet overeen: hier móet de gebruiker er aan denken er een "p." voor te zetten, elders wordt dat door het sjabloon gedaan. Zelf vind ik niet hoeven nadenken wel een plus. Vera ^(talk) 11 aug 2021 22:56 (CEST)

variabele 'url-access' zou mooi zijn ja, om die in het Nederlands toe te voegen! Bestaat er dan ook zoiets als 'alternatieve url' waar iets onbeperkt gelezen kan worden, met daarbij dan dus de 'via'-variabele om duidelijk te maken via welke dienst dat kan? Laurier (overleg) 13 aug 2021 16:38 (CEST)

Als je van url-access gebruik maakt is het toevoegen van een gearchiveerde link misschien relevant. Publicaties zoals de NYT zijn vaak op die manier nog te lezen. De hoofdlink is echter nog niet dood dus dodeurl=ja is niet van toepassing. Onhandig is dat dit weer anders is dan in het Engelse sjabloon: daar moet je aangeven dat de hoofdlink níet dood is als er wél een archiefurl aanwezig is. Dit zou ook mijn voorkeur hebben gehad. Opzich is de "via" dan niet relevant want de inhoud komt in hoofdzaak nog op de oorspronkelijke plek. Vera ^(talk) 17 aug 2021 11:24 (CEST)

Klinkt goed! Laurier (overleg) 17 aug 2021 11:55 (CEST)

Slotje

In vervolg op het eerdere overleg hierover met Vera: op de Engelstalige Wikipedia is er in het sjabloon Cite_web de ref-parameter "url-access=", waar je "free", "registration", "limited" of "subscription" achter zet; dit wordt in de referentielijst getoond met een slotje, zodat de lezer meteen ziet of er een betaalmuur is, en welk type. Zouden we dat hier ook kunnen doorvoeren, op Citeer web en ook op Sjabloon:Citeer nieuws, Sjabloon:Citeer tijdschrift, Sjabloon:Citeer journal, Sjabloon:Citeer boek en waar het eventueel nog meer nodig is? Ik hoop dat iemand dit kan realiseren. Bedankt! Laurier (overleg) 18 jan 2022 12:23 (CET)

Zoals @Matroos Vos het hier al aangaf, andere bronnen zitten ook achter een betaalmuur, daar zetten we toch ook geen slotje achter? Ook ben ik het eens met @Gouwenaar, het doet hier niet ter zake of er wel of niet betaald moet worden om een artikel te lezen. Met vriendelijke groeten, Crazyphunk 21 jan 2022 00:03 (CET)

Volgens mij lopen er drie zaken door elkaar:

1. Voor de wenselijkheid van de bron maakt het niet uit of deze vrij toegankelijk is of niet.
2. Voor de kwaliteit van de bron kan het wel uitmaken of deze betaald is of vrij beschikbaar is. Informatie verzamelen en verwerken kost tijd, dus geld. Hoe serieuzer je hiermee omgaat, hoe meer de informatie gekost heeft. Wat de uiteindelijke prijs wordt, hangt af van wat de gek er voor geeft, en aan hoeveel mensen je de informatie beschikbaar stelt, alsmede aan de publicatie- (en verkoop-)kosten.
3. Voor de zichtbaarheid maakt het wel uit. Als ik bij een bron een boektitel zie, zonder webbron maar met een ISBN, dan weet ik dat ik hetzij naar mijn boekenkast, hetzij naar de bibliotheek of de boekhandel moet om deze informatie te verifiëren. Staat er een link, dan verwacht ik eigenlijk dat ik op een pagina kom waar die informatie om niet wordt aangeboden (al moet je er vaak wat advertenties bij accepteren, en soms flink aan de slag om zo veel mogelijk cookies tegen te houden). Door aan de link wel een symbooltje toe te voegen, geef je de lezer meteen informatie over de beschikbaarheid van die URL. Nadeel hiervan kan zijn dat die informatie in de loop der tijd kan veranderen. Dat is prima aan te passen in een enkel artikel, maar als het een veel gelinkte site is, kan dat wat bewerkelijker zijn.

Ik denk dan ook een dergelijke aanduiding wel meerwaarde heeft, zie Gebruiker:RonnieV/Citaten. Met vriendelijke groet, RonnieV (overleg) 21 jan 2022 00:39 (CET)

Het lijkt mij dat het prettig is voor de lezer/bezoeker dat die meteen kan zien hoe toegankelijk de webbron is. Je bent als Wikipediaan niet verplicht die informatie toe te voegen, maar ik ben er heel blij mee dat dat nu wel kan! Bedankt, RonnieV! Laurier (overleg) 21 jan 2022 09:32 (CET)

Hmm, nu ik het in de praktijk zie, vind ik die rode kleur wel een tik agressief... kunnen we een andere kleur/afbeelding hiervoor kiezen? Het trekt nogal de aandacht wanneer de rest van de bronvermelding zich kalm in grijstinten hult... en het lijkt me juist ongewenst om de aandacht te trekken naar bronnen die misschien juist minder toegankelijk zijn. -- Effeietsanders (overleg) 22 jan 2022 03:07 (CET)

Rood is wel duidelijk: verbodskleur. Ik zal volgende week even kijken of de afbeelding ook in andere tinten beschikbaar is. Enkel een andere alt-tekst is niet heel onderscheidend. Maar ik begrijp wel wat je bedoelt. Met vriendelijke groet, RonnieV (overleg) 22 jan 2022 09:14 (CET)

Het is een echte svg (en niet een png in svg), dus kan je de afbeelding downloaden, kleur aanpassen in de broncode en weer uploaden onder een andere naam. Mbch331 (overleg) 22 jan 2022 10:33 (CET)

De rode kleur lijkt me zeer onwenselijk, het trekt veel te veel de aandacht van waar het om zou moeten gaan, de bronnen. Crazyphunk 22 jan 2022 11:34 (CET)

Slotjes

Ik ben even zo vrij geweest te gaan shoppen in onze speelgoedwinkel:

• Lange titel van een stuk Fictieve volgende tekst 1
• Lange titel van een stuk Fictieve volgende tekst 2
• Lange titel van een stuk Fictieve volgende tekst 3
• Lange titel van een stuk Fictieve volgende tekst 4
• Lange titel van een stuk Fictieve volgende tekst 5
• Lange titel van een stuk Fictieve volgende tekst 6
• Lange titel van een stuk Fictieve volgende tekst 7
• Lange titel van een stuk Fictieve volgende tekst 8
• Lange titel van een stuk Fictieve volgende tekst 9
• Lange titel van een stuk Fictieve volgende tekst 10
• Lange titel van een stuk Fictieve volgende tekst 11
• Lange titel van een stuk Fictieve volgende tekst 12
• Lange titel van een stuk Fictieve volgende tekst 13
• Lange titel van een stuk Fictieve volgende tekst 14
• Lange titel van een stuk Fictieve volgende tekst 15
• Lange titel van een stuk Fictieve volgende tekst 16
• Lange titel van een stuk Fictieve volgende tekst 17
• Lange titel van een stuk Fictieve volgende tekst 18
• Lange titel van een stuk Fictieve volgende tekst 19
• Lange titel van een stuk Fictieve volgende tekst 20
• Lange titel van een stuk Fictieve volgende tekst 21
• Lange titel van een stuk Fictieve volgende tekst 22
• Lange titel van een stuk Fictieve volgende tekst 23
• Lange titel van een stuk Fictieve volgende tekst 24
• Lange titel van een stuk Fictieve volgende tekst 25
• Lange titel van een stuk Fictieve volgende tekst 26
• Lange titel van een stuk Fictieve volgende tekst 27
• Lange titel van een stuk Fictieve volgende tekst 28
• Lange titel van een stuk Fictieve volgende tekst 29
• Lange titel van een stuk Fictieve volgende tekst 30
• Lange titel van een stuk Fictieve volgende tekst 31
• Lange titel van een stuk Fictieve volgende tekst 32
• Lange titel van een stuk Fictieve volgende tekst 33
• Lange titel van een stuk Fictieve volgende tekst 34
• Lange titel van een stuk Fictieve volgende tekst 35
• Lange titel van een stuk Fictieve volgende tekst 36

Als we uitgaan van als (niet gebruikte) optie voor een geheel vrije bron, wat vinden we daar dan bij passen? Bedenk dat het ook in het klein voldoende onderscheidend moet zijn (dat zijn de nu gebruikte afbeeldingen voor een beperkt beschikbare bron of eentje die registratie verplicht stelt niet, want die gebruiken dezelfde afbeelding). Zijn we er dan met 29, 2 en 1 (in die volgorde)?

• Lange titel van een stuk Fictieve volgende tekst 12, Vrij beschikbaar
• Lange titel van een stuk Fictieve volgende tekst 29, Vrije toegang is mogelijk voor een beperkte kennismaking, hierna is registratie verplicht
• Lange titel van een stuk Fictieve volgende tekst 2, Gratis registratie verplicht
• Lange titel van een stuk Fictieve volgende tekst 1, Betaald abonnement verplicht

Is 12, 33, 7,1 een beter voorstel?

• Lange titel van een stuk Fictieve volgende tekst 12, Vrij beschikbaar
• Lange titel van een stuk Fictieve volgende tekst 33, Vrije toegang is mogelijk voor een beperkte kennismaking, hierna is registratie verplicht
• Lange titel van een stuk Fictieve volgende tekst 7, Gratis registratie verplicht
• Lange titel van een stuk Fictieve volgende tekst 1, Betaald abonnement verplicht

Wie heeft er nog een ander idee, of een voorkeur? Wensen voor andere kleurtjes? @CrazyPhunk, Effeietsanders, Laurier, Mbch331:. Met vriendelijke groet, RonnieV (overleg) 26 jan 2022 01:13 (CET)

Schitterend, wat mij betreft inderdaad jouw tweede voorstel: 12, 33, 7, 1. Indien dit wordt doorgevoerd, dan graag bij alle citeer-sjablonen, qua consistentie. Laurier (overleg) 26 jan 2022 12:11 (CET)

In vergrote versie:

Natuurlijk ga ik de hier gemaakte keuze overnemen naar Sjabloon:Citeer nieuws, en komen de andere sjablonen daarna aan bod. Met vriendelijke groet, RonnieV (overleg) 26 jan 2022 12:34 (CET)

Maar begrijp ik nu goed dat je bij elke bron een open of dicht slotje wil gaan plaatsen? Dus wanneer een bron vrij is een open slotje? En ook nog een tekst erachter. Want dan wordt het juist weer onoverzichtelijk. Mijn voorkeur gaat naar een grijs slotje bij bronnen die niet vrij toegankelijk zijn. Met vriendelijke groeten, Crazyphunk 26 jan 2022 13:06 (CET)

@CrazyPhunk: Nee, het groene slotje wordt niet getoond, niet als default en ook (wat mij betreft) niet geforceerd via een mee te geven waarde. Ik had die alleen bedoeld om te laten zien dat er een complete set is. De tekst heb ik hierboven toegevoegd om snel te laten zien waar welk symbool naar verwijst, in de echte versie komt die betekenis alleen in een 'mouseover' in beeld (tenzij de browser niet uit de voeten kan met een afbeelding). Met drie grijze slotjes, alle met een andere betekenis, geven we weinig helderheid aan de lezer. Met vriendelijke groet, RonnieV (overleg) 26 jan 2022 13:25 (CET)

Ja, het groene slotje kan iemand die het echt graag wil wel toevoegen, maar de meeste Wikipedianen zullen dat niet doen. Het is eigenlijk alleen nuttig als een bron juist beperkt toegankelijk is. Laurier (overleg) 26 jan 2022 15:09 (CET)

Dank je Ronnie. Nadenken over de set vind ik wel nuttig, zolang we daarna inderdaad bespreken welke slotjes we willen weergeven. Ik kan me voorstellen dat je dat ook in css verder kunt regelen. Zo zou ik persoonlijk die 'open' slotjes wel handig vinden.

Persoonlijk vind ik de eerste set duidelijker omdat het minder kleur-afhankelijk is. Ik zou alleen voor het overzicht de levels beperken tot drie niveaus: open, 'met beperkingen' en gesloten. Websites gaan vast creatiever worden met hun beperkingen, en ik denk niet dat het haalbaar is dat we dat allemaal een eigen kleurtje gaan geven. Kleurtjes constant opnieuw definiëren gaat ook gedoe opleveren. -- Effeietsanders (overleg) 26 jan 2022 19:00 (CET)

Op dit moment heb ik toch de opties 12, 33, 7 en 1 doorgevoerd voor 'Citeer web', 'Citeer nieuws', 'Citeer boek', 'Citeer tijdschrift' en 'Citeer persbericht'. Ik kan me echter ook wel wat voorstellen bij de opmerking van @Effeietsanders om iets minder kleurafhankelijk te zijn. Volgens mij kan dat door 7 te vervangen door 5:

In vergrote versie:

Gelukkig kan ik dat nu direct aanpassen voor alle vijf de sjablonen die dit gebruiken, in Sjabloon:Citeerslotjes. Als er nog meer wensen of ideeën zijn, laat het maar horen. Met vriendelijke groet, RonnieV (overleg) 10 feb 2022 01:33 (CET)

(nl) voor Nederlandstalige links

Info Eerdere discussies: voornamelijk Overleg Wikipedia:Bij twijfel niet inhalen#Taalcode nl verwijderen uit bronvermelding. (juli 2019); in de kantlijn daarvan ook op de OP van Romaine en in de kroeg op enkele overlegpagina's van gebruikers: Overleg gebruiker:Ad Huikeshoven/Archief2#Aanpassingen Visual Editor (januari 2020) Overleg gebruiker:Erik Wannee/archief 14#nl is onnodig op de Nederlandstalige wikipedia? (februari 2021) Overleg gebruiker:Erik Wannee/archief 15#nl (oktober 2021) zijdelings benoemd in: Wikipedia:Visuele tekstverwerker/To do#Vormgeving bronnenlijst (januari 2020) Wikipedia:De kroeg/Archief/20200719#We schrijven 2020-07-09 (juli 2020) Wikipedia:De kroeg/Archief/20211130#Archiveertool vervangt ook links die nog werken (november 2021) Samenvatting van de situatie: De functie van taalsjablonen zoals (en) en (fr) voor een externe link is voornamelijk om de lezer te informeren dat de betreffende webpagina anderstalig is. De aanduiding (nl) bij links naar Nederlandstalige webpagina's wordt overwegend als overbodige/onzinnige informatie gezien, al zijn er ook situaties waarin de aanduiding wel gewenst kan zijn (bijvoorbeeld zoals beschreven op Sjabloon:Taal-nl). In de citeersjablonen zorgt de taal-parameter voor de invoeging van een taalsjabloon, maar daarnaast is de waarde van de taal-parameter op zichzelf al nuttige informatie over de betreffende bron. Daarnaast kan deze informatie meegenomen worden als een artikel vertaald wordt, en kan het van pas komen bij het categoriseren van bronnen. Een ingevulde taal-parameter bij citeersjablonen is dus gewenst, ook als het om Nederlands gaat, maar tegelijkertijd is de aanduiding (nl) vaak ongewenst. Daar komt bij dat met de Visual Editor automatisch een volledig ingevulde referentie kan worden ingevoegd, op basis van alleen de url van de externe webpagina. Dit wordt dan een ingevulde <ref>{{Citeer web}}</ref>, inclusief de taal indien de betreffende webpagina die informatie geeft (zie bijvoorbeeld deze test met links naar enkele Nederlandstalige sites). Dit heeft de afgelopen jaren voor vele onzinnige vermeldingen van (nl) gezorgd, waarna de taal-parameter vaak (begrijpelijk) werd geleegd of verwijderd. Mogelijkheden om deze tegenstrijdige gewenstheid van taal=nl in citeersjablonen aan te pakken: Standaard voorkomen dat (nl) ingevoegd wordt door de citeersjablonen, en een extra parameter bieden waarmee in de uitzonderingssituaties (nl) toch ingevoegd kan worden. Met deze kleine aanpassing van {{Citeer web}} wordt dat voor die sjabloon bereikt: géén (nl) bij taal=nl, taal=nl-NL en taal=nl-BE, maar in die gevallen tóch (nl) met de extra parameter toonnl (bijvoorbeeld middels toonnl=ja of toonnl=x). Zie hieronder hoe dit uitwerkt. Voordelen: Dit volgt de beredenering dat de aanduiding overwegend als overbodig/onzinnig wordt gezien, beperkt het toevoegen van een extra parameter tot de uitzonderingen, en kan bereikt worden door slechts de citeersjablonen aan te passen. Mogelijk duizenden gevallen waar de aanduiding op dit moment nog overbodig is, hoeven niet aangepast te worden. Nadelen: Ook daar waar bewust gekozen is voor de aanduiding (nl) middels de taalparameter, valt de aanduiding hiermee weg, dus daar zal de extra parameter toegevoegd moeten worden om hetzelfde te bereiken. Een andere optie is om een extra parameter te bieden die het invoegen van (nl) niet forceert maar juist onderdrukt. Dus standaard wél (nl) bij taal=nl, taal=nl-NL en taal=nl-BE, maar géén (nl) middels bijvoorbeeld onderdruk=nl. Voordelen: Voor de gevallen waar (nog) geen extra parameter staat, verandert er niets ('backward compatibility'). De uitzonderingsgevallen – daar waar bewust gekozen is voor de aanduiding (nl) middels de taalparameter – hoeven niet aangepast te worden. Nadelen: Maakt het nodeloos ingewikkeld en bewerkelijk; bij het overgrote merendeel van de referenties met Nederlandstalige externe links (alle behalve de uitzonderingssituaties) zal een extra parameter toegevoegd moeten worden, de Visual Editor zal aangepast moeten worden (als dat al haalbaar is), en alle toekomstige handmatig ingevoegde citeersjablonen zullen gecontroleerd/aangevuld moeten blijven worden. Het is ook een optie om géén extra parameter te bieden, bijvoorbeeld als het ook in (de beschreven) uitzonderingssituaties gewenst is om met het invoegen van (nl) zeer terughoudend te zijn. De citeersjablonen zullen dan nooit (nl) invoegen; slechts in overduidelijke gevallen waarbij de aanduiding tóch gewenst is, kan simpelweg {{nl}} of {{taal-nl}} voor de citeersjabloon worden geplaatst.

Info Noot van de redactie: Bovenstaand is, op het moment van dit schrijven, een poging om te verduidelijken waar de discussie wezenlijk om draait, met als uitgangspunt de tweede bullet ("De aanduiding [..] wordt overwegend als overbodige/onzinnige informatie gezien"). Verduidelijkingen, verbeteringen en aanvullingen in de lijn van dat uitgangspunt zijn welkom, en als ik ergens een denkfout heb maakt, een argument heb gemist, of de plank falikant missla, kaart dat dan hieronder vooral aan. Als een discussie over grotere terughoudendheid bij het gebruik van (nl) – bijvoorbeeld zoals in de derde optie aangestipt – nodig is, lijkt me dat gewenst onder een apart subkopje. Evenzo voor een discussie over de mogelijkheid om persoonlijk de zichtbaarheid van de taalaanduiding te kunnen regelen (wat ik niet uit eerdere discussies heb gehaald, maar hieronder wel wordt geopperd, m.i. vanuit miscommunicatie voortgekomen). Kritiek op mijn dictatoriale trekjes mag ook, maar wel gescheiden van de inhoudelijke discussie. Met vriendelijke groeten — Mar(c). [overleg] 20 mrt 2022 15:38 (CET)

Dit is een BTNI-vrije zone. Dit is een serieus proces ter verbetering van het project. Gelieve uitgeholde kreten als BTNI hier niet in de discussie te injecteren.

Onderstaande discussie is verplaatst vanuit de Helpdesk – 19 mrt 2022 20:15 (CET)

Verzoek & initiële oplossing

Hoi,

In de visuele editor is er een mogelijkheid om internetbronnen toe te voegen, en ze automatisch tot een mooie referentie te converteren. Als het gaat om een Nederlandstalige bron, wordt er soms "taal = nl", "taal = nl-BE" of "taal = nl-NL" mee opgehaald. Ik vind dat zelf geen probleem, dus ik haal het dan ook niet weg, maar meerdere wikipedianen hebben laten merken dat ze dit wél vervelend vinden. Dus mijn vraag luidt:

Kan de editor op nl.wikipedia worden aangepast, zodanig dat bij het converteren van een link de taal niet wordt opgehaald wanneer hierin zich een component "nl" bevindt?

Groetjes, Sietske | _Reageren? 18 mrt 2022 13:14 (CET)

Het is al eerder ter sprake gekomen. De beste oplossing zou zijn om niet de code weg te halen, maar de weergave van het resultaat te onderdrukken als dat resultaat 'nl' is. Dat moet niet al te moeilijk zijn, alleen moet iemand het doen.

Het voordeel van die aanpak is, dat je {{cite web}} dan zonder aanpassingen in andere taalversies kunt gebruiken  →bertux 18 mrt 2022 13:22 (CET)

(Na bwc)  Steun! Ik vind dat we zo min mogelijk zinloze informatie in onze artikelen moeten stoppen. Een taalaanduiding heeft als functie dat er een waarschuwing wordt gegeven dat het gerefereerde artikel in een andere taal is geschreven, die de lezer mogelijk niet beheerst. In dat geval heeft het niet zoveel nut om op de link te klikken. Bij een verwijzing naar een Nederlandstalig artikel is dat natuurlijk nonsens, en daarom haal ik dergelijke nl-taalwaarschuwingen altijd weg als ik ze tegenkom.

Ik heb wel eens overwogen om voor te stellen dat een dergelijke taalverwijzing op NL-WP domweg niet wordt getoond, maar dat is net iets te kort door de bocht omdat het in zeldzame gevallen wel zinvol is om aan te geven dat iets Nederlandstalig is; zo kwam ik ooit een verwijzing tegen naar een Nederlandstalig boek maar met een Engelstalige titel. Erik Wannee (overleg) 18 mrt 2022 13:27 (CET)

Ik ben er ook voor om niet overal expliciet te vermelden dat het om een link naar een (nl) bron gaat, per Erik. En ik ben er ook voor om dat niet te doen door overal taal=nl e.d. weg te halen (of de editor aan te passen), maar door de citeersjablonen simpelweg in die gevallen geen taalduiding te laten tonen, o.a. om de reden die bertux noemt. Indien het ergens tóch gewenst is (zoals in het voorbeeld van Erik), kan {{taal-nl}} voor de citeersjabloon geplaatst worden. Zal ik een poging wagen? — Mar(c). ^[overleg] 18 mrt 2022 16:01 (CET)

 Steun Ik hoef het inderdaad niet getoond te hebben doorgaans, maar vind het wel nuttig dat we die informatie achter de schermen niet steeds weghalen. Dajasj (overleg) 18 mrt 2022 16:05 (CET)

Lijkt me goed, Mar(c)! Dank dat je dit wilt proberen. Sietske | _Reageren? 18 mrt 2022 16:13 (CET)

Op deze manier? {{Citeer web}} toont hiermee geen taalsjabloon indien taal=nl of nl-nl of nl-be (niet hoofdlettergevoelig). Ter voorbeeld: referenties 13 en 14 in Catherine de Zegher hebben de constructie met taal=nl, maar er is daar geen (nl) meer te zien. Evenzo voor referentie 20 in Ennio Morricone, met taal=nl-NL. Als dit zo prima is: zijn er nog andere taalvarianten van nl in omloop, en zijn er andere (citeer)sjablonen met een bij voorkeur wel ingevulde maar niet getoonde taal-parameter? — Mar(c). ^[overleg] 18 mrt 2022 16:20 (CET)

Ah tof! Het lijkt op t eerste gezicht te werken voor citeer web en cite web. Maar klopt het dat sjabloon « citeer nieuws » niet van citeer web overerft? Want op Joost Maegerman zie ik (nl) bv nog staan. Sietske | _Reageren? 18 mrt 2022 17:15 (CET)

{{Cite web}} verwijst door naar {{Citeer web}}, de daadwerkelijke sjabloon (de Engelstalige sjabloontitels zijn redirects naar de Nederlandstalige, zie ook hier waar de redirects groen+cursief zijn weergegeven). Het maakt daarom geen verschil of je "cite web" of "citeer web" in een artikel gebruikt, de uitwerking blijft onderling gelijk, ook na aanpassing van de sjabloon. Verder zijn de citeersjablonen in principe niet aan elkaar gelinkt, dus van overerving is dan geen sprake. Een uitzondering is de vrij nieuwe {{Citeer tweet}}, die van Citeer web gebruikmaakt. (En zo te zien zijn er ook enkele nieuwe citeersjablonen die van een en dezelfde Lua-module gebruikmaken; daar ga ik niet induiken.)

Het lijkt erop dat deze sjablonen voor dezelfde behandeling in aanmerking zouden kunnen komen: {{Citeer nieuws}}, {{Citeer persbericht}}, {{Citeer journal}}, {{Citeer tijdschrift}}, {{Citeer boek}}, {{Citeer encyclopedie}}, {{Citeer hoofdstuk}}. Maar eerst maar even de ontwikkelingen hieronder afwachten.

Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 00:33 (CET)

Dank voor de verheldering. Eens met wat je hierboven zegt. Sietske | _Reageren? 19 mrt 2022 00:39 (CET)

Protest tegen de initiële oplossing

Wat een verademing om te zien dat er niet eindeloos superdemocratisch gediscussieerd wordt, maar dat er meteen doorgepakt wordt. Soms is dat ook gewoon nodig. Erik Wannee (overleg) 18 mrt 2022 17:42 (CET)

Laat ik dan voor een ander geluid zorgen. Ik ben niet blij met deze implentatie. Wanneer er alleen nl referenties zijn heb ik geen moeite met het onderdrukken van de taal, echter bij een melee aan referentietalen wil ik alle talen kunnen tonen. Aan het sjabloon sleutelen vind ik dus een foute optie. Wat eventueel in de editor wordt onderdrukt vind ik best. Zolang de parameter taal zijn functie maar behoud, zelfs bij nl als taal. --Sb008 (overleg) 18 mrt 2022 19:22 (CET)

Het weghalen is niet meer dan een miniem stukje tekst highlighten en de "backspace" toets. Het weer toevoegen is duidelijk meer werk. Dus  Tegen  Tegen  Tegen. --Sb008 (overleg) 18 mrt 2022 19:36 (CET)

Hoi Sb008, volgens mij zitten we toch redelijk op 1 lijn. Veel wikipedianen halen momenteel « taal=nl » actief weg uit de referentiesjablonen. Dankzij de aanpassing van Mar(c) vervalt voor die mensen de noodzaak om « taal=nl » te verwijderen. Eén stap in de goede richting.

Wellicht kan er in de toekomst als tweede stap iets geknutseld worden om te zorgen dat - zoals jij aangeeft - de gebruiker in de instellingen kan aangeven dat de taal altijd of onder voorwaarden getoond kan worden.

Die stap is echter enkel zinvol als « taal=nl » ook daadwerkelijk aanwezig is in de sjablonen. En dat is wat we vandaag met deze wijziging stimuleren. Sietske | _Reageren? 18 mrt 2022 20:13 (CET)

Nee dat is hij niet, als je het effect van |taal=nl niet wenselijk vindt, dan laat je de parameter weg. Ik vind het soms namelijk wel wenselijk om een effect te zien, en dat mag dan niet door het sjabloon onderdrukt worden. Je faciliteert niet iets door iets anders te defaciliteren. Dat is principieel onjuist. Als je voorruit stuk is, fix je dat ook noet door deze te vervangen door de achteruit. Als je iets wilt faciliteren, doe je dat door er iets bij te creeren. --Sb008 (overleg) 18 mrt 2022 20:42 (CET)

 Voor Ik denk dat er voldoende steun is voor Sietskes voorstel, ook als Sb008 tegen is. HT (overleg) 18 mrt 2022 20:45 (CET)

Met Sietskes voorstel heb ik geen probleem. Maar dat is niet wat nu geimplementeerd is. Nu is er functionaliteit in een sjabloon om zeep geholpen. --Sb008 (overleg) 18 mrt 2022 21:22 (CET)

@Sb008, een ander geluid vind ik prima, maar je reacties lezende krijg ik de indruk dat het je alleen om jouw geluid gaat en dat je de geluiden van de rest hier niet wil horen. Zo zijn er redenen om de parameter taal wél altijd ingevuld te hebben, daar ga je in alle drie reacties straal aan voorbij. Het punt dat dit een Nederlandstalige site is, en dat het expliciet benadrukken van de Nederlandstaligheid van externe links in het merendeel van de gevallen zinloze, overbodige informatie is (wat de functionaliteit van de parameter flawed maakte, en dat is nu verbeterd), daar ga je ook straal aan voorbij. Het is echt minder werk om in de uitzonderlijke gevallen {{nl}} of {{taal-nl}} voor de citeersjabloon te zetten, of zoals Sietske terecht oppert om met een extra parameter het tonen van (nl) te forceren, dan in het merendeel van de gevallen (een veelvoud ervan) dat 'minieme stukje' weg te moeten halen (en daarmee ook andere functies ervan om zeep helpen). Met vriendelijke groeten — Mar(c). ^[overleg] 18 mrt 2022 23:19 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Mar(c): Dit is werkelijk de omgekeerde wereld. Ik vind het prima dat mensen geen taalaanduiding willen wanneer dit een nl-variant is. Sietske vraagt om een mogelijkheid om bij een linkconversie te kunnen aangeven dat de taal-parameter niet wordt "meegeconverteerd" wanneer dit een nl-variant is. Met een dergelijke optie/mogelijkheid heb ik geen enkele moeite en zelfs begrip voor. Jij creeert echter niets optioneels, jij laat geen keuze over. Ik kan doen wat ik wil, een taalanduiding voor een nl-variant kan ik niet meer krijgen via het sjabloon. Jij onderdrukt een nl-taalaanduiding per definitie. Wie gaar er nu ergens aan voorbij? Dat ben jij nou precies. Het is geen optie meer, het is de enige mogelijkheid geworden. Bij een zwarte fontkleur is een zwarte achtergrondkleur ook behoorlijk flawed. Zal ik dan maar in alle sjablonen waar een achtergrondkleur parameter bestaat, iets inbouwen om de de achtergrondkleur te onderdrukken wanneer deze een bepaalde mate van zwartheid heeft? Dat jij misshien een witte of gele fontkleur wil gebruiken op een zwarte achtergrond is dan jammer, dat is voortaan onmogelijk. Tegen een keuze, welke keuze dan ook, heb ik nooit een bezwaar, en die keuze kan in menig/veel omstandigheden een valide keuze zijn. Echter dit effectief de enige keuze maken dat is pas flawed en doof zijn voor andere geluiden. Misschien kan je adviseur worden van Kim Jong-un. Bij de Noord-Koreaanse verkiezingen mag je op iedereen stemmen. Maar een keuze op iemand anders dan Kim Jong-un is behoorlijk flawed en moet onderdrukt worden. Als je een staalkabeltje tussen een ankerpunt en het potlood bevestigd en het stembiljet zodanig ontwerpt dat je met het potlood nog meer 1 hokje kan bereiken (welk hokje zou dat nou toch zijn?) dan laat je alle dromen van Kim Jong-un uitkomen. Van keuze vrijheid naar keuze dictatuur. Kortom, bouw wat je wilt en maak het mensen zo makkelijk mogelijk, maar maak het voor anderen niet onmogelijk om een andere keuze te maken, zoals je dat nu wel doet. Faciliteer de vraag, een optie/mogelijkheid en introduceer geen dwangbuis voor iedereen. --Sb008 (overleg) 19 mrt 2022 02:51 (CET)

SB008, je protesteert tegen de verkeerde. Als je wilt dat (nl) zichtbaar blijft, moet je protesteren tegen al die wikipedianen die momenteel « taal = nl » handmatig uit het sjabloon verwijderen. Niet tegen de ene persoon die dat probleem constructief oplost door enkel (nl) niet te tonen.

Plus: Deze manipulatie is de opmaat naar een mogelijkheid om ooit in de voorkeuren in te bouwen wat jij graag wilt, namelijk dat mensen de keuze krijgen om « (nl) » wel of niet te tonen. Tot gisteravond had iets dergelijks überhaupt geen zin, omdat er bijna geen pagina’s zijn waar taal=nl nog aanwezig is.

Sietske | _Reageren? 19 mrt 2022 07:46 (CET)

@Sietske: Hoezo protesteer ik tegen de verkeerde? Ik protesteer niet tegen jouw voorstel en ik protesteer ook niet tegen de mensen die |taal=nl uit het sjabloon weghalen. Waar ik wel tegen protesteer is tegen de gekozen implementatie. Voorheen had je de keuze om (nl) niet te tonen door de parmeter weg te halen. Bij de door Mar(c) gekozen implementatie heb je geen keuze. Je hebt geen mogelijkheid om middels een parameter (nl) toch te laten zien. Ik vind het prima dat mensen iets willen en daartoe de mogelijkheid krijgen. Maar het mag niet zo zijn dat mensen die het anders willen dit onmogelijk wordt gemaakt. En dit laatste is nu het geval. Zorg ervoor dat de conversie e.g. automatisch |onderdruk_nl=ja toevoegt. Pas vervolgens het sjabloon zo aan dat (nl) niet per definitie maar op basis van deze nieuwe parameter wordt onderdrukt. Als ik dan toch (nl) wil zien, zorg ik er wel voor dat |onderdruk_nl= niet aanwezig is. Beter is nog |onderdruk=nl zodat je de taalaanduiding van de opgegeven taal onderdrukt. Dus e.g. |onderdruk=nl,en kan dan ook voor het onderdrukken van zowel de (nl) als (en) aanduiding. --Sb008 (overleg) 19 mrt 2022 08:15 (CET)

Begrijp ik goed dat je zo per individueel artikel wilt gaan regelen of (nl) - voor zover aanwezig - wel of niet getoond wordt? Sietske | _Reageren? 19 mrt 2022 08:32 (CET)

Hoi Sb008, ik snap je bezwaar tegen de gekozen implementatie. Eerder in de discussie wordt al een optie aanbevolen om het toch zichtbaar te maken. Dat je met ander idee komt is prima. Is het echter nodig om vervolgens een collega-vrijwilliger die probeert andere te helpen, te vergelijken met dictatoriale trekjes? Nota bene op de helpdesk, een plek waar hopelijk ook nieuwe gebruikers kunnen komen. Hetzelfde punt had je kunnen maken zonder deze sterke bewoordingen. Met vriendelijke groeten, Dajasj (overleg) 19 mrt 2022 08:56 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Dajasj: Goed lezen Dajasj, ik heb dictatoriaal niet in relatie tot de persoon, maar in relatie tot de implementatie/keuzemogelijkheid gebruikt. Geen keuze=dictatoriaal. En achter die bewoording sta ik nog altijd.

@Sietske: Inderdaad Sietske, met |onderdruk=taal1,taal2,taal3,taal4,enz kan je voor 1 of meerdere talen angeven dat deze niet getoond moeten worden. Wanneer het referentieconversie mechanisme automatisch |onderdruk=nl toevoegd, zal conform jouw wens de aanduiding (nl) niet getoond worden, zonder dat jij hier verder iets voor hoeft te doen. En mocht je je bedenken, dan verwijder je de parameter "onderdruk" en wordt (nl) alsnog weer getoond. Voor de duidelijkheid, dit kan pas werken nadat de referentieconversie en het sjabloon zijn angepast. Sb008 (overleg) 19 mrt 2022 09:17 (CET)

Ik snap je suggestie, maar jouw suggestie lost mijn initiële probleem niet op. Ik zal het herformuleren:

• Feit 1: Bij het converteren van een referentie wordt soms ook een taal opgehaald, en soms is dat « taal=nl »
• Feit 2: Wikipedianen halen « taal = nl » altijd weg uit door mij geplaatste bronvermelding.
• Overweging 1: Ik weiger om « taal = nl » weg te halen nadat ik een bron heb toegevoegd, omdat ik het een overbodige handeling vind.
• Overweging 2: De algemene consensus lijkt te zijn dat (nl) niet zou moeten verschijnen in een bronvermelding
• Overweging 3: Ik weiger tijd te steken in deze mijns inziens overbodige handeling, maar vind het ook vervelend dat anderen nu tijd moeten steken in het weghalen van het door mij veroorzaakte « taal = nl »-probleem.
• De op basis van het voorgaande gedefinieerde wens: Er zou ergens in voorzien moeten worden wat ervoor zorgt dat niemand bij het converteren iets extra’s hoeft te doen aan de blijkbaar ongewenste taalaanduiding « nl » maar dat anderen ná het plaatsen van een dergelijke bron zich óók niet verplicht hoeven te voelen om die taalaanduiding alsnog te verwijderen.

Sietske | _Reageren? 19 mrt 2022 10:28 (CET)

@Sietske als ik Sb008 goed begrijp wil hij dat dat automatische referentiegeval naast taal=nl ook een onderdruk-parameter toevoegt. Klinkt een beetje dubbel, ik zou zeggen laat taal=nl dan niet toegevoegd worden. Echter, als een parameter automatisch toevoegen makkelijker is dan een automatische parameter niet meer automatisch laten toevoegen, klinkt het als een goed optie. Ennomien (overleg) 19 mrt 2022 11:11 (CET)

Er is zeker regelmatig bezwaar aangetekend dat nl niet getoond zou moeten worden, maar het is mij persoonlijk niet duidelijk in welke mate het wel/niet tonen breed gedragen wordt of niet. Gezien de hoeveelheid discussie denk ik dat het zinvol is om éérst vast te stellen of nl wel of niet getoond zou moeten worden. Als dat duidelijk is, kan er nagedacht worden over de eventuele volgende stap. Romaine (overleg) 20 mrt 2022 21:39 (CET)

Tegenvoorstel

(na bwc)

@Sietske: Wat ik schets werkt als volgt.

• Bij een referentieconversie wordt altijd |onderdruk=nl toegevoegt, ongeacht welke taal bij de conversie bepaald wordt. Staat er na de conversie |taal=en dan heeft |onderdruk=nl geen effect omdat alleen nl onderdrukt wordt. Staat er na conversie |taal=nl dan heeft |onderdruk=nl wel effect. (nl) zal niet worden getoond.
• De mensen die niet willen dat (nl) wordt onderdrukt na een conversie zullen wel iets moeten doen, n.l. |onderdruk=nl verwijderen. Ook hier is nog wel een mouw op aan te passen (kom ik zo op terug).
• Mensen zoals ik, die niets met conversies doen, maar zelf {{citeer web}} met parameters intypen is er niets aan de hand. Ik kan elke taalparameter gebruiken en deze wordt getoond.

Dan de mouw. Je zou bij "voorkeuren" een aanvink optie kunnen maken voor het onderdrukken van (nl) . Alleen wanneer deze optie is aangevinkt zal |onderdruk=nl worden toegevoegd, anders niet.

Ik ken het hele conversie mechanisme niet. Als je daar ook voorkeuren kan zetten zijn er ook andere mogelijkheden. Hoe of wat, maakt mij eigenlijk niet uit, zolang het maar niet onmogelijk wordt gemaakt om via {{citeer web}}, (nl) te tonen. Gebeurt dit wel dan zal ik direct een {{citeer web2}} creeren.

@Ennomien: Wat jij schets is volgens mij precies waar Sietske initieel om vroeg. Het niet toevoegen van |taal=nl vereist enige "intelligentie". Je wilt immers dat e.g. |taal=en wel wordt toegevoegd indien van toepassing. Het toevoegen van |onderdruk=nl is een "domme" toevoeging. Dit kan altijd. Het heeft alleen effect wanneer |taal=nl aanwezig is en dus niet bij aanwezigheid van e.g. |taal=en. Het is dus schijnbaar dubbelop. --Sb008 (overleg) 19 mrt 2022 11:28 (CET)

Dat was niet alles wat ik schetste. En ja, dat is dubbelop en zal er wat krom uitzien, maar zal wel voldoen aan alle wensen (en dat was volgens mij wat jij zei met "Wanneer het referentieconversie mechanisme ..."). Daarmee zeg ik niet dat het de beste oplossing is en ik pleit ook niet voor een bepaalde manier. Maar ik stel voor dit gesprek verder te voeren op Overleg sjabloon:Citeer web, aangezien dit meer gaat lijken op overleg/discussie dan op hulp. Ennomien (overleg) 19 mrt 2022 12:14 (CET)

Het lijkt me nog steeds een complexe oplossing voor een eenvoudig probleem. Er zijn niet of nauwelijks wikipedianen die niet willen dat (nl) wordt onderdrukt. Er zijn hooguit een paar wikipedianen die willen dat op de achtergrond « taal-nl » behouden blijft, ook al zie je die niet. Maar vooruit, in uitzonderingssituaties kan het wellicht een handig hulpmiddel zijn, dus ik zie op zich de meerwaarde van jouw voorstel wel in. Laten we dan maar meteen spijkers met koppen slaan: Sb008, kun jij het volgende doen:

1. De wijziging initiëren?
2. Na doorvoeren van de wijziging documentatie toevoegen op de betreffende sjabloonpagina’s, zodat iedereen kan teruglezen waar de extra parameter voor dient? En hij dus ook actief gebruikt gaat worden?

Ik zal op mijn beurt voortaan iedereen naar jouw project doorverwijzen die mijn « taal=nl »-toevoegingen terugdraait en me niet langer met deze discussie in de helpdesk bemoeien. Sietske | _Reageren? 19 mrt 2022 12:29 (CET)

@Sietske: Een sjabloon aanpassen is geen punt. Maar, zoals reeds aangegeven, ik ben niet bekend met de referentieconversie en hoe dit technisch geregeld wordt, Ik zou dan ook niet weten waar ik dit zou moeten initieren. Verder, ik neem aan dat het voor alle andere citeer sjablonen ({{citeer nieuws}}, {{citeer boek}}, {{citeer persbericht}}, enz) analoog zou moeten werken, en waarschijnlijk is het handiger om van sjablonen naar modules te switchen.--Sb008 (overleg) 19 mrt 2022 13:32 (CET)

Kun je uitzoeken / navragen hoe dit voor elkaar te krijgen? Het is zonde geweest van jouw tijd, mijn tijd, en de tijd van alle andere mensen in deze discussie als we nu niet doorpakken. Sietske | _Reageren? 19 mrt 2022 14:41 (CET)

Het toevoegen van |onderdruk=nl is evengoed handmatig werk als het weghalen van |taal=nl, dus dat lijkt me niet de oplossing. Automatisch onderdrukken lijkt me ook niet correct. Bij Nederlandstalige titels is het inderdaad onnodig om (nl) weer te geven; hooguit is het typografisch mooier tussen heel veel anderstalige links mét taalaanduiding. Dit geldt echter niet bij omschrijvingen als (nl) Officiële website, of (nl) Persbericht, als het gaat om een onderwerp van buiten het Nederlandse taalgebied. Wikiwerner (overleg) 19 mrt 2022 15:17 (CET)

Een heleboel discussie, redelijk fel. Ik mis alleen 1 ding, er is al gezegd dat je als alternatief als je het wel wil heel makkelijk {{taal-nl}} ervoor kunt zetten. Voor die enkele keer dat het voorkomt, wat is het bezwaar daartegen. Het Lijkt me ook verstandig de discussie naar elders te verhuizen, mogelijk de Kroeg. Akoopal _overleg. 19 mrt 2022 16:47 (CET)

Voor nieuwe gevallen zou dit afdoende kunnen zijn. Alle bestaande gevallen moeten we dan echter eerst nalopen om te kijken of het gewenst is om het taalsjabloon toch weer te geven. Wikiwerner (overleg) 19 mrt 2022 16:55 (CET)

Simpelweg {{taal-nl}} voor de citeersjabloon zetten heb ik in mijn eerste reactie, 18 mrt 2022 16:01, wel geopperd (en was in vorige discussies ook aangegeven). Voor de citeersjablonen vind ik het echter geen overbodige optie om het daarin te kunnen instellen. Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 17:05 (CET)

Akoopal, je hebt gelijk dat de discussie niet hier thuishoort (zeker vanwege de lengte). Overleg sjabloon:Citeer web lijkt me een betere plek, wellicht met een notificatie in de kroeg en op WP:OG. Zo maar even doen? — Mar(c). ^[overleg] 19 mrt 2022 18:12 (CET)

Even voordat we het allemaal nodeloos ingewikkeld maken. Wat ik voor ogen had met "om met een extra parameter het tonen van (nl) te forceren" (in mijn reactie van 18 mrt 2022 23:19), is dus simpelweg een extra parameter, bijvoorbeeld "toonnl", waarmee (nl) wél getoond kan worden indien taal=nl (of een nl-variant). Dan krijg je met een kleine aanpassing het volgende:

• {{Citeer web|titel=Favorite Things|url=https://example.com/|datum=2022-03-19|taal=nl-NL}} → Favorite Things. Neerlands Magazien (19 maart 2022).
• {{Citeer web|titel=Favorite Things|url=https://example.com/|datum=2022-03-19|taal=nl-NL|toonnl=ja}} → (nl) Favorite Things. Neerlands Magazien (19 maart 2022).

Dit is in wezen wat Sb008 voorstelt, maar dan omgekeerd: een parameter om (nl) te forceren in plaats van te onderdrukken. Met als argumentatie:

1. dit is een Nederlandstalige site, en de taal-parameter bestaat primair om de lezer te informeren dat een link anderstalig is (de extra parameter is dus om de uitzonderingsgevallen te kunnen bedienen, vgl. de voorschriften op Sjabloon:Taal-nl),
2. daarmee hoeft het overgrote merendeel van de {{Citeer web}}-gevallen niet van een extra parameter voorzien te worden (wat het voor de meeste Nederlandstalige links noodzakelijk zou maken, óók als {{Citeer web}} met de hand wordt ingevuld; en voor de anderstalige links is onderdruk=nl al helemaal nutteloos),
3. zo hoeft er niet onnodig geknutseld te worden aan VE-software e.d.

Als er redenen zijn om ook andere talen dan (nl) te kunnen onderdrukken, laat die dan even weten. Ik ben daar niet van uitgegaan in deze doelgerichte, simpele aanpak. Oók omdat ik dat niet in eerdere discussies (de uitgebreidste die ik vond is deze van juli 2019) geopperd heb zien worden; de voornaamste (en mogelijk enige) issue is dat een aanduiding (nl) voor een Nederlandstalige link overwegend als overbodige informatie gezien wordt, voor zover ik heb kunnen nagaan.

En tot slot, even voor de duidelijkheid: mijn insteek is vooralsnog puur de algemene weergave – dus zoals het voor alle lezers eruit ziet – en dat er dus per referentie geregeld kan worden of (nl) wel of niet ingevoegd wordt. Ik zie nu dat ik de bijdrage 18 mrt 2022 20:13 van Sietske vannacht mogelijk verkeerd begrepen heb; daarin lijkt het (mede) om een instelling in de voorkeuren te gaan, waarmee elke individuele (ingelogde) lezer de zichtbaarheid van (nl) zou kunnen aan- of uitzetten (vergelijkbaar met de instelling "Verberg de uitleg boven de dagpagina's van de beoordelingslijst"). Dit is een totaal andere insteek/doel, die ik evenmin in eerdere discussies heb gelezen; ik heb een vermoeden dat dat hierboven uit miscommunicatie is ontstaan. Mag ik aannemen dat zo'n instelling in de voorkeuren totaal niet aan de orde is?

Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 16:56 (CET)

Ook hier geldt wat ik hierboven schrijf (1 minuut geleden, dus misschien stond dit er nog niet toen je jouw reactie schreef): Voor nieuwe gevallen zou dit afdoende kunnen zijn. Alle bestaande gevallen moeten we dan echter eerst nalopen om te kijken of het gewenst is om het taalsjabloon toch weer te geven. Wikiwerner (overleg) 19 mrt 2022 17:06 (CET)

Ik had inderdaad last van bwc's. ;-)

De gewenstheid in bepaalde gevallen begrijp ik, maar als je met "eerst nalopen" bedoelt dat we de sjabloonaanpassingen terugdraaien totdat alle {{Citeer web}}-gevallen nagelopen zijn (en het voor eventuele andere citeersjablonen 'on hold' zetten), dan heb ik zo mijn bedenkingen daarbij:

• Alleen al voor {{Citeer web}} gaat dat om ruim 10.000 artikelen (als ik me niet vergis in de zoekparameters).
• Ik heb meerdere argumenten gezien voor het weergeven van (nl) – d.w.z. meerdere types situaties waarin de weergave gewenst is – en daar valt absoluut wat voor te zeggen. Maar laten we dat niet overdrijven; het ontbreken van (nl) in die situaties is niet dusdanig problematisch dat deze ontwikkeling geblokkeerd dient te worden, toch?
• Er wordt al minstens (een kleine) drie jaar "nl" of "|taal=nl" uit de artikelen verwijderd vanwege de breedgedragen ongewenstheid van (nl) voor elke willekeurige Nederlandstalige externe link, en ondanks de constructieve discussie van toen lijkt er nul komma niets gedaan te zijn. Terwijl wel aangegeven wordt dat het behouden van de informatie taal=nl gewenst is. Ook toen al, zie bijvoorbeeld de reactie van Effeietsanders van 31 jul 2019 17:09. Hoe lang moet er doorgerommeld worden voordat hier stappen gezet mogen worden?

Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 17:59 (CET)

Nog een andere variant voor implementatie, geïnspireerd op de constructieve discussie hierboven:

• Stel {{taal-nl}} zo in, dat deze standaard niets toont, tenzij er een parameter aan wordt meegegeven: {{taal-nl|toon=ja}}
• Vervolgens kun je inderdaad bij sjablonen die taal-nl gebruiken, die parameter doorgeven via een toon-nl constructie zoals hierboven al gesuggereerd.
• Ten slotte kan er dan via css ongetwijfeld iets bedacht worden om voor de enkele gebruiker die toch graag (nl) wil zien, die juist wel te tonen.

Dit behoudt de informatie, voorkomt een hoop kleine edits, en biedt de gewenste flexibiliteit om in uitzonderingsgevallen toch (nl) te tonen. Nadeel is dat we een veelgebruikt sjabloon creëren en aanroepen dat eigenlijk voor de meeste mensen helemaal niets doet. -- Effeietsanders (overleg) 19 mrt 2022 18:28 (CET)

De discussie hier heeft m.i. het uitgangspunt dat (nl) overwegend als nutteloze/overbodige informatie voor de lezers wordt gezien, maar in uitzonderingsgevallen (zoals benadrukken dat een site in het Nederlands is, of voor uniformiteit in een lijst met overwegend anderstalige links; zie Sjabloon:Taal-nl) niet ongewenst is, en heeft als doel erachter te komen wat een goed werkbare methode is voor Wikipedianen (middels aanpassingen in sjablonen/modules/software) om dát te bereiken.

Het lijkt me niet handig om deze discussie verder te verbreden naar buiten de citeersjablonen. Als iemand (nl) expliciet ingevoegd heeft met {{nl}} of {{taal-nl}}, dan zal dat overwegend (per definitie) bewust gedaan zijn om die te tonen, om welke reden dan ook (zoals genoemde uitzonderingsgevallen). En zoals ik om 16:56 al probeerde duidelijk te maken: volgens mij gaat bij degenen die (nl) in bepaalde gevallen wél willen tonen erom, dat het duidelijk/netjes is voor álle lezers, niet omdat ze het puur voor zichzelf willen verduidelijken/verfraaien. Als ik dat mis heb, is het goed om het te bediscussiëren, maar dan wel gescheiden van deze discussie (op Overleg sjabloon:Taal-nl bijvoorbeeld), om te voorkomen dat het nog ingewikkelder wordt (er wordt hier al genoeg langs elkaar heen gepraat).

Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 21:39 (CET)

@Mar(c): In beginsel maakt het mij niet uit of er een |toon= of |onderdruk= is. Ik koos echter bewust voor "onderdruk" omdat ik er, voor mensen die waarde hechten aan het niet tonen van (nl) , er vanuit ging dat deze |taal=nl inmiddels waar gewenst verwijderd hebben. Standaard niet tonen en middels |toon= toch wel tonen betekent dat alle reeds aabwezige instanties van {{citeer web}} moeten worden gecontroleerd of eventueel |toon= moet worden toegevoegd. Standaard wel tonen en middels |onderdruk= toch niet tonen heeft geen impact op de reeds aanwezige instanties van {{citeer web}}. Wel op de nieuwe instanties die als gevolg van een conversie gaan worden toegevoegd. En dat was immers ook de bedoeling. De facto is dit een soort van downwards comptible principe, wat m.i. altijd het uitgangspunt moet zijn. Ik noem overal |toon= en niet |toonnl= omdat dat het gebruik van een taallijst mogelijk maakt, e.g. |toon=nl,de,fr.

Ik vind de (nl) aanduiding niet per definitie overbodig. Als ik 20 referenties heb waarvan er 18 of 19 anderstalig zijn, oogt het wel zo netjes wanneer dan toch voor alle referenties een taalindicator staat. Verder, als je met grote regelmaat op wiki komt zal je t.z.t. wel duidelijk zijn dat geen taalindicator impliceert dat de taal "nl" is. Voor de eenmalige of incidentele bezoeker is dit minder evident. Ook kan een titel misleidend zijn. Wanneer gerefereerd wordt naar het boek "Gödel, Escher, Bach" en de taalindicator ontbreekt, denk ik toch eerst aan de Engelse versie en niet aan de Nederlandse vertaling. Mogelijk zijn er zelfs mensen die, gezien de namen, aan een Duitstalig boek denken.

Een "onderdruk" parameter via een voorkeur wel of niet toevoegen blijft m.i. het moeiste. Als we met een lege wiki zouden beginnen kan dit ook het toevoegen van een "toon" parameter zijn. Echter we hebben een bestaande situatie, en wegens de downwards compabiliteit, geniet "toon" dus niet mijn voorkeur. Om dezelfde reden heeft de situatie dat {{citeer web}} geen (nl) toont, en dat ik {{taal-nl}} handmatig moet toevoegen om (nl) toxh te tonen, ook niet mijn voorkeur. Al het bestaande moet weer gecontroleerd worden --Sb008 (overleg) 19 mrt 2022 18:46 (CET)

Het lijkt me sterk dat taal=nl "inmiddels waar gewenst verwijderd" is; mijn beeld is dat er al jaren een impasse is omdat er nooit doorgepakt is, en dat er in de tussentijd vast veel weggehaald is, maar er ook genoeg bijgekomen door invoegingen van citeersjablonen middels de visuele editor, waarbij taal=nl niet weggehaald is. Verder:

• Bij toon versus onderdruk ga je voorbij aan mijn argumenten 2 en 3. Weet je inmiddels waar of hoe je dit in VE aangepast moet krijgen? Ik niet. En Romaine had er destijds ook al een hard hoofd in óf we dit überhaupt voor elkaar kunnen krijgen (reactie 30 jul 2019 17:35).
• Ik snap je punt van *backward *compatibility, maar begrijp je wel dat het op jouw manier nodeloos ingewikkeld wordt? En dat we dan, in plaats van alleen de nu aanwezige instanties, alle toekomstige instanties moeten blijven controleren/aanvullen? (Ook als de aanpassing van VE zou lukken, dan zitten we nog met alle nieuwe handmatig ingevoegde citeersjablonen.)
• Over "moeten worden gecontroleerd" als we de toon-manier gebruiken: zie mijn reactie hierboven van 17:59. En zoals gezegd, met onderdruk zitten we met net zo goed, en blijvend, met een zekere noodzaak van controleren.
• Over het gebruik van een taallijst mogelijk maken: je hebt nog niet duidelijk gemaakt in welke situaties je iets als onderdruk=nl,de,fr nodig zou achten. En met de toon- of toonnl-parameter is deze alleen nodig om te forceren dat de standaard niet ingevoegde (nl) tóch ingevoegd wordt (we gaan deze aanpassing niet uitbreiden met andere talen, lijkt me). Iets als toon=nl,de,fr is dus per definitie niet nodig. Als je met zoiets bedoelt aan te geven dat de genoemde bron meertalig is: daarvoor is de taal-parameter (zoals in de Engelse versie).

Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 23:38 (CET)

Mijn twee cent: het gaat er denk ik om dat de hier aangeboden kennis zo goed mogelijk voor iedereen wordt ontsloten. Als het mensen kan helpen dat wordt vermeld dat een bron Nederlandstalig is, dan vind ik het prima dat zulks gebeurt, zeker indien in een artikel ook anderstalige bronnen worden gegeven. Wutsje 19 mrt 2022 20:49 (CET)

Dat is precies een van de redenen die in Sjabloon:Taal-nl worden gegeven om (nl) wél te vermelden. Het gaat erom hoe we bereiken dat (nl) alleen ingevoegd wordt bij citeersjablonen, als dat om dat soort redenen expliciet gewenst wordt, en niet bij elke willekeurige invoeging van een citeersjabloon via de visuele editor (die de taalparameter voor veel sites automatisch invult, ook voor Nederlandstalige sites). Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 21:47 (CET)

Dan moeten we de visuele editor zo (laten) aanpassen dat die niet meer standaard 'nl' invult, maar alleen als de gebruiker het veld zelf invult. Wikiwerner (overleg) 19 mrt 2022 22:32 (CET)

Dan moet je misschien de discussies nog een keer lezen, dan weet je dat het gewenst is om de parameter taal wél in te vullen (of ingevuld te laten), omdat het niet alleen om die visuele aanduiding gaat. Zie o.a. de bijdrage van Effeietsanders van 31 jul 2019 17:09, waarnaar ik hierboven al verwees. Met vriendelijke groeten — Mar(c). ^[overleg] 19 mrt 2022 23:25 (CET)

Ik vind het heel goed dat deze discussie gevoerd wordt omdat in de grote meerderheid van de gevallen het absoluut onzin is om aan te geven dat de taal van een referentie Nederlands is. Dus het moet gaan over de gevallen waarin het wél wenselijk is om dat aan te geven (en diverse collega's gaan hierboven juist daarop in), en hoe in die gevallen te handelen. (Onnodig provocerende opmerking verwijderd door Mar(c).) WIKIKLAAS overleg 20 mrt 2022 00:36 (CET)

Gelieve de discussie hier inhoudelijk te houden. Ik heb de opmerking en de reactie verplaatst naar de OP van Sb008. — Mar(c). ^[overleg] 20 mrt 2022 12:22 (CET)

Met die reactie van Effeietsanders ben ik het dus niet eens, zoals daar ook te lezen is, direct erboven. Voordat je besluit om (nl) standaard te verbergen, zullen we iets moeten doen met de bestaande gevallen. Pas als die nagelopen zijn, kunnen we ervoor kiezen om voortaan de toon-manier te gebruiken bij nieuwe gevallen. Wikiwerner (overleg) 20 mrt 2022 09:43 (CET)

Dat lees ik daar helemaal niet. Jij hebt het duidelijk over het visuele (nl) dat gewenst is in uitzonderingssituaties (zoals "benadrukken dat een site in het Nederlands is"). Effeietsanders heeft het over het wel plaatsen, maar niet weergeven. Dat lees ik als: wél taal=nl, maar op een of andere manier niet (nl) weergeven. Op dat "pas als die nagelopen zijn" heb ik hierboven al eerder op je gereageerd. Met vriendelijke groeten — Mar(c). ^[overleg] 20 mrt 2022 10:54 (CET)

(nl) altijd tonen?

Mijn inziens is het tonen van taal=nl altijd gewenst. Ik vul het dan ook altijd standaard in. Ik ga er namelijk vanuit dat de Nederlandstalige Wikipedia ook geraadpleegd wordt door mensen die het Nederlands niet machtig zijn, en zo snel kunnen zien in welke taal de bron (boek, tijdschrift, website, krant, enz.) is geschreven. Ik raadpleeg namelijk ook anderstalige Wikipedia's (ook als ik de taal niet beheers) om te kijken of ik daar nog andere bronnen kan vinden, en ik kan me niet voorstellen dat ik de enige ben. Dit voorstel komt er m.i. op neer dat we de lezer minder informatie geven dan voorheen, en dat schrijvers die nu trouw overal het attribuut taal invullen een omweg moeten verzinnen om die informatie alsnog te tonen. Ik vind het daarom een slecht voorstel. Mvg, Roelof Hendrickx (overleg) 20 mrt 2022 17:07 (CET)

Als de taal niet getoond wordt mag je veronderstellen dat de bron Nederlandstalig is. Uiteraard moet dan bij anderstalige bronnen wel altijd de taal gegeven worden, maar dat was in principe altijd de regel al. Ik ben voorstander van de implementatie van Mar(c). --Strepulah (💬) 20 mrt 2022 17:36 (CET)

Nee, dan mag verondersteld worden dat of de taal nl is, of dat de schrijver vergeten is het attribuut in te vullen. De lezer mag raden welke veronderstelling de juiste is. Want de regel dat bij anderstalige bronnen altijd het taalattribuut wordt ingevuld, wordt lang niet altijd gevolgd.

Overigens zag ik dat de wijziging al is geïmplementeerd. Dus voor mij is het sjabloon zodanig beperkt dat ik het in de toekomst niet meer zal gebruiken. Mvg, Roelof Hendrickx (overleg) 20 mrt 2022 20:53 (CET)

Het is voor de lezer bijna altijd heel instructief om de titel van de referentie even te lezen. Iemand die ooit heeft leren lezen heeft dan doorgaans meteen in de gaten of daar Nederlands staat of niet. Dan gaat het dus goed, behoudens in het geval dat Erik Wannee al in het begin aanhaalde: een Nederlandstalig artikel met een Engelse titel. En dan is het handig om het er even bij te vermelden. Doe nou niet net of het aangeven van de taal van de referentie het enige is waaruit de lezer moet opmaken wat hij/zij voor de kiezen krijgt na klikken op een eventuele link. WIKIKLAAS overleg 20 mrt 2022 21:04 (CET)

Je negeert hiermee het door mij gegeven argument dat het artikel geraadpleegd kan worden die het Nederlands helemaal niet machtig is, die kan dat aan de titel dus helemaal niet zien. Net zo min als ik kan zien of een titel in het Deens, Noors of Zweeds is als ik een artikel de Deense/Noorse/Zweedse Wikipedia raadpleeg om te kijken welke bronnen daar vermeld staan. Daarvoor heb ik het taalattribuut nodig. En dat is nou precies de reden waarom ik dus altijd taal=nl invul. Het is informatie die ik heb, en dus aan de lezer toon. Want ik weet niet wat de lezer wel of niet kan, en ik weet niet waar de lezer naar op zoek is. Mvg, Roelof Hendrickx (overleg) 20 mrt 2022 21:21 (CET)

Een artikel op de Nederlandstalige Wikipedia dat gelezen wordt door iemand die het Nederlands niet machtig is? En die zou dan wél de tekst begrijpen, maar niet de referenties? En dan staan we nog steeds met twee voeten op de grond? WIKIKLAAS overleg 21 mrt 2022 17:40 (CET)

Het spijt me, maar deze reactie getuigt van weinig respect voor wat ik gezegd hebt. Ik laat het dan ook hierbij. Roelof Hendrickx (overleg) 21 mrt 2022 19:21 (CET)

(nl) nooit tonen?

In navolging op "altijd tonen" hierboven:

Als we nu gewoon gezamenlijk afspreken dat we nooit (nl) invoegen, en bij anderstalige bronnen altijd de betreffende taalaanduiding, en we er gezamenlijk voor zorgen dat dit consequent overal gebeurt, dan is het gewoon duidelijk (ook voor mensen die het Nederlands niet machtig zijn): geen taalaanduiding = Nederlands. Klaar. We zetten immers ook geen taalaanduiding voor elke (interne) wikilink. Geen noodzaak meer om te benadrukken dat een link Nederlandstalig is, om welke reden dan ook. En dus ook geen discussie rond een individuele referentie of het daar misschien tóch nodig kan zijn om te benadrukken. Duidelijkheid zónder overbodige informatie is beter dan uniformiteit mét overbodige informatie (bovendien staat het uniformiteit-argument haaks op het benadruk-argument: géén (nl) bij de enkele Nederlandstalige links in een lijst met veel anderstalige links benadrukt duidelijker welke links Nederlandstalig zijn). Dan kunnen we ook de hele discussie toonnl versus onderdruk vergeten. En dan begin ik ook wel wat te zien in het voorstel van Effeietsanders om het voor individuele gebruikers mogelijk te maken voor zichzelf álle Nederlandstalige links van de aanduiding (nl) te voorzien. Meningen?

Met vriendelijke groeten — Mar(c). ^[overleg] 20 mrt 2022 22:06 (CET)

Ik heb geen hele sterke mening over het altijd/nooit weergeven van (nl), met momenteel een lichte voorkeur voor altijd weergeven - maar die voorkeur zal ongetwijfeld nog wel eens veranderen. Wel een relatief sterke voorkeur voor het een of het ander. Waar ik meer moeite mee heb is de uitvoerbaarheid van het altijd invoeren van andere talen: we zullen nooit richting de lezer kunnen garanderen dat talen anders dan (nl) altijd worden ingevoegd. Dat kan zijn omdat de automatische referentie-aanmaak de taal niet herkent (en de auteur niet goed genoeg met de software kan omgaan om dat handmatig te doen), maar het kan ook zijn dat er van een uitzondering sprake is: de bron heeft geen taal (alleen cijfertjes, of een afbeelding bijvoorbeeld), de taal is niet duidelijk (ik kan me niet direct een voorbeeld voor de geest halen waarin de bron toch bruikbaar is, maar dat bestaat vast) of heeft meerdere talen. Als je wilt garanderen dat we hierin absoluut consistent zijn, zullen we toch de taal=nl moeten registreren, al is het maar om de gaten vervolgens te kunnen opsporen. -- Effeietsanders (overleg) 21 mrt 2022 03:59 (CET)

Garanties kunnen we nooit geven, maar we kunnen het wél afspreken en ernaar streven. Voor meerdere talen hebben we een sjabloon (meertalig) , zoiets kan ook in de citeersjablonen verwerkt worden, of beter nog t.z.t. de taal-parameter geschikt maken voor meerdere talen (zie de Engelse versie van Citeer web). Voor curiositeiten als 'geen taal' of 'taal onduidelijk' valt ook wel wat te maken, indien echt nodig. Voor opsporing van niet- of foutief ingevulde taal-parameter kunnen we werken met een verborgen categorie en een (voor de lezer onzichtbare) foutmelding.

Ik ben wel bloedserieus dat dit theoretisch de beste optie is (al had ik dit subkopje gemaakt uit verzuchting), en dat besef ik al sinds het begin van de discussie. Wat ik ook besef is dat – in de praktijk – de uitvoerbaarheid niet zozeer te lijden zal hebben onder eventuele curieuze of technische beren op de weg (zoals die je hier benoemt), maar veel meer onder de eigenwijsheid van collega's. Want als hieruit een 'afspraak' voortvloeit, zijn er zoals gewoonlijk genoeg collega's die de eigen mening belangrijker vinden en hun eigen methodes blijven toepassen (tja, het is 'toch maar' een afspraak). En als er een poging wordt gedaan om er een richtlijn van te maken, wordt dat geblokkeerd door "dit tast de vrije bewerkbaarheid aan", "als dit een richtlijn wordt dan staat het nu in duizenden artikelen fout", "de richtlijn moet strenger anders gaat men zich er niet aan houden", "alle uitzonderingen moeten in de richtlijn anders kan ik er niet van afwijken als zich een evident uitzonderingsgeval voordoet", "met dit als richtlijn ga ik geblokkeerd worden als ik het fout doe", "ik ben stellig over mijn afwijkende mening want ik pretendeer hier verstand van te hebben", etc. Het gebruikelijke riedeltje als er gepoogd wordt een projectbrede afspraak (zeker op het gebied van vormgeving/opmaak) te maken. Met als gevolg dat we blijven doormodderen met ruzietjes, bewerkingsoorlogen, artikelbazerij, divagedrag etc. rond niet eens inhoudelijke zaken. Een uitgebreidere stijlgids zou het project ontzettend ten goede komen.

Ik deel je sterke voorkeur voor óf het een óf het ander, wat ook ik belangrijker vind dan wélke van de twee het wordt. Maar of een afspraak/richtlijn nou beoogt 'altijd weergeven' of 'nooit weergeven' te bewerkstelligen, het gepruttel zal er niet wezenlijk anders door worden. Uitdaging aan de gemeenschap: proof me wrong.

Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 14:17 (CET)

Bedankt voor de samenvatting, hoe nu verder?

De samenvatting is fijn, want er was in heel korte tijd heel veel overleg ontstaan. Dit is dan ook een prachtige fietsenschuur. Ik denk dat iedereen die voor het tonen van (nl) is voldoende wordt bediend door de in de samenvatting voorgestelde uitzonderingsmogelijkheden. Als ik er van uit ga dat we hebben besloten dat het dus verborgen gaat worden (dat hebben we nog niet besloten, dat weet ik), kunnen we dan misschien ook alvast afspreken dat we niet retroactief overal weer taal=nl gaan invullen, maar dat ook niet gaan reverten als iemand dat kennelijk toch nodig vond? Dat scheelt alvast weer een hoop gedoe, denk ik. –Frank Geerlings (overleg) 20 mrt 2022 18:39 (CET)

Dank voor het compliment. Als dit voorstel geaccepteerd wordt, d.w.z. als we het wel/niet invoegen van (nl) door de citeersjablonen volgens mogelijkheid 1 gaan doen, dan lijkt het me evident dat een toevoeging van taal=nl niet gerevert wordt. (Sterker, van mij mogen ze wél, bij voorkeur botmatig, teruggeplaatst worden.)

Als. Want deze fietsenschuur hoeft zeker niet per se volledig egaal te worden, maar aangezien sommige gebruikers het niet eens wat kan schelen of de schuur in z'n geheel nog enigszins toonbaar wordt, en het alleen belangrijk vinden dat hun 'eigen' plintjes de kleur krijgen die ze zelf het beste achten, is een volgende jarenlange impasse van besluiteloze richtingloosheid ook nog best een voorstelbaar scenario.

Met vriendelijke groeten — Mar(c). ^[overleg] 20 mrt 2022 22:41 (CET)

Het is niet per se evident, want als je straks (als nl niet zichtbaar is) taal=nl toevoegt, dan "verandert er niks" en is het "dus" en WP:BTNI-wijziging. BTNI wijzigingen mogen niet. (Ik vind het niet erg BTNI af te schaffen overigens) –Frank Geerlings (overleg) 21 mrt 2022 11:39 (CET)

De B-vlag (zojuist verboden term verklaard) is totaal niet van toepassing; mocht de geheel hypothetische situatie zich voordoen dat we hier echt stappen zetten, bijvoorbeeld met mogelijkheid 1, dan gaat het toevoegen van taal=nl om een technische verbetering per de derde bullet van de samenvatting. Vergelijkbaar met het herstellen van lintfouten, het aanduiden van de taal van een stuk tekst met de attribute lang, het juiste gebruik van interpunctie, allemaal ter verbetering van de accessibility (en de laatste ook zichtbaar). De B-term is om nutteloze wijzigingen in taal en structuur tegen te gaan (en wordt inderdaad veelvuldig misbruikt; over "bij het hanteren van de richtlijn moet het gezonde verstand worden gebruikt" wordt maar al te graag heen gelezen). Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 13:09 (CET)

Preaching to the choir natuurlijk, ik snap ook wel dat het vermelden van taal=nl van nut is, maar dat is dus niet voor iedereen glashelder. Misschien nu wel. Als we maar hebben uitgesproken dat het uitsluitend en alleen toevoegen geen nutteloze wijziging is dan hoeft het woord niet meer te worden genoemd. Daarmee is dit kopje wat mij betreft afgesloten. (Het retroactief-verhaal til ik niet zo zwaar aan.) –Frank Geerlings (overleg) 21 mrt 2022 14:03 (CET)

Wat dat betreft goed dat je het benoemd hebt, dan kan daar bij deze inderdaad een streep onder. Wat mij betreft staat je vraag "hoe nu verder?" nog open. Tenzij van mij verwacht wordt dat ik heel dictatoriaal een beslissing neem natuurlijk. Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 14:28 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Jouw voorstel (waar best wel veel voorstanders voor zijn, dus zo dictatoriaal is het niet) staat al live voor {{Citeer web}} (deze twee edits, toch?), dus we kunnen er alvast aan wennen. De documentatie moet nog worden bijgewerkt en het moet nog worden doorgevoerd in {{Citeer boek}}, {{Citeer tijdschrift}}, {{Citeer tweet}}, {{Citeer hoofdstuk}}, {{Citeer journal}} enzovoort. Dat is denk ik hoe nu verder. –Frank Geerlings (overleg) 21 mrt 2022 17:24 (CET)

Dank voor de waarschuwing. Dan weet ik alvast dat ik die sjablonen straks ook niet meer hoef te gebruiken... Roelof Hendrickx (overleg) 21 mrt 2022 19:22 (CET)

Niets te danken hoor, tot uw dienst. Je hoeft ze niet te gebruiken inderdaad, maar het is dus nog steeds mogelijk de (nl) -vermelding wél te tonen straks, ook met die sjablonen. Dat is hierboven uitgebreid behandeld.

Maar {{nl}} in combinatie met {{aut}} is voor boeken ook prima, het is inderdaad niet nodig de Citeer-sjablonen te gebruiken. –Frank Geerlings (overleg) 21 mrt 2022 23:13 (CET)

@Frank Geerlings: Die twee edits plus de vervolgstappen die je noemt, zijn inderdaad in de basis waar het om gaat, uitgaande van dat het gewenst is om via de citeersjablonen (nl) in te kunnen voegen. Zo simpel kan het zijn, of eigenlijk: had het kunnen zijn. Echter:

Als uit een van bovenstaande kopjes een beeld ontstaat dat er een breed draagvlak is om (nl) altijd of nooit te tonen, dan hoeven we niet moeilijk te gaan doen met een extra parameter. Ik krijg, uit deze en vorige discussies, sterk de indruk dat er veel meer draagvlak is voor nooit weergeven. Ook omdat er volgens mij alleen écht tegengas tegen het schrappen van taal=nl kwam – met als doel (nl) te verwijderen – toen het botmatig werd gedaan. En eerlijk is eerlijk: feitelijk is mijn voorstel, met de parameter toonnl, al een vorm van nooit. Alle huidige aanduidingen (nl) via de citeersjablonen zullen immers verdwijnen, totdat iemand toonnl toevoegt. Degene die (door het gestrekte been en alle miscommunicatie die erop volgde) eigenhandig gezorgd heeft voor een verdubbeling van de lengte van deze discussie, heeft wat dát betreft zeker een punt (zie zijn constructieve bijdrage van 19 mrt 2022 18:46 en mijn reactie erop; helaas heeft hij ervoor gekozen daar niet meer op in te gaan). Ook Wikiwerner heeft bedenkingen op dat punt, en vindt dat eerst alle bestaande gevallen nagelopen dienen te worden, of het wellicht gewenste uitzonderingsgevallen betreffen (zie 19 mrt 2022 17:06 en mijn reactie daarop). Onhaalbaar in mijn ogen, maar ik geef hem graag nog een keer de gelegenheid om op mijn tegenwerping te reageren.

Dit zijn zo'n beetje de zaken die me tegenhouden om de vervolgstappen al te nemen. En ja, mijn verwoede pogingen om deze discussie in goede banen te leiden, zonder ze te willen sturen, zouden best kunnen overkomen – of fijntjes worden aangegrepen – als dictatoriaal gedrag, daar houd ik wel rekening mee (en die term was daarnaast een knipoog naar de suggestie 'adviseur worden van Kim Jong-un'). Voor de zorgvuldigheid een minipeiling altijd versus nooit versus nooit-met-toonnl als eerstvolgende stap?

Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 20:13 (CET)

Dus alleen omdat het "onhaalbaar" is om alle oude NL-sjablonen na te lopen op gewenstheid, halen we ze maar allemaal weg? Dat is immers het gevolg van de actie in het Citeer web-sjabloon. Ik blijf het eens het Sb008: eerst de oude gevallen nalopen. Hoe moet dat dan? Dat is niet aan mij. Het argument van de meta-informatie, bijv. om referenties te kunnen categoriseren op taal, hoor ik voor het eerst in dit overleg en is m.i. een gezocht argument. Als je (nl) niet wilt tonen, dan haal je taal=nl weg uit het betreffende artikel. Wikiwerner (overleg) 21 mrt 2022 20:47 (CET)

Dat dat "immers het gevolg" is, dat geef ik ook al aan. Even in stappen:

Eén: Doorgaans heeft het geen nut om aan te geven dat een externe website Nederlandstalig is, ben je het daarmee eens?

Twee: Vind je het, om de doorgaans ongewenste (nl) tegen te gaan, logisch dat er ofwel continu nabewerkingen nodig zijn (zoals de afgelopen jaren gebeurde), ofwel dat overal waar een citeersjabloon gebruikt wordt, deze met een extra parameter uitgerust wordt om juist dat restje waar het wél gewenst is te bedienen (zoals Sb008 bepleit; en áls het [laten] aanpassen van VE al mogelijk zou zijn, anders zitten we alsnog met nabewerkingen)?

Drie: Vind je serieus dat er eerst nagelopen moet worden, zonder dat je zelf een idee hebt hoe dat dan moet gebeuren?

Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 21:21 (CET)

1. Doorgaans heeft het geen nut, maar soms dus wel. Die gevallen mag je niet automatisch slachtofferen.

2. Ja, mits met duidelijke uitleg op de sjabloonpagina.

3. Ja, dat vind ik logisch. Het is immers niet mijn idee. Zonder na te lopen gooi je gevallen weg waar de aanduiding wél nuttig c.q. nodig is. Wikiwerner (overleg) 21 mrt 2022 21:53 (CET)

1. Dank je. Over "slachtofferen": heb je enkele links naar pagina's waar het nu zo dramatisch mis gaat?

2. Wat bedoel je met "mits met duidelijke uitleg op de sjabloonpagina"? Is dat een reactie op het deel van mijn vraag na de tweede 'ofwel'? Wat lost een "duidelijke uitleg op de sjabloonpagina" op, dat in ruim 99% van de gevallen dat een citeersjabloon gebruikt wordt, daar een extra parameter aan toegevoegd en ingevuld moet worden om het doorgaans gewenste effect te bereiken, versus minder dan 1% dat het nut (dus niet eens dringende noodzaak) heeft om daar niets te hoeven doen? Waar zit de logica in uitzonderingen mogelijk maken door bij alle andere gebruik van de citeersjablonen de noodzaak van een extra parameter af te dwingen? En wat lost die uitleg op aan dat de VE mogelijk niet eens aangepast gaat worden?

3. Het is niet jouw idee, dus je vindt het normaal om maar te eisen dat anderen (want je hebt zelf geen idee hoe dat aan te pakken) duizenden artikelen gaan langslopen, om vast te stellen of een aanduiding die soms nuttig (dus niet eens dringend noodzakelijk) zou kunnen zijn, inderdaad aan een uitzonderingsvoorwaarde voldoet?

Met vriendelijke groeten — Mar(c). ^[overleg] 21 mrt 2022 23:26 (CET)

Het gaat om 14.000 artikelen. Ik wil mezelf wel opwerpen om bij allemaal te controleren of ik het noodzakelijk vind dat er (nl) blijft staan. Ik ben daar in minder dan een minuut mee klaar. 🙂 Waarmee ik bedoel te zeggen dat het zeer subjectief is, en het dus niet uitvoerbaar is. Tenzij je het óf allemaal weghaalt óf allemaal laat staan. Al het andere is willekeur. Je weet nooit wat de afwegingen waren van degene die het citaat toevoegde, en of er wel een afweging is gemaakt ten tijde van het plaatsen. Zowel het achterwege laten als het laten staan van de taalcode kan zonder nadenken gebeurd zijn. –Frank Geerlings (overleg) 21 mrt 2022 23:48 (CET)

@Mar(c) - Wat betreft slachtofferen: zie mijn reactie van 19 mrt 2022 15:17 en ook die van Wickey van 22 mrt 2022 15:44 direct hieronder. Een aanpassing in het sjabloon gaat logischerwijs samen met uitleg daarover. Mensen moeten de (nl) immers kunnen blijven plaatsen. Over je laatste punt: dat vind ik inderdaad normaal en dat is ook hoe het normaliter gaat op Wikipedia. Wikiwerner (overleg) 22 mrt 2022 19:55 (CET)

Beste Wikiwerner,

• Met je standpunt "Automatisch onderdrukken lijkt me ook niet correct" (ik neem aan dat je met "zie mijn reactie van 19 mrt 2022 15:17" daarnaar verwijst) ben ik bekend. Het doet mij ook erg pijn, maar ik zie geen beter werkbare en logischer oplossing dan het huidige voorstel (mogelijkheid 1 in de samenvatting; geen-aanduiding-tenzij-toonnl), om de noodzaak tot nabewerken zoals die de afgelopen jaren er was weg te nemen. Jij wel? (Of iemand anders?) Laat dat dan even weten, met duidelijke en concrete aanwijzingen wat er waar gewijzigd zou moeten worden.
• Je antwoord "mits met duidelijke uitleg" was geen antwoord op een veel uitgebreidere schets van de problemen met de Sb008-aanpak (mogelijkheid 2 in de samenvatting); prima, ik zal er niet verder over doorvragen. Het huidige voorstel voorziet in de behoefte om (nl) te blijven plaatsen, en uiteraard komt er een uitleg op de sjabloonpagina. Tevreden?
• Interessant dat je absurde dingen van anderen eist. Maar goed, ik had tussendoor al rond 1% van die duizenden pagina's bekeken, en als ik dat extrapoleer naar alle betreffende pagina's, dan kom ik net als Frank op 0 (nul) pagina's waar het dringend noodzakelijk is. Nalopen: check. Tevreden? (Of anders, nogmaals: wijs me op een paar pagina's waar die noodzaak er wél is.)

Tot slot: je ziet dat ik erg geduldig kan blijven in mijn pogingen om dingen te verduidelijken, en in mijn pogingen om anderen hun punt te laten verduidelijken, maar dat geduld ga ik natuurlijk niet ad infinitum hooghouden. Uit je korte, weinigzeggende antwoorden kan ik niet opmaken of je überhaupt snapt waar de schoen wringt in het initiële probleem en in de suboptimale oplossing, of dat je principieel dwarsligt omdat er inderdaad wat bewust geplaatste niet-noodzakelijke-maar-hooguit-nuttige aanduidingen vervallen (in dat geval: vraag je eens af of je de prioriteiten goed weegt), of dat je nu niet meer wil of kan toegeven dat je het verkeerd zag, of dat je lekker wil traineren omdat dát inderdaad is "hoe het normaliter gaat op Wikipedia" – of iets anders, ergens tussen dat alles in. Met of zonder concretere antwoorden, en met of zonder concreet en goed uitvoerbaar tegenvoorstel; rond het weekend (als het aan mij ligt; ik heb de komende paar dagen i.i.g. wat minder tijd) zullen er toch vervolgstappen gezet gaan worden, al dan niet met een minipeiling of zo als eerste stap.

Met vriendelijke groeten — Mar(c). ^[overleg] 22 mrt 2022 23:23 (CET)

Ik ben inderdaad tegen omdat er "bewust geplaatste aanduidingen vervallen". Hoeveel dat er zijn, en of die allemaal "niet-noodzakelijk-maar-hooguit-nuttig zijn, dat weet ik niet en daar gaat het ook niet om: het gaat erom of de voorstanders kunnen garanderen dat die gevallen er niet zijn. Dat kun je principieel noemen, maar vind ik de normaalste zaak van de wereld. Stel dat iemand met een botscript al die |taal-nl-aanduidingen blind zou weghalen, dan zou Wikipedia te klein zijn. Maar ja, een aanpassing in een sjabloon, dat komt niet voorbij op Volglijsten, tenzij het sjabloon op je Volglijst staat. Maar goed: je hebt naar eigen zeggen 1%, dus 140 pagina's (?) nagelopen? Wikiwerner (overleg) 23 mrt 2022 20:38 (CET)

Wikiwerner, uit "het gaat erom of de voorstanders kunnen garanderen dat die gevallen er niet zijn" maak je duidelijk dat het je om principieel dwarsliggen gaat, want je weet dat dat een onmogelijke exercitie is. Tenzij je wil aannemen dat het nooit per se noodzakelijk is (voor de derde maal: kom maar eens met een paar pagina's waar die noodzaak er wél is). — Mar(c). ^[overleg] 23 mrt 2022 20:51 (CET)

Opiniepeiling?

Aangezien NL hier de standaardtaal is, is het volkomen overbodig om dit te vermelden. Een zeldzame uitzondering zou zijn als er enkele Nederlandse bronnen tussen een heleboel anderstalige bronnen zouden staan, of als de titel een niet-NL-bron suggereert. In dat geval zou het taalsjabloon kunnen worden toegevoegd.

Ik heb de indruk dat we er zo niet uitkomen, dus een opinie-peiling lijkt voor de hand te liggen. Ik stel voor om dan te beginnen met een keuze tussen 'altijd' en 'nooit plus incidenteel Sjabloon:Taal-nl'. Wickey (overleg) 22 mrt 2022 15:44 (CET)

Heb je geturfd hoeveel mensen voor 'altijd' hebben gestemd in het bovenstaande? Wat was de uitkomst? –Frank Geerlings (overleg) 22 mrt 2022 16:40 (CET)

Nee, niet geturfd. Jij wel? Wickey (overleg) 22 mrt 2022 18:55 (CET)

1. –Frank Geerlings (overleg) 22 mrt 2022 21:21 (CET)

Na een zorgvuldige hertelling van alle turven, kom ik tot de conclusie dat dat een vrij accurate (+/-0) benadering is van het aantal 'altijd'-voorstanders. — Mar(c). ^[overleg] 22 mrt 2022 23:28 (CET)

Dit gemanipuleer geeft wel duidelijk aan dat een opinie-peiling geen overbodige luxe is. In bovenstaande rataplan valt niets te turven. Wickey (overleg) 23 mrt 2022 12:16 (CET)

Huh? Ik ben een beetje in de war over deze reactie. –Frank Geerlings (overleg) 23 mrt 2022 12:45 (CET)

Ik ook. Welk gemanipuleer? Ik zie in deze hele discussie alléén onder het subkopje #(nl) altijd tonen? iemand ervoor pleiten om altijd (nl) in te voegen bij externe links naar Nederlandstalige websites (reactie 20 mrt 2022 17:07). Eén iemand. Kun je een andere naam/reactie aanwijzen? Of interpreteerde je Franks vraag "geturfd hoeveel mensen voor 'altijd' hebben gestemd" anders?

Ik suggereerde 21 mrt 2022 20:13 al een minipeiling als eerstvolgende stap, inclusief die optie 'altijd'. Franks vraag aan jou lijkt voort te komen uit jouw suggestie om de keuze aanvankelijk te beperken tot maar twee opties – zonder de optie 'nooit', die gezien alle discussies een veel aannemelijker uitkomst van een peiling is dan de optie 'altijd'.

Met vriendelijke groeten — Mar(c). ^[overleg] 23 mrt 2022 13:22 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘"een vrij accurate (+/-0) benadering [is] van het aantal 'altijd'-voorstanders" is op zijn zachtst gezegd een nogal ambivalente formulering.

Ik heb zelf een duidelijk argument gegeven voor het nooit weergeven van 'nl'. Ik zie hierboven geen enkel redelijk argument voor het altijd weergeven.
Misschien hebben jullie mijn optie 2 verkeerd geïnterpreteerd. 'Nooit plus incidenteel Sjabloon:Taal-nl' komt in feite neer op de optie 'nooit', waarbij het een ieder vrijstaat om incidenteel handmatig het taal-sjabloon toe te voegen. Een optie die sowieso bestaat, tenzij het taal-sjabloon wordt verwijderd. Dat is dan een andere discussie. Wat mij betreft mogen het ook meteen 3 opties zijn. Dan wordt het

• altijd
• nooit
• soms
  

Maar dan krijg je ook weer een onduidelijker uitkomst van de peiling. Dan krijg je weer discussies over wanneer je het soms mag toevoegen.
Wickey (overleg) 23 mrt 2022 14:56 (CET)

Ah, dan snap ik de verwarring. Met "Na een zorgvuldige hertelling" etc. verwees ik naar Franks bondige antwoord 1, wat ik ermee bevestigde. Excuses dat ik dat met een grappig bedoelde formulering deed.

En we zitten zo te lezen volkomen op één lijn. Je duidelijke argument voor nooit weergeven is inderdaad het breedgedragen sentiment (velen zijn het daarmee eens), en is precies de reden dat de sjabloon Citeer web is aangepast (=het huidige voorstel, misschien ook uit te breiden naar de andere citeersjablonen). Dat het in feite neerkomt op 'nooit': klopt, en mee eens dat dat gebeurt. Maar hierboven ben ik nog wat met Wikiwerner aan het sparren of wellicht een andere aanpak beter zou zijn. Overigens, behalve met Sjabloon:Taal-nl is het in het huidige voorstel ook mogelijk om de aanduiding (nl) te genereren met een extra parameter in Citeer web: {{Citeer web|...|taal=nl|toonnl=ja}}.

Mijn voorstel is: even kijken of er nog wat uit dat sparren komt, dan rond komend weekend iets van een (mini)peiling. Met vriendelijke groeten — Mar(c). ^[overleg] 23 mrt 2022 16:32 (CET)

Ik begrijp niet hoe de verwarring kon ontstaan, maar ik ben nu niet meer in de war. Hooguit wat verbaasd. 🙂 –Frank Geerlings (overleg) 23 mrt 2022 16:41 (CET)

Ik had bovenstaande discussie niet gevolgd, dus je begrijpt wel dat ik die chaos niet uitgebreid ga analyseren.

Als we het er over eens zijn dat vermelding onlogisch en onzinnig is, dan zullen we het er ook wel over eens zijn dat het onwenselijk is om deze optie in het citeersjabloon op te nemen. Als mensen bij het invullen zo'n optie tegenkomen zullen ze mogelijk denken dat het juist wenselijk of noodzakelijk is om het in te vullen. Dat is alleen te voorkomen door nl pro-actief te blokkeren. Maar hoe dat technisch zit weet ik niet. Wickey (overleg) 23 mrt 2022 18:14 (CET)

Met de moeilijkdoenerij van sommigen, ben ik dat ook steeds meer geneigd te doen: keihard Sjabloon:Taal-nl leegmaken zodat het nergens meer verschijnt. Hoppekee, einde discussie.

Maar goed, met de instructie 'wordt soms gebruikt' plus uitzonderingssituaties zoals genoemd in de sjabloondocumentatie, wat er al bijna 14 jaar staat, is zulk gebruik in uitzonderingssituaties blijkbaar wel geaccepteerd. Ook uit de discussies heb ik niet de indruk dat er een overheersende wens zou zijn om dat helemaal te voorkomen. Dus dan vind ik het wel zo netjes om het middels zo'n extra parameter te faciliteren.

Met vriendelijke groeten — Mar(c). ^[overleg] 23 mrt 2022 20:27 (CET)

Er wordt dagelijks heel wat bewust aan WP toegevoegd dat vervolgens door anderen weer wordt verwijderd. En ja, ik heb ook wel eens iets na meer dan 10 jaar verwijderd omdat het onzin was. Wickey (overleg) 24 mrt 2022 13:45 (CET)

(for the record, ik ben zelf ook voorstander van 'altijd tonen', maar heb me er allang bij neergelegd dat dat nooit op voldoende steun zal kunnen rekenen - zoals hierboven ook aangegeven (dat turven was dus niet zo supernauwkeurig :) ). Redenen hiervoor? Consistentie in layout (altijd een taal levert een rustiger beeld op), toegankelijkheid (voor iemand die geen andere talen machtig is, is het wel fijn om snel te zien of bronnen Nederlandstalig zijn) en de opkomst van vertaaltechnologie, en daarmee de mogelijkheid dat iemand die het Nederlands geheel niet machtig is, een artikel hier leest. De aanname dat iemand uit de titel van de bron moet kunnen afleiden in welke taal die is gesteld, of dat iemand ervanuit moet kunnen gaan dat geen-taal-is-nederlands opgaat, ga ik niet in mee. Maar het is verder een lichte voorkeur. Ik vind het belangrijker dat we "onder water" registreren als de bron in het Nederlands is, dan of dat ook zichtbaar is voor de lezer. -- Effeietsanders (overleg) 23 mrt 2022 22:56 (CET) )

De turfmachine stond nogal strak afgesteld, vandaar dat "geen mening met een lichte voorkeur voor altijd tonen" (ik parafraseer een klein beetje) als geen mening is geteld, dus ik heb daarmee onbedoeld de hele boel bedonderd. Bij hertelling zitten we nu op 2.

Ik zou zelf geen bezwaar hebben tegen 'helemaal nooit tonen, ook andere talen n iet', maar zou de taal dan toch liever wel vastleggen zodat de titel goed kan worden uitgesproken door spraaksynthesesoftware. Ik hoef niet in discussie over 'nooit tonen', ik til er niet zwaar aan en ik denk niet dat die variant een kans maakt. –Frank Geerlings (overleg) 23 mrt 2022 23:43 (CET)

Heb je aanwijzingen dat er problemen zijn met spraak-software? Wickey (overleg) 24 mrt 2022 12:49 (CET)

Ik ben hier klaar mee, Wickey. –Frank Geerlings (overleg) 24 mrt 2022 13:30 (CET)

@Effeietsanders: 'Een rustiger beeld' vind ik maar een matig argument. Als ik naar een willekeurig voorbeeld kijk vind ik dat nogal meevallen (en waarom maar bij maar één bron "bewust" 'nl' toegevoegd en bij alle andere niet?). En als je in het sjabloon vastlegt dat het altijd achteraan wordt geplaatst is dat helemaal opgelost. Het nut van "onder water" registreren, whatever it may be, ontgaat mij. Of WP populair is onder mensen die alleen Nederlands kunnen lezen en aan de titel niet kunnen zien of het anderstalig is en hoeveel dat er zijn weet ik niet. Wickey (overleg) 24 mrt 2022 12:49 (CET)

Ik ben prima bereid om hier nogmaals toe te lichten natuurlijk. Hopelijk helpt dat voor het wederzijdse inzicht. OK, laten we aardappel als voorbeeld nemen. dit is de versie die je linkte. De meeste niet-Nederlandstalige bronnen hadden geen taalvermelding. In zo'n situatie is het natuurlijk een beetje vreemd om alleen een paar vermeldingen van Nederlandse taal te zien. Daarnaast kun je er als lezer helemaal dus niet op vertrouwen dat geen vermelding gelijk betekent dat het Nederlandstalig is, integendeel.

Nu als je kijkt naar deze versie, hier heb ik de melding van anderstalige links wel gemaakt. Nu zijn er hier vrij veel Nederlandstalige bronnen, maar je kunt je voorstellen dat dit anders uitpakt bij een biografie over een Indiaas of Japans politicus. Dit beeld is wat 'onrustig' omdat ongeveer 50% wel die inspringing heeft.

Ter illustratie heb ik ook de vermelding voor Nederlandstalige bronnen toegevoegd hier. Zoals je kunt zien in de literatuur-sectie is de boel wat rustiger in zicht. Zeker geen allesoverheersend argument, maar weegt wat mij betreft in het voordeel van altijd vermelden.

Als je nog niet duidelijk is wat 'onder water' registreren betekent, hebben we een probleem, want dan praten we blijkbaar totaal langs elkaar heen in deze discussie: het is zo'n beetje de kern van dit overleg. Laat ik daar voor de zekerheid dus ook maar even op terugkomen. Onder water refereert aan de broncode van een artikel: we vermelden de taalcode wel in de broncode (als "taal=nl"), maar geven deze niet weer voor de lezer (die ziet alleen andere taalaanduidingen dan nl).

Hier zie ik drie grote voordelen aan: 1. als iemand het artikel leest via een vertaalmachine, dan weten ze ook gewoon in welke taal die bron gesteld is. Jij bent hier uiteraard niet de doelgroep voor. Hoewel een minderheid, zijn er toch nog aardig wat bezoekers van de Nederlandstalige Wikipedia van buiten het Nederlands taalgebied, dus ik vermoed dat het zelfs nu al gebeurt. Ik weet niet hoe het met jou zit, maar ik raadpleeg geregeld Wikipedia's waarvan ik de taal niet zelf beheers. 2. als iemand het artikel wil vertalen, kan de taalcode eenvoudiger worden 'meegenomen' via vertaaltools. Die kan dan referentie-sjablonen matchen, en op de Engelstalige Wikipedia bijvoorbeeld gelijk weergeven dat de bron Nederlandstalig is. Hiervoor is alleen de informatie in de brontekst nodig, niet in de weergegeven tekst. 3. Wanneer we het in de brontekst bijhouden, is het eenvoudiger om er bovenop te bouwen met css-scripts enz zodat anderen de taal wel kunnen weergeven, wanneer zij er behoefte aan hebben.

Je hoeft het natuurlijk niet eens te zijn met de argumenten, maar het zou fijn zijn als we in ieder geval begrijpen van elkaar waarom we een standpunt hebben. -- Effeietsanders (overleg) 24 mrt 2022 17:46 (CET)

Ik denk dat 'rustiger beeld' niet zozeer een 'matig argument' zou zijn, maar dat het vooral subjectief is, per persoon zal dat dus verschillen. En met mijn vormgevingachtergrond kan ik er absoluut ook een stuk in meegaan (evenals in andere argumenten voor 'altijd' trouwens). Maar zelfs als we de taalaanduidingen in monospace zouden weergeven, én als de terugverwijzingen van meermaals gebruikte referenties (die ^{a b c} etc.) niet in de weg zouden zitten, voegt een rustiger beeld puur om het rustiger beeld naar mijn mening niet heel veel toe. Wat ik bij de keuze voor 'altijd' (bedankt voor het maken van het vergelijkingsmateriaal!) vooral ervaar – en dat kan eveneens subjectief zijn – is dat ik bij elke referentie weer die extra informatie te verwerken krijg. Juist doordát er altijd een taalaanduiding staat, kost het me meer moeite om snel te kunnen bepalen welke taal de betreffende webpagina heeft. Plus dat, de hele lijst aanschouwend, de taalaanduidingen dusdanig een eentonige brij vormen, dat én de Nederlandstalige links minder benadrukt worden, én de anderstalige aanduidingen minder opvallen.

Dit maakt dat ik veel meer naar 'nooit' neig. En als we daarnaast ook nog een beetje alle neuzen dezelfde kant op krijgen, kunnen we streven naar projectbrede duidelijkheid "geen aanduiding = Nederlandstalig, wel een aanduiding = anderstalig", waarmee de noodzaak voor soms-toch-(nl) weg zou vallen (en er geen extra parameter nodig is). Wat ik onder het subkopje #(nl) nooit tonen? ook wel probeerde duidelijk te maken, maar daar misschien wat vertroebeld raakte door wat frustratie en cynisme mijnerzijds (excuses daarvoor).

Met vriendelijke groeten — Mar(c). ^[overleg] 24 mrt 2022 21:40 (CET)

Ik zat vanavond trouwens te broeden op een drastisch andere aanpak, mede geïnspireerd door het tweede deel van je verhaal. Ik moet het even op een wat helderder moment verder uitbroeden. Hopelijk morgen. — Mar(c). ^[overleg] 25 mrt 2022 00:13 (CET)

@Effeietsanders:

Interessant dat onze artikelen vooral in de VS en in Rusland zo populair zijn.

Het verband tussen vertaalmachine en taalvermelding in de refs ontgaat mij. Ik mag aannemen dat deze dit gewoon in de header van de brontekst van de pagina leest.

Het aanmaken van een artikel via de vertaaltool is een garantie voor een slecht artikel, vooral als refs klakkeloos worden meegenomen/meevertaald.

Je derde punt heeft rechtstreeks te maken met de wenselijkheid überhaupt.

Verder kan ik alleen maar Mar(c)'s argumenten bevestigen: overbodige info is belastend/afleidend; niet-nl-refs vallen niet meer op. Ik denk dat je de waarde van de taalaanduiding sterk overschat. Voor de meesten zal het helemaal niets toevoegen en meestal zie je toch in één oogopslag om wat voor taal het gaat. Wickey (overleg) 25 mrt 2022 12:46 (CET)

@Marc: Als het uitvoerbaar zou zijn, zou ik ook prima kunnen leven met nooit weergeven. Voorwaarde is dan dus wel dat we met een uitvoerbare variant komen die te onderhouden is. Zoals bij het aardappel-voorbeeld duidelijk is, kun je er eigenlijk op dit moment totaal niet vanuit gaan dat niet-weergegeven taalinformatie betekent dat het Nederlandstalig is. Je bent als lezer dus ook in de huidige situatie ertoe overgeleverd om op basis van de titel te gokken of jij iets kunt met die bron voor nader onderzoek. Ik denk dat de kern van de subjectiviteit zich erin bevindt of je het idee hebt dat taalinformatie iets toevoegt, of dat je het maar op basis van een titel moet kunnen gokken.

@Wickey: Als iemand een vertaalmachine gebruikt, kan dat dus prima betekenen dat die persoon helemaal niet doorheeft op welke taalversie het artikel zich bevindt. Dan is die context "oh, er is geen vermelding dus het zal wel Nederlandstalig zijn" natuurlijk ook verdwenen.

(over het wel registreren, niet weergeven:) Voor wat betreft vertalen van artikelen: dat hoeft natuurlijk niet klakkeloos zijn. Maar waarom zou je informatie actief gaan weggooien (dit kost moeite) als dat leidt tot extra kliks bij collega's later wanneer zij het artikel vertalen, en die taal dan weer handmatig moeten toevoegen? Ik laat het oordeel over hoe tot een goed kwalitatief artikel te komen graag aan de vertaler en ontvangende gemeenschap - maar gestructureerde informatie in plaats van impliciete informatie kan dat proces alleen maar eenvoudiger maken. Wanneer gestructureerde informatie beschikbaar is, kun je daar makkelijker tools op bouwen zoals een script zoals CiteUnseen dat een context voor de betrouwbaarheid van de bron weergeeft. Maar ook dat kun je natuurlijk 'gokken' op basis van de titel. -- Effeietsanders (overleg) 25 mrt 2022 16:53 (CET)

Wat we tot nu toe lijken te vergeten is dat er mensen zijn die Wikipedia 'lezen' via spraaksoftware. Of die software daadwerkelijk toekomt aan het notenapparaat, weet ik niet. Maar als spraaksoftware zich moet buigen over de titels van gebruikte bronnen, dan zal die software heel blij zijn met adviezen over de taal. De betreffende gebruiker is dat ook, als hij hoort dat de software zich correct door de taalwarboel worstelt. Of die software naar de code achter de pagina kijkt, ik vrees dat die hard kijkt naar de zichtbare delen.

Van mij persoonlijk (niet afhankelijk van dergelijke hulpmiddelen, hoeven de aanduidingen van de Nederlandse taal er niet voor. Tenzij... er een artikel is met veel bronnen en 70, 80% of meer daarvan wel een taalaanduiding heeft. Dan is het rustiger als alle bronnen dat hebben. Met vriendelijke groeten, RonnieV (overleg) 25 mrt 2022 17:02 (CET)

@Effeietsanders: Ik had het m.b.t. subjectiviteit puur over de presentatie, oftewel zorgt 'een taalaanduiding bij élke bron/referentie' voor een rustiger/duidelijker beeld, en zorgt aan de andere kant 'alleen bij de anderstalige bronnen/referenties een taalaanduiding' voor een rustiger verwerking van de geboden informatie – ik denk dat dat allebei subjectief is. Dat "op basis van een titel moeten kunnen gokken" komt absoluut niet in mijn argumentatie voor. Dat we op dit moment totaal niet kunnen uitgaan van "geen aanduiding = Nederlandstalig" is evident; dat is het gevolg van jarenlang geen eenduidig beleid (en het 'soms' toestaan in mogelijk subjectieve uitzonderingsgevallen). Maar is dat dan tegelijkertijd een reden om daar niets aan proberen te veranderen? Of we in dat kringetje willen blijven ronddraaien, of dat we de koers nu veranderen en mogelijk over een jaar dichtbij zo'n duidelijke "geen aanduiding = Nederlandstalig"-situatie geraken, dat is de wezenlijke vraag die nu voorligt. En de drastisch andere aanpak die goed mogelijk lijkt te zijn, verenigt beide zichtpunten, maar vergt tevens dat juist zo veel mogelijk taalparameters worden ingevuld om naar zulke duidelijkheid toe te werken. Ik broed nog even op wat details rond die aanpak.

@RonnieV: Eens over die spraaksoftware; enige kanttekening in dit verhaal is dat de taalparameter er is om de taal van de externe webpagina aan te geven, niet de taal van de titel van die webpagina. En juist een argument voor het (soms) tonen van (nl) via de taalparameter, is dat de titel van een Nederlandstalige webpagina juist anderstalig is. Met een aparte parameter alla "titeltaal" zouden we ervoor kunnen zorgen dat de spraaksoftware de titel goed uitspreekt; fictief voorbeeld: {{Citeer web|url=...|titel=Un bon vin blanc|werk=de Volkskrant|taal=nl|titeltaal=fr}}. Maar dat valt helemaal buiten deze discussie, en kan totaal onafhankelijk hiervan geïmplementeerd worden.

Met vriendelijke groeten — Mar(c). ^[overleg] 25 mrt 2022 17:36 (CET)

Spraaksoftware lijkt mij typisch een gelegenheidsargument. Zijn er daadwerkelijk problemen bekend en zijn die zodanig groot dat dit een speciale regeling rechtvaardigt? Hetzelfde geldt voor hypothetische problemen met de vertaalmachine (ik neem aan dat we het dan hebben over Google Translate & Co). Ik geef nog even aan waarom de taal nooit vermeld hoeft te worden:

• Bijna altijd is aan de hand van titel en/of naam van de bron (bv. Washington Post) op te maken in welke taal deze is geschreven. Dit geldt met name ook voor vertaalmachines. Die kunnen automatisch de taal detecteren aan de hand van de originele tekst. Met de referenties kunnen ze sowieso niet goed omgaan; anderstalige titels, namen en auteurs moeten helemaal niet vertaald worden.
• Meestal is uit de context van het artikel al op te maken naar wat voor bron de noot verwijst.
• Wanneer iemand echt geïnteresseerd is in de bron, zal hij heus wel zien wat voor bron het is.
• Waarop is de veronderstelling gebaseerd dat de vermelding in een brede behoefte voorziet?
• Een parameter in het sjabloon lost helemaal niets op. Bij links kan onafhankelijk daarvan wel of niet de taal worden aangegeven.
• De kans dat iemand per ongeluk op een bron klikt die hij niet kan lezen is statistisch zo klein, dat we hiervoor niet onze software aan hoeven aan te passen. Wickey (overleg) 26 mrt 2022 12:13 (CET)

Ter verduidelijking: mijn argument is niet dat de vertaalmachine beter functioneert wanneer de taal wordt weergegeven. Was dat maar zo! Vertaalmachines die op dit moment opereren, gebruiken de html en onze weergave is dusdanig niet-standaard, dat ik niet verwacht dat die in de werking wordt meegenomen. Echter, voor de hypothetische (of minder hypothetische, zie de link hierboven?) Russische lezer is het bijzonder relevant om te weten dat een bron Nederlandstalig is, omdat zij die taal niet beheersen. Omdat de titel van de bron ook wordt vertaald, lijkt de titel dus Russisch te zijn voor ze. Dat zou dus een argument voor altijd weergeven zijn (minder voor opnemen maar niet weergeven). Dat er waarschijnlijk voldoende gebruikers zijn in een dergelijke positie, heb ik volgens mij al beargumenteerd.

De vraag die ik vooral heb bij registreren maar niet weergeven: waarom zouden we dit niet doen? Waarom zou je registreren van de taal willen verbieden, wat is daar het voordeel van precies? Er zijn voldoende argumenten voor (onderhoud, technische ontwikkelingen, vertalingen), en ik zie niet echt sterke argumenten tegen behalve "ik ben niet overtuigd door de argumenten voor". Dan kun je het altijd nog hebben over de implementatie natuurlijk. -- Effeietsanders (overleg) 26 mrt 2022 17:08 (CET)

Wickey, uit "Spraaksoftware lijkt mij typisch een gelegenheidsargument" (en eerder werd door Wikiwerner het argument van meta-informatie al 'gezocht' genoemd) krijg ik het gevoel dat je niet doorhebt wat het initiële probleem is, namelijk dat er jarenlang, vanwege het invoegen van taal=nl door de Visual Editor, nabewerkingen nodig zijn geweest omdat de veelvuldige vermelding van de taalaanduiding (nl) niet binnen de huidige beleid past. Dus óf het beleid moet totaal om – d.w.z. élke link naar een externe webpagina, zowel Nederlands- als anderstalig, mag (en om het geen rommeltje te laten worden: moet) een taalaanduiding krijgen – óf we moeten ergens in de sjablonen en/of software iets (laten) aanpassen. Dus onafhankelijk van meta-informatie, spraaksoftware, etc. dient er iets te gebeuren. Meta-informatie en spraaksoftware komen pas om de hoek kijken als argumenten hoe we dit gaan aanpakken. Dit wilde ik nog even benadrukken. Met vriendelijke groeten — Mar(c). ^[overleg] 27 mrt 2022 08:40 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Die uitleg is niet overbodig. Aan het begin van dit item staat dit probleem als vijfde punt vermeld. Zoals uit het verloop van de discussie ook blijkt, zal toch eerst de vraag moeten worden beantwoord over de wenselijkheid van vermelden überhaupt. Pas daarna komt de technische keuze voor een van de 3 opties. Precies andersom dus. Dat altijd tonen moet om het geen rommeltje te laten worden, daar ben ik het alvast niet mee eens.

Overigens is de VE de kern van het software-probleem. Zonder twijfel ook de oorzaak van het slechte functioneren van de reply-tool. Wickey (overleg) 27 mrt 2022 14:25 (CEST)

Oké, ik probeer het nog een keer in andere woorden, want je trekt mijn opmerking over 'rommeltje' wel erg uit z'n context: Als we technisch nérgens iets aanpassen of laten aanpassen (aan sjablonen, VE, etc.), dan blijven we continu met nabewerkingen zitten (namelijk de taal=nl die VE blijft invoegen bij nieuwe referenties, telkens verwijderen) – tenzij we het beleid van "nooit/zelden de taalaanduiding (nl) plaatsen" loslaten, en dan zitten we dus met een beleid "wél altijd de taalaanduiding (nl) plaatsen" om te voorkomen dat het een rommeltje (de ene Nederlandse link wel de taalaanduiding (nl) en de andere Nederlandse link weer niet) wordt. Binnen dat gewijzigde beleid had ik het over 'moet'.

Als je mijn reacties gelezen hebt, m.n. 25 mrt 2022 00:13 en 25 mrt 2022 17:36, dan weet je dat ik aan een andere aanpak zit te denken. Wellicht werpt die wat ander licht op de hele kwestie, inclusief de vraag die jij vindt dat die eerst beantwoord zou moeten worden. (En uit je laatste opmerking krijg ik de indruk dat je geen benul hebt waar je het over hebt; als je over de reply-tool iets aan te merken hebt, graag ergens anders.)

Met vriendelijke groeten — Mar(c). ^[overleg] 27 mrt 2022 15:08 (CEST)

Wow...

Deze overlegpagina staat niet op mijn volglijst, maar nu ik naar aanleiding van de oproep op WP:OG weer even kom kijken, ben ik verbluft over de bijna 50 kB ruim 60 kB die hier intussen is bijgepend. Hoe dan ook: mijn voorkeur gaat uit naar de oplossing die vanuit de ogen van de lezer het beste bijdraagt aan het niet tonen van nl's waar dat niet nodig is en het wel tonen van nl's waar dat zinvol is. Hoe die oplossing geïmplementeerd moet worden laat ik graag over aan de collegae die deze in elkaar kunnen programmeren. Wutsje 24 mrt 2022 14:12 (CET) 25 mrt 2022 23:24 (CET)

Bezochtdatum niet nodig bij dode url

Als een bron-url niet langer beschikbaar is, voeg je 'dode url=ja' toe, en het liefst ook een archief-url met bijbehorende archief-datum. De archief-url komt daarmee niet in plaats van de originele url, maar wordt er aan toegevoegd. Daarmee is de datum waarop de (originele) url voor het laatst bezocht is ook niet langer relevant, want die pagina is niet langer beschikbaar. De originele webpagina is wel beschikbaar via de archief-url op de genoemde archief-datum. De parameter archief-datum komt in dat geval in plaats van de parameter bezochtdatum. Klopt dat? Zo ja, dan kunnen we het toevoegen op de pagina bij 'archief-datum' en bij 'bezochtdatum. Zie ook Wikipedia:Redactielokaal#Geraadpleegd op .... Laurier (overleg) 13 jul 2022 12:21 (CEST)

De versie die op de archiefdatum is aangetroffen, is gearchiveerd. Die versie zal vast onveranderd blijven. Maar of de versie die op de archiefdatum is aangetroffen identiek was aan de versie die op de bezochtdatum is gezien, blijft koffiedik kijken. Alleen als de archiefdatum gelijk is aan de bezochtdatum, weet je dat. Is de archiefdatum later, of eerder, dan weet je dat niet zeker.

Stel dat ik op basis van dit NRC-artikel, in de versie van 11 juli, had geschreven dat er ruim 1000 F1-coureurs zijn geweest. Dan heb ik dat niet geverifieerd noch gefalsifieerd, maar heb ik wel gebruik gemaakt van een bepaalde bron. Daags daarna (12 juli) is het artikel aangepast, en sindsdien staat er meer dan zevenhonderd F1-coureurs. Wordt dat artikel vandaag (13 juli) gearchiveerd en besluiten we ergens in 2032 om de archief-url te activeren, dan sluit een en ander niet bij elkaar aan. Het zou kunnen dat Delpher dan ook de versie van 11 juli alsnog ophoest, want dat was de papieren krant die toen is uitgegeven.

Je hebt dan de NRC-versie van 11 juli, waarschijnlijk de Delpher-versie van 11 juli, de NRC-web-versie van 12 juli en de archiefversie van 13 juli. Je kan niet zonder meer de archiefversie gebruiken in plaats van de originele versie. Met vriendelijke groet, RonnieV (overleg) 13 jul 2022 15:15 (CEST)

Mee eens met RonnieV, het is goed om de bezochtdatum te behouden zolang deze ongelijk is aan de archiefdatum. Overigens lijken de meeste botmatige toevoegingen te kiezen voor een archiefversie zo dicht mogelijk bij de bezochtdatum mits die gegeven is. Dajasj (overleg) 13 jul 2022 15:55 (CEST)

Ja, daar ben ik het denk ik wel mee eens. Zullen we nog even wachten wat anderen zeggen, en dan de 'uitslag' expliciet in de beschrijvingspagina van dit sjabloon vermelden? PS: op de Engelstalige pagina over dit sjabloon staat bij access-date: "Full date when the content pointed to by url was last verified to support the text in the article; do not wikilink; requires url; use the same format as other access and archive dates in the citations. Not required for linked documents that do not change." Volgens mij verandert de gearchiveerde versie in principe niet meer. Laurier (overleg) 13 jul 2022 16:07 (CEST)

Nee klopt, de gearchiveerde versie verandert niet meer, maar de gearchiveerde versie hoeft ook niet per se de versie te zijn die bezocht is voor het artikel. Vandaar dat ik bezochtdatum altijd wel zou vermelden. Of begrijp ik je dan verkeerd? Dajasj (overleg) 13 jul 2022 16:22 (CEST)

Volgens mij begrijp je me goed. Je hebt gelijk dat de gearchiveerde versie niet per se de versie hoeft te zijn die bezocht is voor het artikel, maar in dat geval zou de editor die de gearchiveerde versie toevoegt in principe moeten controleren of de feiten die worden ondersteund door die bron ook inderdaad in de gearchiveerde versie voorkomen. Als dat niet zo is zou ik denken dat de feiten niet meer vermeld moeten worden op de Wiki-pagina...! De bezochtdatum van de oorspronkelijke url is dan toch niet meer relevant, vind ik. Laurier (overleg) 13 jul 2022 17:40 (CEST)

Laurier, dit vind ik twee gevaarlijke stellingen bij elkaar. Ja, degene die de archiefpagina toevoegt zou zich hiervan moeten vergewissen. Maar voor een deel gebeurt het vinden van archiefpagina's geautomatiseerd. Ik zou er niet op durven vertrouwen dat alle archieflinks daadwerkelijk verwijzen naar de inhoud van de pagina op het moment dat daar informatie aan ontleend is. Maar nu het tweede: stel ik heb goede informatie ontleend aan een bepaalde versie van een pagina. Dat domein wordt tien jaar later gekaapt en er staan nu allerlei niet-gerelateerde zaken. Een archiefbot vindt nu pas deze pagina's en gaat deze braaf archiveren. In de archiefversie van de (tien jaar geleden) door mij gebruikte pagina staat nu dus niet wat ik er toen aan ontleend heb. Volgens jou zouden de door mij geplaatste feiten nu zonder meer uit het artikel verwijderd moeten worden. De oorspronkelijke link bevatte de vermelde informatie, de archieflink bevat heel andere informatie en mijn informatie is wel eenvoudig te staven met twintig andere sites (en inmiddels ook wat boeken). Ben je nog steeds voor verwijdering? Met vriendelijke groeten, RonnieV (overleg) 13 jul 2022 18:13 (CEST)

Dat is een heel goeie toevoeging, de bot-toevoegingen van archieflinks. Daar had ik tot mijn schaamte nog niet bij stilgestaan. In dat geval is het wel het beste als de oorspronkelijke bezochtdatum blijft staan, vind ik. En wat kunnen we het beste doen als men direct een archieflink toevoegt, dus niet pas later? Voorbeeld: iemand plaatst een nieuw stukje tekst op een pagina met als referentie een link naar een site die al niet meer live is, dus direct met 'url=...' én 'archief-url=...'. Zou in dat geval de bezochtdatum ook nuttig zijn? Laurier (overleg) 15 jul 2022 13:09 (CEST)

In mijn ogen kan dat nooit kwaad. Ook al is het maar om later te weten te komen wanneer de bron is toegevoegd aan het artikel, om wat voor reden dan ook. Bijvoorbeeld om erachter te komen wie de bron toevoegde om diegene iets te kunnen vragen. Ennomien (overleg) 15 jul 2022 13:16 (CEST)

In dit geval ligt de bezoekdatum dus ná de archiefdatum. De archiefurl en archiefdatum zijn dan het meest relevant, dat is de informatie die gebruikt is. De oorspronkelijke URL, waar het archief een kopie van heeft gemaakt, is dat minder, feitelijk is die pagina niet bezocht. En de bezoekdatum... Misschien inderdaad voor de doeleinden die Ennomien aangeeft (maar daarvoor is het ook in de paginahistorie terug te vinden, al zou er in ieder geval in theorie een aantal dagen, weken tussen kunnen zitten, bijvoorbeeld als iemand een stuk toevoeging voorbereid in de eigen naamruimte). Ik zie de kopie in het archief min of meer als een boek. Of ik nu vorig jaar, gisteren of over tien jaar iets opzoek in een boek dat in 2005 is uitgegeven, de verwachting is dat er altijd hetzelfde staat op pagina 25. Die gearchiveerde webpagina zou ook niet meer mogen veranderen (want een kopie). Met vriendelijke groet, RonnieV (overleg) 15 jul 2022 13:27 (CEST)