Module talk:affix/templates

"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 template, but I'm sure it could happen with  as well. Anyway, there is no reason to explicitly forbid it. --WikiTiki89 00:25, 20 January 2016 (UTC)

Deitalicization
, : 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., Chrome's "inspect" feature tells me that the CSS property of italicization is assigned to the class  in  . 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. DTLHS (talk) 22:04, 1 August 2017 (UTC)
 * What do you mean by validate? Check if there's an English entry for ? 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 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 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 pos N. — Eru·tuon 23:22, 1 August 2017 (UTC)

Module:parameters
I would like to make these templates use Module:parameters, but as you noted above, it's not currently possible because the module treats  and   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 deals with them, by having a prefix. There's two ways we can go about this: Are there any other templates where this is currently an issue? —Rua (mew) 16:15, 3 September 2017 (UTC)
 * 1) Make the parameters fit the standard, i.e. something like what  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.
 * I don't know of any other templates that have the distinction between x and x 1. 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  and   are actually equivalent normally is because the parameter name key is also used as a valid name. So when you do   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   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   instead of   on . But also that   neatly matches with   on, 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 ), and list parameters that should require a number (like  and ). —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 lua boolean argument should be replaced with a lua table, and then the format of the argument at index 1 can be specified with an option like lua or something.


 * To distinguish the keys of the list and non-list parameters, perhaps we could use : lua and lua, 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   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 s   and   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, analogous to , 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)

Alternative text not being handled in the correct order
@Benwing2, there appears to be a problem with the parsing of alternative texts in the affix module when the term links to e.g. Wikipedia, via the w: prefix. See morbillion, where the text is  and the alternative text is. (The template code is  I intended for this to produce a link to the Wikipedia article, but retaining the single-word alternative text, but instead it just reads the entry title without considering the alternative text, apparently. I may try to look at this bug myself, but in the meantime I'm letting you know in case you think it's an easy fix. Kiril kovachev (talk・contribs) 00:31, 28 June 2024 (UTC)


 * @Kiril kovachev I think this is a known bug of sorts in Module:links; the notation is converted internally into  and when this is passed to  in Module:links, the latter ignores the alt value because there's an embedded link in the to-be-linked text that can't be optimized away. I think in this case it actually outputs a debug message indicating that it ignored the alt= value; if you preview the affix template call and look at the bottom of the screen, where it says "Parser profiling data", there should be a section for debug messages, and if you open it up, it should show a message about the ignored alt=. I think you can work around this by writing  or ; the code that handles the  prefix (here: Module:parse utilities) knows about two-part links and handles them correctly. What we should probably eventually do is throw an error when there's an ignored alt= instead of just silently ignoring it, but before doing that we need to introduce tracking (if it's not already there) to see where this is currently handling, so we don't end up with a flood of errors. @Theknightwho for reference, who has worked a lot on Module:links. Benwing2 (talk) 00:43, 28 June 2024 (UTC)
 * I see, thanks, I will try to work around this for now. Kiril kovachev (talk・contribs) 00:57, 28 June 2024 (UTC)