Wiktionary:Bybrunnen

Välkommen till Bybrunnen! Detta är samlingsplatsen för diskussioner som rör Wiktionary-projektet. Känn dig välkommen att delta!

Skapa ett nytt stycke för ditt meddelande

• Gå till Fikarummet om du vill diskutera något som har med språk att göra, eller till Teknikvinden om det är strikt tekniskt (mallarnas eller webbsajtens själva funktion).

När bybrunnen börjar bli full av diskussioner kan man arkivera avslutade och inaktuella diskussioner i bybrunnens arkiv. Lägg gärna till en mening längst ner i diskussionen vad den resulterade i eller varför den är inaktuell (se arkivet för exempel). Lägg gärna diskussionerna i kronologisk följd med avseende på första inlägget.

Arkiverade diskussioner: /Arkiv1 /Arkiv2 /Arkiv3 /Arkiv4 /Arkiv5 /Arkiv6 /Arkiv7 /Arkiv8 /Arkiv9 /Arkiv10 /Arkiv11 /Arkiv12 /Arkiv13 /Arkiv14 /Arkiv15 /Arkiv16 /Arkiv17 /Arkiv18 /Arkiv19

Installera tillägget CategoryTests

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

angående kinesiska

Inget är simpelt med kinesiska, det finns många språk att ta hänsyn till, flera skriftvarianter och transkriberingar.

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 [1]. 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)

Tillägg på böjningsuppslag

I reaktion på [2] och [3] 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)

Omdirigeringar

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 [[länk]]. 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 [[länk]]:

• 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)

{{ref-neo}}

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)

Svenska affix

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- [4] 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 [5] 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 [6] 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)

När är ett adjektiv ett substantiv?

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)

Tech newsletter: Subscribe to receive the next editions

Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [7] [8]
• A software update will perhaps result in temporary issues with images. Please report any problems you notice. [9]
• MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [10]
• VisualEditor was added to all content namespaces on mediawiki.org on May 20. [11]
• A new extension ("TemplateData") was added to all Wikipedia sites on May 20. It will allow a future version of VisualEditor to edit templates. [12]
• New sites: Greek Wikivoyage and Venetian Wiktionary joined the Wikimedia family last week; the total number of project wikis is now 794. [13] [14]
• The logo of 18 Wikipedias was changed to version 2.0 in a third group of updates. [15]
• The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [16]

Future software changes

• The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [17]
• An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [18]
• The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [19]
• A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [20].
• The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [21]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe • 20 maj 2013 kl. 23.14 (CEST)

Important note: This is the first edition of the Tech News weekly summaries, which help you monitor recent software changes likely to impact you and your fellow Wikimedians.

If you want to continue to receive the next issues every week, please subscribe to the newsletter. You can subscribe your personal talk page and a community page like this one. The newsletter can be translated into your language.

You can also become a tech ambassador, help us write the next newsletter and tell us what to improve. Your feedback is greatly appreciated. guillom 20 maj 2013 kl. 23.14 (CEST)

Varianter av bokstäver

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.org/wiki/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)

{{se även}} och ====Se även====

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)

Ta bort röda interwikilänkar i {{ö}}

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)

Introducting Beta Features

(Apologies for writing in English. Please translate if necessary)

We would like to let you know about Beta Features, a new program from the Wikimedia Foundation that lets you try out new features before they are released for everyone.

Think of it as a digital laboratory where community members can preview upcoming software and give feedback to help improve them. This special preference page lets designers and engineers experiment with new features on a broad scale, but in a way that's not disruptive.

Beta Features is now ready for testing on MediaWiki.org. It will also be released on Wikimedia Commons and MetaWiki this Thursday, 7 November. Based on test results, the plan is to release it on all wikis worldwide on 21 November, 2013.

Here are the first features you can test this week:

• Media Viewer — view images in large size or full screen
• VisualEditor Formulæ (for wikis with VisualEditor) — edit algebra or equations on your pages
• Typography Refresh — make text more readable (coming Thursday)

Would you like to try out Beta Features now? After you log in on MediaWiki.org, a small 'Beta' link will appear next to your 'Preferences'. Click on it to see features you can test, check the ones you want, then click 'Save'. Learn more on the Beta Features page.

After you've tested Beta Features, please let the developers know what you think on this discussion page -- or report any bugs here on Bugzilla. You're also welcome to join this IRC office hours chat on Friday, 8 November at 18:30 UTC.

Beta Features was developed by the Wikimedia Foundation's Design, Multimedia and VisualEditor teams. Along with other developers, they will be adding new features to this experimental program every few weeks. They are very grateful to all the community members who helped create this project — and look forward to many more productive collaborations in the future.

Enjoy, and don't forget to let developers know what you think! Keegan (WMF) (talk) 5 november 2013 kl. 21.41 (CET)

Distributed via Global message delivery (wrong page? Correct it here), 5 november 2013 kl. 21.41 (CET)

I väntan på revolutionen

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)

Call for comments on draft trademark policy

Hi all,

The Wikimedia legal team invites you to participate in the development of the new Wikimedia trademark policy.

The current trademark policy was introduced in 2009 to protect the Wikimedia marks. We are now updating this policy to better balance permissive use of the marks with the legal requirements for preserving them for the community. The new draft trademark policy is ready for your review here, and we encourage you to discuss it here.

We would appreciate if someone would translate this message into your language so more members of your community can contribute to the conversation.

Thanks,
Yana & Geoff

Aktivera "assisterade översättningar" som standard

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)

Del 2: Lägg också till nytt översättningsavsnitt direkt

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)

chaparral

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

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

Special:Önskade sidor...

...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)

Översättningsrubriker kan inte ändras med skriptet i Internet Explorer 11

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)

Variantuppslag

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)

Mall:anv, 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)

Mall:anv, 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)

Unicode

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. [a, b] ≝ {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 [23] ä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: [24]. --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)

Grammatiska detaljer i kategorier

Mall:anv 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)

finna (med {tagg}) (transitivt) hitta Jag fann din plånbok! Vanliga konstruktioner: finna något Synonymer: hitta (transitivt) tycka om, ha viss åsikt angående Jag finner matematik vara ovanligt trist. Vanliga konstruktioner: finna något <adj>, finna något vara <adj> (reflexivt, intransitivt) acceptera och anpassa sig till något (oönskvärt) Vanliga konstruktioner: finna sig, finna sig i något, finna sig i att <inf> Besläktade ord: befinna, finnas, infinna

finna (med {grammatik}) hitta Jag fann din plånbok! Vanliga konstruktioner: finna något Synonymer: hitta Grammatik: Verbet är transitivt. tycka om, ha viss åsikt angående Jag finner matematik vara ovanligt trist. Vanliga konstruktioner: finna något <adj>, finna något vara <adj> Grammatik: Verbet är transitivt. acceptera och anpassa sig till något (oönskvärt) Vanliga konstruktioner: finna sig, finna sig i något, finna sig i att <inf> Grammatik: Verbet är reflexivt och intransitivt. Besläktade ord: befinna, finnas, infinna

	{{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)

Fler kategorier

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)

Dölja info invid definitioner som standard med JavaScript?

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 [quotations ▼]. 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)

Mall:anv, 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 [citat ↓]) (-döljs-citat-) (synonymer [sammansättningar, besläktade ord ↓]) (-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)

Uppsnyggning

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)

Ersätta "Motsvarande namn på andra språk" med "Översättningar"?

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

Request for comment on Commons: Should Wikimedia support MP4 video?

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)

Gömbara rutor: mer som en-wikt?

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)

Universal Language Selector will be enabled by default again on this wiki by 21 February 2014

On January 21 2014 the MediaWiki extension Universal Language Selector (ULS) was disabled on this wiki. A new preference was added for logged-in users to turn on ULS. This was done to prevent slow loading of pages due to ULS webfonts, a behaviour that had been observed by the Wikimedia Technical Operations team on some wikis.

We are now ready to enable ULS again. The temporary preference to enable ULS will be removed. A new checkbox has been added to the Language Panel to enable/disable font delivery. This will be unchecked by default for this wiki, but can be selected at any time by the users to enable webfonts. This is an interim solution while we improve the feature of webfonts delivery.

You can read the announcement and the development plan for more information. Apologies for writing this message only in English. Thank you. Runa

Amendment to the Terms of Use

Hello all,

Please join a discussion about a proposed amendment to the Wikimedia Terms of Use regarding undisclosed paid editing and we encourage you to voice your thoughts there. Please translate this statement if you can, and we welcome you to translate the proposed amendment and introduction. Please see the discussion on Meta Wiki for more information. Thank you! Slaporte (WMF) 21 februari 2014 kl. 23.00 (CET)

Call for project ideas: funding is available for community experiments

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)

Proposed optional changes to Terms of Use amendment

Hello all, in response to some community comments in the discussion on the amendment to the Terms of Use on undisclosed paid editing, we have prepared two optional changes. Please read about these optional changes on Meta wiki and share your comments. If you can (and this is a non english project), please translate this announcement. Thanks! Slaporte (WMF) 13 mars 2014 kl. 22.55 (CET)

Request for Comments: c: link prefix for Wikimedia Commons

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)

Lösning för massproduktion av ljudfiler med uttal

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)

Mall:anv, 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)

Changes to the default site typography coming soon

This week, the typography on Wikimedia sites will be updated for all readers and editors who use the default "Vector" skin. This change will involve new serif fonts for some headings, small tweaks to body content fonts, text size, text color, and spacing between elements. The schedule is:

• April 1st: non-Wikipedia projects will see this change live
• April 3rd: Wikipedias will see this change live

This change is very similar to the "Typography Update" Beta Feature that has been available on Wikimedia projects since November 2013. After several rounds of testing and with feedback from the community, this Beta Feature will be disabled and successful aspects enabled in the default site appearance. Users who are logged in may still choose to use another skin, or alter their personal CSS, if they prefer a different appearance. Local common CSS styles will also apply as normal, for issues with local styles and scripts that impact all users.

For more information:

• Summary of changes and FAQ
• Discussion page for feedback or questions
• Post on blog.wikimedia.org

-- Steven Walling (Product Manager) on behalf of the Wikimedia Foundation's User Experience Design team

Pronunciation Recording

Visual workflow draft for pronunciation recording gadget; If you have trouble watching this video here, watch it on vimeo. A more extensive/explanative version is available.

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)

VisualEditor global newsletter—May 2014

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)

Media Viewer

Greetings, my apologies for writing in English.

I wanted to let you know that Media Viewer will be released to this wiki in the coming weeks. Media Viewer allows readers of Wikimedia projects to have an enhanced view of files without having to visit the file page, but with more detail than a thumbnail. You can try Media Viewer out now by turning it on in your Beta Features. If you do not enjoy Media Viewer or if it interferes with your work after it is turned on you will be able to disable Media Viewer as well in your preferences. I invite you to share what you think about Media Viewer and how it can be made better in the future.

Thank you for your time. - Keegan (WMF) 23 maj 2014 kl. 23.29 (CEST)

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

Media Viewer is now live on this wiki

Media Viewer lets you see images in larger size

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!

Standard för att skilja på homonymer med olika betoning?

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)

VIKTIGT: Admin aktivitets undersökning

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)