Wiktionary:Teknikvinden

Definition från Wiktionary, den fria ordlistan.
Hoppa till navigering Hoppa till sök
Välkommen till Teknikvinden!
Detta är samlingsplatsen för diskussioner som rör de mer tekniska aspekterna bakom Wiktionary-projektet, såsom mallar och moduler. 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 Bybrunnen om du har mer allmänna frågor om Wiktionary.

När teknikvinden börjar bli orimligt stor kan en äldre del diskussioner arkiveras. Men töm aldrig helt den här sidan.


Arkiverade diskussioner:

Filing cabinet icon.svg

Nyskapade grammatikmallar på turkiska[redigera]

Hej! Jag är inte så bra på att skriva/formatera mallar här på Wiktionary, men de nyligen skapade Mall:tr-subst-k, Mall:tr-subst-v och Mall:tr-pronomen behöver bearbetas för att följa svenska Wiktionarys formspråk och struktur. Jag kan peta lite, men för det här behöver jag hjälp från någon med mer avancerad kunskap om hur vår skript brukar se ut och fungera. Mvh, Svenji (diskussion) 2 januari 2021 kl. 18.02 (CET)[svara]

@Svenji Kika på Wiktionary:Stilguide/Grammatik/Skapa en mall. Där finns proceduren detaljerat beskrivet! ~ Dodde (diskussion) 7 januari 2021 kl. 02.30 (CET)[svara]
Och kika även på Wiktionary:Stilguide/Grammatik/Allmänna parametrar. Där förklaras vilka parametrar som bör användas och hur. ~ Dodde (diskussion) 7 januari 2021 kl. 02.33 (CET)[svara]
Proceduren finns kanske beskriven, men jag förstår den lika lite som om den var skriven på kinesiska. Jag har försökt modifiera andra malalr tidigare, men när man inte förstår så är det bara en gissningslek som aldrig tar slut. Svenji (diskussion) 20 januari 2021 kl. 19.31 (CET)[svara]

Avseende tr-subst-k, så skulle jag göra de första 12 rutorna synliga alltid och bara possessiv-delen ihopfällbar. Det skulle likna vanliga ryska substantiv som луна när man kommer till sidan. Sedan skulle jag inte blanda tabellkod (som bakgrundsfärg etc.) och grammatisk logik i samma mall. Gör en mall med tabellkod som enbart tar en lång lista med parametrar, och lägg logiken i en annan mall som anropar den första. Jämför {{uk-subst}} som är av första typen och alltid tar 14 argument och {{uk-subst-m}} som är av andra typen. --LA2 (diskussion) 7 november 2021 kl. 19.55 (CET)[svara]

@Svenji, @Dodde - Jag gjorde nu başlangıç enligt mitt förslag. Den använder {{tr-subst}} som tar 12 parametrar och struntar i possessiv-formerna, som är nog så många och ändå finns på en.wiktionary. Bra eller dåligt? Döm själv. Men detta liknar utseendet som finns för belarusiska, ryska och ukrainska grammatikmallar. --LA2 (diskussion) 11 november 2021 kl. 00.22 (CET)[svara]

Hjälpkaoset knappast rört sedan 2008, högsta kategorin, att-göra, mm[redigera]

Föreslår:

Verkställt. Taylor 49 (diskussion) 10 januari 2021 kl. 02.35 (CET)[svara]
Verkställt (nästan). Taylor 49 (diskussion) 10 januari 2021 kl. 02.35 (CET)[svara]
  • ny Kategori:Uppslag dit uppslag-relaterade kategorier (enligt språk, ordklass, ämne, ...) kan flyttas från Kategori:Index som då kan innehålla kategorier såsom "Uppslag", "Hjälp", "Projektsidor", ...
  • döpa om Wiktionary:Projekt/Wiktionary till Wiktionary:Att-göra ... ordet "wiktionary" överanvänds och "projekt" är faktiskt en perfekt synonym alltså 3 gånger samma ort, däremot inte det som egentligen avses: att-göra-listan

SV wiktionary är en av världens bästa i fråga om uppslag, men hjälpen är i nuläget så där ... dit en företrädesvis inte ska titta. Taylor 49 (diskussion) 6 januari 2021 kl. 05.02 (CET)[svara]

Dessutom skulle jag gärna ersätta det här tipset:
  • Hjälp-namnrymden ska innehålla sidor som inte har direkt med projektet Wiktionary att göra, men ändå kan vara till hjälp för bidragsgivare och besökare på ett eller annat sätt.
  • Wiktionary-namnrymden ska innehålla det som mer har med Wiktionary att göra. Viktiga huvudsidor som utgör bas för undersidor: Administration, Användare, Arkiv, Projekt, Riktlinjer, Stilguide
med
  • Wiktionary-namnrymden (projekt-namnrymden) ska innehålla sidor som har med administration, användare och behörigheter, regler och diskussioner (som inte avser en enskild sida) att göra.
  • Hjälp-namnrymden ska innehålla sidor som förklarar wikitekniken för bidragsskrivare och användare.
  • Appendix-namnrymden ska innehålla sidor som har med språk att göra men inte är enskilda uppslag (listor med ord, grammatik, ...)
Verkställt. Taylor 49 (diskussion) 10 januari 2021 kl. 02.35 (CET)[svara]
Taylor 49 (diskussion) 6 januari 2021 kl. 06.41 (CET)[svara]
@Taylor 49
1. Det låter rimligt att inte ha två olika "Hjälp"-namnrymder. Jag håller med om att det är förvirrande och att undernamnrymden Wiktionary:Hjälp kan samlas under namnrymden Hjälp (och Kategori:Hjälp).
2. I nuläget kan man nå alla kategorier via Kategori:Index. Jag tycker att Kategori:Index är överskådlig som den är. Jag tänker också att om man skapar "Kategori:Uppslag" så skapar det också förvirring med den befintliga kategorin Kategori:Alla uppslag.
3. Att städa i Wiktionary- och Hjälpnamnrymden är ju ett projekt och därför underordnat Wiktionary:Projekt. Sidnamnet Wiktionary:Projekt/Wiktionary tänker jag då är logiskt med nuvarande struktur av projekt. Man kanske skulle kunna tänka sig en egen namnrymd för "Projekt" precis som man har en egen namnrymd för "Hjälp". Jag vet dock inte riktigt hur man bör avgöra om något ska ha en egen namnrymd eller inte. Man skulle också kunna tänka sig att göra ett namnbyte från "Wiktionary:Projekt" till "Wiktionary:Att göra" (utan bindestreck) om man tycker att det är mer passande - exakt ord är inte viktigt för mig, men "Wiktionary" skulle fortfarande komma dubbelt till "Wiktionary:Att göra/Wiktionary". Ett alternativ är att döpa om projektet "Wiktionary" till "Wiktionary:Projekt/Metastruktur" eller "Wiktionary:Projekt/Namnrymdstruktur" eller nåt annat.
4. Beskrivningen av namnrymder ska naturligtvis spegla innehållet i namnrymderna. Ändra gärna om du kommer på bättre formuleringar och uppdatera gärna om strukturen ändras. ~ Dodde (diskussion) 7 januari 2021 kl. 03.21 (CET)[svara]
1. Verkställt.
2. Senarelagt.
3. Jag tror inte att det finns behov för ytterligare namnrymder. Jag drar tillbaka förslaget att döpa om en enda sida och vill slå ihop Wiktionary:Projekt/Wiktionary med Wiktionary:Projekt/Appendix istället till Wiktionary:Projekt/Namnrymdstruktur för närvarande. Senare skulle jag gärna ändra Special:PrefixIndex/Wiktionary:Projekt till Special:PrefixIndex/Wiktionary:Att göra men det blir väl många undersidor (190?).
4. Verkställt.
Taylor 49 (diskussion) 10 januari 2021 kl. 02.35 (CET)[svara]
@Taylor 49 3. Att slå ihop eller organisera om bland undersidor till namnrymder ryms inom ramen för sådant man kan "vara djärv" med, om man känner att man är varm i kläderna rörande Wiktionary-strukturen, så kör på! ~ Dodde (diskussion) 25 mars 2021 kl. 21.55 (CET)[svara]

Mall "är lika med" AKK "Mall:="[redigera]

{{=}} Mall:%3D&diff=prev&oldid=3469683. Vad ska vara fördelen med = över =? Nackdelen med DEC-encoding är att alla sidor som använder mallen fastnar i Kategori:Sidor som använder = som en mall (borde egentligen heta "Sidor som använder 'Mall:=' för något annat än just '='"). Ingen annan wiki gör på så sätt, den motsvarande katogorin brukar vara tom och ej skapad. Vågar någon att vidhålla =? Taylor 49 (diskussion) 11 januari 2021 kl. 21.53 (CET)[svara]

@Taylor 49, jag minns inte varför det var nödvändigt - troligen nåt med grammatikmallarna. Men grammatikmallarna har ändrats och nu används inte {{=}} särskilt mkt, så det är nog helt okej att den bara innehåller =. Skalman (diskussion) 14 januari 2021 kl. 22.52 (CET)[svara]
Då är det väl löst ... nu gäller det att vänta tills {{=}} blir en parserfunktion och vi kan radera mallen. Taylor 49 (diskussion) 27 januari 2021 kl. 12.11 (CET)[svara]

Inloggning[redigera]

Jag har nyligen haft problem med inloggningen ... någon loggar ut mig hela tiden, inte bara vid den här wikin, utan även annanstans. Någon har väl slarvat till det centrala inloggningssytemet. Taylor 49 (diskussion) 22 januari 2021 kl. 16.12 (CET)[svara]

Skript-hjälp[redigera]

Hej! Om jag vill lägga till en informationsruta till en mall, likt "not:", när mallen är i oexpanderat läge (och även kvar längst ner i expanderat), hur gör jag då? Jag vill få in texten "Verbstammen diftongeras i de fall stavelsen betonas. I övrigt gäller regelbunden konjugation.". Det gäller {{es-verb-er-dift}}. Svenji (diskussion) 4 februari 2021 kl. 17.28 (CET)[svara]

Åter till frågan: Jag vill kunna lägga till i flera mallar av oregelbundna verb (t.ex. med stamförändringar) att de redan i oexpanderat läge förklarar för den som redan har baskunskaper att verbet följer ett av dessa undantagsmönster. Till exempel för verbet volver: "Oregelbundet: verbstammen ändras i vissa fall med diftongering där o blir till ue. Verbet har oregelbunden participform." Svenji (diskussion) 16 mars 2021 kl. 12.20 (CET)[svara]
@Svenji, som i {{la-subst-1}} (!colspan="3" class="min"|Ordet tillhör den första deklinationen.)? ~ Dodde (diskussion) 21 mars 2021 kl. 21.06 (CET)[svara]
Tack @Dodde, ska pilla med detta när min tentavecka är över. Svenji (diskussion) 23 mars 2021 kl. 13.40 (CET)[svara]

Härledning - samlat: samiska eller norska[redigera]

Om jag vill ange en etymologi från norska, så använder jag språkkoden no, men jag tycker det är bättre om vi inte skiljer i härledningsmallen mellan bokmål och nynorska. Detsamma gäller lånord från samiska (i de fall det saknas vetskap om vilken samiska det först lånats från, kanske oberoende från flera). Jag vet inte hur jag ska ändra en sådan skrift i så fall (t.ex. som att grc blir grekiska). Svenji (diskussion) 16 mars 2021 kl. 12.13 (CET)[svara]

@Svenji Kan du precisera? Varje förståeligt och rimligt förslag kan implementeras. Taylor 49 (diskussion) 10 augusti 2021 kl. 00.09 (CEST)[svara]
@Svenji: "h-nor" och "h-smi" har lagts tillbaka. Taylor 49 (diskussion) 15 augusti 2021 kl. 18.42 (CEST)[svara]
Ur etymologisk synvinkel lånas ord inte in från "bokmål", utan från "norska", och dessa två är skrivna varieteter av ett och samma språk. För samiskans del gäller förhållandet att vissa ord har samiskt ursprung, men vilken standardiserad varietet i den samiska språkvärlden går inte längre att precisera. Att utelämna ett sådant lånord från dess härkomst vore mycket olyckligt. Liknande fall som samiskan kommer att behövas implementeras framöver, inte minst i mitt arbete med spanskan, och dess lånord från central- och sydamerikanska språk från ursprungsbefolkningen, där ibland inte ett tydligt enskilt språk kan bestämmas. Svenji (diskussion) 16 augusti 2021 kl. 11.27 (CEST)[svara]
@Svenji: Det finns väl massor med sidor som använder "non" men borde bättre använda "h-nor" liksom sådana som använder "smi-usm" men borde använda "h-smi". Taylor 49 (diskussion) 16 augusti 2021 kl. 12.16 (CEST)[svara]

Bugg i alla böjningsmallar[redigera]

Hej!

Titta på böjningsmallen i matvana. Titta i synnerhet på sista cellen (genitiv bestämd form plural).

Texten är förskjuten uppåt. I dokumentets DOM ser jag att detta beror på en överflödig P-nod.

--Andreas Rejbrand (diskussion) 21 mars 2021 kl. 19.14 (CET)[svara]

Jag kan reproducera den: stuga men ej hund. Hur länge har den här kritiska buggen funnits? Taylor 49 (diskussion) 21 mars 2021 kl. 19.28 (CET)[svara]
Jag tror att buggen förekommer när det finns en textruta under mallen. Jag såg den först för ett par månader sedan. --Andreas Rejbrand (diskussion) 21 mars 2021 kl. 19.45 (CET)[svara]
Slutrapporten från buggutredningen: Wiktionary:Sandlådan Taylor 49 (diskussion) 21 mars 2021 kl. 20.18 (CET)[svara]
Koden för förled= och not= finns i {{grammatik-slut}}, som mycket riktigt används i stort sett i alla grammatikmallar. Den mallen har inte ändrats sedan 2018. Kan det röra sig om en parsningsbugg i MediaWiki-programvaran som uppkommit nyligen, tro? @Skalman, vad säger du? ~ Dodde (diskussion) 21 mars 2021 kl. 20.57 (CET)[svara]
Kan det vara att buggen alltid har (mycket otydligt) synts? De överflödiga tecknen är ju uppenbara. Taylor 49 (diskussion) 21 mars 2021 kl. 22.10 (CET)[svara]
Nej, är säker på att det har sett korrekt ut tidigare. Men jag har inte granskat utseendet så exakt när det blev fel kan jag inte säga.
Några extra mellanslag, radbrytningar o.d. i den renderade html-koden är inget att bry sig om, det är ingenting som har nån betydelse.
Felet uppstår på grund av koden &#32‌; som skjuts in i en egen <p>-element precis efter "matvanornas" i bestämd form plural genitiv-rutan i böjningstabellen när den används på matvana. Att detta sker är ju egentligen inget konstigt - det är vad som står i mallen {{grammatik-slut}} att det ska ske på rad 1-3 (för 3= dvs. förled= i böjningsmallarna) respektive rad 5-7 (för 2= dvs. not= i böjningsmallarna).
1: <includeonly>{{ #if: {{{3|}}}
2: |&#32‌;
3: {{!}}-
Alltså: Om parametern "3" finns (eller om argumentet är en tom sträng), skjut in c följt av en radbrytning och sedan det som återfinns på rad 3 och 4.
5: -->{{ #switch:{{{2|}}}||-=|
6: #default=&#32‌;
7: {{!}}-
Samma kod med #if användes på rad 5-7 för parametern 2 (dvs. for not= i grammatikmallarna), men tomt argument "" betyder generellt "SANT" och argumentet "-" betyder generellt "FALSKT" i våra mallar, så koden ändrades till att använda "#switch" så att även not=-parametern i grammatikmallarna skulle följa det mönstret.
Alltså: Byt ut 2 (alltså not-argumentet) mot en tom sträng om 2 är "-", annars, använd defaultvärdet: &#32‌; följt av raderna 7 t.o.m. 13.
Så vad gör &#32‌; ens i mallkoden? &#32‌; är en HTML-kod för "space", alltså det vanligt mellanslag. Blanksteg trimmas dock bort i mallkod, så jag GISSAR att användning av &#32‌; var ett hack som var nödvändigt för att tabellavgränsaren i wikisyntaxen skulle börja på en ny rad och därför kunna tolkas om till rätt HTML-kod. Men det är @Skalman som skapat mallkoden så han kan nog svara på det definitivt.
Jag gjorde en snabbtest i sandlådan och det verkar som om det bara är att ta bort &#32‌; samt den efterföljande radbrytningen på två ställen, men det kanske är något jag har missat och eftersom mallen används på så många sidor tänker jag att det ändå är bäst om Skalman kikar på det först. ~ Dodde (diskussion) 22 mars 2021 kl. 17.44 (CET)[svara]
@Andreas Rejbrand, @Taylor 49, @Dodde: Jag har tagit bort &#32; nu.
Något i parsern måste ha ändrats, men jag hittar ingen dokumentation om vad det skulle kunna vara.
Förut var det nödvändigt att ha med, för extra mellanslag/radbrytningar runt | ignorerades, och då blev det som att {{!}} hamnade på föregående rad, och alltså förstörde tabellsyntaxen. Skalman (diskussion) 25 mars 2021 kl. 22.33 (CET)[svara]
@Skalman Jag har just revertertat din redigering eftersom den förvärrar buggen, se medium, Wiktionary:Sandlådan, dvs anrop då både förled= och not= används. Taylor 49 (diskussion) 4 juli 2021 kl. 09.11 (CEST)[svara]

Tagg-mallen, anrop kat=reflexivt[redigera]

Hej! Jag hittar inte var man redigerar i denna mallen (kanske av god anledning). Jag vill lägga till samma funktion för reflexiva verb på fornsvenska och för spanska, som vi nu har för svenska verb, d.v.s. att tagg|reflexivt visar reflexivt: raka sig. På fornsvenska grena vill jag alltså att kommandot skapar reflexivt: grena sik, och för spanska peinar reflexivt: peinarse. Svenji (diskussion) 23 mars 2021 kl. 13.48 (CET)[svara]

Det är förmodligen i modulkoden du kan lägga till stöd för flera språk. Men det är bra att du är försiktig. Ett fel i denna påverkar hela ordboken! --Andreas Rejbrand (diskussion) 23 mars 2021 kl. 13.52 (CET)[svara]

Nya absurda buggar[redigera]

  • Några av mina dagens redigeringar har bot-märket b fastän jag inte även har bot-flaggan på det här kontot (se Special:Senaste_ändringar)
  • fliken "Mer" -> "Flytta" försvann (hände igår på en annan wiki)
  • godtyckliga utloggningar (äldre, se #Inloggning)

Taylor 49 (diskussion) 20 april 2021 kl. 15.50 (CEST) Taylor 49 (diskussion) 22 april 2021 kl. 09.55 (CEST)[svara]

Hjälp med inställningar i redigeringsläge: färgad formatering, plus röd prick för annars "osynliga" mellanrum.[redigera]

Hej! Jag skulle testa lite olika utseenden, vilket resulterade i att jag fick nollställa alla inställningar. Nu märker jag till min förfäran att redigeringsläget är i svartvitt, men jag vill ha tillbaka mina gröna ref-länkar, lila och blåa webblänkar osv... Var ändrar man det? Och den lilla röda pricken som oftast döljer sig efter kopierade ord på t.ex. arabiska och hebreiska - hur får jag tillbaka den? Ingår den kanske också i samma funktion? Tacksam för hjälp!

Pennan till vänster om "Avancerad"? Taylor 49 (diskussion) 21 april 2021 kl. 01.28 (CEST)[svara]
Tack! Jag letade under inställningar, men det var alltså mycket lättare än så. Svenji (diskussion) 21 april 2021 kl. 01.50 (CEST)[svara]

Mall som hämtar från Wikidata[redigera]

Det finns nu många estniska ord med böjningsformer som lexem i Wikidata. Kan vi få en mall/modul här som visar dem? Se t.ex päev (som saknar böjningsformer) och d:Lexeme:L381851 (som har dem). --LA2 (diskussion) 23 april 2021 kl. 00.52 (CEST)[svara]

Frågan är nu även framlagd på en:Wiktionary:Grease pit/2021/April#Getting inflection tables from Wikidata. --LA2 (diskussion) 27 april 2021 kl. 19.41 (CEST)[svara]

Tyska mallar[redigera]

Skulle tyska {{de-verb}} kunna utrustas med gröna länkar? Så att man lätt kan skapa böjningsformer för verb som tagen#Tyska och toppen#Tyska. Det är en vanlig mall (inte modul) som använder {{länk}}. Borde den göras om till modulkod? --LA2 (diskussion) 21 maj 2021 kl. 16.49 (CEST)[svara]

Jag kan inte tyska, men det verkar som att artiklarna ställer till det för att det ska gå att använda den vanliga {{länka-b}} mallen. @Skalman, kan du utveckla? Kanske att skapa en modul är enda möjligheten att komma till rätta med detta. Om en modul ska skapas vore det bra om ett helhetsgrepp togs för alla tyska verbmallar. Hur heltäckande och hur stabila är de tre befintliga verb-mallarna? Dodde (diskussion) 21 maj 2021 kl. 18.07 (CEST)[svara]
Jag har uppdaterat {{de-verb}}, så att gröna länkar skapas. Det är inte alldeles optimalt, då mallen tydligen inte har faktagranskats och man riskerar att potentiellt skapa upp felaktiga böjningsformer. Om man ändå vet att den böjningsformen stämmer, så blir det ju hur som helst smidigt att använda. Skalman (diskussion) 22 maj 2021 kl. 00.01 (CEST)[svara]
Jag snöade visst in på en redigeringskommentar från 2017 om länka-b-mallen, men nu har vi ju istället den mer uppdaterade {{g-cell}}-mallen. Tack för att du fixade utbytet från {{länka}} till {{g-cell}}, Skalman. Jag började så smått med modultester för tyska verb (Modul:de-verb/test), men jag kom sedan på svårigheterna vi stötte på 2017 som framgår av Moduldiskussion:de-verb. Att för enkelhetens skull köra med {{g-cell}} tills vidare är nog ett bra val. ~ Dodde (diskussion) 22 maj 2021 kl. 00.34 (CEST)[svara]
Tack, detta var en stor förbättring! Jag vet inte alls om våra tyska mallar är heltäckande, men jag vet genom stickprov att bara ungefär hälften av våra tyska adjektiv och verb har en böjningsmall inlagd, så här finns mycket att göra. Nu har jag i alla fall skapat böjningsuppslag för tagen#Tyska. De gröna länkarna har blivit blå. --LA2 (diskussion) 22 maj 2021 kl. 00.45 (CEST)[svara]

Kort fråga[redigera]

Varför får inte uppslaget ^^ automatiskt en kategori? Svenji (diskussion) 25 maj 2021 kl. 11.09 (CEST)[svara]

@Svenji Det får den. Som framgår av Wiktionary:Mallar/ordklassmallar så hamnar sidor som använder mallen {{tecken}} i Kategori:Tecken om inte en mer specifik teckenkategori anges som första argument. På sidan ^^ har "--" angivits som första argument och sidan har därför hamnat i Kategori:--, vilket så klart inte var avsiktligt. I vanliga ordklassmallar används första argumentet för att ange språkkod, eller "--" när uppslaget är tvärspråkligt. Men tecken är redan tvärspråkliga, så därför saknas språkargument i tecken-mallen. ~ Dodde (diskussion) 25 maj 2021 kl. 13.52 (CEST)[svara]

Bugg i "MediaWiki:Common.css"[redigera]

Taylor 49 (diskussion) 21 juli 2021 kl. 21.58 (CEST)[svara]
@Taylor 49, jag fixade så att sidan inte fastnar i några kategorier. Däremot är det väl okej att inkludera mallar, så jag ändrar inte det. Ok? Skalman (diskussion) 11 augusti 2021 kl. 23.11 (CEST)[svara]
@Skalman: Hej
== {{saknad betydelse|ejkat=}} ==
Men varför inkluderas de överhuvudtaget? Är omnämningen i CSS-koden inte bara kommentar? Skulle sådant funka (och vara säkrare för alla mallar):
== { {saknad betydelse} } ==
eller
/* <!--
== {{saknad betydelse}} ==
--> */
eller (väl bäst, längst uppe och längst nere):
/* <nowiki> */
/* </nowiki> */
? Taylor 49 (diskussion) 11 augusti 2021 kl. 23.27 (CEST)[svara]
Jag gillar att man ser länken till den när man kollar på "Vad som länkar hit". Om någon av mallarna skulle raderas i framtiden, blir det på så vis också uppenbart att CSS:en bör ändras. Men jag kan ändra till [[Mall:saknad betydelse]] istället. Skalman (diskussion) 12 augusti 2021 kl. 11.10 (CEST)[svara]
@Taylor 49, en bättre lösning emm är om mallarna är så pass smarta att dom aldrig placerar sidan i en kategori om det inte är i huvudnamnrymden. Skalman (diskussion) 12 augusti 2021 kl. 11.19 (CEST)[svara]
@Skalman: Kategorisering enligt namnrymd är en möjlighet som är lätt att implementera, men har nackdelen att den underminerar nyttan av sandlådan och privata sandlådor på undersidor av ens användarsida. Ifall du vill ha länkar kvar (vilket låter rimligt), då är /* <nowiki> */ den näst bästa lösningen, och [[Mall:saknad betydelse]] den bästa, då föreslår jag att ändra {{...}} till [[Mall:...]]. Taylor 49 (diskussion) 13 augusti 2021 kl. 22.10 (CEST)[svara]

Bugg: ".WAV"-filer spelas inte utan laddas ner[redigera]

  • arbetslöshet "Sv-arbetslöshet.ogg" -> funkar
  • xenon "LL-Q9027 (swe)-Moonhouse-xenon.wav" -> laddas ner

Jag vet inte vad det beror på men det funkar vid -eo- wiktionary. Taylor 49 (diskussion) 3 augusti 2021 kl. 00.22 (CEST)[svara]

Skillnaden är väl att eo använder en speciell mall som ger en integrerad ljudspelare direkt på sidan, medan sv inte gör det, utan bara länkar till filen. Om du låter din webbläsare göra en HTTP GET-förfrågan på själva WAV-filen på eo ser du att den laddas ner även där. För att pröva det, klicka på länken på [1]. (Det har kanske med serverns MIME-typer att göra?) Men om du på sv klickar på högtalarikonen så kommer du till filsidan där du får en inbäddad spelare. --Andreas Rejbrand (diskussion) 3 augusti 2021 kl. 00.44 (CEST)[svara]

Bugg: "$wgExpensiveParserFunctionLimit" för lyxiga funktioner[redigera]

Det här är en förargelse och bråkmakare som ställer till det vid många wikier. Strängt taget är det inte en bugg utan en feature som lades till för länge sedan. Gränsen är för närvarande 500 anrop och gäller främst (summan av) ifexists and pagesincategory men ej transkluderingar vilket är märkligt (se nedan). Försök att få igenom en höjning för antingen en wiki eller alla WMF wikier är dömda att få T160685 avslag av "principiella skäl". Vi har ca 420 språkkoder varav ca 360 har uppslag. Vid 500 kategorier med uppslag kommer antalet huvuduppslag på titelsidan att sluta funka eftersom detta beräknas medelst pagesincategory. Vi har råd med ett anrop till en kostsam (lyxig, resurskrävande) funktion per språk, men inte mer. Detta begränsar möjligheter till listor över språk och statistik. Liknande problem finns vid andra wiktionaryer. Det finns ytterligare begränsningar såsom RAM-minne som -en- wiktionary ville ha en höjning på T165935 men fick avslag. Nu håller de på med desperata förändringar som försämrar kvaliteten men kanske reducerar minnesförbrukningen lite grann. Jag har tre ideer att få bukt med det här, som inte kan avslås av "principiella skäl" eftersom de alla är resursneutrala.

  • T278629 Omförhandla prislistan och gör transklusioner dyrare och ifexists and pagesincategory billigare. Det är orimigt att transklusioner som uppenbarligen är mycket mer resurskrävande är gratis medan ifexists kostar. Jag har även utvecklat ett knep som exploaterar den här absurditeten (Provujo länkat från "phabricator") och verkställer 676 ifexists-begäran med giltiga resultat och utan någon skampålekategori. Tyvärr funkar knepet inte för pagesincategory.
  • Batcha sådana begäran. Enligt svaret går det internt att batcha ifexists-begäran, och således bör detta göras tillgångligt även från LUA. Jag vet inte ifall detta gäller också för pagesincategory.
  • Höjning mot restriktioner. Ingen bugg-item vid "phabricator" ännu. Skapa en ny "content model" kallad för "privileged wikitext" som funkar på samma sätt som "wikitext" med följande 3 avvikelser:
    • Kraftigt höjda begränsningar, till exempel 500->10'000 lyxiga funktioner, 10s->40s LUA-tid, 50MiO->200MiO RAM, 2MiO->8MiO pre-expand&post-expand bloat.
      mot
    • Sidan kan redigeras enbart av administratörer.
    • Sidan kan uppdateras enbart sällan, till exempel 1 gång per timme och 3 gånger per dygn, plus mindre ofta eller inte alls automatiskt.

Finns det åsikter kring detta? Jag ber om stödjande röster på min bugg T278629 (batcha allt som går att batcha). Taylor 49 (diskussion) 3 augusti 2021 kl. 01.31 (CEST)[svara]

Jag har lagt till en notis till din appell på Phabricator om att jag stödjer ditt förslag. –Tommy Kronkvist (diskussion), 9 augusti 2021 kl. 15.38 (CEST).[svara]
Jag håller med om att dessa funktioner nog behöver ses över. Mest realistiskt skulle jag tro är Lua-funktioner som stödjer batchning av ifexists och pagesincategory.
En fullösning för huvudsidan skulle vara att helt sonika exkludera dom minsta språken (eller lägga till en hårdkodad schablonsumma för dom).
@Taylor 49, har du något exempel utöver huvudsidan som ger problem på sv-wikt? Skalman (diskussion) 11 augusti 2021 kl. 23.54 (CEST)[svara]
@Skalman: Jo, batchning av ifexists och pagesincategory vore bäst. Problemsidor: Wiktionary:Alla språk och koder med antal huvuduppslag -- för att evaluera hur många kategorier som saknas skulle det behövas min hack. Wiktionary:Balans efter språk och ordklass Och aldono. PS: {{antal uppslag}} har parametrar "list=" , "omit=" och "limit=" som kan användas i ett desperat läge. PPSS: finns det kanske en bättre lösning för MediaWiki:Common.css, se ovan? Taylor 49 (diskussion) 12 augusti 2021 kl. 00.07 (CEST)[svara]
Hur ser de andra språkversionerna av Wiktionary på det här? De torde ju vara uppbyggda på liknande sätt (?) och snart komma att uppleva samma problem som vi. –Tommy Kronkvist (diskussion) 12 augusti 2021 kl. 18.53 (CEST), 12 augusti 2021 kl. 18.53 (CEST).[svara]
Se ovan, de har redan problem. Det gäller bara att ta kontakt. Wiktionary:Bybrunnen/Arkiv26#Modul_önskas_för_beräkningsmall. 16 augusti 2021 kl. 15.49 (CEST)

Färger[redigera]

Är det bara jag som inbillar mig, eller har färgerna på hyperlänkar ändrats (om än ytterst subtilt)? --Andreas Rejbrand (diskussion) 13 augusti 2021 kl. 15.39 (CEST)[svara]

Du ser alltid saker som knappast syns (såsom buggen ovan med minimalt felplacerad text i tabellerna) och ingen annan skulle våga påtala. ;-) Taylor 49 (diskussion) 13 augusti 2021 kl. 22.14 (CEST)[svara]
Jo, visst har de väl blivit lite ljusare? Svenji (diskussion) 16 augusti 2021 kl. 11.29 (CEST)[svara]
Aningen ljusare, upplever jag det som. Synd att sidor som till exempel w:Wikipedia:Länkfärg (eller motsvarande på enWP, Meta-Wiki etc.) inte länkar direkt till någon "global" Wikimedia-CSS eller liknande, så att man enkelt skulle kunna titta efter i historiken. –Tommy Kronkvist (diskussion), 17 augusti 2021 kl. 00.24 (CEST).[svara]
Jag ser ingen skillnad, men jag har heller inte en skärm som återger färger jättebra. Men inte heller i koden ser jag några indikationer på att länkfärgen ska ha ändrats dom senaste 10 åren. Däremot kan det ju vara så att färgen har överridits, men inte längre gör det, så helt säker på vad som hänt i koden är jag inte.
Detta är den relevanta CSS-koden som körs på min dator: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/tags/1.36.1/resources/src/mediawiki.skinning/elements.less#14
Annat som potentiellt skulle kunna påverka, men som inte heller verkar så sannolikt: typsnittet har ändrats, webbläsarens tolkning av färg+typsnitt har förändrats, webbläsarens standardtypsnitt (vilket är det som Vector verkar använda som standard) har förändrats, operativsystemets tolkning av typsnitt har förändrats... Skalman (diskussion) 17 augusti 2021 kl. 10.58 (CEST)[svara]
Jo, det har blivit ljusare. Speciellt tydligt ser jag det på röda länkar, som här. Något har hänt, men i vilket fall som helst så har jag inga problem med ändringen. --Andreas Rejbrand (diskussion) 17 augusti 2021 kl. 13.48 (CEST)[svara]
Här syns skillnaden tydligt: https://privat.rejbrand.se/wtlinkcolour.png. Överst är en äldre skärmdump från januari 2017; underst är från i dag. --Andreas Rejbrand (diskussion) 17 augusti 2021 kl. 13.55 (CEST)[svara]
Jag trodde att det var något som hade hänt dom senaste dagarna, och jag trodde att det gällde andra länkar än rödlänkar. Om jag förstår rätt, så är den aktuella ändringen från mars 2021 och borde ha deployats ganska snart efter det (inom en månad, tror jag). Skalman (diskussion) 17 augusti 2021 kl. 16.22 (CEST)[svara]
Jag är helt säker på att färgerna på min dator ändrades samma dag som jag skrev inlägget ovan! --Andreas Rejbrand (diskussion) 17 augusti 2021 kl. 17.57 (CEST)[svara]
I så fall har jag kanske fel vad gäller inom en månad från mars 2021. Deploy av nya versioner kanske fungerar annorlunda än vad jag minns det som. Skalman (diskussion) 17 augusti 2021 kl. 19.20 (CEST)[svara]

"Mall:kategorinavigering-härledningar" - modularisering[redigera]

Jag har just modulariserat denna mall. Mall:kategorinavigering-härledningar Fördelar:

  • parametrar behövs ej längre: Det andra språket anges här med versalinitial (på Svenska/Härledningar från fornsvenska anges Fornsvenska)
  • språkkoder visas
  • alla tänkbara fel detekteras och bestraffas med felmeddelande liksom spårningskategori
  • etymologiska koder uppmärksammas (se Kategori:Svenska/Härledningar från samiska) och funkar enbart efter Härledningar från , motsatt "Kategori:Samiska/Härledningar från svenska" skulle ej funka

Jag föreslår att ta bort parametrarna medelst bot på alla sidor som använder mallen (kan det röra sig om enbart 487 ??). Taylor 49 (diskussion) 23 augusti 2021 kl. 00.44 (CEST)[svara]

@Taylor 49: Trevligt att bli av med parametrarna! Några kommentarer:
  • Varför behöver språkkoderna visas?
  • Nu genereras ett stycke <p> som innehåller två <br><br>. Skulle det gå att istället generera två <p>?
  • Jag skulle föredra aningen tydligare variabelnamn i modulen, och skulle kanske ha döpt modulen till samma sak som mallen (eftersom den bara används där), men det är småsaker som spelar mindre roll. :-)
Skalman (diskussion) 23 augusti 2021 kl. 09.50 (CEST)[svara]
> varför behöver språkkoderna visas
  • eftersom de behövs då en skapar nya uppslag (en kod) eller lägger till härledning (två koder)
  • vänta ... "fornindonesiska" ... vilken kod hade den igen ... var hade vi listan ... jag kan inte hitta den längre ... jävlar ...
  • jag har dåliga erfarenheter med vissa wikier som skryter med språknamn men vill ha koder som inmatning
  • och dessutom vill jag ha en nytta för funktion "getCode" ... ;-)
> det gå att istället generera två
Det går säkert ... hur menar du det exakt, och vad ska vara fördelen?
Taylor 49 (diskussion) 23 augusti 2021 kl. 14.20 (CEST)[svara]
@Taylor 49:
  • Språkkoder: Jo, du har rätt i att det finns en poäng i att visa språkkoden. Jag skulle föredra en lite annan formatering, men är inte alldeles säker på vad jag tycker skulle bli snyggast. Kanske (kod xx)? Jag har inte jättestarka preferenser här, men tycker att det ser konstigt ut med bindestrecken.
  • <p>: Huvudfördelen är att det ser bättre ut när det inte är så stort avstånd mellan raderna. Generellt bör du undvika <br> och istället använda antingen radbrytningar, <p>Textrad</p> eller <div>Textrad</div>.
Skalman (diskussion) 24 augusti 2021 kl. 20.35 (CEST)[svara]
Jag har tagit bort dessa <br> (British Rail) och ersatt dem med <div> (Divison). Avståndet har blivit lite mindre. Taylor 49 (diskussion) 2 september 2021 kl. 17.22 (CEST)[svara]
Boten ska avfiras nu. Taylor 49 (diskussion) 4 september 2021 kl. 21.18 (CEST)[svara]
Parametrarna har tagits bort från alla anrop, och omedelbart därefter förbjudits i modulkoden. Taylor 49 (diskussion) 4 september 2021 kl. 22.38 (CEST)[svara]
Applåd och lyft på hatt! Tommy Kronkvist (diskussion), 5 september 2021 kl. 03.35 (CEST).[svara]

Översättningar läggs in fel i listor som har en dubbel asterisk[redigera]

Varför läggs översättningar till i oordning? Jag trodde detta var en historisk bugg, men den är livs levande i dag. Här, till exempel, lades "albanska" inte först i listan (som förhandsvisningen angav), utan efter dubbelstjärnan för högsorbiska. --LA2 (diskussion) 8 oktober 2021 kl. 17.21 (CEST)[svara]

Pga en bugg här: MediaWiki:Gadget-translation editor.js. Kan reproducera problemet. Enbart @Skalman kan fixa den här buggen. Taylor 49 (diskussion) 10 oktober 2021 kl. 02.03 (CEST)[svara]
På rad 682 är en loop som stegar bakifrån igenom en lista. Det låter som felets orsak. Om man stegar bakifrån och hittar "**", så är ju det elementet mindre än aktuella språket och alltså stannar man och sätter in där. Koden borde stega uppifrån i listan tills den hittar ett större värde än det aktuella, för då kommer den aldrig att stanna vid "**". --LA2 (diskussion) 10 oktober 2021 kl. 03.31 (CEST)[svara]
Tack för tipset på en bättre algoritm. Det fanns troligen en anledning att göra som jag gjorde, men idag förstår jag inte vad det skulle kunna vara :-). Jag har också fixat en bugg med förhandsvisningen av tillagda översättningar. Det hela ska fungera nu. Skalman (diskussion) 12 oktober 2021 kl. 00.59 (CEST)[svara]
Tack, verkar fungera bra! --LA2 (diskussion) 12 oktober 2021 kl. 16.10 (CEST)[svara]

Turkiska Wiktionary har samma problem i kvadrat. Exempel: 1, 2, 3, 4. Vår MediaWiki:Gadget-translation editor.js motsvaras av deras tr:MediaWiki:Gadget-CeviriEkleyici.js (çeviri = översättning, ekle = lägg till) eller kanske tr:MediaWiki:Gadget-CeviriEkleyici-Veri.js. Men felet tycks bestå i att sorteringen sker i Unicode-ordning (Ç efter Z) i stället för enligt turkisk kollationsordning (Ç som C). Och var i programmet ligger det? Kanske handlar det om någon global parameter, snarare än den här koden? (@Skalman, @Taylor 49) --LA2 (diskussion) 29 oktober 2021 kl. 19.02 (CEST)[svara]

Är problemet nu fixat (hos oss) eller inte? Taylor 49 (diskussion) 29 oktober 2021 kl. 23.03 (CEST)[svara]
Jag tror det är löst hos oss. --LA2 (diskussion) 30 oktober 2021 kl. 18.18 (CEST)[svara]
Ganska komplicerat. Du har nog rätt i att den försöker sortera i Unicode-ordning. Jag tror att jämförelserna här inte sorterar korrekt:
// Rad 1095
} else if (ln && ln > lang && (!nextLanguage || ln < nextLanguage) && lis[j].parentNode.parentNode.nodeName != 'LI') {

// Rad 1224
} else if (ln && ln > nestedHeading && (!nextLanguage || ln < nextLanguage)) {
Men jag är inte alls säker på att detta är dom enda ställena.
Vi har faktiskt samma problem på svwikt, även om det uppträder mycket mer sällan: (italienska, iñupiaq) och (žemaitiska, zhuang) sorteras fel. Om "õ" ska sorteras som "o", så är också (võro, votiska) fel (men iaf sv-wp sorterar det som "ö", vilket i så fall betyder att det är rätt). Skalman (diskussion) 31 oktober 2021 kl. 14.56 (CET)[svara]
Så vitt jag ser, anger javascript-koden ingenstans vilken sorteringsordning som ska gälla. Alltså går den på någon sorts default, och sådant är ju alltid lite osäkert. Hur skulle man kunna implementera detta på ett stabilt sätt, utan att vara beroende av sorteringsordningen? Kunde man följa listan över godkända språkkoder i stället för att strängjämföra språknamnen? Jag är inte hemma i Javascript, men i Perl skulle man kunna lägga in alla översättningar i en hash-tabell och sedan skriva ut hela hash-tabellen i den ordning som anges av en array (no, bg, da) som gör att ordningen alltid blir Bokmål, Bulgariska, Danska. --LA2 (diskussion) 1 november 2021 kl. 19.00 (CET)[svara]
Enligt Stack Overflow finns en String.prototype.localeCompare som man bör använda. Och här är kod hos oss som använder localeCompare på strängar: MediaWiki:Gadget-unit tests/qunit.js. --LA2 (diskussion) 1 november 2021 kl. 20.02 (CET)[svara]
Default är unicode, så det är inte "osäkert" men nog inte det vi önskar.
Lättast är att använda localeCompare, som skulle sortera võro före votiska. Är detta acceptabelt?
Om man vill följa den ordning som finns på Modul:lang/data, måste man ladda in samtliga språk, vilket känns lite onödigt. Men det är också en möjlig lösning. Skalman (diskussion) 1 november 2021 kl. 23.36 (CET)[svara]
Säger svensk locale verkligen att õ ska sorteras som o? Tecknet används väl nästan bara som estniskt ö (som just i võru) och borde sorteras som ö och ø, tycker jag. --LA2 (diskussion) 2 november 2021 kl. 00.24 (CET)[svara]
Ja, tyvärr. Inte heller våra egna sort_rulesModul:lang/data eller infon på Appendix:Alfabet#Svenska tar hänsyn till õ, kanske eftersom det sorteras som (eller efter) o på vissa språk. Samma problem finns alltid när man måste känna till ursprungsspråket för att veta hur det ska sorteras.
Vilken väg tycker du att vi ska gå? Skalman (diskussion) 2 november 2021 kl. 00.49 (CET)[svara]
För mig är võru av så marginell betydelse, att jag inte bryr mig. Viktigare för mig är att få tr.wiktionary att fungera, och det hänger på att hitta en admin med rättigheter och vilja att debugga koden. Men rätt metod borde vara att överallt använda localeCompare, och sedan hoppas att svensk locale förbättras någon gång i framtiden. --LA2 (diskussion) 2 november 2021 kl. 01.36 (CET)[svara]
Jag har fixat sv-wikts sorteringsordning, så om någon wikt kopierar vår kod, bör sorteringen bli rätt.
Jag skulle kunna kika/experimentera med tr-wikts översättningsskript, men om jag inte lyckas lösa det på en timme, så kommer jag ge upp. Det skulle kräva att jag får gränssnittsadminbehörighet. Skalman (diskussion) 3 november 2021 kl. 23.38 (CET)[svara]
Användaren ‎HastaLaVi2, som talar turkiska och har rättigheter, men kanske inte är jättehaj på Javascript, har i dag försökt fixa buggen i tr:MediaWiki:Gadget-CeviriEkleyici.js, men rodde inte båten i land och återställde till gamla versionen. Kan du kolla ändringarna mellan de senaste versionerna och kanske komma med kommentarer och idéer? Användaren har också laborerat med en egen kopia, tr:User:HastaLaVi2/Gadget-CeviriEkleyici.js‎. --LA2 (diskussion) 4 november 2021 kl. 21.19 (CET)[svara]
Jag har fixat något som verkar funka skapligt: tr:User:Skalman/common.js som ersätter tr:MediaWiki:Gadget-CeviriEkleyici.js.
  • Funkar: sparar konsekvent saker i rätt ordning
  • Funkar inte (men likadant som idag): om man lägger till ett språk som ska hamna efter resterande, så visas detta som en del av en helt ny lista (istället för att bäddas in i den existerande)
  • Inte testat: underspråk (dubbla asterisker)
Jag tror alltså att det här här värt att lägga in, eftersom det viktiga väl är hur det sparas. Skalman (diskussion) 5 november 2021 kl. 19.18 (CET)[svara]
Så om varje lista redan hade ett element för Zulu (eller vilket språk som sorterar sist i alfabetet), så skulle det fungera bättre? Jag ser att du skickar med 'tr' som andra parameter till localeCompare(). Är det nödvändigt? Följer det inte med sajten som default? --LA2 (diskussion) 5 november 2021 kl. 19.51 (CET)[svara]
Ja, om listan hade Zulu skulle det alltid funka. Men det är inte förvirrande nu heller, bara konstigt.
'tr' är nödvändigt att skicka in. Annars får man en "internationell" sortering. Skalman (diskussion) 5 november 2021 kl. 21.53 (CET)[svara]
Jag ser att svenska koden skickar med 'sv'. Men är det inte lite konstigt att det ska behövas? Borde inte respektive sajt köra med egna språket som default? --LA2 (diskussion) 6 november 2021 kl. 00.00 (CET)[svara]
Nej, det är inte konstigt. I html är det specat att lang="sv", men detta slår inte över till Javascript. Man kan göra jämförelserna utan att upprepa språkkoden, men vi gör jämförelserna på så få ställen att det inte blir värt det. Historiskt har Javascript-api:erna bara använt webbläsarens språk, medan api:er från det här århundradet (tack och lov!) har varit "tvärspråkliga" (något som liknar det man skulle skriva i kod). Skalman (diskussion) 6 november 2021 kl. 21.26 (CET)[svara]

Ett stort framsteg har skett. Man kan nu lägga till cs (Çekçe) och det sorteras in korrekt före Danca (danska). Men zh (kinesiska, Çince) kommer fortfarande sist i listan. Se diskussionen här och exemplet tr:pazarlama (dess historik). --LA2 (diskussion) 6 november 2021 kl. 22.53 (CET)[svara]

Redskap[redigera]

Om nu översättningar har lagts in i fel ordning, och vi misstänker att det kan ha pågått länge, har vi då något verktyg (en bot) för att kontrollera att ordningen nu är den rätta, eller hitta de artiklar där ordningen är fel? --LA2 (diskussion) 10 november 2021 kl. 17.05 (CET)[svara]

Babel-mallen[redigera]

Hej! Vart går jag för att göra en liten ändring i babel-mallarna för jiddisch? För närvarande återger inte mallen på sv.wikt de diakritiska tecknena till alef, yud och fey, det vill säga nuvarande texten "דער באניצער האט א גרונטיקע ידיעה אין יידיש" skulle ändras till "דער באַניצער האָט אַ גרונדיקע ידיעה אין ייִדיש" (der banitser hot a grundike yedie in yidish). Engelska Wiktionary har f.ö. en helt annan text: ".דער באַניצער האָט תּוך־ידיעה פֿון ייִדיש." (der banitser hot tokh-yedie fun yidish." Svenji (diskussion) 10 oktober 2021 kl. 20.36 (CEST)[svara]

Jag vet inte, men gissar att https://sv.wiktionary.org/wiki/Special:Systemmeddelanden?prefix=babel&filter=all&lang=yi är ett ställe att börja leta på. Eftersom mallen babel anropar "parserfunktionen" (intern kod) #babel, så bör det vara ett systemmeddelande. Men de bör väl vara lika för alla wiki-sajter. Får du rätt accenter på engelska Wiktionary eller på svenska Wikipedia? --LA2 (diskussion) 11 oktober 2021 kl. 00.25 (CEST)[svara]
Svenska Wikipedia har en tredje variant (!): "דער באַניצער קען ביישטייערן מיט אַ גרונטלעכער דרגה פון ייִדיש.", .der banitser ken beyshteyern a gruntlekher dreyge (från hebreiska = "nivå, grad", translitteration?) fun yidish", där även punkten hamnar fel (ska stå till vänster). Svenji (diskussion) 17 januari 2022 kl. 16.20 (CET)[svara]

Rohingisk (rhg)[redigera]

(Can somebody translate this post, please?)

The translation-adding feature ({{ö-topp}} & {{ö-botten}}) doesn't have the language code "rhg" for the Rohingya language. --Apisite (diskussion) 14 november 2021 kl. 12.32 (CET)[svara]

(@LA2 What do you think?) --Apisite (diskussion) 14 november 2021 kl. 13.48 (CET)[svara]

Användare:Skalman typically handles these kinds of requests. I am sure Skalman or some other technician will handle your request later today or within a few days. --Andreas Rejbrand (diskussion) 14 november 2021 kl. 14.14 (CET)[svara]
A beginning might be to create an entry in Modul:lang/data. But what is the language called in Swedish? The Wikipedia article w:Rohingyer (about the people, Wiktionary: rohingyer) states that the language is called ruáingga (which doesn't have an article). --LA2 (diskussion) 14 november 2021 kl. 17.15 (CET)[svara]
@LA2, @Skalman - Maybe either Rohingisk or Rohingyask. --Apisite (diskussion) 14 november 2021 kl. 17.22 (CET)[svara]
I can't find any texts in Swedish that talk about the language. Apparently, it is not a topic of discussion. German Wikipedia has an article about the people, that also discusses "their language", but avoids to give the language any name. Perhaps "ruáingga" is correct in some sense, but since the topic is so remote to Swedish readers I think any term other than "rohingya" will have problems. I suggest we call the language "rohingya". (Languages are lowercase in Swedish.) --LA2 (diskussion) 14 november 2021 kl. 18.19 (CET)[svara]
@LA2, @Skalman - Added "rhg" to Modul:lang/data. --Apisite (diskussion) 14 november 2021 kl. 19.00 (CET)[svara]
@Apisite, it seems like you already added support at Modul:lang/data, which is all that's needed to make it work in translations. In addition, I've added the language to our documentation and to another script. Skalman (diskussion) 14 november 2021 kl. 21.18 (CET)[svara]
It seems like I was responding to a very old version of this discussion. :-) Skalman (diskussion) 14 november 2021 kl. 21.26 (CET)[svara]

Language code tsg[redigera]

@LA2, @Skalman What language name could be used for the language code tsg, "sulu", "suluk" or "tausug"? --Apisite (diskussion) 25 november 2021 kl. 06.45 (CET)[svara]

@Apisite, it seems like NE uses tausug, so that's what I'd go with. Skalman (diskussion) 25 november 2021 kl. 11.23 (CET)[svara]
@LA2, @Skalman - I have added not only Tausug (tsg), but also Magindanaw (mdh) and Maranao (mrw). --Apisite (diskussion) 25 november 2021 kl. 17.05 (CET)[svara]
@LA2, @Skalman I have added also Yakan (yka) to Modul:lang/data. --Apisite (diskussion) 25 november 2021 kl. 17.44 (CET)[svara]
@Svenji Svenji, I see that you've likely seen this thread. --Apisite (diskussion) 25 november 2021 kl. 17.49 (CET)[svara]
I guess this is good. I have no reason to believe otherwise. But it is frustrating to know that it might be years before anybody joins the Swedish Wiktionary user community with any insights that might correct any wrongs about these languages, which are so remote to the Swedish user base. It is also long before the same level of support will be added to smaller and less active Wiktionary sites, such as the Danish or Turkish Wiktionary. Much of this basic support should be made a global part of Wiktionary, and not added to each separate version. --LA2 (diskussion) 25 november 2021 kl. 21.27 (CET)[svara]
@Apisite - thank you, and yes. I see that the language called Magindanaw in English has an entry on NE as magindanao. That follows Swedish orthography better, so I would more recommend that to be the name we use here. About the Yakan language, my gut feeling would be that it's spelt jakan in Swedish, just like Yakut is jakutiska, Yiddish is jiddisch, and so forth. However, I could not find anything to support previous Swedish mention of the language. Svenji (diskussion) 25 november 2021 kl. 21.30 (CET)[svara]
I'm all for language plurality and inclusion, but perhaps with a limit. I encouraged the creation of at least 500 entries in each of the 24 official languages of the European Union, which is why we now have 500 entries in Maltese. But I'm less optimstic about Bavarian (Kategori:Bayerska), South Sami (Kategori:Sydsamiska), and other tiny languages (Bavaria is not small, but most people there only write in standard German, not in the Bavarian dialect). The same goes with languages that are large but very remote and have very little interchange with Swedish. Is it likely that any native speaker of Rohingya will become a contributor to Swedish Wiktionary? Sweden has many thousands of Arabic- and Somali-speaking immigrants, but none or very few come to Wiktionary. Most immigrants focus on learning Swedish, not to learn and teach Arabic (Kategori:Arabiska) or Somali (Kategori:Somaliska). We still only have 259 entries in Arabic. --LA2 (diskussion) 25 november 2021 kl. 23.52 (CET)[svara]
We have 1617 Indonesian lemmas :-). Taylor 49 (diskussion) 26 november 2021 kl. 00.01 (CET)[svara]
From a linguistic point of view, I find every language - however small - to join the project interesting. The issue is of course the problem of fact-checking these words, without knowledge or proper dictionaries at hand. I don't see why Southern Sami would be problematic, as being a vital language in Sweden and one variety of Sweden's official minority languages. More people speak Southern Sami in Sweden than Yiddish, but the latter being a language with big literal history and with speakers living in all corners of the world. When it comes to the Swedish project, I share the concern about major immigrant languages, such as Arabic, Somali, Persian and Thai are so small here still. My wish is that we get a bilingual editor of these languages to help out ASAP. I'm very happy for your recent contributions with Turkish, @LA2. With template structures available, it could easily spark more contributors interest in adding more data. Hopefully I will learn to read the abjad for Farsi next year or so, and then get my head around this meta-language so we get a bit better coverage. At the moment my focus has to stay with my studies in Spanish and Yiddish. And while I'm at it, I really appreciate the Indonesian contributions from you, @Taylor 49. I would love to see Malay grow on here too. Svenji (diskussion) 26 november 2021 kl. 01.00 (CET)[svara]

Two More Languages[redigera]

@LA2, @Skalman, @Svenji: I would like to have two (2) more languages, Ternate (tft) and Tidore (tvo), to Modul:lang/data added. --Apisite (diskussion) 27 november 2021 kl. 02.55 (CET)[svara]

wishlist -- önskelista Taylor 49 (diskussion) 27 november 2021 kl. 12.47 (CET)[svara]

CSS-bugg i böjningsmall för substantiv[redigera]

Titta på böjningstabellen i artikeln täckdag. I kolumnen för plural bestämd form genitiv är texten flera pixlar upphöjd. --Andreas Rejbrand (diskussion) 12 december 2021 kl. 17.10 (CET)[svara]

Vi har redan haft detta. Taylor 49 (diskussion) 12 december 2021 kl. 18.24 (CET)[svara]

Trasig latin-mall[redigera]

Mallen {{la-subst-3-n}} visar inte böjningar, utan bara tomma fält. Svenji (diskussion) 18 mars 2022 kl. 22.49 (CET)[svara]

Grönlänkar till sidor som finns[redigera]

Det är ytterst bekvämt att utifrån en lista med översättningar kunna klicka en grön länk och därmed skapa nya sidor och uppslag. Jag lade nyss till flera översättningar till ordet bar (utskänkningsställe) och klickade sedan på kyrilliska бар och skapade sidan med många uppslagsord på en gång. Men jag kan inte klicka på spanska översättningen "bar", för den sidan finns redan och länken är blå, inte grön. Skulle det vara möjligt att krångla till koden så att länken för spanska bar blir grön och nya uppslag skapas i den befintliga sidan? --LA2 (diskussion) 21 mars 2022 kl. 17.24 (CET)[svara]

@Användare:LA2: Jag tror inte. Detta skulle kräva att JawaScript läser hela denna sida ("bar" i det här fallet) och kollar ifall språket (spanska i det här fallet) redan finns. Visst skulle den kunna avbryta sökningen vid "Swahili" förutsatt att språken är sorterade. Detta skulle behöva göras för alla översättningar, dvs ifall det finns 100 språk med totalt 200 länkade ord, då skulle JawaScript behöva läsa och analysera upp till 200 sidor, bara för att avgöra "blått piller eller grönt piller". Alternativt skulle den kunna kolla ifall sidan i fråga är i kategorin (Kategori:Spanska/Alla uppslag i det här fallet) vilket väl är bättre, men ändå skulle behöva göras för alla länkade ord, i översättningar och böjningstabeller. Plus risken att sidan visserligen har språket men med fel ordklass. Men det är Användare:Skalman som är auktoriteten på JawaScript. Taylor 49 (diskussion) 24 mars 2022 kl. 09.45 (CET)[svara]
Att det går snabbt att kolla om sidan finns, beror ju på att det finns en databastabell över sidor som finns. Om det också funnes en databastabell över sektioner (h2-rubriker, ==) som finns i varje sida, så skulle den kollen också gå snabbt. När en ny version av en sida sparas (vilket inte är jätteofta) behöver den tabellen förstås uppdateras. --LA2 (diskussion) 24 mars 2022 kl. 14.20 (CET)[svara]
Flikar bara in att nu finns det ett spanskt uppslag för bar#Spanska, men när exemplet ovan framfördes så var detta ej fallet. Svenji (diskussion) 24 mars 2022 kl. 14.35 (CET)[svara]
Ur vårt (svwikts) perspektiv, är anledningen till att det går snabbt med grönlänkar, att länkarna på sidan redan är särskilt markerade: dom är röda. Så allt skriptet behöver göra är (i princip) att ändra röda länkar till gröna.
Det skulle gå att lösa tillräckligt effektivt via ett externt verktyg med full tillgång till innehållet på vår wiki (t.ex. på Toolforge), men det är inget som jag kommer göra. Skalman (diskussion) 26 mars 2022 kl. 22.36 (CET)[svara]

Partikelverb för verb som inte tillhör första eller andra konjugationen[redigera]

Jag skapade i går göra upp och i dag se över.

Notera de fina partikelverbsböjningsmallarna till höger.

Tyvärr gör dessa mallar så att artiklarna hamnar i kategorin Kategori:Svenska/Andra konjugationens verb, vilket är olyckligt.

Detta beror antagligen på att grammatikmallen i båda fallen är {{sv-verb-er}}.

Men jag tycks inte ges någon möjlighet att välja {{sv-verb}} (finns inte) och {{sv-verb-ar}} är förstås inte på något sätt bättre (första konjugationen).

Tittar man på respektive grundverbs artikel så ser man att göra också använder {{sv-verb-er}} och också hamnar i kategorin Kategori:Svenska/Andra konjugationens verb, vilket även det är olyckligt. Tittar jag på se så finns den artikeln inte i någon olämplig kategori, men den använder mallen {{sv-verb-r}} som inte tycks ha stöd för partiklar över huvud taget.

Så vad skall en stackars artikelförfattare som jag göra för att allt skall bli rätt?

Notera att mallarnas dokumentation säger "Om något ord inte passar in i någon av dessa beskrivningar kan valfri mall användas.", och visst kan jag få grammatikrutan att se bra ut visuellt även med en semantiskt olämplig mall, men kategorin blir ju fel.

--Andreas Rejbrand (diskussion) 27 mars 2022 kl. 20.08 (CEST)[svara]

Verbet "göra" hamnar också i Kategori:Svenska/Andra konjugationens verb. Jag har aldrig förstått hur detta med "starka" och "avljundsklassade" verb ska funka. Jag har ett eget system med 19 verbklasser. Jag ser ingen snabblösning utom att ta bort dessa kategorier. Taylor 49 (diskussion) 27 mars 2022 kl. 22.29 (CEST)[svara]
Nu skapade jag rå för som också hamnar i kategorin Kategori:Svenska/Första konjugationens verb trots att är av tredje konjugationen. --Andreas Rejbrand (diskussion) 2 april 2022 kl. 18.30 (CEST)[svara]
Den tidigare artikeln rå på hamnar i kategorin Kategori:Svenska/Andra konjugationens verb vilket är lika illa.
Missförstå mig inte: Våra grammatikmallar är superbra och den automatiska konjugationskategoriseringen fungerar bra i många fall (dock inte för ser det ut som). Men det verkar som om utvecklaren glömt bort partikelverben helt och hållet. --Andreas Rejbrand (diskussion) 2 april 2022 kl. 18.33 (CEST)[svara]
Många partikeluppslag som finns sedan tidigare är också felkategoriserade. T.ex. är komma ut kategoriserat som första konjugationen (*jag kommar, jag kommade, har jag kommat), vilket är uppenbart fel. --Andreas Rejbrand (diskussion) 2 april 2022 kl. 19.43 (CEST)[svara]
@Andreas Rejbrand något IP gjorde redigeringen att lägga till kategorierna utifrån vilken mall som används [2]. Om det inte ger ett korrekt och tillförlitligt resultat, tänker jag att kategoriseringen inte ska ske. Det verkar rimligt att helt enkelt avlägsna koden som placerar sidorna i dessa kategorier. ~ Dodde (diskussion) 6 april 2022 kl. 20.11 (CEST)[svara]
Ja, jag tycker också att vi tar bort dem tills vidare. --Andreas Rejbrand (diskussion) 12 april 2022 kl. 19.19 (CEST)[svara]
Verkställt. Taylor 49 (diskussion) 13 april 2022 kl. 08.27 (CEST)[svara]
Tack! --Andreas Rejbrand (diskussion) 13 april 2022 kl. 16.11 (CEST)[svara]

Chrome[redigera]

Hej! Jag vet inte om det är min gamla MacBook Air som håller på att ge upp, men sen igår kväll har jag problem med vissa funktioner på Wiktionary med Google Chrome. Bland annat går inte utfällbara grammatikmallar och översättningslistor att klicka på och därför heller inte att visas. Nu har jag gått över till Firefox. Svenji (diskussion) 5 maj 2022 kl. 13.26 (CEST)[svara]

Använda mallar från andra wiktionaries[redigera]

Vad är rätt sätt att använda mallar från ex. engelska wiktionary? Hade tänkt se över en del arabiska ord och mallar som denna https://en.wiktionary.org/wiki/Template:ar-IPA skulle vara väldigt trevliga att ha. Är rätt sätt att kopiera över den till svenska wiktionary eller finns det något bra sätt att använda den direkt som jag bara inte hittar? Dgse87 (diskussion) 7 maj 2022 kl. 13.03 (CEST)[svara]

+1, även för andra språk (persiska, hebreiska, tigrinya, hindi, m.fl. Svenji (diskussion) 19 maj 2022 kl. 15.40 (CEST)[svara]
Vi brukade inte göra så. Jag måste varna för omfattande beroendeväv som dessa mallar har. Du kan inte bara kopiera "ar-IPA" och då är det gjort. Den kommer att kräva andra mallar, som i sin tur kommer att bero av fler mallar och moduler. Det kommer att sluta med att 99% av mallar från en wiktionary finns här och duplicerar 99% av arbete av våra traditionella mallar, och ingen kan underhålla det hela. Många wiktionaryer har gjort så och slutat med en jättesvinstia. Taylor 49 (diskussion) 19 maj 2022 kl. 22.00 (CEST)[svara]
Så vad är alternativen? Att inte använda mallar då vi är en mindre wiki? Att bygga egna mallar som är enklare att underhålla men som inte är lika fullt utvecklade?
Att bara strunta i att använda mallar känns lite väl drastiskt?
Men oavsett vilket så tolkar jag ditt svar som att det inte finns något sätt att använda mallar som "bor" på engelska wiktionary direkt utan det enda alternativet som finns är att återskapa så mycket som vi kan/vill/orkar underhålla här på svenska Wiktionry? Dgse87 (diskussion) 19 maj 2022 kl. 23.19 (CEST)[svara]
> Så vad är alternativen?
  • kopiera mallar efter diskussion och konsensus, medvetna om svårigheter, och bestämda hur långt vi ska gå med detta (tydligare: Ska vi i slutändan slänga alla förhandenvarande mallar, och köra till 100% på ett system kopierat från en wiktionary?)
  • skapa egna (kanske enklare) mallar
  • köra utan mallar i vissa fall där sådant är rimligt (till exempel exempelmenigar)
> använda mallar som "bor" på engelska wiktionary direkt
Direkt går det verkligen inte. Vi har mallen i två versioner {{härledning}} {{härledning-}} -- lite olyckligt, ingen har hittills hunnit fixa den bättre. Taylor 49 (diskussion) 19 maj 2022 kl. 23.38 (CEST)[svara]
Ok! Låter rimligt även om det som "utomstående" känns lite olyckligt att inte alla mallar på alla wiktionaries ligger i samma "namespace". Såklart inget vi här kan göra nåt åt men ja...
Då blir nästa fråga (ni får säga till om vi ska bryta ut det till en ny "trådstart")
Hur/var skall diskussioner tas kring mallar. Antar att det är bra både att diskutera vilka vi behöver men också vilka som ska kopieras från andra wiktionaries.
Startar man en diskussion här på teknikvinden eller finns det något annat ställe där mallar redan diskuteras? Dgse87 (diskussion) 20 maj 2022 kl. 09.05 (CEST)[svara]

Här i teknikvinden är det bästa stället att diskutera mallal som ännu inte finns, eller spörsmål som rör flera mallar. Vi har redan haft det ett fåtal gånger, se Wiktionary:Teknikvinden/Arkiv02#En_stilla_undran och Wiktionary:Teknikvinden/Arkiv02#Mall_för_exempelmeningar. Du är ute efter bland annat automatisk transkription. Jag har faktiskt önskat detta länge till den här wikin och några andra wikier, men inte hunnit att göra något alls. Som sagt, kopiering från en wiktionary är vanlig, men medför allvarliga nackdelar. Så har en wiktionary flera gånger gjort om sitt system. Vid varje tillfälle gick en bot igenom alla sidor (flera 1'000'000) och anpassade alla mallanrop. Detta skedde så klart enbart inom en wiktionary, men INTE vid andra wiktionaryer dit delar av systemet hade kopierats. Resultatet vid dessa wikier är en blandning av flera generationer av systemet från en wiktionary bredvid varandra, en svinstia som funkar dåligt och ingen har koll på. Delvis tillkom det mallar från andra källor. Mallar, mallar, mallar, och moduler, moduler, moduler, massor med kod som mestadels saknar dokumentation, och duplicerar kod som redan finns mer än en gång annanstans.

"Template:ar-IPA" beror på en enda modul: "https://en.wiktionary.org/wiki/Module:ar-pronunciation", vilken i sin tur beror på 6 moduler "Module:links" "Module:languages" "Module:scripts" "Module:script utilities" "Module:parameters" "Module:IPA". Nästa nivå: "Module:languages" har 155 undersidor. Och slutet är ännu inte nått.

Det är inte så snabbt och smidigt att kopiera en mall från en wiktionary och ha den direkt.

Jag vill inte ha "Module:parameters" från en wiktionary, eftersom den är orimligt komplicerad och fungerar dåligt. Vi har {{#invoke:param}} som är enklare och sköter sig bättre.

Visst är en wiktionary störst och har saker som ingen annan har (automatisk transkription är en av dem), men den är inte alls perfekt eller bäst. Mycket görs där på ett onödigt komplicerat sätt ("Module:parameters" och översättningar är två exempel av många). Även syntaxen på uppslag är onödigt komplicerat.

Jag är i princip inte alls emot automatisk transkription baserad på kod från en wiktionary, men detta måste göras på ett vettigt, genomtänkt och efficient sätt, vilket inte är enkelt. Att snabbkopiera 2 eller 162 sidor är inte en bra början eller ett värdefullt bidrag till den här wikin, tyvärr. Taylor 49 (diskussion) 20 maj 2022 kl. 21.05 (CEST)[svara]

Jag hör vad du säger och håller med dig :) Jobbar till vardags med att skriva kod så och svenska wiktionaries aktiva medlemmar verkar gå att räkna på två händer så håller verkligen med om att vi inte vill kopiera hundratals odokumenterade script med ogenomtänkt syntax "bara för att". Men bra då låter det som om jag får läsa på om hur mallar och moduler funkar och sen se om jag kan producera någonting vi kan diskutera. Dgse87 (diskussion) 21 maj 2022 kl. 21.14 (CEST)[svara]

Ska Mall:subst lägga till kategorin "Kod/Alla uppslag"[redigera]

Enligt dokumentationen för https://sv.wiktionary.org/wiki/Mall:subst så ska mallen placera uppslaget i Kategori:Kod/Substantiv och Kategori:Kod/Alla uppslag. Men när jag använder

{{subst|ar}}

så verkar mallen bara lägga till Kategori:Arabiska/Substantiv men inte Kategori:Arabiska/Alla uppslag. Är dokumentationen fel eller är det en bug i mallen? föregående osignerade kommentar är från Dgse87 (diskussion • bidrag)

Den senare kategorin är en s.k. dold kategori. Du kan sätta på visningen av dolda kategorier under Inställningar > Utseende > Avancerade alternativ > Visa dolda kategorier. --Andreas Rejbrand (diskussion) 7 maj 2022 kl. 19.51 (CEST)[svara]
Fantastiskt :) Tack Dgse87 (diskussion) 7 maj 2022 kl. 23.54 (CEST)[svara]

Det går trögt att lägga till översättningar[redigera]

När jag lägger till översättningar och klickar "förhandsgranska" så tar det ibland 3 sekunder innan något händer. Denna tröghet har jag upplevt de senaste dagarna, men inte tidigare. Har något förändrats som ger anledning till detta? Ny sorteringsalgoritm? --LA2 (diskussion) 13 maj 2022 kl. 13.41 (CEST)[svara]

[CLOSED: FIXED] Betydelser[redigera]

Varför visas inte värdet av parametern betydelser= (siffran 1 resp. 2) i mallarna / böjningsrutorna på sidan характерний? LA2 (diskussion) 14 juni 2022 kl. 12.24 (CEST)[svara]

Löst: Mall:uk-adj&action=history Taylor 49 (diskussion) 16 juni 2022 kl. 19.10 (CEST)[svara]