Moduldiskusjon:External links

Denne løsningen vil liste alle oppføringer, inklusive de som har rang deprecated. — Jeblad 10. mar. 2016 kl. 20:16 (CET)Svar

Logikken er kopiert "rått" fra Modul:Sportslenker, så jeg har ikke kommet så langt enda.. ser at det er en del som må tas hensyn til her ja. Stigmj (diskusjon) 10. mar. 2016 kl. 20:23 (CET)Svar

Ja, det er en veldig begrenset regex-converter, men så langt er det kun slike enkle tester som benyttes i qualifierene for de enkle utsagnene. P1793 for selve "hovedutsagnet" bruker flere egenskaper som også ikke er støttet og det bør finnes en bedre løsning på dette. Synes det er litt rart at dette ikke har blitt tatt hensyn til i forbindelse med implementasjonen av Lua her. De legger inn regex'er for å kvalifisere utsagnene, men gir oss ikke verktøyene for å gjøre noe med dette, eller har jeg oversett noe her? Stigmj (diskusjon) 29. mar. 2016 kl. 14:39 (CEST)Svar

Wikibase skrives i PHP, mens vi bruker Lua. I Lua er det kun implementert en nokså begrenset form for regulæruttrykk, som har en mye mer kompakt kodebase. PCRE er en reimplementering av Perl sine regulæruttrykk, og de er tunge. Det er heller ingen garanti for at disse avslutter i endelig tid. Det finnes noen ufullstendige implementasjoner av PCRE i Lua, det er eventuelt mulig å spørre om å få satt opp disse. Lurer på om de ble utelatt pga sikkerhetsproblemer, men de er uansett nokså tunge. Et alternativ til et PCRE-kompatibelt bibliotek er å oversette til FST. — Jeblad 29. mar. 2016 kl. 14:57 (CEST)Svar

I linje 94; for _, qualid in ipairs( qorder ) do, ser ikke helt hvorfor det loopes over en enkelt property. Vil vel tro at det kan settes opp flere i fremtiden, men det trenger muligens en forklaring. — Jeblad 29. mar. 2016 kl. 14:49 (CEST)Svar

Vær snill å fjern duplisering av informasjon.

Eksempel fra Tecumseh (Nebraska)

(en) Kategori:Tecumseh, Nebraska – bilder, video eller lyd på Wikimedia CommonsRedigere på wikidata

Det er mange som jobber hardt for å rydde opp i rot og duplisering på Wikipedia og andre prosjekter, ikke legg inn slikt som skal i sidemargen. — Jeblad 10. mai 2016 kl. 16:13 (CEST)Svar

Dette er ikke en diskusjon som hører hjemme her, men på Wikipedia:Tinget da det er en større endring i forhold til innholdet i artiklene som er påvirket, samt at det er et kontroversielt tema, basert på tidligere diskusjoner jeg har sett om dette. Jeg er personlig helt enig i at det er totalt unødvendig fra en desktop-site sitt behov, men mobilbrukere har ikke disse sidemarg-lenkene og vil følgelig miste denne informasjonen. -- Stigmj (diskusjon) 10. mai 2016 kl. 16:45 (CEST)Svar

Du har utvidet malen med oppføringer som ikke hører hjemme i den. At Tecumseh (Nebraska) ikke har en sidemarg med disse lenkene er en stråmann. — Jeblad 10. mai 2016 kl. 17:18 (CEST)Svar

Denne modulen er i akutt behov for refactoring. Cyclomatic number er ikke i nærheten av å være på håndterbart nivå. — Jeblad 21. nov. 2016 kl. 14:58 (CET)Svar

Refactoring anyone? — Jeblad 28. apr. 2018 kl. 14:04 (CEST)Svar

Det står nå Harry Connick jr. sitt profil på .... Kan noen korrigere slik at det blir sin når etiketten slutter på punktum eller et ord med små forbokstaver? Eller droppe sin/sitt som det har vært diskutert her. --Avilena (diskusjon) 23. aug. 2017 kl. 22:07 (CEST)Svar

Funktionen mw.wikibase.getEntity (eller aliaset mw.wikibase.getEntityObject) er meget langsom at udføre for store entiteter. Jeg målte omkring 400 ms for at hente entiteten Usain Bolt (Q1189) på dansk Wikipedia. Dette modul bruger mw.wikibase.getEntityObject to gange for hver property det tester. Det er ekstremt ineffektivt. Det er derfor at der er time-out (over 10 sekunder Lua-tid) på artiklen Usain Bolt. Vi havde samme problem på dansk Wikipedia. Jeg løste det der med en simpel ændring (se da:Special:Diff/9647818), så entiteten kun hentes en gang. Jeg anbefaler at I gør tilsvarende. --Dipsacus fullonum (diskusjon) 25. aug. 2018 kl. 23:51 (CEST)Svar

Da ingen svarede, lavede jeg selv rettelsen. Antal artikler i Kategori:Sider med skriptfeil faldt fra 27 til 8 på grund af ændringen. (De øvrige 39 sider i kategorien er i andre navnerom). --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 00:11 (CEST)Svar

The function getEntityObject hits a cache holding the last six entries, and should be pretty fast. If you measure several seconds then something else is probably wrong. Most likely some hits empties the cache. — Jeblad 2. sep. 2018 kl. 03:43 (CEST)Svar

@Jeblad: Nej, rationalet for ændringen er ikke forkert. Der er en cache på 14 entiteter (se mw:Extension:Wikibase Client/Lua#mw.wikibase.getEntity), men selv når entiteten hentes fra cachen tager det tid at oprette mange nye tabeller og strenge. Her er et eksempel udført i feilsøkingskonsollen hvor samme entitet hentes to gange i træk:

=os.clock() ..  ' '.. type(mw.wikibase.getEntity('Q28614')) .. ' '.. os.clock() .. ' ' .. type(mw.wikibase.getEntity('Q28614')) ..  ' ' .. os.clock()
0.31644 table 0.39596 table 0.40668

Det ses at mw.wikibase.getEntity-kaldet udføres på 79 ms første gang, og 10 ms anden gang. De 10 ms tæller op når kaldet bruges ca. 500 gange for {{Sportslenker}}. Og avfallsinnhenting vil også give et meget stort ekstra tidsforbrug når minnet bliver fyldt op med nye entitetsdata hele tiden. Derfor betød ændringen at 19 artikler som har store entiteter på Wikidata gik fra skriptfeil på grund af tidsutløp til at kunne renderes på få sekunder. --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 10:01 (CEST)Svar

Nice, cache changed last year, wasn't aware of that.

Checked in the console for one call with the timing module and your result are consistent

timing=require 'Module:Timing'
=timing.count(1)
=timing.sets(1)
=timing(mw.wikibase.getEntity, 'Q28614')
=timing(mw.wikibase.getEntity, 'Q28614')

First gives

Each call was running for about 8.3e-02 seconds.
	Mean runtime for each set was 8.3e-02 seconds,
	with standard deviation of 0.0e+00 seconds,
	minimum 0.0e+00, maximum 0.0e+00.
	Total time spent was about 8.3e-02 seconds.
Relative load is estimated to inf.

Second gives

Each call was running for about 1.0e-02 seconds.
	Mean runtime for each set was 1.0e-02 seconds,
	with standard deviation of 0.0e+00 seconds,
	minimum 0.0e+00, maximum 0.0e+00.
	Total time spent was about 1.0e-02 seconds.
Relative load is estimated to inf.

And a new run for 100 calls after reload

timing=require 'Module:Timing'
=timing.count(10)
=timing.sets(10)
=timing(mw.wikibase.getEntity, 'Q28614')

That gives

Each call was running for about 1.1e-02 seconds.
	Mean runtime for each set was 1.1e-01 seconds,
	with standard deviation of 2.5e-02 seconds,
	minimum 0.0e+00, maximum 2.0e-05.
	Total time spent was about 1.1e+00 seconds.
Relative load is estimated to 57,461.0.

That is bad as it implies the code does something wrong. With caching this should be way less than 1ms. I'll write a bug about it.

Anyhow, the module code has a lot of issues and should be fixed. (In particular it loops through very large structures instead of using hashes, but in general its complexity is way beyond any sensible limit.) — Jeblad 2. sep. 2018 kl. 18:06 (CEST)Svar

Det tager så lang tid fordi at der skal oprettes mange tusinde tabeller ved hvert kald af getEntity (5386 tabeller for Q28614), og de skal bagefter fjernes af avfallsinnhentingen. Det er ingen feil. Det er sådan lua fungerer. --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 21:23 (CEST)Svar

= #mw.dumpObject(mw.wikibase.getEntity('Q28614')) - #string.gsub(mw.dumpObject(mw.wikibase.getEntity('Q28614')),'{','') 
5386

Funktionen string.urlEncode i linje 115-123 %-indkoder nogle ASCII-tegn som ikke er reserverede i URI'er. Det får URL'er til cyclocross24.com (P13724) som indeholder bindestreger til ikke at virke.

Jeg har løst problemet på den danske udgave af modulet ved at ændre linjerne:

     str = string.gsub( str, "([^-%w/ ])",
        function (c) return string.format( "%%%02X", string.byte(c) ) end )
     str = string.gsub( str, " ", "+" )

til

     str = mw.uri.encode( str, "QUERY" )

Man kunne også tilføje alle ikke-reservede tegn i URI'er til det regulære udtryk, men jeg fandt det bedre at bruge den indbyggede funktion til URI-indkodning.

Jeg foreslår at funktionen også ændres her. Dipsacus fullonum (diskusjon) 9. nov. 2025 kl. 10:30 (CET)Svar