Wikipedia:Gemenskapens tekniska önskelista/2017

Välkommen till Gemenskapens tekniska önskelista 2017!

Tack för att du deltar!

Kalender

• Ta fram första exempel med tekniskt kunniga volontärer: tisdag 4 juli Klar
• Lägg, diskutera och bearbeta förslag: Onsdag 13 juli-måndag 31 juli Klar
• Wikimedia Sveriges team går igenom och organiserar förslag: Tisdag 1 augusti-fredag 4 augusti Klar
• Rösta på förslagen: Måndag 7 augusti-söndag 20 augusti Klar
• Analysera önskelista: Måndag 21 augusti-tisdag 22 augusti Klar
• Resultat presenteras: Onsdag 23 augusti Klar
• Genomgång och utvärdering av de mest populära önskningarna av Wikimedia Sveriges team: Torsdag 24 augusti-fredag 8 september Klar
• Presentation av den preliminära utvärderingen: Måndag 11 september Klar
• Arbete med önskningarna: TBD

Vad är Gemenskapens tekniska önskelista?

Wikimedia Sverige vill hjälpa de mest aktiva volontärerna med att lösa tekniska problem som förhindrat ett effektivt arbete. Den utveckling vi fokuserar på i det här projektet beslutas av Wikimedia-gemenskapen, genom denna önskelista. 2017 är första gången vi genomför detta projekt. Denna pilot är av ett mindre slag och vi kommer endast att kunna lösa mindre tekniska problem i år. Detta på grund av vår personalstyrkas begränsade storlek, samt att utvecklingstiden är kortare då fokus i år har legat på att få grunden på plats. Under 2018 planerar vi dock att utöka projektets storlek om piloten slår väl igenom.

En gång per år ber vi Wikimedia-volontärer att bidra med förslag på tekniska problem som behöver fixas eller nya lösningar som behöver utvecklas och som vårt team bör arbeta med. Efter att vi samlat in förslag under två veckor så är du inbjuden till att rösta på den idé som du är mest intresserad av att se genomförd. Det förslag med flest stödröster blir då vår topprioritet och vi kommer att undersöka dess genomförbarhet.

Idén med Gemenskapens tekniska önskelista togs först fram av Wikimedia Deutschland och vidareutvecklades av Wikimedia Foundation. Vi följer i deras spår med en önskelista för den svenskspråkiga Wikipedia-gemenskapen. Wikipedias systerprojekt hoppas vi kunna utöka med nästa år.

Vad händer under förslagsfasen?

Förslagsfasen pågår de första två veckorna av undersökningen - från måndag 10 juli-måndag 31 juli.

I förslagsfasen uppmanas bidragsgivare att lämna förslag om funktioner och korrigeringar som du vill se under 2017. Förslag kan lämnas på svenska eller engelska.

Förslagen bör vara avskilda, väldefinierade uppgifter som direkt kommer att gynna aktiva Wikimedia-bidragsgivare. När förslagsfasen öppnas kommer vi att ha ett formulär att fylla i, med följande frågor:

• Vad är problemet du vill lösa?
• Hur hanteras problemet nu?
• Vilka användare påverkas? (Bidragsgivare, administratörer, Commons-användare, Wikipedia-användare, etc.)
• Vilka är de föreslagna lösningarna? (Om det finns någon idé)

Ditt förslag bör vara så specifik som möjligt, särskilt i problemformuleringen. Skriv inte bara att "(x-funktionen) är föråldrad", "måste förbättras" eller "har en hel del buggar"; det är inte tillräckligt med information för att räkna ut vad som behöver göras. Ett bra förslag förklarar exakt vad problemet är, och vem som påverkas av det. Det är okej om du inte har en specifik lösning att föreslå, eller om du har några möjliga lösningar och du inte vet vilken som är bäst. Tillsammans med några aktiva volontärer som har tekniskt kunnande har vi tagit fram några första exempel.

Att lägga fram ett förslag är bara början av processen. Den två veckor långa förslagsfasen är en möjlighet för gemenskapen att samarbeta med att utarbeta ett förslag som presenterar idén på ett sätt som mest sannolikt kan bli framgångsrikt i omröstningsfasen. När ett förslag lämnas in är alla inbjudna att kommentera på detta förslag, och bidra till att göra det bättre genom att ställa frågor, och föreslå förändringar. Förslag som är dubbletter kan slås samman; mycket breda förslag bör delas upp i mer specifika idéer. Målet är att skapa bästa möjliga förslag till omröstningsfasen.

Den person som lägger fram ett förslag bör räkna med att vara aktiv i den diskussionen, och bidra till att göra förändringar längs vägen. På grund av detta, kommer vi att begränsa förslag till tre stycken per person. Om du lägger mer än tre förslag, kommer vi att be dig att begränsa den till tre. Presentera dina bästa idéer!

En ytterligare anmärkning: Förslag som går ut på att ta bort eller inaktivera en funktion som ett produktteam på WMF har arbetat med är utanför våra möjligheter att påverka, och kommer inte att inkluderas i röstningsfasen.

Vad händer under omröstningsfasen?

Efter en veckas uppehåll pågår röstningsfasen under de efterföljande två veckorna, från måndag 7 augusti-söndag 20 augusti.

Alla aktiva bidragsgivare uppmanas att granska och rösta för de förslag som du vill stödja. Du kan rösta på så många olika förslag som du vill. Du måste vara inloggad för att lägga en stödjande röst.

De enda röster som räknas är stödröster; den slutliga listan av önskemål rangordnas efter de som fått flest stödröster. Det finns inget behov av att indentera andra typer av röster eller att kommentera för att hindra dem från att numreras - det är bra att se hur mycket uppmärksamhet ett förslag får total. Vi har vårt eget automatiserade system för att räkna stödröster.

Livlig diskussion uppmuntras dock under röstningsfasen, och om du vill lägga till en röst som motsätter sig eller som är neutral med en kommentar, så är du välkommen att göra så. Dessa diskussioner kan hjälpa människor att besluta huruvida de vill rösta på förslagen. Diskussionerna ger också värdefulla bidrag för att styra det arbete som kommer att ske under året.

En rimlig mängd av påverkan är acceptabelt. Du har en möjlighet att sälja din idé till så många människor som du kan nå. Känn dig fri att kontakta andra personer i ditt projekt, Wikiprojekt eller användargrupp. Självklart ska detta inte innefatta marionettkonton, eller trakassera folk om att rösta eller att ändra sin röst. Men en välmenande kampanj om att "få folk att rösta" är helt okej.

Vad händer om en massa människor röstat och stött en dålig idé?

Stödröstrankningen skapar en prioriterad backlog av önskningar och Wikimedia Sveriges team är ansvariga för att utvärdera och ta itu med de önskemål som är högst prioriterade. För att göra det undersöker vi alla de högst rankade önskningarna, och tittar på både tekniska och sociala/politiska riskfaktorer.

De röster som motsätter sig eller är neutrala är till stor hjälp i att peka på potentiella nackdelar. För kontroversiella önskemål balanserar vi röstning med en mer konsensusbaserad granskning.

Önskelista

Inga fler önskemål tas nu emot.

Underhåll

Klottersaneringsstöd

Problem

Att klottersanerandet tar för mycket tid och att klottret även riskerar projektets trovärdighet om vi inte lyckas återställa. (Hur hanteras det idag) Lite olika, några använder verktyg där man med stöd följer alla redigeringar som sker, andra genom att följa SÄ och gå in och titta på bidrag

Vilka påverkas

De mer och mindre aktiva som patrullerar för klotter, alla läsare om vi ej lyckas återställa klotter

Tidigare diskussioner

Wikipedia:Bybrunnen/Arkiv_2017-02#ORES, Wikipedia:Bybrunnen/Arkiv 2016-07#Hjälp med klottersanering mha ORES?

Lösningsförslag

Inför mw:ORES. Det verktyget används på väldigt många språkversioner och har i diskussioner rekommenderats som det kanske mest effektiva verktygen för att upptäcka, flagga och automatiskt återställa klotter. På andra språkversioner har gemenskapen själva fört in Ores men individuella ansatser här har inte gått i mål. Min uppfattning är det behövs en projektledare för införandearbetet som håller ihop och driver det och också till viss del hjälper till ladda startexemplen som behövs.

Föreslaget av

Yger (diskussion) 11 juli 2017 kl. 20.40 (CEST)

Diskussion

Jag skulle behöva mer detaljer om exakt vad som efterfrågas i den här önskan för att få en känsla av dess karaktär samt hur stor den är.

Det första steget för att aktivera ORES är att träna modellen att känna igen vilka ändringar som är vilka. Enligt toollabs:/dexbot/tools/wikilabels_stats.php och mw:ORES#Support_table är detta gjort för reverted (chansen att en ändring kommer att bli återställd) och påbörjat, 85% gjort, för damaging och goodfaith (om en redigering är skadande och/eller gjord i god tro). Träning har inte begärts för wp10 (kvalitetsrankning av artiklar) eller draftquality (troligheten att en ny artikel är vandalism eller spam).

När väl träningen är färdig så behöver ORES värdena för redigeringar/nya sidor konsumeras av ett verktyg som antingen flaggar trolig vandalism eller automatiskt återställer denna.

Är det träningen (genomförande/koordinering) som det önskas hjälp med? Är det i så fall för den påbörjade damaging/goodfaith eller för någon av de opåbörjade modellerna? Eller är det verktyg som använder ORES-värdena (när modellen är tränad) som eftersöks? Finns det i så fall en förlaga/förlagor på andra wikis som vi vill använda här? Om det inte handlar om att porta ett existerande verktyg finns det i så fall en beskrivning av hur det nya verktyget ska fungera och vilka funktioner den ska erbjuda? /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 10.30 (CEST)

I första hand är det projektlederi, dvs att förstå funktionen och lägga upp ett projekt på Wikipedia, och att på Bybrunnen berätta om funktionen och vad som behövs för att få den operativ. Sedan att lägga upp en plan för att träna Ores, och göra några få sådan själv för att sedan uppmuntra andra att göra detsamma. Ores är infört på 32 språkversioner så det finns många förlagor att ta efter. Även att ta reda på hur införandet fungerat på andra språkversioner ligger i det jag ser som arbetet.Yger (diskussion) 21 juli 2017 kl. 11.09 (CEST)

Jag pingar @Julle: som kanske kan ge mer detaljer.Yger (diskussion) 21 juli 2017 kl. 12.14 (CEST)

Jag är datorlös några dagar; återkommer efter helgen. /Julle (disk.) 21 juli 2017 kl. 12.36 (CEST)

@Yger: Tack för klargörandet. Inväntar fler detaljer från Julle. /André Costa (WMSE) (diskussion) 1 augusti 2017 kl. 11.14 (CEST)

@Julle:, du har inte glömt detta?Yger (diskussion) 1 augusti 2017 kl. 17.15 (CEST)

Jag hade mycket riktigt glömt det. Mina ursäkter.

Det vi primärt behöver göra just nu är att slutföra träningen för att ta nästa steg, när ORES-utvecklarna kan gå vidare för att hjälpa oss vidare med stödet att enkelt identifiera sannolik vandalism och misslyckade redigeringar där vi kan försöka leda folk som vill väl åt rätt håll. Kanske också sparka igång draftquality. Jag skulle se wp10 som mindre viktigt för den arbetsbörda vi vill minska. Har vi någon särskild fråga angående implementeringen på andra wikier? Om jag inte själv kan besvara frågan så vet jag vanligtvis vem jag skall vända mig till, i alla fall. /Julle (disk.) 1 augusti 2017 kl. 22.41 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.31 (CEST) Vi behöver allt tekniskt stöd som kan underlätta klottersanering/underhåll. WMF nya strategi trycker också på att automatisera underhåll är en centralt för verksamheten framöver "We will develop services that support positive experiences and lower the burden of maintenance, so that people can focus on enjoyable and creative work.
2. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) Jag har själv gjort ett par omgångar med ORES, men det tar tid och med tanke på att det inte känns som helt säkert att det kommer att bli något vet jag inte om jag vill lägga mer tid på det. En mer ordentlig projektledning tror jag skulle kunna få igång arbetet, vilket skulle kunna ge de mest aktiva klottersanerarna mer tid över till annat.
3. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.41 (CEST)
4. Julle (disk.) 18 augusti 2017 kl. 13.26 (CEST)
5. Jardenberg (disk.) 18 augusti 2017 kl. 14.01 (CEST)
6. Deryni (diskussion) 20 augusti 2017 kl. 19.46 (CEST)

---

Wikidata / faktarutor

Kostnadseffektivare Wikidata-stöd i infoboxar

Problem

Det finns idag otillräckligt stöd för Wikidata i infoboxar. Varje parameter hämtar hela Wikidata-objektet, vilket inte är resurseffektivt. Detta innebär även att vissa infoboxar inte fungerar för att mängden hämtad data blir för stor.

Vilka påverkas

Wikipedianer som skapar infoboxar, läsare (snabbare laddning av sidor).

Tidigare diskussioner

Wikipedia:Bybrunnen#Önskar_fler_mallar_med_stöd_för_data_i_Wikidata

Lösningsförslag

En ny modul (i Lua) som hämtar objektet en gång och gör det möjligt att återanvända faktabitarna på olika ställen i faktamallen. Möjligen även en metamall som kan nyttjas vid byggandet av andra infobox-mallar. Många funktioner som en sådan mall bör kunna finns det exempel på i befintliga WD-stödda mallar.

Föreslaget av

Innocent bystander (diskussion) 12 juli 2017 kl. 15.10 (CEST)

Diskussion

Vet vi om något liknande har åstadkommits på någon annan wiki? Finns det någon (delvis fungerande) förlaga man kan använda sig av? /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 10.32 (CEST)

Mycket god fråga! Återuppfinna hjulet är onödigt! Tyvärr så är de mest innovativa projekten i det här fältet begränsade till språk jag inte behärskar. LUA-baserade infoboxar hag jag sett, men inga som väl integrerat en LUA-baserad infobox med LUA-baserat Wikidata-stöd. Det är där jag tror behovet är störts, för Modul:Wikidata2 går att använda ett tag till, även om den råkar främst vara utvecklad av en amatör. Modul:Wikidata2 är tänkt att gå att använda i en sådan infobox, då den ska klara att man skickar den en tabell med objektet, istället för ge den ett qid. Det är en sådan funktion som idag läser qualifiers i denna modul, men jag har inte testat i ngn större utsträckning att läsa hela objekt på det viset. -- Innocent bystander (diskussion) 21 juli 2017 kl. 10.55 (CEST)

Ska kolla på Wikidata-epostlistan och se om nån har ett tips på om/hur detta gjorts tidigare.

För kunskap till andra som följer diskussionen har det även experimenterats en del med att bädda in metamallen i en modul. Detta ser ut at vara en lovande lösning för åtminstone en del av det som önskas här. /André Costa (WMSE) (diskussion) 1 augusti 2017 kl. 12.01 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.36 (CEST) Att ha resursmässigt effektivare infoboxanrop mot Wikidata är mycket önskvärt och bra, Så stöd för förslaget i sig. men jag tycker det verkar kunna gå i mål utan att skapa ett dedikerat utvecklingsprojekt. Också ser jag inget problem om denna funktion kom fram om några månader, dvs jag ser den inte som tidskritisk, funktionalitet i gränslandet Wikipedia-Wikidata kan gärna mogna till sig lite till, då det är en relativt nytt område

   Ja, det här nya sättet att bygga mallar vi hittat verkar lovande. -- Innocent bystander (diskussion) 7 augusti 2017 kl. 21.24 (CEST)

2. Tore Danielsson Jag tror det här är ett område som har mycket utveckling framför sig. Bra om det är igång! Tore Danielsson (diskussion) 8 augusti 2017 kl. 15.52 (CEST)
3. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.42 (CEST)
4. Julle (disk.) 18 augusti 2017 kl. 13.29 (CEST) Om inte annat är det bra om någon sätter sig ned och tittar på det, i alla fall.
5. Jardenberg (disk.) 18 augusti 2017 kl. 14.03 (CEST)
6. Deryni (diskussion) 20 augusti 2017 kl. 19.47 (CEST)

---

Skapa en Mall:Konstverk WD som hämtar data från Wikidata

Problem

I och med den ökande digitaliseringen av museernas samlingar så kommer fler konstverk att behöva beskrivas i nya artiklar. Det finns också mycket metadata som behöver struktureras. Konstverken, de som är relevanta och har ett internationellt intresse skulle vara förtjänta av en mall som hämtar data från Wikidata

Vilka påverkas

De som skriver och är intresserade av konstverk. Många äldre konstverk (public domain) illustrerar också historiska händelser.

Tidigare diskussioner

Det finns flera diskussioner om mallar och Wikidata i allmänhet på till exempel Bybrunnen

Lösningsförslag

Se om denna mall Mall:Konstverk WD eller befintlig mall Mall:Konstverk går att bygga eller uppdatera. Kanske som del av ett större "mall-arbete"

Föreslaget av

Tore Danielsson (diskussion) 19 juli 2017 kl. 14.33 (CEST)

Diskussion (Skapa en Mall:Konstverk WD som hämtar data från Wikidata)

Det känns som att det finns god överlappning mellan denna önskan och Kostnadseffektivare Wikidata-stöd i infoboxar. Annars skulle detta främst innebära att ta fram en konstverksmotsvarighet till t.ex. Mall:Faktamall biografi WD. /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 14.00 (CEST)

Jag har börjat kika på detta, se Användare:Innocent bystander/sandlåda. -- Innocent bystander (diskussion) 23 juli 2017 kl. 21.07 (CEST)

Vad jag kan förstå så kan Wikidata hantera väldigt mycket mer metadata per målning än vad som kanske behövs i en mall för Wikipedia? Item structure to describe paintings on Wikidata och d:Wikidata:WikiProject_Visual_arts/Item_structure#Describing_individual_objects Men om jag förstår mallar rätt så går det att lägga in fler egenskaper manuellt också om man har den informationen. Det jag dock tror är viktiga parametrar att ha med är "motiv" och "koordinater varifrån vyn ses" då dessa vanligtvis brukar ligga i en beskrivande text (i de databaser jag har sett). Detta skulle vara intressant att arbeta vidare med! "Geografiska koordinater" borde ju komma med som en underdel av "placering" Tore Danielsson (diskussion) 25 juli 2017 kl. 17.15 (CEST)

@Tore Danielsson, André Costa (WMSE): Det går att lägga in väldigt mycket data på Wikidata. Det svåra kan vara att tolka ut den på ett sådant sätt att våra mallar kan tolka varje givet sätt att lägga in detta. I Mona Lisa så anges (på WD) motivet vara "Personen avbildad på Mona Lisa". Sedan när man tittar närmare på objektet som handlar om "Personen avbildad på Mona Lisa" så framgår det där att det finns flera olika källor som anger vem detta är. Det här är enkelt att tyda när man själv snokar runt bland dessa objekt. Det är svårare att skapa en AI som är smart nog att presentera det på ett vettigt sätt.

Det framgår också i just Mona Lisa att den är placerad i "Italienska målningar, sal 6". Sedan ligger denna sal i Louvren som ligger i det 15:e arrondismentet, som i sin tur ligger i Paris. En människa skriver det sannolikt mycket kompaktare som "Louvren, Paris". Där har du också en rejäl utmaning. -- Innocent bystander (diskussion) 25 juli 2017 kl. 21.51 (CEST)

Bra synpunkter! Det finns några problem att arbeta med! Jag brukar kalla mig "normalbegåvad" men när jag kollar runt på Wikidata, Wikimedia Commons och Wikipedia ("Wikivärlden") och den utveckling + de verktyg som finns blir jag minst sagt ödmjuk inför min egen förståelse av helheten. Det ser ändå onekligen ljust ut framöver. Jag tror det finns fler museer (+ andra intressenter med egna samlingar) som vill och kan tänka sig något liknande som LSH och Nationalmuseum har påbörjat och gjort. Kanske ska inte alla Sveriges museers föremål och konstverk in i Wikidata, kanske ska inte alla bilder laddas upp till Commons, kanske ska heller inte alla konstverk ha en egen artikel på svenska Wikipedia. Relevanskriterier och konsensus är väl inte helt klart här men området har en potential att växa i alla fall? Kan man kolla hur andra språkversioner gör? Fungerar en mall WD för alla språkversioner?

Jag kan för lite ur en teknisk synvinkel på hur detta kan göras. Men förstår att om museerna laddar upp delar av sin metadata från samlingarna så är en Infobox WD ett bra stöd för den informationen när artiklar ska skrivas. Så det låter klokt att stoppa in den här önskan i "Kostnadseffektivare Wikidata-stöd i infoboxar" Tore Danielsson (diskussion) 8 augusti 2017 kl. 15.41 (CEST)

Nej, idag funkar inte alla "WD" mallar likadant överallt på alla projekt. De flesta är utvecklade lokalt, även om det självklart finns exempel på mallar som fungerar exakt likadant på ett projekt som ett annat, just därför att rena kopieringar har gjorts. Det finns planer på att skapa ett projekt likt Wikidata och Commons för att centralisera Mall-arbetet. Det ligger dock fortfarande en bit bort. Men det är inte säkert att vi kommer att gilla alla de lösningar som görs i sådana mallar. Det finns redan idag en massa synpunkter på hur Wikidata samlar data. Det går att anpassa lokalt för sådana synpunkter, men det kan bli svårt i en global mall. -- Innocent bystander (diskussion) 8 augusti 2017 kl. 16.32 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.37 (CEST) En bra infobox anpassad för konstverk ser jag som önskvärt och bra, Så stöd för förslaget i sig. Men jag tycker det dels kan mogna till lite mer, det är inte tidskritiskt och jag tycker också det vore möjligt ta fram detta utan att skapa ett dedikerat utvecklingsprojekt.
2. Innocent bystander (diskussion) 7 augusti 2017 kl. 21.25 (CEST) Det här ryms väl inom vad som omtalas längre upp. -- Innocent bystander (diskussion) 7 augusti 2017 kl. 21.25 (CEST)
3. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.42 (CEST)

# Julle (disk.) 18 augusti 2017 kl. 13.26 (CEST)

---

Källor /referenser

Citoid-bibliotek för svwp

Problem

Citoid finns på svenskspråkiga Wikipedia, men det saknas stöd för de flesta vanliga svenska källorna.

Vilka påverkas

Wikipedianer (lättare att lägga till referenser), läsare (bättre kvalitet på referenserna).

Tidigare diskussioner

Det har bland annat diskuterats på wikifikor i Stockholm.

Lösningsförslag

Skapa ett bibliotek för de vanligaste svenska källorna på Zotero och importera dessa till Citoid per mw:Citoid/Creating_Zotero_translators och Fil:Translators-citoid.pdf.

Föreslaget av

♥Ainali ^diskussion_bidrag 12 juli 2017 kl. 21.01 (CEST)

Diskussion

Webbplatser som kan vara lämpliga att starta med är sverigesradio.se, svt.se, dn.se och svd.se. Eventuellt kanske vi borde skapa en egen prioriteringslista för detta. ♥Ainali ^diskussion_bidrag 13 juli 2017 kl. 08.35 (CEST)

En prioriteringslista (samt en lista över svenska resurser som idag stöds) skulle definitivt vara första steget om denna önskan blir vald. Rätta mig om jag har fel men i praktiken skulle detta innebära att man kan släppa en url i referensfältet så konverterar mw:Citoid själv denna till en ifylld {{webbref}}. Detta funkar i VisualEditor och det nya Wikitext-läget men inte i det gamla redigeringsläget? /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 10.50 (CEST)

Ser nu att alla fyra exemplet ovan faktiskt redan ger formaterade källor om man använder dem i "Ange källa"-funktionen i VisualEditor. Kan du förtydliga vilken skillnaden blir om man skapar en Zotero modul för var av källorna? /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 11.09 (CEST)

"Ange källa"-funktionen ger ofta ganska dåliga ifyllnader: Den hittar ofta inte författaren till exempel, på Sveriges Radio anges "Efternamn: Radio, förnamn: Sveriges", på SvD tror jag anges e-mailadressen istället för författaren, och ofta missas info som publiceringsdatum. Jag tänker mig en sida som känner att det är en DN-url och därför vet hur den ska plocka meta-data till våra mallar från DN-artiklar och skriver på rätt sätt. Kanske till och med skapar interwikilänk till tidningen. Kanske är det nåt sånt Ainali tänker också.--LittleGun (diskussion) 21 juli 2017 kl. 11.31 (CEST)

Ja, ungefär. Fast man gör det inte på en sida på svwp utan i den bakomliggande programvaran. Så detta kommer alla språkversioner till godo (likväl som alla andra Zotero-användare). Men någon interwikilänk skapas inte, vilket annat projekt skulle den gå till i så fall? ♥Ainali ^diskussion_bidrag 21 juli 2017 kl. 11.49 (CEST)

Jag menade wiki-länk, dubbelklamrar...--LittleGun (diskussion) 21 juli 2017 kl. 18.57 (CEST)

Tack för klargörandet. Så sammanfattningsvis: Ja flera svenska källor funkar idag men de gör det dåligt och utan att dra nytta av de möjligheter som Citoid egentligen erbjuder (dvs. ordentlig mappning via Zotero).

Angående wikilänkade tidnignsnamn/författarnamn så antar jag att det ligger utanför vad Zotero kan klara eftersom den inte kan göra en mappning mot vad som finns på Wikipedia (att kunna bädda in Wikidata-id för "publisher" skulle ju vara en potentiell förbättring från deras håll). /André Costa (WMSE) (diskussion) 1 augusti 2017 kl. 13.04 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Efter samtal med Lokal profil: Det vore bra om det gick att göra ett visuellt interface för att lägga till och rätta bibliotek i Zotero.//Hannibal (diskussion) 11 augusti 2017 kl. 01.02 (CEST)

Omröstning

1. ? Yger (diskussion) 7 augusti 2017 kl. 11.42 (CEST) Förstår inte förslaget och uppfattar det kan bli en del av förslaget som ligger här nedanför
2. LittleGun. Jag förstår det som att vid automatgenerering av en källa från t ex SvT i VE så hittas fler parametrar så att de kan fyllas i korrekt. Det vore toppen!--LittleGun (diskussion) 7 augusti 2017 kl. 20.09 (CEST)
3. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) Om det går att få till de tio-femton vanligaste källorna vore det toppen.
4. Julle (disk.) 18 augusti 2017 kl. 13.30 (CEST)
5. Jardenberg (disk.) 18 augusti 2017 kl. 14.05 (CEST)

---

Automatkonvertera källhänvisningar som enbart består av URL:er

Problem

Undvika källhänvisningar som enbart består av URL:er. Det går idag att göra ganska enkelt med VisualEditor, genom att ställa sig på fotnoten, klicka "konvertera", vänta en kort stund och sedan klicka utanför rutan. Utan VisualEditor får man klippa ut URL:en, öppna ny flik/nytt fönster, klistra in den där och ta reda på informationen, samt föra in den i artikeln.

Vilka påverkas

Wikipedianer som vill göra källhänvisningarna tydligare.

Tidigare diskussioner

Inga vad jag känner till.

Lösningsförslag

Det vore bra om man kunde få en finess som automatiskt kände efter i artiklar man besöker om det finns källhänvisningar som enbart består av URL:er, frågade om man ville automatkonvertera dem till korrekta källhänvisningar och gjorde det. Om den stötte på problem, till exempel om länken går till en PDF, som VisualEditor inte verkar klara av än så länge, eller en död länk, skulle det vara bra om man fick ett felmeddelande med en länk till sidan, så att man enkelt skulle kunna undersöka problemet.

Föreslaget av

Hannibal (diskussion) 13 juli 2017 kl. 00.32 (CEST)

Diskussion

@Hannibal: Då rena url'er tillhör de vanligare källhänvisningarna på WD också, kanske det här vore något att ta upp för WD's räkning också? (Men kanske inte inom ramen för det här wmse-projektet, utan istället hos wmde.) -- Innocent bystander (diskussion) 13 juli 2017 kl. 07.29 (CEST)

Mycket bra förslag! Det kanske till och med skulle kunna vara så att finessen startar automatiskt i bakgrunden och efter en stund kommer en dialogruta upp med något i stil med "Två URL:er kunde automatiskt konverteras till källhänvisningar. Vill du infoga dessa?" Vid svar ja får man först en chans att granska och korrigera dem, men om de ser bra ut ska det bara vara en knapptryckning för att infoga dem. ♥Ainali ^diskussion_bidrag 13 juli 2017 kl. 08.27 (CEST)

För att denna ska fungera bäst antar jag att den med fördel kombineras med Citoid-önskan ovan?

Annars om jag förstår saken rätt så vill man kolla efter <ref>-taggar som enbart innehåller en url, köra dem genom citoid och (efter bekräftan) ersätta dem med en ifylld tidningsref/webbref? (Not för framtiden: citoid-api, mappning till mallfält.) /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 11.18 (CEST)

För Wikidata (framtiden) blir det något svårare då projektet saknar citoid stöd, vilket troligen beror på att var källsite (åtminstone tidningar) även borde mappas mot motsvarande objekt. Det sagt så skulle det definitivt behövas även där. /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 11.18 (CEST)

Min tanke var något liknande det senare, med ref-taggar, men om det går att föra ihop förslagen har jag inget emot det. Huuvudsaken är att underlätta för att lägga till källhänvisningar.//Hannibal (diskussion) 21 juli 2017 kl. 11.23 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.45 (CEST) men ser helst det slås samman med förslaget nedan
2. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) Om det går enkelt att göra, vore det mycket praktiskt.
3. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.43 (CEST)
4. Jardenberg (disk.) 18 augusti 2017 kl. 14.06 (CEST)
5. Deryni (diskussion) 20 augusti 2017 kl. 19.48 (CEST)

---

Konvertera mellan källmallar

Problem

När källmallar skapas automatiskt blir det ibland fel sort, tidningsref för NE (borde vara bokref), webbref istället för tidningsref, bokref istället för tidskriftsref etc.

Vilka påverkas

De som använder källmallfunktionen och de som vill korrigera till rätt typ/sort.

Tidigare diskussioner

Här har det noterats vara ett problem:[1]

Lösningsförslag

Informationen i mallarna är densamma, och har ofta samma etikettnamn om de är gemensamma. Det vore toppen med ett par knappar och/eller dialog som konverterar från en mall till en annan.

Föreslaget av

LittleGun (diskussion).

Diskussion

Menar du en bot-körning för att ta hand om sådana som redan lagts in? För att förhindra det i framtiden kan vi antingen justera MediaWiki:Citoid-template-type-map.json så att den ger rätt mall alternativt prioritera ne.se högt i mitt förslag "Citoid-bibliotek för svwp". ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 19.37 (CEST)

Inte egentligen. Men, visst, botkörning också, och ett en dialog så att man kan ta hand om dom direkt. Eller om man nöjer sig med att låta en bot ta hand om det alltid.--LittleGun (diskussion) 25 juli 2017 kl. 21.25 (CEST)

Om förslaget egentligen handlar om att ne.se ska få rätt källmall via VisualEditors automatiska generering så är det exakt samma förslag som jag ställde, så då håller jag verkligen med dig om att det borde genomföras. :) ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 21.36 (CEST)

Njae, det handlar om att få rätt typ av källmall. Så att en källa från en tidning som automatiskt blir, eller felaktigt väljs som, webbref enkelt kan ändras till tidningsref etc. Ditt förslag är väl mer att "hjälpa" tidningar etc så att rätt källmall fylls i med så många parametrar som redovisas av tidningarna.--LittleGun (diskussion) 25 juli 2017 kl. 21.49 (CEST)

Mitt förslag handlar om båda delarna. I mappningen som görs i ett Citoid-bibliotek behöver webbplatsen ges en typ, och det är en typen som via sidan MediaWiki:Citoid-template-type-map.json bestämmer vilken mall som ska användas för den angivna URL:en. Just nu gissar Citoid att ne.se är en "magazineArticle" eller "newspaperArticle" (de enda som leder till tidningsref) när det borde vara en "encyclopediaArticle" eller möjligtvis en "webpage". I mitt förslag ska detta givetvis mappas rätt för de utvalda webbplatserna. ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 22.12 (CEST)

Japp, och jag tycker det vore toppen. Det här förslaget handlar om en tredej grej: Att konvertera när det redan blivit fel typ (bokref fast det borde varit tidskriftsref t ex). Utan att det ens kanske finns en url. Egentligen borde det räcka med att ha en källmall oberoende av typ, tycker jag. Vill man prompt ha en typ så skulle det kunna vara en egen parameter.--LittleGun (diskussion) 25 juli 2017 kl. 23.29 (CEST)

Aha, nu fattar jag ditt förslag. Jag trodde felaktigt att det bara handlade om NE. Ditt förslag är bra, för alla webbplatser som inte redan har blivit korrekt mappade (vilket i och för sig kommer att vara de flesta). Typen är inte så mycket en parameter i mallen utan bara ett sätt för Citoid att välja rätt källmall. Citoid kan också göras så att den alltid ger en och samma källmall om vi vill, det är bara att vi bestämmer vilken som ska gälla och så redigerar vi högerkolumnen i MediaWiki:Citoid-template-type-map.json till det värdet för alla rader. Om det inte finns en URL kan citoid inte få fram bokref eller tidskriftsref (Jo, om man släpper en ISBN eller DOI, men då är det ju en bok eller tidskrift och borde väl aldrig ändras?). Så om jag förstår ditt förslag rätt så vill du att det ska gå att ändra källmallen som valts av Citoid i de fall den har försökt gissa (och det saknades en specialbyggd mappning för webbplatsen). Det är ett förslag jag i så fall stödjer. ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 23.44 (CEST)

Jorå, snart har jag lyckats förklara. Men, jag menar i alla de fall som ref-typen blivit fel, eller i framtiden råkar bli fel. Även kolbaserade redigerare väljer fel källmall ibland. Särskilt webref istället för tidningsref. Dessutom föreslår jag, som en parentes, att vi bara har en refmall och att vi låter reftypen styras av en parameter istället.--LittleGun (diskussion) 26 juli 2017 kl. 08.56 (CEST)

Njo, men om ref-typen har blivit fel, på grund av felprogrammerad Citoid-mappning, så är en bättre lösning att rätta mappningen än att varje användare som vill göra en referens till den webbplatsen ska behöva ändra det när de klistrar in URL:en. Ditt sista förslag är, om jag förstår den rätt, inte en teknisk fråga utan en fråga för Bybrunnen. Du menar alltså att vi bara ska ha en enda referensmall och att vi ska avveckla användningen av övriga i Kategori:Källmallar? ♥Ainali ^diskussion_bidrag 26 juli 2017 kl. 09.08 (CEST)

Absolut. En en felprogrammerad Citoid-mappning ska rättas i själva mappningen. 1) All infogning av refmallar görs inte och kommer inte göras via Citoid och kan bli fel. 2) Citoidmappningen kommer ständigt vara i behov av uppdatering och komplettering och kommer att göra fel. Av de båda skälen finns behovet att enkelt kunna byta typ på ref-mallar. Det är mitt önskemål: Att enkelt gå från tex bokref till tidningsref. Eftersom de flest använda parametrarna i tex bokref även finns i tidningsref och specialparametrarna inte är använda eftersom tidningsref var fel typ.
(Som parentes: Jag menar inte avskaffa alla reftyper. Jag vill ersätta alla refmallar med en mall. Denna ska istället ha en parameter som styr vilken typ det är. Istället för att varje ref-typ är en egen mall. Jag vill alltså inte avskaffa alla malltyper, det ska fortfarande finnas olika malltyper, men istället för att det bestäms hårdkodat i titeln på mallen bestäms det av en parameter i mallen. Det skulle jag kunna göra till ett eget önskemål.)--LittleGun (diskussion)

Aha, nu fattar jag än mer vad du är ute efter. Och det vore en smidig och bra funktion! Däremot tror jag att vi har haft lite språkförbistring vad gäller ordet typ. Jag använde det enbart i den teknisk betydelse som mappningen använder, medan du verkar använda det i någon annan funktion, kanske med avseende på layouten av den utskrivna referensen? Som parentes börjar jag känna att vi verkligen bara borde ha en mall och ett utseende för alla källor. Skälen till att ha flera olika är färre idag än när källmallsystemet infördes. ♥Ainali ^diskussion_bidrag 26 juli 2017 kl. 10.05 (CEST)

Typiskt! Med ref-typ menar jag att tidningsref är en typ, bokref en annan och en tredje typ är webbref. Jag förstår själv inte poängen med olika "typer"/sorter, men i den här diskussionen noterades det som viktigt:[[2]].--LittleGun (diskussion) 26 juli 2017 kl. 10.23 (CEST)

Då försöker jag sammanfatta:

1) Ref-mallar blir lätt fel och det är idag komplicerat att byta från en mall till en annan. En mekanism som gör det lätt att konvertera mellan dessa eftersöks.

2) Citoid väljer ofta fel typ av ref-mall. Hanteras av #Citoid-bibliotek för svwp ovan.

3) Behovet av olika refmallar (snarare än en mall där t.ex. en typ-parameter styr utseendet) är otydligt. Går vi denna vägen så löser sig (1) av sig själv, men funktionaliteten skulle ändå behövas under övergångstiden. Det är oklart om Citoid kan hantera att det bara finns en mall och att det istället är en given parameter som måste mappas. Det är även oklart om det finns andra, möjligen sociala, anledningar att använda skilda mallar. /André Costa (WMSE) (diskussion) 1 augusti 2017 kl. 14.26 (CEST)

Jag tycker att det var bra sammanfattat! ♥Ainali ^diskussion_bidrag 1 augusti 2017 kl. 16.03 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.45 (CEST) men ser helst det slås samman med förslaget ovan
2. Hannibal Jag förstår inte behovet av att lägga pengar på att skilja på olika källor, men om andra människor tycker att det är viktigt står jag inte i vägen.

---

Multimedia

Bildförslag

Problem

Det är tråkigt med alla artiklar som saknar bilder. I VisualEditor går det ganska enkelt att hitta bilder. Man klickar Infoga > Media, varpå ett sökverktyg letar på Commons efter bilder med samma namn. Det blir inte alltid rätt, men det är enklare än utan VisualEditor. Där får man leta i en separat flik på Commons så att man har exakt filnamn, klicka på bildikonen och lägga till rätt information.

Vilka påverkas

De läsare som besöker artiklar utan bilder, samt de användare som vill lägga till bilder.

Tidigare diskussioner

Inga direkt om tekniska lösningar, men däremot bildtävlingar och andra "manuella" initiativ.

Lösningsförslag

Jag skulle gärna vilja se en finess, som känner efter om det saknas bilder i artikeln och då söker på Commons efter bilder med liknande namn. Om det finns skulle en dialogruta kunna dyka upp och fråga om någon av de bilder som presenteras där skulle kunna fungera i artikeln. Trycker användaren "Ja" på någon eller några av bilderna, kommer nästa steg, som innebär att sätta bildtext och andra avancerade alternativ. Om ingen av bilderna passar skulle användaren få ett par alternativ: gå till en kategori på Commons som motsvarar en av kategorierna som artikeln ligger i, ladda upp bild, eller markera att det saknas en bild (något som skulle kunna leda till en dialogruta om att lägga till en "Illustration saknas"-mall). För att undvika att fler användare stöter på samma "felaktiga" bilder, skulle det också gå att markera att bilderna inte hör samman med ämnet.

Föreslaget av

Hannibal 14 juli 2017 kl. 11.43‎

Diskussion

Förslaget är i grunden inte dumt alls, men uppmuntra till massinlägg av "Illustration saknas" vet jag inte om jag gillar. Trenden är att den börjat bli den nya "stub"-mallen och det vet jag inte om jag vill se. -- Innocent bystander (diskussion) 14 juli 2017 kl. 12.12 (CEST)

Det är bara ett förslag, men jag förstår din poäng. Jag skulle dock uppskatta att kunna hitta alla artiklar som saknar illustration på något sätt. En dold kategori?//Hannibal (diskussion) 14 juli 2017 kl. 12.19 (CEST)

En möjlighet är att göra en WD-query som listar sidor inom vissa ämnen som saknar P18 (bildpropertyn). Det är ju indirekt synligt i Lista över svenska författare redan nu tex. När väl sedan P18 finns, är det nog tämligen lätt att få över bilden hit med ett script. -- Innocent bystander (diskussion) 14 juli 2017 kl. 16.52 (CEST)

En liten hjälp är ju Kategori:No local image but image on Wikidata som visar artiklar där det redan finns en bild i Wikidataobjektet. Med hjälp av verktyget WD-Fist kan man ju också ganska effektivt lägga till bilder på Wikidata (vilket ju kan fylla på kategorin). Skulle man kunna göra något ännu enklare i det arbetsflödet? ♥Ainali ^diskussion_bidrag 14 juli 2017 kl. 17.05 (CEST)

Hur svårt skulle det vara att göra ett sånt skript som för över bilder som har P18?

WD-Fist förstår jag inte alls. De första rubrikerna är "widar_note", "sparql" och "sparql_example". Därefter finns också "pagepile", "PetScan ID", "use_items", "popular" etc. Hur vore det att sätta ordentliga etiketter på dem, så att icke-programmerare kan använda den? Och att rensa den från onödiga element och sedan ha en "avancerad" version för den som vill?//Hannibal (diskussion) 21 juli 2017 kl. 10.48 (CEST)

Alla verktyg för att föra över bilder till WD har jag inte koll på. Det finns det dock de som har sådan koll. (Alla de fel sådana verktyg skapar är jag dock väl bekant med. Tex ska inte målningar av Rembrandt läggas in i P18, bara bilder föreställande Rembrandt själv.)

Till viss del borde vi redan nu kunna lägga in bilder och bildtexter från P18 i befintliga infoboxar. Det låter sig göras hyfsat enkelt då det redan finns mallar som har sådant stöd.

Det finns redan ett script skapat av Nirmos som för över den återkommande diskuterade infoboxen till alla biografier. Det borde därför vara görbart utan alltför mycket mantimmar att bara föra över P18 tillsammans med svenska bildtexten, utan att behöva slåss med den omtalade mallens övriga tillkortakommanden.

Vad som krävs för att inte bara föra in sådana bilder med JavaScript, utan också in i wikitexten vågar jag inte svara på. Mina kunskaper i ämnet stannar vid att jag inte ens riktigt vet hur man stavar till det. En mall som bara hämtar P18 (med bildtext) från WD borde vara möjligt att föra in även i artiklar som envist bevakas av de användare som tycker infoboxar är onödiga. -- Innocent bystander (diskussion) 21 juli 2017 kl. 13.48 (CEST)

@Hannibal: Det konstiga gränssnittet i wd-fist beror på att den råkar välja arabiska först, men översättningen verkar saknas. Testa att byta språk till engelska långt upp till höger. Här är en förinställd länk till en sökning på kategorin Kvinnor (tar en stund på grund av stor kategori). ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 19.48 (CEST)

Okej, men det där är inte mycket bättre. De konstiga ord jag tar upp finns fortfarande där, och de "förtydligas" genom instruktioner såsom "First SELECT variable has to be item ID" och "PSID".//Hannibal (diskussion) 25 juli 2017 kl. 19.55 (CEST)

Det är sant, det är bara snäppet enklare än Petscan, som också är byggt av Magnus Manske. Jag kan tyvärr inte bygga någon enklare variant, men jag föreslår att bara skriva en kategori i fältet Category, ändra språkversion till sv och trycka Run och se resultatet (kryssar man i rutan "Search Commons" får man många fler träffar). ♥Ainali ^diskussion_bidrag 25 juli 2017 kl. 20.51 (CEST)

Om jag bryter ner förslaget 1) Känna av om en sida saknar bilder och i så fall göra (och presentera) en sökning på Commons. 2) Infoga bilden på sidan 3) länk till Commons/bilduppladdning/illustrations-mall 4) Markera (och kom ihåg) bilder som inte är lämliga.

Punkt 1 borde vara relativt lätt att göra, om jag minns rätt så söker VisualEditor helt sonika på artikelnamnet. Punkt 2 känns lite som ett försök att få in VisualEditors bildhantering i wikitextläget. Jag skulle tror att det då nog är enklare att ge användaren filnamnet för den valda bilden och sedan själv stoppa in den där det passar (eller använda VE eller nya Wikitextläget). Punkt 3 är också rätt enkel men förlitar sig på att kategorierna systematiskt är kopplde mot sin Commons-motsvarighet. En möjlig komplikation är hur man hanterar om flera av kategorierna har Commons-motsvarigheter. Punkt 4 är betydligt mer komplicerat. Då skulle man behöva föra ett register av negativa bild-artikelkopplingar. Den databasen kan nog väldigt snabbt bli väldigt stor. Jag vet att Magnus har byggt in något liknande i WD-Fist men där registreras enbart bilder som är fel för alla artiklar (t.ex. File:No_coats_of_arms.svg. /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 13.41 (CEST)

Tack, André. Ja, det är en ganska bra sammanfattning av de olika punkterna. Punkt 1-kommentaren stämmer: det är så VE gör. Punkt 2 var inte fokuserad på wikitextredigering egentligen, utan på VisualEditor, men jag vet inte hur skilda systemen är så jag vet inte om det ena måste utvecklas separat från det andra. Så för att försöka vara tydligare än jag varit tidigare: jag ser gärna att den här funktionen att få en fråga om jag vill föra in mediafil X i artikeln där markören är placerad både i VisualEditor och wikitext. Punkt 3 är kanske den svåraste, eftersom det inte alltid finns Commonskategori kopplad till artikeln, men där kanske man skulle kunna ha en prioriteringslista baserad på någonting i stil med det här: a) filnamn = artikelnamn, b) bild(er) som finns kopplade till Wikidata-objektet, c) Commonskategori = artikelnamn, och d) fuzzy search på Commons baserat på artikelnamn. Punkt 4 kan nog bli stor, som du skriver, men det kan också vara en mycket tidsbesparande sak, som ett slags curator-funktion, som andra kan tänkas uppskatta också, om vi hittar ett bra sätt att göra det på.//Hannibal (diskussion) 23 juli 2017 kl. 13.27 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.49 (CEST) även om det på många sätt är en god idé om än lite vag i vad som skulle göras, så ser jag det skulle bli ytterligare en av dessa gadgets som man skall kryssa för i sina inställningar. Jag uppfattar genomslaget för sådan gadget blir för litet, och att vi bör överlämna till MWF att utveckla sådana, de kan räkna hem en sådan grej lättare
2. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) Även om jag kan förstå Ygers argument ovan, tänker jag att positiva röster här kan göra att det blir enklare att få WMF att genomföra en sådan här funktion. Oavsett vem som gör det borde funktionen finnas.

---

Mer film och ljud till alla!

Problem

För lite film och ljud som levandegör innehållet i Wikipedia.

Vilka påverkas

Alla användare.

Tidigare diskussioner

Vet inte.

Lösningsförslag

Samverka t.ex. med SVT:s öppna arkiv, filmarkivet.se, Stockholmskällan, Svenskt Visarkiv, Svenskt Rockarkiv etc kring att dela innehåll och upphovsrätt.

Föreslaget av

193.11.31.222 20 juli 2017 kl. 09.10‎ 1 januari 2001 kl. 00.00 (CET)(Signatur tillagd i efterhand.)

Diskussion

Samarbete med olika ABM/GLAM organisationer gör Wikimedia Sverige redan idag. Fokuset för denna önskelista är främst tekniska utvecklingar för Svenskspråkiga Wikipedia. Från beskrivningen är det inte klart vilken sådan funktionalitet som önskas. /André Costa (WMSE) (diskussion) 21 juli 2017 kl. 13.52 (CEST)

Då denna önskan saknar tillräckligt med information kommer den inte att ingå i omröstningen. /André Costa (WMSE) (diskussion) 7 augusti 2017 kl. 10.23 (CEST)

---

Sociala

Automatisk signering

Problem

Ibland glömmer någon att signera i en diskussion (oftast nya användare). Detta gör det svårt att se vem avsändaren är. Nuvarande lösning är att andra användare manuellt lägger till {{osignerad}} vilket är bökigt, tar tid och inte sker systematiskt.

Vilka påverkas

Wikipedianer, både nya (som glömmer signera) och erfarna (som hanterar dessa idag)

Tidigare diskussioner

Wikipedia:Bybrunnen/Arkiv 2017-07#SignBot här?

Lösningsförslag

Bot som signerar osignerade diskussionsinlägg. Idag finns både och c:User:SignBot som skulle kunna anpassas. För den senare finns koden på [3] och den stödjer bl.a. funktionalitet för att opt-out/opt-in, och skiljer mellan nya användare och erfarna användare.

Föreslaget av

Detta var en av idéerna som lyftes under förmötet ( André Costa (WMSE) (diskussion) 17 juli 2017 kl. 11.15 (CEST) )

Diskussion

Ursprunget till denna idé var Skottniss Bybrunnen-inlägg. /André Costa (WMSE) (diskussion) 17 juli 2017 kl. 11.15 (CEST)

Vore det inte bättre med ett redigeringsfilter som påminner och/eller hjälper användaren att signera sina inlägg när ett inlägg (som avslutas med en radbrytning) görs på diskussionssidor? De flesta uteblivna signaturerna beror antagligen på glömska eller okunskap om hur man gör. Om man får en påminnelse och även hjälp med att "få till" de där ~~~~ slipper vi en massa botediteringar. --Larske (diskussion) 18 augusti 2017 kl. 12.31 (CEST)

Kommer ett sådant filter att träffa speciellt många missade signeringar? Det känns som att sannolikheten för att någon gör en radbrytning det sista de gör när de skrivit, men inte signerar, är låg. Om man istället tittar efter redigeringar som inte har ~~~~ som sista tecken är sannolikheten högre, men jag tror att det skulle göra att man få påminnelse varje gång man korrigerar ett inlägg på en diskussionssida, vilket kanske blir tjatigt. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 12.49 (CEST)

Om vi säger "som inte direkt efterföljs av något annat än radslut" då? Dvs det finns ingen annan text efter inlägget på samma rad som inlägget. Då får man heller ingen påminnelse när man korrigerar någonstans inne i ett inlägg. --Larske (diskussion) 18 augusti 2017 kl. 13.00 (CEST)

Ja då är vi nog nere i få falska positiva, även om de såklart kommer att hända (ex. någon korrigerar något i slutet av en rad i en lista i ett diskussionsinlägg). Jag tycker nog ändå att en bot är användarvänligare. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 13.26 (CEST)

Omröstning

1. Yger mycket bra och önskvärt och jag ligger nära stöd, lägger mig dock här då jag känner detta inte tillräckligt ger oss erfarenhet vad vi kan använda Gemenskapens tekniska önskelista till. Det är ju relativt enkel bot, som går lätt få ihop, och här är oftast problematiken kring vem som ansvarar och underhåller en sådan bot, och fler saker som "simmar" omkring utan någon som är operativt ansvarig ser jag inte som önskvärt.
2. Ja, det är nog mer lämpligt att hitta en villig botägare, än sätta "Gemenskapen" på det här. -- Innocent bystander (diskussion) 8 augusti 2017 kl. 16.34 (CEST)
3. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) enligt motiveringar ovan, men med förbehållet att det vore bra om vi kunde hålla koll någonstans på alla funktioner så att det inte råkar bli så att vissa positiva funktioner slutar fungera bara för att en botägare slutar.
4. Jag kan vara botägare för en sådan bot. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.49 (CEST)

   @Ainali: Har du kod? -- Innocent bystander (diskussion) 18 augusti 2017 kl. 12.20 (CEST)

   Nej, men det är ju det som det här förslaget ska fixa. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 12.23 (CEST)

5. Larske (diskussion) 18 augusti 2017 kl. 12.36 (CEST) En lösning på problemet är önskvärd, men jag vet inte om en botlösning är det rätta, se mitt diskussionsinlägg ovan.

---

Wikiträffar

Problem

Svårt att veta när en träff eller skrivstuga sker (om man inte bevakar sidan). Den nuvarande lösningen med Geonotice är opraktiskt då det är en Javascript-sida vilket gör den: svår att redigera, bara redigerbar av administratörer samt att processen är skild från uppdateringen av WP:WT.

Vilka påverkas

Wikipedianer som vill träffas AFK.

Tidigare diskussioner

Lösningsförslag

Bygga en Javascript-finess (Gadget) som bevakar WP:Wikiträffar och notifierar användaren när ett nytt event finns. Användaren bör kunna göra en filtrering på plats och möjligen typ av event.

Föreslaget av

Detta var en av idéerna som lyftes under förmötet ( André Costa (WMSE) (diskussion) 17 juli 2017 kl. 11.15 (CEST) )

Diskussion

Under diskussionerna kom även följande praktiska implementeringstankar/-funderingar:

• Kollar innehållsförteckningen, inte hela sidan
• Sparar relevanta event i localstorage
• Jämför gamla och nya event
• Notifierar användaren - ikon i övre raden

/André Costa (WMSE) (diskussion) 17 juli 2017 kl. 11.15 (CEST)

Det vore fiffigt om finessen klarar av att göra samma sak som geonotice, det vill säga att notifiera om träffar i närheten. Lämpligt är väl kanske att försöka ge en notis för allt inom 50 km radie? ♥Ainali ^diskussion_bidrag 18 juli 2017 kl. 09.03 (CEST)

Fundering Är det möjligt att använda Mediawikis inbyggda notis system? Annars är det kanske användarvänligare med en bot(CRON) som postar till ens användares Diskussions-sida? Anmälning till funktionen och eventuella inställningar(geografiska, tid innan, etc) kan då göras med en osynlig mall på ens användarsida. Abbe98 (diskussion) 19 juli 2017 kl. 14.50 (CEST)

Om det enbart är opt-in så kommer vi missa alla nya användare som inte förstår hur en mall fungerar eller ens hittar den och de är kanske de som annars kan ha mest nytta av att träffa fler erfarna användare. Bättre med en opt-out i finesserna i så fall (som görs lättåtkomlig varifrån nu meddelandet visas). ♥Ainali ^diskussion_bidrag 19 juli 2017 kl. 14.56 (CEST)

Sant! En möjlighet att ha en mall för opt-out/konfiguration. Av egen erfarenhet finner jag att botar är lättare att underhålla än finesser och det känns användarvänligare att använda det inbyggda notis systemet. Abbe98 (diskussion) 20 juli 2017 kl. 11.48 (CEST)

En bot är nog mindre lämpligt med tanke på integritetspolicyn. -- Innocent bystander (diskussion) 20 juli 2017 kl. 12.42 (CEST)

Utvecklingsresurser bör användas till sådant som mer direkt underlättar för många att bidra till uppslagsverkets innehåll, utseende och kvalitet, inte till sådant som bättre kan göras i "sociala media". Parentesen i problemformuleringen innehåller ju lösningen på problemet – bevaka sidan! --Larske (diskussion) 18 augusti 2017 kl. 11.51 (CEST)

Omröstning

1. Yger (diskussion) 7 augusti 2017 kl. 11.55 (CEST) för begränsad målgrupp och för lite nytta
2. Hannibal (diskussion) 9 augusti 2017 kl. 20.16 (CEST) Jag tror att det är bra att träffas utanför Wikipedia också, och ju enklare vi gör för folk att träffas, desto fler sådana tillfällen kommer det att bli. Lägg märke till att redigeringar i mallen Wikiträffar också skulle kunna bevakas av ett Twitterkonto som automatiskt lägger till hashtaggen med den stad som wikifikat kommer att äga rum i.
3. Med lite tanke i början kan detta bli en funktion även andra projekt kan kopiera, vilket kan gen en mycket stor global effekt. ♥Ainali ^diskussion_bidrag 18 augusti 2017 kl. 10.52 (CEST)
4. --Larske (diskussion) 18 augusti 2017 kl. 11.51 (CEST) Som Yger. Se även mitt diskussionsinlägg ovan.

Resultat

Wikimedia Sverige går igenom de olika önskningarna för att se vilka som är genomförbara (inom ramen för den tid och kompetens som finns tillgänglig) samt vilka som förväntas att ge bäst genomslag för den krävda insatsen. Omröstningen (se resultat nedan) ligger till stöd för det slutliga urvalet men utgör enbart ett av kriterierna.

Summering av omröstning

6 -- #Klottersaneringsstöd
5 -- #Kostnadseffektivare Wikidata-stöd i infoboxar, #Automatkonvertera källhänvisningar som enbart består av URL:er
4 -- #Citoid-bibliotek för svwp
1 -- #Skapa en Mall:Konstverk WD som hämtar data från Wikidata, #Konvertera mellan källmallar
0 -- #Multimedia och #Sociala önskningar

Utvärdering och val av projekt

Tack för ert intresse för den Tekniska Önskelistan. Tillsammans kan vi göra världens bästa uppslagsverk ännu lättare att redigera och använda sig av.

WMSE:s utvecklarteam har nu valt ut två av förslagen att arbeta vidare med.

Det första är att implementera klottersaneringsverktyget Ores på svenskspråkiga Wikipedia. Förslaget fick flest ja-röster och bedömdes dessutom leda till mest direkt nytta för såväl redigeraren som läsaren. Här har vi dessutom en stabil grund att stå på i och med att en del av förarbetet med träningen av modellen redan är gjort. Ur utilitaristisk synpunkt är detta ett sannerligen lovande projekt.

Det andra är att vidareutveckla källverktyget Citoid på svenskspråkiga Wikipedia med fokus på de källor som faktiskt används här och som ofta ställer till med besvär. I detta ingår även att automatformatera källhänvisningar bestående av rena url-adresser. Genom att kombinera dessa två delar kan vi förbättra källhanteringen på svenskspråkiga Wikipedia och därmed göra det mer pålitligt. Även detta projekt kommer att gynna många.

Vi vill dessutom nämna att vi har fört omfattande diskussioner om dem av förslagen som rör Wikidata. Att utveckla kopplingen mellan Wikidata och Wikipedia är en intressant frågeställning och dessutom ett område där det just nu händer mycket utveckling. Frågeställningen avfärdas därför inte i sin helhet, utan snarare läggs på hyllan till en tid då vi har mer resurser att ägna åt det, kanske nästa år.

Det egentliga arbetet med att implementera projekten beräknas kunna inledas i slutet av oktober månad. Innan dess är alla varmt välkomna att diskutera på undersidorna:

• Wikipedia:Gemenskapens tekniska önskelista/Ores
• Wikipedia:Gemenskapens tekniska önskelista/Citoid

För er som vill och kan använda Phabricator så finns projekten upplagda även där: Ores, Citoid. Det är självklart inget krav för den som har idéer och förslag, utan det går ypperligt bra att diskutera här på Wikipedia. Säg gärna till om ni vill ha hjälp med att komma igång med Phabricator.

Tack en gång till för ert deltagande i enkäten och diskussionen, och för att ni varje dag visar samhällsmedborgerliga dygder och hjälps åt med att göra kunskap fri och tillgänglig för alla.

Å WMSE:s utvecklarteams vägnar, --Alicia Fagerving (WMSE) (diskussion) 11 september 2017 kl. 09.16 (CEST)

Tack, instämmer i ert resonemang och prioritering. Även att Wikidata(-kopplingar) är ett viktigt område där det kommer dyka upp många beheov, men också att det kan vara bra att vänta till 2018, så rutiner och arbetssätt med mera kan trimmas in med dessa två ärenden.Yger (diskussion) 11 september 2017 kl. 11.06 (CEST)