Wikipedia:SHEIC/Archief/2012-12

Infobox over de volle breedte in pdf[bewerken | brontekst bewerken]

Ik dacht ik ga "mijn" etalageartikel Kanaal van Corbulo eens op pdf afdrukken. Blijkt dat het Sjabloon:Infobox kanaal aan de bovenkant over de volle breedte van de pagina wordt gerenderd. Is dit een bekend probleem? Hans Erren (overleg) 4 dec 2012 22:39 (CET)[reageren]

We hebben helaas niet veel effect op wat de pdfmaker er van bakt. Lastig. Romaine (overleg) 8 dec 2012 00:19 (CET)[reageren]

Hulp bij referenties[bewerken | brontekst bewerken]

Een aantal verwijzingen werken op de een of andere manier niet op het artikel bunzing, zie onder -bronvermelding- . Zou iemand hier eens naar kunnen kijken want ik kom er niet uit. -B kimmel (overleg) 11 dec 2012 22:38 (CET)[reageren]

Het lijkt er op dat een aantal keer http:// ontbrak. Is het probleem nu opgelost? Romaine (overleg) 11 dec 2012 22:47 (CET)[reageren]

Bedankt, dat was het inderdaad. Dat vergeet ik ook nooit meer... -B kimmel (overleg) 11 dec 2012 23:19 (CET)[reageren]

Titel-item-sjabloonprobleem[bewerken | brontekst bewerken]

Onderstaande verplaatst vanaf Overleg gebruiker:RonaldB.

Hallo RonaldB, Het sjabloon Sjabloon:Gesproken Wikipedia klein heeft een probleem sinds een software-update. Klik op menu en er klapt slechts een smalle zwarte rand uit in plaats van het volledige kader bij Sjabloon:Gesproken Wikipedia. Na diverse tests kan ik niet anders dan tot de conclusie komen dat het invoegen in de titelsectie rechtsboven een pagina het probleem is. Het coördinaten-sjabloon dat ook een uitklap heeft kent dat probleem niet. Heb jij enig idee waarom het niet goed lukt en kun je dat repareren? (Zo te zien zowel probleem in FF als IE.) Dank alvast! Groetjes - Romaine (overleg) 16 dec 2012 22:42 (CET)[reageren]

Dag Romaine

Kostte me even wat tijd, want ik ben nog bezig een nieuwe PC volledig in te richten.

De oorzaak moet vermoedelijk gevonden worden in het feit dat bij klein de (class) mediacontainer, gegenereerd door het .ogg bestand, op zich in een div staat. Maar die staat in een table, die op zijn beurt weer in een div staat. Nu is die laatste div bij klein niet hoog en dus zal de table nooit hoger kunnen zijn dan de div waar die inzit. En dat vormt de beperking voor het uitklappen.

Doe bij klein maar even een test met height:400px o.i.d. voor de overkoepelende div en het werkt goed.

De conclusie is dan dus dat er een andere constructie gevonden moet worden ter vervanging van de table. Kijk maar eens of je tot dezelfde conclusie komt, dan denk ik morgen of zo wel weer mee. - mvg RonaldB (overleg) 17 dec 2012 02:23 (CET)[reageren]

P.S. Ik zie vaker bij dit soort sjablonen allerlei gedoe om iets rechtsboven geplaatst te krijgen. Nu is het alweer een tijdje geleden dat ik me intensief met html heb beziggehouden, maar vraag me af of het niet robuuster is om een soort algemene wrapper te maken, incl. de nodige metric, met toepassing van een z-order attribute. Dan heb je m.i. veel beter in de hand waar het ding terecht komt.

Hallo RonaldB, Zoals ik hierboven al schreef, ik heb het uitgetest zonder tabel en puur een div met daarin alleen een class Top_icon_raw en toen ging het ook fout. Zonder deze class werkt het met tabel wel en met div ook prima. Als ik in Gesproken Wikipedia klein de class Top_icon_raw weghaal en in de plaats daarvan style="position:absolute; right:14px; top:-25px;" gebruik, werkt het ook prima. Ik kan dus met html/css zorgen dat het uitklapgeval in de speler goed werkt. Echter zal dit gaan conflicteren met andere icoontjes rechtsboven, waarvoor we de class Top_icon_raw hebben die ervoor moet zorgen dat die icoontjes netjes naast elkaar staan. Het probleem ligt volgens mij dus niet in de html/css maar in MediaWiki:Common.js danwel MediaWiki:Common.css door de eigenschappen die die class aan dit icoontje meegeeft. Groetjes - Romaine (overleg) 17 dec 2012 03:08 (CET)[reageren]

Hoi Ronald, Romaine,

Romaine vroeg me even naar dit probleem te kijken. Het is als volgt. Top_icon_raw plaatst de elementen in de .firstHeading met float in plaats van position (zodat iconen altijd netjes naast elkaar staan). Het probleem wordt veroorzaakt doordat .firstHeading overflow: hidden; heeft. Dit is al heel lang zo. Voorheen was het zo dat de speler geen menu had, dus was dit geen probleem. Nog eerder was sjabloon "klein" geen speler, maar een icoon met link naar onderaan het artikel (waar de grote versie van het sjabloon was, met speler). In ieder geval, overflow is niet toegestaan vanuit de headings.

Kijkende naar de bredere situatie zie ik nog 2 andere problemen:

Er ontbreekt een link naar de bestandspagina. Dit is in conflict met de licentie vereisten. Het is verplicht bij de media (een link naar) licentie en auteurs informatie te vermelden.
Er ontbreekt gebruikersinformatie. Er staat een joekel van een speler met een Play knop boven aan de pagina (het woord "Beluister" linken naar een pagina over Gesproken Wikipedia doet al veel goed).

Ik raad aan om deze twee redenen, en het feit dat het Menu niet zichtbaar is, de oude situatie te herstellen ("klein" is geen grote speler maar een klein "Gesproken Wikipedia" logo icoon (met tooltip over wat het is), linkende naar het eind van de pagina waar de speler is met tekst en uitleg).

Ik neem aan dat de huidige situatie is ontstaan omdat de oude situatie niet (meer) gewenst was, echter kan ik sterk aanraden (vooral voor de gebruikersvriendelijkheid) om toch te overwegen of de oude situatie niet beter was. Hoedanook, er moet een verandering komen i.v.m. de licentie vereisten die nu geschonden worden.

–Krinkle 17 dec 2012 18:54 (CET)[reageren]

De bestandspagina moet inderdaad duidelijk bereikbaar zijn. Je zou denken, Sjabloon:Coördinaten heeft een uitklapkaart, dan zou zoiets ook wel mogelijk moeten zijn. Voorlopig heb ik in ieder geval een info-link naar het bestand toegevoegd, een summary ingevoegd in de broncode zodat het beter te lezen is voor slechtzienden en wanneer iemand met de muis boven Beluister gaat staan verschijnt er ook tekst. Groetjes - Romaine (overleg) 17 dec 2012 19:11 (CET)[reageren]

Misschien is deze discussie beter op zijn plek op WP:SHEIC, ons technische overlegpagina. Voel je vrij het te verplaatsen. Romaine (overleg) 17 dec 2012 19:11 (CET)[reageren]

Bovenstaande verplaatst vanaf Overleg gebruiker:RonaldB.

ogg bestanden[bewerken | brontekst bewerken]

Zie hier en dan met name mijn analyse onderaan.

Om zelf te testen wat een groot deel van de bezoekers (met IE) krijgt te zien als ze een artikel met een .ogg bestand openen (dus b.v.Amsterdam, maar ik stuitte vanavond bij de anon controle met mijn nieuwe machine op DekaMarkt en zo zijn er natuurlijk vele), moet je een tamelijk maagdelijke Windows installatie hebben. Dus geen RealPlayer of iets anders. Afgezien van tekst rechts, krijg je ook nog eens een security warning die vermeldt dat de website Java SE Runtime wil runnen. Die staat er bij mij op, maar ik heb de security settings van IE nog op default staan.

Is mij op mijn oudere machines nog nooit opgevallen, want als wat meer gevorderde gebruiker verzamel je in de loop van de tijd natuurlijk heel wat players en codecs. - mvg RonaldB (overleg) 19 dec 2012 02:15 (CET)[reageren]

De eerste regel van de tekst van Amsterdam kwam niet meer in zicht toen ik Amsterdam opende in deze browser (IE9; 1024x768) op m'n werk. Dit lijkt mij inderdaad niet een goede situatie. Persoonlijk maken mijn wenkbrauwen hele rare bewegingen als ik zie dat een site java wil starten en ik geen flauw idee heb waarvoor. Een click-to-play, die het applet pas laadt als de gebruiker klikt dat hij het bestand wil afspelen is beter imo. Je krijgt weliswaar de waarschuwing te zien, maar het voelt natuurlijker aan waar die vandaan komt.

Wat betreft het uitrekken van het bericht is 'position:absolute' denk ik de enige 'oplossing'. Het is de enige css-regel die in m'n hoofd opkomt die totaal geen rekening houdt met de positie of ruimte van andere elementen buiten dat element. De tekst komt dan over het artikel te staan, maar dat kun je oplossen door een optie te maken waarmee je de tekst kan verbergen.

Ik zal eens kijken of ik wat kan experimenteren met dat spul. Het viel me trouwens op dat we nog 39 andere sjablonen voor het afspelen van geluid hebben. Dat lijkt me rijkelijk veel. Sum ^?urai8^? 21 dec 2012 22:22 (CET)[reageren]

MerlIwBot (IW false positives vlaggen)[bewerken | brontekst bewerken]

Hai, even naar aanleiding van de discussie hier: is er een systeem voor te stellen waarbij medewerkers hardnekkige false positives van interwikibots kunnen vlaggen? (bijv het bijwerken van een pagina in de gebruikersruimte van een bot). Sommige bots gebruiken een wat aggressief algorithme, hetgeen leidt tot een wat grotere frequentie van foute interwikis. Blokken of innemen van botbitje lijkt me geen optie, daar deze bot ook veel goede zaken oppikt, maar een systeem om terugkerende foute connecties te voorkomen lijkt me handig. Milliped (overleg) 25 dec 2012 14:10 (CET)[reageren]

Als hij een niet-standaard programma ('bot') gebruikt waardoor fouten vaker voorkomen dan dat bij de standaard pywikipedia-interwiki-bots het geval is, dan moet hij die wijzigingen niet met botflag uitvoeren. Hij kan ze of zonder botflag doorvoeren (botaccounts kunnen ook wijzigingen doen die niet als botbewerking gemarkeerd zijn), of hij moet geen wijzigingen doorvoeren maar suggesties op een daarvoor geschikte plaats (overlegpagina's, projectpagina) neerzetten die dan na controle doorgevoerd kunnen worden. MrBlueSky (overleg) 25 dec 2012 17:26 (CET)[reageren]