Wikipedia:SHEIC/Archief/2009-07

Titel toevoegen

Is het mogelijk om een titel toe te voegen aan sjablonen als Sjabloon:Galerijbestand klein? -B kimmel 5 jul 2009 18:10 (CEST)

Titel
Zuilenhal van Tiberius
Tempel van Dendera
Mammisi uit Dendera

Ja, voeg de titel toe zoals in dit aangepaste voorbeeld:

{| {{Galerij rechts klein}}
 ! Titel
 |-
 | {{Galerijbestand klein|Denderah_cour.jpg|Zuilenhal van Tiberius}}
 |-
 | {{Galerijbestand klein|Denderah1.jpg|Tempel van Dendera}}
 |-
 | {{Galerijbestand klein|Denderah intérieur mammisi.JPG|Mammisi uit Dendera}}
|}

-- LexTH overleg  5 jul 2009 18:49 (CEST)

Tekstvariatie in sjablonen

Ik vroeg me af of het mogelijk is om verschillende variaties van een bepaalde zin op te nemen in 1 sjabloon. Op nds-nl zou ik bijvoorbeeld voor alle hoofddialecten graag 1 sjabloon houden maar wel dat je kunt kiezen uit de dialecten. Zoiets ongeveer:

• {{Heufdartikel|gos|Appelsap}} dat je dan deze tekst krijgt: "Der bestaait ook n ziede "[[Appelsap]]" mit meer informoatsie op dit onderwaarp"
• {{Heufdartikel|act|Appelsap}} dat je dan deze tekst krijgt: "Der besteet ok ne ziede "[[Appelsap]]" met meer informatie oaver dit onderwarp"

Alvast bedankt! Sεrvιεи | Overleg » 9 jul 2009 00:42 (CEST)

Bedoel je dat de sjabloon alleen die twee zinnen moet produceren, met één invulwoord?

Maak een pagina aan met als titel: "Mal:Heufdartikel". Geef die de inhoud:

{{#ifeq:{{{1}}}|gos|Der bestaait ook n ziede "[[{{{2}}}]]" mit meer informoatsie op dit onderwaarp}}<!--
-->{{#ifeq:{{{1}}}|act|Der besteet ok ne ziede "[[{{{2}}}]]" met meer informatie oaver dit onderwarp}}

Als je extra regels tussenvoegt moeten die aan weerszijden de --> <!-- krijgen. Zie Help:Gebruik van sjablonen voor meer uitleg.

-- LexTH overleg  9 jul 2009 01:26 (CEST)

Krek wa-k wol! Bedankt voor de goede hulp! Sεrvιεи | Overleg » 9 jul 2009 13:18 (CEST)

Het blijkt een heel rijtje dialecten geworden te zijn. Dan is de constructie met #switch beter. Zie nds-nl:Mal:Heufdartikel. -- LexTH overleg  9 jul 2009 14:00 (CEST)

kB, hoger en woorden

Vrienden, bestaat er een omrekeningswijze om bij benadering te weten te komen hoeveel woorden (en A4-pagina's, als je een gemiddeld aantal woorden per pagina vastlegt) een document of een site bevat als je alleen beschikt over het aantal kB (MB, GB ...) uit de pagina-info? Dit is bijv. de pagina-info van De Kroeg ivm grootte: 113,02 KB (115.732 bytes). Dat kan nuttig zijn bij vertalingen en plannen ervoor. Want ik ken geen functie "woorden tellen" op het internet zoals die in elk heus tekstverwerkingsprogramma zit.--RobSchop [geef een gil!] 9 jul 2009 15:34 (CEST)

Dat zal sterk afhangen van het al dan niet hebben van illustraties. Bij platte tekst kun je er van uitgaan dat het aantal bytes iets minder is dan (aantal tekens per regel)x(aantal regels). Grote illustraties zullen het aantal sterk verminderen, en nieuwe alinea's ook wat. En als je door veel nieuwe hoofdstukken nogal eens een halflege pagina hebt tikt dat ook aan.

Je kunt een indruk krijgen door in een tekstverwerker een voorbeeld te nemen dat er vergelijkbaar uitziet, dan weet je het aantal woorden en pagina's. Kijk hoeveel kB het is, en maak vervolgens de pagina's leeg. Het verschil in omvang zal ongeveer overeenkomen met het aantal woorden en pagina's. -- LexTH overleg  9 jul 2009 17:26 (CEST)

Volgens http://blogamundo.net/lab/wordlengths/ is een gemiddeld Nederlands woord 5.51 tekens lang. Dat zou je kunnen gebruiken als je het wilt berekenen/schatten. - Simeon 9 jul 2009 18:29 (CEST)

als je de tekst kopieert en op http://allworldphone.com/count-words-characters.htm plakt heb je met een druk op de knop het aantal woorden. ∼ Wimmel 9 jul 2009 18:42 (CEST)

"Niets slimmer dan een mens, maar hij moet leven", zei mijn moeder altijd.:) Dat ik er zelf niet opkwam, LexTH... denkluiheid? In feite simpel: met een regeltje van drie de kB's van een bestaand document met een bekend aantal pagina's omrekenen naar een ander aantal kB's. Wimmel, ook bedankt hoor, bijzondere site. En de afwijking door de illustraties neem ik er wel bij. Als ik zoiets ooit preciezer wil weten kan ik die misschien apart opzoeken en daar ook eerst op basis van de afmetingen met eenzelfde regel van drie de kB van berekenen en de kB's van het totaal aftrekken.RobSchop [geef een gil!] 9 jul 2009 21:20 (CEST)

Automatische alfabetische schikking

blijkt hier op deze categoriebladzijde te ontbreken.

• Hoe vul je die onbenutte witruimte beter op zodat het ! met het artikel Afkorting bovenaan in de tweede kolom kan staan?
• Krijgen jullie de autom. alfabetisering daar wel aan de praat zodat Lijst van afkortingen ... (10 in totaal) allemaal bijeen staan?
• Lijst van afkortingen (met redirects: Algemene lijst van afkortingen & Lijst van afkortingen (algemeen)) zou dan best nog helemaal als eerste staan, omdat die niet in de ondercategorie hieronder genoemd hoort.
• Bedoeling: de bovengenoemde 10 artikelen in een ondercategorie (N.B. subcategorie wordt als term niet (meer) gebruikt op de categoriebladzijden, lijkt me) stoppen Lijst van afkortingen per onderwerp.
• Maar hoe maak je die Categorie:Lijst van afkortingen per onderwerp als ondercategorie van Categorie:Afkorting? Ik ben hier begonnen bij Arbo en hij staat rood, dus ik doe even niet verder: deze artikelkop biedt geen uitkomst. Moet je gewoon wachten op een goedkeuring erna door een moderator? 'k Heb het intussen gevonden: ik moest gewoon aan een rode fase voorbij, totdat ik een verder leeg blad Categorie:Lijst van afkortingen per onderwerp als "artikel" had opgeslagen.RobSchop [geef een gil!]

Dit is een werkje n.a.v. komende verwijdering van dp met die naam (en terecht initiatief van Jvhertum:) Toegevoegd 13/07: Deel 2, alinea over Lijst van afkortingen per onderwerp. Op het einde zal ik dan de <!-- Opmerking --> voor bewerkers wel aanpassen: vragen om te klikken op de categorie onderaan in het artikel enz.--RobSchop [geef een gil!] 16 jul 2009 22:48 (CEST)

Intussen meen ik alles goed te hebben bewerkt op manuele wijze. Ik dacht nog: ik vraag iemand met een botje om die adviestekstjes tussen <!--- ---> overal gelijk te kopiëren, maar het ging uiteindelijk slechts om 10 artikelen.RobSchop [geef een gil!] 19 jul 2009 20:18 (CEST)

Is Google te dateren of al ergens gedateerd?

(beter geformuleerd (= toevoeging d.d. 21-7-2009): Zijn Google-zoekresultaten te dateren of al gedateerd opvraagbaar?)

Naast al het goede dat men kan zeggen van Google als zoekmachine, moet ik zeggen dat ik het meest een duidelijke ontstaansdatum of bewerkingsdatum mis van de sites in de resultatenlijst. Je hebt wel de laatste cachingdatum na een klik op "in cache", maar niet elk resultaat heeft die cachekoppeling. Maar dan nog merk ik vaak dat in 2009 info uit 2003 gecached is en hopeloos verouderd. Ik verlies toch wel veel minuten met het openklikken van (te) oude links! Hoe lossen jullie dat op? Ditmaal hoop ik niet denklui te zijn, ik heb gewoon geen idee.RobSchop [geef een gil!] 9 jul 2009 21:32 (CEST)

Ik snap denk ik niet helemaal wat je bedoelt, maar misschien kun je hier wat mee; door &as_qdr=y15 toe te voegen aan het google url, krijg je de orginele datum te zien bij de zoekresultaten, bijv: [1] (bron[2]). Op archive.org kun je oudere versies van websites zien, bijv.: [3]. ∼ Wimmel 9 jul 2009 22:15 (CEST)

Het laatste kende ik al, Wimmel, maar bijzonder bedankt voor die twee eerste links. Nu nog een mnemotechniekje om "&as_qdr=y15" te onthouden. Het kunnen sorteren op datum zal wel altijd ingaan tegen de andere behoefte: opvallen als klant en betalende klanten tevreden stellen. --RobSchop [geef een gil!] 12 jul 2009 18:02 (CEST)

Als je smart keywords gebruikt, hoef je het niet te onthouden. smart keywords (firefox), search keywords (chrome), blog post. Ik gebruik dat standaard, en mijn bookmark ziet er zo uit: http://www.google.com/search?hl=en&as_qdr=y15&q=%s ∼ Wimmel 12 jul 2009 19:52 (CEST)

Beste Wimmel, ik heb die links allemaal bekeken, maar doe toch nog iets fout met het automatisch oproepen. Het werd duidelijk dat ik het smartkeyword (FF) en search keyword (GChrome) systeem al gebruikte, omdat het ingebouwd blijkt in de browser. De uitleg over het bewust toevoegen van een sleutelwoord was nieuw: ik vond idd ook in de Nederlandstalige versie (ik sta ingesteld op google.be ipv google.com) die mogelijkheid na een rechtsklik. Vanzelfsprekend probeer ik te achterhalen wat die code betekent en merk dat y=15 staat voor "15 jaar" (qdr=query direction?). Ik snap niet wat de toevoeging q=%s dan wel toevoegt: ik kwam op een willekeurige pag. uit. Maar mijn problemen zijn vooral dat (1) ik zo'n sleutelwoord per zoekopdracht moet toevoegen (ik moet daar dus al éénmaal geweest zijn: het is een "herinneringsfunctie"), blijkbaar kun je niet voor die 15 jaar kiezen in de google-voorkeuren ipv "willekeurig moment" en (2) ik google nooit via een bookmark van een lege googlepag., maar in FF via de Google toolbar (en in Chrome zoals iedereen in 't adresvak). Het voorbeeld met imdb is simpel (waar ze ook zeggen dat je 't telkens moet intikken), maar met &as_qdr=y15&q=%s ligt dit moeilijker. Ik heb de vraag van de koptitel beter geformuleerd eronder (cursief)--RobSchop [geef een gil!] 21 jul 2009 21:39 (CEST)

Die &as_qdr=y15 lijkt inderdaad bedoelt om de zoekresultaten te beperken tot de laatste 15 jaar. In plaats van y15 kan bijvoorbeeld ook w gekozen worden voor de laatste week. Maar het gaat erom dat daardoor de datum ook in de zoekresultaten verschijnt. Het geeft dus niet aan wanneer een website voor het laatst bijgewerkt is, het geeft alleen maar aan wanneer google die pagina de eerste keer gevonden heeft. En het gaat ook maar terug tot januari 2001.

En wat betreft die smart keywords, misschien heb je nog iets aan de uitleg op lifehacker.com. Wat ik doe is eerst een keyword search toevoegen op de gewone simpele manier. Daarna bewerk ik de bookmark handmatig om bijvoorbeeld de as_qdr code toe te voegen. Zie bijvoorbeeld [4] hoe zo'n bookmark eruit ziet in de bookmark eigenschappen.

Het resultaat is dat als ik "g zoekwoord" + ENTER in de adresbalk typ, ik de google zoekresultaten voor dat zoekwoord met de datum te zien krijg. De google toolbar of een andere zoekveld in de browser gebruik ik niet. ∼ Wimmel 21 jul 2009 23:34 (CEST)

Youtube

Hoe kan ik die dansdemo insluiten in mijn GP? De code staat er gekopieerd om te "embedden", maar 't werkt nog niet. Ik wil es wat meer doen dan er alleen naar verwijzen zoals er vlak boven. Maar mag ik dat ook wel hier op deze wikipedia? (Ik vond 'm bij een zekere Kristina Weis van aboutus.org die de volgende code gebruikte: [5]). En dus vraag ik me ook af of deze uitleg ook hier bij ons kan werken; geprobeerd maar voorlopig niet. En ik dacht ook dat het wenselijk is om slechts beperkt html-codes te laten werken. Zouden die youtubers dat zelf aangemaakt hebben... een aparte html code voor youtube?--RobSchop [geef een gil!] 20 jul 2009 11:43 (CEST)

Dat is niet mogelijk aangezien HTML niet in die mate ondersteund wordt. - Simeon 20 jul 2009 11:45 (CEST)

De manier is het te converteren naar Ogg Theora en vervolgens te uploaden, bijvoorbeeld op commons onder de categorie commons:Category:Videos available on YouTube. Vervolgens is het simpel de video te embedden. Natuurlijk moet de video wel een vrije licentie hebben om m hier te kunnen uploaden. ∼ Wimmel 20 jul 2009 12:06 (CEST)

Dank. Ik zie wel of ik dat es toepas. Geen dringende zaak op die fiets. Een externe link volstaat voor mij (zeker op mijn GP).--RobSchop [geef een gil!] 25 jul 2009 18:30 (CEST)

infobox drukt afbeeldingen naar beneden

Op Walderveense molen staan 2 foto's die, om in de lopende tekst te blijven, aan de linkerkant zijn gezet. In IE ziet dat er prima uit, maar in Firefox komen die foto's precies onder de infobox molen aan de linkerkant te staan, dus nog steeds helemaal uit de lijn van de tekst. Zit er een foutje in de infobox? Akoopal _overleg 26 jul 2009 11:05 (CEST)

Het ligt niet speciaal aan deze infobox. Alle infoboxen bevatten de commando's float:right en clear:right. Daarmee komen ze rechts onder elkaar te staan. Wat er in FF gebeurt is dat de foto's op gelijke hoogte komen met de onderste infobox. Dat kun je eenvoudig zien door de openingsinfobox te herhalen.

Intussen heb ik nog geen oplossing voor het probleem, maar ik kan het wel precies aanduiden: Bij het plaatsen van de foto links interpreteert FF de clear:right als clear:all. -- LexTH overleg  26 jul 2009 11:56 (CEST)

Probleem zit in het ook gebruikte sjabloon:Bezoek, verwijderen ervan en bewerking ter controle tonen zet bij mij in FF 3.6 de plaatjes op de volgens de broncode gewenste plaats. Het sjabloon bezoek is een middels html opgemaakte tabel, volgens mij sowieso niet raadzaam, maar heb geen idee hoe ik dit aan kan passen, misschien dat een betere techneut dan ondergetekende dit kan repareren. ♠ Troefkaart 26 jul 2009 12:04 (CEST)

Het fotoprobleem is opgelost met wrapper. Bezoek zal ik wikificeren heb ik gewikificeerd. -- LexTH overleg  26 jul 2009 12:25 (CEST)

Helaas lost dat het verder niet op. We zullen er maar mee moeten leven dat we wrapper weer nodig hebben, dank voor de workaround. Akoopal _overleg 26 jul 2009 12:40 (CEST)

Het komt veel vaker voor deze situatie, en dan is de wrapper de enige oplossing. Romaine (overleg) 26 jul 2009 14:34 (CEST)

Rode link

Op 27 juli 2009 ben ik een artikel gestart over Bobby Kimball, een Amerikaans zanger. Nu dat het artikel reeds twee dagen bestaat - en er door een andere gebruiker is aangepast - blijft de link op mijn gebruikerspagina rood. Ik vroeg me af of iemand dit kan verklaren.
J Roest 29 jul 2009 21:07 (CEST)

Als ik op je gebruikerspagina kijk, dan zie ik een blauwe link. Pompidom 29 jul 2009 21:24 (CEST)

De link was bij mij ook rood, maar na een null-edit (pagina opslaan zonder te bewerken, is dus ook niet in de geschiedenis terug te vinden) werd de link blauw. Heb hier verder geen verklaring voor, ♠ Troefkaart 30 jul 2009 16:18 (CEST)

Ik heb een mogelijke verklaring. Als je een null-edit doet wordt de pagina opnieuw gerenderd, zodat je de nieuwste versie te zien krijgt. Roest en Troefkaart keken nog naar een oude versie uit een cache. Feit blijft wel dat Pompidom al een blauwe link zag. Ofwel jullie pagina's zaten nog ergens onderweg in een cache, ofwel Pompidom keek naar een andere server. Op de ene server kan een nieuwere versie van de pagina in de cache staan dan in een andere. -- LexTH overleg  30 jul 2009 17:05 (CEST)

Regelterugloop

Hoe kun je in een gewone tabel {| border ... een regelterugloop beletten (of met een extra code het niet-teruggaan afdwingen) ofwel hoe kun je daarin de kolombreedte bepalen (hier van de kolom "Heerser"): ik herken daar geen "width". Ik keek naar Lijst van heersers van Walachije en probeerde de vierde man: Thocomerius van Walachije op één regel te krijgen.--RobSchop [geef een gil!] 31 jul 2009 12:10 (CEST)

Ik heb het met {{nowrap}} gedaan. Je kunt ook de spaties door & nbsp; vervangen, maar dan moet je de link splitsen in een paginanaam en een tekst. Bij mij stond het trouwens wel op een regel, maar ik heb een breed scherm. -- LexTH overleg  31 jul 2009 12:20 (CEST)

Okee, LexTH, met nowrap weer iets bijgeleerd, tof. Je hebt wel een heel breed scherm: ik heb een kleine maand een tft 19 inch en toch die terugloop. Nog 2 overwegingen:

• Ik stelde die vraag omdat al die "Basarabs" dieper in de lijst (namen in 4 woorden!) niet teruglopen => soms onberekenbaarheid van mediawiki?;
• Bestaat de andere mogelijkheid ook: de kolombreedte aanpassen? (Of heb je daar dan een andere soort tabel voor nodig (gesofisticeerder)?)

--RobSchop [geef een gil!] 1 aug 2009 04:52 (CEST)

• De kolombreedte is vrij; d.w.z. dat de browser de behoeften in de verschillende kolommen tegen elkaar afweegt en dan verdeelt. Hoe het precies gaat weet ik ook niet; bovendien kan het per browser verschillen. Je kunt zelf breedtes voor een of meerdere kolommen opgeven (met width). Daarmee kun je precies sturen, maar dat heeft twee bezwaren. Je moet uitzoeken hoe breed zo'n kolom moet worden, en je weet niet welke paginabreedte de lezers gebruiken.
• De naam "Thocomerius van Walachije" is net iets langer dan al die "Basarabs". Als je op de bewerkpagina Thocomerius even verwijdert, en vervolgens het venster wat smaller maakt, zul je zien dat de Basarabs al gauw ook verdeeld worden.
• Je zou ook de lange teksten rechts met een break in tweeën kunnen delen. Dit is echter meer werk dan de langste naam onbreekbaar maken. Dan ben je met een regel klaar. Bovendien weet je zo precies wat er gebeurt: je geeft de naam net voldoende ruimte om niet af te breken, en dat is bovendien in alle browsers gelijk. -- LexTH overleg  1 aug 2009 18:50 (CEST)

Okee, voor mij is dat duidelijk genoeg. Alleen nog: heb je dit probleem minder met een ander tabeltype zoals "prettytable", de "standaard uit de zandbak", alla, die ik daar eerst leerde kennen? Want wat nu in gebruik is, lijkt me nog elementairder dan prettytable; "border..." is a.h.w. het kladblok van de tabelsoorten in mediawiki.--RobSchop [geef een gil!] 4 aug 2009 10:09 (CEST)

Prettytable heeft geen invloed op de kolombreedte, evenmin Toccolours vatop. Standaard is steeds dat de browser optimaal verdeelt. Vervolgens kun je beperken door een of meer kolommen een breedte op te leggen, waarbij je kunt kiezen tussen vaste breedtes (in pixels of letterbreedtes gemeten) en percentages van de beschikbare ruimte. Dit kan dan weer doorbroken worden door onbreekbare teksten of juist opgelegde breuken toe te passen. Doordat de pagina's op verschillende schermbreedtes getoond worden blijft het echter schipperen. -- LexTH overleg  4 aug 2009 12:24 (CEST)

Pauzes bij het bewerken (typen van tekst)

Ik bewerk in Firefox. Ik ervaar die pauzes van geschat 4-5 sec. vaker dan me lief is. Je typt als vlotte typist al gauw 30 woorden/minuut (de gem. snelhedenratio ben ik eig. wel vergeten) en dan moet ik zo vaak en herhaald wachten alvorens het resultaat te zien. Gevolg: tikfouten achteraf pas kunnen verbeteren w.o. veel dubbele letter(combinatie)s (omdat je denkt: hé, dat heb ik nog niet getikt!). Ligt het aan

• mijn RAM (768 Mb), 2.60 GHz ? (Tegenwoordig zie ik in de handel pc's met een RAM van wel 2 à 4 Gb: maar is dat niet meer iets voor gamers?)
• een volle buffer: maar ik leeg die geregeld (en misschien juist niet goed tijdens het bewerken) via Extra/Privégegevens opruimen (of via ctrl+shift+r of soms via rechtsklik op één tab en kiezen voor "alle tabbladen vernieuwen") ?
• Firefox zelf of aan de samenwerking ervan met de Wikipedia-servers in Amsterdam; dat m.a.w. het beeld door Wikipedia zelf vaker wordt ververst dan vroeger (en dat FF dit signaal meteen oppikt) ?
  • De knop Toon bewerking ter controle geeft ook een langduriger wachten op resultaat;
  • Hangt het gewoonweg samen met Wikipedia's gestegen populariteit: te veel bewerkers op de drukke tijdstippen ?
• de simpelste reden van allemaal: een mens raakt aan alles gewoon en het moet steeds sneller (wat gisteren waw! was, is vandaag te traag en irritant)?

Ik vond het volgende:

• url [about:config] en
• instelling FF ivm automatische verversing. Als ik kies voor True: Instead of refreshing a page automatically when <meta http-equiv="refresh"> is present (or Refresh HTTP headers), display a browser message indicating the refresh and allow the user to follow it manually. dan krijg je inderdaad die waarschuwingsbalk bovenin en dat is nu ook weer niet handig, want dan moet je daar uiterst rechts altijd weer op klikken. Misschien te veel vragen verstrengeld onder één kopje, maar 'k ben benieuwd naar jullie ervaringen en overwegingen.

Collegiale groet en een bloemetje vooraf --RobSchop [geef een gil!] 25 jul 2009 18:28 (CEST)

Volgens de website typeonline.co.uk is mijn snelheid 37 wpm. Maar ik heb geen last van merkbare vertragingen in firefox. Je schrijft niet welk besturingssysteem je gebruikt, maar ik neem voor het gemak aan dat je windows gebruikt. 768 Mb is voor windows xp volgens mij voldoende, voor windows vista is het denk ik iets te krap. Wat belangrijker is hoeveel programma's tegelijk open staan. Via de taskmanager kun je dan zien hoeveel geheugen nog vrij is. 2.60 GHz is snel genoeg. Ik type dit met een 1.5 GHz pc (maar wel onder linux, en met meer geheugen).

Het zou aan firefox kunnen liggen, met name als je bepaalde add-ons geinstalleerd hebt. Wat je het beste eens kunt proberen om in een nieuw leeg profile te werken. Zie hier. Na het testen kun je weer terug naar je oude profile, zodat je alle instellingen weer terug hebt.

Extra/Privégegevens opruimen doe ik nooit. ctrl+shift+r alleen als een pagina inhoud niet klopt. "alle tabbladen vernieuwen" doe ik al helemaal nooit. Volgens mij heeft dat ook niet veel zin. blockautorefresh heeft ook niets met snelheid te maken. Je zou wel eens kunnen proberen om java uit te schakelen in de instellingen (tools-options-content-enable java).

Je hebt het over pauzes van 4-5 sec. Ik kan eigenlijk geen goede verklaring bedenken hoe dat kan. En van afstand diagnose doen is heel lastig. Eventueel zou iemand via een site als en:Crossloop naar je pc kunnen kijken. Dat je bij het intypen van tekst moet wachten is gewoon niet goed.

Als je op websites moet wachten, zoals bij Toon bewerking ter controle is heel iets anders, en dat heeft inderdaad veel te maken met de belasting van de wikipedia servers. Hoe meer gebruikers, hoe langzamer het wordt. Misschien is ook je eigen verbinding met internet of provider traag.

Als iets wat ik hierboven schrijf niet duidelijk is, laat het maar even weten. Ik vind het altijd moeilijk te bepalen of ik dingen te technisch of juist te simpel uitleg. ∼ Wimmel 30 jul 2009 22:29 (CEST)

Beste Wimmel, bedankt voor je grondige uitleg bijna een maand geleden. Daardoor heb ik de kat uit de boom gekeken en niks overhaast proberen te wijzigen. 'k Moet zeggen dat het nu wel okee is met die pauzes, soms heb ik het ook bij het schrijven van een webmail. Mijn besluit is

• dat ik beter vermijd met 2 browsers tegelijkertijd op dezelfde site te zitten wikipedia, gmail);
• dat de reactiesnelheid iets of soms hinderlijk (bij uploaden van nieuwe wijzigingen) minder is op drukke wikimomenten zoals zaterdagmorgen en op regenachtige vakantiedagen (:-)).

'k Heb wel de indruk dat de laatste versie van FF (3.5.2) en ook dat ik toch wel tamelijk wat addons heb (37), niet echt sneller is geworden ondanks de reclame erover. Iedere FF-er kent wel het kader "Dit is gênant" bij het opstarten.--RobSchop [geef een gil!] 25 aug 2009 23:15 (CEST)

(Nogmaals) die bewerklinks

Beste collega's, ik raak het wel beu om voor die verkeerde plaatsing van bewerklinks altijd verschillende edits te moeten doen (naast het feit dat "Toon bewerking" het volledige eindresultaat met de positie van de bewerklinks niet toont). Zie gerust naar mijn pogingen voor Methylfenidaat: nu heb ik __NOEDITSECTION__ toegevoegd met een opmerking om hier te vragen of er al een oplossing voor bestaat... voor die verkeerde output in FF en GChrome. Deze vraag heeft een geschiedenis, maar misschien is het antwoord van Erik Baas toen, nu achterhaald. Als je nu in het bedoelde artikel Methylfenidaat de wrapper weer toevoegt, staan alle foto's altijd rechts. Dan werkt inderdaad (wat Erik Baas ook schreef) het commando "|left" in een Afbeeldingenregel niet. En wis je __NOEDITSECTION__ dan verenigt de kop Dosering vier keer "bewerken" (zijn eigen link en die van de drie vorige kopjes) in FF en GChrome.

--RobSchop [geef een gil!] 12 jul 2009 17:57 (CEST)

Ik heb een poging gedaan met {{wrapper|links}}, Revert mijn bewerking maar als het niet goed genoeg is. Op mijn pc (firefox/linux) ziet het er goed uit, behalve als ik de tekst verklein, dan staat het eerste bewerk linkje iets te laag. ∼ Wimmel 12 jul 2009 19:34 (CEST)

Nadat de infobox ook in de wrapper gezet is lijkt het bij mij (FF en IE7) nu in orde. Voordien stond op mijn brede scherm het eerste linkje te laag, ook bij gewoon formaat tekst. -- LexTH overleg  12 jul 2009 20:00 (CEST)

RobSchop heeft de infobox weer uit de wrapper gehaald, waarmee de oude fout bij mij weer terug is. Hij verwijst daarbij naar deze discussie, maar schrijft ook hier niet waarom hij het weer verwijderd heeft. Wat ging er dan mis door het plaatsen in de wrapper? -- LexTH overleg  12 jul 2009 22:18 (CEST)

Sorry, LexTH, ik maakte idd die verwijzing, maar vergat het dan. De reden moet wel duidelijk geworden zijn ondertussen: ook de infobox in de wrapper zetten is een klassieke werkwijze waardoor alle foto's weer rechts komen onder de infobox. Goed, maar soms wil je wel eens iets anders als effect/resultaat. Hier spreekt die foto met de uitgestrooide Ritalin pillen erg aan en die moest bovenaan blijven staan (hier dus links, vanwege de infobox klassiek rechts). Vooral de vrijheid vinden om te spelen met foto's links of rechts lijkt me daarbij van belang. Ik denk dat Wimmel die vrijheid nu gevonden heeft door naast "|links" bij het sjabloon wrapper ook {{Clearleft}} toe te voegen, waardoor ook de eerste bewerklink goed staat. De wijziging van left naar center in de afbeeldingcodes had blijkbaar en gelukkig geen effect. 'k Ben nu zelf gaan zien naar de sjabloonpag. over wrapper en die linkse schikking staat kennelijk al lang uitgelegd. In de bewerktekst van wrapper/documentatie staat er ook een regel: "<br clear="all" />", voor mij intrigerend. Misschien even goede extra-regel als Clearleft om alle bewerklinks bij het wrappergebruik goed te krijgen. Zoals het nu is, is het prima. Misschien probeer ik ook es (als experiment) om de andere twee foto's rechts te krijgen: twee wrappers gebruiken dus (volledig volgens de richtlijnen op de sjabloonpagina ditmaal).RobSchop [geef een gil!] 13 jul 2009 17:26 (CEST)

Ik had idd helemaal niet gekeken naar de plaatsing van de foto's, alleen of de bewerklink goed stond. Het waarom is me nu duidelijk. "<br clear="all" />" is een combinatie van "<br clear="left" />" en "<br clear="right" />"; de tekst gaat dus verder onder alle plaatjes, zowel links als rechts. Maar met deze clearacties krijg je op brede schermen grote witte vlakken, dat is dan weer een bezwaar. Je kunt het effect ook op smallere schermen bekijken door de lettergrootte te verkleinen. -- LexTH overleg  13 jul 2009 19:22 (CEST)

Alleen ontgaat me het verband tussen de naam van het commando en het resultaat: begrijp ik het goed dat Clearleft zorgt voor die witruimte rechts van de TOC? Dan zou ik toch als leek Clearright vragen. Zonder die witruimte (en het Clearleft) staat de 1e bewerklink alvast weer verkeerd.--RobSchop [geef een gil!] 16 jul 2009 22:17 (CEST)

Clearleft schuift de tekst eronder op totdat de linkerkant leeg is (dus in dit geval tot onder de inhoudsopgave). Zonder clearleft staat die eerste bewerklink bij hogere resoluties of brede schermen inderdaad verkeerd. Als de witruimte storend is, zou de inhoudsopgave wel langs de intro kunnen. Maar bij gewone wikipedia artikelen staat de inhoud onder het intro. Vandaar dat ik dat ook op die manier gedaan had. Wat natuurlijk ook kan, is de afbeeldingen lager zetten, bijvoorbeeld bij het kopje Bereidingen van methylfenidaat. ∼ Wimmel 16 jul 2009 22:35 (CEST)

Breek nu mijn klomp! 't Lijkt of de afgedwongen TOClinks zorgde voor die eerste foute positie: gewoon allebei gewist en alles staat ook goed!.--RobSchop [geef een gil!] 19 jul 2009 20:11 (CEST)

Ik vind nu op de en.wikipedia bij my preferences/gadgets (die enorm zijn toegenomen) deze: "Moves edit links next to the section headers" en een link naar: Dritlnoths tools. Werkt dit zonder verdere omhaal ook in onze nl.wikipedia? Indien ja, wie voegt dit aan onze "Uitbreidingen" toe? Het is wellicht dé oplossing om voor FF en Gchrome niet voortdurend die wrapper te moeten gebruiken. N.B. De Duitse heeft ze al zo lang "standaard" naast de koptitels: De Duitse WP gebruikt een hack (in Javascript) die goed lijkt te werken, maar desondanks niet algemeen ingevoerd is. (i.v.m. "bearbeiten" direct na elke koptitel) -- Erik Baas 17 jan 2007 03:45 (CET) in Gebruiker:RobSchop/Opstekers#Afbeeldingen --RobSchop [geef een gil!] 4 aug 2009 10:31 (CEST)

Ja, dat is vrijwel zeker ongewijzigd danwel met een kleine aanpassing ook hier te gebruiken. Maar als je dat voor jezelf als gadget installeert, lost het voor jou dit probleem op, maar hebben anderen, die dit gadget niet gebruiken, nog steeds hetzelfde probleem. Het kan ook voor iedereen geïnstalleerd worden maar dan zal er vast een boel tegenstand komen.... ∼ Wimmel 13 sep 2009 20:03 (CEST)

'k Heb het tekstje erover (nog es) bekeken en het verschil is wel dat je het in de Engelse W als gadget kunt aanvinken, in de Nederlandse W dus nog niet. Ik zou die "import" in mijn monobook kunnen zetten, maar 'k denk dat ik het zo ga laten: 1) van dan af zie ik idd niet meer wanneer anderen fout geplaatste bewerklinks zien; 2) mijn indruk is dat lefteditlinks javascriptcode enkel commandeert om de goed staande bewerklinks bij de koptitel te zetten...maar als die foute, of beter, te correcte interpretatie door FF en GChrome roet in 't eten gooit, blijft dat misschien wel doorwerken voor Drilnoths jscode, vindt die m.a.w. de te verplaatsen editlink niet. Wat er ook van zij, het zou goed zijn als een itc'er-wiki'er als jij die optie zou toevoegen aan de voorkeuren, tabblad Uitbreidingen. Die "boel tegenstand" snap ik in dit specifieke geval wel niet: wie daarop tegen zou zijn, zou toch wel èrruug om het uitzicht bekommerd zijn of hééél principieel moeten zijn.--RobSchop [geef een gil!] 13 sep 2009 22:34 (CEST)

Een gadget maken zal niet op tegenstand stuiten. Maar het voor iedereen gaan invoeren denk ik wel. Toen op de Volglijst nieuwe functionaliteit beschikbaar kwam zoals het wet weergeven van de pagina's die zijn bewerkt sinds het laatste bezoek, werd dat binnen een dag weer uitgeschakeld.

Gadgets toevoegen kunnen alleen moderatoren. Ik zou hoogstens kunnen uitzoeken hoe dat werkt, en dat kunnen voorbereiden. Maar als ik dat goed doe, moet ik toch testen op een (eigen) wiki. Met bitnami is dat wel vrij simpel op te zetten, maar ik vind dat toch nog te veel moeite. Dus dat houd het voor mij al snel op, er zijn andere dingen die ik belangrijker vind. ∼ Wimmel 16 sep 2009 19:57 (CEST)