Hej, du har kommit hit för att leta efter betydelsen av ordet Wiktionary:Teknikvinden. I DICTIOUS hittar du inte bara alla ordboksbetydelser av ordet Wiktionary:Teknikvinden, utan du får också veta mer om dess etymologi, dess egenskaper och hur man säger Wiktionary:Teknikvinden i singular och plural. Allt du behöver veta om ordet Wiktionary:Teknikvinden finns här. Definitionen av ordet Wiktionary:Teknikvinden hjälper dig att vara mer exakt och korrekt när du talar eller skriver dina texter. Genom att känna till definitionen avWiktionary:Teknikvinden och andra ord berikar du ditt ordförråd och får tillgång till fler och bättre språkliga resurser.
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!
Senaste kommentaren: för 6 månader sedan7 kommentarer4 personer i diskussionen
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
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
Nu har kag skapat tr-pron-pers baserat på en bearbetning av be-poron-pers. Vet inte om den behöver gömmas, tycker själv det är snyggare än den är öppen på pronomen-uppslag som oftast är rätt så kala på andra språk. 𐏐Frodlekis (✍) 12 april 2024 kl. 00.37 (CEST)Svara
Hjälpkaoset knappast rört sedan 2008, högsta kategorin, att-göra, mm
Senaste kommentaren: för 3 år sedan8 kommentarer2 personer i diskussionen
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
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, ...)
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
@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
Senaste kommentaren: för 3 år sedan1 kommentar1 person i diskussionen
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
Senaste kommentaren: för 3 år sedan4 kommentarer2 personer i diskussionen
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
Senaste kommentaren: för 3 år sedan5 kommentarer2 personer i diskussionen
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
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
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
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   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).
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:   följt av raderna 7 t.o.m. 13.
Så vad gör   ens i mallkoden?   är en HTML-kod för "space", alltså det vanligt mellanslag. Blanksteg trimmas dock bort i mallkod, så jag GISSAR att användning av   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   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
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
Senaste kommentaren: för 3 år sedan2 kommentarer2 personer i diskussionen
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 peinarreflexivt: peinarse. Svenji (diskussion) 23 mars 2021 kl. 13.48 (CET)Svara
Hjälp med inställningar i redigeringsläge: färgad formatering, plus röd prick för annars "osynliga" mellanrum.
Senaste kommentaren: för 3 år sedan2 kommentarer2 personer i diskussionen
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!
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
Senaste kommentaren: för 3 år sedan2 kommentarer2 personer i diskussionen
@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"
Senaste kommentaren: för 3 år sedan6 kommentarer2 personer i diskussionen
sv.wiktionary.org inkluderar massor av mallar och fastnar i 2 kategorier
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 ] istället. Skalman (diskussion) 12 augusti 2021 kl. 11.10 (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 ] den bästa, då föreslår jag att ändra {{...}} till ]. Taylor 49 (diskussion) 13 augusti 2021 kl. 22.10 (CEST)Svara
Bugg: ".WAV"-filer spelas inte utan laddas ner
Senaste kommentaren: för 3 år sedan2 kommentarer2 personer i diskussionen
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å . (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
Senaste kommentaren: för 3 år sedan5 kommentarer3 personer i diskussionen
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.
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).
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
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.
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
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
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
@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. :-)
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>.
Översättningar läggs in fel i listor som har en dubbel asterisk
Senaste kommentaren: för 2 år sedan24 kommentarer3 personer i diskussionen
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
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
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}elseif(ln&&ln>lang&&(!nextLanguage||ln<nextLanguage)&&lis.parentNode.parentNode.nodeName!='LI'){// Rad 1224}elseif(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
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_rules på Modul: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.
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
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)
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.
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
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
Senaste kommentaren: för 2 år sedan3 kommentarer2 personer i diskussionen
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
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)
Senaste kommentaren: för 2 år sedan9 kommentarer4 personer i diskussionen
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
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
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
Senaste kommentaren: för 2 år sedan2 kommentarer2 personer i diskussionen
Senaste kommentaren: för 2 år sedan5 kommentarer4 personer i diskussionen
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
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
Senaste kommentaren: för 2 år sedan9 kommentarer3 personer i diskussionen
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.
Missförstå mig inte: Våra grammatikmallar är superbra och den automatiska konjugationskategoriseringen fungerar bra i många fall (dock inte för 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
@Andreas Rejbrand något IP gjorde redigeringen att lägga till kategorierna utifrån vilken mall som används . 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
Senaste kommentaren: för 2 år sedan1 kommentar1 person i diskussionen
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
Senaste kommentaren: för 2 år sedan8 kommentarer3 personer i diskussionen
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
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.
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.orghttps://dictious.com/sv/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"
Senaste kommentaren: för 2 år sedan2 kommentarer2 personer i diskussionen
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ånDgse87 (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
Senaste kommentaren: för 2 år sedan1 kommentar1 person i diskussionen
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
Betydelser
Betydelser">redigera]
Senaste kommentaren: för 2 år sedan2 kommentarer2 personer i diskussionen
Här har vi den självklara regeln att proverb ska läggas in i befintligt skick. Vid en.wiktionary tar de bort interpunktionen vid slutet men (konsequent nog) INTE inre interpunktion, och de börjar inte en mening med versal, enligt en regel som skapades för ca 20 år sedan. Övriga viktionaryer tog över vanan från en.wiktionary utan att fundera vidare eller alls. Cognate kräver exakt överensstämmelse (med minimala eftergifter) för att bevilja länken. Det går att skapa omdirigeringar, men problemet är att de ofta blir raderare vid andra wikier (en.wiktionary bryr sig inte om andra, de är ju störst, och de har alltid rätt). Det går att använda explicita interwikilänkar, men detta leder till en ensidig fördelning av bördan (sv.wiktionary ska ha både omdirigeringar och interwikilänkar, en.wiktionary ingenting) och medför risken att dessa interwikilänkar tas bort av misstag.
skapa ett magiskt ord __FUZZY_INTERWIKI__ som skulle användas på alla wikier för alla uppslag med ordspråk
förbättra Cognate
ifall magiskt ord inte finns, gör som det har gjorts sedan år 2017
ifall magiskt ord finns:
försök hitta en överensstämmesle på traditionellt sätt, ifall ingen träff
försök igen men ta bort all interpunktion och gör bokstaven i början till en gemen på båda sidorna, till exempel "Rom byggdes inte på en dag." -> "rom byggdes inte på en dag", ifall flera träffar då prioriteras fullvärdiga sidor framför omdirigeringar och större sidor framför kortare
detta skulle väl kräva en fördubbling av hashtabellen som Cognate använder sig av
B (bättre?)
Ändra på WikiData:s regler och den tekniska restriktionen som beror på dem. Behåll grundprincipen "NS 0 i wiktionary är utesluten från WikiData", men inför ett undantag. Skapa en Q-item "wiktionary lemma needing manual interwiki coordination", och alla Q-item som är "instance of" den får länkas till NS 0 i wiktionary. Ifall en wiktionarysida är länkad till WikiData då gäller WikiData, annars Cognate. En bot går regelbundet igenom alla Q-item i fråga och lägger till sidor som har namn identiska med de som redan finns (enligt Cognate:s sätt), vid flera träffar prioriteras fullvärdiga sidor framför omdirigeringar och större sidor framför kortare. d:Q31897455d:Q1390514.
Vad är det för en mystisk "regel som skapades för ca 20 år sedan"? Och som bara sv.wiktionary känner till? Den enklaste lösningen är väl att vi rättar in oss i ledet och följer praxis på en.wiktionary. --LA2 (diskussion) 2 juli 2022 kl. 23.35 (CEST)Svara
@Taylor 49: Ledsen för sent svar, men jag skulle föreslå att de flyttas till formen utan punkt på slutet, samt att vi tog bort den stora bokstaven i början. Förutom på "Rom byggdes inte på en dag", som av förklarliga skäl även fortsättningsvis bör inledas med stor bokstav . Jämför meningar som
Gammal är äldst, sägs det.
Hon svarade att gammal är äldst.
Lägg märke till att ordföljden gammal är äldst kan inledas med stor bokstav och avslutas med punkt. Men den behöver inte göra det. Därför tycker jag det är fel att uppslagsordet ligger på Gammal är äldst. (med stor bokstav och punkt). Det vore bättre att ha dem på gammal är äldst (utan punkt). Inte för att andra gör så, utan för att det helt enkelt är mer korrekt. Du kan jämföra med imperativformen av verb. Följande är en korrekt mening:
Det är en mening, eftersom det används som en mening. Följande är också en mening (med sex ord):
Verbformen sjung stavas med fem bokstäver.
Samma sak menar jag gäller med
When in a hole stop digging.
Det är en mening, eftersom det används som om det vore en mening. Men ordföljden måste inte användas som om det vore en fullständig mening. Här är ett exempel från Google Books :
Indeed, adherence to the Law of Holes (when in a hole, stop digging) would be a welcome start.
Hur kommer det sig att det omsluts av parenteser ser ut så där? Borde inte det börja med stor bokstav efter vänsterparentesen och sluta med punkt före högerparentesen? Svaret på de frågorna har att göra med hur många meningar det finns i raden ovanför. Då måste man skilja på det som kallas en grafisk mening och en anförd mening. Se Svenska Akademiens Grammatik för definition av vad dessa två koncept innebär. "Grafisk mening" finns t.ex. definierat på sidan 177 i volym 1. Ovanför finns det en grafisk mening, som börjar med ordet "indeed" och slutar med ordet "start". Det som står innanför parentesen är inte en grafisk mening. När man citerar andra, antingen om det är ordagranna citat från en specifik person, eller mer generella hänvisningar till vad som "sägs" i form av talesätt, då behöver man inte alltid börja med stor bokstav och avsluta med punkt. Därför menar jag att talesätt av typen
when in a hole stop digging
inte bör inledas med stor bokstav och avslutas med punkt här på Wiktionary. Det går att använda dem som en (grafisk) mening, men man behöver inte göra det. Gabbe (diskussion) 20 augusti 2022 kl. 10.20 (CEST)Svara
Låt mig göra det ännu mer tydligt varför jag tänker som jag gör. När vi funderar på om ett visst uppslagsord ska börja med stor bokstav kan välja mellan ett par olika principer att följa:
Princip 1 Om ordet kan börja med stor bokstav ska artikeln också göra det.
Princip 2 Om ordet måste börja med stor bokstav ska artikeln också göra det.
Ta följande mening:
Det här är en mening.
Eftersom "Det" börjar med stor bokstav skulle det enligt princip 1 innebära att artikeln som nu finns på det ska flyttas till Det. Jag antar att alla håller med mig om att följderna skulle bli bisarra ifall vi tillämpade princip 1. Vi kan jämföra med följande mening:
Italiens huvudstad heter Rom.
Enligt princip 2 så skulle artikeln om staden vara på sidan Rom, inte rom. Låter högst förståndigt. Att det finns ett mellanrum i artikelns titel tycker jag inte förändrar saken. Alltså har vi liten bokstav i början av såväl köpa som köpa in och köpa grisen i säcken.
Så vad händer när vi börjar prata om ordspråk? Ta följande två exempelmeningar för att illustrera:
Osvuret är bäst.
Detta är en korrekt mening, men osvuret är bäst.
Enligt princip två så skulle alltså artikeln om ordspråket hamna på osvuret är bäst. Istället har vi tillämpat princip 1, fast bara för ordspråk. Det menar jag är inkonsekvent och fel. Bättre, i min mening, vore att tillämpa princip 2 även här. Ett motsvarande argument som gäller det för stor bokstav i början kan även appliceras på om vi ska avsluta med punkt. Ta följande mening:
Osvuret är bäst, sägs det.
Där blir det kommatecken, inte punkt, efter "bäst". Motsvarigheten till princip 1 skulle ha punkt i slutet. Motsvarigheten till princip 2 skulle skippa punkten. Gabbe (diskussion) 22 augusti 2022 kl. 08.19 (CEST)Svara
Mall för franskt uttal
Senaste kommentaren: för 2 år sedan12 kommentarer3 personer i diskussionen
På engelska Wiktionary finns en mall jag tycker är himla fiffig: {{fr-IPA}}. Den tar ett givet ord och genererar automatiskt dess korrekta uttal i IPA. Även om det finns specialfall som behöver hanteras manuellt så är den förvånansvärt fullständig. Den bygger på en Lua-modul som, vad jag förstår, borde vara ganska enkel att importera direkt till svenska Wiktionary. Om någon känner sig manad att göra det vore jag mycket tacksam! Gabbe (diskussion) 16 juli 2022 kl. 19.44 (CEST)Svara
Såg först nu att det fanns en liknande diskussion ovanför om den arabiska mallen av det slaget. Jag antar att motsvarande invändningar (tyvärr) är applicerbara även i det här fallet? Gabbe (diskussion) 16 juli 2022 kl. 19.48 (CEST)Svara
Sådana mallar finns oxxå för esperanto, finska och ytterliagre språk. Det finns dessutom fiffiga mallar för transkription av diverse icke-latinska alfabet. Detta är visst på min att-göra listan, men väl inte enkelt. Taylor 49 (diskussion) 17 juli 2022 kl. 17.18 (CEST)Svara
Dock är väl kanske nyttan allra störst hos språk med icke-latinska skrifter, kanske persiska, arabiska och hebreiska? Jiddisch är jag osäker på om det funkar för, då de har ett fonetiskt skrivsätt, med undantag från orden med semitisk rot - som följer hebreiskan. Det är alltså inte meningen att lägga allt detta jobb på ditt bord, Taylor. Jag tänker bara öppet. Ska kolla in modulerna ikväll om jag får tid. Svenji (diskussion) 20 juli 2022 kl. 08.26 (CEST)Svara
Går det att lägga till så att mallen även skriver ut "uttal:"? Nu ser det lite otydligt ut, om vi inte planerar att ändra om uttal till en #:{{uttal|}} Svenji (diskussion) 20 juli 2022 kl. 22.48 (CEST)Svara
Det går säkert ... men sättet hur jag nyligen utökade den urgamla mallen {{ipa}} kan upfattas som lite provisorisk. Jag skulle helst ha en helt ny mall+modul som tar över från den oturliga mallen {{uttal}} som inte tillåter att lägga till flera uttal, inte stöttar anmärkningar, och ibland (ca 230 sidor) kombineras med "ipa". Taylor 49 (diskussion) 20 juli 2022 kl. 23.11 (CEST)Svara
Vad ska jag fokussera på nu? fr, es, eller en helhetslösning för svwikt, dvs en ersättning för {{ipa}} och {{uttal}} som moduler för enskilda språk skulle kunna kopplas till? Det optimala vore en crosswiki-helhetslösning, men enwikt har haft sin lilla stora privata svinstia under 20 år, och det kommer väl att vara svårt dvs omöjligt att få fram en konsensus att göra om detta. Taylor 49 (diskussion) 23 juli 2022 kl. 15.03 (CEST)Svara
@User:Taylor 49: När jag ställde min fråga längst upp så hade jag ögnat igenom modulen på enwikt lite som hastigast. Jag trodde att det handlade om att skarva den en smula för att få den att funka på svenska wiktionary. Fila lite på hörnen, liksom. Om det är så att det skulle krävas nån slags "Extreme Home Makeover", så känn inte att du behöver göra det för min skull. Så svårt är det inte att klipp-och-klistra IPA:n från enwikt. Oavsett så dubbelkollar jag alltid uttalet i en icke-Wiktionary-källa som jag litar på innan jag inför det här. Av de alternativ du räknade upp är det helhetslösningen för svwikt jag skulle rösta för. Gabbe (diskussion) 23 juli 2022 kl. 15.50 (CEST)Svara
Fel med böjningsmallen för det franska verbet "dire"
Senaste kommentaren: för 2 år sedan2 kommentarer1 person i diskussionen
Jag har hittat ett fel i mallen {{fr-verb-dire}} som jag är lite osäker på hur jag ska rätta till. Det gäller andra person plural (vous). För indikativ presens ska det bli dites, precis som det ser ut just nu. Men detta gäller bara för dire. För alla andra verb med "samma" böjningsmall (som contredire, interdire, prédire) ska den formen istället sluta på "disez". Ta till exempel interdire. Just nu blir det "interdites" där, vilket är fel. Det ska bli "interdisez".
Senaste kommentaren: för 2 år sedan3 kommentarer2 personer i diskussionen
En annan tanke, när jag har dig på tråden, är något slags script som korrekt omvandlar uttalet på SAOB till IPA. SAOB använder ett helt eget system. Ta till exempel skjorta. De säger att det uttalas ʃω3rta2 och ʃωr3ta2. Om jag fattat det rätt motsvarar det /ˈɧu:rta/ respektive /ˈɧʊrta/. Särskilt förvirrande är det bland annat att ifall bokstaven "a" har en eller två "våningar" innebär på SAOB precis motsatsen mot vad det betyder i IPA (eller?). Detta anger de dessutom via om bokstaven står innanför <span class="StorKursiv"> eller inte. En korrekt IPA-ifiering av uttalet för svenska ord känner jag inte till någon ordbok som har, varken online eller offline. Det skulle kunna vara något som sätter svenska Wiktionary på kartan, så att säga.
@User:Gabbe: Det går säkert, och betyder jobb, och kanske mer. Men ska det vara en modul, en javascript eller en bot? Det skulle gå att göra en bot som går igenom hela SAOB, läser ut uttalet, konverterar, och lägger till i vår wiktionary. Men är det lagligt att göra så? Känner sig någon manad att skriva till Svenska Akademien och begära tillstånd för sådant tillslag? Min bot är ingen pirat. ;-) Jag håller med att uttal för alla svenska ord medelst IPA är mycket önskvärt. Jag har flyttat Gabbes text till ett nytt avsnitt. Taylor 49 (diskussion) 23 juli 2022 kl. 16.11 (CEST)Svara
Senaste kommentaren: för 2 år sedan6 kommentarer2 personer i diskussionen
Jag har gjort en ny mall som så småningom är tänkt att hantera konjugeringen av franska verb, såväl regelbundna som oregelbundna. Efter att ha fått det och funka dugligt på min Lua IDE tänkte jag att det var dags för nästa steg, att testa på Wiktionary. Därför har jag skapat {{fr-verb-test}}, som anropar Modul:fr-verb-artikel, som i sin tur anropar Modul:fr-verb-konj. Den första av modulerna är en slags "kaross", enbart menad att presentera värdena i det tabellformat som vi vill ha. Den andra av de två modulerna är en slags "motor", där själva konjugeringen sker. Tanken är att det ska gå att anropa den med {{fr-verb-test|artikelnamn=donner}}, {{fr-verb-test|artikelnamn=aller}}, {{fr-verb-test|artikelnamn=être}}, osv. för att testa.
Just nu stöter jag på två problem som inte dyker upp i min Lua IDE. Det första är att den första modulen inte verkar vilja hantera nya rader ("\n") som jag hade hoppats. Se rad 220 och 221 av Modul:fr-verb-artikel. Hur fixar jag det? Gabbe (diskussion) 27 juli 2022 kl. 08.05 (CEST)Svara
Jag har kollat lite grann. Har du skapat modulen "fr-verb-konj" själv? Jag vet inte vad du gjorde i din Lua IDE, men jag misstänker att att du testade enbart "fr-verb-konj" utan "fr-verb-artikel". Det stora problemet med "fr-verb-artikel" är inte nya rader, utan iden att denna genererar mallkod ie #switch #invoke mm. Du kan inte göra så pga parsningsprioriteterna. En modul kan generera HTML + wikilänkar + kategoriinläggningar (bäst), wikimarkup, eller innehållet för enskilda parametrar som matas in i andra moduler eller mallar. En modul får inte generera bland annat "nowiki", "noinclude", hela parametrar såsom "|permanentlybanned=true", eller anrop av andra moduler eller mallar. Slutsats: "fr-verb-artikel" enligt nuvarande design kommer aldrig att funka, och måste därför göras om från grunden. Taylor 49 (diskussion) 27 juli 2022 kl. 11.50 (CEST)Svara
@Taylor 49: Ja, jag har skrivit modulen "fr-verb-konj" helt själv. Jag har visserligen utgått från boken jag nämnde i de inledande kommentarerna. Siffrorna inom hakparentes på några av funktionerna fungerar som en slags källhänvisning. Det kan vara bra ifall man skulle vilja utöka modulen med mer "exotiska" oregelbundenheter. Då kan man fråga sig "är det verkligen så att verb av den här typen böjs på det sättet? vad baserar du det på?". Då finns källhänvisningen där i modulen. Boken innehåller dock bara en beskrivning av hur verben böjs och vilka som böjs på det sättet. Själva koden till "fr-verb-konj" har jag skrivit helt själv.
Angående "fr-verb-artikel" så är det vad jag befarade. Jag går tillbaka till ritbordet med den. Det jag testade i min Lua IDE var att köra både "fr-verb-konj" och "fr-verb-artikel". Den senare gav textkod som output via "print()". Jag vet att vi inte får åberopa "print()" här på Wiktionary. Det som printats ut från "fr-verb-artikel" i min Lua IDE tog jag sen och klipp-och-klistrade in i WT:Sandlådan och tryckte på "visa förhandsgranskning". Jag jämförde sen med de mallar som redan fanns på sidor som aller, donner, osv. Allt såg bra ut. Här är ett exempel.
Om jag vill att "fr-verb-artikel" ska mynna ut i något som är så likt output från {{fr-verb-er}} som möjligt, ska jag alltså återskapa HTML + wikilänkar osv som den mallen mynnar ut i? Det verkar rätt bökigt. Hur hanteras då {{g-cell}} och liknande? Hur brukar andra göra för att konstruera mallar med tabeller utifrån modul-output? Gabbe (diskussion) 27 juli 2022 kl. 12.22 (CEST)Svara
Vilka Unicode-tecken substitueras av Wiki-programvaran
Senaste kommentaren: för 2 år sedan4 kommentarer3 personer i diskussionen
Jag hade en diskussion med @Dodde om testcases för moduler, och kom på följande fråga som är av mer allmänt slag. Så jag pingar in @Taylor 49 också och ställer den här istället.
När jag håller på med forngrekiska tecken vill jag bland ha att göra med
ΰ (U+03B0 "Greek Small Letter Upsilon with Dialytika and Tonos")
ΰ (U+1FE3 "Greek Small Letter Upsilon with Dialytika and Oxia")
Då kommer vän av ordning och säger till mig att det där är inte två olika tecken, utan samma tecken. Vanligen så ser tecknen identiska ut, oavsett om de lagras som U+03B0 eller U+1FE3. Här på Wiktionary verkar det som om mjukvaran automatiskt förvandlar dem bägge till U+03B0 utan att jag bett om det. Om det stämmer, finns det i så fall beskrivet någonstans i detalj vilka sådana slags Unicode-substitutioner som jag kan räkna med att programvaran gör? Gabbe (diskussion) 19 augusti 2022 kl. 14.17 (CEST)Svara
Här finns mer , , , , . Tydligen använder MediaWiki ett paket som heter utfnormal, som finns att granska på Github och kanske informationen du söker finns gömd i "UtfNormalData.inc" i den sista länken. ~ Dodde (diskussion) 19 augusti 2022 kl. 16.03 (CEST)Svara
Avledning med accenter
Senaste kommentaren: för 2 år sedan12 kommentarer3 personer i diskussionen
Känns inte som att syntaxen fungerar som önskvärt. LA2:s exempel borde ju fungera. Visst borde väl 3= sköta detta automatiskt och text= bara användas om en "override" av 3= är nödvändig? ~ Dodde (diskussion) 6 september 2022 kl. 21.02 (CEST)Svara
Om vi får 3= att fungera med accenter, så är detta också vad gröna länken borde lägga till. Notera att избрал är skapad genom grön länk (från избрать) och sedan har jag redingerat in accenten i efterhand. --LA2 (diskussion) 6 september 2022 kl. 21.25 (CEST)Svara
Vad gröna länkar gör ansvarar enbart Skalman för. Det är enkelt att få 3= att fungera med accenter. Ska "text=" då avvecklas helt? Jag vill inte ha någon parameter utan ett vettigt användningsexempel. Taylor 49 (diskussion) 6 september 2022 kl. 21.35 (CEST)Svara
Vi kan sikta på att avveckla text=. Om hinder dyker upp på vägen får vi kolla på det då. Enda användningsområdet för text= som jag kan tänka mig jut nu är om Modul:lang/data saknar lämplig entryname-data för det specifika språket. I så fall kanske det är mer lämpligt att ändra i Modul:lang/data än att använda text=-parametern i böjningsmallen. ~ Dodde (diskussion) 7 september 2022 kl. 01.46 (CEST)Svara
Senaste kommentaren: för 2 år sedan2 kommentarer1 person i diskussionen
Ändring genomförd: Motsvarande {{nollpos}} (CSS-kod: clear:both) sker automatiskt för alla ordklassrubriker och alla översättningsrubriker.
{{nollpos}} blir onödig och kommer tas bort
Parametern halv= till {{ö-topp}} blir onödig och kommer tas bort
Bakgrund. Vi har använt {{nollpos}} ovanför översättningsrubriker, för att rubriken och översättningarna ska hamna nära varandra - det är snyggare. När detta infördes 2007, var det inte ett alternativ att lägga till automatisk nollpositionering på alla rubriker, eftersom vi använde många fler rubriker då, exempelvis ====Synonymer====. Under ett antal år fanns också en Javascriptlösning, men den var aningen buggig och gjorde att rubriker hoppade till rätt position, vilket är ganska fult.
{{nollpos}} har döpts om till {{clear}} och kan inte längre användas på uppslag. Namnbytet syftar till att använda samma namn som Wikipedia. Det verkar som om den behövs på vissa dokumentationssidor, så därför tas mallen inte bort helt.
Parametern halv= har tagits bort från både {{ö-topp}} och {{topp}}.
Senaste kommentaren: för 1 år sedan11 kommentarer3 personer i diskussionen
Hej! Är det möjligt att lägga till tr= som en valbar parameter för citat? Som nu är går det inte att lägga till translitterering om citatet använder mall. Svenji (diskussion) 22 oktober 2022 kl. 18.28 (CEST)Svara
Ja, det vore ju önskvärt! Rent tekniskt lätt att lägga till. Och vore ju även bra för vanliga exempelmeningar. Borde det isåfall rymmas inom citatmallen eller ska en ny mall skapas? Hur vill vi att slutresultatet ska bli? En extra rad? Isåfall, kan vi utgå från att första raden börjat med #: eller finns andra alternativ? ~ Dodde (diskussion) 22 oktober 2022 kl. 18.47 (CEST)Svara
Att mallen saknas språkparameter är ju ett problem, dock. Och känns inte så bra att lägga till parametern språk= när vi är mitt uppe i att överföra språk= till 1= i flera andra mallar. ~ Dodde (diskussion) 22 oktober 2022 kl. 18.51 (CEST)Svara
Wow, det gick snabbare än jag hoppats, om ändå jag misstänkte det inte var en stor teknisk manöver. Tack för det, Dodde! Jag tycker transkriptionsraden ser bra ut, och bra att den står direkt under originaltexten. Är osäker på paranteserna, men någon typ av markering, att detta enbart är en transkribering och inte hur språket skrivs på modersmålet, bör nog finnas. Jag skulle gärna se att vi någonstans (kanske under Uttal:Ryska, Uttal:Jiddisch, Uttal:Arabiska m.m.) även har ett stycke där vi förklarar vilken transkriberingsmetod som vi används på uppslagen. Men det hör till en annan diskussion. Svenji (diskussion) 24 oktober 2022 kl. 21.59 (CEST)Svara
Jag har också ett annat problem när jag skrivit citat med skrivsystem som går från höger, att fetmarkeringen hamnar helt off, hur jag än vrider och vänder. Några gånger har jag dock oförklarligt lyckats få det tillrätta genom att felplacera dem. Vet inte om detta också går att lösa på ett enklare sätt. se t.ex. på נוסח. Svenji (diskussion) 24 oktober 2022 kl. 22.06 (CEST)Svara
@Svenji Detta är definitivt fråga om en eller flera buggar. Jag börjar med att ta bort dina apostrofer. Första konstigheten är att när den exempelmeningen i wikitexten inkluderar en radbrytning så blir orden omkastade så att texten ser ut så här:
digitalishn '''nusekh'''.|publ=The Yiddish Daily Forward|.פֿון הײַנט אָן און ווײַטער וועלן מיר זיך אין
גאַנצן אָפּגעבן מיט אונדזער דיגיטאַלישן נוסח|Från och med idag kommer vi att helt ägna oss åt vår
...men när jag flyttar ner den hebreiska texten på en egen rad så faller orden på plats:
digitalishn '''nusekh'''.|publ=The Yiddish Daily Forward
|.פֿון הײַנט אָן און ווײַטער וועלן מיר זיך אין גאַנצן אָפּגעבן מיט אונדזער דיגיטאַלישן נוסח|Från och med idag kommer vi
Om jag redigerar i det första läget så blir resultatet helt knasigt. Så jag utgår ifrån det nedre exemplet ovan.
Om jag nu placerar ut ''' till vänster och till vänster om "נוסח", så tolkas den vänstra ''' som en separat "left-to-right"-textsträng, medan den högra hamnar som en del av den hebreiska meningens "right-to-left"-textsträng.
Fast det ser rätt ut i wikitexten, så renderas det hela helt fel.
Ett sätt att göra så att det renderas rätt är att flytta den vänstra ''' längst ut till höger:
|.פֿון הײַנט אָן און ווײַטער וועלן מיר זיך אין גאַנצן אָפּגעבן מיט אונדזער דיגיטאַלישן '''נוסח'''|Från och med idag kommer vi att helt
Exakt detta blir också resultatet när man markerar ordet man vill fetmarkera och klickar på wikitexteditorns "F"-knapp.
Av någon outgrundlig anledning så flyttar den alltså bort den vänstra ''' och placerar den sist. Av någon ännu outgrundligare anledning gör den inte detsamma med punten, utan den hanteras och blir istället en del av "right-to-left"-textsträngen.
Den resulterande HTML-koden som genereras av detta, och som alltså renderas på ett sätt så att det ser korrekt ut, blir den här i min Chrome-webbläsare:
Whaat. Jag kanske missar något uppenbart här, men jag ser inte hur detta kan leda fram till ett korrekt utseende, men så är jag heller ingen expert på det här med scripts olika läsriktningar eller hur det är implementerat i webbläsaren. FireFox håller med Chrome om att detta funkar. Det renderas korrekt i båda webbläsarna. Om jag däremot klistrar in HTML-koden direkt i webbläsaren, så flyttas punkten till andra sidan exempelmeningen. MediaWiki håller definitivt på och trollar med renderingen på något sätt, och flyttar punkten så att det ska se rätt ut, men jag kan inte riktigt följa hur det går till. Tyvärr så har man missat att se vad som händer med punkten när det sker en radbrytning mitt i exempelmeningen (testa att kolla på נוסח på mobilen). Punkten blir kvar på första raden, trots att meningen fortsätter på nästa. :/
Eftersom fetmarkeringen visas rätt av e.m.m. fel anledning skulle jag råda till att inte fetmarkera ordet om det är det första eller sista i ett citat eller en exempelmening där språket som används läses från höger till vänster. Om den här buggen åtgärdas nån gång skull det kunna resultera i att alla sidor som en gång såg rätt ut, helt plötsligt inte gör det längre.
Om fetmarkeringen är mitt i en mening funkar det, för då uppstår inte det här problemet.
Ja, tydligen hade jag inte förstått hur allt detta funkade. Det jag trodde var buggar är, antar jag, "by design". Vem hade, som relativt novis på området, kunnat gissa att "right-to-left" och "left-to-right" inte hanteras tecken för tecken, utan i större enheter av right-to-left-text respektive left-to-right-text. Jag kan fortfarande inte förmå mig att tycka att redigering av right-to-left-text faller sig naturligt i en editor inställd för left-to-right-redigerande.
Jag skapade nu en {{rtl}}-mall som i sig inte gör redigeringen av dessa exempelmeningar att kännas mer naturlig, men, den verkar råda bot på "punkt-buggen" ovan och den förklarar iallafall ett sätt som man kan fetstila ett ord på, även i början eller slutet av en exempelmening med höger-till-vänster-text. I redigeringsläget ser det ibland knäppt ut, men det finns en förklaring till varför det ser ut så. Dock förstår jag knappt förklaringen som jag försökte skapa på {{rtl}} själv, så om nån vill försöka sig på att förbättra den, så kör på! ~ Dodde (diskussion) 26 oktober 2022 kl. 06.08 (CEST)Svara
@LA2 En modul kan ändra indata till utdata, så en modul skulle teoretiskt kunna ta en osorterad lista från wikitexten (om den ges som argument i en mall, t.ex. {{besläktade ord}} och _visa den_ som om den vore sorterad, men inte ändra den faktiska ordningen i wikitexten. Vill man ändra ändra den faktiskta ordningen i wikitexten så behövs JavaScript som bl.a. finesser baserar sin funktionalitet på. Vi har en finess som vi kallar för "Tidy" som vi håller på och jobbar på som gör den här typen av grejer. Bra förslag. Vi kan absolut ha med förslaget på önskelistan över funktionalitet. Jag la till det . Jag tänker dock att sortering generellt inte är helt trivialt att få till om man vill stödja specialfall, vilket nog behövs om det ska vara en del av Tidy-finessen.
Tills dess kanske man kan överväga att använda ett externt verktyg som t.ex. https://dataverktyg.se/sortera. Man kan ju också skapa egna script som kan göra det man vill, vilket är enklare än Tidy, men kanske bara funkar till viss del. Jag gjorde ett litet proof-of-concept på Användare:Dodde/sort template list.js. Du kan testa att importera det genom att lägga till textraden "importScript("Användare:Dodde/sort template list.js");" på sidan "Användare:LA2/common.js". Om du vill experimentera och göra egna ändringar så kan du kopiera över scriptet till din en undersida till ditt användarnamn "importScript("Användare:LA2/sort template list.js"); och isåfall uppdatera länken i "Användare:LA2/common.js. Scriptet fungerar så att du markerar en mall med innehåll t.ex. "{{besläktade ord|], ], ]}}" så att markeringen inkluderar exakt hela mallen men ingenting mer. När du släpper muspekaren (måste släppas inuti textarean) så sker sorteringen. ~ Dodde (diskussion) 10 november 2022 kl. 14.31 (CET)Svara
Engelska Wiktionary har mallar som sorterar, t.ex. der3 och der4. Se t.ex. en:bil#Swedish. Men det är fult att en osorterad lista ligger i källkoden. Man vill ha källkoden snygg och likadan som utskriften, så att det är lätt att se eventuella dubletter.
Din javascript-kod verkar fungera, men användargränssnittet är alltför kryptiskt. Jag vill ha en sortera-knapp ovanför redigeringsfönstret, intill pusselbiten för infoga mall och pennan för syntaxmarkering. När den knappen trycks, ska sorteringen tillämpas på det område som då är markerat. --LA2 (diskussion) 10 november 2022 kl. 18.22 (CET)Svara
@LA2 Ja, jag håller med om att man vill ha källkoden i samma ordning som utskriften. Javascriptet var bara ett proof-of-concept. Det visar att det går att fixa något lite snabbt och enkelt, men det har sina skavanker. Det är inte särskilt användarvänligt, det sker inte automatiskt, inte intuitivt, hanterar bara listor som består av ord utan komplicerad länksyntax, sorterar fel på många språk, inklusive svenska (ä sorteras före å, versaler soteras åtskilt från gemener) - för att det är så bokstäverna ligger i Unicode, ingen grafisk knapp att klicka på, men, kanske är det ändå bättre än ingenting om man känner till bristerna. Vill man ha det korrekt, ordentligt, prestandamässigt acceptabelt, kanske automatiskt, stödja alla språk, stödja mer udda syntax osv. Då är detta en rätt stor grej att fixa. Gärna det, men jag vill inte lova om eller i så fall när det kan bli aktuellt för mig att fördjupa mig i det, åtminstone. Jag skulle först se att vi kan få in språkkoderna i dessa mallar och att det kan ske smidigt genom Tidy, men vi är inte riktigt där, ännu, heller. ~ Dodde (diskussion) 10 november 2022 kl. 19.09 (CET)Svara
@LA2 Allt är nog enkelt om man kan det. Men jag har inte gjort det och för mig skulle det vara långt ifrån värt besväret. Det verkar som väldigt mycket krångel att gå igenom för att lägga till en bekvämlighetsknapp för en enskild användare. Om du själv vill göra ett försök, så kanske du kan hitta information här mw:Manual:Custom edit buttons. Se då till att knappen bara läggs till för dig personligen, om det nu ens är möjligt. Det finns två wikitext-redigerare som man kan behöva gå igenom proceduren för: 2010 wikitext editor och 2017 wikitext editor, den senare om/när den tas i bruk.
Om du tänkte att det här skulle vara en knapp att lägga till för samtliga användare, tänker jag att det är en väldigt dålig idé för en funktion som har så otroligt många brister som jag listade en del av tidigare, och att det dessutom vore svårt att kommunicera dessa till användare av funktionen. Det skulle kunna leda till en hel del röra med felaktiga sorteringar och redigeringar.
Vill man lägga till det här för alla, så är det bäst att göra det ordentligt och då tror jag att Tidy är en bättre väg att gå, men som sagt, det är ändå ett projekt av betydande storlek som vi pratar om även då. ~ Dodde (diskussion) 11 november 2022 kl. 11.40 (CET)Svara
Varning: Denna sida kan endast redigeras av administratörer och andra användare med rättigheten tboverride eftersom den matchar följande post i listan över otillåtna titlar:
(?!(User|Wikipedia|File)( talk)?:|Talk:)*.*\p{Cyrillic}.* # Cyrillic + Non-ASCII Latin
number of octet:s : 27
index 0 beg code $D0=#208 length 2 extra $9A codepoint U+$041A dec #1'050 К
index 2 beg code $D1=#209 length 2 extra $83 codepoint U+$0443 dec #1'091 у
index 4 beg code $D0=#208 length 2 extra $BD codepoint U+$043D dec #1'085 н
index 6 beg code $D0=#208 length 2 extra $B8 codepoint U+$0438 dec #1'080 и
index 8 beg code $D0=#208 length 2 extra $BC codepoint U+$043C dec #1'084 м
index 10 beg code $D0=#208 length 2 extra $B0 codepoint U+$0430 dec #1'072 а
index 12 beg code $D1=#209 length 2 extra $80 codepoint U+$0440 dec #1'088 р
index 14 beg code $D0=#208 length 2 extra $BE codepoint U+$043E dec #1'086 о
index 16 beg code $20=#32 length 1 SPACE
index 17 beg code $D0=#208 length 2 extra $A1 codepoint U+$0421 dec #1'057 С
index 19 beg code $D1=#209 length 2 extra $8D codepoint U+$044D dec #1'101 э
index 21 beg code $D0=#208 length 2 extra $BD codepoint U+$043D dec #1'085 н
index 23 beg code $D0=#208 length 2 extra $B3 codepoint U+$0433 dec #1'075 г
index 25 beg code $D1=#209 length 2 extra $8D codepoint U+$044D dec #1'101 э
Senaste kommentaren: för 1 år sedan7 kommentarer4 personer i diskussionen
Finns det någon bot som går runt och uppdaterar {{ö}} till {{ö+}} när nya sidor har skapats på andra språk av Wiktionary? Har det någonsin funnits? Eller borde det finnas? -- LA2 (diskussion) 12 november 2022 kl. 21.58 (CET)Svara
@Andreas Rejbrand Bra iakttagelse! Böjningsmallars kod ser olika ut, visar det sig nu när jag granskar den. Mallar som använder följande kod (t.ex. {{sv-subst-n-or}} på flicka) får ingen länk:
Böjningar av ''{{länka|{{{grundform|{{PAGENAME}}}}}}} {{{betydelser|}}}''
Medan mallar som använder följande kod (t.ex. {{sv-subst-n-ar}} på fisk) får det:
Böjningar av ''{{länk|<språkkod>|{{{grundform|{{PAGENAME}}}}}}} {{{betydelser|}}}''
Användning av {{länk}} genererar länkar på formen ], medan användning av {{länka}} genererar en enkel länk på formen ]. När "ord" är samma sak som sidnamnet gör MediaWiki om den enkla länken till icke länkad fetstilad text, till skillnad från länken som innehåller en ankare.
{{länka}} är äldre än {{länk}} och i början när den generella mallstrukturen utformades så använde alla grammatikmallar {{länka}} på det här stället. Det är nog därför det står kvar så i Wiktionary:Stilguide/Grammatik/Skapa_en_mall. I praktiken gav det samma resultat som att inte använda någon {{länka}}-mall över huvud taget. Så vi tänkte nog inte så mycket mer på det. Vi ville bara att uppslagsordet skulle vara fetstilat. När sedan {{länk}} skapades så övergick många mallar till att använda den istället för {{länka}}, och det resulterade i att ordet i grammatikmallen helt plötsligt blev länkat. Sen har man inte funderat så mycket mer på det, heller.
✔ Löst "wätzig" plus alla föreslagna för radering plus alla som jag har hittat just nu. Flytta ifall det går, och föreslå omdirigeringen för radering. Ifall det inte går att flytta, föreslår den dåliga sidan för radering. Tack för utredningsarbetet. Taylor 49 (diskussion) 24 januari 2023 kl. 11.20 (CET)Svara
OBS att "soft hyphen" (U+00AD) är ett tydligt tecken på kopiering från en annan webbplats. Att kopiera bara titeln ger "bara" strul med titeln, att kopiera ett drabbad ord ger strul med detta ord (röd länk mm), att kopiera definitioner är värre. Tack till alla som hjälper att skapa den här ordboken, men PLAGIERA INTE från andra ordböcker. Taylor 49 (diskussion) 24 januari 2023 kl. 11.27 (CET)Svara
Smartare "vad länkar hit"
Senaste kommentaren: för 1 år sedan1 kommentar1 person i diskussionen
Senaste kommentaren: för 1 år sedan4 kommentarer3 personer i diskussionen
@Dodde, @Taylor 49, @Skalman: Det verkar som om vi tillåter både rak apostrof (' U+0027) och krokig apostrof (’ U+2019) i artikelrubriken. Se följande två (olika):
@Gabbe, jag är osäker på när/var det har diskuterats, men jag har ett svagt minne av att principen är att rak apostrof ska användas i titeln, eftersom den är lättare att skriva. Motsvarande titel med krokig apostrof kan skapas som en omdirigering. Skalman (diskussion) 13 februari 2023 kl. 22.31 (CET)Svara
@Taylor 49 Fixat nu, men några av de felande testerna är korrekta, så 9 felande tester återstår att åtgärda. Verkar som om de automatiska ryska translitteringarna har slutat fungera. ~ Dodde (diskussion) 17 maj 2023 kl. 23.59 (CEST)Svara
Senaste kommentaren: för 1 år sedan5 kommentarer3 personer i diskussionen
På Toolforge finns ett verktyg Text-to-lexemes (en del av systemet Ordia, skapat av dansken F Nielsen) där man kan mata in en text och få ut en tabell med ord, där det framgår vilka ord som finns respektive inte finns som Wikidata lexemes för det angivna språket. Skulle det gå att skapa ett liknande för Wiktionary? Jag skulle t.ex. kunna skriva in "to be or not to be, that is the question" och ange att jag vill att detta kollas mot befintliga engelska ord i svenska Wiktionary. Om då "question" inte har något uppslag, så får jag en röd länk, så att jag kan skapa det uppslaget. Detta skulle antagligen mycket underlätta skapandet av saknade uppslag. Kanske finns det redan något sådant verktyg, som jag inte känner till? -- LA2 (diskussion) 20 maj 2023 kl. 21.50 (CEST)Svara
Jag känner inte till något sådant verktyg, och jag skulle också uppskatta det. Vad jag gör för närvarande (som kanske är av intresse för dig, @LA2) är att jag använder RegEx, till exempel via https://regexr.com/. På den övre raden fyller jag i + och på den nedre raden (under "replace") har jag ]. Det resulterar i att
to be or not to be, that is the question
förvandlas till
] ] ] ] ] ], ] ] ] ]
som jag sen klipp-och-klistrar i WT:Sandlådan och kollar vilka länkar som är röda. Det funkar inte exakt som det du beskriver (bland annat eftersom det inte tar hänsyn till vilket språk ordet är på, bara huruvida det finns ett uppslag). I min erfarenhet funkar det ungefär lika bra ändå. Gabbe (diskussion) 21 maj 2023 kl. 07.18 (CEST)Svara
Det skulle kanske vara möjligt att använda API:t.
constlang="Svenska";consttext="to be or not to be, that is the question";constwords=text.split(/+/u)// L = "letter" och M = "mark" (diakritiskt tecken), använder detta över /+/ för att stöda andra skriftsystem (t.ex. kyrilliskt).sort().filter((e,i,a)=>e&&e!=a);// tar bort dubbletter och potentiella tomma elementnewmw.Api().get({action:"query",prop:"categories",clcategories:`Kategori:${lang}/Alla_uppslag|Kategori:${lang}/Adjektivformer|Kategori:${lang}/Adverbformer|Kategori:${lang}/Substantivformer|Kategori:${lang}/Verbformer`,titles:words}).then(response=>{constmissing=;$.each(response.query.pages,(i,page)=>{if(!page.categories)missing.push(page.title);});console.log("], ]");});
Koden ovan skriver ut de ord som saknar uppslag med det valda språket till konsolen, i det här fallet: "], ]". Om du ändrar språk till "Engelska" (stor begynnelsebokstav) skrivs "]" ut, eftersom alla ord redan finns.
Det största problemet med den här metoden är att den troligen inte fungerar på längre texter då det förmodligen finns en gräns för hur många sidor som kan inkluderas i titles men om behovet finns så skulle detta nog kunna lösas genom att dela upp förfrågan i flera mindre förfrågningar. Andreasl01 (diskussion) 21 maj 2023 kl. 10.17 (CEST)Svara
Jag tror ändå att ett verktyg (program på Toolforge) med inmatningsruta är vad som behövs. Sedan kan man inte API-kolla varje ord i varje inmatning, utan man behöver ha en databas (kanske baserad på senaste XML-dumpen) där man kan se vilka uppslag som finns. För de som inte fanns i XML-dumpen, kan man göra API-anrop, så att man inte rapporterar som saknade de uppslag som har skapats nyligen. --LA2 (diskussion) 21 maj 2023 kl. 16.04 (CEST)Svara
API:t är enligt https://www.mediawiki.orghttps://dictious.com/sv/API:Query#query:titles begränsat till 50 sidor per anrop så, ja, någonting annat skulle nog behövas för längre texter. På den här sidan (Teknikvinden) finns just nu 18 032 ord, varav 3 831 unika. Det skulle alltså bli 77 anrop vilket inte är rimligt. Man kan få behörighet att kolla 500 sidor per anrop, då skulle man bara behöva göra 8 stycken, men din idé att först kolla en databas och sen API:t låter ändå mycket bättre. Andreasl01 (diskussion) 21 maj 2023 kl. 17.17 (CEST)Svara
Inloggning nekad
Senaste kommentaren: för 1 år sedan2 kommentarer2 personer i diskussionen
Svenji här, jag kan inte logga in på Wiktionary längre, möts av meddelandet:
2023-05-31 16:53:49: Allvarligt fel av typen "Exception"". Däremot fungerar Wikipedia att logga in på som vanligt. Någon som vet vad som har hänt, eller ännu viktigare - hur kan jag åtgärda det? /Svenji 46.25.7.4831 maj 2023 kl. 18.58 (CEST)Svara
Senaste kommentaren: för 1 år sedan4 kommentarer2 personer i diskussionen
Specialsidan för relaterade ändringar utgår från en kategori. Om den kategorin har språklänkar, så borde väl även relaterade ändringar kunna visa språklänkar till dessa kategoriers relaterade ändringar. Detta vore användbart för kategori:Ukrainska/Alla uppslag, som är en "senaste ändringar" (vad har hänt?) för uppslag på ett givet språk. Jag vill alltså att den ska länka direkt till sin engelska motsvarighet. -- LA2 (diskussion) 2 augusti 2023 kl. 09.55 (CEST)Svara
Jag förmodar att detta inte går. Den engelska motsvarigheten har inte heller språklänkar. Varför? Det handlar om en "Special:" sida som är utesluten från WikiData. Det som intresserar dig, nämligen ukrainska, matas in genom en HTML-parameter, det är inte ens en del av sidnamnet. Till sist går det inte att transkludera något som skulle innehålla gammaldags interwikimärken. Taylor 49 (diskussion) 2 augusti 2023 kl. 23.14 (CEST)Svara
Senaste kommentaren: för 1 år sedan2 kommentarer2 personer i diskussionen
Jag försökte se var felet låg, men hittar det inte. på uppslaget horunge möts jag av röd text:
"Luafel i package.lua på rad 80: module 'Modul:sort' not found.n Backtrace: : i funktionen "error" package.lua:80: i funktionen "load" package.lua:99: i funktionen "require" Module:categorize:1: i funktionen "chunk" mw.lua:496: ? : ?"
Senaste kommentaren: för 1 år sedan2 kommentarer2 personer i diskussionen
Vad tycks? Bra eller dåligt? Jag införde nu på prov en gammal idé från ryska Wiktionary, nämligen att återanvända "besläktade ord" i form av en mall. Första exemplet är ukrainska verbet читати (att läsa), som använder {{uk-besläktade-tjytaty}} (man får inte blanda latinska och cyrilliska bokstäver i sidnamn, därav transkriberingen), som räknar upp ett antal ord med samma stam (-läs-, -чит-). Mallen återanvänds i de blålänkade orden (прочитати, читальня, читач). Man kan jämföra ru:шаблон:родств:чит som har en stor utfällbar ruta med ryska ord besläktade med stammen -чит- (-läs-). Det skulle kunna bli tusentals sådana mallar, en för varje språk och ordstam. Men är det en börda att ha så många sådana mallar, eller en större börda att inte ha dem och i stället upprepa uppräkningen i olika artiklar? -- LA2 (diskussion) 15 augusti 2023 kl. 23.55 (CEST)Svara
Senaste kommentaren: för 1 år sedan2 kommentarer2 personer i diskussionen
Mallarna {{sammansättningar}} och {{besläktade ord}} verkar bara använda 1 parameter, även om man anger flera. Ingen kontroll görs, man får inget felmeddelande. Mallen {{synonymer}} gör en kontroll och sätter anropande artikel i kategori:Ogiltiga parametrar, om parameter 2 finns, men är annars lika. De bara anropar {{länka|{{{1}}}}}. Kanske kan man införa ett alternativ, när 2 parametrar ges (där 1 är en språkkod (sv) och 2 är en lista av ord utan klamrar), så anropas i stället {{länk|{{{1}}}|{{{2}}}}}? Det skulle vara mycket användbart. -- LA2 (diskussion) 16 augusti 2023 kl. 02.05 (CEST)Svara
Senaste kommentaren: för 1 år sedan4 kommentarer2 personer i diskussionen
I dag försökte jag skriva en mall där en deluppgift var att ta en språkkod som parameter (sv, da) och presentera språktes utskrivna namn (svenska, danska). Jag höll på att leta mig fördärvad innan jag hittade att det heter {{#language:sv}} = svenska. Varför är den informationen så svår att hitta? Var borde den stå? -- LA2 (diskussion) 23 augusti 2023 kl. 17.33 (CEST)Svara
Den där dokumentationen är långt ifrån lättläst. Vad betyder parametern "go", t.ex.? Det förklaras inte. Är det fel att skriva det kortare {{#language:sv}}? Det står inte. Varför skulle någon vilja skriva det längre {{#invoke:langfortemplate|go|sv}}?
Om vi vill dra fler medhjälpare till Wiktionary, så måste det bli enklare att bidra, inte svårare. Folk ska kunna skapa mallar, som t.ex. tar språkkod som en parameter och sedan placerar saker i rätt kategori i vars namn språknamnet ingår, exempel ]. --LA2 (diskussion) 23 augusti 2023 kl. 21.09 (CEST)Svara
Alla frågor besvarade nu? Att skapa bra mallar är svårt, det är ett faktum bevisat bortom allt tvivel efter 20 år med wikier. Det finns inga genvägar. Vill vi ha en ordbok med hög kvalitet, eller vill vi ha maximal mängd lättskapat skräp? Taylor 49 (diskussion) 23 augusti 2023 kl. 21.26 (CEST)Svara
Röda pluppar - hur?
Senaste kommentaren: för 1 år sedan8 kommentarer4 personer i diskussionen
Någon som kan förklara lite enkelt hur de röda plupparna dyker upp (de som endast är synliga i redigeringsvy, se exempelvis här. Ursäkta terminologin "röd plupp", de heter säkert något fint tekniskt. Vad jag förstått visar de datorn vart ett ord kan delas upp med bindestreck, men t.ex. i det länkade uppslaget förstör pricken wikilänkningen. 𐏐Frodlekis (Talk💆♂️) 2 november 2023 kl. 15.22 (CET)Svara
Hej! Om jag öppnar din länk så möts jag av det här: https://privat.rejbrand.se/wtminsting.png. Jag kan inte se några "röda pluppar". Det beror antagligen på att jag har en annan webbläsare än du. Om jag däremot stegar mig genom ordet "syskonskara" med piltangenterna så märker jag att det är ett osynligt tecken mellan "syskon" och "skara".
Om jag däremot kopierar hela texten och klistrar in den i min texteditor så ser det ut så här: https://privat.rejbrand.se/rteminsting.png. Här ser jag att att länken inte är "syskonskara" utan "syskon" + U+00AD: SOFT HYPHEN + "skara".
Unicodetecknet U+00AD: SOFT HYPHEN är, precis som du misstänker, en markör för lämplig avstavningsposition. Det är ett bindestreck, liksom - (U+002D: HYPHEN-MINUS) eller ‐ (U+2010: HYPHEN), fast osynligt tills uppritande mjukvara behöver radbryta texten inuti ordet. SOFT HYPHEN skall jämföras med ‑ (U+2011: NON-BREAKING HYPHEN) som är raka motsatsen: ett bindestreck som alltid visas men som, till skillnad från vanliga bindestreck, aldrig tillåter en radbrytning intill (i t.ex. en kod som A‑1 kanske man inte vill ha radbrytning efter strecket).
Så, till din fråga: texten i filen är alltså "syskon" + U+00AD: SOFT HYPHEN + "skara", d.v.s. en textsträng av längd 12 (inte 11). Det mjuka bindestrecket är osynligt av uppritande mjukvara, men förklarar att mjukvaran vid behov kan avstava här (och då blir strecket synligt sist på övre raden). Tyvärr förstör tecknet wikilänken, så det måste tas bort. Detta kan man göra genom att placera markören direkt till höger om tecknet (direkt till vänster om "skara") och trycka på Backspace. Alternativt kan man placera markören direkt till vänster om tecknet (direkt till höger om "syskon") och trycka på Delete. I en texteditor som min egen är tecknet inte ens osynligt, vilket gör det lättare att arbeta med. --Andreas Rejbrand (diskussion) 2 november 2023 kl. 15.42 (CET)Svara
Som tillägg till Andreas svar, kan jag förklara när den röda pluppen visas. Pametzma la till det mjuka bindestrecket redan när sidan skapades - jag vet inte hur/varför. I vissa program är det lätt att skapa dom (t.ex. i LibreOffice med Ctrl+-; på Mac med Opt+- (iaf för 15 år sen, när jag använde Mac senast)). Dom fyller ju faktiskt en funktion (se enwp).
På Wiktionary visas den röda pluppen för att markera osynliga tecken i redigeringsläge när man har aktiverat syntaxmarkering (se skärmbild). Man vet alltså inte exakt vilket tecken det handlar om, för det finns många, många osynliga tecken, och allihop (?) visas som röd plupp. Skalman (diskussion) 2 november 2023 kl. 21.54 (CET)Svara
Tack så hemskt mycket för de utförliga svaren. 🙏 De här plupparna dyker i princip alltid upp om jag kopierar text utanför redigeringslägen där skrifter som använder right-to-left möter left-to-right. Som ni vet har jag lagt till några tusen ord för jiddisch och hebreiska, men detsamma händer med arabisk skrift. Därför har jag alltid haft för vana att radera dem, men förstår när de dyker upp i ord på LTR-språk att den röda pricken också kan ha en avstavningsfunktion. Intressant att det alltså rör sig om flera olika (!) Unicode-tecken som dyker upp som röda pluppar, och även intressant att inte alla läsare kan se dem (för mig syns de bara när jag redigerar text). Personer som läser i mindre fönster eller med synnedsättning kan alltså tycka dessa är nyttiga, så genomonda kanske de inte är då.
Och de dyker endast upp när jag hårdkopierat texten från den Läs-sida och klistrar in den i via Redigera-fliken. Inte med "svara"-knappen för ovanstående kommentar. Efter varje jiddiskt ord innan mellanslaget dyker detta tecken upp. Om någon skulle undra. :) 𐏐Frodlekis (Talk💆♂️) 3 november 2023 kl. 00.40 (CET)Svara
I exemplen som du gav nu, är det U+200E "LEFT TO RIGHT MARK".
Vid rtl/ltr-skifte kan man förtydliga åt vilket håll det går med hjälp av osynliga unicodetecken: U+200E och U+200F. Se w:en:Right-to-left mark och w:en:Left-to-right mark för information om varför/hur dom kan användas.
Anledningen till att dom inte dyker upp med svara-funktionen är att syntaxmarkering inte är aktiverat där. Alla dessa osynliga tecken fyller egentligen en funktion, men eftersom det är fruktansvärt svårt för dom flesta av oss att redigera tecken som vi inte kan se, så är det enklast att eliminera så många som möjligt på svwikt (och om man behöver, kan man använda ersättningar som syns i wikitexten: ­ ‎ ‏). Skalman (diskussion) 3 november 2023 kl. 22.52 (CET)Svara
Senaste kommentaren: för 8 månader sedan3 kommentarer2 personer i diskussionen
Projekt Runeberg har äntligen bytt från http:// till https. Efter att jag har uppdaterat källmallarna, har Svenska Wiktionary cirka 2000 externa länkar till den gamla adressen (Special:Länksökning/http://runeberg.org/). De fungerar och blir automatiskt omstyrda till https, men kanske har någon bot-operatör lite långtråkigt och då kunde det vara läge att ändra dessa 2000 hänvisningar. LA2 (diskussion) 26 november 2023 kl. 12.37 (CET)Svara
Jag ställde frågan ovan 26 november 2023. Sedan lyckades jag återstarta LA2-bot och gjorde själv redigeringen på många sajter, inklusive här den 15 december 2023. --LA2 (diskussion) 24 februari 2024 kl. 00.38 (CET)Svara
Teknisk lösning för att undvika osynliga tecken i artikeltitel?
Senaste kommentaren: för 8 månader sedan2 kommentarer2 personer i diskussionen
Som jag nämnt ett par gånger tidigare, angående de vanligen osynliga tecknen som uppstår vid kopiering av skrift som skrivs från höger till vänster - dessa tecken ställer till det. Nu inte bara för mig. Dessa tecken som kan visas som röda pluppar i redigeringsgranskaren om man trycker på pennan, kan vi på något sätt göra så att de inte kan infogas i översättningsmallen? Och ännu viktigare, så att de inte därifrån osynligt ingår i ett nyskapat uppslags titel och adress? Jag har gjort många ändringar likt denna, och det enda sättet att uppmärksamma det är att inte interwikilänkarna visas till t.ex. en, he, ar Wiktionary. 𐏐Frodlekis (✍) 23 februari 2024 kl. 12.57 (CET)
Se t.ex. وثق. 𐏐Frodlekis (✍) 23 februari 2024 kl. 15.17 (CET)Svara
Jag har fixat så att man inte längre kan skapa sidor som innehåller vissa osynliga tecken. För att skapa وثق måste man nu vara administratör.
Det här är lurigt, så jag hoppas att jag inte har blockerat nåt som inte bör blockeras.
Lite så var det, ja. Har fått en del hjälp av ChatGPT så slipper peta in bokstav efter bokstav i alla fall. Dock får jag inte mallen att hitta rätt för dubbelbokstäver som t.ex. dh för albanska. Det är iofs ett mindre problem. 𐏐Frodlekis (✍) 26 februari 2024 kl. 23.30 (CET)Svara
Ah, tack, det var där reglerna står. Jag utgick från Appendix alfabet samt engelska Category:Language lemmas. Ska se över resterande nu, men tror jag inte hittade sorteringsfel i övrigt. 𐏐Frodlekis (✍) 27 februari 2024 kl. 21.42 (CET)Svara
Lua 101
Senaste kommentaren: för 6 månader sedan5 kommentarer3 personer i diskussionen
På rad 70 i Modul:ca-subst anropas funktionen removeAccent med den odefinierade variabeln second_last_1 som argument. Argument används sedan i ett anrop till funktionen mw.ustring.gsub som förväntar sig en textsträng i den positionen, därav felet "Script error during testing: bad argument #1 to 'gsub' (string expected, got nil)" (odefinierade variabler är nil). Lösningen skulle vara att definiera second_last_1, baserat på namnet förmodar jag att den ska vara sidnamnets näst sista bokstav (på samma sätt som last_1 är sista och last_2 är de två sista). Det kan även vara bra att se över resten av rad 70, just nu står det plur = removeAccent(second_last_1) .. "os", i de andra elseif-blocken konkateneras pagename, without_last_1 eller without_last_2 till början av plur, jag misstänker att detsamma ska göras här (troligen without_last_2 men det har nog du bättre koll på). Andreasl01 (diskussion) 19 april 2024 kl. 20.32 (CEST)Svara
Senaste kommentaren: för 4 månader sedan8 kommentarer4 personer i diskussionen
Jag får numera följande meddelande när jag klickar på grönlänkade översättningar för att skapa ny sida: <strong class="error"><span class="scribunto-error" id="mw-scribunto-error-3346f18d">Luafel i Modul:entry på rad 95: parameter "h3" missing for entry_type = "translation".</span></strong> Testat inloggad och utloggad, på två enheter i Safari, bägge med Sonoma 14.5. 𐏐Frodlekis (✍) 7 juni 2024 kl. 16.06 (CEST)Svara
Tack båda två för buggrapporten och för hänvisningen till HTML-ändringarna. Tyvärr bestämmer användarens valda tema huruvida den gamla HTML-syntaxen eller den nya ska användas, så jag har anpassat så att bägge stöds. När den gamla syntaxen är helt borttagen från alla teman (om några veckor?), så ska jag förenkla koden så att bara den nya syntaxen stöds.
Tack för buggrapporten. Den här var lite krångligare att fixa, men jag tror att det ska funka nu. Om du ändå hittar nåt specialfall som inte funkar, säg till! Skalman (diskussion) 15 juni 2024 kl. 22.34 (CEST)Svara
Senaste kommentaren: för 3 månader sedan13 kommentarer3 personer i diskussionen
Hej, jag är intresserat av att förbättra svenska och danska lexikaliska data på Wikidata. Jag tänker börja skapa lite funktioner likt och för olika typer av svenska substantiver så det går att böja dem maskinellt.
Jag tänker försöka mig på att skapa en funktion för varje av de sex deklinationerna som finns beskrivna här: w:Substantiv#Böjning
Är nån här intresserat av att hänga på och skapa funktioner för svenska?
OK, det finns funktioner att hita ... men jag blir för närvarande mindre klok av dem. Plus som du skrev på annat ställe går det för närvarande EJ at anropa dessa från andra wikier. Fortsätt gärna diskussionen uteslutande här. Taylor 49 (diskussion) 14 juli 2024 kl. 17.53 (CEST)Svara
Uppdatering: Nu har jag skapat ett gäng funktioner för svenska substantiv.
Jag hittade oregelbundna substantiv som inte passade in i Svenska Akademins klassificering så jag skapade två egna klasser. Målet är att det ska vara busenkelt för användaren att välja den funktion som ger rätt böjningsmönster. Se f:User:So9q för en översikt. Jag har testat med alla substantiverna på Kategori:Svenska/Oregelbundna substantiv och vad jag kan se klarar mina 8 pluralfunktioner av alla förekommande fall nu :)
Jag välkomnar återkoppling och hjälp från er, låt oss skapa funktioner tillsammans som täcker alla former av alla svenska ordklasser, det är kul! :) So9q (diskussion) 17 juli 2024 kl. 04.49 (CEST)Svara
Fast kan valet av rätt funktion (hos oss: rätt mall) någonsin bli busenkelt? För ryska, ukrainska, belarusiska har vi (jag) i princip gett upp och räknar upp alla böjningsformer i stället för att försöka välja rätt mall (funktion) och utvärdera om det blev rätt. Man måste nog vara infödd modersmålstalare för att kunna bedöma det utan att sitta och detaljkolla mot en pålitlig källa. Om valet vore busenkelt, skulle vi se en massa misstag i stil med pojkerna och ekerarna, när någon som kan språket halvbra har gissat vilken som är rätt böjning. --LA2 (diskussion) 17 juli 2024 kl. 13.59 (CEST)Svara
hammer och plektrum har flera pluralformer så jag skapade Z18002. Jag skulle vilja varna användaren när den anges som input, men det går inte än att kalla funktioner mellan WF funktioner.
För singulare tantrum som musik, m.fl. skapade jag Z18006
Uppdatering: endast två funktioner kvar tills alla svenska substantiver täcks!
Svenska substantiver är de mest komplicerade av alla språk som det finns funktioner för än så länge i Wikifunctions vad jag kan se i katalogen. Mycket mera komplicerade av svenska verb som bara har 4 grupper för böjning om jag förstått rätt.
Nu kanske ni undrar: hur vet användaren vilken funktion som ger rätt böjningsmönster för ett givet substantiv? Det går att skapa en funktion för det om man vill också. Det tänker jag dock inte göra utan lämnar det till en modig och kanske ännu lite mera grammatisk kunnig själ 😀
Jag tänker använda funktionerna till Wikidata Lexeme Forms där vi behöver skapa nya former för alla nio klasser plus en form for singulare tantrum. So9q (diskussion) 20 juli 2024 kl. 07.34 (CEST)Svara
Jag la till två uttalanden på wikidata:Lexeme:L473175. Dessa behövs när vi skapar funktioner på Wikifunctions framledes så systemet vet hur substantiven funkar i meningar när text ska genereras.
Mina substantivfunktioner är förresten bara för att hjälpa folk som skapar eller redigerar lexem på Wikidata, inte för att generera text. De måste således inte nödvändigtvis hantera alla udda fall. Jag skapade 3 nya klasser mest för att visa att Svenska Akademien inte gjort klasser som täcker alla vanliga substantiv.
Jag ogillar personligen när folk utger sig för att vara experter och sakkunniga och sen inte håller måttet.
Svenska Akademien ligger långt efter när det gäller öppna data om svenskan. Det drabbar dagligen alla som försöker lära sig svenska och saknar bra data och APIer så är pålitliga och lättanvända.
Frågan är då hur ett system som skapar meningar ska veta vilken som används?
Jag har inget bra svar på den frågan.
Kanske kan systemet fråga om vilken betydelse av sticka som avses av användaren, kanske kan det själv deducere det från input. I dagsläget har vi AIer som chatgpt som endast är byggt på statistik, inte på bra och tillförlitlig språkdata och funktioner skapade av människor med output som går att lita på. So9q (diskussion) 23 juli 2024 kl. 09.15 (CEST)Svara