Web Analytics
Privacy Policy Cookie Policy Terms and Conditions Overleg MediaWiki:Monobook.css - Wikipedia

Overleg MediaWiki:Monobook.css

Zojuist (2 september 2004) werd in de Kroeg gesuggereerd om het uiterlijk van de Nederlandstalige Wikipedia aan te passen, bijvoorbeeld de achtergrond van artikelen een andere kleur te geven dan de achtergrond van niet-artikelen (overlegpagina's, Wikipedia-naamruimte, enz.). Daarnaast zou bijvoorbeeld het lettertype aangepast kunnen worden (een aantal gebruikers is individueel al overgestapt op Verdana), of de lay-out van de pagina (bijvoorbeeld de bewerkingsknoppen niet alleen bovenaan maar ook onderaan). Dit heeft verschillende voor- en nadelen, o.a.:

Voor:

  • Het kan er mooier op worden
  • Overzichtelijkheid verbeteren (bijv. door kleuren achtergrond)
  • Leesbaarheid verbeteren (bijv. door ander lettertype)

Tegen:

  • Consistentie met anderstalige Wikipedia's wordt verminderd (met name als de lay-out aangepast wordt)

Uiteraard kan ieder voor zich het uiterlijk aanpassen (in je eigen monobook.css), het gaat in deze discussie dan ook vooral om het uiterlijk dat niet-geregistreerde gebruikers te zien krijgen (en geregistreerde gebruikers die (nog) geen eigen monobook-css hebben.

Graag jullie reacties, willen we het uiterlijk aanpassen, en zo ja, wat willen we aanpassen?

Inhoud

[bewerk] KLEUREN

[bewerk] Van alles standaard wit naar verschillende kleuren

De niet-artikel pagina's een andere kleur geven. Duits heeft lichtpaarsblauw, Engels licht zeegroen, Frans heeft wat feller groen, terwijl de overlegpagina's zachtgeel zijn. De Franse heeft het duidelijkste css: http://fr.wikipedia.org/wiki/MediaWiki:Monobook.css

Voor:

  • De niet-artikel pagina's een andere kleur geven is een heel goede zaak. Ik ben voor een woestijn/gelige kleur. Zoals vroeger dus. Misschien wat zachter. Walter 2 sep 2004 10:22 (CEST)
  • Ik vind het goed zoals de Duitsers het doen. Känsterle 2 sep 2004 10:24 (CEST) (Dat is een soort licht paarsblauw Elly 2 sep 2004 11:48 (CEST))
  • Ik ben voor een andere kleur. Uit nostalgie sluit ik aan bij Walter. Elly 2 sep 2004 11:48 (CEST)
  • Geel voor de pagina's in de Wikipedia-naamruimte, licht paars voor de overlegpagina's, groen voor de sjabloon-naamruimte. Maar andere kleuren mogen natuurlijk ook :-) Puck 2 sep 2004 21:26 (CEST)
  • Gematigd voor: op dit moment zijn er te veel kleuren, en snap ik niet dat de gebruikerspagina's dezelfde kleuren hebben als de artikelen. Eigenlijk vind ik twee kleuren (wit en bij voorkeur zachtgeel) wel voldoende. Zie ook mijn opmerkingen hieronder. Fruggo 4 sep 2004 13:36 (CEST)
  • Eens met Fruggo: op zich ben ik positief over het idee, maar momenteel vind ik het wel erg onrustig met al die verschillende kleuren; wit voor de artikelen en zachtgeel voor de rest lijkt mij beter. RonaldW 4 sep 2004 18:26 (CEST)
  • Ik vind het mooi, mits de kleuren niet te fel zijn. Een lichte tint is voldoende; overdaad schaadt (de associatie met zonnebank-bruine dames komt in mij op). Quistnix 4 sep 2004 18:23 (CEST)

Tegen:

  • Ik vind het niet mooi, als er een optie is om dit persoonlijk te regelen, dan vind ik het verder best. Ik vind het onrustig. GerardM 4 sep 2004 09:43 (CEST)
  • Eens met Gerard. Ik word er scheel van en krijg een gevoel alsof ik bij Prenatal rondloop. Avanschelven 4 sep 2004 15:36 (CEST)
  • Met bovenstaande heren eens. In mijn persoonlijke .css maak ik overigens onderscheid tussen de verschillende naamruimten door niet de achtergrond maar het kader en een horizontale lijn onder de titel van kleur te laten veranderen (artikelen hebben een geel kader en gele lijn onder de titel, alle andere naamruimten hebben een rood kader en rode lijn onder de titel). Is dat misschien een idee? Lennart Afbeelding:LogoLB.png 4 sep 2004 17:38 (CEST)
    • Vind ik ook wel een mooi idee. Op zich zou je je daarmee trouwens niet hoeven te beperken tot twee kleuren, je zou nog aparte kleuren kunnen gebruiken naar de wikipedia-naamruimte, etc. RonaldW 4 sep 2004 18:17 (CEST)
    • Ik heb Lennarts idee even in mijn stylesheet gekopieerd, en ik vind het geweldig. Het is niet overheersend maar je ziet het wel. Naar mijn idee beter dan via achtergrondkleuren. Sander Spek 6 sep 2004 10:52 (CEST)

[bewerk] LINKS

Het irriteert mij vooral dat de links zijn onderstreept. Dat geeft een erg onrustig beeld. Känsterle 2 sep 2004 10:36 (CEST)
Dat kan je uitzetten in de voorkeuren. Wanneer we dit willen veranderen kunnen we naar mijn idee beter de default-instelling van de voorkeuren wijzigen. Als we het via het stylesheet doen werkt de optie in de voorkeuren wellicht niet meer en kunnen gebruikers de onderstreping niet meer aanzetten wanneer ze dit willen. Sander Spek 2 sep 2004 10:52 (CEST)

Hmmm ja je hebt gelijk. Känsterle 2 sep 2004 10:56 (CEST)


Een hele verbetering zo! :-) Puck 3 sep 2004 15:10 (CEST)

[bewerk] Lettertype

Ik stel voor om over te stappen naar Verdana als lettertype. Een aantal gebruikers is hier individueel al op overgestapt meen ik. Verdana heeft als voordeel dat het een heel open lettertype is en daardoor goed leesbaar op de PC. Ten opzichte van het huidige lettertype heeft Verdana als (in mijn ogen) bijzonder groot voordeel dat schuingedrukte tekst bij Verdana niet doorloopt in de rechte tekst erna. Graag jullie mening! Fruggo 3 sep 2004 18:35 (CEST)

Verdana en Georgia hebben als voordeel dat ze ontwerpen zijn om van een scherm te lezen. Lettertypen als Arial en Times zijn vooral ergonomisch wanneer geprint, niet op beelscherm. Daarom ben ik wel voor Verdana. Nadeel is dat deze volgens mij alleen voor Windows-systemen beschikbaar is, dus wellicht moeten we er nog een paar toevoegen in de stylesheet. Sander Spek 6 sep 2004 08:44 (CEST)
Haha, ik lees nu het SmallZine-artikel waarvan Muijz in de kroeg de link gaf: "Ook zijn (Ben Vrooms) advies om het Verdana letterfont te vermijden zouden meer websites ter harte moeten nemen." :) De letters zijn te groot waardoor er weinig interlinie overblijft. Dan stel ik voor Verdana als lettertype te kiezen en tevens in de stylesheet de interlinie iets te vergroten. Sander Spek 6 sep 2004 10:06 (CEST)
Te weinig interlinie? Wat is dat? Verdana is op mijn monitor heel prima leesbaar. Ik heb er meerdere uitgeprobeerd toen monobook geïntroduceerd werd, maar geen lettertype kon tippen aan Verdana. Fruggo 6 sep 2004 22:10 (CEST)
Ik vind Verdana ook super (alhoewel ik Myriad Roman of Bitstream Vera Sans toch net iets liever heb, maar die heeft niet iedereen). De kritiek -te weinig interlinie- wil zeggen dat de tekens te groot zijn, en dat daarom de witte ruimte tussen regels te klein wordt. MS Word noemt het line spacing. Maar ik moet eerlijk bekennen dat wanneer ik zo eens wat lettertypen naast elkaar zet, ik Verdana helemaal niet overdreven dicht bij elkaar vind staan. Zie [1]. Sander Spek 7 sep 2004 08:54 (CEST)

[bewerk] Toelichting

Na bovenstaande opmerkingen, waarvoor heel veel dank (kennelijk is hiervoor minder belangstelling dan voor de indeling in een categorie van de IJslandse tropischwatersportvissers (dat is dus een geintje met een wat serieuze ondertoon)), heb ik de kleuren voorlopig als volgt ingesteld, grotendeels gebaseerd op de Franse wikipedia:

  • Artikelen, afbeeldingen, categorieën, gebruikerspagina's: wit
  • Alle overlegpagina's: het geel van Walter (als dat ergens nog niet zo is, is dat een vergissing)
  • MediaWiki (zoals dit artikel): paarsachtig
  • Wikipedia naamruimte: groen
  • Sjabloon: lichtblauw (dat is de standaardkleur)
  • Overige: (bijvoorbeeld recente wijzigingen, inlogpagina's, voorkeuren, etc) lichtblauw (dat is de standaardkleur).

Nu de kleuren gewijzigd zijn komen er vast meer opmerkingen. Laten we die eerst maar verzamelen en dan er een grootste gemene deler uithalen. De pagina zelf is beveiligd en kan daardoor alleen door moderators bewerkt worden. Als een andere gebruiker eens wil testen, kan de beveiliging door een moderator tijdelijk worden opgeheven. Een permanente deblokkade lijkt me niet verstandig. Een kwaadwillende gebruiker zou de kleuren namelijk bijv. allemaal zwart kunnen maken, zodat wikipedia onleesbaar wordt. Elly 3 sep 2004 15:27 (CEST)

[bewerk] Opmerkingen bij huidige instellingen van de kleuren

Barst maar los:

  • Op zich vind ik het een goed idee om pagina's via kleuren te onderscheiden. Zeker voor nieuwe gebruikers kan dit veel houvast geven. Maar veel van de huidige kleuren vind ik erg lelijk in combinatie met de grijze monobook-layout die er nog omheen hangt. Ik weet niet of het mogelijk is, maar wellicht is het mooier om juist het veld buiten het content-veld een andere achtergrondkleur te geven. (Maar dat weet ik niet zeker; misschien vind ik dat ook niet mooi.) Maar voorlopig ben ik er wel voor deze kleuren te houden. Sander Spek 3 sep 2004 15:37 (CEST)
  • Ik sluit mij aan bij een goed idee om pagina's via kleuren te onderscheiden. Maar lijkt mij wat teveel van het goede. Al die verschillende kleurtjes, doet mij aan WindowsXP denken. Wit voor de artikels en het geel van deze overlegpagina is goed. Ik ben eerder neutraal tegenover het blauw voor de speciale pagina's. Kwestie van gewenning. Maar dat groen voor de Wikipedia-naamruimte is er over voor mij. Dat zou ik liever ook geel zien, net als hier. Ik zie drie groepen van pagina's;
    • artikel-naamruimte; wit
    • overleg/interne keuken pagina's; geel
    • systeempagina's; (speciale pagina's, media-wiki, inlog enzo) zachtblauw

Walter 3 sep 2004 16:24 (CEST)

Hm, de nieuwe (huidige) instellingen lijken een aantal van mijn persoonlijke instellingen te overschrijven. Zo had ik de achtergrond van de alles behalve de artikelen zachtgeel, maar de gebruikerspagina's zijn nu opeens wit. Weet iemand hoe ik dat in mijn eigen css-pagina weer kan aanpassen? Het zachtgeel zoals op deze pagina vind ik op zich een erg mooie kleur, maar het zachtgroen doet me aan ziekenhuizen en tandartspraktijken denken en dat vind ik niet de beste associatie. De indeling die Walter voorstelt lijkt me een hele goede; de artikelen wit want dat leest wel zo prettig, alles wat niet encyclopedie-artikel is een ander kleurtje (voorkeur zachtgeel) om het onderscheid goed aan te geven. Eventueel mogen de systeempagina's weer een ander kleurtje maar dat maakt me eigenlijk niet veel uit. Fruggo - niet ingelogd omdat 'ie wil zien hoe een anonieme gebruiker het ziet

Ik heb de Wikipedia-naamruimte geel gemaakt. Walter 6 sep 2004 09:30 (CEST)
Ziet er niet slecht uit. Zouden de gebruikerspagina's ook nog geel kunnen worden? Dat zijn voor zover ik zo snel zie de enige niet-artikelpagina's die nog wit zijn. Fruggo 6 sep 2004 22:29 (CEST)

[bewerk] Afgeronde hoeken bij de knoppen?

In de Franse Wikipedia hebben ze in de monobook-skin de knoppen afgerond gemaakt, zie fr:MediaWiki:Monobook.css. Het gaat om de volgende broncode: (volgens mij)

/*
 * Style de l'interface de Wikipédia
 */

/* fenetre arrondi (pour les navigateurs moz/firefox/gecko) */
.pBody 
{
   padding: 0.3em 0.1em;
   -moz-border-radius-topright: 0.5em;
}
.portlet h5 
{
   background-color: #e0e3e6;
   border: thin solid silver;
   -moz-border-radius-topright: 0.5em;
}
#p-cactions ul li, #p-cactions ul li a 
{  
  -moz-border-radius-topright: 0.5em;
  -moz-border-radius-topleft: 0.5em;
}

Zoals er staat, werkt deze hoekafronding alleen voor browsers van Mozilla, maar gezien Wikipedia:Wikipedianen naar internetbrowser verwacht ik niet dat dat problemen oplevert.
Ik vind die hoeken best netjes staan eigenlijk. Sta ik hierin alleen of zijn er meer die dit vinden? Firefox Overleg 7 apr 2005 21:40 (CEST)

Ik geef persoonlijk de voorkeur aan rechte hoeken, maar het is een kwestie van smaak. Rex 7 apr 2005 23:21 (CEST)
Ik vind het zelf niet mooi staan, en de beperkte browserondersteuning (alleen Mozilla browsers), is ook niet echt in het voordeel. Gewoon zo laten als het is! Je kan het altijd nog in je eigen CSS instellen.
Ik heb hem inmiddels in mijn eigen stylesheet ingevoegd. Firefox Overleg 11 apr 2005 15:15 (CEST)

[bewerk] Taxobox class

Graag zou ik hier, net als in de Duitse Wikipedia, een class taxobox zien, met de volgende inhoud:

table.taxobox {
       border-collapse: collapse;
       border: 1px solid gray;
       float: right;
       margin-left: 1em;
       margin-bottom: 0.5em;
       font-size: 95%;
}

table.taxobox th {
       background-color: #ffc0c0;
       border: solid 1px gray;
       text-align: center;
       font-weight: bold;
}

table.taxobox td {
       vertical-align:top;
} 

table.taxobox div.thumb, 
table.taxobox div.thumb * {
       margin: 0;
       padding: 0;
       float: none;
       border: none; 
}

table.taxobox div.magnify {
       display: none;
}

table.taxobox tr td div.thumb div div.thumbcaption {
       text-align:center;
}

table.taxobox td.taxo-naam {
       text-align:center;
       font-weight: bold;
}

table.taxobox td.taxo-afb {
       text-align:center;
       padding: 0;
} 

Nadat deze is toegevoegd, zal ik hem implementeren in de taxobox-sjablonen. Rex 30 mei 2005 01:38 (CEST)

Rex, ik durf het eigenlijk niet te doen, omdat de syntax er anders uitziet dan wat er nu staat. Elly 17 jun 2005 18:59 (CEST)
De syntax is hetzelfde, alleen staat er op dit moment nog bijna niks in het bestand, waardoor het niet duidelijk blijkt dat het om dezelfde soort code gaat. Zie e.v.t. de:MediaWiki:Monobook.css voor de Duitse, uitgebreidere versie van dit bestand. Voor de duidelijkheid: het gaat om een toevoeging, niet om een vervanging. Groet, Rex 21 jun 2005 20:43 (CEST)
Ik zal het dan maar gewoon toevoegen. Elly 21 jun 2005 22:47 (CEST)

[bewerk] Voor als er iets misgaat

(verplaatst vanuit de kroeg op 22 jun 2005 16:53 (CEST) door oscar:)

Op verzoek van Rex heb ik op MediaWiki:Monobook.css iets toegevoegd voor taxoboxen. Als er iets raars misgaat ligt het misschien daaraan. Elly 21 jun 2005 22:51 (CEST)

Is nu weer verwijderd!
A) 1 persoon bepaald niet hoe iedereen tabellen te zien krijgt
B) We kunnen dan elke tabel wel hard gaan neerzetten
C) Het is niet te wijzigen
D) Behalve rex weet over een maand niemand meer waar het staat dus als iemand denkt het te veranderen kan het niet (absoluut anti WIKI!) en zoeken we ons het apezuur.
Waerth©2005|overleg 21 jun 2005 23:09 (CEST)
Aan de layout van de tabellen verandert op zich niks, alleen wordt de code wat efficiënter en wordt de "thumb"-omgeving (voor afbeeldingen in een taxobox) aangepast. Het idee is overigens niet van mijzelf, maar van de Duitse Wikipedia, waar ze dezelfde code in monobook.css hebben opgenomen. Voor de rest ben ik het wel met je bezwaren eens. Rex 21 jun 2005 23:17 (CEST)
Ja het zal best dat ze het in de Duitse wiki doen. Het betekent gewoon keihard dat als er later besloten wordt e.e.a. aan te passen dat dan niemand meer weet waar de boel staat en behalve een paar niemand het aan kunnen passen. Erg tegen de beginselen van wikipedia. Ik heb anders ook nog wel een stuk of 10 boxen die ik permanent hard erin wil hebben zodat niemand ze kan veranderen maar zo hoort het hier niet echt. Waerth©2005|overleg 21 jun 2005 23:20 (CEST)
compliment voor Waerth. Besednjak 21 jun 2005 23:23 (CEST)
Hier sluit ik me bij aan. Taka 21 jun 2005 23:32 (CEST)
Goed bedoeld, maar inderdaad systematisch onjuist (nog afgezien van de andere bezwaren). Sixtus 21 jun 2005 23:33 (CEST)
Zojuist door Elly wederom teruggezet en door mij wederom verwijderd! Waerth©2005|overleg 22 jun 2005 00:18 (CEST)

Ik maak bezwaar tegen het terugdraaien van Waerth. Rex had het keurig gevraagd op de verzoekpagina waar het al wekenlang stond. Niemand doet iets of reageert. Alleen omdat ik onzeker was heb ik het hier gemeld. Ik heb de wijziging van Waerth, (die geen koning is hier - ik raak het ook langzamerhand helemaal zat!!) teruggedraaid. Ik voel me niet serieus genomen in mijn werk hier als moderator, waar ik mij ten dienste stel van anderen. Overleg is wat mij betreft prima, en na consensus kan het dan desnoods weer worden weggehaald, maar geef Rex eerst de gelegenheid toe te lichten waar het voor is. Zeker als de interesse er eerst niet eens voor was! Als je zo doorgaat met je ruziezoekerij Waerth, gaat er echt iets helemaal mis. Elly 22 jun 2005 00:22 (CEST)

Dan had Rex het heel even ergens anders moeten melden, zoals de kroeg en duidelijk moeten toelichten wat de gevolgen waren. Die heeft hij op die overlegpagina er niet bij vermeld. En kan ik er wat aan doen dat ik de eerste ben die het opvalt nadat jij het geplaatst hebt? Waerth©2005|overleg 22 jun 2005 00:27 (CEST)
Het is inderdaad jammer dat er niet op die pagina wordt gelet. Misschien had Waerth het niet zo abrupt terug moeten zetten, maar ik ben het wel met zijn argumenten eens. Rex had dit beter eerst op een centrale diskussiepagina kunnen aankaarten. – gpvos (overleg) 22 jun 2005 00:38 (CEST)
De ruzies rond Waerth komen ook niet door zijn argumenten. Ik ben het 95% met hem eens schat ik. Het gaat juist om de manier waarop hij te werk gaat, waardoor hij momenteel dagelijks iemand tegen de haren instrijkt. Vandaag tegen de mijne, eergister tegen Vandermeer tegen de doorverwijspagina's, gister tegen Evilberry en Niels over de ISBN, morgen tegen ??? Je kan de klok erop gelijk zetten. Als wij hier gaan slapen begint een nieuwe ruzie op Wikipedia vanuit Thailand. En dat mag wel eens anders. Elly 22 jun 2005 00:50 (CEST)
Ik ben het met Elly eens dat wat meer tact en een andere benaderingswijze gewenst zijn. Je kunt hetzelfde resultaat bereiken zonder mensen op de kast te jagen. Chris 22 jun 2005 00:59 (CEST)
Sorry Elly als ik dingen zie kaart ik die aan. Ik kan er toch geen moer aan doen dat dingen mij eerder opvallen dan de meeste anderen? Als ik iets zie zeg ik het meteen. Wat moet ik dan doen? Zwijgen en de ISBN nummers laten weghalen? En ja als jullie gaan slapen sta ik op. Sorry maar dit slaat nergens op. Waerth©2005|overleg 22 jun 2005 00:57 (CEST)
Probeer nou ook eens goed te lezen wat anderen schrijven, zoals Chris hierboven. "Het gaat alleen maar om wat meer tact en een andere benaderingswijze". In dit geval kan ik het uitschrijven voor je:
Niet meteen op de reverse knop drukken
Niet schrijven in de kroeg met uitroeptekens
Niet schrijven in de kroeg met hoofdletters
Geen krachttermen zoals apezuur
In plaats daarvan:
In de kroeg constateren dat er iets veranderd is
Beschrijven wat daarvan het effect is
Op normale toon zeggen dat je het daar niet mee eens bent en waarom
Anderen vragen wat ze ervan vinden
Als die discussie afgerond is, de boel terugdraaien. Er vloeit geen bloed uit als het even, een nacht, een dag, blijft staan.
Ik hoop dat je dit serieus op zijn merites bekijkt. Ga alsjeblieft niet weer op de toer "ik ben nu eenmaal zo". Ieder mens kan zijn of haar gedrag veranderen met enige moeite. Als je het zo had gedaan had je mij echt niet op de kast gejaagd. Waar ik inmiddels gelukkig weer vanaf geklommen ben, want het sop is de kool niet waard. Elly 22 jun 2005 07:38 (CEST)
Wellicht is een algemeen editbaar CSS-bestand, dat vanuit Monobook.css geïncludet wordt, een idee? – gpvos (overleg) 22 jun 2005 00:39 (CEST)
Ik had de indruk dat Elly het gemeld had, zodat er eventueel op gereageerd zou kunnen worden. Waerth heeft in de beste bedoelingen en met goede argumenten gedaan. Waerth heeft gewoon zijn verantwoordelijkheid genomen. Geen reden voor commotie. Besednjak 22 jun 2005 00:41 (CEST)
elly treft ook geen blaam, ik vraag me af waar rex op afstuurt? zie hieronder. oscar 22 jun 2005 01:03 (CEST)

[bewerk] niet acceptabel zolang het tegendeel niet is bewezen

het liefst zou ik de pagina nu beveiligen, maar dat heeft in dit geval geen zin, omdat die sowieso alleen voor moderatoren bewerkbaar is. oscar 22 jun 2005 00:54 (CEST)

  1. ik begrijp uit waerth's argumenten, dat de voorgestelde wijziging een vaste, niet vrij bewerkbare vorm aan alle taxoboxen geeft. is dat gezamenlijk ergens besloten? niet bij mijn weten. niet-acceptabel zolang het tegendeel niet is bewezen oscar 22 jun 2005 00:54 (CEST)
    Dit klopt niet. De taxoboxen blijven gewoon bewerkbaar. De stijl die in de sjablonen wordt opgegeven gaat altijd boven de standaardstijl. Rex 23 jun 2005 00:31 (CEST)
  2. het onbewerkbaar maken van dit soort zaken is anti-wiki en tegen al onze afspraken in. niet-acceptabel zolang het tegendeel niet is bewezen oscar 22 jun 2005 00:54 (CEST)
  3. ik begrijp tevens, dat rex' voorstel niet de eerste keer is, dat hij probeert een vaste layout te creëren voor een groep tabellen. omdat de pagina alleen voor moderatoren bewerkbaar is, heeft hij het niet eigenhandig kunnen doen. heeft rex ergens ooit de verstrekkende gevolgen van de voorgestelde wijzigingen duidelijk uiteen gezet? niet bij mijn weten. niet-acceptabel zolang het tegendeel niet is bewezen oscar 22 jun 2005 00:54 (CEST)
  4. het opnemen van een vaste taxobox code in monobook.css betekent tevens dat alle persoonlijke css instellingen worden overruled voor die gebruikers die een persoonlijke css hebben ingesteld. geen verder commentaar. oscar 23 jun 2005 00:27 (CEST)
    Dit klopt niet. Het gebruikersbestand krijgt altijd voorrang op het standaard stijlbestand. Rex 23 jun 2005 00:30 (CEST)
Ik begrijp de wijzigingen eerlijk gezegd niet helemaal maar goed. Rex is een zeer actieve gebruiker die poogt Wikipedia te verbeteren. Niet alle verbeteringen worden door iedereen als een verbetering ervaren. Ik ga ervan uit dat iedereen die in deze zaak verwikkeld is in elk geval de goede bedoelingen van Rex erkent. Of wordt daar door iemand aan getwijfeld? Is het niet mogelijk om i.p.v. dergelijke wijzigingen direct terug te draaien eerst te zien wat de gevolgen zijn en daarover te discusieren? Wanneer bepaalde zaken moeilijker of helemaal niet meer te wijzigen zijn dan is dat toch een sterk argument in de discussie om het terug te draaien? Even een paar dagen aanzien wat de gevolgen van de wijziging zijn en dan pas beoordelen of het een verbetering of een verslechtering is is toch niet teveel gevraagd? (Ik realiseer me dat ik vragen stel maar kan de antwoorden pas volgende week lezen). Hou allemaal het hoofd koel en blijf bedenken dat degenen waartegen wordt "gevochten" hetzelfde doel hebben, namelijk Wikipedia verbeteren! Chris 22 jun 2005 01:25 (CEST)
Vind ik een superslecht plan. Lees de code en je ziet dat vastegelgd worden afmetingen, kleurkeuze, tekstformaat enz. Allemaal dingen die iemand achteraf dus niet meer kan wijzigen. Ik geloof dat dit van hogerhand opleggen tegen alle grondbeginselen van wikipedia indruist. Waerth©2005|overleg 22 jun 2005 01:29 (CEST)
Niemand twijfelt aan de goede bedoelingen van Rex. Maar de argumenten tegen dit plan zoals al door Waerth opgemerkt, wegen dermate zwaar dat dit plan niet moeten worden uitgevoerd. Ook niet als experiment omdat het tegen het principe van wikipedia indruist. Besednjak 22 jun 2005 01:37 (CEST)
Alle MediaWiki-pagina's zijn toch alleen voor moderatoren bewerkbaar? Ik begrijp niet helemaal waarom het nu opeens "tegen het principe van Wikipedia indruist" om het niet bewerkbaar te laten zijn. Als ik het goed begrijp mag er dus niets meer aan MediaWiki-pagina's worden gewijzigd omdat het principe van Wikipedia dan geschonden wordt? Jelle|overleg|MT 22 jun 2005 07:35 (CEST)
Vreemd genoeg, het lijkt erop. Ik heb gister OK (links in beeld onder het zoekvenster) op verzoek veranderd in "Artikel". Ik zie mij dan als een uitvoerder van een wens van een redelijke gebruiker. Zoals nu ook het verzoek van Rex, dat al weken openstond. Ik hoef me niet het "apezuur" te zoeken, want ik weet waar ik het kan vinden, en ik ben heus niet de enige die dat kan. Die pagina's zijn alleen maar beschermd, omdat ze als ze door vandalen worden bewerkt de werking van de software in de war kunnen gooien. Stel je voor dat de knoppen hieronder ("pagina opslaan" en "toon bewerking ter controle") door een vandaal kunnen worden omgewisseld. Toen die CSS mogelijkheid kwam heb ik zelf de achtergrondkleuren van de pagina's (zoals het geel wat je nu ziet) gewoon ingesteld in wat me mooi leek. Er kwam nog een kleine correctie op, en dat was het. Het getuttel over elke kleine wijziging is juist wat "tegen het principe van Wikipedia indruist". Laten we toch positief staan tegen elkaars voorstellen. Elly 22 jun 2005 07:46 (CEST)
Wat Rex wil doen, is in plaats van de tabelwaardes gewoon op de pagina's zelf zetten, waar ze voor iedereen veranderbaar zijn! Ze zetten op een pagina waar het niet voor iedereen veranderbaar is! Dus als iemand het er niet mee eens is kan hij/zij die tabelwaardes (kleur, font, opbouw enz) niet meer veranderen, wat hij/zij ook probeerd hij wordt overruled door de setting in monobook. Aangezien de gebruiker geen enkel bericht noch indicatie ontvangt waar te zoeken, zal die gebruiker gefrustreerd opgeven en de meeste mensen zullen niet weten waarom! Dit soort artikelopmaakgegevens mogen nooit op zo een manier hardgecodeerd worden zonder dat iedereen er toegang toe heeft. De kleine wijzigingen waar Elly het over heeft zijn van een totaal andere orde. Het gaat daarbij om zaken waarvan iedereen weet dat ze in monobook.css bepaald worden. Maar om de opmaak voor de boxen bij alle taxonomische artikelen hard vast te gaan leggen lijkt me wat overdreven die moeten gewoon voor iedereen wijzigbaar blijven! Waerth©2005|overleg 22 jun 2005 08:01 (CEST)
Die opmaak ligt al vast Waerth, daar is (voor ik hier kwam geloof ik) al overeenstemming over bereikt. Als iemand zomaar wat wijzigt aan de taxoboxsjablonen zonder overleg zal dat waarschijnlijk niet getolereerd worden. Het is juist goed als taxoboxen een eenduidige opmaak hebben.
Voor zover ik kan zien kunnen de sjabloon gewoon bewerkt worden en kunnen er zelfs nieuwe worden gemaakt, zoals het Sjabloon:Taxobox section genus type. Jelle|overleg|MT 22 jun 2005 08:06 (CEST)
Ja Ucucha er zijn afspraken over de opmaak. Maar als iemand het wil veranderen kan het gewoon door op de editknop te drukken! Heel simpel dat is wat wikipedia is, vrij bewerkbaar voor iedereen. Nu in het andere geval kan iemand zoveel op de editknop drukken wat ie wil, maar hij kan het niet veranderen wat hij/zij ook invult. Dit druist rechtstreeks in tegen het principe van vrije bewerkbaarheid. Want die persoon moet eerst bedenken dat ie in monobook css moet zijn en dan iemand overtuigen om de edit voor die persoon uit te voeren. Daarmee pak je alle gebruikers een stukje vrijheid af. Waerth©2005|overleg 22 jun 2005 08:30 (CEST)
En ja je kan een totaal nieuw sjablonen maken, maar is dat niet wat omslachtig als het nu gewoon met de editknop kan en 2 parameters aanpassen? En ja op dit moment is rex zijn voorgestelde niet in monobook opgenomen dus werkt het niet dus kan je alles aanpassen wat je wilt. Waerth©2005|overleg 22 jun 2005 08:27 (CEST)
Een inhoudelijke discussie, dat is waar het over moet gaan. Daarom mijn bijdrage:
  • Een style in de tag zelf overruled het stylesheet, dus er kunnen zeker nog wel dingen veranderd worden in de taxobox zelf (zie Cascading Style Sheets#Prioriteit). In die zin wordt er door toevoegingen aan het monobook-stylesheet helemaal niets onveranderbaar gemaakt. Het enige wat er wordt gedaan is de afgesproken en gebruikte styles te verhuizen naar een andere (algemene) plek.
  • Niet alle skins maken gebruik van monobook. Keuls Blauw bijvoorbeeld niet. Dus om rare effecten te voorkomen moeten dergelijke aanpassingen in alle stylesheets worden doorgevoerd.
  • Niet overal worden de taxobox-sjablonen toegepast, in sommige gevallen staat er nog steeds gewoon een handgemaakte tabel, zonder css-classes. Bijvoorbeeld op de eerste pagina die ik bekeek Merel. Op dergelijke pagina's is dus nog geen enkel effect van de aanpassingen te merken. Dat is natuurlijk een kwestie van tijd, en misschien niet zo'n zwaarwegend argument.
Taka 22 jun 2005 08:37 (CEST)
In plaats van in een stylesheet kan je dingen ook gewoon op een voor iedereen bewerkbare plek doen. Namelijk gewoon sjabloon:xxxxxx in plaats van een oplossing dat het niet voor iedereen vrij bewerkbaar is. Daarnaast als de tags niet al opgenomen worden zullen de meeste mensen niet weten wat te doen nog waar te vinden waar het dan wel bepaald wordt en opgeven. Verder weet ik het niet zeker maar keulsblauw enz waren niet te veranderen. Dus gaat het dan inderdaad vreemde effecten geven. Deze "oplossing" vind ik uitermate gebruikersonvriendelijk, beperkend en rechtstreeks indruisend tegen de principes van vrij bewerkbaar voor iedereen. Waerth©2005|overleg 22 jun 2005 08:47 (CEST)
Daarnaast refereer je naar het artikel Cascading Style Sheets en niet naar een wikimedia uitlegpagina. Is het in wikimedia ook op die manier gebruikt? Dat een tag door een gebruiker voorrang krijgt boven een van boven opgelegde tag?

Waerth©2005|overleg 22 jun 2005 08:45 (CEST)

Geloof me nou maar dat een style aangegeven in de tag zelf de style van de class overrules. De class "printfooter" is alleen zichtbaar bij de printversie van een artikel. Dus <div class="printfooter">Hiet staat tekst</div> is niet zichtbaar. Maar <div class="printfooter" style="display:inline">Hiet staat tekst met een style in de tag</div> is wel zichtbaar. Zoals je hieronder kan zien.


Hiet staat tekst
Hiet staat tekst met een style in de tag

Taka 22 jun 2005 09:01 (CEST)

En wat is het voordeel om het hard erin te programmeren? In plaats van gewoon zo in een sjabloon?
  • Gewoon in een sjabloon = voor iedereen bewerkbaar en meteen inzichtbaar en duidelijk waar je wat moet veranderen = Wikipedia voel je vrij ga je gang
  • In monobook.css = niet voor iedereen bewerkbaar niet meteen inzichtbaar als je niet weet waar het staat niet duidelijk waar je wat moet veranderen = niet Wikipedia voel je vrij ga je gang
Misschien dat zo mijn onoverkomelijke bezwaar duidelijk is. Het voorstel legt iets op en maakt het niet makkelijk veranderbaar. Terwijl als je het in een sjabloon zet iedereen het kan veranderen. Waerth©2005|overleg 22 jun 2005 09:39 (CEST)
Daar ben ik het 100% mee eens. De sjablonen waren zelf trouwens de opmaat tot een Wikipedia-voor-ingewijden, want die zijn eigenlijk ook al erg ondoorzichtig (ik kom er niet aan). Ik weet niet hoe optimistisch ik mag zijn: als iets kan op Wikipedia, gebeurt het immers vroeg of laat toch wel, is mijn ervaring. En als het eenmaal ergens gebeurt, dan lijkt het overal te moeten. Of ben ik te negatief? Fransvannes 22 jun 2005 09:55 (CEST)
Ik wil je als je eens op IRC komt best een korte les geven in editten van sjablonen. Het is heel erg makkelijk in principe. Waerth©2005|overleg 22 jun 2005 09:59 (CEST)
Ik heb geen chatambities, maar ik hou me aanbevolen voor zo'n les. Is er al iets over te vinden in de Help:-naamruimte? Fransvannes 22 jun 2005 10:56 (CEST)
Ik kan niet alles overzien. Maar een rijtje voor- en nadelen.
Voordelen
  • Een afgesproken standaard vastleggen, dat kan natuurlijk ook in het sjabloon zelf, maar dit is een hogere graad van vastleggen. Ik wil me nu onthouden een mening of de gemaakte afspraken zo beton zijn dat ze deze graad van vastlegging verdienen, maar dat is wel een belangrijk punt. Een opmerking is bijvoorbeeld dat de kleur van de th voor organismen in verschillende rijken anders is: bij dieren pink, bij planten lightgreen.
  • Een klein cache voordeel, de stylesheet wordt gecached door de browser, dus dat scheelt bandwidth.
  • Het is eleganter om vastliggende styles in een stylesheet te zetten dan om de style elke keer te noemen. Noem het een goede manier van webdesign.
  • Ingelogde gebruikers kunnen met aanpassingen aan hun eigen stylesheet een eigen layout maken. Daar moet dan ook goed over worden nagedacht welke mogelijkheden er geboden worden. Ik denk bijvoorbeeld aan het weglaten van de rang-vermeldingen: als iemand die niet wil zien, dan kunnen die bv een eigen class worden toegekend, en de gebruiker kan in zijn eigen stylesheet alles van die class onzichtbaar maken.
Nadelen
  • Moeilijker te wijzigen, namelijk alleen door moderatoren (daar zit een hele discussie achter, want misschien is dat ook wel wenselijk). Dat wil niet zeggen dat dingen nu een hogere graad van bescherming tegen vandalisme hebben. Het wijzigen van de classname in het sjabloon zorgt er bijvoorbeeld voor dat de vastgelegde style niet wordt toegepast, en met het style attribute kan nog van alles worden aangepast - maar dat zou niet de bedoeling moeten zijn, want dan vervallen alle voordelen).
  • De vraag of dit nu voor alle "boxen" moet gaan gebeuren, bijvoorbeeld ook voor die van bedrijven en gemeenten en wie weet wat nog meer. Is het misschien niet beter om een generieke box te maken en die in het stylesheet te zetten.
  • monobook wordt niet in alle gebruikers-stijlen gebruikt, bijvoorbeeld niet in Keuls Blauw en dat levert toch een consistentie probleem op.
Er is ongetwijfeld meer over te zeggen. Ik denk ook dat het goed is om deze discussie te verplaatsen naar een andere plek.
Taka 22 jun 2005 10:12 (CEST)
Maar naar welke dan? Naar een die over styles gaat, of naar een die over de privileges van moderatoren? Want in nadeel 1 ligt de crux: er komen A-gebruikers en B-gebruikers. Kennelijk is dan een implicatie van deze manier van vastleggen. De vraag of we dat willen moet eerst door de gemeenschap beantwoord worden. De "hele discussie" daarover moet dan ook als eerste plaatsvinden. Dat geeft misschien een richting voor de verplaatsing aan. Fransvannes 22 jun 2005 10:51 (CEST)
Persoonlijk vind ik de privilege kant van de zaak niet het belangrijkst. Ook het design van de taxoboxen is tot stand gekomen in een soort van consensus, en ook hiervan is het niet de bedoeling dat een individuele gebruiker op eigen houtje hierin aanpassingen gaat doen. Daarnaast, zoals ik al heb aangegeven, blijft het nog steeds voor een individuele gebruiker mogelijk om aanpssingen te doen, omdat het style-attribuut (wat nog steeds door iedereen aangepast kan worden) prioriteit heeft over datgene wat in de algemene stylesheet staat. Maar als de privilege kwestie in deze zaak (door wie dan ook en om welke reden dan ook) als belangrijk wordt beschouwd, dan is het natuurlijk logisch om ook hierover overleg te voeren. Het zijn ook twee aparte dingen. Het probleem is natuurlijk dat de wikisoftware simpelweg bepaalt dat er wat dit betreft A- en B- gebruikers zijn. Want alleen moderators kunnen de standaard-stylesheet aanpassen. Maar nogmaals: het lijkt me goed om eerst over privilege-kant van de zaak te beslissen als daar behoefte aan is. Daar zou bijvoorbeeld kunnen uitkomen dat we simpelweg geen toevoegingen aan de standaard-stylesheet doen, of alleen na een duidelijke consensus, of.... noem maar op. Taka 22 jun 2005 11:27 (CEST)

In principe ben ik het met Waerth eens dat stijlen voor iedereen bewerkbaar moeten zijn. Toch heb ik besloten een verzoek in te dienen voor het plaatsen van de code in monobook.css, en wel om de volgende redenen (nu wordt het technisch):

  • In een stylesheet is het mogelijk een constructie te maken in de trant van: table.taxobox tr { ... }. Hiermee leg je een stijl vast voor elk tr-element in de taxobox. Door te werken met stijl-tags in het sjabloon moet voor elk tr-element de betreffende stijl herhaald worden, hetgeen een hoeveelheid extra code met zich mee brengt.
  • In een stylesheet is het mogelijk de opmaak van "thumb"-plaatjes (met een grijs kadertje) vast te leggen. Wordt zo'n "thumb"-plaatje in een taxobox gebruikt, dan ziet dat er op dit moment niet mooi uit, omdat er al een kader om de taxobox staat, met als gevolg een dubbel kader. Daarom wordt er op dit moment een (omslachtige) code gebruikt om toch en onderschrift onder een plaatje te kunnen plaatsen zonder dat er een kader omheen komt (zie Sjabloon:Taxobox image). In de stylesheet zou ervoor kunnen worden gezorgd dat "thumb"-plaatjes in een taxobox geen kader krijgen, zodat deze gewoon gebruikt kunnen worden. Ook dit levert een besparing van code op.

Ik besef dat dit details zijn waarvoor de meesten zich niet interesseren, maar helaas zijn het wel details die ik niet kan aanpassen door gewoon in het sjabloon te werken. Vandaar mijn verzoek. Maar goed, het is ook geen ramp als dit sommigen te ver gaat.

Rex 22 jun 2005 11:29 (CEST)

Ik denk dat het probleem met andere uiterlijken, (Standaard, Keuls blauw, ...) eerst opgelost moet worden. Danielm 22 jun 2005 13:32 (CEST)
Kwestie van even de CSS-aanpassing voor monobook te kopieren naar de andere stijlen. Zo te zien kane r weinig misgaan: geen absolute positionering, geen CSS-IE-hacks... -Lars- 22 jun 2005 14:52 (CEST)
Ik ben hier op tegen dit soort dingen dient ten alle tijden via sjablonen opgelost te worden. Zodat ze vrij zijn van iedereen. Geen enkele van de voordelen lijken me groot genoeg om op te wegen tegen de nadelen. En standaard? Welke standaard? Volgend jaar is er misschien een groep mensen die het wil wijzigen. Tegen elke vorm van harde vastlegging. Het is anti wikipediaans. Waerth©2005|overleg 22 jun 2005 20:10 (CEST)

[bewerk] KROEG

Verwijderde stijl door Elly op verzoek van een aantal mensen op 5 okt 2005 15:10 (CEST).

/* De Kroeg */
#kroeg h2 { 
    font-size: 120%; 
    font-weight: bold;
    background: #F4EAD7;
    border-bottom: none;
    padding-top: 0.3em;
    padding-bottom: 0.3em;
    padding-left: 0.5em;
    padding-right: 0.2em;
    border: 1px solid #CA993E;
}
#kroeg div.editsection {
    margin-top: 0.3em;
    margin-right: 0.2em;
    padding-right: 0.3em;
    padding-left: 0.5em;
    font-size: smaller;
    background: none;
    color: #F4EAD7;
}
#kroeg h2 a {
    text-decoration: underline;
}
#kroeg div.editsection a:hover {
    text-decoration: underline;
}
#kroeg h2,
#kroeg h2 a:link,
#kroeg h2 a:visited,
#kroeg h2 a:active {
    color: #000000;
}
#kroeg div.editsection a:link,
#kroeg div.editsection a:visited,
#kroeg div.editsection a:active {
    color: #002bb8;
}
 
THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu