Wiktionary:Teknikvinden/Arkiv02

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)

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

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)

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)

• funkar
• trasigt (det saknas färg in användarrutorna)

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)

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)

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)

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 = {visa="]", kat={"Substantiverade adjektiv"}}

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

#{{tagg|kat=substantiverade adjektiv|text=substantiverat i maskulinum|språk=ru}} ] (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}} ] (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)

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)

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)

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 ] istället för ]?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)

• https://sv.wiktionary.orghttps://sv.wiktionary.org/w/index.php?title=Appendix:Om&action=info -> ns = ??? (även "Appendix" syns)
• https://sv.wiktionary.org/w/api.php?action=query&titles=Appendix:Om -> ns = 102
• https://sv.wiktionary.orghttps://sv.wiktionary.org/w/index.php?title=Nej:sida&action=info -> ns = ???
• https://sv.wiktionary.org/w/api.php?action=query&titles=Nej:sida -> ns = 0 !!!
• BUGG: d - alla böjningsformer är spruckna

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.orghttps://dictious.com/sv/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)

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>]</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)

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

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}} }}

425 + 149 = 574

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

548 + 12 944 = Fel i uttryck: Okänt skiljetecken " " ~ Dodde (diskussion) 16 maj 2019 kl. 01.47 (CEST)

Mellanslaget trollar man bort genom att skriva ...|pages|R = 13492 --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)

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)

Hej! Jag har som mitt mission att få till en skaplig ordbok för spanska, och jag saknar vissa parametrar till spanska verb. Många mallar finns redan, vissa av dem är helt otroligt smarta. Tack den som suttit med detta! Då jag inte är nog teknisk för att modifiera de långa mallarna, skulle jag önska mig att vi utvecklade ett per parametrar. Egentligen vill jag kunna ha något sätt att modifera en hel tempus-rad, t.ex. vid oregelbunden presens, subjunktiv eller liknande. Men först:

1. Mall:es-verb-cer|'zco=

Används för en mängd verb som slutar på -cer, till exempel conocer, entristecer, crecer med flera.

Den skulle ändra indikativ presens första person (yo) från -co till -czo, samt presens subjunktiv till -zca, -zcas, -zca, -zcamos, -zcáis, -zcan. Vidare ändrar den även imperativ affirmativ från tredje person (formellt andra person: usted, "ni") till -zca, -zcamos, -zcad, OFÖRÄNDRAT I 2:A PERSON PLURAL (vosotros),-zca, -zcan. Sist men inte minst modifierar parametern också negativa imperativer, redan från andra person (tu) -zcas, -zca, -zcamos, -zcáis, -zcan.

Är detta möjligt att få till, som en början? ╰ Svenji 13 september 2019 kl. 19.28 (CEST)

Jag, som inte behärskar spanska, tänker inte peta i detta. Det finns idag 13 mallar es-verb-..., många skapade 2007 och 2010, några senare. Alla innehåller tabellkod. Detta är (i mina ögon) något hemskt, som är svårt eller omöjligt att underhålla. Om jag hade påbörjat detta i dag, så hade jag skapat en enda mall med tabellkod där man anger alla böjningsformer som parametrar, kanske med namnet es-verb, och sedan utvecklat olika mallar som anropar denna, men själva inte innehåller någon tabellkod utan bara grammatisk logik. Men nu påbörjas ju inte detta i dag. Givet de 13 befintliga mallarna, är nog det enklaste att bara kopiera all kod från es-verb-cer till en ny mall es-verb-cer-zco där du gör de nödvändiga förändringarna. Då behöver dina nytillskott inte förstöra för några andra verb som fortsätter att använda den gamla mallen. Jag tror det var så @Jonteemil gjorde och tänkte 2017 vid skapandet av Mall:es-verb-ar-accent utifrån Mall:es-verb-ar. --LA2 (diskussion) 13 september 2019 kl. 19.57 (CEST)

Lite statistik som stöd för resonemanget. Det finns i dag 439 anrop av dessa 13 spanska verb-mallar. Anropen fördelar sig så här på mallarna: es-verb-ar (309 anrop), es-verb-ar-accent (3), es-verb-car (22), es-verb-cer (2), es-verb-cir (3), es-verb-eer (2), es-verb-er (23), es-verb-gar (17), es-verb-ger (2), es-verb-gir (1), es-verb-ir (26), es-verb-uir (2), es-verb-zar (27). --LA2 (diskussion) 13 september 2019 kl. 20.04 (CEST)

I vänstermarginalen på svenska Wiktionary ser jag de olika språken i följande ordning: Nederlands, Occitan, Oʻzbekcha/ўзбекча, Polski, Português, Suomi, Tiếng Việt, Türkçe, Ελληνικά, Български, Монгол, Русский, Српски / srpski, Тоҷикӣ, Українська, det vill säga att alla namn som skrivs med latinska alfabetet kommer före namn skrivna med grekiska och kyrilliska alfabetet. Ordningen Türkçe, Ελληνικά, Български känns baklänges. Ska det vara så, eller har det råkat bli så på grund av att jag gjort fel inställningar? På engelska Wiktionary ligger grekiska Ελληνικά mellan latinska Eesti och Euskara och efter latinska Português följer kyrilliska Русский, Српски / srpski, innan man kommer till latinska Suomi, som man kunde förvänta sig. --LA2 (diskussion) 14 september 2019 kl. 15.00 (CEST)

Jag tycker det är mer eller mindre självklart att de olika språken bör listas i bokstavsordning oavsett skriftsystem, så gott det nu går. Alltså som på engelskspråkiga Wiktionary. Det tar bort tankar om eventuell värdeladdning ur sorteringsordningen och ger dessutom en standard som alltid är enkel att följa. –Tommy Kronkvist (diskussion), 16 september 2019 kl. 10.40 (CEST).

Jag tycker att det är konstigt när olika skriftsystem blandas. Det är min subjektiva åsikt. Jag har ingen aning om var bokstäver från andra skriftsystem hamnar om det ska sorteras in i det latinska skriftsystemet, eller tvärt om. För mig handlar den nuvarande sorteringsordningen alltså om en tolkning av principen om minsta möjliga förvåning. Att de språk som i någon mening har störst relevans för besökare av svenskspråkiga Wiktionary hamnar längre upp (eller tillräckligt långt upp) i listan. Jag är medveten om att man kan tolka principen från fler synvinklar.

Nuvarande sorteringsordning är beslutad för ett tiotal år sedan och var då alltså ett medvetet val. Språk med latinska namn först - diakriter förbisedda, sedan språk i UTF8-ordning. Det finns några olika varianter som används på olika Wikimediaorojekt. Varje projekt väljer själv. Jag tror att ordningen numera lagras som ett systemmeddelande på MediaWiki:Interwiki config-sorting order. Vi kan ta ett nytt beslut här om vi vill ändra det gamla. Den vanligaste inställningen verkar vara MediaWiki:Interwiki config-sorting order men det finns fler, se meta:Interwiki sorting order och titta runt lite på diskussionssidorna till de olika sorteringsordningarna. ~ Dodde (diskussion) 21 september 2019 kl. 16.24 (CEST)

Hej, finns det en möjlighet att jag kan ta bort eller korrigera ett nytt uppslag strax efter jag tryckade knappen "Publicera ändringar"? Jag har problemet att först efter jag sparade ett nytt uppslag märkar att jag gjorde en felstavning. --Pametzma (diskussion) 22 september 2019 kl. 07.41 (CEST)

@Pametzma Jag tror inte det. Lägg till en raderas-mall istället och skriv som motivering att det var en felstavning. ~ Dodde (diskussion) 23 september 2019 kl. 03.34 (CEST)

De senaste dagarna har det flera gånger hänt mig att när jag ska skapa en ny sida, efter att ha klickat en röd länk, så dyker formuläret med språk, ordklass och betydelse aldrig upp (Wiktionary har inte ett uppslag med exakt denna titel...). Har scriptet ändrat sig nyligen? Eller beror det på hur Javascript körs i (kanske en ny version) av min webbläsare (Firefox 70 på Ubuntu Linux)? Ironiskt nog dyker formuläret nästan alltid (men kanske inte alltid) upp när jag har klickat en grön länk (varvid formuläret ju inte behövs). --LA2 (diskussion) 26 oktober 2019 kl. 09.48 (CEST)

Jag får också fel i FireFox. I Chrome växlar det. Det verkar vara nåt problem med raden $('#nu_definition_input').append($('<input>', { id: 'nu_definition', autocomplete: 'off', tabindex: 1 })); i filen MediaWiki:Gadget-nytt_uppslag.js, att autocomplete anropas utan att först initieras, vad det nu innebär. @Skalman, kan du kika på detta? ~ Dodde (diskussion) 27 oktober 2019 kl. 02.30 (CET)

Har något i detta script ändrats nyligen? Historiken visar inget sedan 2017. Eller är det webbläsarna som ändrat beteende? Det brukade fungera perfekt för en vecka sedan. --LA2 (diskussion) 27 oktober 2019 kl. 09.41 (CET)

Jag har testat i de senaste versionerna av de vanligaste webbläsarna för mac OS. I Safari visas formuläret oftast inte, men det händer någon enstaka gång (alltså lite som i Chrome för Dodde). I Firefox, Chrome, Opera och Brave visas inte formuläret överhuvudtaget. Datorn kör den senaste (skarpa) versionen Apples operativsystem, alltså mac OS Catalina 10.15 build 19A602 (släppt 21 oktober). Notera att man i de nyare versionerna av mac OS inte länge kan köra 32-bitarsprogram. Följaktligen har jag uteslutande testat 64-bitarsversioner av webbläsarna. –Tommy Kronkvist (diskussion), 28 oktober 2019 kl. 13.37 (CET).

Gissningsvis beror det på en ändring i hur Mediawiki laddar skriptet. Jag undersöker saken inom ett par dagar. Skalman (diskussion) 28 oktober 2019 kl. 22.11 (CET)

@Skalman: Det är måhända inte ett dugg relaterat till vårt problem enligt ovan, men på Phabricator har man de senaste dagarna talat en hel del om PHP och dess FastCGI Process Manager (PHP-FPM, som ju bland annat används för kommunikation mellan servermjukvara och databaser) samt Parsoid (en JavaScript-baserad syntaxanalyserare i Node.js som används av VisualEdit). Jag vet inte om detta (ännu) har någon direkt bärighet mot den version av MediaWiki som körs skarpt på servrarna, men kanske? Tydligen så både testar de och startar om diverse olika grejer just nu i dagarna... Se till exempel T236275 på Phabricator och det liknande problemet 546758 på Gerrit. –Tommy Kronkvist (diskussion), 29 oktober 2019 kl. 17.31 (CET).

Problemet löst. Dodde hade rätt ang. vilken rad som krånglade. Det finns ett JQuery-plugin för autocomplete. Det gör att autocomplete inte längre kan användas som property i andra parametern i $()-funktionen. Lösningen blev att explicit sätta aktuella properties.

Jag håller fast vid min hypotes om att det beror på en ändring i hur skript laddas. Gissningsvis laddades vårt skript före autocomplete-pluginet förut, men inte längre. Skalman (diskussion) 30 oktober 2019 kl. 22.57 (CET)

Tack! --LA2 (diskussion) 30 oktober 2019 kl. 22.59 (CET)

Tack! ╰ Svenji 31 oktober 2019 kl. 01.24 (CET)

Hej! Jag skulle önska att vi lade till en valbar parameter i citat-mallen för översättare, när det rör sig om verk som uppenbart inte är angivna på originalspråk. Det känns fel att säga att William Shakespeare använde ett visst ord på svenska, om än det är i hans verk den översättningen finns. Om vi skulle ha en parameter som inte är obligatorisk, t.ex. |översättare=, så skulle man kunna ange detta på ett snyggt sätt. Vad tycker ni? ╰ Svenji 31 oktober 2019 kl. 01.27 (CET) 

Till exempel här. ╰ Svenji 31 oktober 2019 kl. 01.28 (CET) 

Låter som ett bra förslag tycker jag. Kanske något i stil med ='' ({{{publ}}}), {{{förf}}} {{{övers}}}:}} där {{{övers}}} automatiskt lägger till texten (översatt av ) inklusive parentesen (men förstås automatiskt byter ut mot angivet författarnamn). –Tommy Kronkvist (diskussion), 2 november 2019 kl. 13.21 (CET).

Låter rimligt att inkludera en parameter för översättare. Ändrar du, @Svenji eller @Tommy Kronkvist? ~ Dodde (diskussion) 5 november 2019 kl. 14.49 (CET)

Jag är tyvärr inte jättefiffig på att peta i mallar, även om jag lyckats några gånger tidigare. Kanske någon annan vill vara snäll och stoppa in detta? ╰ Svenji 7 november 2019 kl. 21.38 (CET)

Jag tror vi får be @Skalman kika på detta då :) ~ Dodde (diskussion) 14 november 2019 kl. 01.26 (CET)

Efter väldigt lång tid så har jag äntligen fixat det. (ping @Dodde, @Tommy Kronkvist, @Svenji) Skalman (diskussion) 3 december 2019 kl. 23.36 (CET)

Tack för det! Ser bra ut. Jag hade heeelt glömt bort detta... Tommy Kronkvist (diskussion), 3 december 2019 kl. 23.45 (CET).

Tack @Skalman! Den som väntar på något gott väntar aldrig och alltid för längre. VI har ju klarat oss utan parametern ganska många år, så kanske inte var så farligt ord et tog någon månad att genomföra. Svenji (diskussion) 3 december 2019 kl. 23.56 (CET) 

• Hur kan jag redigera kolumnen till vänster (Huvudsida, Appendix, Kategorier, Slumpsida, Stöd Wiktionary, ...), eller vem annan kan redigera den (enbart byråkrater, enbart Phabricator-administratörer, ...)?
• Hur kan en redigera förvalda namnrymnder för sökning dvs "ns0=1" och hur gör en det?
• Hur kan en styra vilka sidor som indexeras av Google?

Taylor 49 (diskussion) 7 november 2019 kl. 19.02 (CET)

@Taylor 49:

1. I MediaWiki:Sidebar refererar raden t.ex. raden "** appendix-url|appendix" till MediaWiki:Appendix-url och MediaWiki:Appendix och tooltop skapas av MediaWiki:Tooltip-n-appendix. Jag tror att redigering av sidor i MediaWiki-namnrymden är begränsat till administratörer.
2. För mig finns en kryssruta "Kom ihåg val för framtida sökningar" om jag väljer att expandera rutan "Sök på". Finns en sådan kryssruta för dig också?
3. En googling gav denna träff, som jag tror är relevant för det du vill veta: w:en:WP:Controlling_search_engine_indexing.

~ Dodde (diskussion) 11 november 2019 kl. 02.14 (CET)

@Dodde Vad bra, tack. Jag har under tiden forskat på andra håll. w:en:WP:Controlling_search_engine_indexing är mycket informativ. Kan jag vara säker på att en sida indexeras ifall den varken innehåller "<meta name="robots" content="noindex,nofollow"/>" eller finns på skamlistan "en.wikipedia.org/robots.txt" ? Taylor 49 (diskussion) 11 november 2019 kl. 11.42 (CET)

@Taylor 49, med kriterierna du anger så får sökmotorerna möjlighet att indexera innehållet, men det finns ingen garanti att Google faktiskt indexerar dom. Google har också en massa egna kriterier (som man inte får veta!), men jag tror att Wiktionary är en tillräckligt stor sajt för att i princip allt som får indexeras kommer att indexeras. Dom här reglerna berättar dessutom bara vilka sidor Google får besöka, så Google kan ha med sidor i sökresultatet som inte finns i dessa listor, men i så fall utan innehåll (sannolikheten är mindre för att dessa sidor dyker upp i sökresultatet).

Att förstå sökmotorer är inte lätt, så det kan hända att något av det jag skrivit inte stämmer. Skalman (diskussion) 4 december 2019 kl. 09.07 (CET)

@Dodde, @Taylor 49, @Skalman: Precis som de flesta andra wikier har även svenska Wiktionary en lokal "robots"-lista. Google och andra sökspindlar förväntar sig att finna den i sajtens rotkatalog, så våran finns här: sv.wiktionary.org/robots.txt (till skillnad från de flesta andra av våra sidor som finns i underkatalogen "wiki": sv.wiktionary.org/wiki/). Hur och vem som kan redigera den vet jag inte, men jag misstänker att man måste upp på steward-nivå. Jag är byråkrat på Wikispecies och där har jag inte hittat någon metod för att redigera robots-filen. Sen ska rent allmänt sägas att Robots Exclusion Standard bara är en rekommendation, och i praktiken är det upp till respektive sökmotor att själva besluta vad de (inte) vill indexera. Huruvida de följer robots.txt och "nofollow" etc. är mer en form av gentlemen’s agreement än något annat, men åtminstone de stora sökmotorerna brukar vara rättrådiga i sammanhanget. –Tommy Kronkvist (diskussion), 4 december 2019 kl. 14.43 (CET).

Dessutom så gäller robots.txt "site-wide" och informationen där överflyglar alla meta-taggar på de enskilda sidorna. Om en sida anger "<meta name="robots" content="index,follow"/>" så kommer den alltså i alla fall inte indexeras om den dessutom står listad som "Disallow" i robots.txt. –Tommy Kronkvist (diskussion), 4 december 2019 kl. 14.58 (CET).

Tack för värdeful information. Att "redigera kolumnen till vänster" har löst sig. Att "redigera förvalda namnrymnder" har löst sig. Varje wiki har visserligen en lokal "robots"-lista men de är alla identiska! Det här problemet har inte löst sig, kan det dröja flera månader tills Google faktiskt tar upp en sida som får indexeras? Taylor 49 (diskussion) 4 december 2019 kl. 18.52 (CET)

@Taylor 49, ja Google kan dröja flera månader. Om det finns många länkar till en sida, så ökar chansen att den indexeras snabbt.

robots.txt kan nuförtiden redigeras lokalt per wiki: MediaWiki:Robots.txt. Men detta är något vi bör använda mkt sparsamt - troligen bör det inte användas alls.

Problemet som jag försökte påtala står bättre beskrivet på mw:Manual:Robots.txt#Spidering vs. indexing. Skalman (diskussion) 5 december 2019 kl. 00.29 (CET)

Problemet har löst sig. Google har äntligen funnit de gömda sidorna (på EO wiktionary) efter några månaders väntetid. Tack för hjälpen. Taylor 49 (diskussion) 31 december 2019 kl. 11.14 (CET)

Hej! Går det att få till en läsning av artikeln som jag skapade för מודעת? Jag skulle vilja att bl.a. mallarna {{böjning}} och {{härledning}} kunde få samma funktionalitet som {{länk}} har. Detta bör också implementeras för (bl.a. men åtminstone) arabiska. Jag skulle också önska att {{länk}} kunde få en parameter för transkription (tr=). Svenji (diskussion) 19 mars 2020 kl. 14.40 (CET)

@Svenji Se Wiktionary:Bybrunnen/Arkiv25#Var anges orden med diakriter?.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 2 april 2020 kl. 06.21 (CEST)

Att tillägga den tidigare diskussionen vill jag poängtera att behovet finns av utveckling av mallar för att tillämpas bättre för t.ex. hebreiska och arabiska. Bägge använder skrivsystem som är konsonantskrifter (abjad). De använder punkter under eller i bokstäverna (i hebreiskan kallade niqqud), och används då uttalet är tvetydigt, eller under inlärning av läskunskaper för barn och vuxna. I praktiken skrivs niqqud sällan ut, då läsaren oftast förstår av sammanhanget och sin läserfarenhet hur ordet ska uttalas. På hebreiska Wiktionary använder man niqqud i rubrikraden, men inte i grammatikmallar eller artiklarna i övrigt. Uppslag för böjningsord ges också niqqud i rubrikraden, för att visa uttal.

Detta gör att både arabiska och hebreiska kan ha ett uppslag för flera skilda ord (typ som åsa, asa, äsa, äsä...). Därför anser jag att det är viktigt att man i den mån det går anger ordet med niqqud i fetstilsraden. Dock aldrig som uppslagssökning. Detta är något som {{ö}} klarar galant. Kag önskar att även {{härledning}}, {{sammansättningar}}, {{besläktade ord}}, {{synonymer}}, {{antonymer}}, {{jämför}} {{seäven}}, med flera kunde stödja länkning av ord skrivna med niqqud så att de kon till ett uppslag utan niqqud. Svenji (diskussion) 2 april 2020 kl. 21.14 (CEST)

@Svenji, den magiska funktionaliteten finns i {{länk}}. Men {{länk}} kräver en språkparameter för att fungera. Och språkparametrar saknas i nuläget i nämnda mallar ({{synonymer}} m.fl.). Se även Wiktionary:Bybrunnen/Arkiv27#Kan vi inte skippa klamrarna i anrop av länkmallar som inte ledde nånstans eftersom det har funnits motstånd för en språkparameter Wiktionary:Bybrunnen/Arkiv25#Ange språkkod för {synonymer} mfl. Teoretiskt kan man lösa det med JavaScript, och jag och Skalman började titta på en sådan implementation i samband med denna diskussionen 2017, men den kom av sig och jag tror att det är ganska långt tills dess att det initiativet kommer återupptas. Så tills dess att det finns en bred acceptans för ett tillägg av 1= som obligatorisk språkparameter för dessa mallar, så är vi nog i ett dödläge. ~ Dodde (diskussion) 11 april 2020 kl. 01.25 (CEST)

Dessa skulle behöva substas:

• Special:Search/Användardiskussion: hastemplate:klotter
• Special:Search/Användardiskussion: hastemplate:klotter-inloggad
• Special:Search/Användardiskussion: hastemplate:välkommen
• Special:Search/Användardiskussion: hastemplate:"logga in".
  - Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 1 april 2020 kl. 05.52 (CEST)

Ja... Lägger till det under projekt Wiktionary:Projekt/Struktur på uppslag ~ Dodde (diskussion) 11 april 2020 kl. 00.48 (CEST)

Vid "Lägg till översättningar" borde

• Arameiska (arc), dalmatiska (dlm), fornspanska (osp), hausa (ha), koptiska (cop), korsiska (co), kurdiska (ku), kymriska (cy), ladino (lad), pashto (ps), polabiska (pox), sardiska (sc), skotsk gäliska (gd), vallonska (wa) och venetiska (vec) ha valen m/f.
• Vidare behöver forndanska (gmq-fda), fornhögtyska (goh), fornnordiska (non), fornsvenska (gmq-fsv) och kasjubiska (csb) lågtyska (nds) medelhögtyska (gmh) medellågtyska (gml) valen m/f/n. Svenji (diskussion) 2 april 2020 kl. 22.35 (CEST)

@Svenji Då endast gränssnittsadministratörer kan göra detta, och vår enda @Skalman inte tycks vara aktiv tycks detta bli lite knepigt. Jag kollade runt lite på meta dock och det står att man kan begära admin/interace admin help på meta:Steward requests/Miscellaneous dock, så om inte @Skalman svarar kan vi nog fråga där.Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 9 april 2020 kl. 11.07 (CEST)

Skalman är nog aktiv, men en ping är nog nödvändig för att han ska hitta hit :) Det är kanske inte superbråttom, så vi kan väl avvakta några dagar... ~ Dodde (diskussion) 11 april 2020 kl. 00.43 (CEST)

@Svenji, ska något av dessa språk också ha mf eller pl? Jag har hittills bara lagt till det du bett om.

@Jonteemil, @Dodde, visst är det så att jag inte är så aktiv. Men med en ping kommer jag hit inom några dagar. Skalman (diskussion) 11 april 2020 kl. 10.28 (CEST)

Okej, vad bra - Jonteemil (diskussion) Ps. använd gärna {{@}} vid svar 11 april 2020 kl. 12.49 (CEST)

Finns här någon som vet vilken bot/modul som lägger till uppdaterad data i MediaWiki:Recentchangestext? Alltså summorna som anges där över vilka sidor som bör raderas, verifieras eller har fel språkkod, antal moduler med testfel etc., och som sedan listas automatiskt under "Andra granskningsverktyg" på Special:Senaste ändringar? Dessutom, hur ofta uppdaterar botten dessa data? Dagligen, två gånger dagligen, oftare eller kanske mer sällan? Det tycks i varje fall inte ske omedelbart.

Det vore intressant att veta, eftersom man då ibland dessutom kan aktualisera dessa cachar manuellt, vilket underlättar om man exempelvis arbetar med översyn av Wiktionarys kategoriträd. Jag har letat i till exempel ListeriaBots status på WMF Labs, just för att man där också kan uppdatera liknande data manuellt. Den botten används av rätt många wikier för diverse liknande uppgifter, men tydligen inte av just svenska Wiktionary. –Tommy Kronkvist (diskussion), 19 april 2020 kl. 20.36 (CEST).

@Tommy Kronkvist, det sker automatiskt. Inga botar är inblandade. Siffrorna kommer från en funktion som efterfrågar hur många sidor som finns i vissa kategorier såsom framgår av wikitexten i MediaWiki:Recentchangestext. Vilka sidor som finns i en viss kategori lagras i en cache. När sidan ändras uppdateras informationen om kategoritillhörighet för aktuell sida. Om en mall eller modul ändras som indirekt påverkar sidor att placeras i eller tas bort från kategorin sker detta inte direkt utan det sker automatiskt nästa gång cachen uppdateras. Jag tror att det är ungefär en gång om dagen. Man kan uppdatera kategoriseringen av en särskild sida manuellt genom att köra ?action=purge på sidan. Jag tror inte man kan påskynda uppdateringen av cachen _för samtliga sidor_ manuellt.

Jag är inte hundra på detaljerna, så ta detta med en nypa salt. Skalman har nog bättre koll så pinga honom om detta svar inte är tillräckligt. :) ~ Dodde (diskussion) 19 april 2020 kl. 21.06 (CEST)

Tack för svar, @Dodde. Det där borde jag ju kunnat lista ut själv om jag bara tittat efter lite mer noggrant i "Recentchanges"-koden. Den ser dock lite olika ut i de olika systerprojekten och jag är mer van vid de motsvarande MW-sidorna på Wikispecies och svenska Wikivoyage, helt enkelt eftersom jag är mer verksam där.

Parametern ?action=purge är jag förstås väl bekant med och använder rätt ofta, jag lägger till exempel ibland in den som länk för mina egna sandlåde-sidor och liknande eftersom det underlättar om man använder sandlådan för att skapa/eller kontrollera lite mer komplicerad kod. Det fungerar förstås bara för enskilda sidor, precis som du säger, men jag är så gott som säker på att jag stött på någon sida i Wikimediagemenskapen eller WMF Labs där man (med eller utan "purge") kunnat uppdatera mellanlager för flera sidor och/eller funktioner samtidigt. Jag har dock glömt vilken sida och att vada runt och söka på måfå bland nästan 700 verktyg i till exempel Wikimedia Toolforge är ett jobb för en annan dag... Dessutom kanske inte modulen/roboten/verktyget finns kvar längre, eller har förändrad funktionalitet.

Den specifika anledningen som gjorde att jag blev uppmärksammad på behovet här på Wiktionary är posten "Fel språkkod" som nu listar ett (1) uppslag MediaWiki:Recentchangestext. Ett klick på den länken leder till Kategori:Okänt språk/Alla uppslag med uppslaget säveldäi ("tonsättare") som enda medlem. Haken är att språket inte alls är "okänt" (Wiktionary-språkkod "xx") utan livvi (också kallat olonetsiska eller onega-karelska, ISO-kod "olo"), och på uppslaget används mycket riktigt substantivmallen {{subst|olo}}. Trots detta listas uppslaget som sagt i Kategori:Okänt språk/Alla uppslag snarare än i Kategori:Livvi/Substantiv som man skulle önska. Jag förmodar att det beror på att språkkoden "olo" inte är registrerad här på Wiktionary, och jag har inte lyckats lista ut var man gör det (dessutom har jag förmodligen inte tillräckliga användarrättigheter för att utföra ändringen). Jag är mer van vid översättningar och språkhantering på Wikispecies, men det projektet skiljer sig stort från Wiktionary eftersom det så långt möjligt försöker vara språkneutralt (det finns bara en version av Wikispecies) medan varje enskild Wiktionary är primärt och uttalat enspråkig (det finns 174 olika Wiktionary-versioner, på olika språk). Så både behov och förutsättningar är väldigt olika för de båda systerprojekten.

Med det sagt så har jag ändå skapat en del av de tidigare nämnda kategorierna här på Wiktionary, för att om inte annat åtminstone slippa rödlänkade kategorier på berörda uppslag. I det arbetet så har jag använt befintliga kategorier som förlagor, till exempel Kategori:Tyska, Kategori:Tyska/Alla uppslag och Kategori:Tyska/Substantiv. Avslutningsvis håller jag med om att @Skalman brukar ha riktigt bra koll på allt sånt här så jag passar på att pinga honom i den händelse han vill bidra med någon sorts sammanfattning om hur saker och ting egentligen ligger till... :-)

–Tommy Kronkvist (diskussion), 21 april 2020 kl. 10.02 (CEST).

@Tommy Kronkvist, jag har uppdaterat språkdata. Det är den datan som konverterar språkkod till språknamn i dom flesta fall. Det här är för övrigt precis anledningen till att vi la in den här notisen i SÄ - nu upptäcktes ett fel som vi lätt kunde åtgärda.

Och tack för att du skapar kategorierna manuellt. Tyvärr har jag inte kört boten på väldigt länge nu.

Jag tror att det ni båda säger stämmer, så jag har inget mer att tillägga.

@Dodde, om vi kunde få tag i språknamnet i en mall, så skulle vi kunna göra den här kontrollen direkt i {{språk}}, så att man direkt ser problemet på WT:SPRÅK. Skalman (diskussion) 21 april 2020 kl. 20.53 (CEST)

@Tommy Kronkvist, under den gedigna listan över språkkoder i Wiktionary:Stilguide/Språknamn finns instruktioner på hur man lägger till ett nytt språk, i avsnittet "Lägg till nytt språk", punkt 3, står det att man behöver lägga till språkkoden i Modul:lang/data. Men det gäller kanske att man vet att den här steg-för-steg-listan finns :) ~ Dodde (diskussion) 21 april 2020 kl. 22.22 (CEST)

@Dodde, @Skalman: Tack båda! Jag kompletterar med nya kategorier under slutet av veckan. Mvh, Tommy Kronkvist (diskussion), 22 april 2020 kl. 10.33 (CEST).

Skall föregås av ett mellanslag enligt https://sv.wikipedia.orghttps://dictious.com/sv/Uteslutningstecken Hur man rättar det är dock inget jag begriper mig på men ... Någon mer kunnig kanske orkar bemöda sig? –föregående osignerade kommentar är från 213.64.113.107 (diskussion • bidrag)

Jag kan lägga till det. Men min språkkänsla vill inte ha något mellanslag där. Är det fler som har synpunkter? Vad säger Svenska skrivregler? Skalman (diskussion) 10 december 2020 kl. 20.42 (CET)

Svenska skrivregler säger att mellanrum skall användas före ellipsen om den avbryter en mening eller markerar tveksamhet. Om den avbryter ett ord skall mellanrum inte användas:

Vem är det som ...

Vilken jubelidi...

Dock bör det påpekas att det aktuella bruket är ett datortekniskt bruk som i det här fallet anger att länken inte direkt lägger till översättningar, utan att användaren behöver göra ytterligare inmatning efter att ha klickat på länken innan några översättningar läggs till (jfr "Spara som..." och "Skriv ut..."). Det är ett bruk som inte nämns explicit av Svenska skrivregler och där det finns en mycket lång tradition i åtminstone Win32-miljö att utelämna mellanrummet före ellipsen. Samma sak gäller vid pågående aktivitet ("Söker..." eller "Laddar ned...").

Detta gör att jag i den aktuella frågan föredrar att utelämna mellanrummet före ellipsen. --Andreas Rejbrand (diskussion) 10 december 2020 kl. 21.17 (CET)

@Andreas Rejbrand, tack för klargörandet. Skalman (diskussion) 10 december 2020 kl. 21.45 (CET)

Skulle någon teknikkunnig kunna skapa en mall för exempelmeningar? Den kan se ut som Mall:ux och Mall:uxi på engelska Wiktionary. Möjligtvis kan man modifiera sagda mallar lite grann bara och så är jobbet gjort. Att ha exempelmeningar i mallen istället för direkt på sidan som wiki-text är att det skapas en kategori vilket gör det lättare att ha överblick över vilka uppslag som har resp. saknar exempelmeningar. Dessutom så kommer mallen att automatiskt skicka användaren till uppslag på rätt språk om man skulle vilja länka inifrån exempelmeningen. a bad guy inifrån en mall som exemplifierar ordet guy skulle skicka läsaren direkt till det engelska uppslaget bad ("dålig") istället för det svenska bad (dåtidsform av be). Observera att man inte behöver göra någon storslagen omformatering av uppslagen från enkel wiki-text till malltext, utan det här kan vara ett alternativ för den som vill. Allahverdi Verdizade (diskussion) 10 december 2020 kl. 15.22 (CET)

Vi har som regel att inte länka ord i exempelmeningar. Taylor 49 (diskussion) 10 december 2020 kl. 15.36 (CET)

Intressant, det jag hittar är "Eftersom exempelmeningen inte direkt berör betydelsen av ordet känns det renare om ord i exempelmeningarna inte länkas om det inte absolut krävs för förståelsen av definitionen." Naturligtvis är det så att exempelmeningar direkt berör betydelsen, då de är just särskilt konstruerade för att belysa densamma. Och det där med att "känns renare" är också märkligt, känns renare för vem då? Funktionalitet är som regel bra, inte dåligt. Men det är en diskussion för senare, nu handlar förfrågan om mallen för användarexempel. Allahverdi Verdizade (diskussion) 10 december 2020 kl. 15.45 (CET)

Som Taylor 49 skrev, är det bra om det finns ett sätt att göra något på. Annars blir det onödigt svårt för nya bidragsgivare och bot- och skriptmakare att förstå sidstrukturen.

Jag motsätter mig således införandet av en mall för exempelmeningar, om inte målet är att på sikt (kanske inom ett år) uppdatera alla existerande sidor. Du kommer ändå inte få någon överblick om inte alla exempelmeningar använder den nya mallen. Skalman (diskussion) 10 december 2020 kl. 20.12 (CET)

>bra om det finns ett sätt att göra något på.

om det inte gäller format (vilket det inte gör här) så är det direkt dåligt om det bara finns ett sätt att göra något på.

>Annars blir det onödigt svårt för nya bidragsgivare och bot- och skriptmakare att förstå sidstrukturen.

Det blir inte ett dugg svårare än idag.

>Du kommer ändå inte få någon överblick om inte alla exempelmeningar använder den nya mallen.

Jag kommer att få all överblick jag behöver över det segment som jag är intresserad av (och som ingen annan än mig förmodligen kommer att redigera).

>Jag motsätter mig således införandet

"Införande" är ett missvisande ord, då ingen har föreslagit att införa något - bara skriva en liten mall.

Min förfrågan kvarstår därmed - någon som har tekniskt kunnande och lust får gärna skriva/anpassa mallen. Allahverdi Verdizade (diskussion) 10 december 2020 kl. 22.07 (CET)

Det är viktigt att wikitexten följer samma struktur i alla uppslag. "Det blir inte ett dugg svårare" Jo, för då måste man ta hänsyn till att vissa uppslag kan använda en viss mall till exempelmeningar.

Det kanske går att lösa ditt problem på något annat sätt. Skulle du kunna beskriva exakt vad det är du vill kunna söka efter/se? Skalman (diskussion) 11 december 2020 kl. 07.42 (CET)

Ifall det finns två någorlunda giltiga lösningar för strukturen av uppslag (med mall för exempelmeningar, och utan mall för exempelmeningar), då väljer jag den enklare lösningen (som inte kräver 2 nya mallar och åtminstone en modul), förutom den mer komplicerade lösningen erbjuder övertygande fördelar, och det gör den i nuläget inte. Taylor 49 (diskussion) 11 december 2020 kl. 10.06 (CET)

@Skalman På ytan följer den ju exakt samma struktur. Jag tror knappast att nya användare kommer gå under av kognitiv dissonans av att se att det finns en mallösning (i den mån de kommer att komma i kontakt med den överhuvudtaget, för jag är som sagt inte intresserad av att konvertera svenska uppslag eller förse dem med användningsexempel).

Vad jag exakt vill göra är helt enkelt att söka igenom kategorier för uppslag med exempelmeningar. Det kommer även att ge mig möjlighet att överblicka uppslag utan axempelmeningar. Uxi möjliggör också en extra parameter för ordagrann översättning., ex {{uxi|az|qanımı qaraltdılar|de gjorde mig ledsen|lit=...gjorde mitt blod svart}}, vilket är jättebra. Allahverdi Verdizade (diskussion) 11 december 2020 kl. 13.47 (CET)

@Allahverdi Verdizade, här får du ett exempel på vad vi kan åstadkomma tack vare att (nästan) alla våra uppslag har välstrukturerad och konsekvent wikitext:

• Sökning efter alla sidor i Kategori:Svenska/Adjektiv som har exempelmening
• Sökning efter alla sidor i Kategori:Svenska/Adjektiv som saknar exempelmening

Hoppas att det där räcker för dina behov. Jag kommer fortsätta vara en mkt stark motståndare till alla lösningar där uppslagens wikitext blir inkonsekvent. Skalman (diskussion) 11 december 2020 kl. 18.36 (CET)

Jag håller med Skalman i den här frågan. --Andreas Rejbrand (diskussion) 11 december 2020 kl. 18.57 (CET)

> exempel på vad vi kan åstadkomma tack vare

Mycket intressant, tack. Taylor 49 (diskussion) 12 december 2020 kl. 11.43 (CET)

@Skalman Dessvärre inte. Den som är tillräckligt tekniskt kunnig för att använda reguljära uttryck kan inte på allvar förväntas bli minsta lilla störd av att uppslag på andra språk än svenska har en extra mall för att strukturera användningsexemplen bättre. Den passive användaren (=läsaren) å andra sidan kommer nästan garanterat inte att använda sig av reguljära uttryck för att göra källkodssökningar, och därmed gå miste om den mycket användbara kategoriseringen.

Förutom den extra parametern för ordagrann översättning i {{ux}} som redan nämnts finns ju den enorma potentialen i att även senare importera automatiska translittereringsmallar från en.wikt, så att användningsexempel i uppslag för ord på språk med andra alfabet än det västerländska får en extra rad med standardiserad och automatiserad translitterering. Allahverdi Verdizade (diskussion) 12 december 2020 kl. 11.51 (CET)

@Allahverdi Verdizade, jag är inte principiellt mot en mall - som du poängterar finns fördelar. Men jag är principiellt mot att ha två system för samma sak.

Du skrev att du vill "söka igenom kategorier för uppslag med exempelmeningar", och jag gav dig ett enkelt sätt att åstadkomma det. Förvisso kommer få läsare använda reguljära uttryck, men få läsare kommer använda dom kategorier du tänker dig också.

Kan du precisera varför sökningen inte räcker? Skalman (diskussion) 12 december 2020 kl. 23.12 (CET)

Jag har den senaste tiden manuellt skapat några tusen böjningsformer genom att klicka på gröna länkar. Det här systemet fungerar otroligt bra, tycker jag, om man bortser från en liten detalj.

När jag t.ex. skall skapa böjningsformer för ett substantiv med åtta olika former så sätter jag fokus på den första böjningsformen i tabellen (rad 1, kol 2: bestämd form singular nominativ). Sedan trycker jag Ctrl+Enter, Tab sju gånger (minus avslutande Tab). Efter det trycker jag Ctrl+Tab, Shift+Alt+S sju gånger med en paus på 0,5 sekunder mellan varje Ctrl+Tab och Shift+Alt+S, så att texten hinner fyllas i.

Det som jag tycker är irriterande är pausen på 0,5 sekunder. Utan den skulle det gå mycket fortare. Dessutom räcker inte alltid 0,5 sekunder, och ibland är jag för snabb, med följden att jag skickar in en tom sida för publicering. Mjukvaran ger mig då en varning om tom sida, så jag får gå bakåt (Alt+Vänsterpil), vänta mina 0,5 sekunder, och sedan trycka Shift+Alt+S.

Vore det möjligt att justera systemet så att Shift+Alt+S automatiskt "flushar" fram texten i rutan? --Andreas Rejbrand (diskussion) 29 december 2020 kl. 13.07 (CET)

Tillägg: När jag (tror mig ha) skapat alla böjningsuppslag trycker jag Ctrl+W sju gånger följt av Ctrl+R. Då ser jag om länkarna blivit blå i böjningstabellen, och ofta är det först då jag upptäcker en eventuell misslyckad sida. --Andreas Rejbrand (diskussion) 29 december 2020 kl. 14.00 (CET)

@Andreas Rejbrand Jag tror att det beror på något inbyggt i webbläsaren att inte hantera inaktiverade tabbar som aktiverade tabbar. Jag har googlat men inte hittat någon lösning på hur man kan ändra hur detta funkar i de senaste versionerna av webbläsarna. Vilken webbläsare använder du? När jag jämförde FireFox och Chrome så var Chrome avsevärt mycket snabbare, så snabb att jag faktiskt inte ens märkte fördröjningen till en början. Måste vara mindre än 0,1 sekunder. Jag antar att datorns snabbhet och internetuppkopplingen kan påverka också. Jag tror att man skulle kunna snabba upp inladdningen genom att ta bort visa element från sidan med personligt javascript, t.ex. menyraden ovanför redigeringsrutan. Man kan också minska antal tabb-tangenttryckningar om man aktiverar "Avaktivera hjälpen för att skapa nya uppslag" under "Finesser" under inställningar. ~ Dodde (diskussion) 7 januari 2021 kl. 02.26 (CET)

Jag kör Firefox. Är det inte ett JavaScript som populerar textrutan? I sådana fall antar jag att det körs i en händelsehanterare (jag kan inte DOM och JavaScript särskilt bra, men kanske "document.onLoad = LoadDefaultText" eller något sådant, där "LoadDefaultText" är själva funktionen). Skulle man då inte bara kunna lägga till en händelsehanterare "form.onSubmit" som lägger till texten när formuläret skickas ifall "onLoad" inte har körts ännu? En boolesk flagga eller en kontroll av textrutans antal tecken (noll eller flera) kan säkerställa så att funktionen inte körs två gånger. --Andreas Rejbrand (diskussion) 7 januari 2021 kl. 23.01 (CET)

Man borde nog inkludera en kontroll att sidan man tänker skapa inte är tom. Det hjälper isåfall mot att du av misstag ska publicera tomma sidor, men det hjälper inte mot 0,5-sekundersfördröjningen. Om användning av Chrome löser problemet, är att byta webbläsare ändå ingenting du skulle överväga? ~ Dodde (diskussion) 7 januari 2021 kl. 23.31 (CET)

Nej, 0.5 sekunder är inte så mycket att jag tänker byta webbläsare. Wikimediamjukvaran ger en varning om tom sida, så man kan inte skapa en sådan av misstag. När jag ser att jag fått en sådan varning backar jag i webbläsaren, väntar mina 0.5 sekunder och sparar igen. Förstå då skapas artikeln. Vore det möjligt att lägga till en "form.onSubmit = LoadDefaultText" utöver "document.onLoad = LoadDefaultText" i min nästan säkert inte korrekta pseudokod? --Andreas Rejbrand (diskussion) 8 januari 2021 kl. 00.14 (CET)

Jag tror absolut att det är möjligt, men jag vet inte på rak arm hur. @Skalman vad säger du? ~ Dodde (diskussion) 8 januari 2021 kl. 00.50 (CET)

@Andreas Rejbrand, @Dodde, om vi vill göra det lättare att skapa nya böjningsuppslag, så är nog den bättre lösningen att skapa uppslaget direkt vid klick, utan att öppna en ny sida och skicka in formuläret. Jag implementerade inte det förut, eftersom jag tänkte att det skulle bli för lätt att skapa böjningsuppslag (med risk för att folk glömmer bort att städa bort felaktigt skapade sidor).

Hur tycker ni att vi bör göra? Skapa ett skript som man får lägga på sin common.js, eller skapa en finess? Om det blir en finess, vilka ska då kunna aktivera den? (Bör emm inte vara aktiverad som standard). Skalman (diskussion) 9 januari 2021 kl. 18.36 (CET)

Låter vettigt. En möjligt nackdel med det nya förslaget är att det gamla förfarandet ger mig en liten extra chans att kontrollera dels böjningsformens korrekthet ("ostar", inte "oster"), dels att sidan blir korrekt skapad. Men jag tror att fördelarna överväger. Jag kan dubbelkolla en extra gång i tabellen på huvuduppslaget och sedan lita på att Skalmans JavaScript är buggfritt! :)

Jag har ingen preferens angående hur det implementeras. Det är bättre att Skalman som är expert på JS får välja det som Skalman tycker känns rimligast. Jag håller med om att det är bra ifall funktionaliteten inte är tillgänglig som standard. --Andreas Rejbrand (diskussion) 9 januari 2021 kl. 22.31 (CET)