Wikipedia:De kroeg/Archief/20220622

Vertalen

Zojuist een bericht ontvangen op mijn overlegpagina met de vraag om verschillende dingen te vertalen voor de nieuwe interface. Het zou handig zijn als ervaren gebruikers dit doen, aangezien ik hier amper ervaring mee heb. ✔ Rots61 Overleg 8 jun 2022 20:09 (CEST)

---

Hello, I'm Szymon, member of the team working on the Desktop Improvements/Vector 2022 project. I need two things translated into Dutch:

1. Two banners - a tiny thing, 5 short lines of text. We'll put a banner encouraging to switch to Vector 2022 on all projects (sister projects, etc.), and another one encouraging to share feedback.
2. An announcement - that one's longer and could take, I think, up to half an hour. I'd be tremendously grateful if you found some time. I'd rather not send it in English, and unfortunately, there are not many helpful and active translators.

On a side note, later, perhaps next week, there will be another thing ready - an instruction for prototype testing. We'll ask volunteers what visual design they'd like to see on wikis. Feel free to check this all out!

Thank you in advance. SGrabarczuk (WMF)

---

Gekopieerd van overlegpagina van Rots61

Inmiddels vertaald. --Strepulah (💬) 10 jun 2022 11:32 (CEST)

De vraag is natuurlijk wel een beetje waarom de WMF ondanks de gigantische zak geld waarop ze zitten continu blijft bedelen bij mensen of ze even gratis professionele diensten willen leveren waarmee ze ook nog eens werk afsnoepen van de professionals. Natuur12 (overleg) 11 jun 2022 13:26 (CEST)

Ten eerste omdat Nederlands geen UN priority language is en de Nederlandse gemeenschap daarnaast nooit duidelijk heeft aangegeven dat ze liever de berichten toch wel al vertaald ontvangen. Sterker nog: op de vertalingen die werden gedaan was in het verleden altijd commentaar en de WMF en degenen die de vertalingen deden konden het nooit goed genoeg doen. Het houdt natuurlijk ook een keertje op stel ik me zo voor. Ciell need me? ping me! 11 jun 2022 13:50 (CEST)

Ik volg je even niet, er is inderdaad kritiek geweest op vertalingen in het verleden, maar ook toen ging het voor zover ik weet niet om berichten die door een professional vertaald zijn. Dat er sprake van peer feedback is, dat zou overigens alleen maar gunstig moeten zijn. Maar dat NL geen UN priority language is doet toch niets af aan het beschikbare aanbod van professionele vertalers? Er zijn er genoeg. Maar zo raar is wat ik zeg toch niet? Dat het wel zo fatsoenlijk is dat voor professionele diensten (waaronder vertaaldiensten in een semi-commerciële setting) gewoon een eerlijke vergoeding betaald wordt? We hebben het hier over een foundation met een goed budget die een professionele dienst vraagt, gratis. Buiten de Wikimediabubbel zou zoiets ongehoord zijn. Natuur12 (overleg) 11 jun 2022 14:19 (CEST)

Maar als er vanuit ons nooit om vertalingen gevraagd is, hoe moet de WMF dat dan weten?

Vanuit de MCDC gaan we naast de zes UN priority languages (wat nog vrij nieuw is dat die standaard door de WMF ondersteund worden), ook naar het Braziliaans Portugees vertalen op verzoek van de mensen van het chapter en de Braziliaanse gemeenschap. Wikimedia projecten bestaan in 300+ talen, die kun je zelfs met de grootste zak geld niet standaard allemaal dekken en moet je ook zeker niet proberen als zich daar ook al mensen op vrijwillige basis voor hebben aangeboden, of dit al eerder hebben gedaan (wat volgens mij de aanleiding is voor Szymon van de WMF om actief deze mensen te benaderen). Naast dat er wel professionele vertalers zijn, is het ook nog een kunst om movement-specific termen (termen die binnen onze beweging een specifieke betekenis hebben en niet één op één vertaald kunnen worden) goed te kunnen vertalen: niet iedere vertaler kent deze, maar onze vrijwilligers juist weer wel. Ciell need me? ping me! 12 jun 2022 21:42 (CEST)

@Ciell: dank voor de verduidelijking. Nu kan ik je opmerking over de UN priority languages wel volgen. Ik denk dat we een fundamenteel verschil van opvatting hebben in hoeverre je professionele diensten kan vragen aan vrijwilligers. Standaarddekking is verder ook niet noodzakelijk omdat het merendeel van de berichten die vertaald worden voor een breed publiek helemaal niet zo interessant zijn. De mensen die wel interesse hebben in "technische berichten" zullen vermoedelijk toch wel het Engels machtig zijn. En het vragen om vertalingen in het Nederlands, sja... Heel eerlijk, volgens mij wordt er alleen maar zo nu en dan in de kroeg om gevraagd omdat het kan. Niet omdat het nodig is. Maar dit staat verder los van mijn punt dat het buiten WP ondenkbaar zou zijn dat je als vermogende foundation gratis om professionele services loopt te bietsen. Natuur12 (overleg) 14 jun 2022 22:16 (CEST)

Woordenboek-sjabloon in artikelen

Onze beste collega Arx - 83 plaatst in veel artikelen een woordenboek-sjabloon. Dat zal toch niet de bedoeling zijn? ErikvanB (overleg) 6 jun 2022 15:07 (CEST)

Toevallig dacht ik er juist over om voor te stellen sjabloon:woordenboek geheel af te schaffen en door te verwijzen naar sjabloon:wikt klein. Het eerste is namelijk onfunctioneel, door alleen een hoofdletter W weer te geven, die de gemiddelde lezer slechts zal interpreteren als de W van Wikipedia. Wickey (overleg) 6 jun 2022 15:32 (CEST)

Beide sjablonen doen wat anders: die van Arx-83 laat een link in de linkerbalk en een W rechtsboven zien en die van Wicky een klein sjabloon. Beide zijn op dit moment hoe we het doen, omdat de link niet in Wikidata mag staan. Ik zou daarom niet weten wat er niet de bedoeling aan is. Ymnes (overleg) 6 jun 2022 16:29 (CEST)

Nou, bijvoorbeeld Gereedschap linken aan het woordenboek. Waarom? Een encyclopedie en woordenboek zijn twee aparte dingen, en bovendien is 'gereedschap' geen moeilijk woord. We linken al zo veel in lemma's: naar Commons, naar bibliografische informatie, naar geografische kaarten (coördinaten), naar Wikiquote, naar Wikisource... ErikvanB (overleg) 6 jun 2022 17:15 (CEST)

Ik kijk alvast uit hoe relevante sjabloondocumentaties zullen evolueren (Sjabloon:Woordenboek, Sjabloon:Wikt, Sjabloon:Wikt klein, Sjabloon:Zusterproject, Sjabloon:Zusterproject klein, ...). Is er een leidraad voor gradatie van moeilijkheid der woorden? @ErikvanB, dank u om deze discussie te openen. Hopelijk verduidelijkt spoedig veel. Arx - 83 (overleg) 10 jun 2022 14:21 (CEST)

Die link in de linkerbalk had ik nog niet eens gezien; gaat volgens mij ook via wikidata. Afgezien van mijn eerdere opmerking vind ik positionering naast de titel ook niet goed. Wickey (overleg) 6 jun 2022 19:13 (CEST)

Bij nader inzien, lijkt me het voorstel van @Wickey om Sjabloon:Woordenboek af te schaffen goed. De betreffende "W in de rechter bovenhoek van de pagina", zoals "doel" stipuleert in "sjabloondocumentatie", zie ik niet op pagina's van Wikipedia's mobiele versie. Hopelijk merk ik binnenkort aanpassingen in sjabloondocumentaties omtrent bedoelingen van Sjabloon:Wikt en Sjabloon:Wikt klein zodat we dit met voortschrijdende inzichten toepassen. Dank alvast voor jullie wijsheid. Arx - 83 (overleg) 9 jun 2022 18:13 (CEST)

Je bedoeling was in ieder geval goed. Het viel mij ook al op dat de documentatie schittert door afwezigheid. Die zou eigenlijk verplicht moeten zijn. Ik zal het eens aankaarten bij Frans Timmermans.

Eén van de weinige nuttige toepassingen van Wikt klein is in een hoofdstukje over de etymologie van een bepaalde term. Wickey (overleg) 10 jun 2022 13:02 (CEST)

Op Sjabloon:Woordenboek staat – in het rood – de reden dat dit in bepaalde gevallen beter werkt dan Sjabloon:Wikt. Iets duidelijker uitgelegd: op Wikiwoordenboek is het zo dat alle betekenissen van een woord(vorm) in alle mogelijke talen op één en dezelfde pagina staan, ook als het gaat om verschillende woorden in verschillende talen die afgezien van de toevallig identieke geschreven vorm niets met elkaar te maken hebben. In zo'n geval is het handig en veel overzichtelijker als er vanaf hier meteen naar de juiste sectie (die over het Nederlands) in het woordenboek gelinkt wordt.

Het eerstgenoemde sjabloon dient dus niet te worden afgeschaft. Een andere mogelijke oplossing is dezelfde functionaliteit inbouwen in het andere sjabloon, maar ik zie niet echt een noodzaak daartoe (behalve als men per se van het eerste sjabloon af zou willen). De Wikischim (overleg) 6 jun 2022 19:25 (CEST) P.S. Ik herinner ook nog maar weer even hieraan. Tijdens die peiling is eveneens ter sprake gekomen dat er naar het woordenboek niet op de "normale" manier wordt gelinkt via Wikidata (waarom dat zo is, weet ik niet; ik neem aan iets softwaretechnisch). De Wikischim (overleg) 6 jun 2022 19:32 (CEST)

Op Sjabloon:Woordenboek staat ook dat het bedoeld is voor "eventuele kadersjablonen onderaan de pagina en/of boven de categorieën en defaultsort". Is er überhaupt overlegd over de wenselijkheid van dit sjabloon?

De peiling waar je hierboven naar linkt ging over de links in de zijkolom. Als dit niet goed functioneert moet het gewoon worden gestopt. De kwaliteit van de lemma's wisselt sterk. Voor interessante lemma's is sjabloon:wikt prima om te linken in 'Externe links' en sjabloon:wikt klein desnoods voor in 'Zie ook', hoewel dat eigenlijk niet de bedoeling is. Als Sjabloon:wikt klein niet goed functioneert kan dat inderdaad worden verbeterd. Ik zie niet daarnaast het bestaansrecht van Sjabloon:Woordenboek.

Deze pagina De Kroeg heeft zelf overigens een vrij merkwaardige WWb-woordenboekdefinitie. Wickey (overleg) 7 jun 2022 12:45 (CEST)

1. Pagina's in de meeste Wikimediaprojecten gaan over een bepaald onderwerp. De titel van zo'n pagina is louter bedoeld om aan te geven wat dat onderwerp is. Daardoor kunnen er meerdere mogelijkheden voor een paginatitel zijn en bestaan er pagina's die de lezer doorverwijzen als meerdere woorden hetzelfde onderwerp aanduiden of een woord juist op meerdere onderwerpen kan slaan. Daarnaast zijn er heel wat woorden waarvoor geen zinvolle pagina is te maken en heel wat onderwerpen die alleen met meerdere woorden (al of niet tussen haakjes) kunnen worden afgebakend.
2. De wiktionary's zijn buitenbeentjes, omdat hier de paginatitel hier direct het onderwerp vormt. Woorden met een overeenkomstige betekenis verwijzen wel naar elkaar, maar krijgen elk een eigen pagina, omdat bijvoorbeeld de uitspraak en afgeleide vormen als regel heel anders zijn. Doorverwijzingen zijn in de hoofdnaamruimte van WikiWoordenboek niet gebruikelijk. Voor een woordenboek is het niets bijzonders dat een woord meerdere betekenissen heeft. Bovendien zijn betekenissen in natuurlijke taal doorgaans een beetje vaag. Dat is geen bug, maar een feature: het maakt dat we elkaar toch kunnen begrijpen als we bestaande woorden gebruiken om iets nieuws uit te drukken. Een goede encyclopedische definitie probeert die vaagheid in te perken, zodat de lezer een duidelijke indruk van het onderwerp van artikel krijgt; een goede woordenboekomschrijving laat juist genoeg ruimte voor die vaagheid, zodat de lezer een beter besef heeft van de manieren waarop het woord gebruikt zou kunnen worden.
3. Het voorgaande verschil verklaart waarom de titels van de meeste Wikimediaprojecten vanzelf beginnen met een hoofdletter ("hoofdleterongevoelig zijn"): het gaat niet om een woord, maar om de naam van het onderwerp. Het verklaart ook waarom een Wikidata-item niet direct aan wiktionarypagina kan worden gelinkt. Dat zou hooguit kunnen naar een specifieke deelbetekenis op zo'n pagina, maar de structuur van wiktionary's leent zich daar niet voor. Op dit moment zijn automatische koppelingen tussen artikelen op Wikimediaprojecten en pagina's in wiktionary's daarom minder geslaagd. Een lezer mag van zo'n link redelijkerwijs verwachten dat dat die betrekking heeft op hetzelfde onderwerp, maar dat hoeft in helemaal niet zo te zijn. Om diezelfde reden is het in mijn ogen niet zo geslaagd om WikiWoordenboek mee te nemen in een rijtje links naar zusterprojecten, hoe die ook worden vormgegeven: alle andere links in dat rijtje hebben als het goed is betrekking op hetzelfde onderwerp, maar de link naar WikiWoordenboek gaat eigenlijk over het woord.
4. Het is goed voorstelbaar dat de lezer van een artikel (ook) behoefte heeft aan informatie over een woord. Daarom is het nuttig dat artikelen in Wikipedia ook links naar WikiWoordenboek aanbieden. Maar het is van belang om te laten zien die principieel een andere invalshoek hebben dan meer informatie geven over het onderwerp. De sjablonen {{wikt}} en {{wikt klein}} doen dat nu op een redelijke manier.
5. Het is nuttig om dit soort links een beetje doordacht (en dus niet volautomatisch) toe te voegen. Vroeger zijn er meermaals links geplaatst die verwezen naar pagina's die op WikiWoordenboek nog ontbraken of geen Nederlandse woorden beschreven. Omdat dit soort links automatisch blauw wordt weergegeven, is dat voor de lezer een teleurstellende ervaring, die ongemerkt lange tijd kan blijven bestaan. Of een woord "moeilijk" is lijkt me hierbij niet zo'n hanteerbaar criterium. Er is op WikiWoordenboek voor Nederlandse woorden nu gaandeweg een basisniveau ontstaan, waarbij er naast de betekenisomschrijving(en) minstens 1 bronvermelding is en een serie lexicografische gegevens (uitspraak, afbreking, genus, flexie, prevalentie) die gewoonlijk niet in een Wikipedia-artikel staan. De aanwezigheid van deze basiskwaliteit lijkt me een praktisch bruikbaar criterium om een link naar WikiWoordenboek toe te voegen.
6. De titel van het artikel is niet per se het enige woord waar de lezer belangstelling voor heeft. Bij zinvolle behandeling van één onderwerp kunnen meerdere termen worden besproken die daarna geen eigen artikel meer nodig hebben, maar uiteraard wel op verschillende pagina's in WikiWoordenboek staan. Het zou een verbetering zijn als een sjabloon de mogelijkheid biedt om in die gevallen meer woorden op te kunnen zoeken.
7. Ook de vormgeving heeft door de verschillende sjablonen het karakter van een allegaartje gekregen. In de linkerbalk is een plaats onder hulpmiddelen beter dan onder zusterprojecten om de redenen onder 3. genoemd. WikiWoordenboek heeft een favicon, dat wel in die links wordt gebruikt, maar in de sjablonen soms wordt vervangen door een W of een te ver verkleinde versie van het beeldmerk. MarcoSwart (overleg) 8 jun 2022 11:40 (CEST)

   Je hebt er een hoop woorden voor nodig, maar we lijken het er over eens te zijn dat het plaatsen van een link in de zijbalk via een bot niet zo'n goed idee is.

   In de wikt-sjablonen zouden eenvoudig parameters kunnen worden ingevoegd om te linken naar meerdere lemma's, zoals bij deze. Laat ik het nog simpeler houden. Hier is de Engelse sjabloon. Wickey (overleg) 9 jun 2022 13:11 (CEST)

   Het Engelse sjabloon is een goede oplossing voor de mogelijkheid om naar meer lemma's te linken. Om iets te doen aan het allegaartje lijkt mij de meest elegante oplossing om tot 1 sjabloon te komen dat redelijk in alle behoeften kan voorzien vervolgens de huidige sjablonen daardoor te vervangen en ten slotte na te gaan op welke andere artikelen het zinvol kan worden toegevoegd. Is er animo om dit in samenwerking op te pakken? MarcoSwart (overleg) 15 jun 2022 17:06 (CEST)

Foto van Anna van 't Hek

(1a) 19 april 2021, vanaf 19 april 2021 gebruikt

(1b) Dezelfde foto, maar uitgedeukt

(2a) 7 december 2020, vanaf 13 juni 2022 gebruikt

(2b) 7 december 2020, lichter gemaakt, nu als optie

Hoi,

Een tijdje geleden had ik de eerste versie van een artikel over Anna van 't Hek aangemaakt en haar management gevraagd of ze daar een foto bij hadden. Onlangs kreeg ik een mailtje van Anna, dat ze via de portal een nieuwe foto hebben geupload die ze graag willen gebruiken bij het artikel.

Zou iemand kunnen nakijken of de foto al is verwerkt? Anna vertelde dat de foto nog in de beoordelings-wachtrij stond.

Alvast bedankt!

24.132.139.187 12 jun 2022 11:47 (CEST)

Wanneer de foto is verwerkt, wordt deze als het goed is gelijk ook in het artikel geplaatst. Momenteel nog niet, voor zover ik het aan de 'buitenkant' van het proces kan zien. Encycloon (overleg) 12 jun 2022 13:25 (CEST)

Er is inderdaad correspondentie over een foto die op Wikiportret is geupload, maar dat is nog niet afgerond. Ik heb zojuist een herinnering gestuurd. Betreft ticket:2022060610012218 (alleen toegankelijk voor medewerkers van het Contactpunt). Groet, Elly (overleg) 12 jun 2022 13:26 (CEST)

Ik moet zeggen dat ik de nieuwe foto geen vooruitgang vind: de foto is donker en het gezicht komt beter uit op de foto uit 2021. Bovendien zie ik wel meer dat artiesten of hun management mee willen beslissen over welk image wordt uitgedragen. Niets mis met meer keuze uit Commons, maar ik moet mijn hoofd schudden als ik hoor dat mensen uit de naaste omgeving van de artiest "een nieuwe foto hebben geupload die ze graag willen gebruiken bij het artikel". Ik vind dat de Wiki-gemeenschap zelf mag beslissen welke foto gebruikt wordt. Vysotsky (overleg) 15 jun 2022 12:16 (CEST)

PS Bovendien is de zogenaamd "nieuwe" foto hoogstwaarschijnlijk een "oudere" foto: volgens de exif-data van 7 december 2020. Vysotsky (overleg) 15 jun 2022 12:31 (CEST)

Dat is inderdaad merkwaardig. Hoe kunnen wij dan in het artikel vermelden dat dit Anna van 't Hek in 2022 zou zijn? Gouwenaar (overleg) 15 jun 2022 14:21 (CEST)

Dat lijkt me een vraag voor Elly, die het jaartal aangaf. –bdijkstra (overleg) 15 jun 2022 14:26 (CEST)

Inderdaad is de nieuwe foto bepaalt geen verbetering. De oude dan weer terugzetten? Saschaporsche (overleg) 15 jun 2022 16:58 (CEST)

De nieuw aangeleverde foto is van december 2020 (zie ook de informatie bij de foto). De eerder gebruikte foto is van april 2021. De foto van 2021 is wat lichter. Maar de foto van 2021 heeft ook erg last van vertekening, zeker als je wat verder inzoomt. De neus is bepaald niet scherp, de wangen zijn glad, maar hebben ook wat vertekeningen. Het lijkt er duidelijk op dat bij die foto wat gebeurd is met het kleurenpalet, waar het eindresultaat bepaald niet beter van is geworden. Op de foto uit 2020 zie ik, ook bij het inzoomen, een natuurlijk gezicht. Nieuwer is zeker niet altijd beter. Ik zou voor de foto uit 2020 gaan, met een correctie van het bijschrift. Met vriendelijke groeten, RonnieV (overleg) 15 jun 2022 17:17 (CEST)

Ik ook, maar dan vooral omdat ze op de foto uit 2021 (de bovenste hiernaast) helemaal niet op zichzelf lijkt. Of, anders gezegd, als je kijkt naar de afbeeldingen van haar op Google Plaatjes, dan heeft er alle schijn van dat die foto uit 2021 een vreemd, vertekend beeld van haar uiterlijk geeft. — Matroos Vos (overleg) 15 jun 2022 17:54 (CEST)

Die bovenste foto lijkt horizontaal enigszins in elkaar gedrukt. Mbch331 (overleg) 15 jun 2022 18:00 (CEST)

Het lijkt me een uitsnede uit een opname met een (goedkope) lens die buiten het centrum nogal vervormt. –bdijkstra (overleg) 15 jun 2022 18:24 (CEST)

Zijbalk

Goedemorgen. Op mobiel zorgen zijbalken zoals {{Zijbalk politiek Nederland}} voor veel problemen. Het zorgt er soms voor dat kopjes verticaal gepresenteerd worden (dus alle letters onder elkaar ipv naast elkaar). Het neemt verder gewoon heel veel verticale ruimte in, waar je het ook plaatst. En het is nadrukkelijk op mobiel géén zijbalk. Is het mogelijk de weergave van zijbalken op mobiel te onderdrukken? En zo ja, vinden we dat wenselijk? Dajasj (overleg) 14 jun 2022 11:48 (CEST)

Ja dat is mogelijk via CSS. Onderdrukken lijkt me beter dan "veel problemen". –bdijkstra (overleg) 14 jun 2022 11:58 (CEST)

Ja, ook voorstander. Meeste zijbalken doen het op mobiel niet al te goed, qua opmaak, en ze zijn vaak redelijk lang. Dat is niet fijn, vooral ook omdat ze bovenaan in het artikel staan. --Strepulah (💬) 14 jun 2022 14:34 (CEST)

Maar die dingen zorgen bij andere mensen dus ook voor problemen, kunnen we ze dan niet beter automatisch uitschakelen bij mobiele apparaten zoals telefoons en tablets? Of is dat software-technisch gezien niet te doen? Dqfn13 (overleg) 14 jun 2022 16:16 (CEST)

<heel zachtjes>mogen ze misschien helemaal uitgeschakeld.... ik zie zoiets liever onderaan het artikel, zoals de navigatiesjablonen. Elly (overleg) 14 jun 2022 16:55 (CEST)

 Steun Dajasj (overleg) 14 jun 2022 17:04 (CEST)

@Dqfn13. Als ik mezelf, bdijkstra en Strepulah goed begrijp, dan is dat ook precies waar we het tot zoverre over eens zijn. Dajasj (overleg) 14 jun 2022 17:04 (CEST)

@Dajasj:, ik bedoel dat zonder css te doen, want niet-ingelogde gebruikers hebben geen css. Dqfn13 (overleg) 14 jun 2022 21:19 (CEST)

Bedoelen ze niet de websitebrede css ipv onze persoonlijke css? Of begrijp ik het dan verkeerd? Dajasj (overleg) 14 jun 2022 21:21 (CEST)

Is dat mogelijk dan? Dan zou één gebruiker een besluit kunnen nemen voor alle gebruikers, lijkt mij niet echt correct. Dqfn13 (overleg) 14 jun 2022 21:27 (CEST)

Is dat niet precies waar Wikipedia:Interfacemoderatoren voor op aarde zijn? "gebruikers die sitebrede CSS- en JavaScript-pagina's kunnen aanpassen" Dajasj (overleg) 14 jun 2022 21:32 (CEST)

Ahum, ik geloof dat ik goed heb op zitten letten. Dqfn13 (overleg) 14 jun 2022 22:15 (CEST)

Niet-ingelogde gebruikers maken net als ingelogde gebruikers gebruik van sitebrede CSS, nl. Common.css voor desktop en Mobile.css voor mobiel. Via persoonlijke CSS is die sitebrede CSS te overrulen, indien gewenst. –bdijkstra (overleg) 14 jun 2022 22:13 (CEST)

Je kan de class "nomobile" toevoegen en dat verbergt een element op de mobiele website. Of je gebruikt TemplateStyles om beneden een bepaalde scherm breedte de elementen te verbergen. Dat is nog beter, want dan werkt het ook voor mensen die een responsive desktop website skin gebruiken op hun mobiel. TheDJ (overleg) 15 jun 2022 13:34 (CEST)

Kunnen we de zijbalken niet gewoon allemaal weghalen? Ze zitten in de weg van de standaard-opmaak: infoboxen, eerste afbeelding, standaardbreedte. Lelijk en onhandig mi. Gewoon vervangen door normale navigatiesjablonen indien van toepassing. — Zanaq (?) 14 jun 2022 17:54 (CEST)

"Gewoon" even 1261 sjablonen vervangen. Áls we (wie?) dat gaan doen, dan is het verbergen een goede transitiestap, lijkt me. –bdijkstra (overleg) 14 jun 2022 18:02 (CEST)

Het zou al wel schelen als er consensus is dat ze vervangen mogen worden. Nu zou ik dat niet zo snel doen in het kader van BTNI. Dat het daadwerkelijke afschaffen dan verspreid is over tien jaar, zou ik geen probleem vinden. Dajasj (overleg) 14 jun 2022 18:08 (CEST)

 Steun Dat klinkt mij als een praktische en haalbare oplossing die goed kan uitpakken voor het web op de lange termijn. Ik vind het tof dat jullie hier nu over nadenken, het is belangrijk dat dit wordt aangepakt, zeker gezien de populariteit en toegankelijkheid van bezoekers die geen desktopomgeving gebruiken! Zouden we, al dan niet via extra commentaar, sjablonen, sitebrede CSS of iets anders kunnen zorgen dat alle sjablonen die nu nog zijbalken gebruiken iets tonen over eventuele plannen aan mensen die toevallig de betreffende sjablonen bewerken, als daar consensus over bereikt gaat worden? Dan is iedereen te allen tijde op de hoogte en kunnen ook mensen die niets afweten van deze discussie bijdragen door het omzetten van sjablonen wanneer ze er tegenaan lopen. Ogidya (overleg)Ogidya‍bijdragen‍overleg‍ 14 jun 2022 23:27 (CEST)

De zijbalken bieden soms informatie, soms navigatiemogelijkheden. Sjabloon:Zijbalk tramlijn M3 Antwerpen doet iets wezenlijk anders dan Sjabloon:Zijbalk computerspelrecensies, Sjabloon:Zijbalk Formatie van Aken of Sjabloon:Zijbalk navigatie Natuurkunde. De eerste heeft, bij omzetting naar een horizontale weergave een paar flinke uitdagingen. Een daarvan is de beperkte breedte van schermen (mobiel, maar ook van een laptop of PC). Daarnaast worden in dat sjabloon heel veel andere sjabloontjes gebruikt, en er zijn spoortrajecten waarin dat er nog veel meer zijn. Computerspelrecensies wordt deels binnen een tabel geplaatst, zodat het 'gewoon' in de lopende tekst gezet kan worden. Navigatie Natuurkunde is een mooie, want die fungeert als kapstok voor vele andere zijbalken. Als we dat sjabloon om weten te zetten, gaan er vele mee. De Formatie van Aken is een klein, overzichtelijk stukje (al viel een van de teksten bijna niet te lezen op mijn mobiel). Deze zou wat mij betreft niet omgezet hoeven te worden.

Wat misschien wel een snelle oplossing is, is het verplaatsen van de zijbalken naar onderen, zodat ze in de buurt van de navigatiesjablonen komen te staan (wellicht voorlopig nog net erboven). Op die manier heeft iedereen op een PC en op een mobiel er iets aan: de navigatiemogelijkheden en de informatie blijven beschikbaar, maar ze verstoren niet de lopende tekst. Nadeel is dat we op tig pagina's het gebruik van deze sjablonen moeten gaan controleren (ze mogen bijvoorbeeld niet in een tabel staan, zoals de computerspelrecensies), en daarna al deze pagina's moeten bewerken. Mooie klus voor een robot.

Als we gaan omzetten zou ik voorrang geven aan sjablonen als Navigatie Natuurkunde, omdat die daadwerkelijk om de navigatie gaan. Idealiter hebben we iets waarmee we het sjabloon gewoon kunnen laten staan, alleen op de mobiele weergave zorgen dat het heel ergens anders opduikt. Met vriendelijke groet, RonnieV (overleg) 15 jun 2022 12:47 (CEST)

Er zijn inderdaad nogal wat zijbalksjablonen die geen "Zijbalk" zijn in de zin van het bovenaan de pagina staan van een vooraf bepaalde vaste inhoud.

Door RonnieV gegeven voorbeelden zijn mi niet (allemaal) het soort Zijbalk waar het hier over gaat. De computerspelrecensies bevat dynamische inhoud die wellicht zo belangrijk is dat je het niet wil verbergen op mobiel, en staat niet bovenaan. De zijbalk natuurkunde lijkt meer op een infobox. De ov-lijnen zouden mi beter toegevoegd kunnen worden aan een infobox. Formatie Aken lijkt op diverse fronten een vaag ding.

Het voorstel is om de bedoelde Zijbalken naar Navigatiesjablonen om te zetten. Voor andere "Zijbalken" (die geen mi Zijbalk zijn) zijn andere oplossingen, maar deze zijn in veel gevallen minder problematisch (hoewel in de meeste gevallen mi ook suboptimaal). — Zanaq (?) 15 jun 2022 13:14 (CEST)

Op de Engelse Wikipedia hebben ze een css class waarmee je kunt zorgen dat een onderdeel van een pagina niet in de mobiele versie getoond wordt, zie en:Template:If mobile. Behanzane (overleg) 14 jun 2022 18:47 (CEST)