@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)
{{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)@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)
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)This module needs to validate its parameters to prevent things like diff. DTLHS (talk) 22:04, 1 August 2017 (UTC)
|lang= don't break. But I wouldn't have an objection to a bot updating them. — Eru·tuon 22:54, 1 August 2017 (UTC)
|lang=; they have code that is intended to do that. — Eru·tuon 23:01, 1 August 2017 (UTC){{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.|pos= and |posN=. — Eru·tuon 23:22, 1 August 2017 (UTC)@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:
{{head}} does, which means renaming existing uses and teaching people that the old way no longer works. That'll obviously upset some people.Are there any other templates where this is currently an issue? —Rua (mew) 16:15, 3 September 2017 (UTC)
|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)
lang= and lang1= are actually equivalent normally is because the parameter name key is also used as a valid name. So when you do = {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)
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.=: 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 rather than args.lang=, 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)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)
@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 w:Morbius (film) and the alternative text is Morbius. (The template code is {{affix|en|w:Morbius (film)|alt1=Morbius|-illion|...}} 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)
w:Morbius film notation is converted internally into ] and when this is passed to full_link() 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 w:]; the code that handles the w: prefix (here: Module:parse utilities#L-555) 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)