Overleg sjabloon:Citeer web

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

Parameter 'Taal' in Sjabloon:Citeer boek[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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?[bron bewerken]

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)

Mag de pagina-aanduiding weer weg?[bron bewerken]

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 Uitgevoerd Teruggezet. Was een ietwat ondoordachte actie van RonnieV. –bdijkstra (overleg) 5 jun 2019 09:47 (CEST)

Taallocalisatiecodes[bron bewerken]

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[bron bewerken]

@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 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[bron bewerken]

@Bdijkstra, Mbch331: Mijn voorstel zou zijn:

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 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[bron bewerken]

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[bron bewerken]

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[bron bewerken]

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)