Wikipedia:De kroeg/Archief/20121026

Afbeeldingen: de breedtes thumb en largethumb en meer

Hallo allemaal, Vanuit de MediaWiki-software, waar Wikipedia op draait, kun je verschillende parameters meegeven bij het plaatsen van bestanden. Zo kun je bepalen of een afbeelding gecentreerd, links of rechts komt te staan, een onderschrift heeft of niet, en meer. Ook vanuit het gebruik op Wikipedia hebben we al vele jaren bepaalde instellingen in sjabloonvorm aangemaakt met een specifiek doel.

Thumb

• Voorbeeld: [[Bestand:Afbeelding.jpg|thumb|Onderschrift]]

• Positie: bij gebruik thumb liever geen |right| gebruiken.
  Uitleg: Wanneer we onder een afbeelding een onderschrift willen tonen gebruiken we in principe thumb. Thumb zorgt er automatisch voor dat een afbeelding uitgelijnd wordt tegen de rechter kantlijn, tenzij je de parameters |left| of |center| gebruik om de afbeelding tegen de linker kantlijn of gecentreerd in het midden uit te lijnen. Omdat bij gebruik van thumb automatisch een afbeelding uitgelijnd wordt tegen de rechter kantlijn, is het zwaar overbodig om |right| te gebruiken en kan beter weggelaten worden, zodat er minder code gebruikt wordt.

• Grootte: bij gebruik thumb liever geen grootte opgeven.
  Uitleg: De grootte van een thumb is per default in de MediaWiki-software gedefinieerd en is gebaseerd op een gemiddeld beeldscherm van de bezoeker. Iedere bezoeker heeft weer een andere beeldschermbreedte en andere beeldscherminstellingen, zodat een artikel er op verschillende manieren uit kan zien afhankelijk van de bezoeker in kwestie. Dankzij de thumb kunnen gebruikers in hun voorkeuren (tweede tabblad: Uiterlijk) zelf een thumb-grootte opgeven. Dit kan handig zijn als je vindt dat de afbeeldingen op jou beeldscherm vaak te klein of te groot worden getoond. Deze functionaliteit is vooral ook heel erg handig voor slechtzienden die op deze manier Wikipedia toegankelijker voor zichzelf kunnen maken.
  Deze vrijheid om voor jezelf in te stellen hoe groot een thumb moet zijn wordt overruled (geblokkeerd) wanneer er een handmatige grootte wordt opgegeven. Daarmee wordt o.a. slechtzienden de mogelijkheid ontnomen de grootte zelf te bepalen en het ziet er bij andere beeldschermformaten en instellingen regelmatig erg lelijk uit. Het is dus zinloos te gaan uitzoeken welke bestandsgrootte het meest geschikt is voor een artikel, omdat een grootte op het ene beeldscherm er heel erg mooi uit kan zien, terwijl dat op een ander beeldscherm een erg lelijk effect geeft. Wikipedia wil informatie toegankelijk maken: gebruik dus liever alleen de grootte (px, upright) bij uitzonderingsgevallen, zoals een afbeelding die te korrelig is.

Largethumb

• Voorbeeld: [[Bestand:Afbeelding.jpg|{{Largethumb}}|Onderschrift]]
  Let op: gebruik sjabloonhaken!

• Uitlijning: gebruik om bestanden uit te lijnen op een infobox of een zijbalk |{{Largethumb}}|.
  In het verleden is er op de wiki een vaste breedte gezocht die het meest optimaal is voor de verschillende beeldschermen van gebruikers. Heel veel infoboxen en zijbalken hebben die breedte in gebruik, zodat ze onder elkaar met de rechter kantlijn en de linker kantlijn recht op elkaar uitlijnen. Voor afbeeldingen hebben we |{{Largethumb}}|, dat is een thumb die speciaal is afgestemd op de breedte van infoboxen en zijbalken, zodat de linker en rechter kantlijn van afbeeldingen gelijk loopt met die van de infoboxen en zijbalken. Deze largethumb maakt het mogelijk om bij eventuele wijzigingen in de MediaWiki-software de afbeeldingen ook in de toekomst gelijk te laten blijven uitlijnen met de infoboxen en zijbalken.

Largethumb is overigens uitsluitend en alleen bedoeld voor bestanden die buiten sjablonen worden geplaatst.

---

Samengevat zijn de aanbevelingen/uitgangspunten:

• gebruik |thumb| zonder |right| en zonder de grootte (px / upright), want een zorgvuldig uitgekozen afbeeldingbreedte voor de een, kan lelijk uitpakken voor de ander, waarbij bovendien de vrijheid van instellingen (o.a. voor slechtzienden) wordt ontnomen.
• gebruik |{{Largethumb}}| om bestanden te laten uitlijnen op infoboxen en zijbalken.

Thumb en largethumb zorgen tevens voor een netter uiterlijk en dat komt de leesbaarheid ten goede. Als iedereen hier een beetje rekening mee kan houden wordt de informatie meer en beter toegankelijker voor meer mensen. Dank! Groetjes - Romaine (overleg) 15 okt 2012 01:56 (CEST)

Allereerst vind ik het vreemd om |right| en |left| te gebruiken in plaats van |rechts| en |links|, want de Nederlandse termen werken net zo goed en zijn mijns inziens een stuk gebruiksvriendelijker (overigens kan volgens mij in plaats van 'thumb' ook 'miniatuur' gebruikt worden, maar dat vind ik een nogal onduidelijke aanduiding). Het is vanwege diezelfde gebruiksvriendelijkheid dat ik meestal wel degelijk |rechts| vermeldt bij een rechtsgeplaatste thumb, ook al is dat van de software niet nodig. Het lijkt me voor een nieuwe gebruiker begrijpelijker om meteen inzicht te krijgen in de mogelijke parameters, net zoals we niet ingevulde parameters in een infobox ook niet achterwege laten.

De parameter 'largethumb' probeer ik zoveel mogelijk te vermijden, omdat ik deze bijna alleen gebruikt zie worden om een enorme rits afbeeldingen onder een infobox te gooien. De positionering van de afbeelding ten opzichte van de tekst lijkt daarbij niet ter zake te doen en ik zie ook regelmatig de afbeeldingenreeks zover doorlopen dat er een wit gat ontstaat waar de tekst ophoudt.

Vriendelijke groet, 15 okt 2012 12:25 (CEST) – De voorgaande bijdrage werd geplaatst door Afhaalchinees (overleg · bijdragen)

Die extra witruimte (soms tientallen centimeters) gaat inderdaad van kwaad tot erger. Het komt waarschijnlijk omdat alleen gebruikers van IE (toch echter nog steeds de meerderheid van onze lezers) hier last van hebben. Bij Chrome en Firefox ontstaat er geen witruimte. Verder dienen plaatjes naar mijn smaak in de tekst en vooral binnen de paragrafen te worden geïntegreerd. Daarbij kan ook horen dat het ene plaatje groter dan het andere plaatje wordt getoond. Om die reden gebruik ik vaak het argument 200px, 250px of 300px bij een thumb. Dit is verre te prefereren boven een serie even grote, niet in de paragrafen geïntegreerde afbeeldingen onder de, in verhouding tot de inhoud van het artikel vaak veel te grote infobox. JRB (overleg)

Inderdaad, in geval van grote witte gaten is een gallery beter. Ik wist niet dat de Nederlandse woorden ook werken, maar dat is natuurlijk veel beter dan de Engelstalige aanduidingen. Dat er 'right' bij een thumb staat is niet nodig, maar hinderlijk is het ook niet, dus ik zou daar geen kruistocht tegen voeren.

Is er ook een manier om de grootte van de plaatjes in de infobox in te stellen? Ik vind vaak die grote portretten van 260px onaangenaam. Glatisant (overleg) 15 okt 2012 18:54 (CEST)

Helemaal mee eens. Vooral bij portretten waar de breedte/hoogte-verhouding naar hoogte doorslaat. Gelukkig is daar de parameter afbeeldingbreedte in een infobox voor. Zie de uitleg op {{Infobox persoon}}. Helaas werkt dit volgens mij niet op elke infobox (of ik doe iets niet goed ;)) --Meerdervoort (overleg) 15 okt 2012 21:17 (CEST)

@Afhaalchinees: Dat er Nederlandse versies beschikbaar zijn gekomen is nog niet zo heel erg lang, maar maakt mij niet zo veel uit. Al jaren worden de Engelstalige benamingen gebruikt voor de parameters en het is een beetje water na de wijn dat dat alsnog een vertaling heeft gekregen. Bij een miniatuur denk ik echt aan iets anders dan waarvoor we nu thumb gebruiken. Van eigen zit rechts ingesloten in thumb, het is dan dus dubbel, in sjabloon met parameters vul je ook niet dubbele parameters in of twee keer hetzelfde om maar één keer het resultaat te krijgen. Dat er in veel sjablonen genaamde parameters tonen is omdat we die in de toekomst ook graag ingevuld willen zien, terwijl we het juist op veel andere plekken weer weglaten. Ik heb de afgelopen dagen wat extra gelet op wat gebruikers hebben ingevuld en dat is me toch regelmatig een hele hatseflats aan code, die vaak niet werkt of een ander effect sorteert. Net als bij sjablonen denk ik dat we ook hier beter het KISS-principe kunnen aanhouden: hoe minder parameters en code waar dat kan, des te beter, want des te minder kan er in fout gaan en minder code is ook vaak begrijpelijker. Dat je bij het plaatsen van bestanden extra zaken gaat toevoegen lijkt me geen goed idee: daarvoor zijn codes niet bedoeld en maak je het er echt niet begrijpelijker op: waarom moet een gebruikers rechts plaatsen als die thumb het al rechts plaatst. Met meer code verliest een nieuwe gebruiker mijn inziens sneller het overzicht ten opzichte van kort en krachtig alleen datgene invoegen wat echt nodig is.

Ik zie regelmatig handmatig allerlei pixels gebruikt worden waardoor de uitlijning niet geschied zoals die bedoeld is. Dan is de largethumb zinvol. Largethumb is inderdaad voor de uitlijning afgestemd op infoboxen en zijbalken, maar als er niet uitgelijnd hoeft te worden kan gewoon thumb gebruikt worden. Groetjes - Romaine (overleg) 15 okt 2012 19:10 (CEST).

@JRB: Alinea's en plaatjes zijn zelden even groot, en op het ene beeldscherm is het ene plaatje even groot als de alinea terwijl juist op een ander beeldscherm het andere plaatje even hoog is als de alinea. Dit verschilt sterk van beeldscherm tot beeldscherm, want ieder heeft verschillende formaten en die hebben ieder weer andere instellingen. En met px opgeven maak je het voor slechtzienden ontoegankelijker, omdat zij (en anderen) het dan niet meer zelf in hun voorkeuren kunnen instellen. Romaine (overleg) 15 okt 2012 19:10 (CEST)

@Glatisant: Juist in infoboxen is er voor gekozen om afbeeldingen netjes uit te lijnen tegen de kantlijnen. Als afbeeldingen niet passend zijn in een infobox hoeven ze niet in een infobox te staan. In een aantal infoboxen is er wel een parameter om de breedte in te stellen, maar die is bedoeld voor uitzonderingsgevallen: bij hele smalle en/of kleine afbeeldingen die te korrelig blijven. Voor het gaan aanpassen van breedtes puur op smaak is die parameter niet bedoeld. De breedte van een infobox is afgestemd op de gemiddelde bezoeker en de plaatjes die er in staan zijn daar ingevoegd met dat formaat mede omdat ze de belangrijkste afbeelding zijn van het artikel en in ieder beeldscherm dan duidelijk worden getoond. Groetjes - Romaine (overleg) 15 okt 2012 19:10 (CEST)

Zeer eens met Romaine. JRB, u schrijft "naar mijn smaak" en "is verre te prefereren". Ik deel uw standpunt volstrekt niet - gevolg is dat ik afbeeldingen niet volgens "mijn voorkeuren" te zien krijg, maar naar uw smaak en uw voorkeuren. Wammes Waggel (overleg) 15 okt 2012 23:17 (CEST)

Ik ben het juist zeer met JRB eens. Afbeeldingen dienen in de tekst geïntegreerd te zijn. Het probleem met de standaard-thumbgrootte is daarbij dat die ongeveer op het minimum is afgesteld waarop de gemiddelde gebruiker nog net kan zien wat een afbeelding voorstelt. Diezelfde gebruiker zal geen voorkeursgrootte ingesteld hebben en krijgt dan automatisch een lap tekst voorgeschoteld, hier en daar onderbroken door vage minuscule plaatjes in een saaie opmaak. Zo zijn wij allen slechtziend. Als een commercieel typografisch opmaker het zou wagen dergelijk broddelwerk te leveren, zou zijn carrière van korte duur zijn. Ik zou erop willen aandringen de opmaak zoveel mogelijk aan de wijsheid van de bijdragers aan een lemma over te laten!--MWAK (overleg) 16 okt 2012 10:16 (CEST)

Het is een encyclopedie, geen plaatjesboek. De tekst staat voorop, plaatjes zijn alleen een kleine ondersteuning. Men kan op de plaatjes klikken voor een grotere afbeelding indien men die wenst te zien. Een encyclopedie hoort iets te zijn waar bij elk artikel een uniforme opmaak plaats dient te vinden. Indien elke gebruiker maar wat doet met 'zijn' artikel, dan ziet het er natuurlijk niet uit. Goudsbloem (overleg) 16 okt 2012 10:44 (CEST)

(na bwc) Ik heb toch sterk het vermoeden dat de schrijvers hierboven (boven Goudsbloem dus) niet gelezen hebben wat Romaine heeft proberen uit te leggen. Natuurlijk horen afbeeldingen geïntegreerd te zijn in de tekst. Maar versmal voor de lol je browser eens en zie hoe de plaatjes aan de wandel gaan in de tekst! Wikipedia is niet een glossy folder gemaakt door typografische specialisten, maar een platform dat op een zo droge (en ja, dus saaie) manier zijn informatie prijsgeeft. We zijn niet voor de mooi, maar voor de info. Om er voor te zorgen, dat de info en afbeeldingen op allerlei platforms goed zichtbaar zijn en de tekst niet overhoop halen (van klein smartphone-schermpje tot super-wide-screen) hebben de software-ontwikkelaars hier een foefje voor geprogrammeerd: thumb. Als je dan eigenwijs toch een breedte wilt opgeven, omwille van de typografische opmaak, dan geef je toch eigenlijk aan, weinig kaas van te hebben gegeten hoe typografie zich op verschillende platforms gedraagt? M.vr.gr. brimz (overleg) 16 okt 2012 10:46 (CEST)

Het punt is dat de afbeeldingen op de default van thumb niet goed zichtbaar zijn. Althans, je kunt wel zien dat dat er een afbeelding is maar om te zien wat er dan eigenlijk op staat, is het te vaak nodig haar te vergroten. Dat is problematisch want anders dan Goudsbloem suggereert, is de afbeelding meestal niet slechts een ondersteuning maar een bron van essentiële informatie. En de gemiddelde gebruiker zal niet klikken maar wel zappen...Het is waar dat er bij telefoons ruimtegebrek kan ontstaan, maar dat zal in mindere mate bij de huidige defaultbreedte ook gebeuren. Langere artikelen zal men toch wel niet op zijn Nokia 100 willen lezen. Een uniforme opmaak is in zijn algemeenheid het doel maar men moet dat niet tot in het absurde willen doorvoeren. Een uniforme opmaakstijl houdt natuurlijk normaliter niet in dat alle afbeeldingen, ongeacht hun proporties, dezelfde breedte hebben.--MWAK (overleg) 16 okt 2012 17:50 (CEST)

Nee, dat geef je niet aan. Zoals ik elders al heb aangegeven, heb ik bij een aantal artikelen veel zorg besteed aan de opmaak. Die heb ik ook op schermgroottes gecontroleerd van 27" tot tablet. Ziet er keurig uit. Een bot kan dat niet bepalen.

Er is niets mis met een default-instelling, honderdduizenden artikelen over insecten kunnen daar prima mee onderhouden worden. Maar maak het alsjeblieft geen dogma voor die weinigen die nog grote overzichtsartikelen schrijven. Dank u. BoH (overleg) 16 okt 2012 13:43 (CEST)

Hear, hear.--MWAK (overleg) 16 okt 2012 17:50 (CEST)

In een recente kwestie paste de bot alleen der onderliggende code aan met gelijkblijvend uiterlijk. De bot in kwestie heeft dus niets bepaald, maar heeft enkel het een door het ander vervangen met een gelijk resultaat, waarbij bovendien onnodige pixel-opgaven werden verwijderd om bijvoorbeeld slechtzienden ook de kans te geven de afbeeldingen te bekijken dankzij de zelf in te stellen persoonlijke voorkeuren. Dat je zelf gekeken hebt op verschillende schermgroottes is weinig relevant: er zijn tientallen beeldschermformaten in omloop en dat vermenigvuldigt met het aantal instellingen die er met beeldschermen (o.a. resoluties) mogelijk zijn alsmede vermenigvuldigd met de diversiteit aan browsers en hun mogelijkheden aan verschillende instellingen. Verder denk ik dat in lijn met het begrip artikelbazen het een slecht idee is dat auteurs claims gaan lopen leggen op artikelen, artikelen worden immers vrijgegeven.

Een dogma wordt er niet van gemaakt, de vraag die hier ligt is wat we willen: willen we dat het voor die enkele schrijver er goed uit ziet (die allang kennis genomen heeft van de informatie in het artikel) of ook voor andere gebruikers/bezoekers waaronder slechtzienden die het maar net moeten hebben van het kunnen instellen van breedtes van afbeeldingen in hun voorkeuren? Ik denk toch dat laatste. Groetjes - Romaine (overleg) 16 okt 2012 16:55 (CEST)

Eens met BoH. Huidige thumbs zijn iederdaad erg klein, waardoor zij soms niet te lezen zijn, waardoor zij hun functie verliezen. Ik vraag me verder af hoeveel mensen de instellingen van afbeeldingen hebben aangepast om de thumbafbeeldingen op een andere grootte te zien. Ik vermoed nog geen half procent van het aantal bezoekers. Druifkes (overleg) 16 okt 2012 18:13 (CEST)

Correctie: Huidige thumbs zijn voor jou erg klein. Het dus dus handig voor jou als je de instelling van grootte in je voorkeuren op een groter formaat kunt instellen. Voor bezoekers met een erg smal beeldscherm zijn de thumbs gewoon prima of misschien al wat aan de grote kant, en willen niet met nog grotere afbeeldingen opgescheept worden. De schatting van je lijkt me totaal uit de lucht gegrepen en nietszeggend. En dan nog, al zouden we een half procent van de bezoekers daarmee kunnen helpen, maken we informatie tenminste ook voor hen toegankelijk. Dat is ons doel immers. Groetjes - Romaine (overleg) 16 okt 2012 18:19 (CEST)

Leuk voor die 0,5% maar de overige 99,5% kunnen hierdoor sommige afbeeldingen niet normaal zien zonder erop te moeten klikken. We hoeven niet alles in een keurslijf te duwen. Druifkes (overleg) 16 okt 2012 18:22 (CEST)

Lees je nou echt niet wat ik schrijf???? Romaine (overleg) 16 okt 2012 18:44 (CEST)

De argumenten lijken niet te volstaan om tot het afdwingen van een thumbdefault van lage breedte te concluderen. Dat een kleine groep slechtzienden niet gedwongen wordt steeds te klikken is mooi. Maar hoe kan dat gerechtvaardigd worden door een regel die de grote meerderheid van de gebruikers vaak dwingt wel te klikken? Ook het argument dat we gebruikers met smalle schermen ter wille moeten zijn, is niet heel overtuigend. Bij grotere afbeeldingen zullen die soms wat raar in de tekst geplaatst worden. Dat probleem lijkt niet op te wegen tegen het nadeel dat klikken meestal een origineel oproept dat helemaal buiten het scherm valt. Natuurlijk, als we het over erg smalle schermen hebben, dreigen alle afbeeldingen erbuiten te gaan vallen. Maar die gebruikt bijna niemand meer. Bij mobieltjes is de schermbreedte al jaren 320px of meer en bij smartphones 480px of meer.--MWAK (overleg) 17 okt 2012 09:59 (CEST)

Na een willekeurige wandeling door wikipedia-wereld, waarbij ik na vele malen klikken een twintigtal pagina's ben tegengekomen met afbeeldingen, kan ik stellen, dat er maar één afbeelding bijzat die groter wilde bekijken. Dat gebruikers dus gedwongen worden om op de afbeeldingen te klikken, valt ook wel weer wat mee. En daarnaast; Romaine schrijft ook heel duidelijk dat niet alle afbeeldingen een thumb hoeven zijn. Als een afbeelding een diagram bevat, of een ander soort van afbeelding waarbij het nodig is dat deze groter wordt weergegeven, dan kan dat ook gewoon. M.vr.gr. brimz (overleg) 17 okt 2012 10:18 (CEST)

Bij heel veel onderwerpen en veel soorten afbeeldingen zal "thumb" uitstekend volstaan. "Largethumb" is daarbij een voortreffelijke aanvulling hierop. Ik ben er niet op tegen dat er een standaard is en die als normale richtlijn gebruikt wordt. Dat biedt veel voordelen. Ik vrees slechts de verleiding die men zou kunnen voelen het vrijwel onmogelijk te maken hiervan af te wijken.--MWAK (overleg) 17 okt 2012 10:35 (CEST)

Mijn intentie is absoluut niet om een richtlijn te maken, gebruikers moeten, vindt ik, echt ruimte hebben om af te wijken als dat echt zinnig is. Maar tegelijkertijd is mijn indruk dat er soms te veel kunst en vliegwerk van gemaakt wordt, te veel creativiteit wordt ingevoegd, die buiten proportioneel is en volgens mij meer van doen heeft met overdrijven en overdaad dan het evenwichtig maken van een artikel. Geen richtlijn dus, maar wel een aansporing naar gebruikers om hier wat meer aandacht om te besteden. Deze functionaliteit is er bewust door de ontwikkelaars in gebracht in de software jaren geleden met goede redenen en is gebaseerd op statistieken van gemiddelde beeldschermformaten. Laten we die functionaliteit dan ook goed gebruiken en rekening houden met de verscheidenheid aan omstandigheden van onze bezoekers aan wie wij de informatie aanbieden. Groetjes - Romaine (overleg) 20 okt 2012 03:28 (CEST)

Ik heb nog maar eens op verschillende schermgroottes gekeken, maar kan in de artikelen die mij aangaan geen probleem ontdekken. Kan er een concreet voorbeeld gegeven worden waar het mis gaat? BoH (overleg) 16 okt 2012 22:14 (CEST)

Zijn er geen conrete voorbeelden te vinden? BoH (overleg) 19 okt 2012 02:45 (CEST)

Ik heb geen voorbeelden bij de hand, maar ik heb in het verleden wel genoeg voorbeelden gezien. Daarnaast gaat het om persoonlijke voorkeuren, zodat mensen met slechte ogen of grotere beeldschermen grotere afbeeldingen kunnen krijgen. Ik denk dat we als makers van een neutrale encyclopedie voorzichtig mogen zijn en wat terughoudend als het gaat om het op smaak van de schrijver meer of minder uitlichten van bepaalde afbeeldingen ten opzichte van andere. Groetjes - Romaine (overleg) 20 okt 2012 03:28 (CEST)

Die persoonlijke voorkeuren zijn mooi, maar kunnen nooit dusdanig worden ingesteld dat ze ideaal zijn voor meer dan een miljoen artikelen. Daarnaast denk ik dat er zo ongeveer 20 mensen zijn die iets anders hebben ingesteld dan default. Maar goed, ik lees hierboven dat je er geen richtlijn van wilt maken en daarmee is voor mij de kous af. BoH (overleg) 21 okt 2012 02:49 (CEST)

Dankjewel voor de uitleg, Romaine! Nu weten we waarom er een thumb is. Wellicht handig om dit ook op de hulppagina zo uit te leggen? Met vriendelijke groet, --Denkhenk

Zie: Help:Gebruik_van_bestanden#Thumb. Daar staat het al een tijd. Romaine (overleg) 20 okt 2012 18:29 (CEST)

Aankomende software-aanpassingen - meldt eventuele problemen

Alle Wikimedia wiki's - waaronder ook deze - zullen worden geüpgraded met nieuwe en mogelijk verstorende code. Dit proces van updaten start vandaag en is klaar op 24 oktober. (zie ook het schema van upgraden & details code).

Kijk alsjeblieft uit voor problemen met de volgende dingen:

• Verschillen bij wijzigingen (diffs)
• Sjablonen
• Pagina's met CSS en JavaScript (zoals scripts gemaakt door gebruikers)
• Bots
• Exporteren van PDF's
• Afbeeldingen, video's, en geluid, en dan vooral het herschalen van deze media
• het Keulsblauwe uiterlijk

Als je nog tegen problemen loopt geef dit dan aan op Bugzilla. Je kan testen voor eventuele problemen op test2.wikipedia.org en mediawiki.org, welke beide al de nieuwste versie draaien.

Alvast bedankt! Met jouw hulp kunnen we problemen vinden en deze zo snel als mogelijk oplossen.

Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 16 okt 2012 05:06 (CEST)

P.S.: Voor de meer reguliere en kleinere MediaWiki updates die elke 2 weken plaats vinden, zie deze pagina.

Distributed via Global message delivery. (Wrong page? Fix here.)
Vertaald door Wiki13 (overleg)

PS: Meld het liever eerst hier, zodat er eerst gekeken kan worden of er in bijvoorbeeld de sjablonen, etc geen fouten zitten die er dringend uit moeten of dat de bugs al ergens gerapporteerd zijn. Dank! Romaine (overleg) 16 okt 2012 16:42 (CEST)

Sjabloon werkt niet meer

Goedenmorgen dames en heren, het is mij opgevallen dat het sjabloon SUHH-VLAG niet meer werkt. Deze laat geen vlag meer zien. Iemand hier meer last van? Eventueel ook een oplossing? Mijn dank zou groot zijn. Met vriendelijke groeten - Scarafax -  17 okt 2012 07:55 (CEST)

Het sjabloon is niet onlangs gewijzigd, en qua code gelijk aan {{NL-VLAG}} die wel gewoon werkt: . Ik zie ook geen vlag, en de afbeelding bestaat wel. Als je {{SUHH-VLAG|50}} gebruikt zie je trouwens wel een vlag: . ed0_verleg 17 okt 2012 09:43 (CEST)

Dat was mij ook al opgevallen inderdaad. Snap dus niet hoe dit komt. Iemand een oplossing? - Scarafax -  17 okt 2012 09:55 (CEST)

Het zou te maken kunnen hebben met de hierboven aangekondigde software-aanpassing. Het enige verschil tussen de twee genoemde sjablonen lijkt mij het formaat van de gebruikte afbeeldingen. Mvg, Fontes 17 okt 2012 10:28 (CEST)

Blijkbaar was het afbeeldingsformaat niet compatible met de ingestelde 1|20 afmeting... Nu maar hopen dat een bot het niet 'repareert' in de drang naar uniformiteit oid... Mvg, Fontes 17 okt 2012 10:40 (CEST)

Is dit dan het moment? Dat al die lelijke vlagsjablonen gewoon van hogerhand worden afgeschaft? Yesss. :-P brimz (overleg) 17 okt 2012 10:47 (CEST)

Wat zul jij een kleurloos bestaan leiden Brimz. ;-) Alles werkt zolang je het maar niet teveel gebruikt (in mate, teveel is nooit goed etc. etc..). In alle lijstjes met een landsnaam er een vlaggetje voor plakken is mij ook te dol natuurlijk (zeker lijstjes met +50 landen).

Ik was gister bezig op de Simpel Engelstalige Wikipedia en zag dit op een gegeven moment ook gebeuren. Ik zat toen al in de sjablonen te kijken of misschien daar het probleem te vinden was, maar vond niks. Ik denk dat het inderdaad zal liggen aan de komende software-aanpassing. --Wiki13 (overleg) 17 okt 2012 11:40 (CEST)

Sorry Fontes, maar dat klopt niet. Dit is gewoon een bug. 20px is een prima formaat voor deze vlag en is geen reden waarom dat niet zo mogen weergeven. Van 1|20 is de 1 slechts de naam van de parameter en heeft dat niets van doen met de afbeelding of het formaat zelf. Het ligt inderdaad aan de software-update zoals die in een kopje hierboven wordt beschreven. Met eerdere updates hebben vergelijkbare problemen zich voorgedaan. Groetjes - Romaine (overleg) 17 okt 2012 15:36 (CEST)

Ook op de Engelse wikipedia speelt dit probleem zie mijn zandbak w:en:User:FakirNL/sandbox. Ik heb op Commons gevraagd of ze denken dat het aan de file-code ligt: commons:File talk:Flag of the Soviet Union.svg. - FakirNL_overleg 17 okt 2012 17:09 (CEST)

Er zijn allerlei meer bestanden die precies dezelfde problemen geven. De oplossing hiervoor is: geduld. Het is een MediaWiki-bug die binnen de kortste keren opgelost wordt. Indien er andere problemen zijn, meld ze! Groetjes - Romaine (overleg) 17 okt 2012 17:38 (CEST)

Dat kan zo zijn, het veranderen van 20 in 21 werkte wel. noem het een acceptabele work arround. Mvg, Fontes 17 okt 2012 19:59 (CEST)

Bij de vlag gaf zowel de variant die 20 pixels breed is en de variant die 25 pixels breed tijdelijke problemen. Deze problemen die te maken hadden met het verkleind weergeven in bepaalde afmetingen betroffen de afbeelding en dus alleen indirect het sjabloon. Het tijdelijk aanpassen van die 20 in 21 was een welkome work around, maar die is intussen niet meer nodig zodat ik deze teruggedraaid heb. Vooral als bij een lijstje met vlaggen alleen die van de Sovjet-Unie 21 pixels breed is terwijl van alle andere landen het 20 pixels is, geeft dat op beeldschermen met niet zo'n hoge resolutie een onrustig beeld. Hoe dan ook, het tijdelijk probleem is opgelost en de meeste lezers hebben er dankzij de work around waarschijnlijk niets van gemerkt. - Robotje (overleg) 18 okt 2012 09:11 (CEST)

Zo te zien is de bug ook bij andere afbeeldingen die dit probleem vertoonden opgelost. Alles zou weer moeten werken wat dat betreft. Groetjes - Romaine (overleg) 18 okt 2012 10:07 (CEST)

Kom er vandaag toch weer een tegen, nog niet helemaal opgelost dus. Romaine (overleg) 18 okt 2012 19:54 (CEST)

Bewerkingen van volglijst verdwenen

Ik stel ineens vast, dat bewerkingen die hier op deze pagina's worden gedaan, van mijn volglijst zijn verdwenen, terwijl Wikipedia:De Kroeg wel degelijk bij mij als 'te volgen' staat aangevinkt. Kan dit met bovengenoemde upgradingsactie te maken hebben? Groet, Piet.Wijker (overleg) 17 okt 2012 22:22 (CEST)

Het kàn ook zijn dat je in je Voorkeuren, onder Volglijst: 'Kleine bewerkingen op mijn volglijst verbergen' aangevinkt hebt staan. Erik Wannee (overleg) 17 okt 2012 22:53 (CEST)

Nee, dat is niet het geval. Overigens werden deze twee laatste berichten weer wèl op mijn volglijst gemeld. Dus voor zover het een probleem was, lijkt het zichzelf inmiddels te hebben verholpen. Groet, Piet.Wijker (overleg) 17 okt 2012 22:57 (CEST)

Heb je soms bovenaan je lijst ingesteld dat bots niet worden weergegeven op je volglijst? De archiveerbot komt soms langs, hetgeen ervoor kan zorgen dat de pagina niet zichtbaar is. Pompidom (overleg) 17 okt 2012 22:59 (CEST)

Ah, dat is het! Dank, Pompidom, voor deze hint. Ik zal erover nadenken, of ik die instelling ga wijzigen. Groet, Piet.Wijker (overleg) 18 okt 2012 08:46 (CEST)

Opnieuw ervaar ik dat iets niet op mijn volglijst voorkomt. Ik heb zojuist een nieuw aangemaakt artikel bewerkt, heb aangeklikt dat ik dit wil volgen en toch komt de titel niet voor op mijn volglijst. Voor alle zekerheid heb ik de volgbutton aangeklikt, de volgoptie ongedaan gemaakt en vervolgens opnieuw als 'te volgen' aangeklikt, maar er gebeurt niets. Raar. Heeft iemand een idee? Groet, Piet.Wijker (overleg) 20 okt 2012 17:41 (CEST)

Ik zie het al. Enkele minuten nadat ik mijn laatste wijziging had aangebracht, is er onverwacht een bot aan de gang gegaan. En bots heb ik uitstaan bij mijn voorkeuren. Probleem opgelost. Groet, Piet.Wijker (overleg) 20 okt 2012 20:19 (CEST)

Import a gadget from Spanish Wikipedia

In Spanish Wikipedia we have this Gadget. It show the history and all specials pages (like contributions) as a numbered list. I like this gadget and I think that it is a good tool. So I request an administrator add it in Speciaal:Voorkeuren> Uitbreidingen > and in Spanish we have in "Interface". Or put this gadget like default changing it the dots. I like the two option (change). The description phrase is "Show the history and all specials pages as a numbered list." For questions, contact me. The translation of the Spanish word Excepciones is Exceptions.--Vivaelcelta (overleg) 20 okt 2012 22:38 (CEST)

Fundraising localization: volunteers from outside the USA needed

Please translate for your local community

Hello All,

The Wikimedia Foundation's Fundraising team have begun our 'User Experience' project, with the goal of understanding the donation experience in different countries outside the USA and enhancing the localization of our donation pages. I am searching for volunteers to spend 30 minutes on a Skype chat with me, reviewing their own country's donation pages. It will be done on a 'usability' format (I will ask you to read the text and go through the donation flow) and will be asking your feedback in the meanwhile.

The only pre-requisite is for the volunteer to actually live in the country and to have access to at least one donation method that we offer for that country (mainly credit/debit card, but also real-time banking like IDEAL, E-wallets, etc...) so we can do a live test and see if the donation goes through. All volunteers will be reimbursed of the donations that eventually succeed (and they will be low amounts, like 1-2 dollars)

By helping us you are actually helping thousands of people to support our mission of free knowledge across the world. Please sign up and help us with our 'User Experience' project! :) If you are interested (or know of anyone who could be) please email ppena@wikimedia.org. All countries needed (excepting USA)!

Thanks!
Pats Pena
Global Fundraising Operations Manager, Wikimedia Foundation

Sent using Global message delivery, 17 okt 2012 19:12 (CEST)

Waarom is bovenstaand bericht niet vooraf vertaald? Mathonius 19 okt 2012 10:22 (CEST)

De Wikimedia Foundation plempt wel vaker engelstalige berichten op anderstalige wiki's, in de wetenschap dat er altijd wel iemand is die de vertaling op zich neemt. --RenéV (overleg) 19 okt 2012 10:32 (CEST)

Klopt. Dat vind ik jammer, want deze berichten zouden volgens mij prima op Meta voorbereid en vertaald kunnen worden. Mathonius 19 okt 2012 11:03 (CEST)

Dat zou ook van meer respect voor de lezers getuigen. » HHahn (overleg) 19 okt 2012 21:14 (CEST)

Aan de andere kant, moet je dagen gaan wachten op een vertaling als je op zoek ben naar vertalers met kennis van Engels. Lijkt me ook weer zonde van de tijd eerlijk gezegd. TheDJ (overleg) 20 okt 2012 16:14 (CEST)

Zonder de amerikaanse marketing-newspeak geparafraseerd:

Hoi allemaal,

Het sponsoren zoekteam van de Wikimedia Stichting wil graag beter begrijpen hoe donateuren uit andere landen (dan de USA) de betreffende pagina's ervaren. Ik zoek vrijwilligers die bereid zijn om 30 minuten via een Skype chat met mij de donatiepagina's van hun land te beoordelen. Je verteld mij daarbij hoe het donatieproces afloopt en geeft daarop tegelijk commentaar.

Voorwaarde is dat je in het betreffende land woont en dat je tenminste een van de donatiemethodes kunt uitproberen (creditcard, IDEAL, E-Wallet enz). Dat geld (1 of 2 dollar) krijg je uiteraard terug.

Om mee te doen: email ppena@wikimedia.org

Bedankt Pats Pena
Global Fundraising Operations Manager, Wikimedia Foundation

Zwitser123 (overleg) 21 okt 2012 16:53 (CEST)

Stemming over uitspraken van de arbitragecommissie

Tot 4 november vindt hier een stemming plaats over bepaalde uitspraken van de arbitragecommissie. Marrakech (overleg) 21 okt 2012 18:00 (CEST)