Moduldiskusjon:WikidataListe

Indentering

Bruk et verktøy for å rydde i indenteringen, og helst et som bruker samme form for indentering som editoren vi bruker. — Jeblad 22. jul. 2015 kl. 01:41 (CEST)

TR-tags

Hvis det dyttes ting inn mellom tr-tags, dvs mellom </tr> og <tr>, så er det litt tilfeldig hvor dette plasseres. Noen unntak finnes, og det er «magic links» eller lenker som tas ut av den normale dokumentflyten og rendres andre steder. Kategori-lenker er slike, men det er kun lenka som flyttes og ikke annet som rendres på samme stedet. Jeg vil sterkt anbefale å unngå at noe som helst plasseres mellom tr-tags, selv om det er trygt når det kun er kategorier uten noe ekstra som i dette tilfellet. — Jeblad 22. jul. 2015 kl. 01:47 (CEST)

Symboler

Alle symboler bør skrives med fulle navn og i henhold til etablert standard. Symboler som «c», «t1», og «t2» bør ikke forekomme. Jeg vet ikke om dette er formalisert noe sted for Lua-kode, men for alle PHP og Javascript i de overordna prosjektene er det stilt som et krav. Jeg mener vi godt kan vedta det på Tinget så blir det ingen diskusjon senere. — Jeblad 22. jul. 2015 kl. 01:52 (CEST)

Litt om maler og wd

Parameternavn og header for samme parameter er ikke det samme. Det betyr i praksis at en rad ikke kan konstrueres med et parameternavn som omskrives til en header. Enten må rad-kallet ta et argument som gir headeren, eller så må det settes opp en struktur noe annet sted. En typisk løsning er å angi headeren via Mediawiki-rommet.

Properties matcher mot parametre i malene, men malene kan ha forskjellige føringer på hva som blir vist. Noen av disse føringene er beskrevet som qualifiers på Wd. Skal en egenskap vises frem så må et boolsk uttrykk evaluere til true. Så langt er dette alltid satt til true i alle våre artikler, men det er ikke vanskelig å tenke seg situasjoner hvor en eller flere qualifiers må evaluere til true. Hvordan disse uttrykkene skal settes opp er ikke klart.

Malene angir typisk en parameter mens properties kan inneholde flere statements, det disse som holder dataverdiene. Det er litt uklart hva som omtales som statements og claims for tiden, og det ligger an til en forenkling. En enkel antakelse er at alle oppføringer skal listes, men det er kun de oppføringene som faktisk tilfredsstiller det boolske uttrykket som skal inkluderes. Minst ett av uttrykkene må evaluere til true for at malens parameter er tilfredsstilt. Dette er egentlig en litt forenklet modell, en riktigere modell er at forskjellige properties former sett av datavalues som så kombineres via sett-operatorer.

Som om dette ikke er nok så finnes det en rank-verdi for de enkelte statements. Hvis et statement er merket med deprecated så skal den ikke brukes. Dette tilfellet er enkelt, for det betyr at oppføringen skal alltid forkastes. Hvis den er merket med preferred så skal den brukes. En oppføring med preferred har også en bieffekt, den skal brukes istedenfor ingen, en eller flere andre statements som også er listet i samme property.

Det som skaper problemer med rank satt til preferred er at det ikke er klart hvilken oppføring som skal erstattes, med unntak av de tilfellene hvor det kun skal komme en enkelt oppføring ut av settet. I disse tilfellene skal oppføringer med preferred velges foran alle andre som tilfredsstiller qualifier-uttrykket, som ofte bare settes til true. Typisk er dette slikt som flagg i en mal for stater. Det er et reelt problem at en del verdier vi lett antar er singulære faktisk ikke er det. Fødested på Knut Hamsun for eksempel, eller fødselsdato (eg. år) på Johannes Flintoe.

Hvis det skal returneres en liste så er det derimot ikke alltid klart hva som skal erstattes. For å identifisere riktig oppføring må det defineres et mål for likhet mellom oppføringer. Dette likhetsmålet kan i noen tilfeller defineres utfra propertyen selv, men som oftes utfra hvilken qualifieres som er i bruk. Ofte er det et lite antall qualifiers i bruk for en property, men hvis oppføringen er preferred så må den ha tilstrekkelig med qualifiers til at andre oppføringer kan forkastes. For eksempel så må oppføringer med en tidsserie for folketall ha qualifiers som sier hvilket tidspunkt folketallet (som er preferred) er gyldig for, og tilsvarende hvilke tidspunkt som er anført for folketall med normal rank. Hvis disse oppføringene bare har diskrete tidspunkt så kan en lett ende opp med at oppføringene med preferred og normal legger seg pent og pyntelig ved siden av hverandre. For å unngå dette må en bruke tidsrom eller presisjon på tidsangivelsene.

Som oftest vil ikke prosessering på Wikipedia forholde seg til properties, derimot til data value type. Dette er en egenskap knyttet til hver enkelt property. Formatering og presentasjon av en property er ikke gitt av propertyen som sådan, men av dennes data value type. Koden i modueln har en metode enkeltverdi, og denne må ha en formatter for hver enkelt data value type.

Det er også et problem med at qualifiers noen ganger brukes for ekstra data. Disse dataene skal da vises frem, og ikke brukes for å filtrere ned et sett. Det er ikke klart hvilken qualifiers dette gjelder, og det er ikke noen entydig beskrivelse på Wd såvidt jeg vet.

Det er helt sikkert mer, men det er vel en slags start. — Jeblad 22. jul. 2015 kl. 05:26 (CEST)

Utdannelse

Bruk av utdannet ved (P69) for «utdannelse» er helt klart gal, men akademisk grad (P512) er også helt gal. En «tømrer» impliserer ikke akademisk grad, men er like fullt en utdannelse. Redigeringen [1] er dermed feil. — Jeblad 18. aug. 2016 kl. 19:06 (CEST)

Du har et poeng, men det er ikke galt, det er bare det at det ikke er definert et dataelement for ikke akademiske utdannelser, "ikke akademiske" "profesjon"s-utdannelser --Mysteriumen•♪Ⓜ (diskusjon) 18. aug. 2016 kl. 19:15 (CEST)

Det er nok ikke helt slik Wikidata fungerer. Bruk riktige egenskaper, og sett på riktige navn på dem. — Jeblad 18. aug. 2016 kl. 23:12 (CEST)

Det er ikke tydelig hva det er du foreslår. Og påstanden din er også utydelig. På wikidata er det en diskusjon om bruken av de to utdannet ved (P69) og akademisk grad (P512) på deres respektive diskusjonsider. Diskusjon om bruken av disse burde vel gå der og ikke her.--Mysteriumen•♪Ⓜ (diskusjon) 19. aug. 2016 kl. 01:19 (CEST)

Det er her inne du har gjort en feil. Egenskapen akademisk grad (P512) er ikke det samme som «utdanning», det er en svært begrenset subtype for akademisk utdanning. Det samme gjelder for utdannet ved (P69), det er en svært begrenset subtype for akademisk utdanningssted. Det virker for meg som om du begår den her typen feil fordi du mangler kunnskaper i norsk. — Jeblad 19. aug. 2016 kl. 10:43 (CEST)

Det er ganske ignorant å påstå at akademisk grad (P512) ikke er utdanning. Jeg ser du prøver å hevde definisjonsmakt på dette. Du har hengt deg opp i en spesiell bruk av denne dataenheten slik den kan brukes som subenhet for utdannet ved (P69). Men det har seg faktisk slik at dataenheten også gir mening alene. Men en kan diskutere om en skal fjerne utdanningsfeltet helt fra wikipedia, eller slå sammen alle de feltene som dreier seg om utdannelse. Det vil isåfall være en ganske radikal endring. Men utdannelse er utdannelse på alle språkene. Feltet akademisk grad (P512) dekker de utdannelsene som omtales mest i wikipedia (så langt jeg kjenner til). Derav kan mye forklares. Hos oss på norsk wikipedia så mangler et script som henter akademisk grad (P512) sammen med utdannet ved (P69). Så for den bruken du antyder, så har vi ikke satt opp for bruk av wikidata... Men utdannet ved (P69) gir mindre mening alene. Uten akademisk grad (P512) så har har informasjonen mindre verdi. Sånn sett er det best at når de to dataenhetene finnes, så blir de presentert sammen, og ikke hver for seg.--Mysteriumen•♪Ⓜ (diskusjon) 19. aug. 2016 kl. 11:27 (CEST)

Kjenner du til typer og subtyper? Er «tømrer» en utdannelse? Er «tømrer» en akademisk utdannelse? Er «lege» en utdannelse? Er lege en «akademisk utdannelse»? Er en «akademisk utdannelse» en «utdannelse»? — Jeblad 19. aug. 2016 kl. 12:36 (CEST)

Slektninger uten artikkel

Er det mulig å la være å hente foreldre, partnere, søsken og barn som ikke har wikipedia-artikkel på noe språk? --Avilena (diskusjon) 2. jun. 2018 kl. 18:45 (CEST)

Tror ikke jeg ser problemet dette skal løse? Slektskap defineres jo ikke utfra hva som er omtalt? — Jeblad 2. jun. 2018 kl. 19:07 (CEST)

@Avilena: Ja, det er det. Hvis du f.eks. ser i artiklene om Christian Krohg eller Oda Krohg står to navn under barn; Per Krohg og Nana Krohg Schweigaard. Sistnevnte har ikke artikkel på noen språkversjon per i dag. Jeg har opprettet element på henne, hun var tegner og grafiker og har bl.a. identifikatorer fra KulturNAV og Norsk kunstnerleksikon. --Anne-Sophie Ofrim (diskusjon) 2. jun. 2018 kl. 20:18 (CEST)

På wikidata er det noen som setter opp fullstendige slektstre. Vi har vel en tradisjon for å bare ta med notable slektninger i infoboksen. Jeg er skeptisk til å ha med Stan Wawrinkas foreldre, søsken og barn! i infoboksen. Mangelen på artikler om disse tar jeg som et tegn på at de ikke er kjent for å være annet enn i slekt med han. --Avilena (diskusjon) 4. jun. 2018 kl. 17:04 (CEST)

Lag/klubber i infoboks sportsbiografi

Kunne noen byttet ut #statements med #invoke:WikidataListe for P54 i {{Infoboks sportsbiografi}}? Det ser bedre ut med årstall, men jeg får det bare nesten til selv. --Avilena (diskusjon) 12. jun. 2018 kl. 22:07 (CEST)

Jeg fikk det til. --Avilena (diskusjon) 14. jun. 2018 kl. 22:27 (CEST)

Sortere lista

Går det an å få sortert resultatet kronologisk etter starttidspunkt, og ikke bare slik forekomstene er lagt inn i wikidata? Det er særlig aktuelt for klubber, men også for bl.a ektefelle. --Avilena (diskusjon) 14. jun. 2018 kl. 23:20 (CEST)

Sortering er et ikke-trivielt problem. Skal en gjøre kronologisk sortering forutsetter det at kvalifikatorer er satt på, og at disse har informasjon om tidspunktene det skal sorteres etter. Det forutsetter også at kvalifikatorene som brukes er sammenlignbare, og at de er entydige. Anta at en utøver har startet i en klubb før han har sluttet i en annen klubb, da er kanskje starttidspunktet entydig, men hva om en bare kjenner medlemskapet ved et bestemt tidspunkt? Hva om en har sortert en liste og så mangler en tidspunktet for en klubb, hvor skal dette plasseres? Hva hvis en har et slutt-tidspunkt, men mangler starttidspunktet, og slutt-tidspunktet er før alle andre i lista? Hva hvis noen andre er før denne oppføringen? Hva hvis alle er før den?

Det er mulig å sortere på samme vis som i cluster-algoritmer, men dette er nokså tungt, og rekkefølgen en får er ikke alltid opplagt. Metoden går ut på at alle type-bestemte tidspunkt har en ordning gitt ved tiltrekning mot andre lavere verdier og frastøtes av høyere verdier, og fordelingen normaliseres slik at plasseringen blir avgrenset. Samtidig tiltrekkes utsagnet av alle plasseringene som gis tidspunktene det selv inneholder. Etter kun noen få iterasjoner er en orden etablert.

Metoden kan brukes for å sortere tidspunkt for medlemskap i klubber, temporale lister, men også heterogene lister som kombinerer tid og posisjon eller helt andre kategorier.

Egentlig er dette ett av tre problemer som henger sammen; d:Wikidata:Grouping statements, d:Wikidata:Sorting statements, og d:Wikidata:filtering statements. Eller egentlig så sklir ordering mellom grouping og sorting. Det er min dårlige samvittighet at disse ikke er skrevet ferdig. — Jeblad 14. jun. 2018 kl. 23:57 (CEST)

Har skrevet kode for alfabetisk sortering og kronologisk sortering. Den første er nokså grei, men den siste trenger litt opprydding og testing. Før dette tas i bruk må det finnes konsensus for det, hvis ikke tror jeg dette ender i en veldig omfattende diskusjon. — Jeblad 15. jun. 2018 kl. 10:18 (CEST)

@Jeblad: Har du lenke til koden? Dette høres jo supert ut! Har flere ganger tenkt på at verdiene burde vært sortert når jeg har sett på infobokser, men som du sier er det jo ikke helt trivielt å fikse på en god måte. – Danmichaelo (δ) 10. des. 2018 kl. 21:07 (CET)

Alfabetisk er i historikken [2], en enkel kronologisk er nesten identisk (dvs definer ny funksjon)). Dette er tilstrekkelig pga måten Lua håndterer tabeller. Et annet eksperiment er på Modul:OrganizeClaims. Dette er for å endre standardsorteringen av qualifiers og references, slik at den passer bedre, whatever bedre måtte være. Begynte på en cluster-algoritme, men er ikke sikker på hvor det var, mistenker at den er ryddet til sylinderarkivet. Det er ikke veldig komplisert kode, det er en w:k-nearest neighbors algorithm av varianten k-nearest neighbors regresion, hvor k=1, og hvor «property value» er distanse i tid og angir sort order. — Jeblad 11. des. 2018 kl. 14:14 (CET)

Hente kvalifikatorer for P2415 (personlig rekord)

Jeg har forsøkt å legge til en funksjon for å hente P2415 ved å bruke WikidataListe for å få med kvalifikatorer i infoboks. Jeg har lagt til funksjonen p.radRekord, men det ser ikke ut til å fungere noe videre. Dette er nokså ukjent land for meg, er det noen mer kyndige her som ser hva som mangler? ---- cavernia -- (diskusjon) 17. mar. 2019 kl. 19:35 (CET)

Sporingskategorier

Er det mulig å justere slik at [[Kategori:Artikler hvor " .. param .. " mangler på Wikidata]] kun settes hvis artikkelen er koblet til Wikidata? --Avilena (diskusjon) 10. feb. 2020 kl. 17:07 (CET)

Liste over ting som må fikses ved sammenligning av lokal og WD parameter

Hei, hvis noen har lyst til å se på hvordan man kan få bedre resultat på kategoriene, Artikler hvor XX samme som på Wikidata og Artikler hvor XX forskjellig fra Wikidata. Her er noen av feilene(/tips om utvidelse) jeg har funnet :) -Premeditated (diskusjon) 9. okt. 2020 kl. 17:20 (CEST)

Artikel	Lokalt (A)	Wikidata (B)	Resultat	Notat	Løst
[3]	| nasjonalitet = svensk	statsborgerskap (P27) → Sverige (Q34)	Artikler hvor nasjonalitet forskjellig fra Wikidata
[4]	|fsted = Miami, Florida	fødested (P19) → Miami (Q8652)	Artikler hvor fsted forskjellig fra Wikidata
[5]	| beskjeftigelse = Danser og koreograf	beskjeftigelse (P106) → danser (Q5716684), beskjeftigelse (P106) → koreograf (Q2490358)	Artikler hvor beskjeftigelse forskjellig fra Wikidata
[6]	| nasjonalitet = Norsk	statsborgerskap (P27) → Norge (Q20)	Artikler hvor nasjonalitet forskjellig fra Wikidata	vanskelig å sammenligne
[7]	Annet navnerom enn hoved	Ikke koblet til noe WD item	Artikler hvor XX forskjellig fra Wikidata
[8]	|nasjonalitet = [[Sverige|Svensk]]	statsborgerskap (P27) → Sverige (Q34)	Artikler hvor nasjonalitet forskjellig fra Wikidata
[9]	|født = {{Fødselsdato|1909|07|02}}	fødselsdato (P569) → 2 July 1909	*ingen kategori*
[10]	|utmerkelser=Nobelprisen i fysiologi eller medisin<br />Louisa Gross Horwitz Prize	utmerkelse (P166) → Nobelprisen i fysiologi eller medisin (Q80061), utmerkelse (P166) → Louisa Gross Horwitz-prisen (Q899039), utmerkelse (P166) → Welch Award in Chemistry (Q1632244), ++	Artikler hvor utmerkelser forskjellig fra Wikidata	$A\subseteq B$
[11]	|bilde = Sune Bergström 3.jpg	bilde (P18) → Sune Bergström 3.jpg, bilde (P18) → Sune Bergström.jpg	*ingen kategori*
[12]	| nasjonalitet = [[Russland|Russisk]]	statsborgerskap (P27) → Sovjetunionen (Q15180), statsborgerskap (P27) → Russland (Q159)	Artikler hvor nasjonalitet forskjellig fra Wikidata	$A\subseteq B$
[13]	|bilde = Mike_Brown_2003.jpg	bilde (P18) → Mike_Brown_2003.jpg	Artikler med bilde forskjellig fra Wikidata
[14]	| født = [[27. oktober]] [[1991]]	fødselsdato (P569) → 27 October 1991	*ingen kategori*
[15]	| født=ca. [[850]]	fødselsdato (P569) → 850	*ingen kategori*
[16]	|død=ca. [[931]]-[[932]]	fødselsdato (P569) → 933	*ingen kategori*
[17]	|far=[[Halvdan Svarte]]	far (P22) → Halvdan Svarte (Q504932)	*ingen kategori*	Testet i «forhåndsvisning»
Sist oppdatert: 9. oktober 2020

Doktorgradsstudenter

@Haros: Kan du vurdere om doktorgradsstudenter (doktorgradsstudent (P185)) bør legges til lista? Parameteren brukes i Mal:Infoboks forsker, og noen forskere har hatt mange av dem (f.eks. Werner Heisenberg). Kanskje det kan legges inn linjeskift etter hver av dem også? - 4ing (diskusjon) 5. mai 2022 kl. 09:10 (CEST)

(en) og andre parenteser

Hei hei! Gjennom henting av informasjon gjennom Wikidata, så forekommer det ofte det jeg mener er usiktlige «(en)»-parenteser (eller andre språkkoder). Om disse skal beholdes, er det mulig å kategorisere disse, slik at det er lettere å finne fram til artikler som har uoversatte etiketter (f.eks. «Kategori:Artikler med uoversatte etiketter fra Wikidata gjennom WikidataListe»)? Jeg mener for øvrig at det kan være litt unødvendig å vise parentesen, spesielt når det handler om ganske mange navn som ellers hadde vært det samme på norsk (som barna til Danny DeVito eller familie til Rhea Perlman og spesielt forekomster hvor det settes ved siden av andre parenteser). Kategori hadde vært hyggelig hverken det skal være språkkodeparentes eller ei.

Utenom språkkodeparentesen, syntes jeg at andre parenteser som henter kvalifikatorer også er noe ufine eller spesielt forkludrende. Jeg tenker på slikt som det som sees under «Akademisk grad» på Ngahuia Te Awekotuku: «Ph.d. (1981) (avhandling bedømt av: University of Waikato)[1]» og under «Hovedkontor» og «Eier(e)» på Meta (selskap): hhv. «Menlo Park (plassering: 1 Hacker Drive, ligger på/i geografisk enhet: Stanford Research Park, jurisdiksjon: USA)» og «Mark Zuckerberg (2021) (av: voting interest), Dustin Moskovitz (2021) (av: voting interest), Eduardo Saverin (2021) (av: voting interest), BlackRock (2021) (av: voting interest)» (kommaene er linjeskift i sistliggende). Jeg reagerer spesielt på dette ettersom etikettene på Wikidata (etter det jeg ser) ikke er skrevet med tanken om at det skal være lettvint for alminnelige lesere å tyde, slik som ved «ligger på/i geografisk enhet» og «jurisdiksjon». Henter modulen alle tilføyde kvalifikatorer på hentede elementer?

Om parentesene er her for å bli, så skulle jeg gjerne sett at de ble kombinert, f.eks. «Facebook Ireland Limited (en; 2004–; jurisdiksjon: Det europeiske økonomiske samarbeidsområde, Irland)» i stedet for det nåværende «Facebook Ireland Limited (en) (2004–) (jurisdiksjon: Det europeiske økonomiske samarbeidsområde, Irland)», men jeg skulle heller ønske at kvalifikatorer var/virket mer håndplukka og tilsikta som tidligere. Jeg tenker også spesielt på dette når en har satt av arbeidstid til å forsøke å gjøre informasjonen i spesifikke infobokser tydelig og raskt lesbar, og er redd for at (og det virker litt bevist) at tilføying av all denne informasjonen kan framstå som utydelig og vanskelig å tyde når infoboksen skal formidle informasjon hurtig (men det er kanskje en litt mer personlig grunn!).

Kort sagt: Jeg liker ikke mengden parenteser i infobokser, spesielt når informasjonen ikke er nyttig ved rask lesing. Om parenteser skal anvendes, bør det kategoriseres (spesielt språkkodene, om det så er én felleskategori) og kombineres. Synlige, ubearbeidede kvalifikatornavn er også et valg jeg ikke syntes er stas. Hva tenker vi? EdoAug (diskusjon) 8. sep. 2023 kl. 14:08 (CEST)

Jeg fjernet prefix/tittel på to av egenskapene. Har ikke fått gjort noe med parentesene hvilket jeg har tenkt gjøre, men har hatt annet som har tatt tid, bl.a. oppdateringer for kartene (i test nå). "av" er en egenskap som helst ikke skal brukes. Litt usikker på hva jeg skal gjøre med det. Språkkodene hadde jeg håpet kunne fått blyant bak seg med lenke. Jeg får komme tilbake med ytterligere svar når jeg får litt bedre tid. Haros (diskusjon) 8. sep. 2023 kl. 21:30 (CEST)

Jeg fjernet språkparentesen for manglende etikeetter ettersom jeg ikke får lenket til redigering for det, i det minste nå. Haros (diskusjon) 16. sep. 2023 kl. 10:54 (CEST)

Alternative parameternavn

Er det mulig å legge inn alternative parameternavn, for eksempel "url" og "nettsted"? 4ing (diskusjon) 19. des. 2023 kl. 13:04 (CET)

@Haros: Har du sett denne? - 4ing (diskusjon) 21. des. 2023 kl. 09:24 (CET)

@4ing: Hadde ikke sett det. Det skal være mulig å legge inn param=url,nettsted, men da bør nok det være gitt en verdi til tekst også. I {{infoboks museum}} er det brukt param=direktør,museumsdirektør og tekst=Museumsdirektør. Et forsøk på å legge inn begge deler viste at direktør=nn blir vist hvis begge er brukt. Alternativene er adskilt med komma, og det er nok ikke noen (praktisk) grense for hvor mange som kan gis. Men det er flere alternativer i dokumentasjonen til {{infoboks biografi}} som ikke er lagt til i malens implementasjon. Haros (diskusjon) 21. des. 2023 kl. 13:16 (CET)

@Haros: Jeg la inn alternativt parameternavn for nettsted i {{Infoboks skole}}. Det er imidlertid bare det første parameternavnet som leses, det etter komma ignoreres. - 4ing (diskusjon) 21. des. 2023 kl. 14:07 (CET)

Nå fungerer det visst! - mvh 4ing (diskusjon) 21. des. 2023 kl. 14:45 (CET)

Det ser ut til at denne endringen endret parameternavnet fra url til nettsted. Det er imidlertid rundt 1000 skoleartikler som bruker url i infoboksen med lokal verdi. Er det hensiktsmessig å standardisere parameternavn på tvers av infoboksmaler, i dette tilfellet til nettsted url som også benyttes i {{Infoboks geografi}}? - 4ing (diskusjon) 21. des. 2023 kl. 14:58 (CET)

@4ing: Jeg prøvde å se om jeg kunne reprodusere det, men nei. Så det kan nok være at det hadde med tid for oppdatering å gjøre.

Jeg synes nok det er en fordel om det er mulig å være snill med de som skriver artikler, slik at vi bør antagelig godta begge. Men det aller beste er jo om det legges inn på Wikidata. Så om vi skal endre på de 1000 artiklene, bør det nok være - flyttet til Wikidata - vi gjør. Haros (diskusjon) 21. des. 2023 kl. 18:43 (CET)

Tynn referanse

Er usikker på om hvor dette hører hjemme, men: Det er en del wikidata-referanser for nasjonalitet som inneholder basert på følgende heuristikk (P887) og utledet av fødested (Q91770864). Ville det være en ide å la være å vise disse som referanser? Se f.eks Gro Bjørnerud Mo. Avilena (diskusjon) 27. feb. 2024 kl. 18:11 (CET)

Skal se på det. Haros (diskusjon) 27. feb. 2024 kl. 20:49 (CET)

@Avilena:. Da skal det være borte. Haros (diskusjon) 27. feb. 2024 kl. 20:57 (CET)