Overleg gebruiker:LexTH/Archief1

Hallo LexTH, welkom en veel plezier op wikipedia. Misschien helpen deze links een beetje bij de eerste stappen.

• Wikipedia:Welkom voor nieuwelingen
• Portaal:Gebruikersportaal
• Wikipedia:conventies
• Wikipedia:Beleid voor gebruik van media
• Hier kan geoefend worden
• Help:Uitleg
• Bij verdere vragen bijvoorbeeld hier: mijn overleg

Succes pjetter 21 dec 2005 22:51 (CET)

Revolutionaire kalender

Lex, misschien moeten we nog niet direct denken aan een nieuw subartikel voor de schrikkeljaren, zie Overleg:Franse Republikeinse Kalender. Door het opwaarderen van het kopje "toepassing vandaag" naar "schrikkeljaren" kan het uitgroeien tot een volwaardig onderdeel van het artikel. Vriendelijke groeten, -rikipedia 31 dec 2007 17:18 (CET)

RhB

De veranderingen aan de links van de RhB waren niet nodig omdat ik alle andere namen via hulp paginas had doorgelinkt. Spoorjan 24 feb 2008 18:37 (CET)

Het is beter om doorlinken te vermijden. Je komt er wel, maar het is een extra slag, en sommige wikipediahandelingen kijken er niet doorheen. Daarom wordt je verzocht om, als je een doorverwijspagina maakt, de verwijzingen aan te passen. - LexTH 24 feb 2008 18:53 (CET)

Testsjabloon

Hallo LexTH, je kunt in je eigen naamruimte (Gebruiker:LexT H/...) sjablonen aanmaken voor test doeleinden. Sjablonen hoeven geen voorvoegsel (naamruimte) "Sjabloon" te hebben om sjabloon te zijn. Omdat het voor jou persoonlijk een sjabloon is heb ik daarom je sjabloon verplaatst naar: Gebruiker:LexT H/Test. Groetjes - Romaine (overleg) 18 jun 2008 01:33 (CEST)

Verwijderingsnominatie Republikeins kalenderblad

Beste LexTH, één of meerdere pagina's die u hebt gestart zijn genomineerd voor verwijdering. Dit betekent dat iemand het artikel op dit moment niet geschikt acht voor Wikipedia. Het gaat om Republikeins kalenderblad. De reden hiervoor staat op Wikipedia:Te verwijderen pagina's/Toegevoegd 20080707 en dat is ook de plek waar u kunt reageren op de verwijderingsnominatie. Wellicht hebt u er iets aan om de conventies door te lezen; daar kunt u zien hoe een artikel er uit hoort te zien. Aangezien dit bericht automatisch is geplaatst, heeft het geen zin hier te reageren. Als u vragen hebt, kun u die stellen op Help:Helpdesk. --E85Bot 8 jul 2008 02:16 (CEST)

Verwijderingsnominatie Franse Republikeinse Kalender/kalenderblad

Beste LexTH, één of meerdere pagina's die u hebt gestart zijn genomineerd voor verwijdering. Dit betekent dat iemand het artikel op dit moment niet geschikt acht voor Wikipedia. Het gaat om Franse Republikeinse Kalender/kalenderblad. De reden hiervoor staat op Wikipedia:Te verwijderen pagina's/Toegevoegd 20080826 en dat is ook de plek waar u kunt reageren op de verwijderingsnominatie. Wellicht hebt u er iets aan om de conventies door te lezen; daar kunt u zien hoe een artikel er uit hoort te zien. Aangezien dit bericht automatisch is geplaatst, heeft het geen zin hier te reageren. Als u vragen hebt, kun u die stellen op Help:Helpdesk. --E85Bot 27 aug 2008 02:19 (CEST)

Schijnnauwkeurigheid

Het uiteraard volkomen met U eens, beste LexTH. U had me niet beter kunnen verbeteren, dan met deze zeer aangename voortreffelijke afronding, die ik het hele vorige jaar al heb voorgesteld, met name gericht op de absurde maatvoering inzake het rollend materieel van het Openbaar Vervoer. Het is de significante kroon op mijn pleidooi. Hartelijk dank ervoor met vriendelijke groet, in de hoop dat zekere zappagrammen en yiotameters en hun "infobox"-tabelvormen, óók nog eens aangepakt mogen worden. D.A. Borgdorff ic 86.83.155.44 5 jan 2009 18:39 (CET)

Beste dAb, bedankt voor de lof, die me wel wat overdreven voorkomt aangezien het maar een miniatuurwijziging betreft. Waarbij ik me bovendien heb laten inspireren door uw eigen strijd tegen de maatvoering bij het rollend materieel. Ik was daar ook net de term schijnnauwkeurigheid tegengekomen, en die sprak kennelijk erg aan.

Aangezien U niet onder een gebruikersnaam schrijft kan ik dit niet op uw eigen gebruikerspagina plaatsen. Ik vraag me echter af of U voor het lezen niet toch van een gebruikerspagina gebruik maakt omdat het volgen zonder daarbij een volglijst te kunnen gebruiken me erg moeilijk lijkt.

Met vriendelijke groet van een nieuwsgierige --LexTH 6 jan 2009 02:01 (CET)

Wel waarde Lex, ik doe bijna alles uit mijn geheugen, "uit mijn hoofd", net zoals ik 10 december vorig jaar op het overleg:Constante van Dirac tegen Madyno grapte, maar ook serieuzer, na een opmerking ruim één jaar eerder te 4 dec 2007 14:32 (CET) van gebruiker:Brinkie op mijn nogal bizar gearchiveeerde pagina's, als overleg gebruiker:86.83.155.44/archief5, in zgn. "zelfrefs", na vragen over de Titulatuur van de geachte (militaire) collega gebruiker:Tdevries, wiens nadere dergelijke geheugen-opmerkingen ik verderop behandeld heb in (dit: nu genoemde) mijn aldaar gearchiveerde overleg onder paragraaf "Tip" begin maart 2008 én waarvan tevens blijk gegeven op het actuele, doch controversiële overleg Wikipedia: de kritische noot, dat evenals mijn reeds gearchiveerd overleg interessant leesvoer blijft bevatten. Na deze openingszin en korter gezegd, bewerk ik (telkenmale) de (inmiddels) talloze Hoofd- en Overlegnaamruimten nog steeds uit mijn Hoofd, zonder een volglijst 'ofzo' van node te hebben. Ook in circa een dozijn buitenlands-talige Wikipediae gaat het niet anders, hoewel ik daar aanzienlijk minder edits pleeg te doen. In hoop enzovoorts, zij U nogmaals voor Uw belangstelling hartelijk dank betuigd, met beste groeten van: dAb \ 86.83.155.44 6 jan 2009 13:36 (CET) → PS: Helaas zijn nagenoeg vijf maanden geleden op 13 augustus 's avonds uit rancune: bijna alle toen geplaatste referenties, zoals bijvoorbeeld op de elektrische tram, door de bureaucraat M2 gewist, maar gelukkig hoopt de ook genoemde deskundige collega-publicist Ab van Donselaar met het dit jaar te verschijnen tweede deel, het standaardwerk over de HTM te voltooien. (dAb) 86.83.155.44 6 jan 2009 14:36 (CET)

SI-eenheden

Je maakt er wat moois van hè? Ik zal me er niet mee bemoeien, maar ik heb mijn twijfels over het maximum dat jij wilt opegeven. Een microfarad is heel gewoon, een megafarad niet. Je kunt dus niet zomaar het maximum op ±6 zetten.

Het is altijd mijn bedoeling geweest dat het maximum automatisch bepaald wordt door het wel of niet bestaan van de artikelen. Dat werkte niet helemaal goed. Het was daarvoor namelijk nodig dat een aantal nutteloze artikelen verwijderd werden, en dat voorstel werd door de gemeenschap getorpedeerd.

Er was zelfs iemand zo optimistisch mijn medewerking te vragen om er redirects van te maken. Die medewerking weigerde ik natuurlijk en toen deed hij het zelf. Ik heb toen de handdoek maar in de ring gegooid. (zie het eerste bericht op mijn OP) Handige Harrie 11 jan 2009 22:55 (CET)

Ja, ik weet ook dat het niet idaal is om één grens te trekken voor veelvouden en fracties. Maar aparte waarden maakt het ingewikkelder, en maakt de tabel niet kleiner. Onder het hoofdje direct hierboven noemt Borgdorff het probleem met die onzinnige eenheden. Ik begreep het eerst niet, maar inmiddels heb ik je commentaren hierover gelezen. Als het dan niet lukt via de verwijderweg kunnen we in ieder geval een eind komen op deze manier. Dan zijn de tabellen iig niet groter dan nuttig is, al bevatten ze nog wel onzinnige waarden in de andere kolom.

Ik heb geen eigen grens getrokken, maar de redirects als richtsnoer genomen. Als beide zijden nog slechts redirects bevatten doet een rij nu niet meer mee. Je kunt trouwens bij elke aanroep van het sjabloon een waarde opgeven; die wint van de verstekwaarde. Dat wordt ook toegepast op de sjabloonpagina zelf. Daar worden de tabellen niet afgekapt.

Heb je trouwens gezien dat de nieuwe sjablonen wel hun uitvoer tonen? Dat maakt het makkelijker om te zien of een wijziging foutmeldingen oplevert. --LexTH 11 jan 2009 23:31 (CET)

Het leuke is namelijk dat de tabellen automatisch worden uitgebreid als er een artikel bij wordt gemaakt. Het liefst zou ik een redirect willen beschouwen als een niet-bestaand artikel, maar de mogelijkheden zijn beperkt. Handige Harrie 12 jan 2009 00:53 (CET)

Ja, en dat principe is ook gehandhaafd. Alleen ga ik er maar van uit dat als van een bepaalde waarde een redirect is gemaakt het om een onzinnige eenheid gaat. En als er wel een zinnig artikel met die naam komt moet er maar een aanpassing volgen; ofwel op de pagina's over die eenheid steeds max opgeven, ofwel de regel in Sjabloon:SI-eenheden/max aanpassen.

Ik ben het trouwens met je eens dat een redirect als een niet-bestaand artikel beschouwen het mooiste is. Daar had ik ook al aan gedacht, maar ik weet niet of het kan, en zo ja, of het dan niet heel ingewikkeld is. Als er echter een eenvoudige test zou bestaan denk ik wel het te kunnen implementeren. --LexTH 12 jan 2009 00:59 (CET)

Die aanpassing bevalt me niet - het zou vanzelf moeten gaan. Jouw max is dan ook niet nodig.

Ja, testen op redirect zou het mooist zijn - als het kon.

Ik heb inmiddels, op verzoek van WP:K een defaultwaarde voor max opgegeven. De pagina's are en hectare en centiare zagen er niet uit. Ik begrijp niet waardoor het kwam dat andere pagina's er geen last van hadden. Handige Harrie 12 jan 2009 12:03 (CET)

Ik heb eerst in de kroeg gekeken, en daar een antwoord geschreven. Pas daarna heb ik gekeken wat jij gewijzigd hebt in het sjabloon. Dat wijst erop dat het inderdaad vanzelf in orde gekomen is, want jouw wijziging kan daar niet bij geholpen hebben. Uiteindelijk zijn alleen verstekwaarden van 80 voor max aangebracht in Sjabloon:SI-eenheden/LR, en dat kan alleen helpen als max nog niet bestaat, dus als je het sjabloon rechtstreeks aanroept. In de normale praktijk wordt echter altijd een max meegegeven, want de aanroep komt alleen uit Sjabloon:SI-eenheden, en dat vult max altijd in. Ik zal echter een rechtstreekse verwijzing naar hectare aanbrengen, want nu kom je er via hectoare. --LexTH 12 jan 2009 14:45 (CET)

De verdwenen uitzondering voor hectare verbaasde me, want daar had ik nooit iets van gezien. Ik ben uitgegaan van de versie van sjabloon:SI-eenheden/LR van 7 jan, en daar was hij al gesneuveld. Ook in sjabloon:SI-eenheden/3 komt hij niet voor. Oudere versies had ik nooit bekeken. Via een redirect kwam je er toch, al stond in de tabel nu wel hectoare. Maar gelukkig had ik met vooruitziende blik ook al voor de linkerkolom een uitzonderingsmogelijkheid ingebouwd, zodat hectare eenvoudig kon worden ingevuld. Nu ziet het er weer goed uit. --LexTH 12 jan 2009 16:56 (CET)

Opslaan artikelen

Beste LexTH, zoals ik al bij Bertus heb geantwoord, weet ik nu dat dit probleem niet alleen bij mij is. Voor alle zekerheid zet ik mijn artikel altijd eerst op wordpad, en daarna alles in mijn (Gebruiker:Renegade/concept...). Daarna verbeter ik nog eens alles en zet er de categoriën, extra links, enz... bij. Hopelijk gaat dit 'probleem' wel opgelost geraken. Groeten Renegade 20 jan 2009 - 13:08 (CET)

wijlen hoort niet thuis op Wiki.

Hi, ik zag net jouw verbetering, helemaal mee eens. Aangezien er per definitie een waardeoordeel van uitgaat. Ik wou net alle wijlens gaan verwijderen, heb er een stuk of 20 gedaan, totdat ik zag dat het in totaal 429 voorkomt. Wel erg veel om handmatig te doen... Weet jij hoe we een bot kunnen aanvragen zodat ze allemaal automatisch weggaan? Groet, vels 23 jan 2009 23:39 (CET)

Ik denk dat een robotactie niet mogelijk is, omdat niet alle "wijlen"s geschrapt kunnen worden. Een voorbeeld vind ik het door jou geschrapte wijlen in Carolina van Oranje-Nassau, waar je volgens mij in een letterlijk citaat geschrapt hebt. Ook kwam ik een "Jos van Wijlen" tegen. --LexTH 24 jan 2009 00:19 (CET)

Nog een uitzondering in SI-eenheden

Hoi Lex, ik heb een kleine verandering aangebracht in Sjabloon:SI-eenheden/1, maar dat had niet het gewenste effect. Jij weet natuurlijk veel beter dan ik wat er veranderen moet.

Het probleem zit in mega-annum en giga-annum, waar een streepje in staat.

Dank bij voorbaat. Handige Harrie 24 jan 2009 21:28 (CET)

Er waren twee problemen:

1. Je moet bij link de complete linktekst, dus inclusief de getoonde tekst opgeven. Dit omdat de getoonde tekst af moet kunnen wijken van het systeem. Ingevoerd wegens 'hectare', en hier ook noodzakelijk.
2. Er bestonden geen pagina's met de standaardnaam. Daarom heb ik die doorverwijspagina's nu gemaakt. Ik vind het trouwens ook wel logisch om zo'n dp te hebben.

Gelukkig had ik de voorziening voor een tweede afwijkende link al ingebouwd. Nu kon de tweede link zo ingevuld worden. Een derde kan trouwens indien nodig zo toegevoegd worden, nu het systeem met de switches al bestaat. Dat is veel makkelijker uit te breiden dan als het met #if's geregeld is. --LexTH 24 jan 2009 22:46 (CET)

Vreemde pagina's

Hallo LexTH, Ik kwam een serie pagina's van jou hand tegen Speciaal:Voorvoegselindex/Franse_Republikeinse_Kalender/ die in de artikelnaamruimte staan, maar niet voldoen aan de eisen die aan een artikel worden gesteld. Sjablonen zijn het zo te zien ook niet want ze worden nergens ingevoegd. Kun jij er iets mee doen? Anders plaats ik ze denk ik op de verwijderlijst, omdat ze in hun huidige toestand niet zo lijken te kunnen blijven bestaan. Groetjes - Romaine (overleg) 3 feb 2009 19:28 (CET)

Dag Romaine, deze pagina's kunnen niet gemist worden. Het zijn inderdaad geen artikelen op zichzelf, maar het zijn dan ook subpagina's van Franse Republikeinse Kalender. In dit artikel, en ook in de bijbehorende artikelen over de maanden, staat een kalenderblad afgebeeld: {{Republikeinse Kalender}}. Middenonder kun je een van die pagina's aanklikken, en dan krijg je een jaarkalender. Omdat de pagina's altijd via deze weg bereikt worden is een nadere uitleg niet nodig. Het is precies duidelijk wat er bedoeld wordt, en meer uitleg stoort alleen maar. In een eerdere versie had ik die pagina's sjabloon genoemd, maar dan komt dat ook boven de kalender te staan, en dat is niet zo mooi.

Nog mooier zou zijn als het sjabloon facultatief, na aanklikken dus, getoond kon worden op de pagina zelf. Maar daar voorziet het systeem niet in, of weet jij misschien een manier? Ik bedoel hier niet een uitklapsjabloon, want dan wordt de kalender altijd berekend, ook als hij niet getoond wordt. En dat is veel werk.

De pagina's zijn dan wel niet rechtstreeks ingevoegd, maar als je "links naar deze pagina" opvraagt zie je dat ze wel degelijk op die pagina's gebruikt worden. En bij de statistieken kun je zien dat ze geregeld opgevraagd worden. Er is dus echt belangstelling voor. --LexTH 3 feb 2009 20:03 (CET)

Ok, dat zet deze pagina's in een helderder perspectief. Toch, en dit is op ieder pagina het geval, staat er minstens 1 openingszin die verklaart wat de inhoud van de pagina is. Ook al zou je hier wellicht kunnen volstaan met een openingszin die op ieder van deze pagina's vrijwel hetzelfde is, mijn verzoek is of je die openingszin op de pagina's zou kunnen toevoegen. Via google en de categorieën kan iemand zonder de essentiële basisinformatie gezien te hebben toch op deze pagina terecht komen. Op de wiki kennen we geen bijlages, maar uitsluitend op zichzelf staande pagina's die altijd beginnen met een openingszin. Zodoende mijn vraag/verzoek of je dit kunt toevoegen? Groetjes - Romaine (overleg) 3 feb 2009 21:19 (CET)

Bedankt!! :-) Romaine (overleg) 4 feb 2009 16:01 (CET)

1. Ja, hoewel ik eerst liever helemaal geen tekst bij de kalender had heb ik er zo wel vrede mee. Het geeft bij de meeste jaren toch nog net een beetje specifieke informatie. Toch zijn het natuurlijk geen volwaardige artikelen. Dat moet ook niet, omdat het de bedoeling is dat de jaarkalender direct in beeld komt, en de tekst onder de lange kalender is ook niets.
2. Nu was een van de redenen voor de toevoeging dat lezers er via de categorieën terecht kunnen komen. Dat was eerst nogal onwaarschijnlijk, want toen stonden ze bij de sjablonen, waar ze m.i. ook thuishoren. Het zijn pseudo-sjablonen omdat ze dienen als alternatief voor een aanklikbaar sjabloon, dat helaas niet bestaat. Aanvankelijk zijn het ook echte sjablonen geweest, maar omdat ze in de lijst van ongebruikte sjablonen verschenen heb ik ze sjabloon-af gemaakt. Is er bezwaar om ze weer bij de sjablonen neer te zetten?
3. Je hebt (elders) wel eens {{PAGENAME}} weggehaald uit een categorietoewijzing aan een sjabloon, en vervangen door een identieke vaste tekst. Waarom is dat? Ik vind het makkelijk bij het aanmaken en verplaatsen van code in een reeks samenhangende sjablonen. --LexTH 4 feb 2009 20:01 (CET)

1. In principe had de intro ook korter gekund, met alleen een zin dat deze pagina bij die kalender hoort + wat deze pagina specifiek weergeeft.
2. Ik kwam de pagina's juist tegen omdat we bezig zijn de sjablooncategorieën op te schonen en zuiver voor sjablonen te houden. Sjablonen horen niet in artikelcategorieën thuis en pagina's anders dan in de sjabloonnaamruimte niet in sjablooncategorieën. Pseudosjablonen kennen we niet. De eigenschappen van een sjabloon zijn: staat in sjabloonnaamruimte, wordt op pagina's ingevoegd, en wordt niet naar gelinkt. Voldoet aan alle drie niet en horen dus ook niet in een sjablonencategorie te staan. Ik hoop dus dat we ze zo kunnen laten staan. Ik ben eerlijk gezegd erg blij dat in mijn ogen dat pagina's nu op orde zijn, want er zat echt iets scheef voor mijn gevoel.
3. Op de betreffende pagina's waar we het hier over hebben wilde ik ze liever onder de Y (=achteraan) ordenen. Als je het hebt waarom ik het elders weghaal. Veelvuldig zijn er klachten dat het bewerken van pagina's en sjablonen steeds moeilijker zou worden en complexer. Omdat ik veel met sjablonen te maken heb en daarin qua beleid tracht aan te houden wat de gemeenschap wil, heb ik een aantal doelen gesteld. Een van de dingen die ik doe is het zo veel mogelijk versimpelen van pagina's en sjablonen. Er zijn veel gebruikers die deze magische woorden niet kennen en vaak genoeg ook niet begrijpen. Ik hou dus de uitgangspunten simpel en functioneel aan in het werken op de wiki. Op sjablonen is PAGENAME sowieso een gruwel, omdat ze daar in 95% van de gevallen een sjabloon niet goed categoriseren (omdat die beginnen met bv navigatie/infobox) en ook daar ik het voor gebruikers simpel wil houden. In artikelen zelf zijn magische woorden sowieso een taboe. Groetjes - Romaine (overleg) 4 feb 2009 21:17 (CET)

Sjabloon:Infobox honkbalspeler

Hoi, Ik wilde de breedte van de linkerkolom zodanig breed maken dat de langste term (vermoedelijk : "Most Valuable Player") op 1 regel kon. Dat was ook gelukt, maar kennelijk veroorzaakte het toevoegen van de width parameter weer andere problemen. Mischien weet jij er iets op? Magalhães 3 feb 2009 20:50 (CET)

De termen in de linkerkolom worden nu niet meer onderbroken. Aanvankelijk had ik een pixelbreedte opgegeven in de bedreigde cellen, maar later bedacht ik dat het beter is de woorden met no-brake spaces aan elkaar te koppelen. Dan wordt er precies de nodige breedte geclaimd, en niet meer.

Ik heb meteen wat overbodige dingen weggehaald, waaronder ook zaken die ik zelf ingevoerd had, zoals het voorwaardelijk afdrukken van de naam en de persoonlijke-informatiekop. Die zijn er immers altijd wel, anders is het sjabloon zinloos. --LexTH 4 feb 2009 01:42 (CET)

Bedankt! groeten Magalhães 4 feb 2009 06:45 (CET)

GB en GiB

Ik ben nieuwsgierig over dit edit. Over welk verzoek gaat het precies? Bij voorbaat dank. Thunderbird2 16 feb 2009 18:59 (CET)

Het gaan hierom: Wikipedia:De kroeg#omrekenhulp gevraagd. Hoewel ik eigenlijk vind dat de informatie er al staat blijkt het toch te moeilijk te zijn. Dus voor degenen die willen weten hoeveel MB er past op 2 GB is het nu makkelijker te vinden. --LexTH 16 feb 2009 19:19 (CET)

Simpele wekker/timer

Hallo LexTH, Een wekker kan vele malen simpeler, we gebruiken hem namelijk al langere tijd. Het kan door (eventueel zonder de zachterste nullen): Na . En dat werkt gewoon goed en eenvoudig. Groetjes - Romaine (overleg) 21 feb 2009 23:37 (CET)

Dag Romaine, hoe bedoel je dat? Is er al een sjabloon met deze functie? Ik vind trouwens {{Wekker|090301|tekst}} al erg simpel. Dat je er een tijdstip bij kunt zetten is gewoon een extraatje dat je niet hoeft te gebruiken, evenals de facultatieve verschuiving met een aantal dagen. Dat kan echter handig zijn, als je bijvoorbeeld 100 dagen na vandaag wilt opgeven. --LexTH 21 feb 2009 23:54 (CET)

Niettemin, de tijd wordt nu alleen nog getoond als je die speciaal opgegeven hebt, in de vorm van hhmm of als een verschuiving met een niet-geheel aantal dagen. Dat is idd mooier. --LexTH 22 feb 2009 00:44 (CET)

Hallo LexTH, ik bedoel de te zeggen dat de code van het sjabloon simpeler kan, zonder zomer/wintertijd aanpassing oa, omdat daar vanuit het systeem ook rekening mee gehouden wordt. Wat je hebt gemaakt bestaat niet in een sjabloon, omdat een simpele parserfunctie effectief goenoeg is. Groetjes - Romaine (overleg) 22 feb 2009 02:06 (CET)

Nee, dat is te eenvoudig gedacht. Je kunt met LOCAL wel tijden uitvoeren, maar niet invoeren. Als je tijden in een parserfunctie wilt invoeren zit je vast aan UTC. En dan heb je zomer- en wintertijd nodig. Voor de verschuiving in dagen moet je vergelijken met een continu veranderende grootheid, en dat is alleen de secondefunctie, en die is niet beschikbaar in LOCAL. Bovendien kun je zo facultatief een tijdstip meegeven, en dat is iig veel ingewikkelder als je het met andere parserfuncties wilt oplossen. Natuurlijk kun je hetzelfde direct bereiken, maar dan moet je gewoon de sjabloon nadoen. Je kunt wel vereenvoudigen door bijvoorbeeld de kleur en het kader weg te laten, maar daarmee tast je de effectiviteit aan. Nu wordt er juist optimaal gebruik gemaakt van de sjabloonfunctie: zeer simpele code voor de gebruiker, met als je dat wilt nog wat extra, en automatisch een zeer duidelijk verschil tussen voor en na de omschakeldag.--LexTH 22 feb 2009 02:37 (CET)

wat een werk!

Doe niet te veel moeite. Als je ongerechtigheden vindt in de isotopentabel, zeg het me dan en dan draai ik het computerprogramma even over. Doe je dat niet, dan loop je het risico dat de foutjes terugkomen als ik zelf wat verbeter. Handige Harrie 24 feb 2009 14:10 (CET)

Aha, ik wist niet dat het bij jou uit een computer kwam. Ik heb de eerste twee kolommen verwijderd. Daartoe zijn alle colspans met 2 verlaagd, en bij de eerste drie regels zelfs helemaal verwijderd.

Bovendien heb ik wat ongerechtigheden eruit gehaald, die staan in de andere edits. In de eerste alinea moet de kleurenuitleg nog aangepast worden aan wat je veranderd hebt. Denk je ook nog aan de zustertabellen? Vermoedelijk is dat voor jou veel minder werk met je computerprogramma.

Het valt me net op dat vroeger de protonen- en neutronenaantallen werden aangegeven. Nu niet meer, maar het zijn wel nuttige gegevens. Kun jij dat ook in je computerprogramma erbij zetten, of is dat toch handwerk? --LexTH 24 feb 2009 14:54 (CET)

Harrie, bij Help werd geklaagd over de kleuren, die te fel zouden zijn en de tekst moeilijk leesbaar maken. Technisch is het goed mogelijk i.p.v. kleuren een eenvoudige code mee te geven voor de halfwaardetijdklasse, bijvoorbeeld 1-10 of a-k. Die code kan dan ook in de tabel gezet worden. Dan kunnen de kleuren zachter worden, want als je in de legenda op wilt zoeken welke klasse het is kun je dat via de code doen. Het biedt nog het voordeel dat je de kleuren dan in de sjabloon kunt wijzigen, zonder de tabel te veranderen. Nadeel is natuurlijk dat de tabel wat groter en drukker wordt. Hoe denk jij daarover? --LexTH 24 feb 2009 18:10 (CET)

Met de hieronder vermelde wijziging kun je kleuren veel makkelijker aanpassen. Ik wil zelf een steeds helderder kleur naarmate de isotoop labieler is, dus zwart (niet rood) voor stabiele isotopen.

De zustertabellen kunnen later. Ik wil dit eerst goed hebben.

Ja de protonen en neutronen staan er niet meer in. Daar moet ik nog mee aan 't werk. En ik zit momenteel maar een uurtje per dag aan Wikipedia. Handige Harrie 25 feb 2009 00:37 (CET)

kortere kleurcodes

Hoi Lex, ik heb in Sjabloon:Isotoop de mogelijkheid ingebouwd de kleur met een enkel cijfertje op te geven. De code in het hoofdartikel wordt dan een stuk kleiner. Ik heb ook geprobeerd witte tekst te maken als de achtergrond donker is, maar dat heb ik nog niet aan de praat gekregen. Handige Harrie 25 feb 2009 00:33 (CET)

Ha Handige Harrie, ik heb zojuist de laatste hand gelegd aan de bijbehorende sjabloon. Deze toont de code onder het massagetal. Ik gebruik als code de letters abcdefhi omdat die klein zijn en geen staart hebben Maar wellicht kan een extra klein cijfer ook, dat zal ik nog even proberen. Ik vind die met de letters beter. Nog iets: als het vakje eenkleurig is moet er maar een codeletter opgegeven worden, anders krijg je dubbele letters. Als dit voor jou te moeilijk is kan ik het ook wel onderscheppen, maar dat betekent extra te doorlopen code, en dat heel vaak bij elke vertoning. --LexTH 25 feb 2009 01:11 (CET)

Ik moet nog even leren eerst jouw overleg te lezen voor ik zelf een nieuw bericht schrijf. Die letters zijn dus weer weg. Maar wat is de betekenis van de letters? Handige Harrie 25 feb 2009 12:37 (CET)

Sorry

Lex, toen ik mijn werk van vannacht wilde voortzetten, merkte ik dat jij intussen ook wat aan het sjabloon had veranderd. Ik snapte er niks meer van, maar wat ik wel snapte was dat de Isotopentabel na mijn geplande wijziging niet meer klopte. Ik heb daarom jouw wijzigingen van vannacht teruggedraaid en ben verder gegaan met mijn eigen versie van ongeveer middernacht. Handige Harrie 25 feb 2009 12:33 (CET)

Ja, we hebben een beetje langs elkaar heengewerkt. Ik wil een kleurcode linksonder tonen zonder dat het vakje noemenswaardig groter wordt. Daar heb ik heel lang aan zitten prutsen, maar uiteindelijk is het gelukt. Intussen probeerde jij witte letters te maken, maar dat heb ik er ook al in verwerkt. Alleen wil ik de code in letters, omdat dat minder verwarring schept.

Ik gebruik nu

i instabiel
a )
b )
c ) oplopende halfwaardetijd
d )
e )
n natuurlijk radioactief
s stabiel

Ik vind zwart voor rood een mooie verbetering. En in de code zijn cijfers wel duidelijker dan lettercode. Toch lijkt me een aanduiding in de blokjes wel zinvol, althans voor de gekleurde vakjes. Bij stabiel en instabiel kan het waarschijnlijk beter worden weggelaten. Ik zal daarnaar kijken. Als de code toch niet zonder meer zelf wordt getoond maakt het niet uit of er gecodeerd wordt met cijfers of letters. Ik zal daarom doorgaan met de code zoals die nu is. --LexTH 25 feb 2009 13:11 (CET)

Het lastige is dat er twee soorten activiteit zijn: alfa en beta. Sommige isotopen zijn zowel alfa- als beta-actief, met verschillende halfwaardetijden. Dat zijn dus de tweekleurige hokjes.

Het is misschien wat moeilijk te verdedigen, maar als een isotoop maar een soort activiteit vertoont, bijvoorbeeld alfa, dan is die isotoop voor de andere activiteit stabiel. Het vakje zou dan links gekleurd en rechts zwart moeten zijn.

Een probleem is nog dat ik niet weet of de isotopen alfa-of beta-actief zijn. Bij veel hokjes zijn de kleuren dus verwisseld. Als je dat goed wilt maken ben je nog wel even bezig.

Handige Harrie 25 feb 2009 13:56 (CET)

Ik heb het net klaar. Als er een enkele kleur is wordt maar een code getoond. --LexTH 25 feb 2009 13:59 (CET)

En vanaf heden wordt het vakje dan niet meer in tweeën gedeeld. Er staat dan een alfa of beta in het vakje. Maar er moet nog worden uitgezocht welke precies de alfa- en betastralers zijn. Het sjabloon bestaat nu uit twee delen, waarbij Sjabloon:Isotoop/2 het oorspronkelijke sjabloon is. Handige Harrie 25 feb 2009 18:02 (CET)

Dat lijkt me idd een mooiere opkossing omdat het een rustiger beeld geeft. Ik Heb net ook wat uitgezocht, andere kleuren die ook een rustiger beeld geven. De breedte van de hokjes: Kennelijk had je er moeite mee dat de eerste kolommen te smal werden. Dit kwam doordat je width="4500" in de eerste regel hebt weggehaald. Ik had het juist weer teruggeplaatst voordat ik je opmerking zag. De oplossing komt dus daardoor, niet door een wijziging die jij mogelijk net in de sjabloon hebt aangebracht.

Ik zal alfa-beta en de zachtere kleuren combineren. --LexTH 25 feb 2009 18:10 (CET)

In de oorspronkelijke versie stonden de kleuren op regenboogvolgorde en dat vond ik geen succes. Mijn kleuren waren gebaseerd op: hoe donkerder hoe stabieler. Andere kleuren mogen, maar hud de volgorde intact.

Dat ik width heb weggehaald was per ongeluk. Ik wilde namelijk testen met een miniversie van de tabel en kennelijk heb ik width toen niet meer teruggezet. Ik zie overigens met de complete geen verschil tussen width en geen width. Handige Harrie 25 feb 2009 18:17 (CET)

Ik heb (met Firefox) een duidelijk verschil: zonder width zijn de hokjes niet breder dan de letters die erin staan, ondanks de width per hokje. Wat de kleuren betreft: ik heb het rustiger gemaakt door alle kleuren wat lichter te maken. Dat maakt vooral voor het veel voorkomende zwart een groot verschil. Ik had ze alle gelijke helderheid gegeven, in regenboogvolgorde. Maar voor de beschouwer lijken dan idd sommige kleuren helderder. Ik heb dus grijs voor stabiel, dat is mooi en duidelijk. Voor natuurlijk radioactief had ik rood gekozen, dat leek me wel een mooie aanduiding. Ik ben echter een beetje kleurenblind, en voor mij is rood een donkere kleur. Voor de meesten is het dan misschien te licht. Maar gelukkig zijn wijzigingen nu heel makkelijk aan te brengen, zodat je het rustig kunt proberen. --LexTH 25 feb 2009 18:37 (CET)

Ik had even wat doms gedaan en jij hebt me met een revert bestraft. Het moet nu goed zijn.

Ik heb opzettelijk de heel instabiele isotopen wit gemaakt, dan lopen ze naadloos over in de ongebruikte delen van de tabel - waar de kernen staan die zo instabiel zijn dat ze niet kunnen bestaan. Handige Harrie 25 feb 2009 19:19 (CET)

Ik zie geen witte velden. Die kleuren moeten we gewoon nog wat uitproberen. Iets anders: mij valt net op dat er geen stabiel goud zou zijn, dat lijkt me niet in orde. --LexTH 25 feb 2009 19:31 (CET)

Ja, jij hebt net alle velden een kleurtje gegeven. Maar er zijn nog wel witte velden, bijvoorbeeld 16B en 7He. Dat zijn kernen die zo kort leven dat ze niet kunnen bestaan. Ze zouden dezelfde kleur meoten hebben als de heel erg instabiele kernen, want de grens daartussen is onduidelijk.

Er zijn nog vrijwilligers nodig om de zaak te controleren. Ik heb zelf al een fout bij 14C verbeterd. Handige Harrie 25 feb 2009 19:58 (CET)

Wat betreft de witte velden in het midden: enig onderscheid met de instabielste kernen is er wel, want die zijn wel gemeten en deze niet. Zoals het nu is lijkt het me juist mooi; de kleuren liggen dicht bijeen maar zijn niet helemaal hetzelfde. Wellicht kan de lichtste kleur nog iets lichter worden genomen. --LexTH 25 feb 2009 21:42 (CET)

Doe mij en jezelf een lol en blijf van het hoofdgedeelte van Isotopentabel (compleet) af. Ik verander de gegevens in m'n computerprogramma (dat ik later ook nog wil gebruiken voor de gedeeltelijke tabel) en dan zou ik jouw veranderingen weer ongedaan maken. Dat kan natuurlijk niet de bedoeling zijn. Wil je wat veranderen aan de intro, de legenda, de categorieën enzo, dan is dat prima. Handige Harrie 26 feb 2009 12:45 (CET)

Pardon, ik zie net dat je zojuist aan de legenda hebt gewerkt, niet aan de hoofdtabel. Dat is prima. Ik heb je dus niks te verwijten. Handige Harrie 26 feb 2009 12:48 (CET)

Dat is inderdaad precies wat ik doe. Wat het hoofdgedeelte betreft heb ik nu twee dingen die ik zou willen wijzigen: Van n=.. en p=.. kopjes maken, zodat ze niet tegen de rand aangeplakt zitten. En verder het weer toevoegen van de aanklikbare elementnamen.

Daarnaast heb ik nog een vraag: Inmiddels wordt de in sjabloon2 ontvangen code in alle gevallen getoond; hij wordt alleen omgezet van cijfer- in lettercode. Als de code ook als letttercode in de tabel zou staan is deze omzetting niet meer nodig. Alleen moet de wit/zwartkeuze dan weer met #switch, maar ik denk dat het renderen dan wel sneller wordt. Het is mooi om te zien hoe mijn moeilijkheid om de kleuren te onderscheiden, waarom ik een code wilde toevoegen, geleid heeft tot de toevoeging van alfa, beta en EV. Ik zou het nooit verzonnen hebben, en jij waarschijnlijk ook niet als de structuur er niet al zou zijn. Want het uitvinden hoe je dat klein linksonder krijgt was, althans voor mij, een hele klus. --LexTH 26 feb 2009 13:04 (CET)

Ik vind de cijfers prima. Je kunt er ook nog mee rekenen. Ik ben niet zo enthousiast over jouw letters (de kleur is voldoende) maar ik zal er niet aan knoeien.

Kopjes maken van n en p, je bedoelt met een uitroepteken ervoor, zodat ze vet worden en gecentreerd worden. Goed idee.

Klikbare elementen, ja, dat moet ook nog. Als ik lui ben, maar ik links naar de symbolen (Ag, Pd) en dan kom je meestal op een dp terecht. Toch maar iets ijver tonen. Handige Harrie 26 feb 2009 13:40 (CET)

Isotopen

LexTH, samen met Handige Harrie doe jij de laatste tijd het meeste aan Isotopentabel (compleet). vandaar dat ik jouw mening (en die van Harrie) wil vragen over mijn voorstel op Overleg:Isotopentabel (compleet). KoenB 25 feb 2009 19:42 (CET)

Zou je voor de aardigheid eens een blik willen werpen op Sjabloon:IsotoopI? Ziet dat er goed uit voor jou? KoenB 28 feb 2009 10:48 (CET)

Nee, dat ziet er absoluut niet goed uit voor mij. En ik denk dat ook voor jou de eerste drie kleuren moeilijk te onderscheiden zijn. Je hebt goed begrepen dat kleine roodstappen voor mij onzichtbaar zijn, maar de stappen in de andere kleuren moeten gelijkmatiger verdeeld zijn. Je hebt hier de eerste helderheidsstapjes wel heel erg klein gemaakt. De tweede letter van elk paar doet maar weinig, daarom kun je voor dit doel voor de overzichtelijkheid meestal de eerste gewoon herhalen.

Gelukkig was het idee van Bertux goed uit te voeren. Nu worden standaard jouw kleuren getoond, en zielepieten zoals ik kunnen een ander kleurenpalet kiezen. Uiteraard is het eerste alternatief geheel naar mijn zin, maar voor een andere groep kan eenvoudig nog een setje worden gemaakt. Ik zie nu dat je dat zelfs al gedaan hebt. Mooi. --LexTH 28 feb 2009 12:32 (CET)

Ik volg het ff niet, je verwijderde de inhoud van overleg:istopentabel (compleet), daarna zette je dit op overleg:isotopentabel. Ik heb dit teruggedraaid, en de hele overlegpagina hernoemd. en nu verander je de titel van Isotopentabel in Isotopentabel (compleet)? wat is nu eigenlijk de tiel, waar moet het overleg naartoe, etc, en zou je hiervoor de knop tielwijzigen kunnen gebruiken voor de goede orde? Mvg, Taketa (overleg) 28 feb 2009 17:27 (CET)

Ik denk dat ik zelf ook een fout had gemaakt waardoor ik in de war raakte. Ik heb de verkeerd uitgevoerde titelwijziging hersteld, waardoor Overleg sjabloon:Isotopentabel nu de juiste geschiedenis heeft. Ik weet eigenlijk nog steeds niet waarom dit overleg hernoemd werd? Taketa (overleg) 28 feb 2009 17:43 (CET)

Ik zit er net naar te kijken. Het gaat er om dat de complete tekst van isotopentabel (compleet) verplaatst is naar sjabloon:Isotopentabel (compleet), waardoor nu verschillende kleurversies mogelijk zijn. Omdat alles nu plaatsvindt op deze sjabloonpagina heb ik het overleg ook daarheen verplaatst. Je hebt gelijk dat ik dat met een titelwijziging had moeten doen; ik heb daar domweg niet aan gedacht. Maar zo als het nu is is het misschien wel beter; het overleg heeft betrekking op zowel isotopentabel (compleet) als op isotopentabel (in delen) en de sjabloon. Ik zal een doorverwijzing maken. --LexTH 28 feb 2009 18:00 (CET)

Kijk eens op Gebruiker:Handige Harrie/test en Sjabloon:Isotoop/2. Op die manier kun je de gegevens van een isotoop veranderen en dan verandert het in beide tabellen. Morgen lees ik je antwoord. Handige Harrie 2 mrt 2009 22:31 (CET)

Het is een elegante oplossing om het onderhoud voor de twee tabellen enkelvoudig te maken. Ik zie wel een mogelijk bezwaar, maar ik weet niet hoe ernstig het probleem is. Deze oplossing betekent niet alleen 2007 extra sjabloonaanroepen, die steeds in de lijst opgezocht moeten worden, het betekent bovendien 145 MB extra code om te doorlopen. Ik zal eens kijken of ik daar een testje voor kan bedenken. Of weet jij misschien of dit bezwaarlijk is? Tot enkele maanden geleden zou het in elk geval geblokkeerd worden door de paginalimiet van 1 MB, maar tegenwoordig kan het geloof ik wel; ik weet echter niet hoeveel tijd het kost. De methode van de tabel in 8 stukken knippen heeft dit bezwaar niet. Het nadeel van het niet meer in elkaar schuiven van de tabel in delen kan bij nader inzien grotendeels worden opgelost door de tabel in 16 stukken te knippen.

We hebben dus drie alternatieven

1. Zo laten als het nu is. Het bezwaar is dat alle edits dubbel moeten.
2. De methode via het extra sjabloon met de zeer lange switch-lijst. Mogelijk kost het renderen teveel tijd.
3. De 16 hokken-methode. De pagina in delen wordt iets hoger, maar er hoeft nauwelijks extra code doorlopen te worden.

--LexTH 2 mrt 2009 23:53 (CET)

Om egoïstische redenen ben ik tegen alternatief 3. Ik heb er net zo veel moeite voor gedaan, en dan is het niet leuk als het in de prullenmand verdwijnt.

Het dubbele onderhoud valt trouwens wel mee. Als je ontdekt dat 206Te een andere halveringstijd heeft, dan zoek je 206Te in beide lijsten en verander je het. Dat wordt met 16 hokken niet eenvoudiger.

Of het renderen extra tijd kost betwijfel ik. Ik heb vermoedens dat Wiki de pagina's gerenderd opslaat. Dat wil zeggen, als je een sjabloon verandert, dan worden alle bijbehorende pagina's direct (of de eerste keer als ze worden opgevraagd) gerenderd en daarna niet meer.

O ja, de switch-tabel is opzettelijk per kolom geordend, terwijl een wiki-tabel per rij is. Veel handiger als je iets zoekt, denk ik. Handige Harrie 3 mrt 2009 10:38 (CET)

Dat je tegen alternatief 3 bent kan ik invoelen. Ik had er dan ook nog niets aan gedaan. Wat betreft onderhoud: als het er alleen om gaat op een enkele plaats een waarde te veranderen ben ik het er mee eens. Het verschil doemt vooral op als je ook iets aan de opmaak wilt doen, want dat betekent op beide een grote operatie. Wat het renderen betreft, dat zit iets anders. Ik weet dat doordat Franse Republikeinse Kalender/Yx een enorme rekenpartij is, waarbij je bovendien automatisch een tijdstempel krijgt. Aanvankelijk duurde het nog veel langer, maar ik heb deze versie geoptimaliseerd voor korte rekentijd. Je merkt er duidelijk het verschil tussen een gecachete en een verse pagina. Als de pagina zelf, of een van de aangeroepen sjablonen, bewerkt is wordt een verse pagina gemaakt, die opgeslagen wordt in een cache. Als de pagina opnieuw opgevraagd wordt zonder dat er intussen een bewerking was krijg je de pagina uit de cache, tenzij die er al langere tijd in zit. Op de NL-wiki ligt de grens bij een paar uur, op de engelse kan het wel dagen duren.

Als het omzetten veel werk is moet dus van te voren getest worden of het renderen lang duurt. --LexTH 3 mrt 2009 11:51 (CET)

Ik test nu al geruime tijd een sjabloon met ongeveer evenveel velden als de echte tabel. Maar bijna altijd lukt het opslaan niet. Er komt niet een echte foutmelding, maar de mededeling dat WP problemen ondervindt. Ik denk dat het er mee te maken heeft dat het omzetten te lang duurt. Helaas lijkt de oplossing met de dubbele sjabloonaanroep en de 145 MB code dus niet goed te werken. --LexTH 5 mrt 2009 00:13 (CET)

Je kunt zelf proberen hoe lang het laden van een verse pagina duurt met H/Test?action=purge Dat is dus niet bewerken, maar het laden van de pagina - niet uit de cache - . --LexTH 5 mrt 2009 00:21 (CET)

Jammer

Jammer, dat je niet hebt kunnen wachten, tot we misschien overeenstemming bereikt hebben. Zo maai je het gras voor mijn voeten weg. We zijn het dan misschien nu wel niet met elkaar eens, maar dat betekent niet, dat we nooit een consensus zouden kunnen bereiken. M.vr.gr. brimz 3 mrt 2009 14:30 (CET)

Als je het sjabloon:SI-eenheid (het badwater) wilt verwijderen uit Megawatt, dan ben je welkom. Schrijf maar een verhaal. Maar zet dan wel het kind, dat is {{SI-eenheden|symbol=W|unit=watt|link=watt (eenheid)}} erin.

Handige Harrie 3 mrt 2009 14:37 (CET)

Ah ok. Er zijn dus twee sjablonen, waarvan één mét introductiezin en één slechts tabel, die qua naamgeving wel erg veel op elkaar lijken. Maar ik denk dat ik het snap. Ik heb nu even geen tijd om er een leuk artikeltje van te maken, maar ik zal vanavond eens kijken, of ik er iets moois van kan maken. M.vr.gr. brimz 3 mrt 2009 14:55 (CET)

Romaine is inmiddels al begonnen met de sjablonen uit de artikelen te verwijderen en te vervangen. Hij heeft geen twee weken geduld en hij heeft niet gelezen wat er op Sjabloon:Sjabweg staat: "Het is niet de bedoeling dat het sjabloon al van pagina's verwijderd wordt voordat het uit het systeem is verwijderd." Handige Harrie 5 mrt 2009 23:39 (CET)

Megagram

Hoi Lex, al is het oorspronkelijk mijn sjabloon, jij hebt er meer aan gewerkt. Snap je waarom Megagram niet in het tabelletje van Sjabloon:SI-eenheden staat? Handige Harrie 4 mrt 2009 19:20 (CET)

Ja, kennelijk vond ik het een onzinartikel. Het is op de grens, maar nu staat hij erbij. --LexTH 4 mrt 2009 19:38 (CET)

Ik heb het gezien. In mijn versie van het sjabloon werden alle aanwezige artikelen getoond, onzin of niet. Jij hebt er nog meer ingebouwd, zodat je ze per stuk kunt onderdrukken. Ik weet niet of dat gewenst is, maar we omzeilen daarmee het probleem dat het verwijderen van de onzinartikelen niet lukte. Handige Harrie 4 mrt 2009 23:15 (CET)

Ja, ik heb het noodgedwongen ingebouwd, omdat het verwijderen van de lemma's werd geweigerd. Het staat duidelijk in de gebruiksaanwijzing, en ik meen zelfs dat ik het in ons overleg heb gemeld. Maar ja, jij leest de gebruiksaanwijzing natuurlijk niet, omdat je weet hoe je de sjabloon moet gebruiken. --LexTH 4 mrt 2009 23:34 (CET)

Ik meen vagelijk dat ik me er iets van herinner. Maar je weet hoe het gaat, als je tegen het probleem aanloopt wil dat net niet meer te binnen schieten. Handige Harrie 5 mrt 2009 00:04 (CET)

code-tag

Hallo LexTH, met deze edit draai je grotendeels mijn vorige edit terug. Als je begint met <code> dan hoor je dat toch af te sluiten met </code> of niet soms? - Robotje 9 mrt 2009 09:41 (CET)

Sorry voor die fout, ik heb je verbetering hersteld. De verklaring voor die fout is dat ik eerst maar niet kon zien wat je gewijzigd had. Ik kan rood slecht zien, dus die twee slashes vielen mij niet op. Bij het zoeken heb ik mijn en jouw versie naast elkaar geopend. Toen ik je verbetering gevonden had heb ik nog even een commentaarregel toegevoegd, en daarbij heb ik per ongeluk mijn versie genomen. Het was dus zeker geen opzet om je verbetering ongedaan te maken. --LexTH 9 mrt 2009 10:47 (CET)

Geen probleem, ik heb ook wel eens moeite om kleine verschillen te vinden. Volgende keer is het waarschijnlijk beter als ik ook in de bewerkingssamenvatting vermeld wat ik gedaan heb. - Robotje 9 mrt 2009 10:51 (CET)

Prima, dat is dan opgelost. Zou er een manier zijn om de wijzigingen in blauw weer te geven i.p.v. rood? --LexTH 9 mrt 2009 10:54 (CET)

Bij de Franse Wikipedia wordt het verschil veel duidelijker weergegeven (zie bijv. hier). Maar ook dan kan het lastig zoeken blijven zoals de slash in de "ref/" in deze edit. Hoe je dat voor jezelf kunt regelen kun je misschien beter in Wikipedia:SHEIC (zeg maar de technische 'kroeg') vragen. Om het standaard zo op de Nederlandstalige Wikipedia te krijgen, lijkt me een voorstel in de 'gewone' kroeg meer van de hand liggen. - Robotje 9 mrt 2009 11:01 (CET)

Nee, het is niet mijn bedoeling om het algemeen zo te krijgen. Het zou een persoonlijke wijziging moeten zijn. Maar ik zal het eens voorleggen in SHEIC. Bedankt voor de tips. --LexTH 9 mrt 2009 11:05 (CET)

Ik zie dat je wat aan het experimenteren bent geslagen. Bij SHEIC schreef je dat je nog steeds problemen hebt met hele kleine wijzigingen zoals een '/' waar het mee begon. Ik heb voor mezelf ook wat geëxperimenteerd en met

.diffchange {
  background:#b8b8b8;
  color:red;
  font-size:larger;
}

ziet het er voor mij veel beter uit. In plaats van 'red' kun je natuurlijk ook een andere kleur proberen. - Robotje 9 mrt 2009 17:57 (CET)

Bedankt voor het meedenken. Voor mij is zwart beter dan rood, want rood geeft voor mij nogal korrelige letters (V). Ik vind van het vergrote letterformaat het bezwaar dat dan wijzigingen die een deel van een regel beslaan veel meer nadruk krijgen dan compleet toegevoegde of verwijderde regels. Dat is al zo bij gelijkblijvende grootte, maar het is sterker bij larger.

Hoewel het dus voor verschillende personen verschillend uitpakt, lijkt me toch dat er hier verbetering voor iedereen te bereiken zou zijn. Weet jij waar dat aangekaart moet worden? --LexTH 9 mrt 2009 18:34 (CET)

Om voor iedereen de standaard te veranderen zal waarschijnlijk MediaWiki:Monobook.css, MediaWiki:Common.css of een soortgelijke pagina moeten worden aangepast. Dat is iets wat alleen een moderator kan. Als het om een (vrij) ingrijpende verandering gaat is dat iets waar eigenlijk enige consensus over hoort te bestaan voordat een moderator dat gaat aanpassen. Hoe de gemeenschap over zoiets denkt kun je het beste te weten komen door met een voorstel te komen en dat in 'de kroeg' naar voren te brengen. - Robotje 9 mrt 2009 18:48 (CET)

Uiteraard is dit een wijziging die eerst in breed verband besproken moet worden, en slechts door moderatoren kan worden doorgevoerd. Ik wist alleen niet wat de juiste plek is om het te berde te brengen. --LexTH 9 mrt 2009 18:55 (CET)

Monobook

G'day, mag ik uit belangstelling vragen wat je probeert te veranderen aan de diffchange in je monobook.css? Zolang je bgcolor of backgroundcolor gebruikt veranderd er volgens mij sowieso niets, je kunt beter background of background-color gebruiken, groetengedoe, ♣ Troefkaart 9 mrt 2009 15:05 (CET)

Echt bedankt voor de hulp. Ik was er net zelf achter gekomen dat het "background-color" moet zijn. Ik ken geen html, alleen wat ik in WP opgepikt heb, vandaar. --LexTH 9 mrt 2009 15:10 (CET)

Zag dat je het net voor ik het melde zelf ontdekt had, mooi. Eventuele vragen over aanpassingen over css kun je me altijd stellen, ♣ Troefkaart 9 mrt 2009 15:16 (CET)

in de kroeg

Ik heb het al op mijn eigen overlegpagina beantwoord, maar ik kan me voorstellen dat je daar niet kijkt, dus ook hier maar: Als je een bericht beantwoordt, dan is het de gewoonte om 1 niveau verder in te springen dan het bericht waarop je reageert. Op die manier blijft duidelijk wie waarop reageert, ook als er meerdere reacties op 1 bericht zijn. Jij sprong juist minder in, waardoor het leek alsof je op een eerder bericht (van Brya) reageerde, en de logische plaats voor mijn bericht er dan boven was (als indirecte reactie op een eerdere reactie op hetzelfde bericht). Overigens heb je geheel gelijk dat ik niet zo moet schreeuwen :-) - André Engels 12 mrt 2009 13:47 (CET)

Ik heb ook al op jouw pagina geantwoord. Ik begrijp nu dat jij door mijn inspringen veronderstelde dat mijn bericht niet een reactie op Brimz was, dat maakt het begrijpelijker. Er zijn overigens kennelijk twee conventies, die door elkaar lopen. Jij houdt je strikt aan 1 meer inspringen als je op iemand reageert. Maar er wordt meestal steeds 1 meer ingesprongen, ook als het niet speciaal een reactie op de voorgaande is. En met jouw systeem loop je vast als je op 2 berichten wilt reageren. Hoe moet dat dan? --LexTH 12 mrt 2009 14:01 (CET)

1. Als je altijd 1 meer inspringt, dan kun je toch net zo goed niet inspringen?
2. Jij sprong minder in, wat dus tegen beide conventies zou gaan.
3. Op 2 berichten reageren, dan moet je er inderdaad 1 van de 2 uitkiezen (meestal de laatste). Ook dat blijft bij een ander inspringsysteem onveranderd. - André Engels 12 mrt 2009 16:06 (CET)

Ik heb het inspringen altijd opgevat als een methode om makkelijk te kunnen zien waar een volgend bericht begint. Als twee berichten evenveel inspringen is dat niet zo duidelijk. En in de praktijk komt het weinig voor dat twee berichten evenveel inspringen. Overigens wordt juist hier een probleem gedemonstreerd. Jij springt 2 in, maar geeft een genummerde opsomming. Als ik nu 3 inspring lijnt dat ongeveer uit met jouw tekst.

Ik zal in het vervolg de regel toepassen. Wel vind ik dat er dan 1 of 2 witregels tussen moeten om de grens duidelijker te markeren. Is daar ook een conventie voor? --LexTH 12 mrt 2009 16:47 (CET)

Infobox reservaat

Bedankt voor je werk aan sjabloon:Infobox reservaat, LexTH. Zier er nu mooi uit! --Beachcomber 30 mrt 2009 14:31 (CEST)

Graag gedaan. Het grote voordeel van knip- en plakwerk is dat ook mensen die niet precies weten wat al die code doet een tabel kunnen maken. Het nadeel is alleen dat daarmee ook onnodige code wordt overgenomen. Hier kon ruim een derde geschrapt worden. Veel overzichtelijker zo. --LexTH 30 mrt 2009 15:10 (CEST)

Eenedit

Hallo LexTH, Als dit sjabloon nu niet wordt gesubsitueerd, maar gewoon wordt ingevoegd (wat eigenlijk niet de bedoeling is) dan, wordt het niet goed weergegeven: Romaine (overleg) 8 apr 2009 22:26 (CEST)

Beste LexTH,

Bedankt voor je bijdragen op het artikel Artikelnaam. Je hebt hier meerdere bewerkingen op dezelfde pagina kort na elkaar gedaan.
Elke keer een pagina opslaan maakt de bewerkingsgeschiedenis van een artikel onoverzichtelijk, daarom is het handig als je meerdere bewerkingen aan een artikel in één keer doet.

Door boven het artikel op bewerk te klikken (in plaats van boven een kopje) is het hele artikel in één keer te bewerken.
Door eerst op Toon bewerking ter controle te klikken, kun je zien hoe het artikel er na jouw wijzigingen uitziet. Je kan deze knop meerdere keren gebruiken, voordat je op de knop Pagina opslaan drukt. Zie ook Wikipedia:Welkom voor nieuwkomers voor meer informatie. Bedankt voor je begrip!

Ja, daar ben ik me van bewust. Daarom heb ik ook eerst om een botbewerking gevraagd om alle 1700 bestaande aanroepen te substitueren. Dat is inmiddels gebeurd. Wonderlijkerwijs waren er enkele overgeslagen; ik was net begonnen die in orde te maken, en dat gaf een bewerkingsconflict met jou.

Ik heb nog gezocht of er een manier is om de directe aanroep wel goed te maken, of desnoods helemaal te onderdrukken, maar die lijkt er niet te zijn, tenminste niet als je de gesubstitueerde tekst correct wilt hebben. Nieuwe plaatsingen zullen hopelijk niet meer gebeuren, want dat kan redelijkerwijs alleen als je helemaal niet kijkt naar wat je gedaan hebt. --LexTH 8 apr 2009 22:39 (CEST)

Nou, dat laatste... Dat komt echt te vaak voor, helaas. :-( Romaine (overleg) 8 apr 2009 23:23 (CEST)

Misschien wel. Even in de gaten houden of er nieuwe links ontstaan. Als het te erg zou worden moet de oude toestand maar weer terug, maar hopelijk valt het mee. Ervaren plaatsers weten dat er gesubstitueerd moet worden, en onervaren plaatsers zullen toch wel kijken wat ze doen. Vergeet niet dat de oude versie geen zichtbare afwijking gaf als je vergat te substitueren. --LexTH 8 apr 2009 23:35 (CEST)

Stuureffect van de spooras

Hoi Lex, ik ben het eens met je revert op dit artikel, maar niet met je commentaar "allemaal waar". De wielen van een auto hebben allemaal een eigen as, ongeacht waar de motor is en welke wielen aangedreven zijn. De toevoegingen "klassieke auto" en "motor voorin" en "aandrijving op beide achterwielen" sloegen nergens op (en heb je dus terecht verwijderd). Handige Harrie 22 mei 2009 20:24 (CEST)

Je hebt gelijk dat het niets met de plaatsing van de motor te maken heeft, en dat het hier dus nergens op slaat. Maar deze gebruiker heeft zeker een poging gedaan om iets dat in zijn ogen zinvol was toe te voegen; het was geenszins vandalisme. En dat wil ik niet ontmoedigen door het botweg te reverten, al heb ik het evengoed verwijderd als met een echte revert. En was het zelfs aanleiding om een oude wijziging ook te editen, omdat het hier niet om de krachtverdeling gaat. -- LexTH overleg  22 mei 2009 20:43 (CEST)