Overleg gebruiker:Michiel1972/Archief/dec 2011

Laatste reactie: 12 jaar geleden door Michiel1972 in het onderwerp Jan Kalff

Deze archiefpagina bevat overleg van december 2011.

MichielBot in Honduras bewerken

LOL, het overzicht van de veranderingen op mijn volglijst was wel erg lang vandaag, omdat jouw bot langs alle Hondurese gemeenten geweest is. Bedankt dat je bij je onderhoudstaken ook deze verre uithoek in Midden-Amerika meeneemt! Hopelijk vond je bot het niet te warm en te vochtig daar šŸ™‚ Groeten, LeRoc (overleg) 1 dec 2011 18:04 (CET)Reageren

Arrondissementen van Lyon bewerken

Hello M1972, bedankt voor het aanmaken van bovenstaande pagina! netraaM ā€¢ 5 dec 2011 17:15 (CET)Reageren

Gemenebest graven bewerken

Hallo, ik las een van de artikelen over de oorlogsgraven in Frankrijk. Daarin staat vaak het zinnetje "De begraafplaats telt x geĆÆdentificeerde graven waarvan y Gemenebest graven uit de Eerste Wereldoorlog". Dit is onjuist spatiegebruik. Het moet "Gemenebestgraven" zijn of desnoods voor de duidelijkheid "Gemenebest-graven". Misschien kun je je bot er nog eens langs laten gaan? Groeten, LeRoc (overleg) 6 dec 2011 07:51 (CET)Reageren

Hoi, dat kan. Ik wacht nog even op eventuele andere tekstuele verbeteringen die ik mee kan nemen. Michiel1972 7 dec 2011 10:19 (CET)Reageren

Sjabloon rijksmonumenten en erfgoed Vlaanderen bewerken

Hallo Michiel,

In bovengenoemde sjablonen had je een aantal dagen terug de links naar google maps langer gemaakt, hierdoor werd de gemiddelde grootte van alle monumentenartikelen zo'n 10-15% groter (de post-expand grootte). Er zit een maximum aan de post-expand grootte die door deze wijziging op 19 artikelen de limiet overschreef, waardoor die 19 artikelen afgekapt werden door de software, ik heb dus de link weer ingekort (ik heb ook nog de link in het link rijksmonument sjabloon ingekort, wat ook zo'n 7-10% per monument scheelt. Ik begrijp dat het beter is om meer informatie mee te geven, maar denk dat het in deze twee gevallen onderhevig is aan het belang van kortere links, en daardoor kortere post-expandresultaten.

Eigenlijk zou het meest optimaal zijn als we beide externe links in de lijsten weg kunnen halen, en door een link een korte url kunnen vervangen, en dat die url dan een aanvraag doet in de rijksmonumenten API. Hierdoor kan de omvang van de monumentenlijsten nog eens 20-35% lager worden, en de snelheid van de hele boel dus ook. Ik wil je bij deze overigens verzoeken dat als je weer in het sjabloon extra informatie toevoegd je dan ook controleert (lijst van utrecht is het langste) of de lijsten niet daardoor de max. transclusiegrootte overschrijden. Mijn excuus dat ik nu pas reageer, gisteren was het wat te laat.

Mvg, Bas (o) 7 dec 2011 16:56 (CET)Reageren

Nog even in aanvulling: Bij deze omvang van lijsten moet er dus een afweging gemaakt worden tussen welke informatie we allemaal willen bieden en hoeveel objecten we weer willen kunnen geven. Die twee moet je met elkaar vermenigvuldigen en dat moet dus onder 2 miljoen blijven anders breekt het systeem de lijsten af. Het leek mij vrij logisch dat het belang van de titel in een externe link minder groot is dan het belang van logisch opgesplitste lijsten, we naderden namelijk het punt waarop zo'n 100 extra plaatsen weer opgesplitst moeten worden. Ik begreep van iemand dat die die keuze niet per se de meest logische keuze vond en dat erover gediscussieerd was, dus misschien is het nodig om nog even deze afweging gemaakt moet worden, want ik meen dat in de discussie de transclusiegrootte en dus het opsplitsen van lijsten niet ter sprake is gekomen. Het spijt me dan dat ik zonder dat overleg te voeren de boel het teruggedraaid (ik was niet op de hoogte van het feit dat jouw wijz. nav overleg ergens was), ik stel wel voor mijn wijziging van gisteren lopende het overleg nog even te laten staan, want het is makkelijker die terug te draaien dan om nu alle lijsten eerst op te gaan splitsen en dat na een evt. discussie weer te moeten terugdraaien. Mvg, Bas (o) 7 dec 2011 17:22 (CET)Reageren

Om het overzichtelijk te houden. Na overleg heeft Michiel op de Duitse wiki hierover technisch overlegd. Vervolgens heeft hij aan de sjablonen een functionaliteit toegevoegd zodat aan dat overleg gehoor gegeven kon worden. Dan blijkt dat de grote rijksmonumentenlijsten die al bijna te groot waren qua maximale transclusiegrootte (een software-technische beperking), nu echt te groot werden, waardoor het onderste deel van die pagina's niet goed getoond werd. Daarop is de sjablooncode van de tabelrijen aangepast, waarbij onder andere de functionaliteit van het eerdere Kroegoverleg eruit gegooid werd. Aangezien gemiddeld slechts 60% van de foto's in de lijsten staat, zal er nog 40% bij gaan komen, alsmede zullen er nog tekstuele aanvullingen komen. Dit zal als gevolg hebben dat over enige tijd de lijsten opnieuw te groot zullen zijn, en dan alsnog opgesplitst moeten worden. Door de zogenaamde oplossing om een functionaliteit er uit te gooien wordt het probleem alleen maar vooruit in de tijd geschoven en zal het probleem later opnieuw terugkeren, en als er binnen de gebruikersgemeenschap andere wensen zijn om toe te voegen aan dit sjabloon voor tabelrijen, dan kan dat niet omdat de lijsten nog steeds te groot zijn.
Samengevat is er dus gekozen voor een schijnoplossing en zal het probleem in de toekomst wederom terugkeren omdat er niet gekozen is voor een structurele oplossing, alsmede is er een functionaliteit uitgegooid die er juist op verzoek is ingekomen. Groetjes - Romaine (overleg) 7 dec 2011 17:49 (CET)Reageren

Het spijt me Michiel maar ik moet even fel reageren op Romaine's reactie hierboven. Ik heb net met hem op IRC gesproken/gediscussieerd (lang voordat hij hier reageerde). Hij weigerde te luisteren naar wat ik in te brengen had op de punten hierboven die hij daar ook presenteerde. En zonder dus ook maar iets te zeggen plaatst hij het op een andere plek terwijl ik hem erover uitleg aan het verschaffen bent (vervolgens wordt ik verzocht op te rotten omdat ik iets zeg over deze te starre houding).
Ik denk dat de eerste constatering die we moeten maken is dat er een afweging gemaakt moet worden, we kunnen nu eenmaal niet lijsten met 1000 monumenten en allerlei mooie links presenteren. We moeten dus een afweging maken of we kortere lijsten willen of dat we kortere sjablonen willen (beide kan ook het is een glijdende schaal.
Voor die afweging is het handig een onderscheid te maken tussen de vlaamse en de nederlandse lange lijsten, beiden worden namelijk door een ander sjabloon gegenereerd, en er spelen andere aspecten. Zo zijn de Vlaamse lijsten in enkele gevallen veel langer, bij de plaatsen met meer dan 1000 objecten zijn opsplitsingen nou eenmaal onvermijdelijk. Bij de Nederlandse lijsten zijn echter de meeste opsplitsingen al vrij volledig gedaan. Met behoud van de huidige structuur van het rijksmonumententabelrijsjabloon kan volgens mij op 0 tot 4 lijsten na elke lijst volledig afgemaakt worden, met foto's tekst en referenties zonder in problemen te komen met de transclusiegrootte. Waarom ik dat denk? De lijst van Groningen is vrijwel af en zit momenteel toch flink wat procent onder de maximale transclusiegrootte, de lijst van Groningen is de vijfde grootste lijst van rijksmonumenten die er is, het is dus onwaarschijnlijk dat andere lijsten daaronder veel groter zullen worden. In Nederland zijn er veel lijsten die zo rond dit aantal monumenten liggen en is het dus veel gunstiger om niet tot opsplitsingen over te gaan, het zou onhandig zijn als honderd plaatsen met 300-500 monumenten opgesplitst moeten worden, omdat opsplitsen de vindbaarheid voor lezers drastisch verslechterd.
Daarmee kom ik op het volgende punt. Romaine heeft het hier over dat ik een functionaliteit weggooi, dat kan ik niet ontkennen dat is namelijk zo, maar het alternatief is een andere functionaliteit weggooien, namelijk door lijsten onoverzichtelijker te moeten maken. Dat is dus gewoon een afweging die gemaakt moet worden. Ik denk inderdaad dat het probleem van de kaarten bij artikelen met meerdere keren dezelfde foto opgelost moet worden. Maar is de huidige manier wel de beste manier? Moeten de rijksmonumenten daar bijvoorbeeld wel in? er is namelijk een veel betere kaart van rijksmonumenten.
Tot slot vind ik het jammer dat Romaine zijn meningen hier als de waarheid presenteert (de getallen 40% en 60% zijn uiteraard gewoon uit de lucht gegrepen, voor de post-expand waardes zal het effect van inhoudelijke invullingen waarschijnlijk vrij klein zijn, aangezien die in complete lijsten volgens mij eerder 25% van de omvang bepalen, links hebben door hun terugkerende aspect nou eenmaal erg grote invloed), hij gooit daarmee, zoals gebruikelijk de overlegdeur dicht zoals hij dat op IRC ook deed, er wordt bijna nooit tot nauwelijks geluisterd naar argumenten die niet gelijk zijn aan zijn argumenten, dat betreur ik. Daardoor verharden discussies vaak onnodig en weet hij op onfatsoenlijke wijze vaker zijn mening door te drukken dan dat dat misschien terecht zou zijn. Ik wil namelijk niet geloven dat hij simpelweg altijd gelijk heeft. Mijn bewerkingen van gisteren als schijnoplossing aanmerken is daarnaast enkel polariserend. Nogmaals sorry naar jou Michiel dat ik hier zoveel negativiteit moet gebruiken. Nog even positief afsluiten dan: Te overwegen valt een oplossing waarbij de coƶrdinatenlinks in de rijksmonumentenlijsten van 2 naar 1 gebracht worden, en dat deze gelinkt worden naar een korte url, waarin enkel het RM-nummer meegegeven wordt. Op basis van dit RM-nummer kunnen dan dmv de rijksmonumenten-API/database van multichill alle benodigde gegevens opgevraagd worden, zoals het coƶrdinaat, het adres, de omschrijving, de foto wat je maar wilt, alsmede evt. alle andere monumenten in de betreffende plaats. Een snel alternatief is misschien om de Rijksmonumenten geheel uit de openstreetmapskaartjes te halen, er is immers een alternatief. Een ander iets waar naar gekeken kan worden is om de link naar alle monumenten in een plaats slechts 1 keer per pagina te vermelden, en niet per monument. Mvg, Bas (o) 7 dec 2011 18:18 (CET)Reageren
De reden waarom ik je aansprak Bas was omdat je zonder pardon een besproken functionaliteit er uit gooide. Ik weigerde niet te luisteren, we hadden gewoon een verschil van inzicht en Bas kan niet met onderbouwde kritiek op de gemaakte keuze omgaan. Dat is niet erg, meningsverschillen zijn juist een kenmerk van een rijk project. Wat wel vervelend werd was toen ik niet instemde met jou gedachtegang (mijn inziens was de onderbouwing onvoldoende) ik allerlei verwijten en persoonlijke aanvallen mijn richting opgegooid kreeg. Toen je daar mee bleef doorgaan heb ik het gesprek maar beƫindigd omdat dat totaal niet op normaal overleg lijkt. Je verdraaide bovendien met regelmaat mijn bewoordingen, en dat doe je hier weer. Bovendien ga je hier wederom verder met persoonlijke aanvallen. Met negativiteit bereik je echt niets.
In mijn ogen zijn de lijsten sowieso niet overzichtelijk, de gedachte dat ze door opsplitsen onoverzichtelijk zouden worden steun ik niet omdat ze al onoverzichtelijk zijn. Er is ooit in het verleden voor gekozen om bepaalde lijsten op te splitsen, en dat is - heel begrijpelijk - niet goed gebeurd omdat er daarbij onvoldoende rekening is gehouden met een toenemende hoeveelheid data/media die deze lijsten steeds meer gaan bevatten. Volgens de MediaWiki-software waren deze lijsten te groot, en gezien de nog steeds erg grote hoeveelheid data (die toenemende is) is de kans bijzonder groot dat die grens binnen het komende jaar opnieuw bereikt gaan worden. Dat een deel van een pagina door de software niet getoond wordt is pas echt een drastische verslechtering. Groetjes - Romaine (overleg) 7 dec 2011 19:06 (CET)Reageren
PS: 40% is het percentage van het aantal foto's dat nog in de lijsten ontbreekt, alsmede de 60% het percentage van het aantal monumenten dat reeds een foto heeft. Deze getallen zijn tijdens de prijsuitreiking van Wiki Loves Monuments begin november letterlijk genoemd. En een schijnoplossing is iets een oplossing noemen, waarbij het probleem op dezelfde wijze later terug gaat komen. Romaine (overleg) 7 dec 2011 19:18 (CET)Reageren
Tja maar op de post-expand grootte zal dat een veel minder grote invloed hebben dan een steiging van 40%, eerder eentje van minder dan 5%, daarnaast gaat het bij deze foto's voornamelijk om de kleinere lijsten, vrij off-topic dus. Mvg, Bas (o) 7 dec 2011 19:35 (CET)Reageren

Hoi Basvb en Romaine, aangezien ik jullie werk beider werk erg waardeer wil ik eigenlijk verder alleen inhoudelijk over mogelijke oplossingen van het geconstateerde probleem overleggen, graag op een daarvoor beter geschikte plaats, namelijk op Overleg_sjabloon:Tabelrij_rijksmonument#Anker. Ik zelf vind het wel wenselijk dat uiteindelijk op de OSM-kaart de juiste tekst & afbeelding wordt getoond, wat nu is teruggedraaid. Maar ook dat we niet nog veel verder gaan opsplitsen van de lijsten. Michiel1972 7 dec 2011 21:34 (CET)Reageren

Uiteraard prima Michiel. Ik wilde enkel aangeven wat de situatie is en het verder aan anderen overlaten. Ik waardeer het werk van Bas en van jou Michiel ook heel erg. Ondertussen is een en ander reeds op IRC uitgesproken. Groetjes - Romaine (overleg) 7 dec 2011 22:15 (CET)Reageren

If (eiland) bewerken

Dag Michiel1972,

Ik zag dit voorbijkomen. Leuk om zulke kleine onderwerpen toe te voegen, maar ik dacht, dat ken ik onder een andere naam, en werd het niet als gevangeniseiland gebruikt? Chateau d'If heet het. In dit geval zou ik samenvoegen, en van If (eiland) een redirect maken. Groet, Vier Tildes (overleg) 9 dec 2011 20:02 (CET)Reageren

Tsja, een eiland en wat er op staat een (kasteel/gevangenis) zijn eigenlijk twee verschillende onderwerpen. Zo hebben we ook Cuba (land) en Cuba (eiland). En er zijn nog meer voorbeelden waarbij dit onderscheid expliciet is gevolgd. Vandaar dat ik ooit If heb aangemaakt. Michiel1972 9 dec 2011 20:06 (CET)Reageren
Dat zag ik later ook, er staat een link naar Chateau d'If, dus je hebt bewust de keus gemaakt, het gaat dus om een zo compleet mogelijke 'eilandenreeks'. Groet, Vier Tildes (overleg) 9 dec 2011 20:11 (CET)Reageren

Seeland bewerken

Hoi Michiel,

Ik zag vandaag dat je seeland hebt verplaatst naar Seeland (eiland) en een bijbehorende DP hebt aangemaakt. Dat kan best, maar valt dat niet onder BTNI? Er bestond namelijker eerder een alternatieve doorverwijsconstructie. Groetjes, Sir Iain overleg 10 dec 2011 15:32 (CET)Reageren

Voor zover ik weet was er geen dp constructie aanwezig maar een zieartikel-vermelding. Ik ben die aan het nalopen (Gebruiker:Thijs!/viervoudigezieartikel, Gebruiker:Thijs!/driedubbelezieartikel, Gebruiker:Thijs!/dubbelezieartikel) aan het opschonen (overbodige links eruit halen) en indien mogelijk en passend er een normale dp van maken. Michiel1972 10 dec 2011 16:15 (CET)Reageren
Dat is waar, en na wat nalezen blijkt dat inderdaad niet opgenomen te zijn onder de mogelijke manieren van doorverwijzen. Je kunt mijn bovenstaande bericht dan ook als niet verzonden beschouwen.
Iets heel anders waar ik jou als sjabloon expert misschien mee lastig mag vallen. In artikelen over landen en historische landen staan bovenin de infobox het wapen en de vlag. Bij mij worden die niet vertikaal gecentreerd, maar bovenaan geplaatst. Ongetwijfelsd heeft dat iets te maken met infobox generiek. Zelf vind ik het niet prettig om daar aan te gaan sleutelen. Zou jij daar misschien naar willen kijken? Groetjes, Sir Iain overleg 10 dec 2011 16:39 (CET)Reageren
In Firefox worden ze bij mij verticaal gecentreerd weergegeven. Dat betekent dus dat er een compatibiliteitsprobleem bestaat waarbij niet alle browsers goed met de code overweg kunnen. Groetjes - Romaine (overleg) 10 dec 2011 16:52 (CET)Reageren
Ok. En hoe nu verder? Zou dat opgelost kunnen worden? Groetjes, Sir Iain overleg 10 dec 2011 18:31 (CET)Reageren
In beide sjablonen wordt reeds door middel van code gezorgd dat het verticaal uitgelijnd wordt. Het is bijzonder storend dat er browsers zijn die gewoon HTML-code niet goed uitvoeren. Ik zou niet weten hoe dat is op te lossen (behalve door het nemen van een ander browser), misschien heeft Michiel een idee? Groetjes - Romaine (overleg) 11 dec 2011 13:41 (CET)Reageren
Ik heb zelf een beetje zitten testen en bij bij ziet het er nu goed uit. Ik hoop dat het nog steeds werkt bij andere browsers. Groetjes, Sir Iain overleg 11 dec 2011 14:34 (CET)Reageren
Bij mij ziet het er nog steeds verticaal gecentreerd uit. Dus als dat voor jou nu ook het geval is lijkt het nu overal goed te gaan (hoop ik). Groetjes - Romaine (overleg) 11 dec 2011 14:37 (CET)Reageren
Probleem opgelost! Bedank voor het meedenken en werken, Romaine! Groetjes, Sir Iain overleg 11 dec 2011 14:51 (CET)Reageren

Spellen uit Duitsland bewerken

Dat komt omdat bijna 90% van de spellen in het Nederlands van Duitse origine zijn. Duitsland is het spellenproductieland bij uitstek. Zoals je zou kijken naar recensies over Bier zal je ook moeten vaststellen dat de meeste uit bvb Belgiƫ komen. Vdkdaan (overleg) 12 dec 2011 11:52 (CET)Reageren

Bestand:Map canton code 77 26.svg bewerken

Michiel, ook hier is enkel het exclave-gedeelte ingekleurd. Kun je dit rechttrekken? Sonuwe (āœ‰) 13 dec 2011 18:53 (CET)Reageren

Verwijderingsnominatie Knooppunt Geusselt bewerken

Een Wikipedia-gebruiker heeft Ć©Ć©n of meer artikelen die u hebt gestart of waar u aan hebt gewerkt genomineerd voor verwijdering. Dit betekent dat deze gebruiker het artikel op dit moment niet geschikt acht voor Wikipedia. Het gaat om Knooppunt Geusselt dat is genomineerd door Alankomaat. De reden hiervoor staat op Wikipedia:Te verwijderen pagina's/Toegevoegd 20111220 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. Zie ook Help:Waarom staat mijn artikel op de verwijderlijst.

N.B. dit is een automatisch bericht geplaatst door een bot. Ik heb niets met de nominatie te maken en kan er niets aan doen. Als u vragen hebt, kunt u die het beste stellen aan de gebruiker die het artikel genomineerd heeft. --E85Bot (overleg) 21 dec 2011 01:03 (CET)Reageren

Wapens Franse gemeenten bewerken

Michiel, mooi dat je je bot de ontbrekende wapens laat toevoegen maar kun je de bewerkingen op de gemeenten met dit wapen zoals Guibeville terugdraaien. Het is niet de bedoeling om Franse tekst te laten verschijnen. Sonuwe (āœ‰) 23 dec 2011 10:56 (CET)Reageren

Wijken en buurten in Schiedam bewerken

Hallo Michiel, Je hebt ooit aan de wieg gestaan van bovengenoemd artikel. Die wijkindeling is veranderd. Kan je naar de Overlegpagina kijken of je er iets aan kunt doen. Ik heb de tekst van de verschillende artikelen over de wijken aangepast, maar bovengenoemd artikel klopt nog niet. Ik heb de vraag al eerder hier geplaatst, maar ik zoe hem niet meer. Groeten, Salix2 (overleg) 23 dec 2011 22:23 (CET)Reageren

Binnenhof bewerken

Beste Michiel,

Zojuist plaatste je niet alleen coƶrdinaten, maar tevens "ne" op het lemma Binnenhof (Nijmegen). Los van het feit dat ik het daarmee oneens ben: Ga je dit lemma ook nog op de verwijderlijst plaatsen? Daar wou ik namelijk al mijn tegenreactie plaatsen, maar ik kon het lemma er niet vinden...

Groetjes Erik'80 Ā· 27 dec 2011 20:05 (CET)Reageren

sorry vergeten, nu toegevoegd, graag je reactie aldaar. Michiel1972 27 dec 2011 21:33 (CET)Reageren

Jan Kalff bewerken

Beste Michiel, je bent nogal dwars door mijn bewerking c.q. reparatie heen aan het vonken. Als je wilt kijk even in mijn 'bijdragen'. Morgen check ik of alles consistent is, en doe ik indien nodig nog aanpassingen. Welterusten straks Heemskercker (overleg) 30 dec 2011 23:48 (CET)Reageren

Sorry als ik in de weg liep. Personen disambigueren we nooit met Ir of directeur, maar bij voorkeur met de meest essentiele bijdrage van die persoon. En Plan Kalff zou geen redirect moeten zijn naar de persoon maar een apart artikel. Hoop dat je die nog wil schrijven. Michiel1972 30 dec 2011 23:56 (CET)Reageren
Terugkeren naar de gebruikerspagina van "Michiel1972/Archief/dec 2011".