Wikipedia:SHEIC/Archief/2010-07

Plakkende tekst

Hoe zorg je ervoor dat, wanneer gekozen is voor het links plaatsen van afbeeldingen, de tekst niet tegen de rechterrand van de afbeeldinglijst plakt. Met html? met een div? Ik wil het goedgemaakt zien in Johann Wolfgang von Goethe zonder dat de afbeeldingen rechts gaan staan natuurlijk. Collegiale groet, --RobSchop [geef een gil!] 3 jul 2010 21:06 (CEST)

Door bij de afbeeldingen de optie "left" op te geven (ook als deze al in een linksgeplaatste {tl|wrapper}} staan). Ze worden dan links tegen de kantlijn geplaatst, en krijgen rechts een voldoende marge. - Erik Baas 3 jul 2010 21:25 (CEST)

Breedte van afbeeldingen resp. infoboxen

Om afbeeldingen even breed te tonen als infoboxen is destijds {{largethumb}} gemaakt, maar dat lijkt niet goed meer te werken, althans niet op Stein (gemeente)‎‎: het blijkt nu afhankelijk van schermresolutie (?) en ingestelde fontgrootte. En terwijl ik bezig was met onderzoek werd de pagina beveiligd, dus nu mag iemand anders het uitzoeken. - Erik Baas 8 jul 2010 11:08 (CEST)

Ik heb het vermoeden, dat niet de afbeelding (met largethumb), maar de infobox van breedte wisselt. Overigens is bij mij bij drie verschillende resoluties, met grote en kleine fonts, op XP en Vista, met FF en IE8 in alle gevallen het plaatje even breed als de infobox. M.vr.gr. brimz 8 jul 2010 11:49 (CEST)

Navigatie

Navigable TOC

Op deze bijdrage in de Kroeg kwam geen enkele reactie. Je mag toch verwachten dat als een bepaalde keuze in de voorkeuren wordt aangeboden, die keuze ook werkt na het aanvinken? Is er iets mee gebeurd wat ik gemist heb? Zoiets kan hier natuurlijk makkelijk als je niet alle dagen aanwezig bent...en dan nog! Graag een antwoord, collegae. Dank vooraf. RobSchop [geef een gil!] 18 jul 2010 23:46 (CEST)

Ik herinner me dat ik dat gelezen heb, maar ik heb (nog steeds) geen idee wat er bedoeld wordt met "Navigeerbare inhoudsopgave"... Is het een soms een feature van de vector-skin ? - Erik Baas 19 jul 2010 00:31 (CEST)

Ik heb op en.wiki dit gevonden. Inclusief een screenshot (zie ook hiernaast). Maar omdat ik ook niet wist dat dat bestond, en het nooit werkend heb gezien, kan ik er ook niet veel over zeggen. --Wimmel 19 jul 2010 18:51 (CEST)

Ja, Wimmel, die schermfoto klopt. En het werkte dus op onze nlwiki. Mijn lichte ergernis is nu: okee dat het niet meer werkt, maar dan moet het ook niet meer als een keuze in de voorkeuren staan. Ik neem aan dat jullie de weg kennen om die keuze te verwijderen of (beter) die toepassing weer te laten werken. 't Is wel iets uit de tijd voor vector: nog iets van monobook. Het staat helemaal onderaan bij voorkeuren/Bewerken: Navigeerbare inhoudsopgave inschakelen (Alphafunctionaliteit, ik begrijp dat de Bètafunctionaliteit erboven die bij mij uitgevinkt staat, verwijst naar vectorskin. Ik gebruik de extra bewerkingsknoppen onder Uitbreidingen: die en bèta sluiten elkaar uit, zo begrijp ik vermoedelijk goed.) 't Was wel handig hoor, probeer het zelf maar in de enwiki. Bij het bewerken kun je erg vlot naar bepaalde stukken springen, zeker bij langere artikels zoals hier in dit voorbeeldartikel over Obama.RobSchop [geef een gil!] 22 jul 2010 02:31 (CEST)

Dingen die niet beschikbaar zijn zouden idd geen voorkeurs opties moeten toevoegen. Ik heb Roan net weer gevraagd dit te repareren. Dit is een bekend probleem dat al een tijdje op de lijst van problemen staat, maar dat iedere keer het onderspit delft tov grotere problemen. Hopelijk haalt ie het vandaag wel :D TheDJ 22 jul 2010 19:06 (CEST)

Domeinomleiding

Ik heb enkele dagen geleden bit.ly ontdekt en vind het wel erg handig. Ik zocht nu hier en vond het korte artikel Domeinomleiding. Nu merk ik dat ik tinyurl ook al geregeld heb gezien. Ik gebruik die bit.ly nu een paar dagen zonder twitter. Twitteren interesseert me geenszins (Facebook is meer dan voldoende!), maar mijn vraag aan jullie is: wat is er in feite mis met zo'n domeinomleiding, want ik kreeg bij het opslaan in een OP een spammelding vanwege 2 niet-aanvaarde korte urls met bit.ly gemaakt? Het ging om verkortingen van mijn docs.google urls en ik heb die lange urls dan maar ingeplakt. Is er iets mis met domeinomleiding in 't algemeen of met bit.ly in het bijzonder? Ik ben te weinig nerd om dit te snappen. Ik snap wel dat omleiden van een IP-adres illegaal is, maar verkorten van een url? RobSchop [geef een gil!] 22 jul 2010 02:43 (CEST)

Bit.ly staat op de globale bloklijst. Waarom weet ik niet. Misschien worden dit soort domeinomleidingen te vaak gebruikt om onder de spambloklijst uit te komen? MrBlueSky 22 jul 2010 03:19 (CEST)

Sites als bitly en tinyurl verwijzen naar andere sites, maar je kunt aan het url niet zien welke site. Dus zou je op die manier ook links kunnen toevoegen naar ongewenste sites. En dan heeft die hele spam blacklist geen zin, je kunt immers mbv bitly toch een link naar zo'n site toevoegen. Met behulp van sites als longurl.org kun je er wel achter komen waar de link uiteindelijk naar toe gaat, maar dat moet wel eerst geimplementeerd worden. --Wimmel 22 jul 2010 09:11 (CEST)

Heldere antwoorden, bedankt. In feite is er dus niks mis met het gebruik ervan, ik loop zelf geen gevaar. Alweer een nieuw begrip geleerd, MrBlueSky, namelijk: Regex. Gelukkig zit zo voor de doorsnee gebruiker het gigantische spamprobleem op de achtergrond verborgen.--RobSchop [geef een gil!] 22 jul 2010 12:54 (CEST)

Over gevaar lopen, kun je misschien http://blog.bit.ly/post/138381844/spam-and-malware-protection nog even lezen als extra toevoeging. (als het mij lukt deze link door het spamfilter te loodsen). --Wimmel 22 jul 2010 20:47 (CEST)

Vector design wijzigingen

Het sjabloon Sjabloon:Help_inhoud_terug lijkt niet goed meer te werken, op bijvoorbeeld deze pagina staat ie te laag. Bij subpagina's zoals Wikipedia:Snelcursus/Uitgangspunten verschijnt onder de kop "< Wikipedia:Snelcursus", en dat drukt het sjabloon rechts wel op de goede plek. Als je op Portaal:Hulp_en_beheer een willekeurige link aanklikt dan zie je het probleem ook. Met vriendelijke groet, Kwiki overleg 27 jul 2010 05:18 (CEST)

Als je in het sjabloon op de eerste regel top:12px; verandert in top:0px; staat ie op de goede plek, maar mogelijk niet voor degenen die niet vector gebruiken. top:-40px; kan eventueel ook, dan komt het een regel hoger te staan. --Wimmel 27 jul 2010 22:02 (CEST)

Gebruik een id en/of class en definieer het net als titel iconen in hogere CSS. probleem opgelost. TheDJ 28 jul 2010 01:04 (CEST)

Etalage-artikel sterretje wordt dubbel weergegeven

Mij valt op dat het etalage-artikel sterretje in het linkerblokje "In andere talen" op de Nederlandstalige en de Franstalige wikipedia dubbel wordt weergegeven. Voorbeeld is artikel Late oudheid. De Duits- en de Engelstalige wikipedia schijnen er geen last van te hebben. In ben wel geïnteresseerd in de vraag wat de oorzaak van deze afwijking is. Mvg JRB 28 jul 2010 16:40 (CEST)

In mediawiki:common.css staat

li.FA {
        list-style-image:url(http://upload.wikimedia.org/wikipedia/en/d/d4/Monobook-bullet-star.png);
}

In mediawiki:vector.css staat

#mw-panel div.portal div.body ul li.FA {
        -moz-background-clip:border;
        -moz-background-inline-policy:continuous;
        -moz-background-origin:padding;
        background:transparent url(http://upload.wikimedia.org/wikipedia/commons/d/d4/Monobook-bullet-star.png) no-repeat scroll left top;
        margin:-3px 0 6px -10px;
        padding:0 0 0 10px;
}

Dus er is zowel een background als list-style-image gedefinieerd. --Wimmel 28 jul 2010 18:42 (CEST)

Hallo Wimmel, dank voor jij reactie. Ik neem aan dat het een fout was. Bovenstaande twee bestanden zijn echter niet aangepast en het probleem lijkt nu verholpen. Over het algemeen gaan problemen echter niet vanzelf weg. Enig idee wat er gebeurd is? Mvg 28 jul 2010 19:19 (CEST)

Toen ik reageerde zag ik het ook niet dubbel. Ik ging er vanuit dat dat aan mijn browser lag. Ik zie nu dat elders ([1]) overflow: hidden; staat, daardoor wordt list-style-image niet zichbaar, en is maar 1 sterretje.

	div#mw-panel div.portal div.body ul li {
		line-height: 1.125em;
		padding: 0;
		padding-bottom: 0.5em;
		margin: 0;
		overflow: hidden;
		font-size: 0.75em;
	}

Dus mogelijk was er een hele andere reden dat er tijdelijk 2 sterretjes waren. --Wimmel 28 jul 2010 19:54 (CEST)

Bedankt ik houd in de gaten of het probleem inderdaad weg blijft. Mvg JRB 28 jul 2010 20:07 (CEST)

Alsnog zou die regel uit Common.css eigenlijk naar Monobook.css moeten natuurlijk. Is en blijft monobook specifiek. TheDJ 28 jul 2010 22:03 (CEST)

Kopjes die niet correct worden weergegeven

Naar mijn vermoeden zit er in het script om icoontjes als titel-item weer te geven een bug, die er voor zorgt dat kopjes met een bepaalde naam rechtsboven komen te staan.

Commons

De vier kopjes hierboven worden niet getoond (wel bewerkknopje rechts), maar worden rechts van de titel weergegeven. Dit is niet in alle browsers het geval, in FF3.6.2 wel. Het is geen nieuw probleem, werd vorig jaar ook al geconstateerd, maar s nog niet opgelost. Romaine (overleg) 30 jul 2010 18:38 (CEST)

Het probleem en de oplossing staan hier ook al. - Erik Baas 30 jul 2010 23:32 (CEST)

Dus niet. De oorzaak blijkt in MediaWiki:Vector.js te zitten, in de functie "Titel_item3", en wel in regel 66:

Titel_toevoegen("Semibeveiligd", h1, content);

en de 6 volgende regels. Ik denk dat we alle gewone Nederlandse woorden die in sjablonen als classname of ID worden gebruikt, moeten vervangen door tekenreeksen die niet ook toevallig als kopje getypt kunnen worden (let wel, dat geldt voor alle naamruimten !). Een combinatie van goedgekozen woorden kan goed zijn, eenvoudiger is wellicht een underscore toe te voegen voor of na de bestaande classname of ID ("Beveiligd" wordt "_Beveiligd", etc.). Dat moet dan wel tegelijk worden uitgevoerd in Vector.js en de betreffende sjablonen. - Erik Baas 31 jul 2010 00:32 (CEST)

Ja gewoon een consistente prefix of postfix. Ik merk trouwens op, dat voor sommige mensen (browser afhankelijk) Common.js en Vector.js tot wel 30 dagen gecached kunnen zijn (niet vaak, maar het kan wel). Dingen 'tegelijk' vervangen is dus zo goed als onmogelijk, op en.wp proberen we vaak tijdelijke dubbele functionaliteit te creëren. In dit geval moet het script dan een maand, beide versies herkennen, en dan kan je na een maand de id's in de templates vervangen. TheDJ 31 jul 2010 03:50 (CEST)

Inderdaad, daar had ik niet aan gedacht. Wil jij alvast de nieuwe code toevoegen aan MediaWiki:Vector.js ? - Erik Baas 31 jul 2010 14:48 (CEST)

Is kennelijk niet gebeurd, wel is er een stukje script uit vector.js gehaald waardoor nu niet alleen de eerder genoemde sjablonen maar b.v. ook de coördinaten op de verkeerde plaats staan (zie [2]). - Erik Baas 12 aug 2010 11:51 (CEST)

Per vandaag lijkt het opgelost te zijn door de aanpassingen van RonaldB op Sjabloon:Woordenboek, Sjabloon:Etalage, Sjabloon:Beveiligd, Sjabloon:Semibeveiligd, Sjabloon:Coördinaten (incl Sjabloon:Coor title dec en Sjabloon:Coor title dm) en Sjabloon:Coor title dms plus de aanpassing op MediaWiki:Vector.js. Op MediaWiki:Sharedupload moet de aanpassing nog plaatsvinden. Als het ergens verkeerd staat moet de cache van de pagina of de browser eerst geleegd worden. Groetjes - Romaine (overleg) 12 aug 2010 13:22 (CEST)