Moduldiskussion:Sandlådan/Sextvåetc/WD

message: Jag upptäckte att en väsentlig funktion i Modul:Wikidata inte funkar. Den ser inte skillnad på url-datatypen, mediafil-datatypen och string-datatypen. Kan du jämföra denna version med denna och se om något ser ut att gå bananans på grund av denna förändring? -- Innocent bystander 5 oktober 2015 kl. 19.33 (CEST)
replies: text: Vilken funktion är det som inte levererar det du förväntar dig? Visa gärna med en tabell om det går.

text: Modulanrop                                     	Förväntat resultat	Erhållet resultat (WD)              	Erhållet resultat (IB/WD)                                  	Kommentar
          	Luxemburg         			Fungerar i båda
	xxx               	yyy                                 	xxx                                                        	Fel i WD, Rätt i IB/WD

text: --Larske (diskussion) 5 oktober 2015 kl. 23.31 (CEST)
replies: text: :Det var när jag ville lägga in en funktion för att kunna använda parameter label tillsammans med "url"-datatypen som det inte funkade. datatype.type ser inte skillnad på url/string/commonsmedia-datatyperna. De är alla string i den parametern. Det är bara funktion formatStatements jag berört här.

text: :

text: :En liknande funktion ska kanske finnas även för string-datatypen, men bör fungera helt annorlunda i media-datatypen.

text: :[File:The Simpsons Shorts Logo.png Hej] ger inte önskad effekt, utan bör istället ge . - Innocent bystander 6 oktober 2015 kl. 07.43 (CEST)
thread_title: Ändringar

message: Modulen på Wikidata är byggd för en flerspråkig wiki och saknar flera funktioner, så jag har byggt vidare på Modul:Wikidata för att få den att stödja källor och bättre kunna skräddasy påståenden. Inte heller andra stora wikis har haft något bra stöd för källor. Undantaget har kanske varit ruwiki, men språkliga hinder har gjort den svåröversatt. Dessutom är den delvis byggd för att prioritera ryska källor, något jag inte vill kopiera. Även jag har här byggt in en funktion som gör att svenskspråkiga påståenden ges företräde, men det är främst (eller snarare enbart) för att vi inte ska råka ut för att kilogram ska förkortas кг.
Min kodning på omstående sida är inte vacker, men det börjar likna något:
Verk: 
Sysselsättning: 
Ni kan prova att justera källorna för P800 och P106 i Q4115189 och se hur ovanstående påverkas. Det som syns i källorna här ovan är ännu bara "placeholders", men man ser tydligt att närvaron och antalet källor framgår. Det här är långt ifrån moget att presenteras för wikin i stort, men jag ville ändå visa framstegen. Och eftersom koden är rena spagettiwestern, kan den knappast exporteras till andra wikis. -- Innocent bystander 8 oktober 2015 kl. 14.41 (CEST)
replies: text: Det syns lite mer nu. Det som stöds hittills är titel och författare. Jag hade stöd för ISBN ett tag, men en bugg har plockat bort det... hmmm -- Innocent bystander 9 oktober 2015 kl. 11.47 (CEST)
replies: text: :Och där funkar ISBN. -- Innocent bystander 9 oktober 2015 kl. 16.41 (CEST)
Tätortskod: 
replies: text: ::Och ovanstående visar att "referens-url" funkar för att källbelägga Kumlas tätortskod. -- Innocent bystander 9 oktober 2015 kl. 16.50 (CEST)
replies: text: :::redaktör tillaggd. -- Innocent bystander 9 oktober 2015 kl. 17.05 (CEST)
replies: text: ::::+Utgivare. -- Innocent bystander 9 oktober 2015 kl. 17.13 (CEST)
replies: text: :::::+Hämtdatum, åtminstone om årtalen är gregorianska och e.Kr. -- Innocent bystander 10 oktober 2015 kl. 09.18 (CEST)
replies: text: ::::::+Publiceringsdatum -- Innocent bystander 10 oktober 2015 kl. 11.34 (CEST)
replies: text: :::::::+Utgåva. -- Innocent bystander 10 oktober 2015 kl. 12.21 (CEST)
replies: text: ::::::::+Sidnummer. -- Innocent bystander 10 oktober 2015 kl. 14.17 (CEST)
replies: text: :::::::::+Volym, doi, pmid, nummer. -- Innocent bystander 11 oktober 2015 kl. 15.05 (CEST)
replies: text: ::::::::::+licens och importerat från. -- Innocent bystander 11 oktober 2015 kl. 16.44 (CEST)
replies: text: :::::::::::Och där har jag nu lagt in alla källor som bygger på string-datatyper som det finns en P1630 i själva propertyn för. Se not 5 i den översta referenslistan ovan. Där finns VIAF, vilket är en property som Module:Cite inte har en skräddarsydd procedur för. Just den grejen är nog den mest avancerade jag byggt här på Wikipedia. Nästan vilken "Auktoritetsdata" som helst finns det nu i princip stöd för. -- Innocent bystander 11 oktober 2015 kl. 18.31 (CEST)
thread_title:  Framsteg 

message: Experimenterat lite på hur man bäst får anpassade länkar till Wikidata inne i infoboxarna. Det system jag arbetat med här funkar inte i komplexa sammanhang, såsom i Mall:Ortsfakta Sverige WD som anropar en modul som anropar en modul. Istället kräver det här att man hämtar direkt genom anrop eller direkt i mallen (såsom i biografi-mallen). (I Ortsfakta går det dock att bygga samma sak i den yttre modulen.)
Douglas Adams kön:
* 
* (default)
* (bakom sup-tag)
* (bakom sub-tag)
*(bakom small-tag)
* (Det går också att anpassa länklabeln)
-- Innocent bystander (diskussion) 22 december 2016 kl. 21.18 (CET)
replies: text: Frwiki har dessutom dessa länkar bakom lite css-hokuspokus. Behöver vi det?  Var, när och hur? -- Innocent bystander (diskussion) 22 december 2016 kl. 21.47 (CET)
replies: text: :Innocent bystander: Kan du länka till en sida på frwiki så att jag kan se vad du menar? Nirmos (diskussion) 23 december 2016 kl. 11.18 (CET)
replies: text: ::Jag besöker frwiki ganska sällan, men en början är :fr:Module:Wikidata. Där finns en funktion med namnet "wd.addLinkback". Jag har inte alls byggt min funktion i denna mall likt den franska, så... -- Innocent bystander (diskussion) 23 december 2016 kl. 11.51 (CET)
thread_title:  WD-länk 

message: Thanks a lot for your help last time! That was of great help! Now, I try to avoid problems with multiple coordinates in the same page, by adding "secondary" instead of "primary" in the call to this parser. options.num is an internal parameter, counting the "index" of the claims. But it does not look like it solves the problem. Look now in our WD-sandbox which now call for P625 in the WD sandbox. -- Innocent bystander (diskussion) 26 december 2016 kl. 20.52 (CET)
replies: text: mw:Extension:GeoData doesn't seem to support this magic word, simplified. Matěj Suchánek (diskussion) 26 december 2016 kl. 21.22 (CET)
thread_title:  1 = secondary Geodataparser 

message: Jag försöker experimentera här med konvertering av enheter. ha->km2 mile2->km2 etc. Systemet fungerar tillfredställande när det gäller själva beräknandet nu. Alingsås har sin area angiven i hektar, medan Saginaw har sina i kvadratmile. Konverteringsfunktionen ger nu:
replies: text: 
Som du ser så funkar det utmärkt att konvertera när omvandlingen är ett jämnt tiotal, men från kvadratmile till kvardratkilometer blir det nu löjligt många decimaler. Jag funderar på om det funkar att konvertera även lowerBound och upperBound och skicka vidare till Module:Math#p.newFromWikidataValue för avrundning. Men det funkar nog inte när dessa parametrar saknas eller är samma som "value".
Den här funktionen kan nu inte konvertera från procent till ppm eller liknande. Det funkar bara för de som har P2370. Den funkar inte heller för enheter som fot, som inte heller har P2370. En förutsättning är också att både den i objektet angivna enheten och den enhet man vill åt, har angivit samma enhet i P2370. Så finns det delade meningar om vilken som är grundenhet så sk-ter det sig. -- Innocent bystander (diskussion) 28 december 2016 kl. 08.10 (CET)

text: Vet inte om det kan vara till nån hjälp, men jag har gjort en Lua-funktion "avrunda2" som kanske skulle kunna användas för att få ett önskat antal decimaler (eller kanske hellre önskat antal värdesiffror) i variabeln "amoutconv".

text: Exempel med 18.1 square miles till kvadratkilometer med tre värdesiffror:

text: Den ska även klara av att behålla "nollor på slutet":

text: och negativa tal om det skulle vara aktuellt:

text: Några fler testfall finns på sidan Användare:Larske/Testsida5#Test av Lua-funktionen avrunda2. --Larske (diskussion) 28 december 2016 kl. 19.25 (CET)
replies: text: :Tack, Larske! Jag gjorde en fix nu så att upperBound och lowerBound följer med i konverteringen, när dessa finns. Det löser fall som Saginaw på ett hyfsat snyggt sätt.

text: :Men det löser inte de fall där upper/lowerBound saknas. Då återstår din algoritm. Hur bestämmer man antalet värdesiffror, eller tvingas man ange det och ha kanske tre siffror som default? -- Innocent bystander (diskussion) 28 december 2016 kl. 20.05 (CET)
replies: text: ::I nuvarande utförande är "vardesiffror" en parameter (konstant) som man kan ange om man inte väljer att ange antalet decimaler. Det är ju bara ett värde som ska avrundas och hur det värdet har kommit till vet funktionen inget om. --Larske (diskussion) 28 december 2016 kl. 20.18 (CET)
replies: text: :::Testade nu, och det ser ut att fungera mycket väl. Finns ingen "upperBound" eller den är identisk med "amount" så används din algoritm med vardesiffror = 3 som default. Vill du kopiera över din algoritm till Modul:Math så kan jag ropa på den där?! -- Innocent bystander (diskussion) 28 december 2016 kl. 20.42 (CET)
replies: text: :::: OK, funktionen har flyttat in i :Modul:Math nu. Där heter den avrunda. Det andra namnet var bara nåt jag använde för att jag redan hade en funktion i min testmodul som hette avrunda. --Larske (diskussion) 2 januari 2017 kl. 23.40 (CET)

text: Testar!
*
*
*
*

text: -- Innocent bystander (diskussion) 3 januari 2017 kl. 07.24 (CET)
replies: text: :Se där! Hästkraft går inte att konvertera till kvadratmeter! -- Innocent bystander (diskussion) 3 januari 2017 kl. 07.35 (CET)
replies: text: ::Och kvadratfot går inte att konvertera till Watt! -- Innocent bystander (diskussion) 3 januari 2017 kl. 09.53 (CET)
thread_title:  Konvertering av enheter 

message: Funkar den koorder förenkling som jag gav mig på i Modul:Sandlådan/Lokal Profil/WD? Var ett tag sedan jag kikade i LUA och är definitivt inte insatt i LUA optimering. /André Costa (WMSE) (diskussion) 28 juli 2017 kl. 16.31 (CEST)
replies: text: Det ser definitivt rätt ut! Din lösning ser dessutom ut att kunna öppna upp för att ta hänsyn till ännu finare precision än vad den gör nu. -- Innocent bystander (diskussion) 28 juli 2017 kl. 20.17 (CEST)
replies: text: : Observera att när du kopierar över din kod till Modul:Wikidata2 så behöver du ändra "Cite2" till bara "Cite" i koden. Skillnaden är att den här testmodulen har sin egen källhanterings-lösning skild från Wikidata2's. Detta behövs eftersom modulerna länkar varandra fram och tillbaka.

text: :En sak jag hade tänkt försöka lösa också, är att slippa upprepa samma källa 25 gånger såsom det görs nu i "Stockholm (tätort)" i Användare:Innocent bystander/sandlåda. Det känns lite småknepigt, men jag tror det ska gå. Varje reference är associerad med en "hash"-kod som också används som kod i <ref name=hash>. Genom att samla ihop en "stack" av sådana koder, kan jag sedan sortera ut de källor som upprepas. Då kan din "nålihöstack"-lösning komma väl till pass. -- Innocent bystander (diskussion) 28 juli 2017 kl. 20.33 (CEST)
replies: text: ::Jag kopierade över koorder och inlist till Modul:Wikidata2  men har inte kopierat över något av det andra (eftersom jag inte vet vilka ändringar som gjorts). /André Costa (WMSE) (diskussion) 1 augusti 2017 kl. 12.28 (CEST)
replies: text: :::Gott, det enda som var ändrat i övrigt var ett försök till fix för det skriptfel som finns lite överallt nu. Det problemet finns dock djupt nere i Wikibase/Scribunto, inte i koden här. -- Innocent bystander (diskussion) 7 augusti 2017 kl. 16.41 (CEST)
thread_title:  koordinater 

message: För att kunna fånga alla fall där annat språk än svenska används, behöver labeln hämtas på annat sätt än genom mw.wikibase.label( entityId ). Tror du det blir väldigt kostsamt? 62 osv (diskussion) 5 december 2019 kl. 09.09 (CET)
replies: text: Jag tror att det som är resurskrävande ("kostsamt") främst är att läsa in hela objekt, getEntityObject() alltså. Speciell om det är mastodontobjekt som till exempel . Helst borde man bara läsa in ett objekt en gång för varje faktamall. Det är en balansgång, hur mycket ska man baka in i Lua-koden och hur enkelt ska det vara att kunna "bygga om" infoboxmallarna med hjälp av  och "måsvingespråket" för de som inte kan eller vill koda i Lua.

text: Men om objektet redan är inläst tror jag att "kostnaden" att i Lua-koden "slå upp" några etiketter är marginell. Men att loopa över alla språkkoder bör kanske undvikas.

text: Sammanfattning av vad jag tror:

text: item = getEntityObject(qid) ← kostsamt

text: svensk_etikett = item['labels']['sv'] ← inte så kostsamt

text: För att undersöka "kostnaden" kan du göra en testfunktion där du loopar den kodsnutt du är orolig för till exempel 100 gånger och se vilken inverkan det har på exekveringstid och minnesåtgång. Det finns uppgifter om "Lua time usage", "Lua memory usage" med mera längst ner på sidan.

text: --Larske (diskussion) 5 december 2019 kl. 09.48 (CET)
replies: text: :Det gör att det blir kostsamt om man måste varna även för engelska labels. Och det är kanske främst de som irriterar. De är vanligast åtminstone. 62 osv (diskussion) 5 december 2019 kl. 10.14 (CET)
replies: text: ::Hmm, nu är jag inte riktigt med. Det som är kostsamt är väl att plocka fram det objekt som en viss egenskap har som värde, men det görs väl alltid (oavsett etikettstatus). Men att sedan konstatera om det saknas en svensk etikett för detta objekt kostar, om mitt resonemang ovan stämmer, inte mycket om objektet redan är inläst.

text: ::Kan du ge något konkret exempel.

text: ::--Larske (diskussion) 5 december 2019 kl. 10.22 (CET)
replies: text: :::Det är ju inte objektet självt (artikeln som mallen ligger i) som vi i 99 % av fallen är intresserade av att få fram label om. Och är vi det, brukar vi nog gå andra vägar än genom formatStatements. Istället är det ju vilken label objektet som en property länkar till som är intressant. Idag hämtar vi bara hem hela objektet om det saknas en svensk eller engelsk label på den propertyn. Måste vi alltid göra det, för att undersöka om den label som hämtats är svensk eller engelsk, så kan det bli väldigt kostsamt när mallarna är stora. 62 osv (diskussion) 5 december 2019 kl. 10.31 (CET)
replies: text: ::::Du skriver att "vi hämtar bara hem hela objektet om det saknas en svensk eller engelsk label". Men då finns det alltså redan information om huruvida det saknas, så vad är problemet du vill lösa?

text: ::::--Larske (diskussion) 5 december 2019 kl. 10.39 (CET)

text: ::::Tillägg: Jag förstår inte varför det, i en faktamall, är intressant att ange exakt på vilket språk det finns lablar för ett objekt som pekas ut av en egenskap. Det räcker väl att konstatera att svensk etikett saknas om så är fallet och lägga in artikeln i en åtgärdskategori för just detta.

text: ::::--Larske (diskussion) 5 december 2019 kl. 10.45 (CET)
replies: text: :::::I funktionen "formatEntityId" börjar den med en "label = mw.wikibase.label( entityId )". Här tilldelas label ett värde om det finns en etikett på svenska eller engelska.

text: :::::Om label inte fått något värde tidigare, så nås raden "local s = getLabelFromFallBack( entityId )" längre ner. I den funktionen hämtas hela objektet för att hitta någon label. (Kostsamt, men det sker inte så ofta.) Uifrån vad den hittat går det att lägga in en kategori för labels på främmande språk. (Om den är på turkiska eller swahili är kanske mindre intressant.) Men det går inte att se om label har ett värde på svenska eller engelska om den fick ett värde i det första skedet. Och det är de icke-svenska värdena vi är intresserade av. 62 osv (diskussion) 5 december 2019 kl. 10.52 (CET)
replies: text: ::::::Ja, då förstår jag vad du menar. Men vad är det som får mw.wikibase.label att returnera svenska eller engelska? Kan man inte med någon parameter ange att man bara är intresserad av svenska. Då ges det direkt av svaret om det finns eller inte finns någon svensk etikett.

text: ::::::Jag hittade mw.wikibase.getLabelByLang(). Den borde väl gå att använda.

text: ::::::--Larske (diskussion) 5 december 2019 kl. 11.01 (CET)
replies: text: :::::::Exakt vad jag letar efter! Det står att den är avsedd för flerspråkiga wikis, men vi kan alltid testa. 62 osv (diskussion) 5 december 2019 kl. 11.34 (CET)
replies: text: ::::::::Jag tycker att det står att den inte bör användas för flerspråkiga wikis, men svwp är väl inte flerspråkig så det är nog helt ok. --Larske (diskussion) 5 december 2019 kl. 11.50 (CET)
replies: text: :::::::::Då så!   62 osv (diskussion) 5 december 2019 kl. 12.08 (CET)
===Test av "kostnaden" för getLabelByLang()===
Jag gjorde en enkel test av exekveringstiden för funktionen getLabelByLang(id,lang). Resultatet nedan visar att den är cirka 0,3–0,4 millisekunder i medeltal för 100 "slumpvis valda" objekt. Inget att oroa sig för alltså.
Anrop	Resultat
	
--Larske (diskussion) 5 december 2019 kl. 12.32 (CET)

text: Funktionen fungerar även i "raw"-mode. 62 osv (diskussion) 5 december 2019 kl. 19.43 (CET)
thread_title:  formatEntityId 

message: Jag gjorde en enkel test av exekveringstiden för funktionen getLabelByLang(id,lang). Resultatet nedan visar att den är cirka 0,3–0,4 millisekunder i medeltal för 100 "slumpvis valda" objekt. Inget att oroa sig för alltså.
Anrop	Resultat
	
--Larske (diskussion) 5 december 2019 kl. 12.32 (CET)
replies: text: Funktionen fungerar även i "raw"-mode. 62 osv (diskussion) 5 december 2019 kl. 19.43 (CET)
thread_title: Test av "kostnaden" för getLabelByLang()