Wikipedia:Botcafé/Archief/2006-11

interwiki.py bot idee

Ik heb een idee om de interwiki.py bot, die heel vaak draait, uit te breiden. Namelijk met een automatische vermelding van het sjabloon commonscat, of commons + inhoud natuurlijk. Op nl: zijn daar dezelfde sjablonen voor als elders. Is dat een goed idee of zie ik nadelen over het hoofd? En waar dit te melden? Ik heb het ook gepost op gmane.comp.python.pywikipediabot.general Groeten, Elly 5 nov 2006 20:49 (CET)

Zo simpel is het ook weer niet. Er bestaan nu al verschillende sjablonen die naar commons verwijzen: commons, commonscat, commonscat2, commonscatklein, commonsklein, taxobox commons,...Michiel1972 5 nov 2006 21:02 (CET)

En die verschillen dan ook nog van taal tot taal, en kunnen op verschillende plaatsen op de pagina staan. - André Engels 8 nov 2006 02:37 (CET)

Lijkt me inderdaad ook moeilijk met al die verschillen: namen van sjablonen, plaatsen waar te zetten op de pagina, taal van de pagina waarnaar gelinkt wordt, etc... Iets simpels zoals doorverwijspagina's veroorzaakt nu soms al wat problemen. Het zal waarschijnlijk wel mogelijk zijn, maar veel werk. Bovendien zal je dan nog eens al je botstatussen moeten heraanvragen, omdat je bot ineens andere dingen gaat beginnen doen, waar in de aanvraag voor het oorspronkelijke botbitje geen sprake van was. --Tuvic 8 nov 2006 15:33 (CET)

Nog een idee voor de interwiki.py bot

is er misschien een scriptje wat je in je bot kan zetten zodat als je een sjabloon interwikit dat het de tags <noinclude> en </noinclude> automatisch bijzet? Crazyphunk 12 nov 2006 16:17 (CET)

Ik heb het net eens uitgetest: als de interwikis al binnen noinclude staan, blijft de bot er ook binnen. Als ze buiten de noinclude staan, houdt de bot ze erbuiten, en als er nog geen interwikilinks staan, dan zet de bot het gewoon in het sjabloon, zonder noincludes bij te voegen. Er is dus al wel gedeeltelijke functionaliteit aanwezig, maar het kan nog beter. --Tuvic 15 nov 2006 22:03 (CET)

Category.py

Ik heb net een probleempje gehad met category.py move. het gaat om een probleempje met <include>: zie deze verandering: [1] . Een van de haakjes is blijven staan. Kan iemand licht op deze zaak werpen? Londenp _{zeg't maar} 14 nov 2006 13:22 (CET)

Raar. De botsoftware is een tijdje geleden nog wel aangepast ivm noincludes en includonly's en zo, misschien dat de nieuwe versie downloaden helpt? --Tuvic 14 nov 2006 16:15 (CET)

zet de nieuwe versie die dingen er automatisch bij? ook bij sjablonen? Crazyphunk 14 nov 2006 16:28 (CET)

@FANSTAR: zie kopje hierboven --Tuvic 15 nov 2006 22:03 (CET)

@Londenp: de fout zit ook in de laatste bot-versie, ik kan ze perfect reproduceren. Waar het aan ligt weet ik echter niet. Misschien dan André het wel weet? --Tuvic 15 nov 2006 22:03 (CET)--Tuvic 15 nov 2006 22:03 (CET)

Ik zal er eens naar kijken. Sorry voor de trage reactie. - André Engels 23 nov 2006 11:10 (CET)

Opgelost in wikipedia.py 1.763. - André Engels 23 nov 2006 11:25 (CET)

Mijn dank :-) Londenp _{zeg't maar} 23 nov 2006 11:36 (CET)

Probleem

Ik wil proberen of een bot wat voor mij is, ik heb alles geïnstalleerd en het bestandje user-config.py aangemaakt. Ik wil dan het login.py bestandje openen, maar mijn computer geeft als melding dat de opdracht of bestandsnaam onjuist is. Nou wil het zo zijn dat ik per ongeluk de computer heb aangegeven met welk programma de .py bestandjes te openen (en dat is niet de juiste). Oftwel, weet iemand hoe je die instelling kan terugdraaien, zodat ik het opnieuw kan proberen om te kijken of hij het dan wel doet. (opnieuw downloaden of andere suggesties in die zin: dat heeft geen zin) Met vriendelijke groeten, Vincentsc 19 nov 2006 17:39 (CET)

(shift)-rechtermuisklik, openen met, dan python.exe selecteren. Of gewoon python <filenaam> gebruiken. valhallasw 19 nov 2006 23:33 (CET)

Meer waarschijnlijk lijkt mij dat die opmerking betekent dat je in de verkeerde directory bezig bent. - André Engels 23 nov 2006 11:09 (CET)

O, wacht even, wat ook nog kan is dat je op Linux zit. In dat geval dien je "python login.py" in plaats van alleen "login.py" te doen. Er is wel een methode om ook het tweede goed te laten gaan, maar die is niet bij alle bots toegepast. - André Engels 23 nov 2006 15:50 (CET)

Vraagje

Niet echt een botvraag maar ik heb geen zin om het in de kroeg te zetten. Zie Gebruiker:Michiel1972/testbreedte. Alle breedtes zijn ingesteld op 270px maar de breedte tussen {{berg}} en {{commonsklein}} is niet gelijk. En dat was eigenlijk mijn doel met {{Infobox/breedte}}. Iemand een idee waarom het niet even breed is? Vanwege het verschil in een div en tabel? Michiel1972 29 nov 2006 11:08 (CET)

Het heeft idd te maken met het verschil div/tabel (zie de dubbele rand). Heeft waarschijnlijk te maken met een andere interpretatie van margin of padding. (ik denk margin maar ik zou het zo 1-2-3 niet weten) valhallasw 29 nov 2006 13:44 (CET)

Hallo Michiel. Volgens mij heeft valhallasw gelijk en heeft het te maken met de margin (of eventueel padding). Ik weet alleen niet of het wel voordelig is om te werken met dat sjabloon Infobox/breedte. Het doel van zo'n sjabloon is om ervoor te zorgen dat je de breedte in één keer op verschillende sjablonen kan veranderen (en gelijk is). Volgens mij is het daarentegen niet de bedoeling om die breedte regelmatig te veranderen waardoor dat het misschien beter is om een stadaard-breedte af te spreken, zoals die 270px en dat die gebruikt wordt in plaats van het sjabloon. Stel nu dat we het toch zouden gebruiken, dan zouden we eigenlijk ook moeten nagaan of dit niet te breed is en te smal voor alle sjablonen die die standaardbreedte gebruiken, wat eigenlijk veel is om te doen. Een andere zaak is de discussie die zich misschien gaat stellen: "wat is de goede breedte?". Als we met iedereen regelmatig die waarde gaan veranderen, dan gaat dat weerslag hebben op al die verschillende pagina's en dan gaan er altijd mensen zijn die dat nog snel willen veranderen of over discussiëren. Ik zie het meer als een zwak punt omdat je dan minder controle hebt over zo'n massa-bewerking. Ik vind het idee eigenlijk goed gevonden, ik pleit ook voor een standaardbreedte, maar liever zonder het gebruik van een sjabloon daarvoor. Groeten, Christophe 29 nov 2006 16:06 (CET)

Hoi, bedankt voor je antwoord. Ik zie er voorlopig vanaf om de breedte verder te standardiseren aangezien het technisch blijkbaar al niet eenvoudig te realiseren valt (ik heb geen zin in 2 breedtesjablonen voor divs en tabellen). Een discussie/werkgroep over de standaardisatie van (elementen van)de paginaopmaak lijkt me een goed idee. Is er overigens ook een optie om de breedte van een afbeelding dynamisch aan te passen aan de resolutie van het scherm? Zo zit ik op mijn werk met een superhoge resolutie en zijn de 250px en 270px boxen en afbeeldingen nogal klein ten opzichte van de rest van de pagina. Thuis is het net andersom, daar is 300px echt te breed. Michiel1972 29 nov 2006 18:30 (CET)

Technisch is het mogelijk om (met % of zelfs met em) de breedte dynamisch aan te laten passen aan je schermresolutie (of beter gezegd aan de breedte van het venster van je browser), maar dan weet je niet zeker hoe het sjabloon eruit ziet op het scherm van iemand anders. Misschien komt de relatieve breedte op jouw scherm goed uit en is die breedte perfect om de tekst er juist op te krijgen, maar is dat dan helemaal niet op het scherm van een andere wikipedia-bezoeker, waar de breedte dan misschien veel te groot of veel te klein is. Ik zou het bij een standaardbreedte houden in pixels die niet afhangt van je resolutie, dan zitten we niet met die problemen van te groot en te klein. Christophe 29 nov 2006 21:59 (CET)

Hmm. Ik ben het oneens met je conclusie. Juist met een vaste breedte voor alle resoluties heb je veel 'ontevreden' lezers omdat je de opmaak zich niet aanpast aan die van de lezer. Ik weet dat je de breedte van boxen als een percentage kan uitdrukken, maar hoe doe je met een losse afbeelding? Michiel1972 30 nov 2006 22:27 (CET)

Hey Michiel. Ik weet niet of we nu over hetzelfde spreken. Ik bedoelde dat ik voorstander ben van een vaste breedte voor een sjabloon naast een artikel. Met vaste breedte bedoel ik dat deze zich niet aanpast aan de schermresolutie. Ik begrijp jouw laatste zin daarover eigenlijk niet.

Ik weet niet of je de breedte van een afbeelding met % kan instellen. Groeten, Christophe 1 dec 2006 01:25 (CET)

Ondertussen ben ik bezig geweest om te onderzoeken wat de verschillen zijn mbt breedtes, zie Gebruiker:Michiel1972/testbreedte. Een tabel van 270px is even breed als een div van 261px. Die hanteer ik even als 'standaard'. Toch zie ik elke keer als ik naar mijn werk ga en een hoog resolutiescherm (1600x..) bekijk dat in verhouding de infoboxen vrij klein zijn. Vandaar mijn vraag of afbeeldingen ook kunnen worden geschaald als percentage van de schermbreedte. Als dat niet kan is mijn volgende vraag: hoe kan ik dynamisch de breedte aanpassen van een infobox/afbeelding als ik {{Infobox/breedte}} en {{breedtedivbox}} als basisbreedte hanteer. Is er een parserfunctie om de resolutie van de gebruiker op te vragen en op basis daarvan de ideale infobox-breedte te berekenen (wat is ideaal? Ik schat 1/4 van de schermresolutie breedte in pixels) Michiel1972 19 dec 2006 02:33 (CET)

Technisch zal het wel mogelijk zijn om op de een of andere manier de breedte in verhouding te stellen van de schermresolutie. Ik zou het alleen niet zo ingewikkeld maken. Het neemt veel meer tijd om na te gaan of een infobox er bij een bepaalde breedte, die automatisch aanpast wordt aan de schermresolutie, er goed uitziet, dan tijd om na te gaan of de "gewone" tekst wel goed getoond wordt. Elke infobox heeft een bepaalde inhoud die meestal aangepast is zodat deze juist past binnen de ingestelde breedte. Indien we die breedte variabel gaan maken, dan zouden we dat eigenlijk ook voor de inhoud moeten doen die erin staat. Die inhoud (zowel tekst als afbeeldingen) moet dus van tekstgrootte en afbeeldingsbreedte veranderen. We kunnen immers niet de inhoud veranderen (door woorden gaan te verwisselen met synoniemen die langer, dan wel korter zijn) omdat het nog steeds de bedoeling is om elke bezoeker inhoudelijk van dezelfde informatie te verschaffen. Het brengt ons daarom volgens mij veel te ver als we dit willen doorvoeren op deze manier.

Een ander voorbeeld. Stel, een Wikipedia-gebruiker heeft een grote schermresolutie. Deze gebruiker voegt eender welk infobox sjabloon in en voegt daarin een foto toe met een breedte die voor hem/haar overeenkomt met de relatieve (!) breedte van de getoonde infobox. Een bezoeker met een kleine schermresolutie komt langs en ziet een te grote afbeelding in een, in vergelijking, te kleine infobox. Dit is maar een voorbeeld om aan te tonen dat we het ons veel te moeilijk gaan maken zo.

Michiel, je vertrekt van het goede idee dat ik ook terugvind in je sjabloonbeschrijving: "Om de opmaak van de wikipedia pagina's met veel sjablonen uniformer te maken is een standaardbreedte van infoboxen gewenst." Ik geef je daarin gelijk. Alleen denk ik niet dat het met een sjabloon hoeft. Wat is precies het voordeel om dit met een sjabloon te doen?

Sorry voor het lange stukje tekst. Ik hoop dat je het helemaal leest en hoop dat je begrijpt wat ik wil zeggen. Groeten, Christophe 23 dec 2006 00:45 (CET)

Het idee om dynamisch de breedte van infoboxen en/of afbeeldingen aan te passen aan de resolutie heb ik voorlopig opgegeven. Het is inderdaad zo dat de breedte in pixels niet (relatief gezien) hoeft te worden vergroot wanneer je een hogere resolutie gebruikt. Dat idee was deels niet realistisch (maar een zeker percentage zou wel acceptabel kunnen zijn voor de leesbaarheid!) . Het tweede punt van meer standaardisatie blijft overeind, al zullen de meningen verschilen of 350px, 300px of 250px een gewenste breedte voor een infobox (onder alle resoluties!!) zal zijn Michiel1972 23 dec 2006 00:55 (CET)

Ik ben akkoord dat een standaardbreedte de uniformiteit van pas komt. Ik ben alleen nog niet overtuigd dat we dit met sjablonen als Sjabloon:Breedtedivbox en Sjabloon:Infobox/breedte moeten doen. Het is volgens mij niet de bedoeling om die standaardbreedte steeds te veranderen. We kunnen ook gewoon een breedte (of een aantal breedtes) afspreken en die toepassen in plaats van dat te doen door die sjablonen in te voegen. Ik begrijp er de voordelen dus nog niet van... Christophe 23 dec 2006 14:58 (CET)