Wiktionary:Bybrunnen/Arkiv20

Någon som är intresserad av att lägga till rim på svenska wiktionary. De har redan det på den engelska motsvarigheten och det är väl bra då wiktionary får en annan grupp internetanvändare att attraheras hit.Jonteemil (diskussion) 24 mars 2016 kl. 04.24 (CET)

Ingen som vill ha rim?Jonteemil (diskussion) 3 april 2016 kl. 16.40 (CEST)

Varför finns inte denna verb form på svenska verbmallar? Ett monster är inte skjuten utan skjutet, ett barn är inte född utan fött och många fler exempel kan läggas fram. Jag tycker man borde ändra alla verbmallar på alla sidor! Jonteemil (diskussion) 18 februari 2016 kl. 13.07 (CET)

Inte heller skjutna, skjutne finns med. Jag kan hålla med dig om att man kunde lägga till.detta. Som det är nu får man gå in på adjektivartikeln skjuten... --Andreas Rejbrand (diskussion) 18 februari 2016 kl. 13.41 (CET)

Hur svårt är det att skapa en ny eller ändra en böjningstabell?

Om det inte är allt för svårt kanske jag skulle kunna göra det?

Jonteemil (diskussion) 4 mars 2016 kl. 22.09 (CET)

Först måste vi undersöka vad gemenskapen har för åsikt i frågan och ta reda på vad konsensus är. --Andreas Rejbrand (diskussion) 5 mars 2016 kl. 00.06 (CET)

Vem skulle inte hålla med? Jag menar, det är ju tre verbformer som inte visas i denna inte helt fullt utvecklade böjningstabell.

Jag stötte även på en annan "böjningstabellserror" och det är nämligen så att adverbavledning framgår inte på dom adjektivmallar som inte är komparabla eller med mer och mest-komparabla. Detta bör också fixas.Jonteemil (diskussion) 5 mars 2016 kl. 14.38 (CET)

Jag tycker inte att det är en bra idé att ha med böjningsformer till perfektparticip, eftersom de är avledda adjektiv. Information om deras böjningar finns på det uppslaget. Om vi ska ha med alla former direkt kopplade till ett verb så blir det väldigt många: alla adjektivformer för perfektparticip (skjuten, -et, -na, -ne, gäller både attributivt och predikativt), för presensparticip (skjutande/skjutandes med nollböjning, attributivt men knappast predikativt), substantivavledning (ett skjutande, -t, -s, -ts, oräknebart). Och drar vi gränsen där eller ska vi ha med ännu fler avledningar som skjutning (eller föda>födelse)?

Det känns inte som om vi hanterar böjningsformer på ett tillräckligt strukturerat sätt som det är, så jag skulle vara skeptiskt till att lägga till många fler.

Som Andreas sa, så kan man gå in på respektive sida för att se mer information om det ordets böjning. //Skal 5 mars 2016 kl. 21.56 (CET)

Okej jag ger mig vid perfekt participen men att adverbavledningen till okomparabla adjektiv inte finns tycker jag ändå borde åtgärdas då den förekommer vid komparabla adjektivJonteemil (diskussion) 9 mars 2016 kl. 15.00 (CET)

CategoryTests är ett tillägg till MediaWiki-mjukvaran för att kolla om en sida tillhör en viss kategori. Tillägget skulle exempelvis kunna användas för att på förhand ta reda på vilka språk ett visst uppslag behandlar. Denna information kan sedan användas till många ändamål, exempelvis halvautomatiska översättningar (se även Malldiskussion:test-länka). Vill vi ha CategoryTests kan vi skriva en buggrapport som begär att programtillägget installeras. Tror det krävs att en formell omröstning först äger rum. Bounce1337 13 april 2011 kl. 20.08 (CEST)

Buggrapport. Bounce1337 16 april 2011 kl. 17.25 (CEST)

Stödjer

1. Bounce1337 13 april 2011 kl. 20.08 (CEST)
2. Dodde 13 april 2011 kl. 20.14 (CEST)
3. --Lundgren8 (d · b) 14 april 2011 kl. 00.08 (CEST) Det verkar användbart.
4. JoolzWiki ^(d|b) 14 april 2011 kl. 20.30 (CEST)
5. – Smiddle 14 april 2011 kl. 20.43 (CEST) Inga nackdelar? Då så.
6. "85" 18 april 2011 kl. 19.50 (CEST)

Stödjer ej

Avstår

Diskussion

Hur kan man:

1. Visa vilken kinesiska det handlar om? Hur vet man om det är mandarin eller kantonesiska som avses i uppslagen?
2. Redovisa förenklad respektive traditionell skrift i uppslagen?

Jag vet inte hur mycket detta har diskuterats tidigare, men det har inte diskuterats under min tid på wiktionary så vitt jag vet, och eftersom kinesiska inte är ett stort språk på sv.wikt kanske det är värt att ta upp? --Lundgren8 (d · b) 10 juli 2011 kl. 01.23 (CEST)

Jag vet inte vad som är skillnaden ens. Om du eller någon annan har god kunskap i kinesiska kan det diskuteras hur kinesiska uppslag lämpligen ska se ut. Vi har tidvis diskuterat japanska ganska mycket och kommit fram till vissa slutsatser, men även där känns det som om det finns en hel del kvar. Det finns en speciell japansk stilguide som försöker lyfta fram strukturprinciper som är speciella för japanskan. Jag har för mig att det dock hade behövts arbetas vidare på den, och en hel del japanska uppslag skulle behöva gås igenom och struktureras om, men för närvarande har vi såvitt jag vet ingen aktiv användare som sysslar med japanska uppslag.

Förmodligen finns behov för kinesiska som liknar behoven för japanska. Därtill antar jag att Nord- och sydkoreanska och kanske något mer språk(?) som det också gärna hade fått tagits hänsyn till.

Jag känner inte till om olika språkkoder används för mandarin och kantonesiska på andra språkversioner av Wiktionary. Wikipedia anger ISO 639-1-koden "zh" för båda. Stilguiden säger för närvarande att språknamnet mandarin inte ska användas, till förmån för kinesiska. Detta bestämdes innan någon gång mellan 2004 och 2006 (innan jag registerarade mig som användare) och jag känner inte till hur resonemanget såg ut. Jag gissar att Sanna som redigerade här tidigare möjligtvis kan svara på den frågan.

I brist på särskild struktur för kinesiska, så är det generella svaret på den frågan är att den typen av information kan anges på fetstilsraden eller med {{tagg}}. Med tagg-mallen så får det isåfall liknande struktur som används när man vill informera om en viss stavning gäller t.ex. amerikansk eller brittisk engelska, eller en dialekt. Jag antar att noteringen om stavningen avser traditionell eller förenklad kinesiska bäst nämns på fetstilsraden (om det ens är nödvändigt? ser man inte skillnaden på något sätt som ex.vis skillnaden mellan kanji och hiragana i japanskan?). I översättningslistorna markerar man de kinesiska översättningarna på motsvarande sätt, traditionell eller förenklad kinesiska, eller vilken "dialekt" det rör sig om, inom sned parentes efter (eller framför?) översättningen. Jag vet inte vad som är lämpligt i det här fallet, alternativet är ju som du förmodligen är inne på att använda olika språkkoder för olika kinesiska "dialekter".

För redan befintliga kinesiska uppslag och översättningar: saknas den här informationen så antar jag att man inte direkt kan säga vilken kinesiska det handlar om.

För kinesiska uppslag för traditionell kinesisk skrift, antar jag att man inom parentes kan ange den förenklade, på samma sätt som hiragana/katakana (och romaji) anges inom parentes på fetstilsraden på kanji-uppslag.

Men för att dra igång nåt större strukturprojekt om detta/en kinesisk kompletterande stilguide behövs nog betydligt mer kunskap än vad jag kan bidra med. ~ Dodde (diskussion) 24 december 2012 kl. 09.20 (CET)

Jag kan väl lägga till diskussionen att problematiken med de kinesiska uppslagen (som är samma tecken som japanska kanji) är ju att de regionala variationerna av "kinesiska" skiljer sig så markant åt att de är inbördes obegripliga. Kinesiskan har genomgått något som liknar latinets splittring, och många språkforskare anser de regionala varianterna som separata språk (t.ex. har kantonesiska hela 9 tonljud, gentemot mandarins fyra). Det som gör kinesiskan svår att sammanfatta under ett uppslag är ju just dess många, många varianter som alla ska rymmas under ett tecken, till skillnad från språk med ljudåtergivande alfabet där de olika varianterna mer självklart får egna uppslag och artiklar.

Jag tittade närmare på hur en:wikt har löst det, och där har mandarin, kantonesiska och min nan (och möjligen fler) fått egna artiklar under samma uppslag, vid sidan av japanska kanji och koreanska hanja.

Mandarin och kantonesiska har samma iso-1kod, men iso2 skiljs de åt som shi och chi, minnan ISO-3koden "nan". ╰ Svenji 8 februari 2013 kl. 20.07 (CET)

Så frågan är väl bara om någon har kunskap och engagemang till att skilja på alla kinesiska uppslag och översättningar och placera dem under mandarin respektive kantonesiska, isåfall kan vi efter det ta bort "kinesiska", eller? ~ Dodde (diskussion) 10 februari 2013 kl. 09.58 (CET)

Jag skulle kunna tänka mig att göra det, men frågan är hur det skulle struktureras i översättningsmallar. Kinesiska som huvuduppslag med indragna rader därinunder (som kyrillisk och latinsk version av serbiska), eller helt separat som bokmål och nynorska? Jag föredrar nog att de ändå samlas under kinesiska eftersom det är troligast att besökare till wiktionary letar efter översättningen just där.

• kinesiska:

  mandarin:

  kantonesiska:

  annan variant: ╰ Svenji 13 februari 2013 kl. 15.00 (CET)

Vi försöker undvika indragna rader (till skillnad från ex.vis enwikt). För serbiska framgår det exempelvis ganska tydligt om skriften är kyrillisk eller latinsk, i andra fall kan vi tydliggöra med parenteser e.dyl. Jag har ändrat detta i en hel del översättningslistor, men det finns nog fler kvar att fixa till.

Principen är att vi skiljer på språk genom olika språkkoder. De vi skiljer åt får därför egna rubriker på motsvarande sätt som de får egna rader i översättningslistorna. Språknamnsrubrikerna och språknamnen i översättningsraderna är också motsvarande varandra, f.n. helt utan undantag. Svaret är alltså ja, helt separat, precis som bokmål och nynorska.

Att rada upp de språknamn som blivit, i bokstavsordning, har nämnts innan att det kan bli lite dumt ibland, men det gäller isåfall inte bara kinesiska utan ett flertal språk, bokmål är ett tydligt exempel. Det för å andra sidan med sig helt andra typer av gränsdragninsproblem. Så jag är tveksam till att gå in på den vägen. ~ Dodde (diskussion) 16 februari 2013 kl. 02.01 (CET)

Jag är intresserad av att omstrukturera hur vi hanterar kinesiska språken, jag vill lösa upp kategorin kinesiska och efterlikna den struktur som engelska Wiktionary använder. Ta gärna en titt på en:Category:Chinese language, en:Category:Sinitic languages och en:Category:Mandarin language för att få en snabb bild av hur det kan se ut. Förenklingen mandarin > kinesiska är något vi alltså bör undvika. Sedan vill jag att stor fokus ska läggas på att organisera Hanyu pinyin som används som officiell transkribering, det bör inte räcka med att bara skriva pinyin då det finns flera pinyin-system, även om Hanyu pinyin är det vanligaste så kan det ställa till det för den som t.ex. använder sig av Tongyong pinyin. Och långsiktigt arbete bör ta hänsyn till detta. Sedan finns det en punkt till som kan vara intressant att utveckla, och det är att fylla ut artiklar med "IME-språk" alltså hur kinesiska tecken skrivs på tangentbord. Vanligt för västerlänningar är att skriva fonetiskt då räcker det med pinyin, men lika vanligt är det att använda sig av formbaserade tecken som Zhuyin (Bopomofo) eller Cangjie som ofta skrivs på de andra språkversionerna, detta tycker jag bör tas med då teknikerna är lika tillgängliga även för västerlänningar.

Sedan behöver fokus läggas på att fixa indexlistor för alla kinesiska radikaler, alla pinyinljud, exempel en:méi och en:mei2. Dessa två är identiska med undantag på hur de skrivs ut i olika pinyin former, för den som studerar kan det dock underlätta med separata sidor. Mallar behövs också för att förklara om det är traditionella tecken eller förenklade, och såklart bör även extrasidor för detta skapas då språk som japanska kan använda det ena tecknet men inte det andra. C.Nilsson (diskussion) 27 februari 2013 kl. 12.27 (CET)

Jag har tyvärr ingen kunskap i kinesiska, men... låter positivt alltihop. Det viktiga ur struktursynpunkt är att vi bestämmer oss för vad som ska hanteras som språk (bestämma svenskt språknamn och bestämma språkkod). När detta väl är bestämt görs det strukturmässigt ingen skillnad på språk och språk. Ett språk, en språkkod, en egen rubrik, en översättningsrad i översättningslistorna. Så första steget är att redigera Wiktionary:Stilguide/Språknamn och lägga till språknamnen och språkkoderna i Wiktionary:Användare/Robotar/Sorteringsinställningar så att bottar kan känna igen dem. Jag tycker att det är rimligt att skapa en mall / flera mallar för att tydliggöra vilken transkribering som används, vilket är viktigt för långsiktigheten som du säger. Antingen en mall (typ {{trans}}) med parameter system= eller annat, som kan ta parametrar som hanyu och tongyong, eller att man skapar egna mallar för dessa (typ {{tr-hanyu}} eller bara {{hanyu}}), vad tycker du? Berörs ex.vis japanska och/eller koreanska av detta? Zhuyin och Cangjie (låter som japanskans kanji?) hänger jag inte med på, men så länge det sker med en genomtänkt struktur så är det bara positivt. Om det krävs nån speciell struktur än "den allmänna" för just detta, förklara gärna så vi får in det i helheten så bra som möjligt. Indexlistor, fungerar appendix-sidor bra till det, eller är det någon sorts kategori-sidor du menar? Angående traditionella tecken eller förenklade, hur menar du att mallar är nödvändiga. Ska varje tecken omgärdas av en mall, eller räcker det att det läggs till en text på fetstilsraden? Hur viktigt är markering i ex.vis översättningslistor? ~ Dodde (diskussion) 28 februari 2013 kl. 22.52 (CET)

Jag skulle gissa på att vi kan använda appendix-namnrymden för att översätta en:Index:Chinese och dess innehåll (rätta mig om jag har fel). Angående språkkoder så bör det sättas till de stora språkfamiljerna, se bilden. Mandarin (cmn) har t.ex. väldigt många dialekter, om det finns anledning att gå djupare i språkfamiljerna så bör det såklart göras om det finns intresse, men det kommer nog dröja många år innan det finns motivation att prioritera sånt. Viktiga är dock att undvika (zh) som synonym för mandarin (standard kinesiska) då det skapar förvirring, även om detta är korrekt. Zhuyin är ett fonetiskt transkriptionssystem likt pinyin. Cangjie är en inmatningsmetod för datorer, Tecken som kombineras för att bygga nya tecken kan man säga. Angående kategorisortering så vet jag inte riktigt hur det löses bäst, det får kollas upp, jag vet att engelska Wiktionary har löst det på något sätt så det borde gå kopiera. Angående mallar, det bästa tror jag är att ha mallar som är avsiktliga för varje språk.

Exempel 1: om vi utgår från en artikel om 面 och fokuserar på mandarin, {{cmn-hanzi|han=|hans=面|hant=麵|hanyu=miàn|tongyong=(lämnas tom, samma som hanyu)|wg=mien4|zhuyin=ㄇㄧㄢ}} som då ger resultatet:

面 (traditionellt tecken: 麵, Pinyin: miàn (mian4), Wade–Giles: mien⁴, Zhuyin: ㄇㄧㄢ)

Om man förutsätter att artikeln handlar om artikeltiteln så skulle alltså första, andra eller tredje parametern gå att jämföra med titeln för att få vettig formatering.

Exempel 2: Om både hanyu och tongyong hade fyllts i till artikeln 對照 skulle det istället stå:

對照 (förenklat tecken: 对照, Hanyu Pinyin: duìzhào (dui4zhao4), Tongyong Pinyin: dueìjhào, Wade–Giles: tui⁴chao⁴, Zhuyin: ㄉㄨㄟˋ ㄓㄠˋ)

Här nämns inget om Cangjie då det inte är knutet till mandarin, utan till tecknet (och bör nämnas i översta stycket). Det kan alltså fungera oavsett talat språk, till skillnad från Zhuyin som för det mesta utgår från mandarin. Liknande mallexempel bör alltså tas fram för samtliga språk som det väljs att skrivas om. Jag tror förresten att en projektsida för sinitiska språk kan vara vettigt så det får diskuteras på ett annat ställe än bybrunnen. C.Nilsson (diskussion) 1 mars 2013 kl. 03.34 (CET)

Ser bra ut, vad jag kan se. Det är hur som helst svårt att riktigt förstå om man inte är insatt i det. Viktigt att användningsinstruktioner finns så att fler än mallskaparen kan använda sig av den. :) Mallarna beskriver vi på Wiktionary:Mallar eller undersidor till den sidan. Det kanske även är aktuellt att skapa en egen stilguide (som för japanska Wiktionary:Stilguide/Japanska) där strukturen för kinesiska uppslag tas upp lite mer detaljerat. "förenklat tecken" och "traditionellt tecken" kanske ska ändras till "förenklat" respektive "traditionellt" för att undvika problem med att det ibland är ett och ibland fler tecken i uppslaget. font-size kanske ska vara lite mindre, eftersom mallen väl ska kunna fungera även i översättningslistor och kanske även i övrig text, men tillräckligt stort för att man ska kunna se tecknen ordentligt förstås. Kanske är det bra att ha uppslagsordet isär från mallen, så att formateringen för fetstilsraden med tre apostrofer före och efter kan finnas med för att den allmänna strukturen kan bibehållas. Vet ej om det är möjligt. Också för att i översättningslistorna få länkningen till kinesisk wiktionary att fungera. ~ Dodde (diskussion) 1 mars 2013 kl. 07.48 (CET)

Formateringen går det pyssla mer med, och centrerar man i höjd så brukar det bli bra faktiskt. På Wikipedia har vi nöjt oss med <big></big> (font size 3) för att inte kladda ned artiklar med stora tecken, detta är inte tillräckligt stort alla gånger tyvärr. Anledningen är såklart att kinesiska tecken måste renderas i fler pixlar än latinska bokstäver om man vill ha läsbarhet, se t.ex kinesiska Wiktionary som valt en en större grundstorlek. Jag ska sätta mig ned och börja skriva lite mallar i helgen, det behövs såklart ett par vettiga exempel som man kan utgå ifrån också när man skriver en ny stilguide. C.Nilsson (diskussion) 1 mars 2013 kl. 11.06 (CET)

Toppen! Baka gärna in formaterings/storleks/fontinställningar i en skrift-mall (som inleds med ett +-tecken) istället för direkt i de mallar du skapar. {{ö}} (översättningsmallen) anropar exempelvis dessa mallar när parametern skrift= används, och de nyskapade mallarna kan också anropa dem. Mallarnas namngivning följer ISO 15924 för skriftsystem . Ett antal mallar är redan skapade, bland annat {{+hani}} och {{+hans}} Kategori:Wiktionary:Grafiska_mallar. Jag gissar dock att mallarnas innehåll kan behöva ändras (större tecken ex.vis). ~ Dodde (diskussion) 1 mars 2013 kl. 12.42 (CET)

Bra, då fattas bara {{+hant}} för att hanzi ska täckas i översättningsmallarna. Jag skrev på teknikvinden om hur en bättre mall tagits fram på engelska Wiktionary som jag gärna vill ha hjälp med att kopiera hit. C.Nilsson (diskussion) 1 mars 2013 kl. 14.02 (CET)

I reaktion på och föreslår jag att man på något vis lägger in informationen under en grammatikrubrik på huvuduppslaget. Detta som en möjlighet. – Smiddle 3 april 2012 kl. 11.42 (CEST)

Jag tycker också det vore bra att samla informationen på huvuduppslaget. Skulle det vara konstigt att använda {{homofoner}} på huvuduppslaget för såväl grundformen som för dess böjningsformer? Eftersom det tangerar med uttal (båda är dessutom sällan förknippade med endast en definition i de fall flera finns), är en tanke också att integrera homofoninformation med uttalsmallen? ~ Dodde (diskussion) 3 april 2012 kl. 15.17 (CEST)

Vissa böjningsformer uttalas oregelbundet, t.ex. en:says. Jag tycker att franskspråkiga Wiktionary har en bra lösning, där grammatikmallarna kan förses med uttalsbeskrivning (se exempelvis fr:cocher). De flesta formerna kan skapas automatiskt, förutom i oregelbundna fall. Dessutom kan man enkelt infoga informationen i respektive böjningsuppslag, ifall man någon gång i framtiden skulle ändra sig. Bounce1337 (diskussion) 3 april 2012 kl. 19.17 (CEST)

Se mallen till höger. Bounce1337 (diskussion) 3 april 2012 kl. 21.45 (CEST)

Jag gillar idén att lägga till uttal i böjningsmallen, det ser snyggt ut. Men lite fundersam över hur långt t.ex. franska och spanska verb-mallar (t.ex. faire) skulle sträcka sig om de fick uttalsbeskrivning... ╰ Svenji 4 april 2012 kl. 14.16 (CEST)

Jag undrar också hur ni andra ser på uppslag som gårde, en böjningsform som ej finns med i någon grammatikmall men som finns kvar som stelnat uttryck. För närvarande har det underrubriker för att förklara böjningen, det tycker jag själv känns helt rätt. ╰ Svenji 4 april 2012 kl. 14.36 (CEST)

Låter som mycket arbete att utveckla sådana mallar. Det finns otroligt mycket att göra i förbättringsväg när det gäller grammatikmallarna redan. Till och med för svenska råder det stor oklarhet hur uttal egentligen ska skrivas (åtminstone sträcker sig stilguiden/uttal bara en bit i den riktningen), så det kanske inte är nån bra idé att dra på allt för stora växlar förrän en del av de frågetecknen retts ut. För andra språk kanske det råder än större oklarhet. Kanske det då är smidigare att överlåta mer djupgående uttalsinformation till de aktuella språkversionerna av Wiktionary. I den takt och mån vi ändå skulle bestämma oss för att införa uttalsanvisningar som en del av grammatiktabellerna, tycker jag alltså att vi isåfall åtminstone ska begränsa oss till de svenska. Och information om uttal tycker jag ska begränsas till huvuduppslaget. Men allt detta är inget jag tycker att vi ska satsa på i nuläget alltså. För avvikande uttal av böjningsformer finns redan möjlighet att notera det på exemppelvis uttalsraden på huvuduppslaget med {{uttal}} (även om kanske information om den möjligheten saknas i mallbeskrivningen för närvarande).

Men till ursprungsdiskussionen. Kommer vi nån vart med homofonerna? ~ Dodde (diskussion) 4 april 2012 kl. 17.23 (CEST)

På WT:Stilguide#Omdirigeringar beskrivs att {{inget uppslag}} används vid samma tillfällen som {{se även}}, fast då det inte finns något uppslag. Jag skulle vilja förtydliga/ändra till följande:

{{inget uppslag}} används vid felstavningar och andra fall då användaren bör bli uppmärksam på att hen skrev fel i sökningen. Om användaren skrev något som kan klassas som rätt, men där vi har valt att ha uppslaget på en annan titel används #OMDIRIGERING ]. Notera att detta inte ersätter behovet av att ha riktiga variant-uppslag.

Exempel på {{inget uppslag}}:

• abbonemang → abonnemang
• quatre-vingts-dix → quatre-vingt-dix

Exempel på #OMDIRIGERING ]:

• bosätta sig → bosätta
• allt är inte guld som glimmar → Allt är inte guld som glimmar.

Vad tycker ni? //Skal 16 november 2012 kl. 21.10 (CET)

Enligt min mening ska Wiktionary ha med rättstavade ord, men vara försiktig med att uttala sig om felstavade. Därför är det sagt att användning av {inget uppslag}/{se även} inte är en värdering om huruvida en stavning är korrekt eller ej, utan endast ett konstaterande att Wiktionary för närvarande saknar ett uppslag för den stavningen (alternativt att man även har ett uppslag med liknandet stavning). {inget uppslag}/{se även} ska helt enkelt kunna användas då användaren kan tänkas vilja komma till en annan sida än den han eller hon skrev in.

Vad jag minns/uppfattade från tidigare diskussioner så ska hård omdirigering inte användas då det kan vara problematiskt om användaren inte uppmärksammar att han eller hon hamnar på en annan sida än den han eller hon faktiskt skrev in. Exempel på tillfällen då det är problematiskt är vid liknande stavningar. Exempel på tillfällen då det inte är problematiskt är längre uppslag såsom exempelvis ordspråk, då anledningen kan vara skillnad i punktuation eller att man inte skrivit in den exakta ordalydelsen. Det finns ju ofta många varianter, så det är rimligt att slussa användaren vidare direkt. Det kan finnas kortare sidnamn som inte innebär problem att omdirigera med hård omdirigering. Ditt exempel med bosätta sig kan vara ett sådant exempel. Detta skulle kunna förtydligas i mallbeskrivningen/stilguiden. Andra formuleringar kan förstås också behöva filas lite på, det viktiga är ju att andemeningen kommer fram på ett lättfattligt sätt. ~ Dodde (diskussion) 22 november 2012 kl. 17.29 (CET)

Jag har skapat mallen {{ref-neo}}. Jag tänker att den förenklar och normaliserar referenser till Nationalencyklopedins ordbok. Vi kan lägga till motsvarande mallar för andra verk som refereras till ofta också. Vad tycker ni? //Skal 27 november 2012 kl. 12.07 (CET)

Är för idén, men hade gärna sett att den harmoniseras i valda delar med {{citat}}. Där används parametrarna år= och datum= annorlunda. titel= finns för uppslagsordet, utgivare= borde kunna finnas för en allmän användning av mallen. Om vi använder rubriken ==Källor== kanske {{källa}} är lämpligare än {{ref}} (eller om rubriken ska ändras till ==Referenser==. {{källa}} skulle vidare kunna vara för {{källa-neo}} vad {{Artikelursprung}} är för exempelvis {{enwp}}, {{nowp}} och {{Ugglan}} på Wikipedia (om du minns mallarna vi skapade för några år sedan). Ibland kan man behöva ange en länk till uppslagsordet, exempelvis om Språkrådet påstår något i sin frågelåda. Isåfall används parametern titel= i {{citat}} även till det. Möjligtvis är det nödvändigt att ha ett ställe att ge ytterligare en kommentar till informationen. ~ Dodde (diskussion) 27 november 2012 kl. 13.36 (CET)

• Jag är med på att döpa om "ref-" -> "källa-", trots att det blir lite längre.
• {{källa}}: {{ref-neo}} är i nuläget väldigt enkel och jag har svårt att se att den kommer bli mkt mer komplicerad. Men visst, om du tror att det är bättre.
• år= och datum= vs. 2=: Skillnaden är att man nog gärna anger datum för när man läst nåt på en webbsida. Eftersom mallen kommer användas inuti andra mallar ville jag hålla syntaxen så kort som möjligt, och eftersom poängen är att normalisera ser jag inte att det behövs så mkt variation. Eller tänker du att det är acceptabelt att endast ange vilket år man går in på en webbsida?

//Skal 27 november 2012 kl. 14.11 (CET)

Jag menar nog bara att man bör ta de saker jag skrev i beaktande. Precis som {{Enwp}} är en förenkling av {{Artikelursprung}} så kan {{källa-neo}} vara en förenkling. Det viktiga är att man inte ska behöva hålla reda på en massa olika syntaxregler beroende på vilken ordbok eller annan källa man väljer att hänvisa till, och att man då det finns behov av att hänvisa till en källa som det inte finns en specialmall för så ska man kunna använda den generella mallen {{källa}}. Kanske att man får kika på {{citat}} hur den är uppbyggd för att harmonisera {{källa}} lite med den, men liknande parameternamn osv., medan man får harmonisera de olika specialmallarna sinsemellan. Kanske numrerade parametrar 1=, 2= och 3= utöver de namngivna parametrarna är rimliga att använda. Kanske datum= som namngiven parameter borde bytas ut mot exempelvis läst= för att göra det tydligare och att inte blandas ihop med {{citat}}-mallens parameter datum=, men naturligtvis också då i specialmallarna som numrerad parameter. Men som sagt, man kanske får spåna lite i om olika typer av källor kanske har lite olika behov av parametrar innan vi klubbar syntax för {{källa}} och specialmallarna som utgår från den. ~ Dodde (diskussion) 27 november 2012 kl. 18.37 (CET)

Om vi vill göra en generisk {{källa}} så finns nog en poäng i att inte ha numrerade parametrar där, iaf om vi tänker att det inte bara är för ordboksskällor. Och det kanske är en vits med att kalla det läst= ist.f. 2= för tydlighetens skull, också i specialiserade mallar som källa-neo. {{källa-neo|kompis|läst=2012-11-27}} är inte för jobbigt, men jag vill inte byta ut 1=.

Vad finns det mer för källor? Några vanliga som vi använder är: SAOB, Språkrådets frågelåda och NE. Här skiljer sig nog främst Språkrådet, då det snarare är korta artiklar än uppslagsord, vilket gör att titel= kommer krävas och url= också. //Skal 28 november 2012 kl. 06.58 (CET)

En annan viktig källa är Hellquists etymologiska ordbok på Runeberg. Etymonline.com är en annan (engelsk) bra etymologiordbok. --Lundgren8 (d · b) 28 november 2012 kl. 09.27 (CET)

Svårt att veta nackdelar med numeriska parametrar i den generiska mallen förrän vi har fler exempel på specialmallar och om den generiska mallen behöver användas ofta, men absolut, kör på namngivna parametrar i den generiska mallen till att börja med. ~ Dodde (diskussion) 17 december 2012 kl. 20.06 (CET)

Det kanske är att gå händelserna i förväg, men apropå datum= tycker jag personligen att man i mallens dokumentation sedan bör påtala att datumen lämpligen skrivs ut i sin helhet (alltså "2 maj 2004"), precis som rekommenderas för källmallarna på Wikipedia och för all del av Språkrådet. Slutresultatet blir en tydligare och mer lättläst källförteckning än om datumen skrivs i ISO-format (alltså "2004-05-02"). –Tommy Kronkvist (diskussion), 19 december 2012 kl. 09.15 (CET).

Vet inte vad som blir bäst, men som sagt, om möjligt gärna att det harmoniseras med {{citat}} (som inte har någon av de ovan nämnda formaten). ~ Dodde (diskussion) 19 december 2012 kl. 22.47 (CET)

Jag har flyttat mallarna till källa-*. //Skal 19 januari 2014 kl. 17.27 (CET)

På engelska, danska och ryska Wiktionary gör jag, för de svenska uppslagsorden, flitigt bruk av länkar till SAOL och SAOB med mallar som da:Skabelon:SAOL och ru:Шаблон:SAOB. De ligger förstås i kategorier för externa länkmallar (da, en, ru). I jämförelse verkar svenska Wiktionary vara väldigt sparsam med källhänvisningar. --LA2 (diskussion) 8 april 2015 kl. 07.33 (CEST)

Som tidigare på Wikipedia, när man länkar till en källa som artikeln ursprungligen baserades på blev den snabbt inaktuell i takt med att sidan uppdaterades. För definitioner riskerar en markering med källa att cementera definitionen och göra den otillgänglig för förbättring och rimlig uppdelning mellan olika delbetydelser. För exempelmeningar försöker vi använda {{citat}} där källhänvisning kan anges och det uppmuntras även för etymologiska beskrivningar med {{etymologi}}. I övriga fall tycker jag att redigeringskommentaren är ett bra ställe att beskriva sin ändring eller diskussionssidan om det behövs en längre utläggning. ~ Dodde (diskussion) 8 april 2015 kl. 12.59 (CEST)

Hej! Jag tror inte att skit-, under- m.fl. räknas som affix i svenska grammatikor, utan helt enkelt som rotmorfem i sammansättningar. Dessutom förekommer rubriken Sammansättningar i uppslag om affix; förutom att affix utgörs av min morfemnamne, inte rötter, bildar de ju faktiskt avledningar, inte sammansättningar. Något av en begreppskrock här, med andra ord.

Jag tänkte börja med att ta bort uppslag som anger substantiv och andra solklara rotmorfem som affix, men föra över informationen om rotmorfemets vanliga funktion i sammansättningar (samt exempel) till rotmorfemets huvuduppslag, om det inte redan finns där.

Dock listas bl.a. under- som prefix även i engelska Wiktionary, och jag vill därför öppna upp för diskussion först. Finns det någon anledning att man kategoriserar (skenbara?) rötter som affix? Trevlig helg! --Restmorfem (diskussion) 11 januari 2013 kl. 21.05 (CET)

Nej, avsikten är att skilja på affix av olika slag (vilket nog framgår när man ser majoriteten av sidor som placerats i ex.vis Kategori:Svenska/Affix) å ena sidan och morfem som förekommer i sammansättningar å andra sidan. Dessa placerar vi under rubrikerna förled respektive efterled. Jag är ingen expert på området, och vissa gånger kan jag tycka att det är knepigt att dra en tydlig gräns. Jag håller dock med dig om "under-", så jag hade också valt att byta ut rubriken affix. Mot rubriken förled, eller kanske rentav flytta den till under med {{tagg|text=som förled i sammansättningar}} på definitionsraden. Jag tror inte det har diskuterats, men faktum är ju att självständiga ord ofta även kan fungera som förled i sammansättningar, så det ena utesluter ju inte det andra. Ibland förekommer ett ord endast som förled men aldrig självständigt, så rubriken förled som sådan är nödvändig att ha kvar e.m.m. och det man tror blir tydligast (eget uppslag på förledet, eller tillsammans med uppslaget utan avslutande "-") i det enskilda fallet är nog det bästa. Konstaterar att över- redan sedan innan använder rubriken förled. ~ Dodde (diskussion) 11 januari 2013 kl. 23.32 (CET)

Hej! Den mycket enkla åtskillnaden är att affix inte utgör självständiga ord. :) De ord i Kategori:Svenska/Affix som kan stå självständiga är därmed inte affix, utan rotmorfem. För- och efterled i sammansättningar är alltså rotmorfem, och bör istället ingå i uppslaget utan bindestreck. Jag vill inte heller kalla mig expert, men tack och lov är denna del av svensk grammatik relativt entydig. :) Jag rådfrågar en ny grammatika (2009), som anger att även prepositioner och verbpartiklar är rotmorfem i sammansättningar och inte affix i avledningar. (forts.)

Vill man skilja på svenska affix vore underkategorierna prefix (m. underkategorier), interfix/fogemorfem och suffix (m. underkategorier) något att fundera på. Men just nu finns det inte så många affix att dela in, och såhär spontant ser jag inte vilken nytta den specifika indelningen skulle göra. Bindestrecken anger ju redan effektivt om affixet sätts först, sist eller inuti ordet. (forts.)

Men precis som du säger så finns det tvetydiga fall, t.ex. när affix och rötter är homonyma och etymologiskt besläktade. Så det gäller att hålla ögonen öppna. Med detta i åtanke tänker jag mig att jag genomför "avaffixeringen" av rotmorfem nu, om ingen har några invändningar? Det gäller inte särskilt många ord i kategorin, och jag kan ange dem här efterhand, ifall eventuell fortsatt diskussion leder till ändringar. (forts.)

Förresten: Ah, så tillägget text= gör så att det man skriver i taggen inte anges som en kategori längst ner på uppslaget? Jag lär mig fortfarande. :) En annan nybörjargrej jag gjorde var att själv skapa sidor för böjningsformer, men jag hann bara med två ord innan jag läste någonstans att det arbetet är automatiserat. --Restmorfem (diskussion) 12 januari 2013 kl. 12.54 (CET)

Nu krockar mina grammatikor. Jag gör såhär: förstärkande förled som ap-, skit-, bajs- m.fl. behandlar jag istället som affix, som Wiktionary redan gör, oavsett vad någon grammatika säger. De har ingen direkt semantisk koppling till sitt motsvarande rotmorfem och fungerar alla som jätte-. Däremot finns det fortfarande en grupp ord kvar som inte är att betrakta som affix, exempelvis rena substantiv+substantiv-sammansättningar och verbpartiklar i fast förbindelse med sitt verb. Ändrar detta, och anger dem här så småningom. --Restmorfem (diskussion) 12 januari 2013 kl. 13.26 (CET)

dotter-, efter-, för- (för(e)-), huvud-, lusse-, rea-, under- är de uppslag som nu föreslagits för radering eller vars affixdefinition tagits bort; deras respektive huvudartiklar har vid behov kompletterats med sammansättningsdefinition och -exempel. --Restmorfem (diskussion) 12 januari 2013 kl. 14.33 (CET)

Då återstår det omfattande arbetet med att se till att sammansättningar kallas sammansättningar och att avledningar kallas avledningar i uppslagen. Jag ber om ursäkt om detta verkar tjatigt och något uppförstorat, men om terminologin inte används rätt blir den både urvattnad och överflödig, och kanske till och med ett hinder eller en orsak till förvirring. --Restmorfem (diskussion) 12 januari 2013 kl. 14.55 (CET)

Absolut inte, jättebra att du tar tag i detta! Återkommer med längre svar lite senare. ~ Dodde (diskussion) 12 januari 2013 kl. 21.07 (CET)

Exempel på förled (rotmorfem) som inte kan skrivas självständigt är e.m.m. universal- och hydro-. De förekommer bara som förled i sammansättningar, men jag skulle ändå inte kalla dem prefix. Det stämmer visserligen att affix inte utgör självständiga ord, men av det kan inte slutsatsen dras att alla "orddelar" som inte står/kan stå som självständiga ord därmed måste vara affix. I praktiken består ju alla sammansättningar av två ord just av ett förled och ett efterled. Det intressanta är de ord som endast kan fungera i sammansättningar men inte självständigt, som universal- och hydro- m.fl. Det knepiga är var informationen ska placeras när det finns olika betydelser eller betydelsevarianter med eller utan gemensam etymologi. Förleden på en egen sida, eller som del av uppslaget utan bindestreck (vars ord ju också kan fungera som förled). Den andra frågan som är knepig (nu när vi konstaterat att osjälvständiga ord inte automatiskt är affix) är hur mycket "egen betydelse" som krävs för att ett osjälvständigt ord ska gå från att vara affix till regelrätta för- eller efterled (rotmorfem). Ap-, skit- och jätte- skulle jag nog beteckna som förled och inte prefix. Och lättast att hitta vore de väl på huvuduppslagen apa, skit och jätte, tänker jag. För- i användningen fördela hade jag dock betecknat som prefix. Det är möjligt att under- också har en prefixbetydelse, lite osäker men tänker ex.vis på undergå ("företagets ekonomiska förehavanden undergår granskning"), men förled i ex.vis underminera, undervattenbåt, underexponering.

Angående rubriken affix har vi valt att ha för att undvika ha en alltför stor uppdelning och spridning av rubriker (och därmed kategorier). Vill man kan kan förtydliga vilken typ av affix det rör sig om på fetstilsraden, efter det fetstilade ordet, något som kanske känns överflödigt på grund av markeringen med bindestreck, så denna möjlighet är inget som används särskilt ofta.

Om text= i tagg-mallen: korrekt uppfattat :)

Vi använder inte rubriken (eller numera mallen) avledningar, eftersom det insinuerar vilket av de sinsemellan genom affix besläktade orden som är avledning till vilket (något som kan vara lite kruxigt att belägga) och det gör också att avledningarna bara kan listas i det ena uppslaget men inte det andra (eftersom avledningar bara sker åt ett håll. Istället är det "besläktade ord" som används, och med detta ordval avser vi avledningar åt båda hållen, alltså de ord som delar rotmorfem och bara skiljs åt genom sina tillagda eller borttagna affix. Bo, bebo, boende ska alltså listas under besläktade ord på alla tre uppslagen. På samma sätt för atom, atomär och atomisk. Ej under sammansättningar, alltså. Mvh ~ Dodde (diskussion) 12 januari 2013 kl. 23.55 (CET)

Hej igen! Led som inte kan stå ensamma, utan bara bär betydelse i sammansättningar (ofta bara i en enda sammansättning), och som inte är affix, analyseras ändå som rötter och kallas, liksom jag, restmorfem. Termen angavs fram till nyss i sitt uppslag som en synonym till fritt morfem, vilket är fel. :( Har under de senaste dagarna blandat ihop termerna i mitt lättförvirrade sinne pga detta. En kategori för restmorfem vore kanske på sin plats? Dock har jag bara sett termen restmorfem användas för äldre ord (det vanligaste exemplet kan vara körs- i körsbär). Men jag har å andra sidan aldrig hört eller sett det definieras som enbart gällande äldre ord, utan även nyare ord, med exempelvis hydro-, borde kunna anses innehålla restmorfem.

Jätte- betraktas som ett allmänt förstärkande avledningsprefix, och anledningen till att jag ändrade mig angående ap-, skit- och liknande är att de används just som jätte-; allmänt förstärkande, men helt utan att syfta till det ord det egentligen är eller från början var. Min grammatiklära från 2009 (färsk forskning) anger just jätte- och skit- som avledningsprefix, medger att de skulle kunna analyseras som rötter, men poängterar att de förlorat den semantiska kopplingen till jätte och skit. Därför fungerar oxymoroner som jätteliten och skitgod.

Håller med om att uppdelningen/spridningen bör hållas nere i fallet affix! Och om jag förstår dig rätt (lite slö nu) så låter även det bra, det om att ändå undvika rubriken Avledningar. Jag kan tänka mig att ordet otrohet är ett exempel på det du menar; man vill alltså undvika att antyda att vare sig otro eller trohet skulle ha bildats först?

--Restmorfem (diskussion) 13 januari 2013 kl. 01.03 (CET)

Men vad bra, då är det ingen tvekan om de förstärkande avledningsprefixen! Det belyser väl dock att det kan vara svårt att avgöra var gränsen går ibland. :) Det stämmer bra att vi vill undvika att antyda vilka ord som bildats först. Vet inte om just otrohet är det typiska exemplet, men hur kan man exempelvis veta om bad eller bada bildades först? Det kanske visst går att ta reda på, men det gör det betydligt mer tidsödande att lägga till länkar till besläktade ord, och risken blir då att vi får ett stort antal antydanden som riskerar att vara felaktiga. Felaktiga påståenden vill vi förstås minimera så långt det är möjligt, och kan det göras enkelt genom anammandet av en viss struktur så anser jag att det är en bra väg att gå. Ett annat exempel på ett sådant strukturellt ställningstagande är att vi av olika skäl aldrig påstår att vissa stavningar av vissa ord är felstavningar. Vi länkar istället till en stavning vi (eller relevant källa) påstår är korrekt. Angående att byta förled och efterled till restmorfem låter som ett bra förslag, men hur blir det då med förled och efterled som består av flera morfem? Jag tänker på förled som uni-versal-, sam-häll-s-, på-nytt-, till-handa- och kanske älsk-ling-s- och efterled som -dimension-ell, -vet-are, -mak-are, -ät-are. Även om enmorfemiga förled och efterled är bundna morfem, så är de väl ändå förled respektive efterled och om vi byter ut förled- och efterledrubriken mot restmorfem innebär det väl att flera uppslag faller mellan stolarna och inte kan placeras ut någonstans? Något vi vill undvika. Uppslagen rotmorfem, restmorfem, fritt morfem och bundet morfem behöver hur som helst förbättras lite. Om jag förstår saken rätt så är rotmorfem och restmorfem antonymer, precis som fritt och bundet morfem är antonymer. Rotmorfem är synonymt med fritt morfem och restmorfem synonymt med bundet morfem. Detta bör framgå tydligare. (För närvarande beskrivs restmorfem som "rotmorfem som endast är betydelsebärande i sammansättningar" vilket verkar motsägelsefullt, då rotmorfem per definition ensamt kan utgöra ett ord.) ~ Dodde (diskussion) 13 januari 2013 kl. 09.31 (CET)

Ja, visst är det sällan glasklart hur indelningarna ska göras. Det vittnar om att även grammatik, som ju kan verka så systematiserat och matematikartat, ofta är en ren tolkningsfråga. :)

Tanken om att sträva efter att undvika felaktiga antaganden, påståenden m.m. genom ett "less is more"-liknande tänk låter verkligen jättebra. Att uttrycka sig något vagare eller generellt kan ofta vara en tillgång, även om det klingar illa att kalla det "vagare"; besläktad är ickedestomindre bättre än avledd om man vill undvika påståenden utan grund.

Nja, restmorfem utgör egentligen en egen kategori. Trots att de inte fungerar som självständiga ord brukar de ändå analyseras som rötter, eftersom de delar fler egenskaper med rotmorfem än med affix (t.ex. en mycket snävare betydelse och användning än affixen har, i likhet med vanliga rotmorfem). (Dock når vi här poängen att Wiktionary nog inte är en plats för grammatisk analys, utan en ordbok; jag ändrar definitionen för restmorfem litegrann.)

De led du nämner är alltså inte restmorfem. Universal- är av språkhistoriska skäl förledsmotsvarigheten till universell; samhälls- är roten samhälle plus fogemorfem; pånytt- och tillhanda- är ihopskrivna adverbial i sammansättning; -dimensionell är roten dimension plus affix; -vetare, -makare och -ätare är rötterna veta, *maka och äta plus affixet -are ... Nu slog det mig att det var fullständigt i onödan jag skrev ner allt det här, när det ju är termen restmorfem vi definierar (och du varken bad om eller behövde lektion i ordbildning :)).

Angående ord som samhälle, makare och älskling är det nog inte högsta prioritet att Wiktionary ska innehålla mer historiska morfem som -hälle (torde vara besläktat med hålla?) och det ålderdomliga verbet maka i betydelsen "tillverka" - ändelsen -ling finns visst redan - även om det är intressant och inte sällan vackert ... Men nu går jag väl utanför ämnet för diskussionen ... :) --Restmorfem (diskussion) 13 januari 2013 kl. 12.01 (CET)

Okej, så morfem kan vara affix också, dvs. alla affix och restmorfem tillsammans tillhör gruppen bundna morfem. Fria morfem är visserligen alltid rotmorfem, i svenskan, men inte nödvändigtvis i andra språk, så begreppen är egentligen inte synonyma. Ett restmorfem kan inte vara ett rotmorfem, men är helt enkelt de bundna morfem som återstår då affixen plockats bort. Stämmer detta, nu då? :) Jag försöker bara förstå... ~ Dodde (diskussion) 13 januari 2013 kl. 16.41 (CET)

Nej, de är inte restmorfem, och det där var därför jag nämnde dem. :) Tar vi bort rubrikerna förled och efterled och ersätter dem med restmorfem hamnar dessa mellan stolarna. Förled och efterled å andra sidan är bredare och innesluter restmorfemen. Vad är dina tankar om det? Vi kan definiera rubrikerna förled och efterled och tydligare säga att det är restmorfemen och andra bundna flermorfemiga ord som inte är affix som är avsedda att användas med den rubriken. Att skapa ytterligare en rubrik vid sidan om förled och efterled tycker inte vi skulle vinna så mycket på, när restmorfemen ju även kan hänföras till grupperna förled och efterled. Alternativ hade vi kunnat använda restmorfem som rubrik, och i definitionen ange att vi även avser innesluta bundna flermorfemiga ord som inte är affix, med risk för att trampa över lite på sidan om att inte vara korrekta. ~ Dodde (diskussion) 13 januari 2013 kl. 16.41 (CET)

Det tycker jag låter bra. :) Visserligen blir definitionen negativ: restmorfem är inte affix och inte självständiga rotmorfem. Men det är å andra sidan svårt att skriva en entydigare definition på annat sätt. (Ett problem när man definierar restmorfem som en sorts bundna morfem kan vara att många kanske tänker "bundna morfem = affix". Men restmorfem är ju bundna.)

Då förstår jag! Jag tror att jag är lite väl fastkörd i min skolterminologi, men nu börjar det lossna lite. Men det enda av exemplen som skulle behöva en egen artikel är väl universal-, för att det är så olikt sitt motsvarande adjektiv. Men exempelvis samhälls- är ju egentligen bara ordet samhälle. Att -e försvinner och -s- läggs tills är kanske inte intuitivt för alla med svenska som främmande språk och de (och andra) kan ha nytta av separata uppslag som visar hur ord förändras i sammansättningar. Men dylikt kan ju framgå av ordet samhälles uppslag. Å andra sidan är ju Wiktionary en väldigt detaljerad ordbok, med exempelvis ett uppslag per grammatisk form ... Å tredje sidan är ju samhälls- varken avledning eller grammatisk form av samhälle, utan -s- ses ju mer som en fog mellan rötterna, och -e assimileras bort av fonologiska skäl snarare än morfologiska.

Det finns fog för flera åtgärder, även att ha kvar uppslag och indelningar som de är. :) --Restmorfem (diskussion) 14 januari 2013 kl. 17.43 (CET)

Tycker nog de flesta av mina nämnda "flermorfemiga" för-/efterled förtjänar ett eget uppslag. De må vara skapade ur sin rot eller sitt särskrivna adverb, men de är inte desto mindre orddelar som har en betydelse men som inte kan stå självständigt i förhållande till andra orddelar. Eftersom Wiktionary har den smått överdrivna målsättningen att ha med "alla ord på alla språk" så känns det rimligt att det ska existera en rubrik för dessa ord och att en grupp ord inte faller mellan stolarna i onödan. Det är också en struktur som ska fungera för alla språk, inte bara svenska. Därav rubriken Affix istället för Prefix som är det affix som nästan uteslutande används i svenskan. Det är möjligt att samhälls- bör flyttas till samhälle, har inte kikat närmare på det. Oavsett vilket kan parametern förled= användas för att ange hur ett ord skrivs ut när det används som förled i en sammansättning, med eller utan foge-s eller om annan ändring sker. Gata blir ex.vis gat- eller gatu-. ~ Dodde (diskussion) 14 januari 2013 kl. 19.39 (CET)

Sorry för detta wall-of-text-svar. :) Summan av kardemumman: Jag håller med! Men måste av någon anledning redogöra för varenda liten tanke och efterforskning.

De hade ju inte fallit mellan stolarna om de nämnts i eller framgått av ordets artikel. Men tänker man närmare på Wiktionarys utförlighet (antal uppslag per faktiskt ord) i övrigt verkar det naturligtvis rimligt att ha separata uppslag för ord som tar till fogemorfem som -u-, -s-, -e- (m fl?) och/eller ett uteblivet fonem i sammansättningar. Och då är för- och efterled lämpligare, generaliserande rubriker. Jag känner tydligt av min envisa tendens att visst vilja dela in enligt en mer detaljerad grammatisk terminologi, och det är väl det som har ställt till det lite i det här samtalet. :) Det du säger är naturligtvis betydligt mer användarvänligt.

Jag är nöjd bara den utgallrade gruppen rotmorfem inte listas som affix (dotter-, efter-, för- som assimilerad form av före, huvud-, lusse-, rea-, under-; jag har redan föreslagit radering, flyttat definitioner m.m.). Ska se över andra icke-affix i affixkategorin och lista dem som led. :)

Puh! Lärorik diskussion. --Restmorfem (diskussion) 15 januari 2013 kl. 14.44 (CET)

Kruxet med dessa diskussioner är att hur man än delar in morfem är indelningen alltid en påklistrad modell. Precis som att medeltida människor inte visste att de levde på medeltiden, vet ju inte ord att de tillhör en viss grupp eller klass. Det finns alltid fall där man reagerar och frågar sig om för- eller efterledet är tillräckligt betydelsespecifikt i sig för att räknas som led och inte affix, och ofta finns det inte heller slutgiltiga svar. :) --Restmorfem (diskussion) 15 januari 2013 kl. 15.19 (CET)

Nördspånar vidare bland termerna. Här definieras restmorfem mycket mer kärnfullt än jag lyckats med: bundna lexikala morfem. Rent semantiskt ett ord, men ordbildningsmässigt bundet. Denna korta definition kan vara till hjälp vid indelningen, eftersom affix inte är lexikala; dvs, om ett morfem lättast definieras utifrån sin funktion och inte sin betydelse, så är det förmodligen ett affix. Om -het och -ig säger man kanske "används för att bilda substantiv resp. adjektiv" medan t.ex. hydro- är semantiskt begränsat till vatten och, likt ett vanligt rotmorfem i en sammansättning, bara lägger till betydelse.

Förutom restmorfem eller bundet lexikalt morfem verkar det som att termen som på engelska lyder lexical affix kan syfta på samma sak (eller i alla fall något liknande): lexical affix definieras som morfem med rotfunktion och affixform. Dock tycker jag att man bör fortsätta undvika ordet "affix" när man talar om icke-affix, annars drabbas man (jag) lätt av begreppsförvirring. :) --Restmorfem (diskussion) 15 januari 2013 kl. 17.05 (CET)

Angående affix har jag inte heller där hittat en entydig definition. Det gemensamma för dem är att de antingen är kopplade till språkets grammatik (med funktionerna grammatisk böjning, ändring av ordklass, negation m.m.) eller semantiskt mycket allmänna eller ospecifika. Lingvisten David Crystal fyller i att de är få; han uppskattar antalet prefix i engelska språket till omkring 50 st. (Engelska och svenska är ju mycket lika ur ett internationellt perspektiv.) Om vi omsider ser detta i Wiktionarys kategorier, dvs om kategorierna för- och efterled innehåller många och betydelsespecifika morfem, och affixkategorin innehåller färre och semantiskt vagare morfem, så är vi nog på rätt spår. :) --Restmorfem (diskussion) 16 januari 2013 kl. 12.42 (CET)

(åter till marginalen)

Jättebra. Vi är helt överens om att det är önskvärt för Wiktionarys del att skilja på affix å ena sidan och "restmorfem" (inkl. flermorfemiga) å andra sidan (genom rubrikerna förled och efterled då, som konstaterat). Håller också med dig om att det i vissa fall blir "påklistrat". Det finns naturligtvis ibland flera aspekter att ta hänsyn till och de motsäger ibland varandra. Vad jag tänker är att den logik man använder sig av bör vara språkoberoende. Exempelvis är det kanske enklare att kalla adverb för "adjektiv i adverbial form" e.d., men då Wiktionary förutom ordbok är ett mångspråkigt lexikon tycker jag att man tar hänsyn till detta när vi definierar vad vi menar med rubriker osv. Utgångspunkten är att ett ord tillhörande en ordklass ska översättas med ett ord på det andra språket, men fortfarande tillhörande samma ordklass. Vi har stavningar och böjningsmönster som å ena sidan bör vara si av olika anledningar, å andra sidan så av andra anledningar. Då är det naturligtvis dumt att sätta sig till doms och utnämna det ena till helt korrekt och det andra helt felaktigt. Istället kan man lyfta fram aspekterna och förklara varför något kan anses vara korrekt enligt en aspekt, medan något annat kan anses vara (lika) korrekt enligt en annan aspekt. Något kan anses vara korrekt för att det är så pass vanligt, något annat för att det följer gängse språkregler, och ett tredje för att det kan härledas ur ett lånord t.ex. Så, för denna diskussionen, var går gränsen mellan affix och icke-affix. Jag tyckte mig se för mycket av betydelse i skit- och jätte-, men du hade å andra sidan en källa som kallar dem just affix. Det handlar väl mer om konvention än om rätt och fel. Och finns en bra konvention att utgå ifrån så gör det ju saken lättare om det inte finns någon anledning att frångå den. :) Ja, "bundna lexikala morfem" lät kärnfullt och bra! Tycker dock att det är den betydelsen vi har konstaterat redan innan, om än inte alls så kärnfullt... Ang. engelskans "lexical affix" gör det kanske lämpligt och det förklarar kanske engelskans val att placera under- under rubriken "affix". Med de termer vi använder är dock förledsrubriken lämpligare - även för det engelska förledet (lexikala affixet) under-. Det kanske finns(?) motsvarande begrepp på svenska, "lexikala affix"? Jag är dock benägen att, som du, skilja på affix och lexikala affix (om det begreppet nu är användbart i svenskan). OM det är användbart i svenskan, skulle dock, antar jag, förled respektive efterled som rubriker kunna ersättas med rubriken "lexikalt affix". Men för det krävs väl vidare efterforskning, isåfall. En liten fundering jag har är enhetsprefix (som de väl faktiskt brukar kallas), i dess förkortade (k-, m-, h-) och utskrivna variant (kilo-, milli-, hekto-) - hur tänker du om rubriksättningen där? I semantiskt perspektiv är de väl inte affix, eller? ~ Dodde (diskussion) 17 januari 2013 kl. 06.44 (CET)

Det var märkligt att hitta den här diskussionen nu, efter att jag här om dagen tog initiativet till en:Wiktionary:Beer parlour#Subcategories for compounds by component, som just är det motsatta: Att införa kategorier för sammansättningar liknande dem som finns för prefix och suffix. Se en:Category:Swedish compounds with maskin. --LA2 (diskussion) 24 januari 2013 kl. 14.24 (CET)

Att rinna är ett verb och presensparticipformen rinnande är en verbform, men också ett (oböjbart) adjektiv. I Wiktionary brukar ord som rinnande rubriceras som adjektiv och deras bakgrund som verbform anges i etymologi-avsnittet. Att söka är ett verb och presensparticipformen sökande är en verbform. Men är det också ett substantiv? Man säger ju gärna en sökande, många sökande. Det är lika oböjbart som substantiv som det är som adjektiv. Just ordet sökande har rubricerats som substantiv. Men om sökande är ett substantiv, varför är då inte rinnande, gul och andra adjektiv också substantiv? Var dras gränsen? Kan man formulera språkexempel där det framgår om ett adjektiv också är ett substantiv? --LA2 (diskussion) 22 april 2013 kl. 10.23 (CEST)

Om jag ska spåna lite så skulle nog säga att

1. Så länge som adjektivet beskriver en människa/person, så kan man ofta utelämna ordet person (el. motsvarande) och istället betrakta adjektivet som substantiv (en sökande, en glad, en vit, en svart - och när det gäller färgerna så får man väl säga att oavsett vad man tycker om bruket, så används det/har det använts om människor just på det här viset.)
   Dock är dessa substantiv bara oböjliga om de härstammar från presensparticip (jfr. Jag vill lära känna den glada lite närmare, De två långa därborta...). I vissa fall blir det ovant (en skrivande?) men jag vet inte om de ska betraktas som icke-existerande.
   Frågan är till vilken grad dessa bör betraktas som självständiga ord. Definitionen känns lite formulaisk: person som <verb> alt. person som är <adjektiv>.
2. Om ett presensparticip beskriver en process blir det ett neutralt substantiv (skrivandet, gåendet, rinnandet(?), porlandet, ..). Återigen verkar vissa ligga sämre på tungan (även om just 'rinnandet' dyker upp i enstaka sökmotorträffar, bl.a. i samband med snusning och medicin). Finns här någon grupp av undantag, med presensparticip som aldrig används som substantiv?

\Mike 26 maj 2013 kl. 18.30 (CEST)

Det "rinnande" som betraktas som verbform respektive adjektiv är samma ord, det som skiljer är vilka aspekter man väljer ska väga tyngst i klassificeringen. Syntaktiskt fungerar de som adjektiv, och det är därför de presenteras på det sättet här på Wiktionary (det nära släktskapet gör dock att de tas med i grammatiktabellen för verbet).

De allra flesta av dessa ord (presensparticipen) kan också anta substantivisk form, och får då en sorts automatisk betydelse i likhet med den adjektiviska betydelsen. I princip skulle varje uppslag för presensparticipen kunna ha både en adjektiv-rubrik och en substantiv-rubrik, men osäkert om detta kan/bör ske automatiskt. Manuellt har det gjorts för ett fåtal ord. Särskilt sådana där substantiveringen fått en utökad betydelse (resande, studerande osv). Substantivisk användning kan ibland kännas konstlad, och i praktiken sakna relevanta träffar som styrker användning. Man kan få fundera en bra stund på en situation då ordet i substantivisk betydelse skulle kunna användas med en faktisk och korrekt betydelse.

Sökande (och andra presensparticip) som substantiv är inte oböjliga. För person-betydelsen är det sökande(s), sökanden(s), sökande(s), sökandena(s). För den impersonella betydelsen (oräknebar) är det sökande(s), sökandet(s), som i exempelvis "Sökande efter bortsprungna katter prioriteras inte av Polisen. Sökandet efter flickan pågick länge. Polisen ställde sig tveksam till sökandets effektivitet. osv". Rinnande är ett exempel på ord som man får fundera på en stund. Mike skriver om processer, det kanske är begränsat till det. Jag vet inte. "Ögonens rinnande avtog efter en stund", är ett språkexempel på substantivisk användning iallafall.

För att den substantiviska formen ska tas med, tycker jag att det ska kunna motiveras med ett språkexempel som känns rimligt och inte alltför konstlat, i de fall man kan förvänta sig att någon skulle ifrågasätta ordets existens. Därför blir det svårt att göra detta automatiskt. person som <verb> alt. person som är <adjektiv>, som Mike nämner är formuleringar jag vänder mig emot, åtminstone om språkexempel inte kan ges som verkligen bekräftar just den betydelsen som anges.

Vad gäller frågan om alla adjektiv kan uttryckas som substantiv är jag tveksam. Men jag har inte gjort någon djupdykning i den saken, så jag vet inte säkert.

När det gäller rena uteslutningar av ord, som exempelvis "Jag vill ha två äpplen, ett rött (äpple) och ett grönt (äpple)." är jag tveksam till att inkludera dessa som substantiv i Wiktionary, annat än då de fått en utökad betydelse (de vise, de äldre, de svarta). Gränsen (för inkludering i Wiktionary) tycker jag ska dras just där.

Färgord anses normalt sett vara adjektiv, men de kan vara substantiv också. Klassificeringen av färgord är dock inte alltid helt enkel. Ett försök har gjorts på blodröd, blodrött med diskussion, men vi har inte kommit i land med den frågan ännu. ~ Dodde (diskussion) 28 maj 2013 kl. 08.31 (CEST)

Jag är ingen tekniker, men prövade mig på att skapa {{test-bokstav}} som kan infoga en del andra representationer av bokstäver till Appendix-sidorna för varianter, t.ex. Appendix:Varianter/g som för närvarande använder sig av testmallen. Skulle det kunna vara nåt? Jag ser att teckenspråk skulle vara högst relevant att få med i den här mallen, men att det saknas media för den bokstavering på svenskt teckenspråk. Dess utom vet jag inte om vi behandlar amerikanskt teckenspråk på sv.wiktionary eller ej. Gör vi det? Ni kan väl kommentera ifall ni tycker nåt känns överflödigt (även om all info bör finnas med på wiktionary) eller om något saknas, t.ex. brittiskt teckenspråk som jag hittills uteslutit. Jag behöver någons hjälp också med hur man ska få in länken till teckenspråk, för vi använder ju inte mallen term som engelska wiktionary har. ╰ Svenji 29 maj 2013 kl. 20.04 (CEST)

Frågan om amerikanskt teckenspråk. Nja, inte än iallafall, tycker jag. Vi hanterar inte ens svenskt teckenspråk för tillfället. Ska svenskt teckenspråk redovisas som en underrubrik e.d. i svenska avsnitt, eller ska de redovisas under egna rubriker (==Teckenspråk (Svenska)==?) och vad ska sidnamnet i så fall döpas till? Om fler teckenspråk ska tas med måste det dessutom bestämmas hur varje sådant språk ska skrivas i form av sidnamn. Jag lutar åt att det måste vara enklast och mest användbart för användaren om svenska teckenspråkstecken presenteras som en underrubrik (e.d.!) i det svenska avsnittet. Det gör det möjligt att även lägga till ex-vis amerikanskt teckenspråk under ==Engelska==. Men, stukturen behöver nog diskuteras igenom och någon som kan formge sådana mallar att de smidigt, lagom tydligt och lagom diskret kan placeras på sidorna behövs isåfall också. När det gäller appendixen tycker jag att det finns anledningar att vara friare vad gäller inkludering, så länge relevansen är tillräckligt god och kvaliteten håller tillräckligt god nivå. Vad gäller teckenspråksmedier finns ett intresse att sprida teckenspråket genom spreadthesign.com och det har åtminstone tidigare talats om att släppa teckenspråksvideor under en Wiktionary-kompatibel licens. ~ Dodde (diskussion) 7 juli 2013 kl. 02.30 (CEST)

Skulle det finnas någon fördel med att placera t.ex. svenskt teckenspråk under samma rubrik som svenska? Teckenspråk och talade språk är olika, med olika grammatik och ordförråd, och även om tecknade språk påverkas av talade, så är påverkan uppenbarligen inte så stor att ASL skulle närmat sig BSL (amerikanskt respektive brittiskt teckenspråk) från dess franska ursprung (jepp, större likheter mellan franskt och amerikanskt än mellan brittiskt och amerikanskt). Så min uppfattning är att man inte bör blanda teckenspråk med talade språk.

När det gäller språkrubriker, varför inte bara kalla dem ==Svenskt teckenspråk== och motsvarande? (Finns vedertagna förkortningar i stil med ASL för alla teckenspråk? Hittade någonstans att svenskt teckenspråk förkortas "STS"). Anledningen till att jag inte vill ha "svenskt teckenspråk" under svenska, eller "amerikanskt teckenspråk" under engelska är flera:

1. Det ligger bland annat i att en stor andel av de som använder ASL inte bor i engelsk-språkiga områden (jfr https://en.wikipedia.orgview_image.php?q=Wiktionary:Bybrunnen/Arkiv20&sq=Wiktionary:Bybrunnen/Arkiv20&lang=sv&file=File:ASL_map_%28world%29.png ). Jämför också med norskt teckenspråk där mindre än 10% av de som tecknar norskt bor i norsk-talande områden: resten bor på Madagaskar - så ska norskt teckenspråk läggas under franska, malagassiska, eller norska? ;) (Notera att inte heller alla teckenspråk refererar till något talat språk/något land: det finns bland annat ett som (på engelska) heter "Lyons sign language").
2. Det finns inga svenska ord, vars skrivna form också är ett ord i en skriven form av svenskt teckenspråk. I bästa fall skulle vi kunna, till ett teckenspråkstecken, kunna använda en svensk definition/översättning som titel - men vi använder ju inte sidtiteln samhälle, förening, sällskap, utan vi använder titeln society. Varför göra det annorlunda för teckenspråk? Visst, på något vis måste teckenspråken skrivas ned för att forma en titel (engelska har den fördelen att det finns en väletablerad ortografi), vilket jag inte vet om det finns för alla teckenspråk.

Så i korthet tror jag att det enklaste är att frikoppla teckenspråken och de talade språken, och jag vet inte om det finns någon poäng med att förbjuda införande av andra teckenspråk än svenskt, om det finns folk som vill arbeta på dem...

Intressant fråga om släktskap och likheter, med tanke på att det är ett helt eget språkträd som växt fram parallellt med de talade språkträden, men också fått influenser av talade språk... Jag behöver läsa på mer! (Tyvärr känns wikipedias artiklar som en smula motsägelsefulla i vissa detaljer.) \Mike 10 juli 2013 kl. 13.30 (CEST)

Vi har under en tid gått från H4-rubriker såsom ====Synonymer==== till att ange dem med en enkel mall {{synonymer}} - och vi har gjort motsvarande för {{jämför}}, {{etymologi}} m.fl. Den enda H4-rubriken som vi har lämnat är ====Översättningar==== och ====Se även====, och den sistnämnda antagligen bara för att {{se även}} redan används till annat (högst upp på sidan).

Nu såg jag att Svenji använde {{se även}} invid definitionen, så jag tänkte att det kan vara värt att ta upp. Med den här diskussionen skulle jag vilja ersätta ====Se även==== med en mall invid definitionen. Temporärt skapade jag {{seäven}} att användas invid definitionen.

Vad tycker ni? För att lättare kunna diskutera olika förslag har jag lagt till tre alternativ nedan:

1. Ändra inget. ====Synonymer==== är bra; använd {{se även}} högst upp på sidan.
2. Behåll {{se även}} högst upp på sidan; använd t.ex. {{seäven}} invid definitionen.
3. Döp om {{se även}} t.ex. till {{sä}}; använd {{se även}} invid definitionen.

//Skal 23 oktober 2013 kl. 20.50 (CEST)

Jag gjorde det utan att reflektera över att det inte fanns en mall för den rubriken, men jag ser inte varför se även-rubriken skulle fasas ut bara för att det finns en mall med samma namn. Bra, och tack! ╰ Svenji 23 oktober 2013 kl. 22.13 (CEST)

Motiveringen för att fasa ut dom andra rubrikerna var att dom hamnar för långt bort från definitionen, så att det blir svårt att se vad som hör vart. Där {se även} hjälper invid definitionen, som i andrahandskontrakt, finns ingen anledning att använda ====Se även====. I vissa fall är rubriken enklare att hantera - framförallt där det finns mkt innehåll (oftare aktuellt för Etymologi och Användning). //Skal 24 oktober 2013 kl. 07.27 (CEST)

Jag har länge varit ganska neutral till utfasningen av H4-rubrikerna, men jag har märkt att översikten blir sämre på en del uppslag och att texten känns ihoptryckt och att det inte blir lika lättläst. Det gäller särskilt när det är flera definitioner och mallar under varje def. En mall som jag gillar är {{jämför}}, men i stort är jag ganska tveksam till den här utvecklingen.

Kommer inte på något riktigt skräckexempel just nu, men se sammansättningarna i skola. Visst att man kan göra undantag för ord med riktigt många sammansättningar, men det är bättre med en struktur som funkar att använda konsekvent i alla uppslag. /Jiiimooh » DISKUSSION – BIDRAG 24 oktober 2013 kl. 16.06 (CEST)

Jag tycker att i dom fall där det blir väldigt mkt innehåll kan få finnas som rubrik, men när det bara är någon rad kan det finnas invid rubriken. //Skal 24 oktober 2013 kl. 21.39 (CEST)

Engelskspråkiga Wiktionary har gått över till att inte visa interwikilänkar i översättningar där Wiktionaryupplagan saknar uppslag. Med {{t}} visar dom alltså bara en intern länk, och med {{t+}} visar dom både intern länk och en interwikilänk.

Dom röda interwikilänkarna - med {{ö-}} - fyller egentligen ingen funktion. Det blir inte särskilt mkt lättare att skapa uppslag på den wikin, och om man planerar att skapa ett så kan man lika gärna börja med {{ö}} direkt. Dessutom blir det mer enhetligt/lättare att hantera språk som saknar Wiktionaryupplaga - dom kommer kunna använda samma syntax och ange språkkod.

Vidare föreslår jag att liksom en-wikt gå över till att använda {ö} och {ö+} ist.f. {ö-} och {ö}. Det här är alltså två förslag:

1. Ta bort röd interwikilänk när uppslag inte finns
2. Ändra namn på mallarna: {{ö}}→{ö+} och {{ö-}}→{ö}

Vad tycker ni? //Skal 5 november 2013 kl. 10.29 (CET)

När jag skriver en artikel på en.wiktionary lägger jag in {t} och sedan är det en bot som ändrar till {t+} om det finns en översatt artikel. Jag själv kollar inte det. Men är en likadan bot aktiv på sv.wiktionary? --LA2 (diskussion) 11 november 2013 kl. 16.13 (CET)

Det var Skalbot som fixade det för länge sedan, men nu har den inte varit igång på mkt länge. Jag tänkte att det kan vara en bra idé att bestämma hur vi gör med {ö} och {ö+} innan jag gör storskaliga ändringar med bot.

Förändringarna jag föreslår här är för att synkronisera vårt system med en-wikts - dels är det bra att ha liknande system, dels så är det här en snyggare lösning. //Skal 11 november 2013 kl. 18.10 (CET)

Om ingen säger något inom en vecka så tolkar jag tystnaden som att förslaget accepteras och kommer 1) ta bort röd interwikilänk, 2) ändra namn på mallarna {ö}>{ö+} och {ö-}>{ö}, och 3) med bot gå igenom alla uppslag och korrigera användning. //Skal 19 november 2013 kl. 08.27 (CET)

Jag har tjuvstartat lite. Kika gärna på Skalbots ändringar för att se hur det blir. //Skal 21 november 2013 kl. 16.41 (CET)

Jag har nu ändrat i {{ö}} och börjat köra boten. Men jag granskar de flesta av botens ändringar, så det går ganska långsamt. //Skal 25 november 2013 kl. 14.29 (CET)

Det var mer manuellt arbete än vad jag hoppats på. Uppslag från A till D är iaf fixade nu. //Skal 26 november 2013 kl. 15.31 (CET)

Nu är alla uppslag fixade! Jag tror inte att boten har gjort några fel, men om ni märker nåt, säg till. //Skal 28 november 2013 kl. 13.58 (CET)

Eftersom inga uppslag använder {ö-} längre så har jag raderat mallen! Nu är vi i den nya världen med bara {{ö}} och {{ö+}}. //Skal 29 november 2013 kl. 22.35 (CET)

Vi fortsätter att skriva artiklar i samma jämna takt. Svenska Wiktionary fortsätter att vara den 9:e största. Jag fortsätter att scanna ordböcker i Projekt Runeberg, nu senast Ord för ord. Men berget av inscannat ordboksmaterial som ännu inte har blivit inlagt i Wiktionary fortsätter att växa. Här är jag lite förvånad: Borde vi inte, med hjälp av Internet, robotar och allsköns datormagi kunna hitta på något snabbt sätt att tolka och omvandla det inscannade materialet till färdigformaterade Wiktionary-artiklar? Det är ett område där jag hade förväntat mig nya upptäckter, nya algoritmer, nya språng i teknikutvecklingen. Men jag väntar ännu. --LA2 (diskussion) 12 november 2013 kl. 14.39 (CET)

Grejen är väl att även inskannat material kräver en hel del arbete. Vidare har vi vissa minimikriterier (språk+ordklass+definition) och om en källa saknar något av det måste det anges manuellt (Ord för ord verkar sakna ordklass). Och förstås kan man inte ersätta existerande definitioner med nya.

Jag kan bistå med visst skriptande, men kommer inte lägga ner så mkt tid på korrekturläsning och komplettering av information. Vilka ordböcker ser du störst potential för? Tror du att det skulle finnas ett värde att presentera informationen på något sätt utanför vår vanliga struktur? Vad och hur? Har du förslag på hur man enkelt kan involvera fler? //Skal 12 november 2013 kl. 15.21 (CET)

Jag anklagar ingen för lättja. Men ärligt talat, det scriptande som både du och jag klarar är väl i stort sett samma scriptande som vi gjorde för fem år sedan, år 2008? Har det egentligen skett några radikala tekniska framsteg på vårt område, att wiki-koda existerande kunskap? --LA2 (diskussion) 12 november 2013 kl. 16.16 (CET)

I stället för Mediawikis API (läs artikel, skapa artikel, redigera artikeltext) kunde vi ju t.ex. skapa ett Wiktionary-API där operationerna i stället är

• För språket X och ordet Y, vilka definitioner finns och vilka synonymer finns till varje definition?
• För ordet X, lägg till synonymen Y.

Det vore ett steg framåt. Finns det något sådant redan? --LA2 (diskussion) 12 november 2013 kl. 16.35 (CET)

Menar du programtekniskt API? Det enda stället där det där finns strukturerat tror jag är det internationella OmegaWiki. Det är trivialt att skapa API:et "för språk X och ord Y, ge definitioner + synonymer". För att lägga till en synonym måste du specifiera också vilken definition. Men jag ser inte värdet i det.

Däremot skulle det vara möjligt att lägga till definitioner och lägga till synonymer till ett uppslag utan behöva se någon wikitext (precis som jag nu experimenterar med att lägga till översättningar utan att se wikitext).

Wikidata är ett radikalt tekniskt framsteg, men det är långt kvar till dess att det kan användas av Wiktionary, och inte ens då är det säkert att data från existerande ordböcker platsar där.

Här är ett sätt att snabbt få in jättemycket information på Wiktionary utan att förstöra dom existerande uppslagen:

1. Låt varje uppslag ha ett avsnitt längst ner med "extern information"
2. Importera allting från ett flertal olika källor och lägg det i mallar i det där avsnittet (t.ex. {{externt-ordförord|sida=9|<definition och/eller synonymer>}})
3. Ha ett JavaScript som extraherar information från det avsnittet och sätter in den på lämpligt ställe, men markerat så att det tydligt framgår att det inte ingår i det ordinarie uppslaget. Sedan finns knappar för att ta bort, inkorporera eller lägga till informationen till uppslaget (och därmed också ta bort ur externt-avsnittet).

//Skal 12 november 2013 kl. 16.56 (CET)

Detta låter lovande, om vi fick Ord för ord inkorporerat skulle svwikt bli i det närmaste heltäckande. Jag är gärna med på ett hörn i projektet. Jag funderar på om man kan göra något mer än bara OCR på de inscannade bilderna för att automatiskt identifiera var definitionerna börjar och märka upp uppslagsorden. Jag gjorde något liknande för en kinesisk-engelsk frasbok med PythonMagick för inte så länge sedan. Fiskjuice (diskussion) 13 november 2013 kl. 22.46 (CET)

Innan något sånt kan ske måste åtminstone uppslagsorden märkas upp på något sätt, vilket kan bli arbetssamt då inte OCR tydligen inte känner av fetstilta tecken... Och Runeberg verkar inte ha någon möjlighet att bara märka upp delar av en sida. //Skal 15 november 2013 kl. 13.53 (CET)

Du kan ladda hem (via download-länken i sidfoten) både OCR-texten för att undersöka den och bilderna för att göra egen OCR, så slipper du i alla fall att scanna boken själv. Kanske räcker det att söka efter ord som inleder en rad och som kommer i bokstavsföljd, för att känna igen uppslagsorden i en ordbok? Men OCR-felen försvinner förstås inte förrän man gjort fullständig korrekturläsning. I just Ord för ord är det många "l." (eller) som blivit 1. (siffran ett). --LA2 (diskussion) 16 november 2013 kl. 04.33 (CET)

Några av uppslagsorden står fetstilta mitt i texten (om det är klart avlett tror jag). Jag kan inget om OCR och har nog inte bättre verktyg till hands. Angående l. och 1. - varför ändrar du inte det automatiskt i hela boken? Och samma angående att göra ord i bokstavsordning i början på en rad fetstilta... Det blir bättre än ingen korrekturläsning och gör att det krävs mindre manuellt arbete. //Skal 16 november 2013 kl. 08.19 (CET)

Sådana automatiska rättningar blir alltid osäkra och kräver mycket manuell granskning som tar tid, samtidigt som de ger intrycket av att sidan är korrekturläst, vilket den ju ännu inte är. Jag följer hellre samma enkla arbetsschema för alla slags böcker, och överlåter all korrekturläsning åt frivilliga. --LA2 (diskussion) 20 november 2013 kl. 18.25 (CET)

Varför skulle det ge intryck av att sidan är korrekturläst? Man behöver väl inte markera den som sådan? Tanken är att underlätta för dom som faktiskt granskar manuellt - det går snabbare om man inte behöver göra ändringar. Aja... jag ska inte lägga mig i Runebergs arbetssätt. //Skal 20 november 2013 kl. 19.10 (CET)

I händelse av att reellt behov uppstår anmäler sig undertecknad – som nyttjar manuella granskningsmetoder – härmed som frivillig korrekturläsare. Det vore förstås bra om det på något vis framgår vilka uppslag som är inlästa på detta vis och därför (kanske) behöver korrekturläsas. Den saken torde gå att åtgärda ganska enkelt, exempelvis med hjälp av automatisk kategorisering av sådant inläst material (samt därpå följande manuell omkategorisering när korren är klar). –Tommy Kronkvist (diskussion), 21 november 2013 kl. 18.32 (CET).

Jag föreslår att vi fortsätter diskussionen på Wiktionarydiskussion:Projekt/Ord för ord. Jag har importerat över 10 sidor som gärna får korrekturläsas. Om det funkar bra med de första 10 sidorna så kan jag enkelt importera över resten också. //Skal 21 november 2013 kl. 18.46 (CET)

Några av er har provat på verktyget för att enkelt lägga till översättningar utan att gå in i redigeringsläget. Det verkar inte som om någon har stött på några större problem, så jag tänkte att det kanske är dags att aktivera det för alla användare som standard.

För att testa verktyget går man till Inställningar->Finesser och väljer "Lägg till översättningar direkt".

Har någon några kommentarer, synpunkter eller önskemål? Om inte så tolkar jag tystnaden som acceptans och kommer aktivera det som standard för alla användare, inkl. oinloggade, inom en vecka. //Skal 30 november 2013 kl. 20.49 (CET)

Jag har utökat verktyget så att man också kan lägga till helt nya översättningsavsnitt. Det är dock inte en del av originalskriptet och man aktiverar den funktionaliteten separat (också via Inställningar->Finesser).

Eftersom ingen mer än jag har testat det hittils kommer jag inte aktivera i detta första steg. På lördag är det alltså bara den första delen som kommer aktiveras. //Skal 5 december 2013 kl. 14.45 (CET)

Sådär. Nu är den första delen aktiverad för alla användare, inkl. oinloggade. Om man av någon anledning ogillar dom så kan man avaktivera det i sina inställningar. Som alltid, säg till om ni har synpunkter! //Skal 7 december 2013 kl. 13.31 (CET)

För närvarande är bara funktionen för att lägga till översättningar till existerande översättningsavsnitt aktiverad. Jag har gjort ett litet tillägg så att man också kan lägga till helt nya översättningsavsnitt och jag tänkte aktivera det om ingen har något emot det.

För att testa tillägget går man till Inställningar->Finesser och väljer "Lägg också till nytt översättningsavsnitt direkt".

Har någon några kommentarer, synpunkter eller önskemål? Om inte så tolkar jag tystnaden som acceptans och kommer aktivera det som standard för alla användare, inkl. oinloggade, inom en vecka. //Skal 12 december 2013 kl. 11.20 (CET)

Jag har just aktiverat funktionen för att lägga till hela översättningsavsnittet direkt för alla användare. Hoppas att det kommer till användning! //Skal 19 december 2013 kl. 16.57 (CET)

Hur böjs ordet chaparral? 83.233.110.64 20 december 2013 kl. 14.59 (CET)

Växtlighetstypen är utrum, dvs. den chaparralen , och förekommer knappast i plural. Bilmodellen, och båtmodellen, har en pluralform chaparaller. \Mike 20 december 2013 kl. 15.35 (CET)

...har uppdaterats igen, för ungefär två veckor sedan. Under flera år hette det att den sidan inte skulle komma att uppdateras igen - vi får väl se hur ofta det kommer ske nu. \Mike 30 december 2013 kl. 16.11 (CET)

I Internet Explorer 11 (Windows 7 Home Premium, 64-bit) är det inte möjligt att med hjälp av skriptet ändra översättningsrubriker. Det vore bra om skriptets utvecklare kunde ordna det. --Andreas Rejbrand (diskussion) 1 januari 2014 kl. 00.41 (CET)

Jag har inte haft möjlighet att testa i ie11 än. Förhoppningsvis kan jag göra det inom ett par veckor, men om du förklarar vad som händer eller ger felmeddelandet, kanske jag kan fixa det snabbare. //Skal 1 januari 2014 kl. 03.07 (CET)

Det händer ingenting när man trycker på länken. --Andreas Rejbrand (diskussion) 1 januari 2014 kl. 12.31 (CET)

Jo, nu minns jag: Texten "Laddar..." kommer upp i en tredjedels sekund, varefter den försvinner och allt ser ut som innan man tryckte på länken. --Andreas Rejbrand (diskussion) 1 januari 2014 kl. 12.32 (CET)

Det verkar fungera i IE10 nu, så jag antar att detsamma gäller IE11 (och tidigare versioner också). Jag har inte prövat att spara, men det ser ut som om det kommer att fungera. //Skal 10 januari 2014 kl. 22.30 (CET)

Provade inte heller att spara, men allt annat fungerar i alla fall nu. --Andreas Rejbrand (diskussion) 10 januari 2014 kl. 22.35 (CET)

Angående den här ändringen: är det inte underförstått att all information om ordet (inklusive översättningar) finns på huvuduppslaget? --Andreas Rejbrand (diskussion) 2 januari 2014 kl. 12.54 (CET)

@Pametzma, det här gäller din redigering.

Jo, jag tycker att det är underförstått när det är fråga om en ren stavningsvariant och det bara finns en enda definition. För andra synonymer eller om det finns flera definitioner så föreslår jag att vi använder {{ö-se}}, liksom en-wikts en:Template:trans-see. //Skal 3 januari 2014 kl. 15.51 (CET)

Jag medger att det egentligen inte var onödig att sätta en egen länk för översättningen. Men på alla (Svenska) uppslag uppvisas följande klickbar text "Lägg till översättningar..." om det inte finns någon översättning. Jag föreslår att mallen som står bakom knappen inte sätts på sådana uppslag som vanligtvis inte behöver översättningat (t. ex. böjningsuppslag och variantuppslag som i det här fallet). --Pametzma (diskussion) 3 januari 2014 kl. 17.44 (CET)

@Pametzma, du har helt rätt. Om det bara finns böjningsformer på sidan så visas inte "Lägg till översättningar...", men det finns inget perfekt sätt att detektera variantuppslag.

Jag skulle däremot kunna försöka kolla om den första eller andra kursiva taggen innehåller ett ord "variant" eller "stavningsvariant" och i så fall inte visa det... Ska försöka fixa det någon gång nästa vecka. //Skal 7 januari 2014 kl. 23.43 (CET)

Detta är mer eller mindre fixat. Om "variant av" eller "stavningsvariant av" förekommer i den första kursiva taggen så visas inte "Lägg till översättningar", men om man t.ex. har {{tagg|ålderdomligt}} så blir den förvirrad och erbjuder att lägga till översättningar. Jag tror inte att det är ett tillräckligt stort problem för att orka göra något åt nu iaf. //Skal 8 januari 2014 kl. 14.29 (CET)

Jag tycker att Unicode är bland det bästa människan uppfunnit. Bra, nu fick jag det ur mig.

Tyvärr är de flesta datoranvändare (enligt mig) på tok för okunniga om det. Till exempel vet ju många inte hur man infogar allmänna Unicode-tecken i oformaterad text. "Nästan inga" tecken finns ju på tangentbordet, och t.ex. Windows EDIT-kontroller saknar ju metod för att infoga godtyckliga tecken. Detta yttrar sig bland annat i att folk inte använder de tecken de behöver (utan förklarar i prosa vilket tecken de egentligen ville ha, eller använder någon kombination av vanliga tecken, såsom oo i stället för ∞).

Behovet att använda tecken som inte finns på tangentbordet är ofta påträngande. Tidigare i dag skrev jag t.ex. ≝ {x ∈ ℝ: a ≤ x ≤ b} på StackOverflow.

En annan manifestation av folks okunskap om Unicode är att de använder fel tecken. Till exempel har jag flera gånger sett att folk använder upphöjda nollor eller gemena o:n som gradtecken, vilket naturligtvis är en semantisk mardröm, bortsett från att det ser fel ut. Jag har till och med sett folk använda º (U+00BA: MASCULINE ORDINAL INDICATOR) i stället för gradtecknet ° (U+00B0: DEGREE SIGN).

Av denna anledning tar jag varje tillfälle i akt att påpeka vilken kodpunkt och beskrivning ett tecken har. Inte sällan får man t.ex. anledning att betrakta följande familj av tecken:

- U+002D: HYPHEN-MINUS
− U+2212: MINUS SIGN
‐ U+2010: HYPHEN
‑ U+2011: NON-BREAKING HYPHEN
katt­mat: U+00AD: SOFT HYPHEN (mellan "katt" och "mat")
– U+2013: EN DASH
— U+2014: EM DASH (används inte på svenska)

Jag funderar på om vi inte kunde införa kodpunkt och beskrivning i våra artiklar om tecken, såsom −. Jag såg f.ö. att vår artikel är helt felaktig: "minustecknet" är ett bindestreck och "bindestrecket" är ett minustecken.

Jag tänker mig något i stil med det här:

<div class="teckenvisning">
  <span>−</span>
  <code>U+2212: MINUS SIGN</code>
</div>

där radbrytningen mellan tecknet och koden ordnas via CSS (för att få koden semantisk). Just nu använder vi mallen {{tecken}} för att visa tecknet i en flytande ruta till höger. Kan vi inte lägga till information om kodpunkt och beskrivning i den mallen? Kan man rent av (t.ex. via JavaScript) infoga kodpunkt och beskrivning automatiskt? Jag gissar att kodpunkt går att automatisera, medan beskrivningen kräver en databas. Jag har själv en sådan lista: . --Andreas Rejbrand (diskussion) 4 januari 2014 kl. 14.39 (CET)

Det känns som ok info att ha med även om det väl snarare hör till wp. Vi utökar {{tecken}} och om det blir för jobbigt med bot eller för hand så kan vi fixa en modul. Onödigt med js till det här. //Skal 4 januari 2014 kl. 17.36 (CET)

Jag tänker mig då något i stil med det här. Koder och beskrivningar kan jag infoga manuellt för de flesta allmänna tecken. --Andreas Rejbrand (diskussion) 4 januari 2014 kl. 20.59 (CET)

Verkar okej, men jag föreslår att vi använder svenska för parameternamnen: kodpunkt= och beskr=. Är det okej? (Redan beskrivet på {{tecken}}) //Skal 6 januari 2014 kl. 00.03 (CET)

Visst, det går bra. Jag inför den nya mallen och börjar lägga till kodpunkter och beskrivningar i artiklar i morgon om ingen (mot förmodan) motsätter sig det. --Andreas Rejbrand (diskussion) 6 januari 2014 kl. 02.14 (CET)

@Pametzma la till kategorin Reflexivt på WT:KAT, vilket jag motsatte mig eftersom vi inte har kategorier för andra grammatiska egenheter, men han har en poäng i att det kan vara användbart att lista alla ord med en viss egenhet.

För de flesta användare tror jag att {{konstr}} är tydligare än att förklara de grammatiska termerna. T.ex. är {{konstr|unna sig något}} tydligare än (reflexivt, transitivt), men det första ger oss ingen möjlighet att lista alla reflexiva verb.

Vill vi ha detta i kategorier? I så fall föreslår jag:

• Att vi har tydliga kategorinamn, t.ex. "reflexiva verb" och inte bara "reflexivt".
• Att vi inte använder {{tagg}} till detta, eftersom det a) dels blir svårare att hitta definitionen i wikitexten och b) blir mkt text före definitionen om kategorierna inte döljs (men i så fall syns det ju inte)
• Att vi istället utökar {{grammatik}} för att specificera kategorierna. T.ex. kan det fungera såhär:

  {{grammatik|Annan grammatisk info.|reflexivt=|transitivt=|språk=franska}}, som skulle resultera i

  Grammatik: Annan grammatisk info. Verbet är reflexivt och transitivt.

  Det här tar förstås mer plats, men tar inte fokus från definitionen.

• Att vi, där det är möjligt, har med kategorier i grammatiktabellen. T.ex. kan genus nästan alltid stå med där, så slipper man använda {{grammatik}}.

Vad tycker ni? Har någon några bättre förslag? //Skal 7 januari 2014 kl. 11.12 (CET)

Jag tycker det mesta du skriver verkar OK. Däremot är det viktigt för mig att vi använder just orden "reflexivt" och "transitivt", på något sätt: "Verbet är reflexivt" är OK för mig. Anledningen till min uppfattning är insikten att det är med begrepp man begriper (som Lars-Alfred Engström brukade säga). Det är också alltid bra att lära ut begrepp. Jag stödjer ditt förslag om utökning av {{grammatik}}, liksom införandet av dessa kategorier. --Andreas Rejbrand (diskussion) 7 januari 2014 kl. 13.33 (CET)

Jag tycker det vore bättre att utvidga mallen {{tagg}} med nya parametrar reflexivt=, transitivt=, intransitivt=, opersonligt= osv som placerar uppslaget i rätt kategorier. Många verb skiftar ju betydelse beroende på hur det används (t.ex. finna / finna sig (i något)) och att ha en grammatiksektion efter varje definition i såna fall tror jag skulle se rörigt ut. Fiskjuice (diskussion) 7 januari 2014 kl. 14.47 (CET)

Jag tycker att även {{tagg}}-varianten är helt OK. (Vi behöver ju inte göra en "ordbok för dummies"...) --Andreas Rejbrand (diskussion) 7 januari 2014 kl. 15.32 (CET)

Varför inte använda båda varianterna? Om en artikel innehåller en enda definition av verbet, kan vi använda {{grammatik}}. Kanske kan vi även göra detta (efter {{avgränsare}}) om samtliga definitioner av verbet har samma egenskap. I annat fall, om verbet har flera definitioner, vissa transitiva (eller reflexiva) och vissa inte, kan vi använda {{tagg}} i stället. --Andreas Rejbrand (diskussion) 7 januari 2014 kl. 16.12 (CET)

Kul med feedback!

Som jag skrev tror jag att dom flesta förstår {{konstr}} mkt bättre än grammatiska termer. Därför vill jag gärna ha fokus på konstruktioner och ser gärna att vi har konstruktioner efter varje definition. Jag motiverade också varför jag inte vill använda {{tagg}}: det gör raden med definitionen svårare att förstå.

Jag tror inte på att använda båda varianterna: det är mkt enklare om det finns ett sätt att göra det på.

För att det ska bli lättare att se vad vi pratar om har jag infogat två alternativ nedan: antingen med {tagg} eller {grammatik}. Själv tycker jag att det är lättare att hitta definitionerna i {grammatik}-varianten. //Skal 7 januari 2014 kl. 23.33 (CET)

	{{tagg}}	{{grammatik}}
fördelar	minimal förändring mot nuvarande system kompaktare definition	logisk, separerar ut grammatiken sätter definitionen i fokus lättare att förstå för den oinsatte
nackdelar	blandar grammatik med kategorier tar bort fokus från själva definitionen	mer att skriva då man skapar en definition uppslagen blir längre i höjdled

Jag ändrar mig till neutral. Båda är bra. Fiskjuice (diskussion) 8 januari 2014 kl. 12.47 (CET)

Jag håller med om dina nack-/fördelar, men för mig så väger "sätter definitionen i fokus" mkt tyngre än det andra. Jag skulle också kunna tänka mig att dölja viss information som standard, ungefär som en-wikt döljer citat. //Skal 8 januari 2014 kl. 13.29 (CET)

En ytterligare fördel med {{tagg}} är att t.ex. transitivitet och reflexivitet känns som en viktig del av själva uppslagsordet, rent av på en mer grundläggande nivå än definitionen. Det kan vara bra att matas med den informationen innan man läser definitionen. --Andreas Rejbrand (diskussion) 8 januari 2014 kl. 13.38 (CET)

Jag håller inte med dig, jag vidhåller att {{konstr}} är viktigare/tydligare för att förstå konstruktionen än grammatiska termer, för den absoluta majoriteten. //Skal 8 januari 2014 kl. 14.36 (CET)

Jag lutar mot att hålla med Andreas om fördelen med {{tagg}} för reflexivitet/grammatik, men även för bruksangivelser. Jag inser att det skulle kunna vara för att jag känner igen mig i den strukturen från andra verk, men också för att jag tycker att det redan finns för mycket mellan själva definitionerna som så att säga börjar stjäla fokus. Jag ser heller ingen fördel i tydlighet för det högra exemplet, så som de är formulerade just nu: då den vänstra säger '(reflexivt)' så säger den högra 'Grammatik: Verbet är reflexivt', vilket ger en skillnad i... pladdrighet och inte mycket mer. Om man är rädd att läsaren inte ska känna till innebörden av termerna, så är det exempel som behövs, men de är redan införda i båda exemplen i.o.m. {{konstr}}-mallen.
(Sedan kan jag väl tycka att mallarna mellan definitionerna allaredan stjäl fokus för läsaren, men det är annan diskussion.) \Mike 9 januari 2014 kl. 14.26 (CET)

Är "bruksangivelser" = "konstruktioner"? Vore det bättre att bara ha "Grammatik: Reflexivt." ? Ang. utvidgning i höjdled så tänker jag att det kan diskuteras separat, se nedan. //Skal 9 januari 2014 kl. 15.58 (CET)

Var det "brukstaggar" vi kallade det? 'Vardagligt' / 'ålderdomligt' / 'dialektalt' m.m. \Mike 9 januari 2014 kl. 21.22 (CET)

Vi har ganska mycket information i och med våra böjningstabeller. Vill vi använda dom till att kategorisera mer finkornigt? Några av förslagen nedan kan vi fixa genom att uppdatera böjningstabellerna, några måste man ange manuellt genom {{tagg}} eller {{grammatik}}. Fyll gärna på med fler förslag på kategorier och kommentera på om det behövs:

1. Genus: "Substantiv i utrum", "Substantiv i neutrum", "Substantiv i femininum", "Substantiv i maskulinum"
2. Räknebarhet: "Oräknebara substantiv"
3. "Verb i 1:a konjugationen"; "Er-verb", "Ir-verb", "Re-verb" (franska); "Starka verb", "Svaga verb" (Exakta namn behöver vi fundera mer på.)
4. "Adjektiv som kompareras", "Adjektiv som inte kompareras", "Adjektiv som kompareras perifrast" (hur säger man det här snyggare?)
5. "Substantiv som slutar med -are"
6. "Oböjliga adjektiv", "Oböjliga substantiv", "Oböjliga verb"
7. Efter vilken preposition/artikel/partikel som följer ett verb: "Verb som följs av att", "Verb som följs av på", "Verb som följs av till" (svenska), "Verb som följs av partitiv", "Verb som följs av elativ" (finska).

   Det här är ganska användbart när man ska lära sig språk. Både för franska och finska har jag fått listor över verb som följs av en viss preposition/böjningsform.

Kommentarer? //Skal 8 januari 2014 kl. 13.29 (CET)

Jag är generellt positiv till kategorisering av ord. Det skadar ju knappast. Själv funderade jag i morse på att införa en kategori för partikelverb (tycka om, skrämma bort, gå på, äta upp, ...). --Andreas Rejbrand (diskussion) 8 januari 2014 kl. 13.40 (CET)

Går det att kategorisera på vilketn partikelverb som används? "Partikelverb med om" osv. Hur anger man den informationen på bästa sätt? {{grammatik|partikel-om=}}? Skulle man skriva ut någon text? //Skal 8 januari 2014 kl. 14.36 (CET)

(Du menar nog "...på vilken partikel som används".) Det går ju också, men jag vet inte hur pass meningsfullt det skulle vara. Jag tror däremot inte det är någon poäng i att skriva ut något på sidan, utan kategoriseringen räcker. --Andreas Rejbrand (diskussion) 8 januari 2014 kl. 14.40 (CET)

Ja, det menade jag. Jag instämmer: vissa saker är värda att visa, vissa inte. Hur skiljer man på partikelverb och verb som kräver viss preposition efter? "ge något till någon" t.ex. //Skal 8 januari 2014 kl. 15.22 (CET)

Menar du hur man avgör om något som ser ut som ett partikelverb verkligen är det eller inte? I sådana fall är uttalet nyckeln. I partikelverb betonas partikeln. --Andreas Rejbrand (diskussion) 8 januari 2014 kl. 15.37 (CET)

Angående uttalet så har det uppkommit lite oenighet i minst ett fall om var betoningen verkligen ligger (se Diskussion:gå_på), så det verkar inte alla gånger vara en entydig nyckel. Jag har inte heller sett (men så har jag inte följt med så noga på senaste tid) om det problem är löst, som rör s.a.s. reflexiva verb med partikel (t.ex. 'ta sig ut') versus partikelverb som är reflexiva (t.ex. 'ta ut sig').
Jag tror inte på en {{grammatik|partikel-om=}}-struktur* per definition, eftersom partikelverben har egna uppslag och hellre skulle kunna stå i en lista över fraser el. dyl. (jfr. gå). Däremot bör, anser jag, icke-partikelverb som kräver en viss preposition markeras. Hittills har jag bara gjort det med en textkommentar i {{tagg}}en, och jag tycker att det är viktigare att det syns i (eller vid) definitionen än att det kategoriseras, men jag tänker inte argumentera mot kategorisering. \Mike 9 januari 2014 kl. 13.57 (CET)

*Var tanken att placera grammatikmallen på "grundverbets" eller på "partikelverbets" uppslag? Vore i så fall rimligare att kategorisera gå på än gå med en eventuell 'Kategori:Partikelverb med 'på' '.

Jag tänker att grammatikinfo finns där ordet beskrivs. Eftersom vi har partikelverb på två-ordiga uppslag så bör rimligtvis grammatikinfon finnas där, men för någon som lär sig svenska vore det bra att se gå i en på-lista, eftersom man säger "gå på teater". Det kanske är skilt från partikelverben? //Skal 9 januari 2014 kl. 15.58 (CET)

Vad jag minns är att vi sagt att 'gå' i betydelsen 'besöka en aktivitet' bör listas på uppslaget gå eftersom det inte är ett partikelverb (gå är betonat i ' gå på teater') medan partikelverbet 'gå på' (=bli lurad) skulle få ett eget uppslag. Jfr diskussion från 2010. Det var något som beslutades/växte fram ganska tidigt; det kan mycket väl vara så att vi borde reevaluera detta. Just det här fallet, 'gå på', har i praktiken gjorts annorlunda, med samtliga 'gå + på' på samma sida (partikelverb eller ej), och två fetstilsrader. Det vore väl också en möjlig struktur: problemet som jag ser det är väl att vissa definitioner skulle behöva en synonym eller annan hänvisning ('ge till' <-> 'ge åt') och i praktiken dubblera information, medan andra skulle mångfaldigas i många led/ges ett stort antal triviala definitioner ('gå på (väg)' <-> 'gå i (snö)' <-> 'gå till (affär)' <-> ... och alla andra prepositioner som skulle kunna tänkas användas för att beskriva var någon promenerar.) Jag tror därmed att det är att föredra att behandla dessa icke-partikelverb under huvudordet. En speciell kategori för de betydelser som kräver vissa prepositioner (eller andra konstruktioner, även om det skulle kunna föra lite väl långt) ska jag inte protestera mot, men någon synlig tagg vore önskvärd i anslutning till definitionen. I just fallet 'gå' finns en manuell sådan tagg för betydelsen 'spenderas på' som skulle kunna formaliseras i mallkod, och ge en kategorisering. \Mike 9 januari 2014 kl. 21.22 (CET)

Den här diskussionen har gått lite off-topic, men kort: Jag tycker att gå på kan ha alla definitioner (ev. med hänvisning till viss def i gå), medan gå till inte bör skapas om det inte också finns partikelverbbetydelse. Vidare ersätter jag gärna det manuella (med "till") med konstr+grammatik (eller +tagg om andra hellre ser det). Vidare diskussion om partikelverb kan kanske ske under egen rubrik? //Skal 9 januari 2014 kl. 23.04 (CET)

Det blev särskilt relevant med diskussionen ovan där jag föreslår att oftare ha med {{grammatik}}, men också annars så börjar vi få mer och mer information mellan definitionerna. Det här är början på en diskussion för att se om vi kan dölja en del av det som standard.

En-wikt har under en längre tid dolt citat under en liten länk . Vi skulle kunna göra något liknande, där vi också döljer annat mellan definitionerna. Jag föreslår att vi gör såhär:

1. visa alltid
   • Exempel, konstruktioner, synonymer, antonymer, varianter
2. dölj om det finns mer än tre inforader mellan definitioner
   • Citat
3. dölj om det finns mer än tre inforader mellan definitioner, men även om det inte finns det, så kortas raden om den är för lång
   • Sammansättningar, jämför, besläktade ord, fraser, se även, etymologi, grammatik, stavning, hyperonymer, hyponymer, kohyponymer, holonymer, meronymer, troponymer

Verkar det här vara en bra idé att testa? Har någon några bättre förslag? //Skal 9 januari 2014 kl. 15.58 (CET)

Jag har skrivit en finess som döljer. Den är inte så smart, så den döljer alltid alla avsnitt som jag listat som "dölj" eller "dölj + kortas". Men det ger ändå en idé om hur det kan se ut. Pröva och kommentera gärna! //Skal 9 januari 2014 kl. 18.04 (CET)

Är inte positionen på etiketten lite tokig? Nu är den på definitionsraden; jag vill hellre ha den på den sista indragna raden (precis före nästa definition). --Andreas Rejbrand (diskussion) 9 januari 2014 kl. 20.30 (CET)

@Andreas Rejbrand, du har en poäng, men jag ser ingen självklar lösning. Hur gör du i detta fall: (definition) (-döljs-citat-) (synonymer)? Det funkar inte riktigt att placera etiketten på synonymer-raden, eftersom det som gömts och nu visas finns ovanför. Här är två potentiella sätt att lösa det på:

1. Sortera om raderna, men i så fall kan vi lika gärna försöka ha rätt ordning från början
2. Ha separata etiketter: (definition ) (-döljs-citat-) (synonymer ) (-döljs-sammansättningar-) (-döljs-besläktade ord-)

Är någon av dom bättre? Finns det fler idéer? //Skal 9 januari 2014 kl. 22.51 (CET)

OK, jag vet inte. Det här inte en viktig funktion för mig (alla mina skärmar har upplösningen 1920×1080 (24 tum eller större), så att spara in 10 px här och där är inte relevant). Det här är kanske mest en funktion för folk med så kallade "smartphones" och liknande. Däremot borde den visuella buggen fixas. --Andreas Rejbrand (diskussion) 10 januari 2014 kl. 22.39 (CET)

Man skulle kunna aktivera det endast om sidan är mindre än 600px hög.

Ja, den visuella buggen bör fixas, men har du något förslag på hur det ska lösas? //Skal 10 januari 2014 kl. 22.53 (CET)

Eller menar du översättningsrubrikens position? Det planerar jag att lösa vid tillfälle. 10 januari 2014 kl. 22.54 (CET)

Om man klickar på 'besläktade ord' på besöka så åker rubriken 'Översättningar' ner bakom översättningsrutan, så att den inte syns. --Andreas Rejbrand (diskussion) 10 januari 2014 kl. 23.00 (CET)

Även förminskning av fönstret (oavsett om du expanderar besläktade ord eller ej) orsakar problem för rubriken. --Andreas Rejbrand (diskussion) 10 januari 2014 kl. 23.00 (CET)

Jag har fixat översättningsrubrikens position nu. Etikettens position behöver däremot fortfarande bestämmas. //Skal 11 januari 2014 kl. 10.03 (CET)

Jag har snyggat upp visningen enl. förslag från Dodde. Ser det bra ut?

Det finns också en idé om låta var och en välja vilka delar man vill se. Inte helt säker på hur det skulle gå till, men det verkar vettigt. //Skal 22 januari 2014 kl. 01.00 (CET)

Snyggt, men användarvänligheten blir lidande av att bara man måste träffa en knapp på 12×12 pixlar med musen eller fingret (t.ex.) för att aktivera länken. Rimligtvis borde hela området på 12×90 px vara klickbart. --Andreas Rejbrand (diskussion) 22 januari 2014 kl. 07.11 (CET)

Man kan faktiskt trycka lite utanför också, så egentligen är det ett område på 16x16 pixlar. Tidigare prövade jag med 24x24 pixlar, men då blev det problem om det fanns näraliggande länkar. Hur som helst - jag ska pröva att göra området bredare! //Skal 22 januari 2014 kl. 09.36 (CET)

Tack för påpekandet. Nu kan man trycka på ett 16px högt område med samma bredd som strecket. //Skal 22 januari 2014 kl. 09.45 (CET)

Strålande! --Andreas Rejbrand (diskussion) 22 januari 2014 kl. 10.17 (CET)

Se Wiktionarydiskussion:Stilguide#Ersätta "Motsvarande namn på andra språk" med "Översättningar"?

I apologize for this message being only in English. Please translate it if needed to help your community.

The Wikimedia Foundation's multimedia team seeks community guidance on a proposal to support the MP4 video format. This digital video standard is used widely around the world to record, edit and watch videos on mobile phones, desktop computers and home video devices. It is also known as H.264/MPEG-4 or AVC.

Supporting the MP4 format would make it much easier for our users to view and contribute video on Wikipedia and Wikimedia projects -- and video files could be offered in dual formats on our sites, so we could continue to support current open formats (WebM and Ogg Theora).

However, MP4 is a patent-encumbered format, and using a proprietary format would be a departure from our current practice of only supporting open formats on our sites -- even though the licenses appear to have acceptable legal terms, with only a small fee required.

We would appreciate your guidance on whether or not to support MP4. Our Request for Comments presents views both in favor and against MP4 support, based on opinions we’ve heard in our discussions with community and team members.

Please join this RfC -- and share your advice.

All users are welcome to participate, whether you are active on Commons, Wikipedia, other Wikimedia project -- or any site that uses content from our free media repository.

You are also welcome to join tomorrow's Office hours chat on IRC, this Thursday, January 16, at 19:00 UTC, if you would like to discuss this project with our team and other community members.

We look forward to a constructive discussion with you, so we can make a more informed decision together on this important topic. Keegan (WMF) (talk) 16 januari 2014 kl. 07.47 (CET)

Jag föreslår att vi ändrar utseende på våra gömbara rutor (t.ex. översättningar) till att mer likna en-wikts rutor: en tydlig ram och en smal vit bord innanför det.

För att göra det hela mer konkret har jag fixat så att man kan aktivera det nya utseendet med en finess: Inställningar->Finesser->Experiment (längst ner).

Verkar det vara en bra idé att införa som standard för alla? (Om ingen säger något på en vecka så aktiverar jag det.) //Skal 2 februari 2014 kl. 01.16 (CET)

Jag har genomfört ändringen. Säg till om något blev tokigt eller kan förbättras. //Skal 14 februari 2014 kl. 13.19 (CET)

I apologize if this message is not in your language. Please help translate it.

Do you have an idea for a project that could improve your community? Individual Engagement Grants from the Wikimedia Foundation help support individuals and small teams to organize experiments for 6 months. You can get funding to try out your idea for online community organizing, outreach, tool-building, or research to help make Wiktionary better. In March, we’re looking for new project proposals.

Examples of past Individual Engagement Grant projects:

• Organizing social media for Chinese Wikipedia ($350 for materials)
• Improving gadgets for Visual Editor ($4500 for developers)
• Coordinating access to reliable sources for Wikipedians ($7500 for project management, consultants and materials)
• Building community and strategy for Wikisource (€10000 for organizing and travel)

Proposals are due by 31 March 2014. There are a number of ways to get involved!

Hope to have your participation,

--Siko Bouterse, Head of Individual Engagement Grants, Wikimedia Foundation 28 februari 2014 kl. 20.44 (CET)

Apologies if this is not in your local language. Please translate as you find it appropriate.

There is a cross-wiki discussion in progress as to whether c: should be enabled globally as an interwiki prefix for links to the Wikimedia Commons. As your wiki has a page whose title begins with "C:", it will need to be renamed if this proposal gains consensus. Please take a moment to participate in the discussion. Thank you. –föregående osignerade kommentar är från TeleComNasSprVen (diskussion • bidrag)

Om detta går igenom kommer vi behöva flytta vårt uppslag c:a till Övriga uppslagsord. Det verkar okej för mig. //Skal 17 mars 2014 kl. 19.58 (CET)

(English comment, sorry!) Yes, the article c:a would need to be put on Övriga uppslagsord. A similar thing will happen for "c:a" at English Wiktionary, at their Appendix:Unsupported titles. Scott (diskussion) (meta:User:Scott) 19 mars 2014 kl. 17.35 (CET)

@Skalman: (Försöker Google översättning...) Det verkar som om förslaget kommer att lyckas när det stängs, två dagar från nu. Kan du hjälpa till genom att flytta c:a för att Övriga uppslagsord och med omdirigeringen tas bort? Jag skulle älska att markera detta projekt som "klar" på vår lista. Tack! Scott (diskussion) 22 mars 2014 kl. 21.49 (CET)

I'll do that. (By the way, Swedes love English far more than the crappy Swedish you get from Google...) --Andreas Rejbrand (diskussion) 22 mars 2014 kl. 21.52 (CET)

Haha! Cool. :) I actually just added it to the list myself, to save you some time; I was going to change my comment but you got in with a reply first. Scott (diskussion) 22 mars 2014 kl. 21.55 (CET)

Yeah, I got a bit surprised! But now everyhing is right. --Andreas Rejbrand (diskussion) 22 mars 2014 kl. 21.56 (CET)

Jag har under flera års tid gått och funderat på att skapa ett Windows-program som automatiserar skapandet av ljudfiler med uttal för uppslagsord på svenska.

Jag hade då tänkt mig en nativ Win32-applikation med en webbläsarkontroll. I denna slår man upp en artikel. Då kan man t.ex. dubbelklicka på en fetstilsrad varvid ett gränssnitt för ljudinspelning kommer upp. Man spelar in ordet, och kan sedan kontrollera hur det blev (man kan också trimma och kanske applicera lämpliga transformer på ljudet). Sedan, men en knapptryckning, så sparas ljudet i lämpligt format (OGG, antar jag), laddas upp på Commons under lämpligt filnamn och med automatiskt genererad beskrivning, och en mall som länkar till ljudfilen läggs in i den aktuella artikeln.

Jag har dessvärre aldrig tagit tag i projektet.

Nu när jag kom att tänka på det igen slog det mig att man numera borde kunna implementera hela lösningen i HTML5 (i vid bemärkelse). Kanske kunde man skapa ett "tillägg" på sv.wiktionary.org som fungerar som mitt tänkta Win32-program, fast direkt i valfri HTML5-kompatibel webbläsare. Vad säger experten (Skalman)?

Oavsett hur funktionaliteten implementeras tror jag att jag med hjälp av den ensam skulle kunna skapa bortåt hundra uttal per dag. --Andreas Rejbrand (diskussion) 31 mars 2014 kl. 21.24 (CEST)

@Andreas Rejbrand, det låter som en bra idé. Jag har aldrig rört ljud i webbläsaren annat än på stort avstånd, men skulle absolut kunna tänka mig att jobba på det. Problemet är väl att jag har många påbörjade projekt och lite tid: översättningsskriptet behöver putsas, jag håller på att skapa en applikation för diverse botuppgifter och det vore trevligt att putsa "gömma info invid def"-finessen så pass att den kan aktiveras som standard. Vad borde jag prioritera?

Skulle du själv vara intresserad att delta i kodandet? //Skal 3 april 2014 kl. 22.13 (CEST)

För övrigt finns det ett stort antal ljudfiler redan, och inte alla har lagts in i våra uppslag än. Utifrån ett stickprov verkar det som om vi knappt har några alls inlagda.

Jag har nu frågat på Commons om det finns något verktyg vi kan använda för inspelning och uppladdning. //Skal 5 april 2014 kl. 08.12 (CEST)

Jättebra initiativ. Jag tänker att, även om det vore möjligt med nån sorts javascriptslösning, så blir den omständlig om en person ska skapa många ljudfiler. Isåfall skulle jag föreslå att man använder något befintligt ljudinspelningsprogram, med möjlighet till ex.vis brusreducering, normalisering (så att ljudfilerna håller en jämn volym) och så man kan få visuell feedback på hur inspelningen lyckades. Så spelar man kanske in 100 ord i en följd med mindre pauser emellan och sedan använder man ett ljudsplittningsprogram som splittar överallt där det är tyst enligt någon inställning. http://www.nch.com.au/splitter/ dök upp när jag googlade. Sedan, väl med alla ljudfiler skapade, kan man skapa en tabell med ord, ordklass och filnamn och med hjälp av det kan man ju enkelt döpa filerna efter detta. Sedan återstår uppladdning till Commons (och de har väl api för massuppladdning) och sen behöver någon bot gå igenom sidorna på svwikt och lägga till länkarna till Commons, på de uppslag som existerar. Det bör gå att göra effektivt med "applikationen för diverse botuppgifter" som Skalman nämnde, även om det ligger en bit fram i tiden innan vi ser en körbar version av den.

Att lägga till ljudfiler en och en via svwikt, om tanken med javascript på svwikt nu främst var att alla olika användare ska kunna lägga till en ljudfil enklare, så känns det som om det finns mer prioriterade områden för förbättring vad gällre användarvänlighet. ~ Dodde (diskussion) 5 april 2014 kl. 12.00 (CEST)

Hi everybody, when I was prioritizing the notifications of Wiktionaries, I just looked at the number of entries and not on how vibrant the community is. This was obviously a mistake and I'd like to apologize for that. Because creating such a gadget and doing it properly will be associated with a huge amount of work, I went to Grants IEG on Meta, where you can read about my proposal. Skalman, Andreas Rejbrand, are you interested joining this project? Actually, if you are enthusiastic about low-level processing stuff: There will be the need for some audio filters. The budget can be raised. If you are interested in testing or in an advisory role, that would be also quite helpful, I think. Let me know whether you are and what you are interested in, and let's make a really good gadget!

On the other hand, if you want to code it your own, Skalman was asking about code for uploading. Currently, I am not aware of a JavaScript audio encoder for opus or flac. Are you? However, one can upload in wav format to Commons (for pronunciation it's okay I think) and composing a boring PCM wav file from the raw audio data is quite easy stuff; one just has to add some headers. Uploading can be done through FormData. But due to a bunch of possible errors, this is everything but trivial. UploadWizard and commons:User:Rillke/MwJSBot.js implement JavaScript upload. -- Rillke (diskussion) 5 april 2014 kl. 22.37 (CEST)

Rillke, great to hear that others are thinking along the same lines. I don't have very much time, and if this project will complete without me I'd rather leave it to others, but I could certainly take part. I don't know anything about audio filters and wouldn't be able to help there.

I somehow imagined that the browser's audio encoding would be directly available in JS, but it seems like we'd have to use WAV, unless we include an encoder (which might or might not be doable with Emscripten).

One thing to take into consideration is that there are many recorded files that have not yet been added to the entries (at least here at sv-wikt). Before suggesting to record a new file, it should try to find an existing file that would do the job. //Skal 6 april 2014 kl. 01.04 (CEST)

Nu har det gått ännu ett år, och vi har ännu inte den här funktionaliteten... --Andreas Rejbrand (diskussion) 12 juli 2015 kl. 02.17 (CEST)

Dear Wiktionary community!

About me

My name is Rainer Rillke, and I have been volunteering at Wikimedia Commons for 3 years now, gathering experience around media files. I've been always interested in how things work and how one could improve them.

The idea

One idea that appeared last Summer was allowing the recording of small chunks of speech, uploading that to Wikimedia Commons in the background and including this into a Wiktionary entry without having the hassle doing everything by hand or installing additional software. That idea led to the foundation of MediaWiki extension PronunciationRecording during the Google Summer of Code. However, this was not completed; instead development is stale for over 5 months now.

My proposal

To make this going to work, so Wiktionary has an immediate benefit of this feature, I would like to provide the work done so far as a gadget and add some more work in regard to usability. You can see my plan at m:Grants:IEG/Finish Pronunciation Recording. And more importantly, you can give me a hand, if you are interested by writing your comments.

Thanks and kind regards --Rillke (diskussion) 7 april 2014 kl. 19.26 (CEST)

This message was delivered based on commons:User:Rillke/gmd/prg. Translation fetched from: commons:User:Rillke/prg/en -- Rillke^(q?) 17:42, 26 January 2013 (UTC)

This is a one-time mailing to projects that may need this information. Future newsletters will be available as opt-in only. To receive future newsletters (about one per month), please add your page to the subscribers' list at m:VisualEditor/Newsletter. You're welcome to translate to your language.

Since the last newsletter, the VisualEditor team has mostly worked on the new citation tool, improving performance, reducing technical debt, and other infrastructure needs.

Did you know?

The cite menu offers quick access to up to five citation templates.  If your wiki has enabled the "⧼visualeditor-toolbar-cite-label⧽" menu, press "⧼visualeditor-toolbar-cite-label⧽" and select the appropriate template from the menu.

Existing citations that use these templates can be edited either using the "⧼visualeditor-toolbar-cite-label⧽" tool or by selecting the reference and choosing the "⧼visualeditor-dialogbutton-reference-tooltip⧽" item in the "Infoga" menu.

Read the user guide for more information.

The biggest change in the last few weeks is the new citation template menu, labeled "⧼visualeditor-toolbar-cite-label⧽". The new citation menu offers a locally configurable list of citation templates on the main toolbar. It adds or opens references using the simplified template dialog that was deployed last month. This tool is in addition to the "⧼visualeditor-dialogbutton-reference-tooltip⧽" item in the "Infoga" menu, and it is not displayed unless it has been configured for that wiki. To enable this tool on your wiki, see the instructions at VisualEditor/Citation tool.

Eventually, the VisualEditor team plans to add autofill features for these citations. When this long-awaited feature is created, you could add an ISBN, URL, DOI or other identifier to the citation tool, and VisualEditor would automatically fill in as much information for that source as possible. The concept drawings can be seen at mw:VisualEditor/Design/Reference Dialog, and your ideas about making referencing quick and easy are still wanted.

• There is a new Beta Feature for setting content language and direction.  This allows editors who have opted in to use the "Språk" tool in the "Infoga" menu to add HTML span tags that label text with the language and as being left-to-right (LTR) or right-to-left (RTL), like this:  <span lang="en" dir="ltr">English</span>. This tool is most useful for pages whose text combines multiple languages with different directions, common on Right-to-Left wikis.
• The tool for editing mathematics formulae in VisualEditor has been slightly updated and is now available to all users, as the "⧼math-visualeditor-mwmathinspector-title⧽" item in the "Infoga" menu. It uses LaTeX like in the wikitext editor.
• The layout of template dialogs has been changed, putting the label above the field.  Parameters are now called "fields", to avoid a technical term that many editors are unfamiliar with.
• TemplateData has been expanded:  You can now add "suggested" parameters in TemplateData, and VisualEditor will display them in the template dialogs like required ones.  "Suggested" is recommended for parameters that are commonly used, but not actually required to make the template work.  There is also a new type for TemplateData parameters: wiki-file-name, for file names.  The template tool can now tell you if a parameter is marked as being obsolete.
• Some templates that previously displayed strangely due to absolute CSS positioning hacks should now display correctly.
• Several messages have changed: The notices shown when you save a page have been merged into those used in the wikitext editor, for consistency.  The message shown when you "⧼visualeditor-toolbar-cancel⧽" out of an edit is clearer. The beta dialog notice, which is shown the first time you open VisualEditor, will be hidden for logged-in users via a user preference rather than a cookie.  As a result of this change, the beta notice will show up one last time for all logged-in users on their next VisualEditor use after Thursday's upgrade.
• Adding a category that is a redirect to another category prompts you to add the target category instead of the redirect.
• In the "Bilder och media" dialog, it is no longer possible to set a redundant border for thumbnail and framed images.
• There is a new Template Documentation Editor for TemplateData.  You can test it by editing a documentation subpage (not a template page) at Mediawiki.org: edit mw:Template:Sandbox/doc, and then click "Manage template documentation" above the wikitext edit box.  If your community would like to use this TemplateData editor at your project, please contact product manager James Forrester or file an enhancement request in Bugzilla.
• There have been multiple small changes to the appearance:  External links are shown in the same light blue color as in MediaWiki.  This is a lighter shade of blue than the internal links.  The styling of the "Textstil" (character formatting) drop-down menu has been synchronized with the recent font changes to the Vector skin.  VisualEditor dialogs, such as the "⧼visualeditor-toolbar-savedialog⧽" dialog, now use a "loading" animation of moving lines, rather than animated GIF images.  Other changes were made to the appearance upon opening a page in VisualEditor which should make the transition between reading and editing be smoother.
• The developers merged in many minor fixes and improvements to MediaWiki interface integration (e.g., edit notices), and made VisualEditor handle Education Program pages better.
• At the request of the community, VisualEditor has been deployed to Commons as an opt-in. It is currently available by default for 161 Wikipedia language editions and by opt-in through Beta Features at all others, as well as on several non-Wikipedia sites.

Looking ahead:  The toolbar from the PageTriage extension will no longer be visible inside VisualEditor. More buttons and icons will be accessible from the keyboard.  The "Kortkommandon" link will be moved out of the "Sidalternativ" menu, into the "Hjälp" menu. Support for upright image sizes (preferred for accessibility) and inline images is being developed. You will be able to see the Table of Contents while editing. Looking further out, the developers are also working on support for viewing and editing hidden HTML comments. VisualEditor will be available to all users on mobile devices and tablet computers. It will be possible to upload images to Commons from inside VisualEditor.

If you have questions or suggestions for future improvements, or if you encounter problems, please let everyone know by posting a note at mw:VisualEditor/Feedback or by joining the office hours on Thursday, 19 June 2014 at 10:00 UTC. If you'd like to get this newsletter on your own page (about once a month), please subscribe at w:en:Wikipedia:VisualEditor/Newsletter for English Wikipedia only or at Meta for any project. Thank you! --Elitre (WMF) (talk) 22 maj 2014 kl. 19.39 (CEST)

Greetings— and sorry for writing in English, please translate if it will help your community,

The Wikimedia Foundation's Multimedia team is happy to announce that Media Viewer was just released on this site today.

Media Viewer displays images in larger size when you click on their thumbnails, to provide a better viewing experience. Users can now view images faster and more clearly, without having to jump to separate pages — and its user interface is more intuitive, offering easy access to full-resolution images and information, with links to the file repository for editing. The tool has been tested extensively across all Wikimedia wikis over the past six months as a Beta Feature and has been released to the largest Wikipedias, all language Wikisources, and the English Wikivoyage already.

If you do not like this feature, you can easily turn it off by clicking on "Disable Media Viewer" at the bottom of the screen, pulling up the information panel (or in your your preferences) whether you have an account or not. Learn more in this Media Viewer Help page.

Please let us know if you have any questions or comments about Media Viewer. You are invited to share your feedback in this discussion on MediaWiki.org in any language, to help improve this feature. You are also welcome to take this quick survey in English, en français, o español.

We hope you enjoy Media Viewer. Many thanks to all the community members who helped make it possible. - Fabrice Florin (WMF) (talk) 19 juni 2014 kl. 23.54 (CEST)

--This message was sent using MassMessage. Was there an error? Report it!

Jag lade just till betydelsen "kissa" på ryska verbet писать, ett ord som också kan betyda "skriva" – beroende på om betoningen ligger på första stavelsen (písat' = kissa) eller sista stavelsen (pisát' = skriva). Eftersom det är helt skilda ord med olika uttal så lade jag dem med varsin rubrik, trots att de båda tillhör samma ordklass (verb), så att det blir tydligare att uttalet skiljer sig åt.

Någonstans inom mig ringer dock en klocka om att det kanske inte är helt enligt föreskrivna mönster – att alla ord inom samma ordklass egentligen ska ligga under samma ordklassrubrik – men innan jag lade upp "kissa"-betydelsen så letade jag runt utan att hitta något motsvarande (samma stavning (homograf), samma ordklass, olika betoning); endera så tillhör orden olika ordklasser (apart, subject) eller så överlappar betydelserna delvis (otrolig) eller så rör det sig om grundord + böjningsform (modern).

Efter att jag uppdaterat писать hittade jag dock två ord jag själv lagt till tidigare med liknande problematik, fast då gällande genus och inte betoning:

• аймара – två olika genus beroende på betydelsen (men samma böjningsmönster eftersom båda är oböjliga)
• соль – två olika genus och två olika böjningsmönster

…där jag dock använt två olika sätt att ange genus – i аймара har jag angett båda ordens genus på fetstilsraden efter varandra, utan att förtydliga vilket genus som hör till vilken betydelse eftersom det framgår av böjningstabellerna (vilket inte betyder att det inte vore bra att ange det även i samband med själva genusmarkörerna, det vore det), medan jag i соль angav genusmarkören på samma rad som förklaringen.

Finns det någon standard för hela Wiktionary hur man ska ange genus och betoning när de skiljer sig för olika betydelser för en och samma stavning? (Jag hittade inget i Stilguiden om detta, inte heller en Google-sökning på temat (begräsat till site:sv.wiktionary org) gav några användbara resultat.) /Elias Mossholm (diskussion) 24 juni 2014 kl. 22.15 (CEST)

Det har diskuterats om att ha flera fetstilsrader, men konsensus är att bara ha en per ordklass. Detta är min tolkning av nuvarande standarder:

• Om definitioner under samma ordklass har olika uttal, ange multipla uttalsrader (t.ex. som se till)
• Om definitioner under samma ordklass har olika genus, ange inget genus alls på fetstilsraden. Om samtliga definitioners genus framgår av böjningstabeller, gör ingenting. Om genus annars inte framgår, visa det med {{grammatik}} under varje definition eller gemensamt efter {{avgränsare}}.

Däremot finns det fortfarande många uppslag som inte följer detta, och denna lösning är kanske inte optimal på alla sätt. //Skal 25 juni 2014 kl. 01.00 (CEST)

Ja, flera fetstilsrader för samma ordklass bör undvikas. Om multipla uttalsrader är jag tveksam. Finns det nån diskussion jag missat? Jag har utgått ifrån att endast en rad ska användas för uttal och man använder då en parameter "uttalslänk=" (utan någonting efter likhetstecknet, och det kanske kan diskuteras, men så är det just nu iallafall) för att inte ytterligare en länk med texten "Uttal" ska skrivas ut. Se درس. Liksom grammatiktabeller kan man hänvisa till olika definitioner med nummer e.d.

Heller inte det bästa exemplet med se till, kanske, eftersom betydelsen med betoning på "se" följt av prepositionen "till" istället bör förklaras på uppslaget för se.

På frågan om olika genus är jag också tveksam till Skalmans tolkning. (Har jag missat någon diskussion även här?) Jag tycker jag att du har löst det bra på båda uppslagen соль och аймара.

Det finns lite olika information som normalt nämns på fetstilsraden men som kan vara olika för olika definitioner. Det finns inget uttalat rätt och fel utan det beror lite på vad man tycker blir tydligast. Det kan vara information om genus, böjlighet, numerus, transitivitet m.m., också lite beroende på olika språk. Antingen kan man ange den på fetstilsraden liknande exemplet för uttal på درس, alltså typ postajati, eller framför varje enskild definition.

Ett rekommenderat sätt, om man anger informationen enskilt framför varje definition, är att använda sig av {{tagg}}-mallen, alltså {{tagg|text=transitivt}}, {{tagg|text=endast i plural}} eller liknande. Mallen {{grammatik}} tänker jag mig bör användas för en något ordrikare grammatisk kommentar.

I fallet med {{n}} och {{f}} så blir kursiveringen fel om den används inuti tagg-mallen, så jag tycker att det är helt ok som du har gjort på соль.

Det är, så vitt jag vet enligt de diskussioner jag minns, inget fel att ange genus på fetstilsraden även om grammatikmallar finns. Det är åtminstone ganska utbrett att göra så. Och i ditt exempel аймара så har du angett båda möjliga genus, vilket ju framgår av grammatikmallarna vilket som hör till vad. En markering på fetstilsraden om vilket genus som hör till vilken definition, alternativt genusangivelsen framför respektive definition hade också funkat. ~ Dodde (diskussion) 25 juni 2014 kl. 04.36 (CEST)

Hej. En ny policy angående borttagandet av "avancerade rättigheter" (administratör, byråkrat, o.s.v)var nyligen antagna avglobalt community samstämmighet

Vi har fastställt att följande användare möter inaktivitets kriterierna (inga redigeringar och ingen logg aktivitet på mer än 2 år):

1. Fenix (administrator)

Dessa användare kommer snart att motaga en kungörelse, förklarnade att de måste starta en gemenskaps disskusion för att behålla sina rättigheter. Ifall användaren inte svarar, så kommer deras höjda rättigheter att tas bort av förvaltarna.

Dock om ni som en gemenskap vill skapa en egen aktivitetsutvärderingsprocess och upphäva den globala processen så att ni kan göra en egen bedömning av dessa inaktiva rättighetshållare, eller om ni redan har en policy som vi har missat, så meddela förvaltare på Meta-Wiki så att vi vet att vi inte skall fortsätta med rättighetsutvärdering på eran wiki. Thanks, Rschen7754 28 juni 2014 kl. 08.33 (CEST)

Please write in English instead of using machine translation! Anyhow, we got the message. --Andreas Rejbrand (diskussion) 28 juni 2014 kl. 23.29 (CEST)

In one respect, this was an extremely bad translation; the name of the link was also translated, to a non-existing page, with absolutely no way to find the page with the original discussion.

Rschen, you above gave a link to the page m:Begäran av kommentar/Aktvites-nivåer av avancerade administrativa rättighets innehavare. This page does not exist, and according to the logs it never has existed. I suppose that you just let a 'bot or Google translate the English name of the page, whichever it was, together with the text you intended to translate.

It is clearly necessary that you (or some other person with full insight in what happened) ASAP provide the correct link here. If you did the same machine translation of links maneuver in many projects, you actually should go back to all your notices (possibly by means of a 'bot), and check whether or not you only gave links to non-existing translations of the discussion page, and provide the correct link whenever this was not done. Alternatively, all these Meta-pages should be created - possibly just as links to the page containing the request for comments or whatever "Begäran om kommentar" was a translation of. Jörgen B (diskussion) 27 juli 2014 kl. 04.09 (CEST)

The policy is m:AAR. Apparently, a lot of our translators did not do a good job translating, and for that I apologize. Also, I suspect that this is only an error in the Swedish-language version of the translation, and this is the only Swedish project to receive this notice (sv.wikipedia has a reconfirmation process, for example, and thus did not get this). --Rschen7754 28 juli 2014 kl. 18.25 (CEST)

Thanks; I hope you are right about the translations to other languages! Jörgen B (diskussion) 28 juli 2014 kl. 18.41 (CEST)

Om du tror dig kunna ha synpunkter på detta, så kan du gå till Appendixdiskussion:Verb på svenska som inte slutar på kort a#Uppdelning i två listor. M. v. h., Jörgen B (diskussion) 27 juli 2014 kl. 04.22 (CEST)

Bör beskrivningar av hur konjunktiv faktiskt (sporadiskt) används i nutida svenska i första hand ges här eller på wp? Vad anbelangar bildningen av formerna utgår jag från att ett wiktappendik är den naturligaste platsen. (I vilket fall kan man självklart informera om wpartiklar här och om wiktappendix där.) Jörgen B (diskussion) 27 juli 2014 kl. 04.27 (CEST)

Jag tänker att man på Wikipedia vill ha en översiktlig beskrivning av det (och om det finns tillgängligt, information om hur användningen ändrats med tiden, länkar till debatter/artiklar om användningen). Detta i kontrast till ett Wiktionaryappendix, där fokus blir fullständighet, och att läsaren ska kunna lära sig den grammatiska konstruktionen. (T.ex. kan alla nutida användningar platsa i ett appendix, liksom detaljer om formens bildning.)

Oavsett hur du väljer att göra informationen tillgänglig, så är korslänkning Wikipedia<->appendix önskvärt. (Obs: detta är min uppfattning, och andra kan ha andra åsikter.) //Skal 27 juli 2014 kl. 08.50 (CEST)

Jag tänker att det skulle vara bra att kunna länka termer som exempelvis används i grammatiktabeller här på Wiktionary till undersidor till Appendix:Grammatik. Om vi hänvisar till en viss konjunktivform som kallas något speciellt, så är det bra om besökaren kan klicka sig vidare och komma till en sida som faktiskt handlar om att beskriva denna formen i sitt sammanhang. För det ändamålet och infallsvinkeln tror jag att det är bättre på Wiktionary. Wikipedia är mer läst, så information som passar det "formatet" kan förstås finnas där också. ~ Dodde (diskussion) 31 juli 2014 kl. 09.49 (CEST)

Tja, korslänkning är förstås i vilket fall mycket rimligt. Ert råd är väl närmast att de mer fullständiga genomgångarna av modern användning göres (= "må göras", pres. konj. pass. av "att göra") här, men historiken där. Jag riktar in mig på detta. Jörgen B (diskussion) 6 augusti 2014 kl. 11.25 (CEST)

The VisualEditor team is currently working mostly to fix bugs, improve performance, reduce technical debt, and other infrastructure needs. You can find on Mediawiki.org weekly updates detailing recent work.

The biggest visible change since the last newsletter was to the dialog boxes. The design for each dialog box and window was simplified. The most commonly needed buttons are now at the top. Based on user feedback, the buttons are now labeled with simple words (like "Cancel" or "Done") instead of potentially confusing icons (like "<" or "X"). Many of the buttons to edit links, images, and other items now also show the linked page, image name, or other useful information when you click on them.

• Hidden HTML comments (notes visible to editors, but not to readers) can now be read, edited, inserted, and removed. A small icon (a white exclamation mark on a dot) marks the location of each comments. You can click on the icon to see the comment.
• You can now drag and drop text and templates as well as images. A new placement line makes it much easier to see where you are dropping the item. Images can no longer be dropped into the middle of paragraphs.
• All references and footnotes (<ref> tags) are now made through the "⧼visualeditor-toolbar-cite-label⧽" menu, including the "⧼visualeditor-dialogbutton-reference-tooltip⧽" (manual formatting) footnotes and the ability to re-use an existing citation, both of which were previously accessible only through the "Infoga" menu. The "⧼visualeditor-dialogbutton-referencelist-tooltip⧽" is still added via the "Infoga" menu.
• When you add an image or other media file, you are now prompted to add an image caption immediately. You can also replace an image whilst keeping the original caption and other settings.
• All tablet users visiting the mobile web version of Wikipedias will be able to opt-in to a version of VisualEditor from 14 August. You can test the new tool by choosing the beta version of the mobile view in the Settings menu.
• The link tool has a new "Open" button that will open a linked page in another tab so you can make sure a link is the right one.
• The "Cancel" button in the toolbar has been removed based on user testing. To cancel any edit, you can leave the page by clicking the Read tab, the back button in your browser, or closing the browser window without saving your changes.

The Wikimedia Foundation recently created a new feature, "superprotect" status. The purpose is to prevent pages from being edited by elected administrators -- but permitting WMF staff to edit them. It has been put to use in only one case: to protect the deployment of the Media Viewer software on German Wikipedia, in defiance of a clear decision of that community to disable the feature by default, unless users decide to enable it.

If you oppose these actions, please add your name to this letter. If you know non-Wikimedians who support our vision for the free sharing of knowledge, and would like to add their names to the list, please ask them to sign an identical version of the letter on change.org.

• Letter to Wikimedia Foundation: Superprotect and Media Viewer
• Letter on change.org

-- JurgenNL (talk) 21 augusti 2014 kl. 19.35 (CEST)

Apologies for English. Please help translate this message.

Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.

• Submit your proposal
• Get help: In IdeaLab or an upcoming Hangout session MediaWiki message delivery (diskussion) 2 september 2014 kl. 18.52 (CEST)

Part or all of this message may be in English. Please help translate if possible.

-- User:Keegan (WMF) (talk) 9 september 2014 kl. 18.23 (CEST)

VisualEditor will become available to users of Microsoft Internet Explorer 11 during today's regular software update. Support for some earlier versions of Internet Explorer is being worked on. If you encounter problems with VisualEditor on Internet Explorer, please contact the Editing team by leaving a message at VisualEditor/Feedback on Mediawiki.org. Happy editing, Elitre (WMF) 11 september 2014 kl. 09.29 (CEST).

PS. Please subscribe to the global monthly newsletter to receive further news about VisualEditor.

Varför är det nödvändigt att licensiera bidrag under både CC-BY-SA 3.0 och GFDL? Såvitt jag kan förstå gör detta det omöjligt att bygga redigeringar av svenska wiktionary på material licensierat under endast CC-BY-SA. Varför inte ställa krav endast på CC-BY-SA? Folkets Lexikon är ju t ex. en fantastisk resurs som är tillgänglig under en sådan licens. Mycket av det materialet skulle ju (halv-automatiserat) kunna integreras här, om det inte vore för GFDL-begränsningen. Tango24 (diskussion) 29 september 2014 kl. 09.50 (CEST)

@Tango24, jag är ingen jurist, men ska försöka förklara så som jag uppfattar situationen. I normala skulle du ha rätt, men eftersom GFDL passar bättre för dokumentation så la man till en klausul i GFDL 1.3 som gjorde det möjligt för en webbplats som Wiktionary att migrera till CC BY-SA 3.0, förutsatt att migrationen gjordes före 1 aug 2009.

Alltså: Man skulle kunna importera från Folkets Lexikon, förutsatt att man tydliggör att innehållet bara är tillgängligt under CC-BY-SA (och förstås berättar om tidigare bidragsgivare där). Däremot borde detta nog bekräftas av någon med mer kunskap än mig först.

Vidare läsning:

• Licensing update: "With the transition, the Wikipedia community will now be allowed to import CC-BY-SA text from external sources into articles."
• Contributors' rights and obligations: "...you may ... import text that is ... single-licensed under terms compatible with the CC BY-SA license..."

Har du tankar om hur man skulle integrera informationen? //Skal 31 oktober 2014 kl. 23.20 (CET)

Jag borde förstås ha läst nästa avsnitt ("Öppna data från Språkrådet") innan jag svarade här. Jag tänker ändå att sidorna jag länkar till ytterligare stödjer uppfattningen att det är okej. //Skal 31 oktober 2014 kl. 23.26 (CET)

Språkrådet har nu lagt ut sina ordlistor under en CC BY 2.5 licens: http://www.sprakochfolkminnen.se/sprak/sprak-och-it/oppna-sprakdata.html. --Vesihiisi (diskussion) 2 oktober 2014 kl. 15.32 (CEST)

Väldigt välkommet och tack för länken. Men kan materialet användas på Wiktionary då det inte är GFDL-licensierat? Se ovanstående fråga. (Jag menar inte att just du behöver svara, utan vill helt enkelt uppmuntra till diskussion). Tango24 (diskussion) 2 oktober 2014 kl. 16.36 (CEST)

Jag försöker nu få klarhet i det hela. Det relevanta avsnittet på Wikipedia lyder: Vad gäller text måste materialet ligga under CC-by-sa. Om materialet inte kan användas under GFDL, antingen för att det licensierats enbart under CC-by-sa eller för att det innehåller otympliga "bestående avsnitt" (Invariant Sections), bör detta anges explicit, lämpligen i redigeringskommentaren (t.ex. "ej GFDL"). Så CC BY är helt dugligt för oss om jag förstått korrekt. (Och eftersom det är just CC BY och inte CC BY-SA så är vi egentligen inte förbjudna att dubbellicensiera?) Vesihiisi (diskussion) 2 oktober 2014 kl. 16.59 (CEST)

Tack för att du grävt litet i saken. För att spara en sida måste man godkänna att oåterkalleligen "släppa itt bidrag fritt enligt licenserna CC BY-SA 3.0 och GFDL". För mig framstår det som märkligt att först godkänna det för att i nästa stund skriva i redigeringskommentaren att hälften av villkoret trots allt inte godkänts. Texten från Wikipedia som du citerar är litet förvirrande. Det som står om "bestående avsnitt" torde gälla GFDL-licensierat material som genom sina bestående avsnitt inte är kompatibelt med CC, men det har ju ingen bäring på frågan om CC-material kan publiceras under GFDL. Det står dessutom högst upp på den länkade sidan att den inte är något officiellt eller juridiskt dokument, så jag vet inte hur mycket man kan lita på den. Problemet verkar alltså, som jag ser det, kvarstå. Tango24 (diskussion) 2 oktober 2014 kl. 18.13 (CEST)

Ja, det är lite rörigt och det vore bra om någon som har mer koll på sånt också tittade på det. Som jag ser det ger oss Språkrådets CC BY licens lite mer spelrum då vi inte tvingas "dela lika".

Även enwp säger i grund och botten samma sak om GFDL: Some text has been imported only under CC BY-SA and CC BY-SA-compatible license and cannot be reused under GFDL; such text will be identified either on the page footer, in the page history or the discussion page of the article that utilizes the text, vilket är nog det närmaste vi kommer ett "officiellt" dokument (Wikipedia policy with legal considerations)... --Vesihiisi (diskussion) 2 oktober 2014 kl. 19.09 (CEST)

Visste du att?

TemplateData is a separate program that organizes information about the parameters that can be used in a template. VisualEditor reads that data, and uses it to populate its simplified template dialogs.

With the new TemplateData editor, it is easier to add information about parameters, because the ones you need to use are pre-loaded.

See the help page for TemplateData for more information about adding TemplateData. The user guide has information about how to use VisualEditor.

Since the last newsletter, the Editing team has reduced technical debt, simplified some workflows for template and citation editing, made major progress on Internet Explorer support, and fixed over 125 bugs and requests. Several performance improvements were made, especially to the system around re-using references and reference lists. Weekly updates are posted on Mediawiki.org.

There were three issues that required urgent fixes: a deployment error that meant that many buttons didn't work correctly (bugs 69856 and 69864), a problem with edit conflicts that left the editor with nowhere to go (bug 69150), and a problem in Internet Explorer 11 that replaced some categories with a link to the system message MediaWiki:Badtitletext (bug 70894) when you saved. The developers apologize for the disruption, and thank the people who reported these problems quickly.

Increased support for devices and browsers

Internet Explorer 10 and 11 users now have access to VisualEditor. This means that about 5% of Wikimedia's users will now get an "Edit" tab alongside the existing "Edit source" tab. Support for Internet Explorer 9 is planned for the future.

Tablet users browsing the site's mobile mode now have the option of using a mobile-specific form of VisualEditor. More editing tools, and availability of VisualEditor on smartphones, is planned for the future. The mobile version of VisualEditor was tweaked to show the context menu for citations instead of basic references (bug 68897). A bug that broke the editor in iOS was corrected and released early (bug 68949). For mobile tablet users, three bugs related to scrolling were fixed (bug 66697, bug 68828, bug 69630). You can use VisualEditor on the mobile version of Wikipedia from your tablet by clicking on the cog in the top-right when editing a page and choosing which editor to use.

TemplateData editor

The tool for editing TemplateData has been deployed to 30 more Wikipedias this week. Other Wikipedias and some other projects may receive access next month. This tool makes it easier to add TemplateData to the template's documentation. When the tool is enabled, it will add a button above every editing window for a template (including documentation subpages). To use it, edit the template page or a subpage, and then click the "Redigera TemplateData" button at the top. Read the help page for TemplateData. You can test the TemplateData editor in a sandbox at Mediawiki.org. Remember that TemplateData should be placed either on a documentation subpage or on the template page itself. Only one block of TemplateData will be used per template.

Andra ändringar

Several interface messages and labels were changed to be simpler, clearer, or shorter, based on feedback from translators and editors. The formatting of dialogs was changed, and more changes to the appearance will be coming soon, when VisualEditor implements the new MediaWiki theme from Design. (A preview of the theme is available on Labs for developers.) The team also made some improvements for users of the Monobook skin that improved the size of text in toolbars and fixed selections that overlapped menus.

VisualEditor-MediaWiki now supplies the mw-redirect and mw-disambig class on links to redirects and disambiguation pages, so that user gadgets that colour in these types of links can be created.

Templates' fields can be marked as 'required' in TemplateData. If a parameter is marked as required, then you cannot delete that field when you add a new template or edit an existing one (bug 60358).

Language support improved by making annotations use bi-directional isolation (so they display correctly with cursoring behaviour as expected) and by fixing a bug that crashed VisualEditor when trying to edit a page with a dir attribute but no lang set (bug 69955).

Looking ahead

The team posts details about planned work on the VisualEditor roadmap. The VisualEditor team plans to add auto-fill features for citations soon, perhaps in late October.

The team is also working on support for adding rows and columns to tables, and early work for this may appear within the month. Please comment on the design at Mediawiki.org.

In the future, real-time collaborative editing may be possible in VisualEditor. Some early preparatory work for this was recently done.

Supporting your wiki

At Wikimania, several developers gave presentations about VisualEditor. A translation sprint focused on improving access to VisualEditor was supported by many people. Deryck Chan was the top translator. Special honors also go to संजीव कुमार (Sanjeev Kumar), Robby, Takot, Bachounda, Bjankuloski06 and Ата. A summary of the work achieved by the translation community is available. Thank you all for your work.

This was the first translatable VisualEditor newsletter, so thanks to everybody who made this possible! If it hasn't been delivered in your language, and you'd like to help with translations in the future, please subscribe to the Translators mailing list or contact Elitre (WMF), so that you will be notified when the next issue is due.

VisualEditor can be made available to most non-Wikipedia projects. If your community would like to test VisualEditor, please contact product manager James Forrester or file an enhancement request in Bugzilla.

Please join the office hours on Saturday, 18 October 2014 at 18:00 UTC (daytime for the Americas; evening for Africa and Europe) and on Wednesday, 19 November at 16:00 UTC on IRC.

Give feedback on VisualEditor at mw:VisualEditor/Feedback. Subscribe or unsubscribe at Meta. Thank you! —Elitre (WMF)

13 oktober 2014 kl. 11.49 (CEST)

Globala redigeringsfilter används för att stoppa interwikispam. Eftersom vi är en liten wiki som inte har så mkt resurser att lägga på administration ser jag ingen nackdel med detta. Om ingen kommer med några invändningar inom en vecka så kommer jag att anmäla vårt intresse. Information om globala redigeringsfilter hittas på meta:GAF. //Skal 2 november 2014 kl. 00.20 (CET)

Jag tror att globala redigeringsfilter har aktiverats, som del i utrullning på mellanstora wikier. Det borde komma mer information inom några dagar. //Skal 10 november 2014 kl. 22.32 (CET)

Ja, det låter bra! ~ Dodde (diskussion) 5 december 2014 kl. 12.30 (CET)

— 14 november 2014 kl. 18.34 (CET)

Did you know?

VisualEditor is also available on the mobile version of Wikipedia. Log in and click the pencil icon to open the page you want to edit. Click on the gear-shaped settings button in the upper-right corner to pick which editor to use. Choose "⧼Mobile-frontend-editor-visual-editor⧽" to use VisualEditor, or "⧼Mobile-frontend-editor-source-editor⧽" to use the wikitext editor.

It will remember whether you used wikitext or VisualEditor, and use the same editor the next time you edit an article.

The user guide has information about how to use VisualEditor. Not all features are available on the mobile website.

Since the last newsletter, the Editing Team has fixed many bugs and requests, and worked on support for editing tables and for using non-Latin languages. Their weekly updates are posted on Mediawiki.org. Informal notes from the recent quarterly review were posted on Meta.

Recent improvements

Basic support for inserting tables and changing the number of rows and columns in them was just introduced to Wikipedias. Advanced features, like dragging columns to different places, will be added later.

To help editors find the most important items more quickly, some items in the toolbar menus are now hidden behind a "Mer" item, such as "Understrykning" in the styling menu.

The French Wikipedia should see better search results for links, templates, and media because the new search engine was turned on for everyone there. This change is expected at the Chinese and German Wikipedias this week, and the following week at the English Wikipedia.

The "pawn" system has been mostly replaced. Bugs in this system sometimes added a chess pawn character to wikitext. The replacement provides better support for non-Latin languages, with full support hopefully coming soon.

VisualEditor is now provided to editors who use Internet Explorer 10 or 11 on desktop and mobile devices. Internet Explorer 9 is not supported yet.

The keyboard shortcuts for items in the toolbar menus are now shown in the menus.

VisualEditor will replace the existing design with a new theme from the User Experience/Design group. The appearance of dialog boxes has already changed in the mobile version. The appearance on desktops will change soon. You are welcome to compare the old "Apex" design and the new "MediaWiki" theme which will replace it.

Several bugs were fixed for internal and external links. Improvements to MediaWiki's search solved an annoying problem: If you searched for the full name of the page or file that you wanted to link, sometimes the search engine could not find the page. A link inside a template to a local page that does not exist will now show red, exactly as it does when reading the page. Due to an error, for about two weeks this also affected all external links inside templates. Opening an auto-numbered link node like with the keyboard used to open the wrong link tool. These problems have all been fixed.

TemplateData

The tool for quickly editing TemplateData has been deployed to all Wikimedia Foundation wikis on Thursday, 6 November. This tool was already available on the biggest 40 Wikipedias, and now all wikis will have access to it. This tool makes it easier to add TemplateData to the template's documentation. When the tool is enabled, it will add a button above every editing window for a template (including documentation subpages). To use it, edit the template or a subpage, and then click the "Redigera TemplateData" button at the top. Read the help page for TemplateData to learn more about it. You can test the TemplateData editor in a sandbox at Mediawiki.org. Remember that TemplateData should be placed either on a documentation subpage or on the template page itself. Only one block of TemplateData will be used per template.

You can use the new autovalue setting to pre-load a value into a template. This can be used to substitute dates, as in this example, or to add the most common value for that parameter. The autovalue can be overridden by the editor, by typing something else in the field.

In TemplateData, you may define a parameter as "required". The template dialog box in VisualEditor will warn editors if they leave a "required" parameter empty, and they will not be able to delete that parameter. If the template can function without this parameter, then please mark it as "föreslagen" or "valfri" in TemplateData instead.

Looking ahead

The VisualEditor team plans to add auto-fill features for citations soon. The appearance of the media search dialog will improve, to make picking between possible images easier and more visual. The team posts details about planned work on the VisualEditor roadmap.

The user guide is being updated to add information about editing tables. The translations of the user guide for most languages except Spanish, French, and Dutch are significantly out of date. Please help complete the current translations for users who speak your language. Talk to us if you need help exporting the translated guide to your wiki.

You can influence VisualEditor's design! Tell the VisualEditor team what you want changed during the office hours via IRC. The next sessions are on Wednesday, 19 November at 16:00 UTC and on Wednesday 7 January 2015 at 22:00 UTC. You can also share your ideas at mw:VisualEditor/Feedback.

Also, user experience researcher Abbey Ripstra is looking for editors to show her how they edit Wikipedia. Please sign up for the research program if you would like to hear about opportunities.

If you would like to help with translations of this newsletter, please subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Subscribe or unsubscribe at Meta. Thank you! —Elitre (WMF)

15 november 2014 kl. 00.29 (CET)

Jag har nu avslutat min genomgång av SAOL13 (och parallellt delvis SAOB). Jag letade främst efter starka verbformer, men även efter konjunktivformer i allmänhet, och infinitiver på -s. Jag har vaskat fram en del "rådata", som nog kan vara av intresse både för starka verb i allmänhet och för konjunktiver i synnerhet.

Jag är själv litet osäker på hur man går vidare. Det visade sig vara väldigt många "å ena sidan men å andra sidan"-verb, mycket mer än vad jag väntat mig. Jag har i stort sett tagit med rubbet, ibland med rätt utförliga kommentarer. "Rubbet" inkluderar listor över sammansättningar (både med standardprefix och i övrigt). Jag tar upp starka verb, starka verb som ibland böjs svagt, svaga verb som ibland böjs starkt, och en del verb som i dag nästan aldrig böjs starkt, men som jag träffat på starka former av i exempelvis folkvisor. Vissa verb böjs olika i olika former. En hel del böjs inte helt lika i SAOL och SAOB.

Jag har försökt markera ovanligare former med parenteser, och mycket ovanliga med dubbla parenteser (men jag har nog inte varit konsekvent). Detta gäller dock inte preteritum konjunktiverna; där kan inte merän kanske en handfull sägas vara vanliga eller bara litet ovanliga. Det finns litet mer användning av dem än vad akademin valt att ta upp i SAOB och SAOL; i min början på en excerptsamling, Användare:JoergenB/Excerpter, har jag bland annat hittat former som inte finns med men akademiledamöterna själva ibland använder vid sina högtidstal. (Jag koncentrerar mig dels på modernare belägg (där dock formen "vore" bara undantagsvis tas med), dels på att illustrera olika användningsområden (och där tar jag också med citat ur en del äldre texter).

Jag har en rensad Användare:JoergenB/Konjunktivbildning i svenska#Tabell., och mina fulla Användare:JoergenB/Konjunktivbildning i svenska#Rådata. Tabellen är nog inte på bästa möjliga format. (Det är också litet för mycket jag inte begriper av mjukvaran för tabeller och mallar, vilket gör det svårare att hitta vettiga presentationsmodeller). Eftersom huvuddelen av råinsamlandet nog är avslutat, kan det vara vits för den som vill att kopiera över delar och själv bearbeta det.

Mina vaga idéer går ut på att göra dels en lista på "de starka (osammansatta) verben i svenska", med verbtema; och dels en kompakt lista över samtliga, med smidiga länkar.. Denna komme då att omfatta i storleksordningen 100-150 verb, beroende på vilka man väljer att ta med. Jag har utgått från de fyra formerna i traditionella verbtemata, när jag gjorde upp tabellen, men detta är inte givet det bästa.Fördelen är att man ser stamväxlingen tydligt, och det är just den som är mest utmärkande för de starka verben (jämte perfektparticipböjningsändelserna, som vanligtvis är -en, et, na). Jag hade litet idéer om att man också kunde ha fotnoter till anmärkningar på något smidigt sätt, så att de ej stör den som ej vill se dem.

De sammansatta formerna tar jag helst med någonstans. (Jag kan ha missat åtskilliga; och ni får gärna fylla på sådana direkt bland mina "rådata", den som vill.) Man kan tänka sig en separat alfabetisk lista över dem, för var och en av dem med någon slags hänvisning till rätt osammansatt verb. Det skulle också vara trevligt att kunna hitta sammansättningarna från de enkla verben; men jag vet inte riktigt hur man löser detta smidigt. (I en tabell över minst hundra verb är det inte så trevligt att lägga in extralistor; däremot kanske också här fotnoter.)

Om jag förstode mallarna o. d. här bättre, så skulle jag kanske också ha bättre idéer om hur man hanterar "huvudtabellen". Gör man en för starka verb och en annan för dessa verbs konjunktivformer? Finns det något smidigt sätt att göra kolumner i wikitabeller kollapsbara, så att alla ser infinitiv, pret. ind. och supinum, men de som vill också kan få se tabeller över bl. a. pret. konjunktivformerna? Jörgen B (diskussion) 16 november 2014 kl. 20.54 (CET)

Imponerande arbete! Om och isåfall hur dessa former i så fall ska presenteras i huvuduppslagen grammatikmallar är väl ingen lätt nöt att knäcka, men jag utgår ifrån att du i första hand tänker dig en sida under Appendix? Hur "detta med tabeller" fungerar beskrivs lite på Wiktionary:Stilguide/Grammatik/Skapa en mall, i synnerhet längst ned på sidan. Kanske att man hade velat ta en existerande tabell som liknar den tabell man har tänkt sig och göra ändringar i den i enlighet med de behov som finns, ex-vis att man vill slå ihop columner, rader, celler. Kollapsbar i sidled förmodligen möjligt på ett sätt eller ett annat, men osäker på om wikisyntax har stöd för det (men det finns möjlighet ex.vis med javascript och kanske css). Kanske två tabeller är enklare att arbeta med istället. ~ Dodde (diskussion) 5 december 2014 kl. 12.24 (CET)

Hej,
Jag har ett önskemål. I alla svenska verbmallar skulle Passivform av Particip Presens tas bort. Jag har hittills aldrig funnit en användning av presensparticip i passiv. Se också "SAOL Plus".--Pametzma (diskussion) 3 december 2014 kl. 13.15 (CET)

Participen i de svenska verbmallarna är inte aktiva/passiva, då de i själva verket antar en adjektivisk form. Om du avser s-formen av presensparticipen, så existerar de, och ska naturligtvis vara kvar av den anledningen. Wikipedia skriver lite om detta på w:Presens particip. Om participformer över huvud taget ska beskrivas i verbmallen kan förstås diskuteras, men det är en helt annan diskussion. ~ Dodde (diskussion) 5 december 2014 kl. 12.03 (CET)

Did you know?

Basic table editing is now available in VisualEditor. You can add and remove rows and columns from tables at the click of a button.

The user guide has more information about how to use VisualEditor.

Since the last newsletter, the Editing Team has fixed many bugs and worked on table editing and performance. Their weekly status reports are posted on mediawiki.org. Upcoming plans are posted at the VisualEditor roadmap.

VisualEditor was deployed to several hundred remaining wikis as an opt-in beta feature at the end of November, except for most Wiktionaries (which depend heavily upon templates) and all Wikisources (which await integration with ProofreadPage).

Recent improvements

Basic support for editing tables is now available. You can add and delete tables, add and remove rows and columns, set or remove a caption for a table, and merge cells together. To change the contents of a cell, double-click inside it. More features will be added in the coming months. In addition, VisualEditor now ignores broken, invalid rowspan and colspan elements, instead of trying to repair them.

You can now use find and replace in VisualEditor, reachable through the tool menu or by pressing ^ Ctrl+F or ⌘ Cmd+F.

You can now create and edit simple <blockquote> paragraphs for quoting and indenting content. This changes a "Stycke" into a "Blockcitat".

Some new keyboard sequences can be used to format content. At the start of the line, typing "* " will make the line a bullet list; "1." or "#" will make it a numbered list; "==" will make it a section heading; ": " will make it a blockquote. If you didn't mean to use these tools, you can press undo to undo the formatting change.

There are also two other keyboard sequences: "[[" for opening the link tool, and "{{" for opening the template tool, to help experienced editors. The existing standard keyboard shortcuts, like ^ Ctrl+K to open the link editor, still work.

If you add a category that has been redirected, then VisualEditor now adds its target. Categories without description pages show up as red.

You can again create and edit galleries as wikitext code.

Looking ahead

The current VisualEditor design will be replaced with a new theme designed by the User Experience group. The new theme will be visible for desktop systems at mediawiki.org in late December and on other sites in early January. (You can see a developer preview of the old "Apex" theme and the new "MediaWiki" one which will replace it.)

The Editing team plans to add auto-fill features for citations in January.

Planned changes to the media search dialog will make choosing between possible images easier.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Translations of the user guide for most languages are outdated. Only Ukrainian, Portuguese, Spanish, French, and Dutch translations are nearly current. Please help complete the current translations for users who speak your language.
• Talk to the Editing team during the office hours via IRC. The next session is on Wednesday, 7 January 2015 at 22:00 UTC.
• File requests for language-appropriate "Fet" and "Kursiv" icons for the character formatting menu in Phabricator.
• The design research team wants to see how real editors work. Please sign up for their research program.
• If you would like to help with translations of this newsletter, please subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Subscribe or unsubscribe at Meta. Thank you!

— Elitre (WMF)

26 december 2014 kl. 19.59 (CET)

Nuvarande verbmallar stödjer inte partikelverb, vilket framstår som en ganska stor brist. Vad sägs om att lägga till en ny partikel-parameter till nuvarande verbmallar? Böjningstabellen för "se till" skulle då kunna genereras med

{{sv-verb-r|pret=såg|partikel=till}}

Om det underlättade implementationen skulle parametern kunna anges som partikel= till, dvs. med ett inledande blanksteg. Det borde vara ganska lätt att integrera i mallarna. För enkelhets skull skulle man kunna låta participformerna fortsätta att fungera som de gör nu, dvs. användaren skulle alltid behöva ange dem uttryckligen för partikelverb.

Tango24 (diskussion) 11 januari 2015 kl. 16.20 (CET)

Det är bra att du tar upp denna diskussionen. Jag tror att vi för väldigt länge sedan kom fram till att flerordsuppslag inte skulle ha länkade böjningsformer om deras böjningsmönster helt och hållet framgick av böjningstabellen på uppslagen för dess respektive delar. Vid vissa tillfällen hat böjningsmallar använts på flerordsuppslags, men utan att de länkas, t.ex. på organiserad brottslighet. Detta skulle man kunna ha på ännu fler uppslag och ditt förslag tycker jag verkar bra (förutom att en rot=-parameter behövs). Kanske kunde användning av partikel= automatiskt göra så att länkarna tas bort. "85" 12 januari 2015 kl. 18.04 (CET)

Som ÅttioFem säger. De böjningsformer som böjningstabeller länkar till bör ha egna böjningsuppslag, men vi har sagt att böjningsuppslag inte ska finnas för flerordsuppslag då det skulle innebära en väldig ökning av antalet sidor utan att tillföra ordboken speciellt mycket. När det undantagsvis är relevant att ha en böjningstabell för ett flerordsuppslag behöver man då se till att böjningsformerna inte länkas. Det finns i nuläget inget inbyggt i mallarna utan man får lösa det manuellt som exempelvis på plante verte. Jag tänker också att det komplicerar mallkoden för mycket för att lägga till det (och görs det på en mall vill man ju gärna att motsvarande funktionalitet ska finnas i alla mallar). Med tanke på hur många enordsuppslag som saknar böjningsmall så känns det tveksamt att prioritera tilläggandet av mallar för flerordsuppslag. Partikelverb är lite speciella av en anledning och det är hur många av dem ger upphov till avledningar, att exempelvis säga upp har ett motsvarande perfektparticip uppsagd. Det talar för att vi egentligen skulle behöva en lösning. En specialmall för partikelverb som i princip hänvisar till böjningstabellen i säga men att tabellen förutom det även redovisar participen. Någon sådan mall har vi inte, men det skulle troligen vara önskvärt. ~ Dodde (diskussion) 8 april 2015 kl. 11.05 (CEST)

Jag har skrivit ett skript som konverterar uppslagsord i Lexin-lexikonen till Wiktionary-format (med hjälp av böjningar från Saldo). Både Lexin och Saldo har CC-BY-licens, så resultatet bör gå att importera här om man bara ger erkännande på rätt sätt. Skriptet behöver finputsas en aning (adjektivhantering kan förbättras och ordspecifika böjningar av adverb stöds inte än). Jag roade mig med att köra skriptet på ord från svenska wiktionary:s lista över önskade ord. Den som är intresserad får gärna ta sig en titt på resultatet . Jag tar gärna emot synpunkter och kommentarer. Tango24 (diskussion) 12 januari 2015 kl. 22.38 (CET)

Vad innebär CC-BY-licens? Menar du att vi kan använda oss av all information från dessa ordböcker om de bara erkänner det, och finns det i så fall ingen risk för att det rör sig om upphovrättsbrott? Resultatet som du länkade till såg för det mesta bra ut. Jag tycker att det nog skulle kännas schystare att använda egna exempelmeningar åtminstone. Det skulle inte se så bra ut om man kan se att informationen här är exakt densamma som i Lexin. Är tanken att alla (svenska) ord i lexin ska skapas med hjälp av scriptet? "85" 13 januari 2015 kl. 11.42 (CET)

Om licensen och idén bakom en konvertering

Med CC-BY menar jag . Uttryckt på svenska: "Licensen Creative Commons erkännande innebär att du, som upphovsman, tillåter andra att använda, sprida, göra om, modifiera och bygga vidare på ditt verk, även i kommersiella sammanhang. De som använder dina Creative Commons licensierade verk ska uppge att det är du som upphovsman, när de använder, bearbetar eller sprider ditt verk".

Lexin byggdes upp bl.a. för SFI-undervisning och 2013 fick Språkrådet för att "stimulera utvecklingen av teknik som gagnar språken i Sverige och bidrar till ökad tillgänglighet till information och service". Det är alltså inte på något sätt ojust att använda dessa data - tvärtom! Själva tanken med ovanstående projekt var ju just att de skulle spridas och komma till användning. Och om exempelmeningarna är bra, så varför inte använda dem även här?

Med "erkännande" menar jag att man måste hänvisa till upphovsmännen/licensgivarna ( och ) med namn och länk, samt ange vilken CC-licens som gäller med namn och länk. Något tillstånd utöver det som CC-licensen redan beviljat behövs inte. När CC-licensierat material återanvänds mellan olika wiki-projekt verkar det vara praxis att ange detta i ändringsloggen, men eftersom det här handlar om externt material är det kanske bra att lägga det i en fotnot så att det blir litet mer synligt.

Fördelen med att konvertera Lexin till Wiktionary-format (och ja, det kan göras för alla 28 000 Lexin-uppslag) är att man snabbt skulle kunna få wiktionary att täcka en betydligt större del av svenska språket, all information skulle bli möjlig att redigera och fler uppslag skulle kunna uppmuntra till nya bidrag och fler översättningar. Översättningar skulle också kunna anges mer specifikt för vissa betydelser av ord. Målet är självklart inte att bli en Lexin-kopia, utan att bana väg för något större och mer omfattande. Det vore jätteintressant att höra mer av vad ni andra tänker om detta. Tango24 (diskussion) 13 januari 2015 kl. 12.42 (CET)

Statistik

Jag gjorde en snabb koll och kan konstatera att användning av Lexin-data skulle kunna ge på Wiktionary. Så många Lexin-ord saknas nämligen här. Många av dessa är, som framgår av den länkade listan, ganska vanliga ord som borde finnas representerade här. Totalt verkar det i Lexin finnas 22 158 unika ord. De uppslag som redan existerar skulle kunna kompletteras med översättningar, exempel och annat från Lexin.

Ok, tack för informationen! Detta låter som en väldigt fin idé. Visar det sig att vi kommer behöva kontrollera drygt 5000 robotskapade uppslag så är jag gärna med och gör det. "85" 16 januari 2015 kl. 16.26 (CET)

Jag tycker det låter som ett bra förslag, så ni räkna med min hjälp i kontrolläsandet också. Jag gjorde en snabbkoll på lexins uppslag och såg att viss information av orden är minst sagt knaper (t.ex. deras uppslag för krukväxter som begonia), men det kan man som sagt komplettera om det finns en checklista att gå efter. Gött initiativ, Tango24! ╰ Svenji 17 januari 2015 kl. 02.09 (CET)

Kul att ni ställer er positiva till idén. Jag ska göra litet förbättringar av skriptet innan jag gör en mer skarp konverteringen. Ett par funderingar och frågeställningar som jag eventuellt behöver hjälp med: 1) bör serbiska översättningar skrivna med kyrilliska respektive latinska bokstäver blandas eller delas upp? (uppdelning verkar vara vanligare på engelska wiktionary) 2) hur hanteras nordkurdiska/sydkurdiska bäst och bör man använda samma språkkod för båda? 3) Finns det någon mall för erkännande av externt CC-licensierat material (t ex. något som skulle passa att använda som fotnot)? Om inte, kanske det vore värt att skapa för att få enhetlighet i hur erkännandet presenteras. Jag vore tacksam för hjälp med det i sådana fall.

Lexin använder presens i definitionen av verb. Eftersom de flesta definitioner är ganska korta kanske man skulle spara en del jobb på att låta skriptet försöka automatiskt konvertera till infinitiv. Ska ta mig en titt på det. En annan sak som saknas i nuläget är wikilänkar i definitionen. Om jag får tid tänkte jag se om det skulle finnas möjlighet att lägga in en del länkar automatiskt, kanske grundat på ordfrekvensdata. Tango24 (diskussion) 18 januari 2015 kl. 22.39 (CET)

Jag kom att tänka på engelskspråkiga Wiktionary och hur de använt bl.a. Webster's Dinctionary som start för många uppslag då Wiktionary ännu låg i sin vagga. Man skulle kunna titta på och fråga hur de gjorde med sina importer. Se diskussioner vidare här: Wiktionary_talk:Public_domain_sources

Vad gäller serbiska så skrivs det i officiella sammanhang med kyrilliska bokstäver idag, medan det latinska alfabetet ofta används i vardagssammanhang. Därför bör väl bägge skrivsätten finnas med i vår dokumentation. Hur menar du med delas upp/blandas? Jag tror att uppslaget sto återger den standard vi hittills har för serbiska i nuläget, men jag skulle gärna se en mer uppfinningsrik lösning om någon har en bättre idé. Jag är inte ett fans av blandade skrifter under samma språkkod egentligen, då det blir väldigt rörigt och ger en irrbild i statistiken. ╰ Svenji 18 januari 2015 kl. 23.38 (CET)

Toppenidé Tango24!

Angående erkännandet så tänker jag att det inte är bra om mallar läggs till på uppslaget på sådant sätt att det riskerar att leda till att man inte fortsätter att förbättra uppslaget för att en mall på något sätt markerar att detta hör till något annat och bör inte ändras. Det får heller inte vara så att en mall säger att ett visst innehåll kommer från en annan källa, när innehållet sedan dess har ändrats. Det bästa vore ju om man även här vid själva tilläggandet skriver källa i sammanfattningen för redigeringen som vi brukar göra. "+Översättning från ". Eftersom det rör sig om väldigt många uppslag, definitioner, exempelmeningar och översättningar kanske man ska ta en kontakt med Språkrådet och höra deras inställning till detta sätt att lösa det eller om de har något annat bra förslag. När det gäller exempelmeningar så är det bra att vi anger källan, som vanligt, direkt på uppslaget.

Angående serbiska så låter det bra för serbiska uppslag som Svenji sa, men jag tänker att du menade hur vi gör med serbiska översättningar. Det har diskuterats tidigare och det ska göras som på Zambia, *serbiska: {{ö|sr|Замбија}}, {{ö|sr|Zambija}}. Inga konstigheter, inget krusidull. Vi behöver inte skriva att översättningen är med latinska eller kyrilliskt alfabet, det framgår ju av bokstäverna. Alla serbiska översättningar har inte ändrats till det här formatet ännu, men helst ska det se ut så här. ~ Dodde (diskussion) 8 april 2015 kl. 11.39 (CEST)

Hei til alle svenskpråklige! Enhver som føler seg kallet, er herved invitert til å hjelpe norsk Wiktionary med oversettelser til svensk. Se gjerne her for en kategori med artikler som mangler oversettelse til svensk. På forhånd takk for hjelpen.
- Teodor (d • b) 24 januari 2015 kl. 19.24 (CET)

Hej, skulle gärna se att ovannämnda mall uppdaterades så att den även innehöll det könsneutrala ordet hen. Har försökt göra det på egen hand men har gått bet på det. Om någon antingen gjorde det själv eller gav en instruktion på hur det skulle göras så vore jag tacksam. Tack på förhand. Cyan samurai (diskussion) 2 februari 2015 kl. 20.57 (CET)

@Cyan samurai, det har diskuterats förut och då var slutsatsen att ordet inte skulle med. Nu, några år senare, anser jag att situationen är en annan och har fortsatt diskussionen på Malldiskussion:sv-pron-pers#Icke vedertagna former. Om någon annan som varit med på Wiktionary ett tag tycker att det verkar som en bra idé så lägger jag till det. //Skal 21 februari 2015 kl. 22.29 (CET)

Jag fick en kommentar, så jag har lagt till det. //Skal 22 februari 2015 kl. 00.26 (CET)

Since the last newsletter, the Editing Team has fixed many bugs and worked on VisualEditor's appearance, the coming Citoid reference service, and support for languages with complex input requirements. Status reports are posted on mediawiki.org. Upcoming plans are posted at the VisualEditor roadmap.

The Wikimedia Foundation has named its top priorities for this quarter (January to March). The first priority is making VisualEditor ready for deployment by default to all new users and logged-out users at the remaining large Wikipedias. You can help identify these requirements. There will be weekly triage meetings which will be open to volunteers beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC). Tell Vice President of Engineering Damon Sicore, Product Manager James Forrester and other team members which bugs and features are most important to you. The decisions made at these meetings will determine what work is necessary for this quarter's goal of making VisualEditor ready for deployment to new users. The presence of volunteers who enjoy contributing MediaWiki code is particularly appreciated. Information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins.

Due to some breaking changes in MobileFrontend and VisualEditor, VisualEditor was not working correctly on the mobile site for a couple of days in early January. The teams apologize for the problem.

Nyliga förbättringar

The new design for VisualEditor aligns with MediaWiki's Front-End Standards as led by the Design team. Several new versions of the OOjs UI library have also been released, and these also affect the appearance of VisualEditor and other MediaWiki software extensions. Most changes were minor, like changing the text size and the amount of white space in some windows. Buttons are consistently color-coded to indicate whether the action:

• starts a new task, like opening the ⧼visualeditor-toolbar-savedialog⧽ dialog: blå ,
• takes a constructive action, like inserting a citation: grön ,
• might remove or lose your work, like removing a link: röd , eller
• is neutral, like opening a link in a new browser window: grå .

The TemplateData editor has been completely re-written to use a different design based on the same OOjs UI system as VisualEditor. (T67815, T73746.) This change fixed a couple of existing bugs and improved usability. (T73077, T73078.)

Search and replace in long documents is now faster. It does not highlight every occurrence if there are more than 100 on-screen at once.(T78234.)

Editors at the Hebrew and Russian Wikipedia requested the ability to use VisualEditor in the "Article Incubator" or drafts namespace. (T86688, T87027.) If your community would like VisualEditor enabled on another namespace on your wiki, then you can file a request in Phabricator. Please include a link to a community discussion about the requested change.

Spaning framåt

The Editing team will soon add auto-fill features for citations. The Citoid service takes a URL or DOI for a reliable source, and returns a pre-filled, pre-formatted bibliographic citation. After creating it, you will be able to change or add information to the citation, in the same way that you edit any other pre-existing citation in VisualEditor. Support for ISBNs, PMIDs, and other identifiers is planned. Later, editors will be able to contribute to the Citoid service's definitions for each website, to improve precision and reduce the need for manual corrections.

We will need editors to help test the new design of the special character inserter, especially if you speak Welsh, Breton, or another language that uses diacritics or special characters extensively. The new version should be available for testing next week. Please contact User:Whatamidoing (WMF) if you would like to be notified when the new version is available. After the special character tool is completed, VisualEditor will be deployed to all users at Phase 5 Wikipedias. This will affect about 50 mid-size and smaller Wikipedias, including Afrikaans, Azerbaijani, Breton, Kyrgyz, Macedonian, Mongolian, Tatar, and Welsh. The date for this change has not been determined.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Please help complete translations of the user guide for users who speak your language.
• Join the weekly bug triage meetings beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC); information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins, and you can also contact James F. to learn more about this initiative.
• Talk to the Editing team during the office hours via IRC. The next session is on Thursday, 19 February 2015 at 19:00 UTC.
• Subscribe or unsubscribe at Meta. If you would like to help with translations of this newsletter, please subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

— Elitre (WMF)

5 februari 2015 kl. 19.30 (CET)

Hej. En ny policy gällande avlägsnande av "avancerade rättigheter" (administratörer, byråkrater etc) antogs 2013 genom global gemenskapskonsensus. I enlighet med detta konsensus genomför stewards en kontroll av administratörers aktiviteter på alla wikis inom Wikimediastiftelsen som inte har någon inaktivitetspolicy. Vi har förstått att ni på er wiki saknar en formell policy för att avlägsna avancerade rättigheter från inaktiva användare. Detta innebär att stewards kommer att utföra detta i linje med aktivitetskontroll av admins.

Vi har funnit att följande användare är inaktiva enligt de kriterier som fastställts (inga redigeringar och inga adminåtgärder under de två senaste åren):

1. Bounce1337 (administratör)
2. Calandrella (administratör)
3. Natox (administratör)

Dessa användare kommer snart att få förfrågan om att starta en gemenskapsdiskussion om de vill behålla några eller alla rättigheter. Om användarna inte svarar, kommer deras avancerade rättigheter att avlägsnas av Stewards.

Om ni däremot som gemenskap föredrar att skapa er egen aktivitetskontroll som ersätter den globala, har en annan åsikt om dessa inaktiva administratörer, eller redan har en policy som vi har missat, ber vi er informera stewards på Meta-Wiki så att vi kan avsluta aktivitetsukontrollen på er wiki. Tack, Openbk (talk) 7 februari 2015 kl. 00.03 (CET)

Jag tycker att detta låter som en bra idé - mindre administrativt arbete. //Skal 21 februari 2015 kl. 22.32 (CET)

Jag tycker nog att det är snyggare med kursivering (se t.ex. denna ändring). Vad tycker ni andra? Finns det redan någon norm i frågan? --Andreas Rejbrand (diskussion) 18 februari 2015 kl. 14.58 (CET)

Mallen Mall:ö-förfråga/förfrågan/förfrågning är markerad för snabbradering. Den används emellertid i t.ex. förfrågning. Vad tycker gemenskapen om den här sortens mallar? --Andreas Rejbrand (diskussion) 27 februari 2015 kl. 23.58 (CET)

Jag har länkat om översättningarna på förfråga och förfrågning till förfrågan med {{ö-se}}. Så jag har också raderat {{ö-förfråga/förfrågan/förfrågning}}. //Skal 3 mars 2015 kl. 22.26 (CET)

Hi, this message is to let you know that, on domains like sv.m.wikipedia.org, unregistered users cannot edit. At the Wikimedia Forum, where global configuration changes are normally discussed, a few dozens users propose to restore normal editing permissions on all mobile sites. Please read and comment!

Thanks and sorry for writing in English, Nemo 1 mars 2015 kl. 23.32 (CET)

Det verkar som om en del av våra västerbottniska artiklar också kategoriseras under Kategori:Svenska/Alla uppslag och en tillhörande ordklasskategori, såsom Kategori:Svenska/Substantiv, medan andra inte gör det. Exempel på förra fallet är fługusopp och bráttum medan andra fallet exemplifieras av forshnakk’ och forórð’.

Vad föredrar vi? Personligen tycker jag det känns lite konstigt att stöta på ord såsom fługusopp och bráttum när jag går igenom ett index över "svenska" ord. Jag skulle alltså spontant föreslå att så här pass dialektala ord inte listas i de allmänna svenska kategorierna. Vad tycker ni andra?

I vilket fall som helst borde vi förstås vara konsekventa. --Andreas Rejbrand (diskussion) 3 mars 2015 kl. 15.57 (CET)

Samma sak som för västerbottniska gäller för umemål: jämför skȧm (i svenska index) med skrähni (utan svenska index). --Andreas Rejbrand (diskussion) 3 mars 2015 kl. 16.01 (CET)

Jag håller med om att orden inte passar i rikssvenska kategorier. Går det att avkategorisera ord som hnefa, samtidigt som man behåller någon sorts böjningsmall? — Knyȝt (diskussion) 3 mars 2015 kl. 16.53 (CET)

Notering: Samma kategorisering finns hos andra dialektala ord, t. ex. ajkwönn och pantofflagröd. — Knyȝt (diskussion) 3 mars 2015 kl. 17.16 (CET)

Med nuvarande mallar måste uppslagen kategoriseras i den kategori som står som språk (alltså svenska). Det skulle vara lätt att justera mallar som {{subst}} till att kategorisera sidan i egen underkategori, om behovet verkligen finns. Rör det sig om så pass många ord att det skulle bli störande? Är den här stavningen vedertagen bland dialekternas talare (om inte ska orden nog inte med över huvud taget)? //Skal 3 mars 2015 kl. 22.04 (CET)

Enligt min mening är frågan helt och hållet strukturteknisk och att avvika från följande känns inte rimligt. Alla språkkoder som används bör ha en egen språkrubrik. Bestäms att ett uppslag ska ha en viss språkrubrik så ska motsvarande språkkod användas, och också kategoriseras bland andra uppslag tillhörande samma språk. Om en diskussion ska föras bör den nog istället gälla om botniamål/västerbottniska/umemål osv. som nämnts bör hanteras som enskilda språk eller som en del av svenska. Oavsett kategorisering framgår det i vanlig ordning på uppslaget att orden är dialektala så det bör inte ske några missförstånd där. Älvdalska hanterar vi för närvarande som ett eget språk (liksom fornsvenska). Genuina dialekter över lag känns rimligt att göra det med. Men det krävs nog någon som kan detta bättre för att styra upp det. ~ Dodde (diskussion) 8 april 2015 kl. 12.19 (CEST)

Ord som vi klassar som svenska ska listas i Kategori:Svenska/Alla uppslag, även de dialektala. Enda anledningen jag kan se till att inte lista t ex västerbottniska ord i de svenska kategorierna, är om man anser att västerbottniska inte är en svensk dialekt, utan ett eget språk. Däremot hade det inte varit fel med fler appendix, t ex ett för maträtter på svenska. I sådana appendix är de rikssvenska orden oftast de mest relevanta och då "slipper" läsaren t ex skånska pantofflagröd. /Jiiimooh » DISKUSSION – BIDRAG 14 april 2015 kl. 07.23 (CEST)

Västerbottniska ligger numera under taggen botniamål med neutral stavning, och det skulle vara väldigt tjänligt och behändigt att ha dessa uppslag under egen språkbetecknelse. Tanken är att alla mål kring bottenviken ryms inom denna kategori. Om det borde kallas just botniamål kan förstås diskuteras. — Knyȝt (diskussion) 25 maj 2015 kl. 14.38 (CEST)

Det faktum att översättningar till svenska för hela meningar läggs till betyder att vi absolut bör behandla det som ett språk, trots att språkkod saknas. Vi behöver alltså definiera både språknamn och -kod själva, något som @Knyȝt antagligen gör bäst. Om "botniamål" är språknamn, så skulle t.ex. någon av följande koder fungera: sv-bot, sv-bt.

Jag tycker också att vi behöver ha ett uppslag om botniamål, om ordet är tillräckligt vedertaget. Om det inte är det så bör vi fundera på att använda något annat språknamn. Om inget kan hittas så bör vi ändå beskriva språket i Wiktionary-namnrymden. Detsamma gäller västerbottniska.

Jag kan vara behjälplig med grundläggande grammatikmallar så småningom. //Skal 8 augusti 2015 kl. 19.47 (CEST)

Namnet botniamål kommer från den här bloggen. Ordet i sig är väl sådär halvlyckat; mål betyder dialekt, och botnia är latin, vilket känns onödigt. På engelska Wikipedia kör de med Westrobothnian, och vi kanske helt enkelt borde köra med namnet västerbottniska också, men bottniska kanske är bättre eftersom det låter neutralare i modernt språkbruk. — Knyȝt (diskussion) 10 augusti 2015 kl. 14.45 (CEST)

Västerbottniska eller bottniska låter bra för mig. Om vi ska försöka hitta språkkod, vad väljer vi? Om vi utgår från en-wp så är några kandidater till prefix: indoeuropeiska språk (ine), germanska språk (gem), nordiska språk (gmq), svenska (sv). Vilket av dessa tycker du känns mest specifikt, men ändå korrekt? Som suffix kan vi använda t.ex. bot eller bt.

Vilka mallar behövs? Substantivmallar för mask., fem. och neutr. med samma struktur som svenska substantivmallar? Behövs någon verb- eller adjektivmall, och vilka former ska förekomma i så fall? //Skal 11 augusti 2015 kl. 22.28 (CEST)

gmq-bot blir nog bra. Ja, subst. i mask., fem. och neutr. med nominativ- och dativböjning — dvs. som svenska mallen fast men dativ i stället för genitiv. För verb duger en mall med passiv form och en utan passiv form, men hur beskriver vi egentligen de här skillnaderna i verb på Wiktionary? I mallen för falla står ju "aktiv", men det kanske är olika sammanhang. Om adjektiv tror jag att de flesta som regel bara tar fyra former: stærk, stærkene, stærkest, och stærkt. — Knyȝt (diskussion) 13 augusti 2015 kl. 01.54 (CEST)

Jag tror att vi ser det som att "falla" har den aktiva formen, även om betydelsen väl är passiv.

Verb: alltså som {{sv-verb-ar}} och {{sv-verb-ar-ejpass}}. Adjektiv: vad heter formerna? //Skal 13 augusti 2015 kl. 13.11 (CEST)

stærk motsvarar svenska "stark", "starke" och "starka", stærkene motsvarar "starkare", och stærkest motsvarar "stakaste" och "starkast". stærkt "starkt". Annars motsvarar det nog den svenska mallen. — Knyȝt (diskussion) 13 augusti 2015 kl. 17.49 (CEST)

@Knyȝt, följande är gjort:

• Nytt språk med namn "bottniska" som {{gmq-bot}}
• Nya grammatikmallar, se Wiktionary:Stilguide/Grammatik/Bottniska
  • Se exempel på {{gmq-bot-adj}} på stærk. Ser det bra ut och fungerar attributivt och predikativt på samma sätt som i svenskan?
  • I nuläget är mallarna "dumma" och innehållet i en ruta påverkar sällan innehållet i någon annan. T.ex. på svenska så sätts passivformen automatiskt till aktiv+s. Ska några sådana enkla regler läggas till?
  • På svenska har vi adjektiv som kompareras "perifrast", dvs. med "mer" och "mest". Se t.ex. fantastisk. Ska vi göra något liknande för bottniska, och vad heter i så fall "mer" och "mest"? Jag planerar också att lägga till en mall för okomparerbara adjektiv.

//Skal 13 augusti 2015 kl. 22.25 (CEST)

Jag kan inte minnas att jag någon gång stött på komparativ form attributivt, men det går ju inte direkt att påvisa att det inte förekommer, så det kanske vi ska låta vara så länge.

Vissa väldigt vanliga böjningsmönster kan ju vara bra att lägga till. Adjektiv böjs som regel såsom stærk, alltså komp. -ene sup. -est, eller i färre fall med lite annan vokal: -ane, -ast. En mall motsvarande böjningen i stærk skulle vara praktisk.

För substantiv finns det många böjningsmönster som verkar vara väldigt bestämda.

Maskuliner: Kortstaviga enstavingar böjs som veg* och dag. Långstaviga enstavingar böjs som skóg* och kæll. Kortstaviga tvåstavingar böjs som maga och hnefa. Långstaviga tvåstavingar böjs som goss’ och handlóf’. *ibland har g:et i dat. bfsg. mjuknat

Fortsättning följer om fler genus. Tillsvidare kan jag nämna ett par allmänna saker: Ord med grav accent eller tvåtoppsaccent (t. ex. svału och guss’) har i alla tre genus oböjd form i nom. obfpl. och dat. obfsg. och samtliga ord böjs -um i dat. obfpl. och dat. bfpl.; t. ex. fingr, hvurr’, græn, vætn etc. — Knyȝt (diskussion) 15 augusti 2015 kl. 00.04 (CEST)

Jag har ändrat några uppslag . Du får gärna hjälpa till att konvertera existerande uppslag, men det är väl inte direkt bråttom. //Skal 13 augusti 2015 kl. 23.16 (CEST)

Jag kommer då inte behöva stå sysslolös den närmsta tiden. — Knyȝt (diskussion) 15 augusti 2015 kl. 00.04 (CEST)

Nej, det finns ju några uppslag att fixa. För att hjälpa till med det så skrev jag ett skript som försöker göra några av ändringarna automatiskt (men man måste bekräfta, för det kan inte fixa allt och det kan bli fel). Du testar det genom att lägga in följande på din common.js:

mw.loader.load('//sv.wiktionary.orghttps://sv.wiktionary.org/w/index.php?title=User:Skalman/konvertera_bottniska.js&action=raw&ctype=text/javascript');

En knapp bör dyka upp bredvid aktuella Svenska-rubriker. Säg till om det inte fungerar, eller om du kommer på ytterligare någon ändring som skriptet borde göra automatiskt. //Skal 16 augusti 2015 kl. 00.17 (CEST)

Det funkar fint! — Knyȝt (diskussion) 16 augusti 2015 kl. 11.55 (CEST)

This March, we’re organizing an Inspire Campaign to encourage and support new ideas for improving gender diversity on Wikimedia projects. Less than 20% of Wikimedia contributors are women, and many important topics are still missing in our content. We invite all Wikimedians to participate. If you have an idea that could help address this problem, please get involved today! The campaign runs until March 31.

All proposals are welcome - research projects, technical solutions, community organizing and outreach initiatives, or something completely new! Funding is available from the Wikimedia Foundation for projects that need financial support. Constructive, positive feedback on ideas is appreciated, and collaboration is encouraged - your skills and experience may help bring someone else’s project to life. Join us at the Inspire Campaign and help this project better represent the world’s knowledge!

• Inspire Campaign main page

(Sorry for the English - please translate this message!) MediaWiki message delivery (diskussion) 4 mars 2015 kl. 21.01 (CET)

Det finns ett typografiskt fel i åtminstone mallen Mall:sv-subst-t-0 vilket syns i tempus, där det står "tempuset, (tempus)". Det här är, som synes, ett exempel på "dubbla avgränsare". Kommatecknet eller parentesen måste bort. Kan någon som är insatt i böjningsmallarna kommentera -- eller, helst, ändra -- detta? --Andreas Rejbrand (diskussion) 9 mars 2015 kl. 22.11 (CET)

Ah, det var visst fritext, så problemet låg i artikelns användning av mallen, och inte i själva mallen. Jag åtgärdade fritextfälten. --Andreas Rejbrand (diskussion) 9 mars 2015 kl. 22.12 (CET)

Jag ser att det finns en artikel för ärans och hjältarnas språk, men inget för mellanmjölkens land. Detta är ju (väl?) citat av Tegnér respektive Jonas Gardell. Borde de ligga i Wiktionary eller kanske i Wikiquote? Finns det någon regel eller princip som styr detta? Ett nytt uttryck som hörs ibland är "den humanitära stormakten" som halvironisk beteckning på Sverige. Är den tillräckligt etablerad för att få en egen artikel? Hur drar man den gränsen? Finns det någon inspiration i regelverken för andra språk av Wiktionary för att avgöra detta? --LA2 (diskussion) 15 mars 2015 kl. 18.39 (CET)

Grundregeln är förstås att vi inte skall ha med rena citat i ordboken, men om fraserna biter sig fast i det allmänna medvetandet och börjar fungera som byggstenar i nya texter (liksom vanliga ord) hos olika författare så bör vi ha med dem. Exempelmeningen i din länkade artikel antyder att frasen används på det sättet, åtminstone en gång i DN. Bedömningen om uttrycket är tillräckligt utbrett för att det skall få en artikel eller inte sker rimligtvis på samma sätt som för vanliga ord. --Andreas Rejbrand (diskussion) 15 mars 2015 kl. 22.37 (CET)

"Sverige är en humanitär stormakt" enligt utrikesdeklarationen 2013 (PDF, sid. 10). Och uttrycket återfinns i 12.000 andra Google-träffar. Men är det antalet Google-träffar vi räknar, eller vad? Sådana här fraser kommer ju inte in i SAOL. Jag vill förtydliga att jag inte argumenterar för att skapa en artikel, utan jag vill veta vilka våra principer är. Termen smart telefon är ju ett generellt begrepp, bara en särskriven sammansättning. Men "humanitär stormakt" och "mellanmjölkens land" är inga generella begrepp utan används enbart av svenskar som en beskrivning av eller poetisk omskrivning för Sverige, alltså ungefär som "ärans och hjältarnas språk". --LA2 (diskussion) 16 mars 2015 kl. 00.38 (CET)

"humanitär stormakt" skall vi definitivt inte ha som artikel, eftersom det inte är ett begrepp i sig i den meningen att betydelsen skiljer sig från den man får av de två delorden i sig. Man kan lika gärna säga att Sverige är en "välutvecklad monarki" eller ett "långsmalt konungarike". Termernas innebörd följer direkt av de två delordens innebörd. Detta gäller däremot inte för "ärans och hjältarnas språk", och egentligen inte för "smart telefon", heller. Så dessa artiklar är motiverade. --Andreas Rejbrand (diskussion) 16 mars 2015 kl. 01.36 (CET)

Där är jag inte enig. Det är inte två ord vilka som helst, som kombineras ihop dagligen, utan en bestämd fras som har en bestämd översättning (precis som "smart telefon" eller ett sammansatt ord), och som kan härledas till ett visst ursprung (endera utrikesdeklarationen 2013 eller något tidigare dokument). --LA2 (diskussion) 16 mars 2015 kl. 10.02 (CET)

Nu läser jag sällan litteratur som innehåller den aktuella frasen, men jag har lite svårt att se hur betydelsen av frasen humanitär stormakt skiljer sig från den betydelse man får från de två enskilda orden. Kan du förklara skillnaden mellan "humanitär stormakt" och "humanitär" "stormakt"? Och är inte t.ex. den engelska översättningen helt enkelt humanitarian superpower? --Andreas Rejbrand (diskussion) 16 mars 2015 kl. 16.20 (CET)

den humanitära stormakten, om den frasen används för att specifikt beteckna landet Sverige, är en helt annan sak, däremot; inget av de ingående orden har något specifikt med landet Sverige att göra. --Andreas Rejbrand (diskussion) 16 mars 2015 kl. 16.31 (CET)

Vi kan nämna och förklara "humanitär stormakt" i humanitär och/eller stormakt på olika sätt. Kanske enklast i en exempelmening, men man kan även beskriva det under "användning" (mallen {{användning}}) om det är relevant, eller om det är fråga om en kollokation (och det är det jag tror att du LA2 menar att det är fråga om här) så kan man ange det som en vanlig konstruktion med mallen {{konstr}}. Som Andreas säger uttrycker inte "humanitär stormakt" idiomaticitet (se Wiktionary:Stilguide/Vilka ord skall tas med#Idiomaticitet) men om "Den humanitära stormakten" skulle vara en benämning på Sverige är det en annan sak. ~ Dodde (diskussion) 8 april 2015 kl. 12.39 (CEST)

Är det möjligt att logga in permanent och inte bara under en 30-dagarsperiod? Jag brukar inte märka att jag är utloggad förrän efter några redigeringar och även om det inte är hela världen är det roligare att få cred för de ändringar man gör (nu senast under ip 213.89.108.55). /Elias Mossholm (diskussion) 15 mars 2015 kl. 23.04 (CET)

@Eliashedberg, jag tror inte att det går att logga in mer permanent (på ett lätt/bra sätt). För att märka om man är inloggad/utloggad kan man ändra utseendet på något sätt (t.ex. göra inloggningslänken och/eller redigeringsrutan stor och röd när man är utloggad, eller göra någon stor förändring när man är inloggad som att byta tema eller gömma loggan).

Förändringar som sker när du är inloggad gör du på Special:MyPage/common.css (eller .js). För att göra förändringar när du är utloggad behöver du ett "tillägg" som Stylish eller Greasemonkey för Firefox, eller Stylish eller Tampermonkey för Chrome (jag känner inte till om det finns tillägg för andra webbläsare).

Om du behöver vidare hjälp med hur du gör för att ändra utseende, säg hur du vill ha det, så ska jag försöka förklara noggrannare. //Skal 22 mars 2015 kl. 20.57 (CET)

Tack för tipset! Om det går att göra "Spara sidan"-knappen röd om man inte är inloggad så vore det tacknämligt, går det? Jag har Tampermonkey installerad sedan tidigare men så vitt jag minns lyckades jag inte riktigt få den att göra det jag ville den gången (stänga av Chromes autofyllfunktion på minasidor.telenor.se, det är dock inte aktuellt längre). /Elias Mossholm (diskussion) 7 april 2015 kl. 07.45 (CEST)

Jag tror mig ha noterat en ökning av "klotterkonton" den senaste tiden. Ett konto registreras, och börjar omedelbart används för att klottra. Jag brukar oändlighetsblockera dessa konton. (Det går ju att ångra.)

Vet någon varför denna ökning inträffat? Är det inte en massa arbete förknippat med kontoskapande? Hur orkar klottrare med detta, och vad ger det jämfört med att klottra oinloggad? Är oändlighetsblockering av kontona den lämpliga åtgärden? --Andreas Rejbrand (diskussion) 21 mars 2015 kl. 11.42 (CET)

En möjlig förklaring skulle kunna vara mobilredigeringar: i mobilen så kan man 1) gå in på en sida, 2) trycka på penna för att redigera, 3) få popup: logga in eller skapa konto, 4) skapa konto och 5) omdirigeras tillbaka till sidan där man kan redigera. Detta kanske kan leda till att man lätt skapar nya konton, antingen för test eller klotter.

Jag tror inte att de flesta av dessa användare är återkommande, varför oändlighetsblockering verkar onödig (jag skulle nöja mig med en dag). Men det spelar nog ingen roll. //Skal 30 mars 2015 kl. 22.38 (CEST)

En annan anledning kan vara att folk nog är mindre misstänksamma mot bidrag från registrerade användare och därför inte klickar in på sidor för att kontrollera bidrag på samma sätt.

Om en användare gjort flera klotterredigeringar och inga seriösa bidrag tycker jag att oändlighetsblockering är den bästa åtgärden. /Jiiimooh » DISKUSSION – BIDRAG 7 april 2015 kl. 07.55 (CEST)

Jag vill påminna om att det finns en avsomnad men icke avslutad diskussion på Diskussion:djur, som föranlett att uppslaget djur burit en förfrågan om kvalitetskontroll ända sedan i februari 2007. Är det inte dags att lösa upp den knuten? –Tommy Kronkvist (diskussion), 23 mars 2015 kl. 00.37 (CET).

En lösning är att ta bort kvalitetsmallen. En annan är att också ta bort den långa utläggningen under rubriken Användning. --Andreas Rejbrand (diskussion) 24 mars 2015 kl. 18.57 (CET)

Jag föredrar den sistnämnda lösningen; detta är en ordbok. –Tommy Kronkvist (diskussion), 28 mars 2015 kl. 15.18 (CET).

Gjort. --Andreas Rejbrand (diskussion) 28 mars 2015 kl. 17.35 (CET)

Mitt nya projekt är att lära mig ryska och förbättra ryska Wiktionary, främst genom att öka det svenskspråkiga inslaget där. Det finns idag ungefär 2100 svenska uppslagsord, vilket gör svenska till det 34:e största språket där. Än så länge skapar jag inga nya artiklar, utan förbättrar de som finns genom att lägga in rätt böjningsmönster, synonymer, sidobetydelser och referenser samt rätta förekommande felaktigheter. Jag lägger också till svenska (och ibland engelska och tyska) översättningar på de ryska uppslagsord som finns. Jag för dagbok på engelska på ru:User:LA2. Som svenskspråkig medarbetare i ryska Wiktionary har man det ganska ensamt. Det vore skoj om fler ville hjälpa till. --LA2 (diskussion) 1 april 2015 kl. 22.48 (CEST)

Tidigare har det bestämts att uppslag för böjningsformer inte ska ha någon grammatikmall direkt under h2-rubriken (t.ex. {{verb}}), eftersom den placerar uppslagen i kategorin <språknamn>/Alla uppslag, som är avsedd att endast innehålla huvuduppslag (grundformer). Jag upptäckte nu att många uppslag för tyska böjningsformer som har skapats nyligen innehåller en mall av ovan nämnda typ. Det totala antalet huvuduppslag och antalet tyska huvuduppslag som anges på statistiksidorna är därför mycket större än det verkliga antalen. Det skulle kräva väldigt mycket tid att som vanlig användare rätta till detta på alla uppslag som har skapats, så det bästa vore om en robot (Doddebot, Skalbot) kunde göra det. Jag hoppas att någon botägare har tid, men jag vill inte att ni ska känna er tvingade till något. "85" 4 april 2015 kl. 10.20 (CEST)

Tack, har åtgärdat de som kunde åtgärdas automatiskt (1465 sidor). Några sidor kvar som behöver kollas på manuellt: ehemaliger, einzige, jeden, macht, jünger, keine, Ahnen, keines. ~ Dodde (diskussion) 8 april 2015 kl. 12.48 (CEST)

Tack så mycket! "85" 14 april 2015 kl. 11.34 (CEST)

Hello, I made a proposal on Meta to change the rules for the steward confirmations. Currently consensus to remove is required for a steward to lose his status, however I think it's fairer to the community if every steward needed the consensus to keep. As this is an issue that affects all WMF wikis, I'm sending this notification to let people know & be able to participate. Best regards, --MF-W 10 april 2015 kl. 18.12 (CEST)

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Greetings,

I am pleased to announce that nominations are now being accepted for the 2015 Wikimedia Foundation Elections. This year the Board and the FDC Staff are looking for a diverse set of candidates from regions and projects that are traditionally under-represented on the board and in the movement as well as candidates with experience in technology, product or finance. To this end they have published letters describing what they think is needed and, recognizing that those who know the community the best are the community themselves, the election committee is accepting nominations for community members you think should run and will reach out to those nominated to provide them with information about the job and the election process.

This year, elections are being held for the following roles:

Board of Trustees
The Board of Trustees is the decision-making body that is ultimately responsible for the long term sustainability of the Foundation, so we value wide input into its selection. There are three positions being filled. More information about this role can be found at the board elections page.

Funds Dissemination Committee (FDC)
The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions being filled. More information about this role can be found at the FDC elections page.

Funds Dissemination Committee (FDC) Ombud
The FDC Ombud receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled. More information about this role can be found at the FDC Ombudsperson elections page.

The candidacy submission phase lasts from 00:00 UTC April 20 to 23:59 UTC May 5 for the Board and from 00:00 UTCApril 20 to 23:59 UTC April 30 for the FDC and FDC Ombudsperson. This year, we are accepting both self-nominations and nominations of others. More information on this election and the nomination process can be found on the 2015 Wikimedia elections page on Meta-Wiki.

Please feel free to post a note about the election on your project's village pump. Any questions related to the election can be posted on the talk page on Meta, or sent to the election committee's mailing list, board-elections -at- wikimedia.org

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery on behalf of the 2015 Wikimedia Foundation Elections Committee, 05:03, 21 April 2015 (UTC) • Translate • Get help

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Voting has begun for eligible voters in the 2015 elections for the Funds Dissemination Committee (FDC) and FDC Ombudsperson. Questions and discussion with the candidates for the Funds Dissemination Committee (FDC) and FDC Ombudsperson will continue during the voting. Nominations for the Board of Trustees will be accepted until 23:59 UTC May 5.

The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions on the committee being filled.

The FDC Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled.

The voting phase lasts from 00:00 UTC May 3 to 23:59 UTC May 10. Click here to vote. Questions and discussion with the candidates will continue during that time. Click here to ask the FDC candidates a question. Click here to ask the FDC Ombudsperson candidates a question. More information on the candidates and the elections can be found on the 2015 FDC election page, the 2015 FDC Ombudsperson election page, and the 2015 Board election page on Meta-Wiki.

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Volunteer Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery 03:45, 4 May 2015 (UTC) • Translate • Get help

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Voting has begun for eligible voters in the 2015 elections for the Wikimedia Foundation Board of Trustees. Questions and discussion with the candidates for the Board will continue during the voting.

The Wikimedia Foundation Board of Trustees is the ultimate governing authority of the Wikimedia Foundation, a 501(c)(3) non-profit organization registered in the United States. The Wikimedia Foundation manages many diverse projects such as Wikipedia and Commons.

The voting phase lasts from 00:00 UTC May 17 to 23:59 UTC May 31. Click here to vote. More information on the candidates and the elections can be found on the 2015 Board election page on Meta-Wiki.

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Volunteer Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery 17:20, 17 May 2015 (UTC) • Translate • Get help

Vi behöver ha mer nya kategorier och bli bättre på att föra in ord i olika typer av kategorier, som exempelvis Kategori:Svenska/Poesi, förslag till nya kategorier är bland annat Kategori:Svenska/Ontologi. Engelskspråkiga Wiktionary har exempelvis Category:English_suffixes. Vi på svenskspråkiga Wiktionary kan också börja kategorisera svenska ord efter ordled. Vi behöver förnyas oss. Tanken är "Ordböcker i en ordbok". Någon som instämmer i min syn? --Vannucci (diskussion) 22 maj 2015 kl. 18.28 (CEST)

Visst behöver hela kategoristrukturen ses över. Kanske skulle Wiktionary:Projekt/Kategorisering kunna utvidgas till att handla om allt som rör kategorierna, d.v.s. även kategoristrukturen och kategorisering av existerande uppslagsord. Det skulle även kunna vara en plats för diskussioner där man kan komma med förslag på nya kategorier m.m. Angående engelska suffix så skulle den kategorin nog kunna skapas som en underkategori till Kategori:Engelska/Affix. Problemet är då att grammatikmallen fortfarande placerar den i kategorin affix. En lösning på det skulle kunna vara en parameter i mallen {{affix}}, d.v.s. att man anger t.ex. typ=suffix. "85" 22 maj 2015 kl. 21.57 (CEST)

Kanske Kategori:Svenska/Suffix där man lägger in -logi, -nomi, -ism o.s.v.? Och inte de själva orden utan ordleden som slutar med -logi, -nomi, -ism o.s.v.? Samma sak för prefix och andra ordled. --Vannucci (diskussion) 22 maj 2015 kl. 22.10 (CEST)

Jag ser ingen anledning till att ändra någon rubrikstruktur, dvs. att byta ut H3-rubriken "Affix" mot "Prefix" respektive "Suffix". Det var väl inte något som någon föreslog heller. Det sätt som återstår i dagsläget är att placera ut en mall på sidan för tilläggandet av kategorin. Där har vi en mall redan. {{tagg}}. Som man i detta fall använder som {{tagg|kat=prefix}} e.d. Vanligtvis placeras denna på en definitionsrad, men är den inte knuten till en särskild definition kan den lika gärna placeras på fetstilsraden: '''pre-''' {{tagg|kat=prefix|språk=engelska}}. Då hamnar sidan både i Kategori:Engelska/Affix och i Kategori:Engelska/Prefix. Det kanske är lite olyckligt. Då låter 85:s förslag som ett bra förslag, att ändra i H3-mallen {{affix}} så att man kan skriva {{affix|underklass=prefix}} (och för andra språk än svenska - {{affix|<språkkod>|underklass=prefix}}) e.d. På motsvarande sätt skulle substantivmallen kunna användas som {{subst|underklass=egennamn}} om man vill. Kanske finns fler exempel då det kunde vara praktiskt och parametern kanske skulle byggas in i samtliga av våra h3-mallar (så att om en underklass används, så placeras den i denna kategori istället för i kategorin för huvudklassen). Som du säger, Vannucci, hamnar orden då i ex.vis Kategori:Svenska/Suffix som i sig länkas i kategoristrukturen som en "underkategori" till Kategori:Svenska/Affix (och i sedvanlig ordning även som underkategori till Kategori:Suffix). ~ Dodde (diskussion) 2 juni 2015 kl. 04.01 (CEST)

Hi. I stumbled upon an error on the page "smälta". Could anyone please adjust the text under the heading "Användning" to this change? I could change "andra" to "första" myself, but my Swedish is far from perfect and although I think that would do the trick, I'd still be afraid I overlooked a detail and made things worse. Thanks in advance! Caudex Rax (diskussion) 23 maj 2015 kl. 16.14 (CEST)

@Caudex Rax, thanks for the notice. I've changed the entry. //Skal 27 maj 2015 kl. 22.35 (CEST)

Tack ska du ha! --Caudex Rax (diskussion) 28 maj 2015 kl. 13.51 (CEST)