Wiktionary:Teknikvinden

Definition från Wiktionary, den fria ordlistan.
Hoppa till navigering Hoppa till sök


Välkommen till Teknikvinden!

Detta är samlingsplatsen för diskussioner som rör de mer tekniska aspekterna bakom Wiktionary-projektet, såsom mallar och moduler. Känn dig välkommen att delta!

Skapa ett nytt stycke för ditt meddelande

Gå till Fikarummet om du vill diskutera något som har med språk att göra, eller Bybrunnen om du har mer allmänna frågor om Wiktionary.

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


Arkiverade diskussioner:

Filing cabinet icon.svg

Insource[redigera]

insource-sökningar har jag funnit mycket användbara sedan jag blivit varse om dess existens. Hur gör man dock om man vill söka efter något med tecknet | (VERTICAL LINE)? När jag har skrivit in insource:/X|Y/ då har den letat efter alla gånger X skrivits, och alla gånger Y skrivits men jag letar ju efter just X|Y. Vänligen hjälp mig!Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 12 november 2018 kl. 14.10 (CET)

@Jonteemil Googla reguljära uttryck/regular expressions. Då får du reda på en mängd användbara koncept som du kan använda för att forma din sökning. Tecken som ^$[]()|/\ m.fl. har speciella betydelser och "escape":as med ett \-tecken. Du skriver alltså /X\|Y/. ~ Dodde (diskussion) 12 november 2018 kl. 15.20 (CET)
@Dodde: Tack!Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 12 november 2018 kl. 16.55 (CET)

Botgöra 3[redigera]

Genom [1] begöver inte längre uppslag med parametern are= i {{sv-subst-n-0}} rot-parametern. Om någons bot kan ta bort den så vore det super. Det är alla uppslag [2].Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 13 november 2018 kl. 20.20 (CET)

Det är bara 119 sidor. Eller glömde du kanske de övriga sidorna [3] som har "are=" och "rot=" i omvänd ordning? Då blir det 1'170 sidor. Taylor 49 (diskussion) 16 november 2018 kl. 09.33 (CET)
@Taylor 49: Jag menar som du visar alla uppslag som använder are=-parametern, oavsett ordning. Har någon en bot som kan ta bort rot= på dessa 1170 sidor?Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 24 november 2018 kl. 17.43 (CET)
@Dodde: Du som nyligen använde din bot för att ta bort alla {{ö-mitt}}, skulle du kunna fixa det?Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 28 november 2018 kl. 03.37 (CET)
@Jonteemil, @Taylor 49 Jag hittar ingen dokumentation till den här magiska funktionaliteten och jag kan inte utläsa ur koden vad den gör. Är den ens önskvärd? Jag kan inte komma på något sätt att beskriva det på ett enkelt och begripligt sätt och det är inte positivt att mallkoden krånglas till ytterligare. Jag kan inte heller bedöma om ändringen är säker. Jag föreslår en revertering. ~ Dodde (diskussion) 28 november 2018 kl. 04.51 (CET)
@Jonteemil: Hittills har ingen bot tagit bort alla {{ö-mitt}}. Med den tas bort i ett enskilt ö-block då en lägger en ytterligare översättning via JS.
@Dodde: Jag förstår knappast vad du menar. Vad ska reverteras? Vilken mall ska eller inte ska krånglas till ytterligare? Förresten, hela wikigrejen (MediaWiki + tusentals Extensions) har redan krånglats bortom det rimliga (Har någon koll på all JavaScript och all CSS? Inte jag. Även privat JS och privat CSS lär finnas.). För 20 år sedan brukade Internet funka med alla webbläsare och utan JS. Nu måste en "uppdatera" alla sina datorer och mobiler nästan varje dag, annars slutar diverse viktiga tjänster funka. Nu har den här diskussionen slutgiltigt degenererat. Vi kan rösta om en revertering så snart som det är klart vad som ska reverteras. Taylor 49 (diskussion) 28 november 2018 kl. 12.51 (CET)

@Taylor 49: Det hen menar är min ändring [17] som nämns där uppe.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 28 november 2018 kl. 12.58 (CET)

Men nu kör boten som ett jehu ... en redigering varje 3 sekunder. Hur snabbt får en bot köra? Det finns regler som utkräver "åtminstone 30 sekunder paus mellan redigeringar". Angående din ändring 17 [4] ... är det inte bra? Jag har inte studerat koden, men har vi inte haft en massa sådana förbättringar tidigare? Det är lite korkat att behöva ange en "rot" som redan finns. Mall-koden är förresten allt utom vacker ... med all "}}}}}}}}}}}}}}}}}}}}" ... jag skulle troligast brygga hela tabellen via LUA istället. Det här måste diskuteras separat. Jag voterar emot en revertering. Taylor 49 (diskussion) 28 november 2018 kl. 13.10 (CET)
Visionen är väl att alla mallar ska skrivas i LUA men än så länge är det bara adjektiven där det har lyckats. Därnäst är nog verben för där har vi all data åtminstone, sen kanske substantiven. Som du säger dock är det bäst om endast rot=:s vara eller icke vara i {{sv-subst-n-0}} diskuteras här. Det blir så himla sprötigt annars.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 28 november 2018 kl. 13.35 (CET)
Det är omöjligt att göra koden i LUA om ingen kan läsa och förstå mallkoden eller bedöma alla konsekvenser som en ändring skulle ge. Det är så många slarviga malländringar som gjorts att jag tappat räkningen. Dokumentation saknades även denna gång. Mallkoden har inga tester som felar om något blir fel, och vad jag känner till skapar inte Jonteemil några listor över alla användningar för att bedöma om användningar kan ge oväntade konsekvenser. Därför är det viktigt att det är tydligt hur parametrar fungerar och vad de gör. Det är fler än den som skapar mallen som ska kunna förstå hur den ska användas. När det gäller en serie mallar så är det viktigt att funktionaliteten är motsvarande. Det är orimligt att rot=parametern i en av ett dussin substantivmallar plötsligt inte ska användas, i vissa fall på grund av en svårbegriplig magi har lagts till. Om magin inte kan förklaras eller användningen av mallen inte förenklas, så är det orimligt att göra den här typen av ändringar. Denna diskussion har vi haft tusen gånger och är lika tröttsam varje gång. Så, nej, det är inte en förbättring, enligt min mening, för jag kan inte se i nuläget att vinsten med att slippa ange rot= i dessa specialfall överväger förlusten med en mycket krångligare beskrivning av substantivmallarnas användning. Detta oavsett framtida mallar byggda på LUA-moduler eller ej. ~ Dodde (diskussion) 28 november 2018 kl. 19.34 (CET)

@Dodde: Menar du att ”magin” ska beskrivas i Wiktionary:Stilguide/Grammatik/Svenska/Substantiv?Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 28 november 2018 kl. 21.40 (CET)

Ja, grammatiksidorna är de sidor som bör användas för att beskriva mallarnas användning och funktion. Enkelhet och enhetlighet bör väga väldigt tungt. Magi kan i vissa fall förenkla användningen, samtidigt som den är lätt att beskriva, som i portugisiska adjektivmallen {{pt-adj}}. Som du ser där beskrivs hur mallen fungerar på ett systematiskt sätt, syntaxen är enkel (alltid utan parametrar) men varje ändelse beskrivs vad den genererar för böjningsformer. Man behöver alltså inte i detalj beskriva vilka operationer som utförs i koden, det kan man ju titta i koden direkt för, men det kan vara bra att exempelvis förklara varför en parameter finns (eller varför den undantagsvis inte finns) men bäst av allt är om det är så enkelt att ingen beskrivning behövs. Det kan också vara bra att beskriva vad som sker när man använder parametern. Det är en balansgång. I det här fallet krånglar det till användningen inte bara för den aktuella mallen, utan för samtliga substantivmallar, för man måste nu fungera på om mallen man använder ska använda rot= eller inte - det behöver man inte tänka på om samtliga substantivmallar använder rot=. Det är olyckligt och bör starkt undvikas. Det krånglar även till användningen av den aktuella mallen för att man måste sätta sig in i onödigt krångliga regler, när det innan bara hade räckt att använda en enkel huvudregel - "använd rot=". ~ Dodde (diskussion) 28 november 2018 kl. 22.51 (CET)
@Dodde: Okej, då kan jag skriva en beskriving av mina ändringar i stilguiden👍🏻.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 29 november 2018 kl. 00.44 (CET)
@Jonteemil Det verkar inte som du läste mitt svar ordentligt, om detta var din behållning av vad jag skrev. Om ändringen gör det enklare överlag, ska det beskrivas där, men i detta fallet gör det sannolikt inte det, av alla de skäl som jag radade upp. Lösningen är i det här fallet att återställa ändringarna omgående för att undvika att onödiga fel uppstår till följd av att mallen används under tiden. Att skriva in dokumentation för en malls funktioner som inte ska behållas är ju inte så bra. ~ Dodde (diskussion) 29 november 2018 kl. 07.12 (CET)
Vi har redan tagit bort diverse rötter flera gånger. Jag ser ingen fördel med att behöva upprepa hela ordet i syntaxen. På "sidan assisterande domare" är det mycket bättre att skriva {{sv-subst-n-0|are=}} än {{sv-subst-n-0|are=|rot=assisterande domar}}. Parametern "rot" borde helt avvecklas, inte bli tvingande i alla mallar. Att strunta i att upprepa ordet i onödan är ingen "obskyr magi", utan ett effektivt och rimligt tillvägagångssätt. Jag instämmer i att mallkoden suger och inte borde krånglas till ytterligare, men drar inte slutsatsen att Jonteemils redigering borde genast återställas utan bevis att denna är felaktig. Jag ser att det redan har hänt flera gånger att Jonteemils redigeringar på mallar och moduler har återställts av Dodde. En redigering borde inte underkännas enbart eller främst på grund av att en särskild person har genomfört den. Taylor 49 (diskussion) 29 november 2018 kl. 13.57 (CET)

I vissa fall behövs dock pluralrot, t.ex. på nöt eller get. Jag kan dock inte komma på ett fall där rot ska behövas.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 29 november 2018 kl. 14.29 (CET)

Alltför ofta hamnar det i omvänd bevisbörda i de här diskussionerna rörande Jonteemils malländringar. Det åligger den som gör ändringar att säkerställa att de är säkra och är i enlighet med dokumentationen. Det misslyckas Jonteemil påfallande ofta med. Det kan inte åligga mig eller någon annan att hitta och peka ut alla brister. Det har skett så många gånger att jag tappat räkningen och jag har bett Jonteemil att upphöra med de här ogenomtänkta och många gånger buggiga ändringarna, ändå fortsätter han och får nu stöd av dig Taylor. Jonteemil gör en fantastiskt massa bra saker, det är inte det, men malländringarna håller ofta inte tillräckligt god kvalitet. Mallkod är inte enkelt och det är många aspekter att ta hänsyn till och helst bör det stötas och blötas och vridas och vändas på innan ändringar genomförs. Jag har skrivit en lång lista till Jonteemil över saker som behöver åtgärdas efter fel som skapats (länge sen nu) men Jonteemil har inte visat något intresse av att städa upp efter sig när det gäller dessa malländringar. För att förhindra långtgående skador kan snabba återställningar av malländringar som utförs av vissa personer vara den enda vägen. ~ Dodde (diskussion) 30 november 2018 kl. 04.42 (CET)

Förslag kring substantivmallar[redigera]

Jonteemil genomförde nyligen en kontroversiell förbättring på mallen {{sv-subst-n-0}}. Detta ledde (se ovan) till "lite" missnöje och en degenererad diskussion utan resultat. Förslag:

  • Jonteemils redigering ska inte reverteras utan hårda bevis att denna är felaktig.
  • Utan trängande skäl ska inga ytterligare redigeringar på substantivmallarna genomföras, särskilt inte sådana som gör koden mer komplicerad, innan det råder konsensus kring hur syntaxen och implementeringen ska se ut i framtiden.

Den som röstar NEJ till detta kan gärna lägga fram alternativa förslag. Taylor 49 (diskussion) 29 november 2018 kl. 14.08 (CET)

Låter som omvänd bevisföring. Ändringen är kontroversiell och bör återställas tills det finns konsensus för att avvika från praxis. Jag har givit många skäliga argument, alltför många gånger dessutom. ~ Dodde (diskussion) 29 november 2018 kl. 17.57 (CET)
Jag har återställt @Jonteemils ändringar i mallen, eftersom ändringarna innehåller buggar. Jag återkommer snart med mer info. Skalman (diskussion) 29 november 2018 kl. 23.31 (CET)
Som Dodde säger så ligger det faktiskt på mig att argumentera för min ändring, inte på andra att argumentera mot den. Jag tycker ändå jag gjort det och som sagt ändrat i Stilguiden. Om ändringen som Skalman säger däremot resluterat i buggar så förstår jag självfallet varför den återställs. Ginge det att undvika dessa buggar så ser jag ingen anledning till varför den inte skulle införas, med tanke på förklaringen i Stilguiden.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 29 november 2018 kl. 23.40 (CET)
Jag har demonstrerat buggen på Användare:Skalman/test/sv-subst-n-0-jonteemil. Detta är ett utmärkt exempel på varför komplicerad mallkod bör undvikas. Att skriva mallkod är skitsvårt! Om sån här logik ska implementeras, så skulle jag föredra en ny mall {sv-subst-n-0-are} (som kanske bara anropar {sv-subst-n-0}).
{{sv-subst-n-0|are=}} har orsakat problem också i augusti 2017. Jonteemil gjorde då en ändring som tar bort en "feature", men den lämnar kod som inte längre behövs. Fixat. Skalman (diskussion) 30 november 2018 kl. 00.23 (CET)
@Skalman: Varför är det en bugg? har {{sv-subst-n-0|are=|testare}} skrivits någonstans som eller? Då skulle jag i så fall säga att det är den sidan, snarare än mallen som bör uppdateras.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 30 november 2018 kl. 00.36 (CET)
@Jonteemil: Jag tror inte någon sida skriver så, men alla våra grammatikmallar stödjer den syntaxen. Förklaring:
Man kan ange 1=, 2=, 3= ... för att direkt sätta innehållet i olika celler. Om man inte anger nåt parameternamn, så sätts namnet automatiskt till nästa siffra. Alltså är alla dessa ekvivalenta: {{sv-subst-n-0|are=|testare}} {{sv-subst-n-0|testare|are=}} {{sv-subst-n-0|1=testare|are=}}.
Om man angav 1= i det här fallet, så blev det alltså fel i cell 2= och 4=, vilket knappast är förväntat resultat. Skalman (diskussion) 30 november 2018 kl. 00.47 (CET)

@Skalman: Nu ändrade jag i och för sig mallen så det gick, men ska det verkligen behövas? Behöver verkligen alla msllar följa den syntaxen i alla fall? Jag tänker att alla ord som har are= har ju ett bestämt böjningsmönster helt utan undantag så jag kan tycka att min ändring fortfarande är befogad. Den s.k. ”buggen” förstör ju ingenting. Nu säger jag inte att du har fel utan bara att regeln att alla substantivmallar måste följa den syntaxen bör ändras lite för alla ord med are=.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 30 november 2018 kl. 01.43 (CET)

Ja, det är mycket viktigt. Jag ser på de här funktionerna som ett interface (sök på det - varför är interface viktigt). Det är ett kontrakt som upprättas för alla mallar. Att man ska kunna använda numrerade parametrar på ett visst sätt. Att man ska kunna använda vissa allmänna namngivna parametrar och att de ska fungera på ett visst sätt. Det förbättrar kvalitén, minskar risken för oväntade fel, det underlättar för användaren att lära sig vad som gäller och vara trygg med att detta gäller överallt. Alla dessa undantag kanske sparar ett par tangenttryckningar i det enskilda fallet, men komplicerar till det nåt ofantligt när man ska lära sig hur man ska gå tillväga för att ange rätt mallsyntax. Din beskrivning som du la till nyss, om undantaget, är i det närmaste obegriplig för alla andra än dig själv, skulle jag tro, vilket jag iofs kunde förutse. Jag är inte säker på att jag skulle kunna beskriva det mycket bättre. Det är hela min poäng. När beskrivningen blir så komplicerad är det bättre att göra det enkelt och skippa att bygga in onödig magi i mallkoden. ~ Dodde (diskussion) 30 november 2018 kl. 04.57 (CET)


Målprioritering[redigera]

Det känns som om dessa diskussioner har sitt ursprung i att vi prioriterar olika mål. Jag försöker här beskriva vad jag ser som våra olika utgångspunkter, och försöker argumentera för att undvika magi. Min bild:

  • Mål 1: Det ska gå lätt att förstå hur mallar/moduler fungerar. "Magi" ska undvikas i möjligaste mån.
    Innebär också: Dokumentationen måste vara bra. Alla mallar bör fungera på ungefär samma sätt. Alla mallar tillsammans bildar en enhet.
  • Mål 2: Mallsyntaxen i uppslagen ska vara så enkel/kort som möjlig.
    Innebär också: Mallsyntaxen kan bli svårare att förstå. Kräver viss magi.

Båda dessa mål har fördelar, och programmeraren i mig driver mig mot mål 2 (DRY). Däremot måste Wiktionary fungera långsiktigt, och det ställer krav såsom att vem som helst ska kunna förstå mallkoden, mallar ska antingen vara "uppenbara" eller måste testas noggrant. Ju mer magi som finns i mallarna, desto svårare blir det att göra förbättringar och fixa buggar (vilket tydligt demonstreras här, där Jonteemil skapat två problem pga. samma mall med samma parameter).

När nåt blir fel, är det dessutom lättare att söka upp sidor som har en viss parameter, än att söka upp sidor som behöver en extra parameter.

Jag uppmanar @Jonteemil och @Taylor 49 att omvärdera, och prioritera mål 1 framför mål 2. Skalman (diskussion) 30 november 2018 kl. 00.23 (CET)

Jag kan inte bestämma mig för "mål 1" eller "mål 2":
  • > Det ska gå lätt att förstå hur mallar/moduler fungerar
Viktigt.
  • > "Magi" ska undvikas i möjligaste mån.
Beror på vad som tolkas som magi. Vi har en massa bra magi i "Modul:sv-adj". Och lite mindre bra och odokumenterad magi i "Modul:tagg" (att gömma vissa anteckningar från kategoriseringen).
  • > Innebär också: Dokumentationen måste vara bra.
Viktigt.
  • > Alla mallar bör fungera på ungefär samma sätt. Alla mallar tillsammans bildar en enhet.
Jag skulle helst se bara en mall för alla SV substantiv. Men vissa parametrar såsom "not" borde visst vara samma i alla mallar.
  • > Mallsyntaxen i uppslagen ska vara så enkel/kort som möjlig.
Viktigt. Mallen ska gissa mönstret utifrån ordet, främst ändelsen. Ifall gissningen går fel, använd en namngiven parameter för att rätta till. För att ytterligare justera, använd ytterligare namngivna parametrar. Mallen ska vara smart så att extra parametrar behöver användas så lite som möjligt. Gör vi inte på så sätt med adjektiv?
  • > Innebär också: Mallsyntaxen kan bli svårare att förstå.
Det behövs LUA. Koden med }}}}}}}}}}}}}}}}}}}}}} suger och det går inte även att använda variabler.
  • > Kräver viss magi.
Kanske. Magi måste dokumenteras.
Jag uppfattar särskilt parametern "rot" som löjlig. Vi har över 1'000 ord som slutar på "-are" och alla (utom ca 2) följer samma mönster. Mallen borde gissa mönster från ändelsen. Jag skulle gärna se (passare) {{sv-subst}} som tillräckligt. För andra ord, till exempel (fot) {{sv-subst|plo=fötter}}.
> Jag uppmanar "Jonteemil" och "Taylor 49" att omvärdera, och prioritera mål 1 framför mål 2
Prioriterar vi inte redan tvärtom för adjektiv?
> men alla våra grammatikmallar stödjer den syntaxen
Jo ... liten. Och detta är utan tvekan en fördel.
> Man kan ange 1=, 2=, 3= ... för att direkt sätta innehållet i olika celler. Om man inte anger
> nåt parameternamn, så sätts namnet automatiskt till nästa siffra. Alltså är alla dessa ekvivalenta:
> {{sv-subst-n-0|are=|testare}} {{sv-subst-n-0|testare|are=}} {{sv-subst-n-0|1=testare|are=}}
Jag skulle helt avveckla anonyma parametrar i komplicerade mallar. De försvårar bara förståelsen och höjer risken för buggar. Taylor 49 (diskussion) 30 november 2018 kl. 12.48 (CET)
Jag håller med om det mesta.
  • "Det behövs LUA" Ja, det löser många problem, som testning och viss tydlighet. Jag skulle ha mkt mindre emot såna här förbättringar, om det fanns många tester, så att vi kan verifiera att det inte blir buggar.
  • "Prioriterar vi inte redan tvärtom för adjektiv?" Jo, kanske. Jag skulle gärna se en tydligare förklaring av vilka transformationer sv-adj gör. Det verkar också som att svenska adjektiv är mer regelbundna än substantiv, vilket underlättar. Vidare har Dodde gjort ett gediget arbete med att analysera alla olika typer av adjektiv. För mig är det inte uppenbart att den uppsättning subst-mallar motsvarar alla "typer" av substantiv på svenska. Som jag skrev tidigare, så skulle jag nog inte ha nåt emot en ny mall {sv-subst-n-are}, ist.f. are=.
  • "Jag skulle helt avveckla anonyma parametrar" Med Lua skulle det inte behöva krångla till koden särskilt mkt.
Skalman (diskussion) 30 november 2018 kl. 17.52 (CET)
Angående svenska adjektivmallarna. Vi ville nå mål 2 utan att tumma på mål 1. Jag gör som du, Taylor, en skillnad i tolkning av magi och magi. Jag anser att magi kan vara ok om det är något som användaren inte behöver oroa sig för (som i {{sv-adj}} m.fl.), eller om resultatet av magin är transparent (som i {{pt-adj}}). I båda fallen kan "magin" studeras i detalj i själva modulkoden - till skillnad från mallkod som är betydligt svårare att läsa.
Vi har gjort omfattande analyser av de svenska adjektivens böjningsmönster. Vi har gått igenom samtliga användningar av de svenska adjektivmallar som fanns innan vi skapade modulen. Vi har skapat ett stort antal tester för att försäkra oss om att modulkoden skapar de korrekta böjningsformerna. Vi har kommit fram till att det inte är möjligt för koden att gissa allt. Vi har kommit fram till att man kan göra ett lackmustest för att avgöra om adjektivet följer huvudböjningsmönstret, annars följer det ett alternativt böjningsmönster. "De har +t i neutrum, +a i plural." Detta är allt användaren behöver veta för att veta om {{sv-adj}} eller {{sv-adj-alt}} ska väljas. Det spelar ingen roll vilken ändelse adjektivet har, vilket var en viktig upptäckt under det här arbetet. Det finns också en grupp adjektiv som skiljer ut sig väldigt tydligt. Det är de adjektiv som är helt oböjliga i positiv. Syntaxen och användningsinstruktionerna är väldigt genomtänkta att vara så enkla som bara är möjligt, utan att tumma på att samtidigt minimera risken för att en användare råkar använda fel mall eller syntax och därmed av misstag inkludera felaktiga böjningar i tabellen. Om adjektivens böjningsmönster hade innehållit fler oregelbundenheter är det inte alls säkert att vi hade kunnat ha den här approachen. Vi har gjort den här analysen innan vi genomförde förändringen.
Jonteemils malländringar är allt annat än genomtänkta, analyserade, testade, gjorda utifrån ett helhetsgrepp (alla mallar i en uppsättning hör ihop). De görs spontant och utan tanke på eventuella konsekvenser, utan att fundera på att hålla dokumentationen uppdaterad, och det är bråttom att få mallarna återställda så fort som möjligt för att minimera skadorna. Magi i dessa fall är extra skadliga. Jag gör själv få malländringar, för jag vet hur svårt det är att få det rätt. Det är mycket bättre att spendera tiden på att göra research och kvalitativa analyser, som i utformningen av {{pt-adj}} och några fler språks adjektivmallar som Jonteemil stod för det mesta arbetet med.
Jag är inte emot förbättringar i mallar, men med tanke på hur komplicerat det är och hur stor risk det är för fel, är det är bättre använd tid att fokusera på hur vi kan skapa bra moduler. Tyvärr har jag inte tid att djupdyka i det just nu, men som jag nämnt tidigare är jag beredd att bistå med modulkodande om research- och analysarbetet görs av någon annan. ~ Dodde (diskussion) 1 december 2018 kl. 01.58 (CET)

(Förmodad) CSS-bugg[redigera]

Har vi en bugg här? Taylor 49 (diskussion) 11 december 2018 kl. 12.24 (CET)

Fixat. Skalman (diskussion) 11 december 2018 kl. 18.57 (CET)
Vad bra ... det gick snabbt. :-) Taylor 49 (diskussion) 11 december 2018 kl. 19.26 (CET)

En stilla undran[redigera]

Hej och ursäkta mitt rättframma språk, men jag har undrat över en sak... Har ni någonsin funderat på att riva hela stället och göra om till en kopia av engelska Wiktionary (vad gäller formen, utseendet, strukturen, moduler, mallar osv), så att det inte ser ut som att året fortfarande var 2002? Det är verkligen inte menat som ett påhopp alltså, en uppriktig undran. Allahverdi Verdizade (diskussion) 27 december 2018 kl. 14.02 (CET)

@Allahverdi Verdizade: Jag vet inte vad som skulle behöva rivas för att vi skulle bli mer lik en.wikt. Det är bara att ändra färger, storlek på vissa mallar o.s.v. Personligen tycker jag inte att vare sig en.- eller sv.wikt. ser ut att vara från 2002 direkt :), men visst, alla har rätt till sin åsikt. Strukturen här gillar jag också. Mycket enklare än en.wikt.:s. Moduler kan jag inget om men de flesta är väl snarlika antar jag. Varför tycker du sv.wikt. är sämre än en.wikt. på varje av dina nämnda ”delar” (form, utseende, struktur, modul, mall).Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 27 december 2018 kl. 14.58 (CET)
Ja, var ska man börja. Att ta en sån sak som etymologier bara. Hur funkar de på en.wikt och hur funkar de på sv.wikt? Det är ju rena rama katastrofen. Det finns inga mallar som motsvarar {suf}, {der}, Mall:inh, Mall:bor. Ingenting. {etymologi} skapar inga kategorier, vad är den ens tänkt att göra? Det är som att möjligheterna som ett elektroniskt uppslagsverk erbjuder används till 5%. Det är som ett pappersverk, bara att uppslagen är sökbara. Med andra ord så är svenska wiktionary ungefär lika bra som en control+F-bar pdf fil av en pappersordbok... Allahverdi Verdizade (diskussion) 27 december 2018 kl. 16.03 (CET)
@Allahverdi Verdizade: {{etymologi}} motsvarar ju en.wikt.:s etymologiavsnitt, inte någon mall, och är därför inte tänkt att kategorisera någonting. Vår motsvarighet till en:T:der är ju {{härledning}} och den kategoriserar på samma sätt som dess engelska motsvarighet. Mallar för suffix, prefix och interfix kan jag hålla med om vore bra men det är ju inte allt för svårt att skapa. Ingenting behöver rivas där direkt :). Det var en grej. Vill du ha någon konkret förändring föreslår jag att du är lite mer tydlig om var du vill ha förändring. Nu nämnde du en grej bara.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 28 december 2018 kl. 00.09 (CET)
@Jonteemil Jag förstår det som så att ni tidigare hade underrubriker, men har gjort er av med dem och nu kretsar allting, från etymologier till avledningar kring enskilda definitioner. Det är olyckligt. Särskilt att avledningar och sammansättningar är tvungna att nästas i enskilda definitioner.
Men det största problemet är ju förstås för få mallar och kategorier. Det räcker inte med en mall, härledning. Det är såpass stor skillnad mellan lån, härledning, arv, affixering och sammansättning att alltihopa kan bara inte lemmas in under en och samma mall. Samma sak med mallen besläktade ord... ord kan vara besläktade på så många sätt. Är det ord som är kognater? Avledningar från samma rot? Är det ena avlett från det andra? Dubletter? "Besläktat" borde vara en etikett man tar till när man inte riktigt vet exakt hur ord är besläktade Allahverdi Verdizade (diskussion) 28 december 2018 kl. 01.40 (CET)
@Allahverdi Verdizade: Avledningar och sammansättningar behöver inte nästlas under enskilda definitioner, utan kan läggas under en {{avgränsare}}. Det finns vissa fördelar med att sätta etymologi under definitionen och inte tvärtom: betydelser med samma ursprung kan ha olika vägar in i språket och olika första användning.
Jag tror inte att det är aktuellt att börja om från början. Om du har förslag på en prioriterad förändring som är otvetydigt förbättrande och som kan genomföras så att våra uppslag fortfarande är konsekvent utformade, så kan vi hjälpas åt att införa den på sv-wikt. Skalman (diskussion) 28 december 2018 kl. 08.58 (CET)

Добро пожаловать, новичок. Tagga ner och börja arbeta. Det som är trasigt och behöver fixas är ru.wiktionary, inte sv. Sv är litet, men vackert och det växer och blir större. Inte minst har vi nu under 2018 fått böjningsmönster för 500 ryska verb. Du kanske kan hjälpa till med nästa 500? Etymologierna fungerar bra även utan kategorier, men inget hindrar att du börjar utveckla dem. Mindre snack, mer verkstad. --LA2 (diskussion) 28 december 2018 kl. 02.08 (CET)

> Har ni någonsin funderat på att riva hela stället
NEJ.
> och göra om till en kopia av engelska Wiktionary (vad gäller formen, utseendet, strukturen, moduler, mallar osv)
NEJ. SV Wiktionary är mycket bättre än EN Wiktionary. To be frank, EN Wiktionary sucks.
> så att det inte ser ut som att året fortfarande var 2002?
Vad är det som är fel?
Taylor 49 (diskussion) 22 januari 2019 kl. 15.32 (CET)

Genvägar[redigera]

Skriver man Wt:X kommer man till Wiktionary:X, skulle någon kunna göra så att Kat:X på leder till Kategori:X, liksom en:Cat:X leder till en:Category:X på en.wikt.?Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 10 januari 2019 kl. 13.35 (CET)

Av wt:Bybrunnen/Arkiv14#WT samma namnrymd som Wiktionary? att döma så ska man tydligen efterfråga detta på ”bugzilla”, vad nu det är.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 10 januari 2019 kl. 20.13 (CET)
Det låter som en bra idé. Jag ser inga negativa konsekver.
Bugzilla är ett bugg- och ärendehanteringssystem som Wikimedia brukade använda. Numera används Phabricator. Jag föreslår att vi väntar några dagar, så att övriga får chansen att säga sitt innan vi lägger in ett ärende på Phabricator. Skalman (diskussion) 13 januari 2019 kl. 23.07 (CET)
Låter bra.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 14 januari 2019 kl. 13.11 (CET)
@Jonteemil, jag har skapat en förfrågan på phabricator:T214329. Skalman (diskussion) 21 januari 2019 kl. 20.49 (CET)
@Jonteemil, detta är nu infört på sv-wikt. Skalman (diskussion) 23 januari 2019 kl. 17.05 (CET)
Perfekt!Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 23 januari 2019 kl. 17.06 (CET)

Tagg-förkortning[redigera]

Jag skapade en kategori:Ryska/Substantiverade adjektiv. För att tagga ord där skulle en rad behöva läggas till i Modul:tagg/data som kopplar:

taggar["substantiverat"] = {visa="[[substantiverad|substantiverat]]", kat={"Substantiverade adjektiv"}}

I dag skriver jag i artikeln верующий:

#{{tagg|kat=substantiverade adjektiv|text=substantiverat i maskulinum|språk=ru}} [[troende]] (person)

Men i stället vill jag kunna skriva som följer. --LA2 (diskussion) 22 januari 2019 kl. 15.10 (CET)

#{{tagg|substantiverat|text=maskulinum|språk=ru}} [[troende]] (person)
Det finns inga tester kopplade till modulen och jag har inte varit med och skapat den så jag vågar inte gå in och ändra. @Moberg, vill du ta dig en titt? Jag är lite tveksam till att man ska behöva gå in i modulkoden för av avkoda vilka specialord som kan användas och vad de gör, men det kanske är en annan fråga. ~ Dodde (diskussion) 24 januari 2019 kl. 00.25 (CET)
Koden med logik ligger ju i Modul:tagg, medan dessa ord ligger i undersidan /data som en rak och enkel lista. --LA2 (diskussion) 24 januari 2019 kl. 00.29 (CET)
Jag är fortfarande inte nöjd, men lämnar diskussion därhän just nu. Jag har lagt till raden du efterfrågade. ~ Dodde (diskussion) 24 januari 2019 kl. 00.39 (CET)
Det nuvarande resultatet fungerar mycket bra för mig. Det finns nu 44 artiklar i kategorin och man skulle kunna lägga dit många fler. --LA2 (diskussion) 24 januari 2019 kl. 22.18 (CET)
Bra ~ Dodde (diskussion) 25 januari 2019 kl. 02.16 (CET)
Testen ligger som sagt direkt under modul:tagg (modul:tagg/test). Sorry för konfunderingen med "/data". –dMoberg 31 januari 2019 kl. 09.34 (CET)

Teknisk göra[redigera]

Ibland råkar jag börja en diskussion men sedan kommer jag på mig själv att jag glömt trycka på ”nytt ämne” så då trycker jag där men allt som jag skrivit försvinner då. Nu har jag lärt mig att man måste kopiera det man skrev och sen klistra in det när man tryckt på ”nytt ämne”. Det är dock lite jobbigt så jag undrar bara om någon kunnig kan fixa så att texten man skriver följer med så att säga när man trycker på ”nytt ämne”. Det vore uppskattat!Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 23 januari 2019 kl. 15.04 (CET)

@Jonteemil, får du inget varningsmeddelande i en popup-ruta: "Vill du lämna webbplatsen? Ändringar som du har gjort kanske inte sparas."? Det är standard för alla formulär att fungera så, så jag vet inte om det är något vi vill ändra. @Skalman, vad säger du? ~ Dodde (diskussion) 24 januari 2019 kl. 00.34 (CET)
@Dodde: Jag får inget varningsmeddelande.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 24 januari 2019 kl. 09.16 (CET)
@Jonteemil: Låter som en bugg. Vilken webbläsare använder du? Svara gärna med {Firefox, Edge, Internet Explorer, Chrome, Safari} på {Windows, Mac, Linux, Ios, Android}.
Fwiw, i Firefox så kommer texten tillbaka om man trycker på bakåtknappen. :-) Skalman (diskussion) 24 januari 2019 kl. 19.11 (CET)
Safari på iPhonn. Texten kommer tillbaka här också men är ändå lite irriterande att man ska behöva gå tillbaka och kopiera texten.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 24 januari 2019 kl. 19.17 (CET)
@Jonteemil, jag har rapporterat en bugg om detta för att få till varningen också i iOS. Får se vad dom säger. Skalman (diskussion) 24 januari 2019 kl. 20.24 (CET)
Perfekt👍🏻.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 24 januari 2019 kl. 21.52 (CET)
@Jonteemil, jag vet inte om du vill testa att lägga in "importScript("Användare:Dodde/areyousure.js");" på Användare:Jonteemil/common.js och rensa cachen, och se om det gör nån skillnad? Eftersom jag redan innan får upp en ruta så vet jag inte riktigt hur jag ska testa detta själv. ~ Dodde (diskussion) 25 januari 2019 kl. 02.42 (CET)
Jag har inte testat det, men jag är rätt säker på att detta inte kommer funka. Det verkar som att mobilt Safari kräver nånting med pagehide... Skalman (diskussion) 25 januari 2019 kl. 08.25 (CET)

Botgöra 4[redigera]

Kan någon göra så alla ord i Kategori:Svenska/Substantiv som ska få fog byter mall till {{sv-subst-n-oräkn|fog=}} istället för {{sv-subst-n-oräkn|2=<ordet>n}}. Orkar inte göra det manuellt men kan göra det om är krångligt att lösa det med bot.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 2 februari 2019 kl. 21.40 (CET)

@Jonteemil I och med Modul:sv-subst kommer syntaxen ändå ändras, så det är nog bortkastad tid att ändra på syntaxen nu, på sidorna i kategorierna. Behåll gärna kategorierna så kan jag använda mig av den informationen. ~ Dodde (diskussion) 3 februari 2019 kl. 02.33 (CET)
Låter rimligt👍🏻.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 3 februari 2019 kl. 20.27 (CET)
Kunde inte hålla mig, gjorde det ändå manuellt.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 3 februari 2019 kl. 20.41 (CET)

Länkar till #Svenska #Adverb etc #Svenska/Adverb (flytt)[redigera]

Flyttat från Moduldiskussion:sv-adj#Adverb eftersom detta är en principiell diskussion, inte något specifikt för Modul:sv-adj. Taylor 49 (diskussion) 4 februari 2019 kl. 14.50 (CET)

@Dodde: Kan du göra så att adverbavledningarna i {{sv-adj-0}}, {{sv-adj-0-peri}} och {{sv-adj-0-okomp}} länkar till [[<ordet>#Adverb|<ordet>]] istället för [[<ordet>#Svenska|<ordet>]]?Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 31 januari 2019 kl. 15.48 (CET)

@Jonteemil Jag vet att det varit så i någon mall, men jag frångick det medvetet när modulen utvecklades. Jag är osäker på om #Adverb är att föredra framför #Svenska, men inte heller säker på motsatsen. Att övergå till #Svenska var av konsekvensskäl, att så sker i andra mallar och för andra språk. Om man ska länka till ordklassrubriken bör det nog göras för samtliga språk isåfall, inte bara för svenska. Isåfall behöver mer än modulen ändras. Mer specifika ankare måste isåfall placeras ut i html-koden. Jag är inte helt säker på hur det isåfall görs bäst. Finns alternativ till JavaScript? @Skalman, input? ~ Dodde (diskussion) 1 februari 2019 kl. 00.07 (CET)
@Dodde, @Jonteemil, eftersom svenska (nästan alltid) är första språk, så funkar länkar som #Adverb för svenska, medan det inte gör det för andra språk. Jag skulle föredra en lösning där svenska får länkar till ordklass, såsom Jonteemil föreslår.
Om vi vill kunna länka till #Svenska/Adverb, så bör vi gå över till en lösning som fr-wikt har, där alla rubriker anges med mallar, dvs ==={{h3|sv|adverb}}===. (För jag tycker inte att det är acceptabelt att lösa det med JavaScript.) Skalman (diskussion) 1 februari 2019 kl. 07.20 (CET)
@Skalman det blir dock fel om adverbrubriken saknas i det svenska avsnittet medan det finns en adverbrubrik i det engelska avsnittet. Känns som ett fulhack. Men det kanske fortfarande är det minst dåliga valet. Är andra alternativ uttömda? ~ Dodde (diskussion) 1 februari 2019 kl. 23.10 (CET)
Sant - det blir fel om adverbrubrik saknas. Jag antar att man skulle kunna skapa ankaret "#Svenska/Adverb" via {{adv|sv}} och {{sv-adv}}... Då får man på nåt sätt placera ankaret ovanför ovanvarande rubrik. Jag känner mig lite tveksam till om sådan komplicerad CSS är att föredra. Dessutom skulle HTML:en bli lite felaktig. Skalman (diskussion) 2 februari 2019 kl. 09.12 (CET)
Och "{{h3|sv|adverb}}" skulle fixa detta? Hur vore det med "===(SV) Adverb===" , "===(ID) Räkneord===" etc? Taylor 49 (diskussion) 4 februari 2019 kl. 14.54 (CET)
@Taylor 49, ja med "{{h3|sv|adverb}}" kan man lägga in ett ankare.
Tekniskt så skulle också "===(SV) Adverb===" funka, men det blir rätt fult att visa språkkoder i alla rubriker. Skalman (diskussion) 4 februari 2019 kl. 17.00 (CET)
Hur vore det med "=== Adverb{{ankareh3|sv|adverb}}==="" då mallen "h3ankare" är osynlig? Kanske är "===(SV) Adverb===" fult, men det skulle lite underlätta orientering på sidor som är långa och innehåller många (liknande) språk med flera ordklasser per språk. I nuläget finns inte många sådana, så att det här väl inte är ett trängande problem. Taylor 49 (diskussion) 5 februari 2019 kl. 11.35 (CET)
Det skulle faktiskt räcka med "===Adverb{{ankare|sv}}===", men då kanske man lika gärna kan gå hela vägen till "==={{h3|sv|adverb}}==="? Båda dessa varianter är rätt Jag tycker att det är en acceptabel lösning, men vet inte om det är nån som orkar ta tag i det hela, och vet heller inte om folk tycker att syntaxen är acceptabel... Om vi hade komplicerad syntax innan, så gör ju inte det här saken bättre... Skalman (diskussion) 5 februari 2019 kl. 16.42 (CET)
Inget av nämnda alternativ känns riktigt bra. Jag tycker att vi låter det vara som det är. Att man länkas till språkavsnittet, även om språkavsnittet är svenska. I de flesta fall ställer det inte till med några problem. ~ Dodde (diskussion) 5 februari 2019 kl. 17.01 (CET)

Namnrymder och wikidata[redigera]

Vem är det som kan skapa namnrymder? Bara byråkrater? Taylor 49 (diskussion) 12 februari 2019 kl. 13.14 (CET)

Då försöker jag igen ... ns:102 finns ej på listan en.pedia.org/wiki/Wikipedia:Namespace ... vem är det som har skapat denna namnrymd och hur gör en? Hur kan en fixa sidan d? Taylor 49 (diskussion) 19 februari 2019 kl. 14.26 (CET)
@Taylor 49:
Skapa namnrymder
Bara Wikimedias serveradministratörer kan lägga till namnrymder, så vill man ha en ny så får man rapportera en bugg dit - alltså inte heller byråkrater. Detta kräver dock diskussion och att gemenskapen är överens.
Våra namnrymder
Namnrymder med id under 100 är inbyggda i MediaWiki, och t.ex. Appendix=102 är något som vi på sv-wikt har bett om. Dessutom har vi bett om Rimord=104 och Transwiki=106. Övriga namnrymder över 100 är sådana som ingår i tillägg till MediaWiki.
Uppslagsrymden
Denna namnrymd har inget riktigt namn. Den har id=0. Eftersom "Nej:" inte är en namnrymd hamnar "Nej:sida" i uppslagsrymden.
d:, w:, en:, fr:
"d:" används för att länka till Wikidata, "w:" för att länka till Wikipedia, "en:" för att länka till en-wikt och "fr:" för att länka till fr-wikt.
d, bh och Övriga uppslagsord
Pga. namnrymder eller interwikilänkar kan vissa uppslag inte skapas med rätt sidtitel. Lösningen är att lägga informationen på Övriga uppslagsord. Fel som beror på andra MediaWiki-begränsningar lägger vi på Övriga tecken.
Skalman (diskussion) 19 februari 2019 kl. 18.20 (CET)
Tack för svaret. Krångligt med "d:et", verkligen. EN ktionary har också en namnrymd "Appendix", men märkligt nog som ns:100!!! Måste en ny namnrymd verkligen beställas via bugzilla (är detta en bugg??) Wiktionary:Bybrunnen/Arkiv9#Namnrymder (6 månaders väntetid) Wiktionary:Bybrunnen/Arkiv11#Rapport_från_bugzilla.... Jag är inte så mycket sugen på nya namnrymder här. Jag ville bara veta hur en har gjort. Taylor 49 (diskussion) 20 februari 2019 kl. 12.52 (CET)
@Taylor 49: Namnrymder över 100 kommer i den ordning dom beställs. Väntetiden är inte alls lång, när vi väl talar om att vi vill ha den här typen av förändring. Senast tog det två dagar.
"Bugzilla" (liksom nuvarande "Phabricator") är ett slags ärendehanteringssystem - inte bara för buggar. Eftersom "bugg" inte är så bra beskrivning av vad det handlar om så döper olika system det omväxlande till "bug" (Bugzilla, Azure DevOps), "task" (Phabricator, Azure DevOps), "issue" (Gitlab, Github, Jira), "ticket" (Trac). Alltihop är samma sak.
Se även en:Appendix:Unsupported titles. Skalman (diskussion) 24 februari 2019 kl. 15.35 (CET)
Namnrymd Lampiran = Appendix har skapats. Lagom krångligt. Jaha, det har jag varit ute efter. Tack för hjälpen. Taylor 49 (diskussion) 14 april 2019 kl. 06.34 (CEST)
Namnrymd Aldono = Appendix har skapats med index 102. Inte "i den ordning dom beställs" utan "på det indexnummer som har beställts". Lagom krångligt. Jaha, det har jag varit ute efter. Tack för hjälpen. Taylor 49 (diskussion) 1 maj 2019 kl. 11.31 (CEST)

Välkomstmall för oinloggade[redigera]

Det tycks som att mallen {{logga in}} automatiskt avslutas med fyra tilde som dock sedan inte automatiskt omvandlas till användarnamn och tidstämpel på användardiskussionssidorna. Se Användardiskussion:2A02:908:C3B:9420:1CE5:236A:6910:E223 för exempel. Det som spökar är troligen att mallens kod såvitt jag kan se avslutas med

~~<includeonly/>~~<noinclude>[[Kategori:Wiktionary:Användarmallar]]</noinclude>

Som synes är serien av tilden där bruten med wikikod. Att hårdkoda användarnamn och datumstämpel in i mallkoden omnämns vad jag kan se första gången 2006 av @Dodde i diskussion med @Andreas Rejbrand (se Wiktionary:Bybrunnen/Arkiv7#Uppdateringar) och själva mallen i sin nuvarande utformning redigerades senast i september 2013 av @Skalman. Den används på ca 120 sidor. Förutom denna finns också den relaterade omdirigeringssidan Mall:Logga in som länkar till två sidor. Mvh, Tommy Kronkvist (diskussion), 23 februari 2019 kl. 14.12 (CET).

Om jag inte minns fel är mallen tänkt att användas genom substitution: {{subst:logga in}}. Samma sak gäller väl {{klotter}} och {{välkommen}}. --Andreas Rejbrand (diskussion) 23 februari 2019 kl. 14.29 (CET)
@Tommy Kronkvist, det som Andreas säger stämmer. Det borde nog dokumenteras bättre... Skalman (diskussion) 23 februari 2019 kl. 15.07 (CET)
@Andreas Rejbrand, @Skalman: Jag har redigerat diskussionsidan jag angav som exempel ovan, och med substitution fungerar det ju bra. I nuläget har ingen av {{klotter}}, {{logga in}} eller {{välkommen}} någon som helst dokumentation. Jag kan lägga till den senare under dygnet eller imorgon, om ingen annan hinner före. För närvarande är det bara mallen {{sandlådan}} i Kategori:Wiktionary:Användarmallar som nämner substitution i malldokumentationen. Är det tänkt att någon av de övriga mallarna i kategorin också ska substas? I sådant fall lägger jag gärna till informationen även för dem, men måste veta vilka mallar det gäller.
I dagsläget används de tre {{klotter}}, {{logga in}} och {{välkommen}}-mallarna på sammanlagt lite knappt 700 sidor. Efter att ha kollat ungefär 20 slumpmässiga av dessa (per mall, alltså sammanlagt ca 60) har jag inte funnit någondera mall substituerad på någon enda av dem. Har vi någon bot som skulle kunna substa sidorna i efterhand? Eller ändras tidstämpeln då – eller rentav användarnamnet? Dessutom har användare i vissa fall lagt till signaturen med fyra "manuella" tilden direkt efter mallen, och då skapar ju en bot bara dubbletter av redan befintliga signaturer. –Tommy Kronkvist (diskussion), 23 februari 2019 kl. 15.57 (CET).
Om man subst:ar mallarna kommer användarna få en ny notifiering/mejl, vilket väl inte är önskvärt. Jag tror att vi kan leva med 700 osubst:ade förekomster. Skalman (diskussion) 24 februari 2019 kl. 15.37 (CET)
@Andreas Rejbrand, @Skalman: Jag har nu skapat en dokumentationssida till mallen {{logga in}}. Ta gärna en titt på den och kom med synpunkter, innan jag går vidare och även kompletterar de övriga mallsidorna i kategorin. Mvh, Tommy Kronkvist (diskussion), 25 februari 2019 kl. 19.09 (CET).
@Tommy Kronkvist, det ser bra ut, tycker jag! Skalman (diskussion) 25 februari 2019 kl. 20.03 (CET)

Kinesisk språkkod (en kort fråga)[redigera]

Hej! Jag såg några ändringar härom dagen som en användare gjort i översättningsfältet från |zh| till |zh-tw|. Jag vet att vi har zh-tc (traditionell) och zh-sc (simplifierad) men då jag inte lagt intresset på kinesiska har jag inte koll på hur eller om vi använder dessa. Min fråga är: varför fungerar länkarna hon skapade med zh-tw? Det öppnar automatiskt zh.wiktionary. Har det något att göra med Taiwan? ╰ Svenji 1 maj 2019 kl. 11.09 (CEST) Efter en minuts vidare undersökning märkte jag att översättningarna är skrivna på förenklad kinesiska, zh-sc. Kanske är det därför att användaren inte använt sig av korrekt språkkod som länkarna heller inte förts in i översättningskolumnen? Ping @Taylor 49. Jag funderar på om det kan bli möjligt att i översättningsmallen kunna använda zh-sc och -tc men föra dessa under samma språk, kinesiska, men att inläggen följs av markering (traditionell) (förenklad). ╰ Svenji 1 maj 2019 kl. 11.19 (CEST)

Jag har noll koll på kinesiska men någon lägger notoriskt ö-ar under botten: [5]. Taylor 49 (diskussion) 1 maj 2019 kl. 11.26 (CEST)
Precis i början, om det var 2006 eller något, så utgår jag ifrån att det bestämdes att "zh" var den enda språkkoden som skulle användas och "kinesiska" var namnet på språket (för så väl enkel som klassisk kinesiska, för såväl mandarin som kantonesiska). Det är så det står skrivet i vår stilguide än idag. Det har nog konstaterats flera gånger sen dess att det valet förmodligen inte(?) var vare sig klokt eller korrekt. Men att ändra till något annat kräver både en hel del tid och kunnande. Jag tror att ingen hittills har känt sig manad eller haft förmågan. Om någon nu eller i framtiden vill och har förmågan, kunnandet och uthålligheten att ta på sig att genomföra ändringar på detta område är det bara positivt.
Anledningen till att zh-tw funkar beror vad jag kan se inte på något vi har lagt till i våra mallar eller moduler, utan är möjligen något som finns inbyggt i själva MediaWiki-mjukvaran. Jag hittar denna fil, som möjligen kan spela en roll, genom en googlesökning: https://doc.wikimedia.org/mediawiki-core/master/php/LanguageZh_8php_source.html ~ Dodde (diskussion) 1 maj 2019 kl. 16.19 (CEST)
Franska och tyska Wiktionary använder (liksom vi) språkkoden zh. Engelska Wiktionary (som väl borde veta bäst) använder cmn. Ryska Wiktionary använder zh-tw och zh-cn. Jag vet inte vad som är rätt och det verkar inte finnas någon entydig linje att följa. --LA2 (diskussion) 1 maj 2019 kl. 16.35 (CEST)
Notis
Delvis analogt med ovanstående listar Wiktionary:Stilguide/Språknamn fornhögtyska (goh), medelhögtyska (gmh), medellågtyska (gml), lågtyska (nds), pennsylvaniatyska (pdc) och tyska (de), samt med tyskan nära besläktade språk som till exempel alemanniska (als), bayerska (bar) och luxemburgiska (lb). Däremot listas inte schweizertyska (gsw), trots att det precis som föregående "tyskor" har en ISO 639-3-kod. Är det bara en miss eller finns det konsensus eller någon riktlinje som ligger bakom? Tommy Kronkvist (diskussion), 3 maj 2019 kl. 12.24 (CEST).
För svenska ords etymologi borde det vara "gml" (medellågtyska) som används oftast, av dem du räknade upp. Detta har jag ingen statistik på, men det borde väl gå att ta reda på. Att sitta och göra en ordbok över medellågtyska ord för deras egen skull, är däremot av marginellt intresse. Schweizertyska har förmodligen inte gett något enda inlån till svenska, utan den språkkoden har enbart användning för att dokumentera språket i sig. --LA2 (diskussion) 4 maj 2019 kl. 20.37 (CEST)
@Tommy Kronkvist Av intresse eller ej - har språket en ISO-kod så är utgångspunkten att det ska hanteras som ett enskilt språk här på svenskspråkiga Wiktionary, om inget annat bestämts. Om något sådant bestäms bör det framgå i stilguiden på sidan om språknamn. Jag har inte sett någon diskussion om att medvetet utelämna någon tysk språkvariant. ~ Dodde (diskussion) 6 maj 2019 kl. 04.16 (CEST)

Alla böjningsuppslag på alla språk[redigera]

Vi har 695.929 böjningsuppslag enligt huvudsidan (sidor i huvudnamnrymden) och närmar oss 700.000. Och om man summerar Kategori:Alla uppslag får man 319.321 huvuduppslag på alla språk (där telefon räknas som 10 uppslag). Men går det också att summera antalet böjningsuppslag över alla språk, så att telefoner räknas som två? --LA2 (diskussion) 15 maj 2019 kl. 12.06 (CEST)

Vad jag känner till finns ingen funktion som rapporterar hur många gånger en mall används. PAGESINCATEGORY rapporterar hur många sidor som finns i en viss kategori. Alla uppslag som använder {{böjning}} läggs i kategorin Språk/Verbformer (Substantivformer,Adjektivformer osv). Om man summerar alla dessa kategoriers sidantal så får man fram en siffra som räknar "telefoner" två gånger, en för Svenska/Substantivformer och en för Danska/Substantivformer. Dock fortfarande endast en gång mer språk och ordklass, så tomten räknas bara en gång, trots att det är en böjningsform både till tomt och tomte. Man kan summera siffror med EXPR, men PAGESINCATEGORY returnerar sidantal som inkluderar tusentalsavgränsare vilket gör att EXPR inte kan användas. Motsvarande går dock att uppnå med en modul, vari en funktion motsvarande PAGESINCATEGORY finns: t.ex. mw.site.stats.pagesInCategory("Bokmål/Verbformer"). Problemet som då återstår är att PAGESINCATEGORY (oavsett hur anropet sker, i en mall eller i en modul) räknas som en "dyr" förfrågan. Det finns en begränsning på 500 sådana dyra förfrågningar per sidanrop. Men väljer man t.ex. de 30 största kategorierna och uppskattar resterande med ett specifikt antal kommer man förmodligen betydligt närmare en korrekt angivelse av antalet böjningsformer än vad som för närvarande är fallet. Hur väsentlig den informationen är på förstasidan kanske dock kan ifrågasättas?
{{PAGESINCATEGORY:Bokmål/Verbformer|pages}} + {{PAGESINCATEGORY:Nynorska/Verbformer|pages}} = {{#expr: {{PAGESINCATEGORY:Bokmål/Verbformer|pages}} + {{PAGESINCATEGORY:Nynorska/Verbformer|pages}} }}
275 + 92 = 367
{{PAGESINCATEGORY:Danska/Verbformer|pages}} + {{PAGESINCATEGORY:Tyska/Verbformer|pages}} = {{#expr: {{PAGESINCATEGORY:Danska/Verbformer|pages}} + {{PAGESINCATEGORY:Tyska/Verbformer|pages}} }}
På grund av mellanslaget uppstår ett fel i uträkningen:
262 + 12 148 = Fel i uttryck: Okänt skiljetecken " " ~ Dodde (diskussion) 16 maj 2019 kl. 01.47 (CEST)
Mellanslaget trollar man bort genom att skriva ...|pages|R = 12410 --LA2 (diskussion) 28 maj 2019 kl. 19.25 (CEST)
Se där! Det hade jag missat. Tack för info. ~ Dodde (diskussion) 30 maj 2019 kl. 08.54 (CEST)

Ordklassmallar / motsvarande "{ {head} }"[redigera]

Kan ni inte modifiera motsvarande { {head} } så man slipper skriva ' ' 'term XY' ' ' för hand under mallen på vartenda uppslag? Ketiga123 (diskussion) 28 maj 2019 kl. 18.23 (CEST)

Förstår inte frågan. Taylor 49 29 maj 2019 kl. 22:43
Tidak apa-apa, pasti ada yang mengerti yang bisa menjawaban. Atau saudara selalu menjawab pertanyaan yang saudara tidak mengerti? Ketiga123 (diskussion) 30 maj 2019 kl. 01.25 (CEST)
Engelska Wiktionary har en mall "head" som inleder varje uppslag och skriver ut sidans namn i fetstil, så att man slipper skriva '''gurka''' i sidan gurka. Det är tydligen vad Ketiga123 önskar att även vi hade. Men våra mallar, t.ex. {{sv-subst-n-ar}} eller {{subst}}, fungerar ju inte riktigt på det viset. Och jag tror inte vi har lust att ändra på detta. När man skapar en ny sida hos oss, kan man ju använda ett formulär, som gör att man faktiskt slipper skriva '''gurka''' för hand. Detsamma gäller när man klickar på gröna länkar. --LA2 (diskussion) 30 maj 2019 kl. 01.42 (CEST)
Hm, det stämmer faktiskt. 85.229.254.57 30 maj 2019 kl. 14.20 (CEST)
@Ketiga123 Saya sama sekali tidak menjawab semua pertanyaan dengan "tidak mengerti". Apakah Anda menemukan banyak diskusi lain tempat saya menjawab "tidak mengerti"? Tidak ada templat "{ {head} }" di wikikamus ini. Dan sampai sekarang Anda membuat satu halaman saja. Taylor 49 (diskussion) 30 maj 2019 kl. 15.29 (CEST)
Jag är också mindre lycklig med uppslagens struktur, fastän av andra skäl. Taylor 49 (diskussion) 30 maj 2019 kl. 15.29 (CEST)
Vad är det för skäl? Ketiga123 (diskussion) 30 maj 2019 kl. 16.38 (CEST)
Kategori:Wiktionary:Ordklassmallar - 27 mallar som gör samma sak. Jag skulle föredra en mall för alla ordklasser. Dessutom {{subst|eo}} -> {{eo-subst}} ... varför kastas orden om ??? Taylor 49 (diskussion) 30 maj 2019 kl. 18.10 (CEST)