Module talk:affix/templates

@Wikitiki89 "It is often useful to display just one part of the compound and use the template for categorization" Can you give an example of a case like this? —CodeCat 00:23, 20 January 2016 (UTC)

See for example כּלומרשט. Mostly this applies to the {{affix}} template, but I'm sure it could happen with {{compound}} as well. Anyway, there is no reason to explicitly forbid it. --WikiTiki89 00:25, 20 January 2016 (UTC)

Deitalicization

@CodeCat, @Wikitiki89: could we edit this module so that {{prefixsee}} and its sisters do not italicize words? We don't usually italicize words in bulleted lists (we use {{l}} rather than {{m}} for them) anyway. At the very least, could we edit this module so that non-Latin characters do not get italicized, just as {{m}} doesn't italicize non-Latin characters? —Aɴɢʀ (talk) 19:26, 25 March 2016 (UTC)

The only thing that could control the display, that I can see, is the "derivedterms" CSS class. —CodeCat 19:29, 25 March 2016 (UTC)

Is it maybe something at Module:compound rather than this subpage? —Aɴɢʀ (talk) 19:51, 25 March 2016 (UTC)

That template doesn't use the main module. —CodeCat 20:34, 25 March 2016 (UTC)

So how do we fix it? —Aɴɢʀ (talk) 09:58, 26 March 2016 (UTC)

Huh, this issue has still not been resolved. @Angr, Chrome's "inspect" feature tells me that the CSS property of italicization is assigned to the class CategoryTreeLabelPage in ext.categoryTree.css. Not sure how to access that file. It would be nice if the list of words could have language-appropriate fonts applied to them. — Eru·tuon 09:22, 28 December 2016 (UTC)

Validation

This module needs to validate its parameters to prevent things like diff. DTLHS (talk) 22:04, 1 August 2017 (UTC)

@DTLHS: What do you mean by validate? Check if there's an English entry for -t-? That would be quite expensive. — Eru·tuon 22:16, 1 August 2017 (UTC)

No, not accept a language parameter in two different positions (as lang= and as 1) DTLHS (talk) 22:18, 1 August 2017 (UTC)

Well, that's so that the possibly hundreds of morphology templates with |lang= don't break. But I wouldn't have an objection to a bot updating them. — Eru·tuon 22:54, 1 August 2017 (UTC)

It is broken, since if you do something like {{affix|let|-t-|-er|lang=en}} it will be categorized under Category:Lesing-Gelimi words interfixed with -t-. DTLHS (talk) 22:57, 1 August 2017 (UTC)

Oh, I didn't notice that. I thought all the templates were able to correctly handle |lang=; they have code that is intended to do that. — Eru·tuon 23:01, 1 August 2017 (UTC)

The idea with {{affix}} was that it was never going to accept the |lang= parameter, but I guess someone didn't know that and used the parameter anyway.

But I agree that Module:compound and Module:compound/templates need updating. Way too much repetition, and it would be great if the template interface functions could use Module:parameters. That may not be currently possible, if Module:parameters can't distinguish between |pos= and |posN=. — Eru·tuon 23:22, 1 August 2017 (UTC)

Module:parameters

@Erutuon I would like to make these templates use Module:parameters, but as you noted above, it's not currently possible because the module treats lang= and lang1= as equivalent. The module is coded this way because that's how we generally use/name parameters, so the way that these etymology templates name them is actually an exception. Contrast it with how {{head}} deals with them, by having a prefix f. There's two ways we can go about this:

1. Make the parameters fit the standard, i.e. something like what {{head}} does, which means renaming existing uses and teaching people that the old way no longer works. That'll obviously upset some people.
2. Modify Module:parameters in some way so that parameters like this can be handled properly.

Are there any other templates where this is currently an issue? —Rua (mew) 16:15, 3 September 2017 (UTC)

I don't know of any other templates that have the distinction between |x= and |x1=. I'd rather not mess with the parameters of the morphology templates, and instead make Module:parameters accommodate them, unless there is another reason to change the parameters. (For instance, if the parameter names are so confusing that people are using them incorrectly.) — Eru·tuon 21:22, 3 September 2017 (UTC)

Ok. Then to solve that problem. The reason that lang= and lang1= are actually equivalent normally is because the parameter name key is also used as a valid name. So when you do ["lang"] = {list = true}, then because the key is "lang", you automatically get that as a valid parameter name. There is currently no way around this. If you use a pattern like "lang=" as the name, meaning that the equals sign stands for a number, then the module strips the equals sign from the name when storing the arguments, so they still end up as "lang". User:Kc kennylau did it this way apparently on purpose, although I don't know why. A consequence of this is that you can actually use faccel= instead of f1accel= on {{head}}. But also that f_qual= neatly matches with f= on {{ro-noun}}, which is desirable, so we don't want to remove this feature. I suppose fundamentally, the distinction is between list parameters that should allow omission of the number 1, or perhaps even forbid its inclusion (like on {{ro-noun}}), and list parameters that should require a number (like {{head}} and {{compound}}). —Rua (mew) 22:17, 3 September 2017 (UTC)

Yes, we certainly need to have a way to distinguish those two cases. If there are multiple list arguments in a given template, and all of them either require or forbid the number 1, it would be concisest to specify it using an argument. Probably the return_unknown boolean argument should be replaced with a options table, and then the format of the argument at index 1 can be specified with an option like require1 = true or something.

To distinguish the keys of the list and non-list parameters, perhaps we could use =: lang= and lang, and then have another option to tell Module:parameters not to remove the =. I don't completely like that solution because you have to type args["lang="] rather than , and it looks clunky. But perhaps there's no other option, for instance a character unlikely to be used in template parameter names, but permitted in Lua names. — Eru·tuon 00:27, 4 September 2017 (UTC)

Proto-Indo-Iranian and Proto-Indo-Aryan roots

Since we have Category:Terms by Proto-Indo-Iranian root by language and Category:Terms by Proto-Indo-Aryan root by language as existing etymology subcategories, at some point derivtypes "PII root" and "PIA root" respectively should be added (though I personally don't know exactly what this would need to entail). This would be useful so that templates like {{PII root see}}, analogous to {{PIE root see}}, can be created to be used in Derived Terms sections of PII and PIA entries. — 69.120.66.131 04:20, 25 November 2021 (UTC)