Overleg sjabloon:Largethumb

verbod op vastgelegde grootte's

Op een aantal wiki's is het nu verboden om vaste grootte's in te stellen, zoals largethumb. Is dat iet's om hier op nl.wiki over na te denken? Ik denk bijvoorbeeld aan de mobiele systemen zoals een mobele telefoon of een pad, waar een foto in de grootte van 261px moeilijk te handteren is, laat staan als het om breede foto's gaat die soms op 600px of zelfs 800px worden vastgezet in artikelen. Op de Deense wiki is het vastzetten van de grootte nu ook verboden, dus graag een reactie hierover. --Met vriendelijke groeten, Ro de Jong op (Samråd) 6 sep 2011 16:10 (CEST)

Zie dit overleg (da) --Met vriendelijke groeten, Ro de Jong op (Samråd) 6 sep 2011 16:12 (CEST)

Alle Wiki's bepalen hun eigen regels volgens mij. Voor mij persoonlijk is het een non-discussie, ik heb op mijn mobiele apparaat geen enkele moeite om de mobiele versies van pagina's te lezen. JZ85_overleg 6 sep 2011 16:13 (CEST)

Als je alleen thumb -dus zonder aantal px- gebruikt wordt de afbeelding weergegeven op de grootte zoals je die zelf hebt ingesteld bij je voorkeuren. Mexicano _(overleg) 6 sep 2011 16:14 (CEST)

Er zijn drie groottes mogelijk: de thumb-grootte, de largethumb-grootte en de op het artikel zelf ingestelde grootte. Als het gaat om een eventuele depreciatie van ingestelde groottes gaat het hoofdzakelijk om afbeeldingen waarvan handmatig op artikelen de grootte bepaald is. Largethumb hebben we op nl-wiki ingesteld zodat een afbeelding gelijk uitgelijnd met de infobox op een artikel. Voor ander gebruik dan dat is de largethumb eigenlijk niet bedoeld. In principe is de stelling dat largethumb bedoeld is voor het gelijk uitlijnen met een infobox, en dat alle andere afbeeldingen gebruik maken van thumb zonder handmatig opgegeven, maar voor een echte vaststelling daarvan als staand beleid is zover ik weet geen consensus gezocht (en is minstens melding op WP:OG nodig). Met thumb wordt het gebruikers met slechte ogen bijvoorbeeld de vrijheid gegeven de grootte van afbeeldingen groter te maken. Groetjes - Romaine (overleg) 6 sep 2011 16:18 (CEST)

Ik ben me bewust van de verschillen, en de werking van dit sjabloon. Het leek me een goede plaats om het hier even te peilen. Op de Deense wikipedia werd dit sjabloon namelijk verwijderd, omdat het een vaste grootte heeft. Het blijkt dat dit verbod op meerdere wiki's geld, en vroeg me af, of hier ook een peiling voor gestart moest worden. Zeker als het gaat om in artikelen een grootte in te stellen van bijvoorbeeld 300px of 250px wat heel veel gebeurt. Sommig mobieltjes kunnen dit best aan, vast wel, mar er zijn blijkbaar nog een heleboel mobiele eenheden die dit niet aan kunnen. Zoals Mexicano aangeeft, is dat ook de veelvuldige opmerking bij de tegenstemmers. Ze willen zelf de grootte van de plaatjes instellen via de voorkeuren. Zolang wij al die groottes zelf blijven instellen in artikelen met XXXpx ontneem je de lezer die mogelijkheid. Largethumb, voor het uitlijnen, lijkt mij prima, maar ik kan het verbod op XXXpx wel voorstellen, en zou dat hier eigenlijk ook wel toejuichen.--Met vriendelijke groeten, Ro de Jong op (Samråd) 6 sep 2011 17:13 (CEST)

Ik ben altijd tegen het standaardiseren van de grootte van afbeeldingen geweest, om de volgende redenen:

• De huidige default is veel te klein voor de beeldschermen die gebruikt worden in het Nederlands taalgebied. Voor de Engelse Wikipedia, die voor lezers van over de hele wereld geschreven is, begrijp ik nog wel dat men voor postzegelverzamelingen kiest, maar voor ons is zoiets geen service voor de lezer. Hetzelfde geldt trouwens bij de standaardgrootte in galleries.
• De standaardisatie maakt alle afbeeldingen even groot qua breedte, maar niet qua oppervlakte. Het netst wordt over het algemeen een opmaak geacht die zo min mogelijk verschillende lijnen aanhoudt. N.m.m. is dit een opmaak waarbij minstens twee verschillende groottes gebruikt worden, een voor in de lengte en een voor in de breedte georiënteerde afbeeldingen. Dat is onder de huidige omstandigheden onmogelijk als je geen pixelbreedte instelt.

Zodra aan beide punten technisch tegemoet gekomen kan worden, zou ik geen bezwaar meer hebben tegen het afraden van pixelbreedtes. Woudloper _overleg 6 sep 2011 17:44 (CEST)

Problems with Parsoid

Would be great if something could be done on this template to get it working with Parsoid/VE https://bugzilla.wikimedia.org/show_bug.cgi?id=54803#c5 Kelson (overleg) 6 dec 2013 20:42 (CET)

Largethumb: een klein plaatje

Aangezien mijn wijziging blijkbaar op weerstand botst, geef ik bij deze gehoor aan de oproep tot overleg.

Ten eerste dit: uiteraard is het niet nodig dat dit sjabloon gewijzigd wordt. Het is ook mogelijk een nieuw sjabloon aan te maken dat in een grotere pixelbreedte voorziet. Als men de afbeeldingen in de artikelen die het sjabloon nu gebruiken liever zo laat, dan is de laatste optie laatste wellicht beter.

Motivatie

Ten tweede mijn motivatie (ik wijzigde niet zonder de zaak overdacht te hebben). Afbeeldingen zijn dragers van informatie. De hoeveelheid informatie verschilt natuurlijk per afbeelding - je zou dat de informatiedichtheid kunnen noemen. Afbeeldingen die geen tekst bevatten en een duidelijk hoofdobject hebben (bv. de eerste afbeelding in het artikel roodborst) hebben een relatief lage informatiedichtheid. Afbeeldingen die geen duidelijk hoofdobject hebben en veel tekst bevatten (bv. kaarten) hebben een hoge informatiedichtheid. Een afbeelding met een gemiddelde informatiedichtheid bevat misschien enkele woorden en niet meer dan een paar objecten.

Mijns inziens geldt voor een afbeelding hetzelfde als voor andere informatiedragers in artikelen: deze dient in een oogopslag te bevatten te zijn. Doorklikken is voor de echt geïnteresseerde lezer: de afbeelding heeft primair de functie te informeren. Wat dat in theorie betekent is dat een afbeelding met een gemiddelde informatiedichtheid, indien deze tekst bevat, ongeveer dezelfde puntgrootte heeft, maar zeker niet minder dan de helft, als de puntgrootte in de tekst.

Verder ga ik uit van een gemiddelde schermgrootte, dat is ongeveer 13 of 14 inch. Zelf gebruik ik op het werk een 13 inch beeldscherm, maar ik heb ook een 8 inch tabloidachtig apparaat waarmee ik nog wel eens bewerk.

Ik kom dan uit op een grootte van ongeveer 300px voor een horizontaal gepositioneerde afbeelding met een gemiddelde informatiedichtheid, om dezelfde puntgrootte te bewerkstelligen als in de tekst. Een groter dan gemiddelde afbeelding zou dan rond de 350 px dienen te hebben; een kleiner dan gemiddelde afbeelding rond de 250 px. Bij een vertikaal gepositioneerde afbeelding is dat ongeveer 80 pixels minder (d.w.z. respectievelijk 270, 220 en 170 px). Uiteraard zijn er nog zaken die daar van afwijken, zoals panorama's (groter) of logo's (kleiner), maar laten we die even buiten beschouwing.

Conclusie

Als we uit de naam van dit sjabloon mogen afleiden dat het bedoeld is voor grote afbeeldingen (d.w.z. afbeeldingen met een relatief grote informatiedichtheid), dan is de afbeeldingsgrootte die op het moment in dit sjabloon staat te klein voor horizontaal geschikte afbeeldingen. Aangezien ik een gebruiker massaal pixelgroottes zag wijzigen in dit sjabloon, stuit ik op het probleem dat veel afbeeldingen te klein gemaakt worden (of in de toekomst kunnen worden gemaakt). Hoe we dat oplossen is me om het even, maar vanwege de naam die dit sjabloon draagt leek me het wijzigen ervan geen vreemde ingeving.

Vr. groeten, Woudloper _overleg 23 jan 2014 15:12 (CET)

Volgens mij slaat de naam {Largethumb} op het feit dat de grootte 130% van de standaard-thumbnail van 200 pixels is. Dit sjablonen is vooral in gebruik om afbeeldingen mooi op infoboxen te laten aansluiten aangezien die 270 pixels in beslag nemen, wat evenveel is als de 260px + border van een Largethumb-afbeelding. Mijn bezwaar is vooral dat Largethumb nu de infoboxbreedte van 260/270 pixels gebruikt en ook op die manier in gebruik is en dat je dat dan niet zomaar kan veranderen. Misschien kan 260px|thumb hernoemd worden in {{Infoboxthumb}} of iets van die strekking als je denkt dat dat beter aansluit bij de betekenis. - FakirNL_overleg 23 jan 2014 16:19 (CET)

Dat van de grootte van infoboxafbeeldingen had ik niet bij stil gestaan - je terugdraaiing was terecht.

Inderdaad lijkt me "infoboxthumb" een betere naam dan "largethumb", maar moeten dan alle afbeeldingen in infoboxen aangepast worden aan de nieuwe naam? Dat zou een botopdracht worden.

Dat men 200px als standaard beschouwt wist ik niet. Wellicht een overblijfsel uit 2002, toen Wikipedia van start ging en de gemiddelde beeldschermgrootte nog een stuk kleiner was dan nu(?) Uitgaande van bovenstaande overwegingen zou ik 200px alleen nog voor verticaal georiënteerde afbeeldingen of logo's, handtekeningen e.d. gebruiken. Woudloper _overleg 23 jan 2014 16:35 (CET)

De naam veranderen lijkt mij totaal niet aan de orde, aangezien deze naam redelijk ingeburgerd is. Een nieuw sjabloon is misschien wel een idee, maar eerst kijken via bijvoorbeeld een peiling of daar vraag naar is. Ik heb verhalen gelezen dat we juist het forceren van afbeeldingsbreedte willen voorkomen, omdat de persoonlijke miniatuurbreedte genegeerd wordt. Sjoerd de Bruin (overleg) 23 jan 2014 17:47 (CET)

"maar moeten dan alle afbeeldingen in infoboxen", het gaat niet om afbeelding IN infoboxen, maar die er mooi onder aansluiten, zoals op Elizabeth Bowes-Lyon (om maar eens een artikel te noemen). - FakirNL_overleg 23 jan 2014 18:46 (CET)

Misschien is het wel een idee om in plaats van één instelbare file-size naar twee of drie over te gaan (zodat iedereen nog meer vrijheid heeft), maar daar zal dan eerst wat breder over moeten worden gediscussieerd. - FakirNL_overleg 23 jan 2014 18:47 (CET)

Ik heb dit sjabloon al eens zonder succes ter verwijdering genomineerd. Ik vind dat afbeeldingen altijd de standaardgrootte moeten volgen, die ook door de gebruiker in te stellen is. Slechts bij hoge uitzondering afwijken, en niet omdat de uitlijning "lelijk" is, maar slechts omdat de informatie dan beter overkomt. — Zanaq (?) 23 jan 2014 19:08 (CET)

Probleem in de visuele tekstverwerker

Images: Handle templated image options containing pipes is Phabricator (voorheen bugzilla ticket) phab:T51400. De ontwikkelaars zoeken naar manieren om dit werkend te krijgen in de visuele tekstverwerker. Ad Huikeshoven (overleg) 14 nov 2015 11:16 (CET)