Wikipedia:De kroeg/Archief/20221019

Commons thumbs gebroken

Een verandering op Commons betreft de manier waarop thumbnails van Special Search getoond worden. Ze worden nu aan drie kanten afgesneden en lange lijsten van 500 items laden niet. Voorbeeld voorbeeldlijst 500 items. Maak uw mening kenbaar. Village_pump tech Peli (overleg) 9 okt 2022 15:35 (CEST)

Is dit al opgelost? Bij mij laadt het wel. –bdijkstra (overleg) 10 okt 2022 12:35 (CEST)

Met de eerste 500 items heb ik geen probleem, behalve dat de pagina bij scrollen wisselend reageert: om en om gaan er tien vlot, daarna moet er misschien een nieuwe cache ingeladen worden en gaan er tien sloom.

Bij 2000 items worden sommige plaatjes niet weergegeven. Trouwens ook als ik bij 500 op 'volgende' heb geklikt.

Er wordt wel iets opgehaald, want de Chrome-extensie Hover Zoom+ laat ze gewoon in groot formaat zien als ik de muispijl op het lege kader zet; die lege kaders zijn trouwens steevast te groot, soms wel 10×10 maal de vereiste maat.Zou het moeizame scrollen daarmee te maken hebben, dat de kaders steeds herberekend worden? Soms zie ik eerst een leeg kader in correct formaat en dan een in buitensporig formaat.

Als ik de pagina herlaad vallen er willekeurig andere thumbnails uit. De problemen nemen toe naar de onderkant van de pagina. Bij deze met 17 missers zat maar een van de fouten in de bovenste helft. Ook bij deze, met 78 fouten zaten de meeste in de onderste helft. Als je de pagina herlaadt zie je elke keer iets minder fouten; Na een keer of zes zijn ze weg. Het scrollen gaat dan ook soepeler. Ook de lijst van 2000 kreeg ik foutloos met heel vaak herladen. Deze afbeelding was wel hardnekkig, ook na vijf keer herladen van de zoekpagina gaf die niet thuis. Die moest ik in het gareel dwingen door met de rechter muisknop in het lege vak de optie afbeelding laden te gebruiken  →bertux 11 okt 2022 03:43 (CEST)

Betreffende lange lijsten die moeilijk laden. Dit is bij zoeken naar svg extreem. De pagina neemt daarvoor 25 seconden de tijd. zoeklijst 500 items amsterdam+svg. Ze laden dan wel zonder uitzondering maar de user is al lang vertrokken omdat hij dacht dat de site niet reageerde. Als de plaatjes eenmaal op binnenlandse servers staan zal het daarna ook wat sneller gaan allicht. Men heeft nu ook herkend dat het op Commons special search results (images) zeer onpraktisch en eigenlijk onwerkbaar is de verhoudingen van de plaatjes niet direct in hun geheel te kunnen overzien in de lijsten. Het lijkt erop dat eraan gewerkt wordt. https://phabricator.wikimedia.org/T320459 Peli (overleg) 11 okt 2022 11:42 (CEST)

@Peli: Jouw zoekopdracht kost bij mij vandaag ongeveer 8 seconden. Wikipedia lijkt vandaag een stuk sneller dan gisteren, zou er iets mis geweest zijn bij onze Amsterdams hub?

Maar dit kan handiger: als je bovenaan, bij Geavanceerd zoeken, opgeeft dat je het bestandstype svg zoekt gaat het nog wat sneller, 4 seconde bij mij, waarbij de resultaten uiteraard relevanter zijn bovendien. Ter controle ook Rotterdam gezocht, met hetzelfde resultaat: 4 seconden. Tilburg duurde 11 seconden, maar "Tilburg" slechts 3. "New York" was 11 seconden. Voor de grap ook gezocht op "the": 6 seconden, 2.101.405 resultaten. Een poging het miljoenste resultaat op te vragen mislukte (maximaal 10.000), maar nummer 9.901 tot 10.000 kostte 12 seconden  →bertux 11 okt 2022 21:13 (CEST)

Zoekresultaat COA filemime:image/svg+xml laat hier vandaag nog steeds zo'n 35 sec op zich wachten, op wireless verbinding buiten Amsterdam met locale css hack voor volledige thumbs geactiveerd. De veranderingen in onderligende code hebben te maken met de opzet om in zoekresultaten op alle wikis alle lemma's van uniforme vierkante, driezijdig afgeknipte, mini plaatjes te voorzien, men heeft herkend dat dit op Commons voor het vinden van de juiste bestanden onwerkbaar is. Hopelijk wordt het probleem met het laden van lange lijsten ook spoedig opgelost. Peli (overleg) 12 okt 2022 17:13 (CEST)

Jouw zoekopdracht duurt bij mij ook zo lang en vergelijkbare opdrachten kosten 3 tot 50 seconden. Ik kan er geen systeem in ontdekken. Dank voor de css, ik heb hem ook meteen geactiveerd,  →bertux 12 okt 2022 18:02 (CEST)

Controleerbare bron bij overlijden

Na een verzoek van mij voor een controleerbare bron voor de overlijdensplaats en -datum, is bij het artikel van Johan Berger een verwijzing opgenomen naar het NRC. Het betreft hier een bron die ik zelf niet kan controleren. De datum heb ik controleren middels een andere bron (zie daarvoor de overlegpagina), maar de plaats van overlijden staat niet in de bron. Ik kan de juistheid daarvan niet toetsen. Wat is nu wijsheid in deze? Ik ga er wel van uit dat de verwijzing klopt. Davv69_overleg 10 okt 2022 20:35 (CEST)

Ik heb een abonnement, en een linkje naar de annonce in de digitale krant bijgezet. Er zijn ook sites zoals Mensenlinq is die veel familieberichten overnemen, daar stond hij ook tussen. Milliped (overleg) 10 okt 2022 21:09 (CEST)

Milliped, bedankt! Op mensenlinq vond ik het bericht uit de Stentor, maar zonder overlijdensplaats. Davv69_overleg 10 okt 2022 21:34 (CEST)

Ik zie regelmatig dat voetstoots aangenomen wordt dat een persoon is overleden in een genoemde woonplaats in het overlijdensbericht. Dat is echter lang niet altijd het geval. Het komt regelmatig voor dat iemand bijvoorbeeld is overleden in een ziekenhuis buiten de woonplaats, zonder dat dit vermeld wordt in het overlijdensbericht. In die gevallen is het veel beter om geen plaats te vermelden dan een verkeerde. Gouwenaar (overleg) 12 okt 2022 09:20 (CEST)

@Davv69: In zulk soort gevallen kun je met Wayback Machine een archiefversie van de tekst opzoeken of zo nodig maken; onder andere bij NRC kun je daarmee de betaalmuur omzeilen. In dit geval is er een screenshot gemaakt van het overlijdensbericht, dus dat kun je gewoon openen. Overigens eens met Gouwenaar dat je niet blind moet varen op de plaats die genoemd wordt, maar in dit geval zegt de annonce expliciet

Den Haag, 22 augustus 1938   Den Haag, 29 september 2022.

Deze lijkt dus voldoende bebrond  →bertux 12 okt 2022 09:39 (CEST)

Archive.is werkt bij sommige bronnen ook om een betaalmuur te slechten. StuivertjeWisselen (overleg) 12 okt 2022 10:13 (CEST)

Allen, bedankt voor de tips. Davv69_overleg 12 okt 2022 14:19 (CEST)