Wikipedia:SHEIC/Archief/2010-04

URL's afdrukken

Bij het afdrukken van pagina's worden externe links voluit geschreven, maar dat geeft bij pagina's als b.v. Lijst van rijksmonumenten in Hoorn (plaats) een hoop rommel: er staan n.l. 383 links naar het "externe kaarten"-script, en dat zijn l a n g e URL's...

De oorzaak zit in commonPrint.Css:

#content a.external.text:after, #content a.external.autonumber:after {
    /* Expand URLs for printing */
    content: " (" attr(href) ") ";
}

Is er een eenvoudige manier om dit plaatselijk te omzeilen, m.n. voor pagina's als de genoemde ? Kan er anders zo'n mogelijkheid geschapen worden ? Deze code werkt in dat opzicht prima, maar zou zodanig aangepast moeten worden dat ze alleen voor een specifieke class werkt (die dan aan een tabel, div of span kan worden toegekend). - Erik Baas 10 apr 2010 02:24 (CEST)

Op en wikipedia, hebben we daarvoor de "nourlexpansion" class in en:MediaWiki:Print.css. TheDJ 10 apr 2010 03:39 (CEST)

Dat is precies wat ik zocht; ik dacht eigenlijk dat er op nl: toch ook al zoiets bestond, maar nee dus... Goed, bij deze dan het verzoek aan een moderator om de volgende code op te nemen in MediaWiki:Print.css:

/* URL van externe links niet afdrukken */
#content cite a.external.text:after,
.nourlexpansion a.external.text:after,
.nourlexpansion a.external.autonumber:after {
 display: none !important;
}

N.B.: De code is getest (Gebruiker:Erik_Baas/monobook.css en Sjabloon:Tabelkop rijksmonumenten). Alvast bedankt, Erik Baas 10 apr 2010 22:23 (CEST)

P.S.: De knopjes tbv. het sorteren van de kolommen in een tabel worden ook afgedrukt, maar dat lijkt me niet echt nuttig... :-p - Erik Baas 10 apr 2010 23:34 (CEST)

Ik heb de inhoud van je eigen css gekopieerd naar MediaWiki:Print.css. Mochten er nog fouten in zitten, meldt het maar. Pompidom 12 apr 2010 07:56 (CEST)

Prima, dank je wel, maar... het ging alleen om de laatste 6 regels, dus letterlijk de code zoals in het kadertje hierboven (d.d. 10 apr 2010 22:23 (CEST)). De volgende regels

 
 #conditions, #editnotice-ns-12, #rctext, #lopendepeilingen, #lopendestemmingen, #wl-current {display:none;}
 
 .diff-otitle, .diff-ntitle  {width:50%;}

horen er niet bij, wil je die er weer uit halen ? - Erik Baas 12 apr 2010 12:40 (CEST)

Gedaan. Groet, Pompidom 12 apr 2010 13:10 (CEST)

Hij is fijn, dank je. :-) - Erik Baas 12 apr 2010 22:51 (CEST)

Sjabloon portaal van de week

Hallo, hier een vraagje of er iemand met verstand van zaken kan kijken naar het Sjabloon:Portaalvandeweek volglijst, dat ik gemaakt hebt naar aanleiding van het invoeren van een beurtrol voor het portaal van de week op de hoofdpagina na deze stemming. Ik ben zelf geen techneut maar na wat zoeken heb ik een werkende volglijst samengesteld, de definitieve begindatum moet ik nog invoeren (start 1 mei 2010). Het probleem is wanneer de lijst ten einde is en alle portalen de revue hebben gepasseerd, dit sjabloon niet terugkeert naar de eerste op de lijst. Is er iemand die een idee heeft om automatisch een return naar de eerste in de lijst te doen nadat de laatste in de lijst aan de beurt is geweest ? Let wel, het aantal portalen in de lijst zal over tijd variabel zijn, er zullen portalen bijkomen en wegvallen. groet, Ziyalistix 23 apr 2010 11:13 (CEST)

Het gaat om dit stukje:

{{#expr: floor( abs( {{#time:U|{{LOCALTIMESTAMP}}}} - {{#time:U| 18-04-2010 }} ) / 604800  +0.5   ) }}

Wat je kunt doen, is dat vervangen door:

{{#expr: floor( ( {{#time:U|{{LOCALTIMESTAMP}}}} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}

Dit levert altijd een getal van 1 t/m 121. Zie te volgende tabel:

berekening	resultaat
{{#expr: floor( ( {{#time:U| 18-04-2010 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	1
{{#expr: floor( ( {{#time:U| 24-04-2010 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	1
{{#expr: floor( ( {{#time:U| 25-04-2010 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	2
{{#expr: floor( ( {{#time:U| 01-05-2010 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	2
{{#expr: floor( ( {{#time:U| 02-05-2010 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	3
{{#expr: floor( ( {{#time:U| 11-08-2012 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	121
{{#expr: floor( ( {{#time:U| 12-08-2012 }} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}	1

Als het aantal veranderd, moet je ook de 121 in de formule aanpassen. Maar let op: Dat geeft een probleem als dat na 12-08-2012 gebeurt. Nu zal op die datum weer het eerste portaal gebruikt worden. Maar als er 122 portalen zijn, zal opeens in die week portaal 122 aktief worden, en alles een week opschuiven. Natuurlijk wil je niet dat midden in een week het portaal veranderd. Dus moet je op de datum dat het eerste portaal weer aktief is, de datum 18-04-2010 aanpassen naar die datum.

Mijn voorstel zou zijn om het sjabloon dan automatisch aan een categorie toe te voegen, zodat iemand dat opvalt. Dat kan bijvoorbeeld door zoiets toe te voegen:

<noinclude>{{#ifeq:{{#expr: floor( ( {{#time:U|{{LOCALTIMESTAMP}}}} - {{#time:U| 18-04-2010 }} ) / 604800 ) mod 121 + 1 }}|{{#expr: floor( ( {{#time:U|{{LOCALTIMESTAMP}}}} - {{#time:U| 18-04-2010 }} ) / 604800 ) + 1 }}||Datum veranderen[[Categorie:Wikipedia:Pagina's waar iets mee is]]}}</noinclude>

Als het niet duidelijk is wat ik hierboven beschrijf, laat het maar weten. ∼ Wimmel 23 apr 2010 20:54 (CEST)

Ok, heel erg bedankt. Nog een vraagje, waar moet de non-wiki code precies komen met de waarschuwing om de datum te veranderen, mag dat mee tussen de (non-wiki) categorie , of er net voor of achter ? Ziyalistix 23 apr 2010 21:11 (CEST)

Als het maar ergens tussen noinclude staat, maakt niet zoveel uit waar. Misschien het beste meenemen in de noinclude die er al staat, voor de categorie die er al staat. Alleen is het misschien wel handig om een betere melding en categorie te zoeken. Maar daar heb je nog 2 jaar tijd voor.... ;) ∼ Wimmel 23 apr 2010 22:08 (CEST)

Inderdaad, ik heb nog wat tijd :) Alvast bedankt nogmaals. Ziyalistix 23 apr 2010 22:26 (CEST)

Ik heb sterk mijn twijfels over zo'n bak code, vraag me sterk af of dat wel nodig is. Groetjes - Romaine (overleg) 23 apr 2010 22:54 (CEST)

wat bedoel je precies, vind je het beter om de code tussen de noinclude weg te laten ? Ziyalistix 23 apr 2010 23:39 (CEST)

Ik had het over alle code die gebruikt is, en dan met name juist die code buiten de noinclude... Het zal wel aan mij liggen, maar ik snap niet waarom dit hele sjabloon zo complex moet zijn. Romaine (overleg) 24 apr 2010 02:53 (CEST)

Als jij vind dat het makkelijker kan en er zin in hebt, mag je het aanpassen hoor, dan wacht ik nog wat met het maken van de sjablonen voor de doorschuifplaatsen, ik ken daar eigenlijk zelf niet zoveel van, groeten, Ziyalistix 24 apr 2010 04:28 (CEST)

Hallo Ziyalistix, Soms zijn dingen wat vertraagd, dan is een herinnering eraan prima. Waar ik op stuitte is een enorme complexe code, waarvan ik mij afvraag of dat wel nodig is. Op de vraag of het nodig is kan ik geen antwoord vinden, mede omdat ik niet weet wat precies je bedoeling is. Ik begrijp dat er wekelijks een nieuw portaal van de week is en dat die per week gewisseld wordt, dit zou dan automatisch moeten gaan gebeuren. Ik begrijp dat er een lijst met goedgekeurde portalen is en dat die gebruikt gaat worden. Als al vaststaat wie over een x aantal weken het portaal van de week wordt, lijkt het mij het eenvoudigste om gewoon het jaar + het weeknummers als uitgangspunt te nemen. Dus bv 2010-16 (week 16 in 2010. Je kunt door middel van een switch waarin het jaar + weeknummer worden bepaald door de parserfunctie daarvoor, en dan een lijst samenstellen met voor het =-teken het jaar + weeknummer en na het =-teken het portaal. Samengevat: je maakt dan een lijst van jaar+weeknummer gecombineerd met het portaal van die week, en je hebt mijn inziens een veel eenvoudiger systeem. Dit is mijn suggestie maar, maar zo worden op veel portalen ook gewerkt met variabele pagina's afhankelijk van de week, dag of maand. Groetjes - Romaine (overleg) 29 apr 2010 00:37 (CEST)

Hallo Romaine, het probleem is denk ik dat er nieuwe portalen kunnen bijkomen en moeten ingevoegd in de week volgend op de dan huidige week en dat er ook portalen kunnen verdwijnen uit de lijst. Ik denk dat het voorlopig beter is om gewoon het huidige sjabloon te gebruiken omdat je aangeeft voorlopig geen tijd te hebben en ikzelf niet genoeg kennis heb. Aanpassingen kunnen eventueel later nog gebeuren. Inmiddels kan het nieuwe systeem op 1 mei ingang vinden. Bedankt en groeten, Ziyalistix 29 apr 2010 00:51 (CEST)

Hallo Ziyalistix, Als ik het sjabloon zie, zul je bij iedere toevoeging/verwijdering de hele daarop volgende nummering moeten aanpassen, hetzelfde geldt voor het idee wat ik net beschreef. Maar als het werkt laat ik het verder rusten. Groetjes - Romaine (overleg) 29 apr 2010 01:03 (CEST)

Dat had ik ondertussen ook al gevonden, het aanpassen wordt lastig, maar ik zie zelf niet meteen een andere oplossing. Mvg, Ziyalistix 29 apr 2010 01:33 (CEST)

Romaine vindt code al gauw "heel complex", zo ondervond ik eerder vandaag. De vraag rijst dan of dat aan de code ligt... - Erik Baas 29 apr 2010 01:49 (CEST)

Of een sjabloon te complex is, wordt volgens mij alleen bepaald doordat er voldoende aktieve wikipedianen zijn die het sjabloon kunnen onderhouden. Als blijkt dat dit sjabloon over 2 jaar niet werkt omdat het dan een schrikkeljaar is, moet er op dat moment iemand zijn die het kan bewerken. Als dat niet lukt, is het te ingewikkeld.

Misschien is het een oplossing om met een stukje javascript dit sjabloon te genereren, en dat bij elke wijziging opnieuw te doen. Het sjabloon kan dat vereenvoudigd worden volgens de suggestie van Romaine. Als er niemand aanwezig die de javascript bij een wijziging opnieuw uit kan voeren, kan het ook handmatig aangepast worden. ∼ Wimmel 29 apr 2010 20:47 (CEST)

Het gaat mij eerlijk gezegd allemaal al mijn petje te boven, maar goed :) Bij de parcelfuncties zag ik dat er een code (L?) bestaat om een schrikkeljaar aan te geven. Zou er niks geschreven kunnen worden dat wanneer het een schrikkeljaar is het getal 604800 vervangen wordt in de formule door het een ander dat overeenkomt voor 366 dagen ? Zo zou de cyclus van 7 dagen toch overeind blijven (denk ik) ? Ziyalistix 30 apr 2010 14:28 (CEST)

Romaine vindt zelf sjablonen helemaal niet te gauw te complex, maar Romaine tracht te luisteren naar de geluiden in de wikigemeenschap die aangegeven dat er regelmatig te complexe sjablonen zijn die voor gemiddelde gebruikers met tabelkennis te complex zijn. Het doel van sjablonen is niet om ze zo complex mogelijk te maken, maar ze zijn bedoeld om een bepaalde functie te vervullen, waarbij het onderhoud door een grote groep gebruikers op deze wiki uitgevoerd moet kunnen worden. Groetjes - Romaine (overleg) 4 mei 2010 00:41 (CEST)

Tja, ik zie dat anders: wie een sjabloon te complex vindt moet er gewoon niet aan gaan sleutelen, maar de maker (of iemand anders) om hulp vragen. Klachten van mensen die iets niet begrijpen of er niet mee om kunnen gaan mogen m.i. geen reden zijn om dan maar alle complexe code te weren van WP. Zie b.v. de code van {{Coor dec}}, daar word ik ook duizelig van; maar het sjabloon is wel onmisbaar, want op bijna 5000 pagina's in gebruik... - Erik Baas 4 mei 2010 01:41 (CEST)