Moduldiskussion:grammar-table

Prioritering getRow()

Här följer mina önskemål om hur getRow() ska fungera.

1. Existerande funktionalitet måste fortsätta fungera, eller också måste samtliga mallanvändningar gås igenom och korrigeras:
   • Alla riktiga ord ska fortsätta länkas
   • <nowiki/>
   • När bara vissa ord har länkats, får dom övriga inte länkas
   • Specialfall -
   • Specialfall ? (borde detta kategoriseras?)
   • Specialfall tom sträng måste på något sätt markeras som felaktigt, antingen genom konstig visning eller genom kategori
2. Nya, smarta funktioner:
   • Länkning av två former via (form1, form2 → [[form1]], [[form2]])
   • <span> placeras direkt runt länken istället för runt hela cellinnehållet

//Skal 4 juli 2017 kl. 22.58 (CEST)

@Skalman, jag är osäker på att testet med <span> är som vi vill ha det (kanske vi vill att detta ska anges på annat sätt), så jag avvaktar med det lite. Det andra verkar fungera hyfsat, men fler tester visar förmodligen på behov av ytterligare anpassning av koden (t.ex. ser jag i ett användningstest att mask-lösningen kan se konstig ut med synliga hakparenteser). Apostrofer som du hade med i ett test antar jag borde vara utanför span-taggarna så jag ändrade testet. Jag la till kategorisering inte bara för tomma strängar utan även för icke-befintliga argument (nil). "Smarta" funktioner känns bra och du skapade ju tester för dem, så de finns med i koden. Koden... behöver snyggas till.

Jag tänker att det är lika bra att gå igenom alla mallanvändningar som ska börja använda moduler som stödjer sig på getRow, så bakåtkompabilitet tänker jag inte är nödvändig. ~ Dodde (diskussion) 7 juli 2017 kl. 12.06 (CEST)

@Dodde, det är nog så att vissa test kan behöva anpassas.

• mask= ska förmodligen inte hanteras as getRow(), utan av den som anropar getRow(). Missförstår jag något?
• Det spelar ingen roll vilken ordning apostrofer och <span> hamnar. Gör det du tycker blir bäst. Det enda som är viktigt är att [[]] finns nånstans inuti ett element (t.ex. <span>) som har class="infl".
• Finns det inget fall då man vill ha en tom cell (och att man därför inte borde få nån kategori)? Min tanke var att tom sträng är ett fel (kan skickas från mall), medan nil kan vara med flit (kan endast skickas från modul). Det är kanske bättre att ange en type='>empty' om det behövs?

//Skal 8 juli 2017 kl. 17.46 (CEST)

@Skalman, mask-parametrar eller andra mallspecifika parametrar ska getRow naturligtvis inte känna till, men getRow borde nog ha stöd för {{länka-tveksam}}-funktionalitet för att slippa skriva ut parenteser och frågetecken manuellt i modulkoden varje gång det finns behov av en "mask-lösning".

Jag kan inte komma på något fall då man vill ha en tom cell i en grammatikmall. Finns inte formen ska det vara ett streck och är man osäker ska det vara ett frågetecken (och kanske något mer framför). Vad skulle en tom cell betyda? Tömma rubrikceller finns naturligtvis och de genererar inga extra kategoriseringar. (Och OM man nu hade velat ha en tom cell vet jag inte om NIL hade varit bra att skicka med, då hade det varit rimligare att skicka med en tom sträng, eftersom NIL skulle kunna vara ett tecken på en bugg nån annan stans i koden). ~ Dodde (diskussion) 8 juli 2017 kl. 23.26 (CEST)

@Skalman, @Nummer 8589869056 eller andra. Jag har strukit ett förslag på funktionalitet till förmån för en bredare och mer genomtänkt funktionalitet för såväl referenstaggar, stilmarkörer och kanske annat, i grammatiktabellernas celler. Det är dock en sådan typ av sak som skulle vara bra att ha mer än ett par ögon på, och eftersom jag inte vet om eller när isåfall någon har tid och möjlighet att diskutera detta mer genomgående med hjälp av bollande via chatt eller (eller genom att presentera en mer kvalitativ, genomtänkt och självständig utläggning här på wikin), så har jag strukit den funktionaliteten tills vidare. Alla länkar som anges i tabellrutor kommer därmed att tolkas som böjningsformer tills vidare, så not-rutan får vara platsen för övriga länkar tills vidare. ~ Dodde (diskussion) 14 augusti 2017 kl. 00.07 (CEST)

deprecation of pseudo variable "arg" in newer Lua versions

Regarding changes made by @Dodecaplex, I could find mw:Extension:Scribunto/Lua 5.2 changes (I think currently Lua 5.1 is used) and also a reference to this change in Lua unofficial FAQ: 1.23 How to make functions receive a variable number of arguments?. The MediaWiki page states that these changes "may be problematic if Scribunto is ever changed to use Lua 5.2 or later". My question is if anyone knows if un upgrade of the Lua version is planned or how probable it is that it will happen. Should we prepare for Lua version upgrades (alot of modules use the "arg" pseudo argument)? Anyone who can link to information regarding this? @Skalman? ~ Dodde (diskussion) 17 juli 2020 kl. 08.28 (CEST)

@Dodde, I can't find any particular information about upgrades, but I thought I'd pose the question on IRC. I haven't gotten a response yet, but if we get one, it'll be available in the chat log.

Regardless, I think there will be a concerted effort to ensure that any incompatible code is dealt with before upgrading the Lua version. I'd expect something similar to what happened when they replaced the parser: dual compilation for several months, a notification at Bybrunnen, and at least some "outside" help to deal with tricky cases. Skalman (diskussion) 1 augusti 2020 kl. 15.18 (CEST)