Module talk:checkparams

Interaction with tables

@JeffDoozan Can you add a trailing newline if used with tables? The table at Middle Korean 죽다 (cwukta) is trashed. —Fish bowl (talk) 11:50, 18 March 2024 (UTC)

@Fish bowl:  fixed, thanks! JeffDoozan (talk) 14:38, 18 March 2024 (UTC)

Gaps in Positional Parameters

@JeffDoozan: The logic for positional parameters is hostile. If, for example, {{{2}}} is allowed going by the text of the template, but {{{1}}} is not, then at present we get a warning. The logic should be amended either to consequently allow {{{1}}}, or to check that {{{1}}} is blank. The second alternative is probably unnecessarily severe. I'm currently finding a lot of warnings from Lithuanian inflection templates, which I'm slowly switching off (via the list of allowed parameters) I now understand them. The nastiest so far is a template with 28 positional parameters, of which only the even numbered parameters are used.--RichardW57 (talk) 12:08, 31 March 2024 (UTC)

@RichardW57:  Done, it no longer warns for empty gap parameters. JeffDoozan (talk) 17:02, 31 March 2024 (UTC)

Thanks, but I think you missed something. Its still failing for

{{lt-noun-m-is-1-1|dangoraiž|dangóraiž}}

Declension of dangóraižis

	singular (vienaskaita)	plural (daugiskaita)
nominative (vardininkas)	dangóraižis	dangóraižiai
genitive (kilmininkas)	dangóraižio	dangóraižių
dative (naudininkas)	dangóraižiui	dangóraižiams
accusative (galininkas)	dangóraižį	dangóraižius
instrumental (įnagininkas)	dangóraižiu	dangóraižiais
locative (vietininkas)	dangóraižyje	dangóraižiuose
vocative (šauksmininkas)	dangóraiži	dangóraižiai

.

I can only get warnings displayed in preview mode, so this post may not serve as a demonstration of the problem To reproduce, edit dangoraižis and preview. --RichardW57 (talk) 17:18, 31 March 2024 (UTC)

Aha! It does work, by currently putting this page in cat:Pages using bad params when calling Template:lt-noun-m-is-1-1. --RichardW57 (talk) 17:21, 31 March 2024 (UTC)

@JeffDoozan: I understand now. You've gone for the overly strict interpretation, which doesn't help with the Lithuanian declension templates. I'll carry on with listing the positional parameters, so {{lt-noun-m-is-1-1}} will no longer be a test case and this topic will stop showing the error. --RichardW57 (talk) 17:37, 31 March 2024 (UTC)

It's warning because {{lt-noun-m-is-1-1|dangoraiž|dangóraiž}} has a non-empty value for the "gap" parameter |1=. If the template doesn't use the parameter, and an editor enters a value, I think it's correct to show a warning that the value entered isn't going to be used. If you find templates like this that have existing uses with "old" data in some of the positional params that can safely be discarded, let me know and I can clean them up with the bot. JeffDoozan (talk) 17:38, 31 March 2024 (UTC)

@JeffDoozan: That's an editor-hostile idea. As far as I can make out, for Lithuanian noun declension templates the first parameter is the stem when the stress is on the ending, so is the stem as normally written, and the second parameter is the stem when the stress is on the stem. One accent pattern has fixed stress on the stem, and another three have mobile stress, largely in accordance with the IE strong/weak case distinction and de Saussure's Law. It's simpler for the editors if we keep it this way, so bots stripping the redundant parameter out would not help. --RichardW57 (talk) 19:40, 31 March 2024 (UTC)

@RichardW57: Thank you for your thoughts on this. If understand you right, you're saying that in the case of the Lithuanian templates, there are multiple noun templates that all follow the pattern {{lt-noun-1|foo|bar}}, {{lt-noun-2|foo|bar}}, etc even though not all of them use |foo so that editors can put the same parameters in the same order without thinking about which template they're using. That's exactly the sort of special-case that's meant to be handled as you're doing, by explicitly listing the allowed-but-not-used parameters so that editors can continue as-is. I still think that's a special case, and not the most common case and therefor shouldn't be the default. To make things less hostile, what do you think about putting a short message in the warning, maybe with a link to a page with more helpful instructions for explicitly allowing unused parameters? Any suggestions for wording such a message? JeffDoozan (talk) 23:30, 31 March 2024 (UTC)

@JeffDoozan: It might also be helpful to say 'unexpected param' or 'unused param' rather than 'bad param'. 'Unused' would be a good word if your analysis can work out which parameters may be used: 'unexpected' if not. (A template can contain something like {{{{{{1}}}}}}},and I think module invocations are also inscrutable.) A link to the detecting module would also help. When I first saw the message, I thought the interface had changed since the call was written and was wondering if the generated tables could be correct. --RichardW57 (talk) 00:08, 1 April 2024 (UTC)

"Parameter 4 is never used by Template xxx" is comprehensible - it's its presence, not its content, which is causing the problem.

If there are allowed but unused parameters, don't we have to list them all, whether potentially used or not? --RichardW57 (talk) 00:14, 1 April 2024 (UTC)

@RichardW57: Great suggestion, thank you. I went with "The template X does not use the parameter(s): 3=test; foo=bar. Please see Module:checkparams for help with this warning." I want it to show the value of the parameters to help editors find the source of the problem when there's an extra "=" or "|" that causes the parser to detect a new parameter in unexpected places. If there are allowed but unused parameters you'll have to list them all except for empty positional parameters, which with the new "allow empty gap" logic will always be allowed up to the greatest explicitly listed positional parameter. So if you've got a template that only uses the first 2 of 8 positional parameters, you can list "1,2,8" and it will allow any value in parameters 1,2 and 8, and blank values in "3,4,5,6 and 7" JeffDoozan (talk) 01:09, 1 April 2024 (UTC)

@JeffDoozan There is a simpler way to handle allowing just a few parameters. For example, to allow the passing of non-blank parameters 3 and 4, just add {{#if:{{{3|}}}{{{4|}}}|}} to add nothing if either is non-blank. That will change those two parameters to being used, without having to list any used parameters as being allowed. --RichardW57m (talk) 15:28, 3 April 2024 (UTC)

Sure, that works, just leave a comment for the next editor explaining why there's a construction that doesn't do anything. JeffDoozan (talk) 15:46, 3 April 2024 (UTC)

@RichardW57m Richard - I'm really, really not keen on what you're doing here. You're basically just finding ways to circumvent the very thing this module is designed to catch... Pinging @Benwing2, @This, that and the other and @Surjection for thoughts, since what Richard's suggesting just adds needless overhead and clutter, for the sake of turning a warning off instead of simply fixing it. Theknightwho (talk) 01:26, 4 April 2024 (UTC)

@Theknightwho I agree, this makes no sense. Do you have examples of Richard actually doing this, or is it just a suggestion on his part? Benwing2 (talk) 01:28, 4 April 2024 (UTC)

@Benwing2 I've just reverted a few examples of Richard explicitly allowing unused parameters ([1], [2], [3], [4]), when the much more obvious solution would be to unify/fix the templates themselves. The warnings are a symptom, not an issue. Theknightwho (talk) 01:32, 4 April 2024 (UTC)

@Theknightwho I agree; a basic principle of computer science is you do not mask bugs, you fix them. Benwing2 (talk) 01:36, 4 April 2024 (UTC)

@Theknightwho, Benwing2: A basic principle of engineering is, "IF IT AIN'T BROKE, DON'T FIX IT". --RichardW57 (talk) 01:50, 4 April 2024 (UTC)

@RichardW57 The template call at rytai is a complete mess. I don't know if it's because of a syntax change at some point in the past or simple user incompetence, but either way, it clearly should go in a maintenance category. What you've been doing here is not helpful, and I can't understand why it matters to you so much when it's very easy to ignore if you don't care about it. Theknightwho (talk) 01:55, 4 April 2024 (UTC)

@Theknightwho, Benwing2: I agree that it could be rearranged a lot better. If the parameters were arranged 4 to a line, so one row per case, it would be a lot clearer. At some time, it seems that the order of the quartets was:

1. singular without accentuation
2. singular with accentuation
3. plural without accentuation
4. plural with accentuation

Having both forms seems unnecessary, and I can't find any trace of them both being used. Only the 2nd and 4th elements are now used, but there are quite a few examples where all four are populated, which is confusing while the templates are undocumented. I think it would be better to replace {{lt-decl-noun-stress}} with {{lt-decl-noun}} throughout, but we don't need any maintenance categories to do that, and we don't need to scare the horses while we do it. Red ink distracts from any other work that needs doing. Note that {{lt-decl-noun-stress}} is currently used throughout to present the noun declension tables with accentuation. It seems to have been added as a bad programming move.

There is the issue that the accentuation pattern has not been determined for several cases, but that does not impede giving the normal spelling of the inflected forms. With the current parameter set-up, the calls just giving the spelling can easily be converted to what is needed to also show the accentuation - once it has been determined.

What we have is templates as a set of forms to be filled out by lexicographers, not an exercise in programming. (I know the skill sets often overlap.) It is easier for the usual templates where the programming provides the endings if we leave the pattern of {{template|stem in orthography|stem with accent marked}}. When accentuation is shown and is mobile (patterns 2, 3 and4), both forms of the 'stem' are needed. I write 'stem' as the final vowel and sometimes the preceding consonant vary by case and number. For this simplicity of use, I believe it is easier to give both parameters, even when only one is needed. (As an additional complication to the programming, there seems to be some irregularity or complication in the genitive plural.) --RichardW57 (talk) 02:46, 4 April 2024 (UTC)

@Theknightwho @JeffDoozan @RichardW57 I have converted all uses of {{lt-decl-noun-stress}} and {{lt-decl-noun-unc-stress}} to {{lt-decl-noun}} and {{lt-decl-noun-unc}} and fixed places where {{lt-decl-noun-stress}} was wrongly used for plurale tantum nouns, like rytai. Benwing2 (talk) 03:39, 4 April 2024 (UTC)

@Benwing2: Thank you. I hope we haven't accidentally destroyed information as to which nouns' declension lacks stress marking. --RichardW57 (talk) 05:30, 4 April 2024 (UTC)

@RichardW57 How would that have happened? Benwing2 (talk) 05:34, 4 April 2024 (UTC)

@Benwing2: I was beginning to form the hypothesis that {{lt-decl-noun}} was being used when the stress was not shown, and {{lt-decl-noun-stress}} was being used when it was shown. I got up to check this hypothesis, only to find that you had already made the move. However, I believe it is straightforward to check whether it is shown (a simple bit of Lua, probably only testing the nominative) and add to an explicit maintenance category if not, so it's actually a small loss, and the replacement would be more reliable. --RichardW57m (talk) 08:29, 4 April 2024 (UTC)

I had been worried that monosyllabic nouns might never be marked for stress, but the example pàts indicates that this is very unlikely to be a problem. --08:29, 4 April 2024 (UTC) RichardW57m (talk) 08:29, 4 April 2024 (UTC)

@RichardW57 I am thinking of fixing the Lithuanian noun templates so you don't need to specify both the accented and unaccented stems, only the accented one. AFAIK you can derive the unaccented stem from the accented stem simply by removing the accents (acute, grave, circumflex), so it seems a waste of editor effort to require both. Any objections? Benwing2 (talk) 05:57, 5 April 2024 (UTC)

@Benwing2: Are you doing this because I am in the middle of documenting and regularising the templates? There are also some sneaky tricks going on, so the parameters aren't always in the right order and the probably misnamed {{lt-noun-m-is-3}} has a different, so far undocumented interface to the rest. Finally, there are some irregularities that could be stress-related - I haven't dug into them. The grammars I've looked at so far are vague on how the forms are selected. In other words, please hold on a week or two. --08:10, 5 April 2024 (UTC)

It is probably also worth reviewing the adjective and verb templates at the same time.

And don't forget to remove an explicit dot above when you strip off an accent above an 'i' - but not above an 'e'! --RichardW57 (talk) 08:10, 5 April 2024 (UTC)

@RichardW57 Not trying to undercut you, I didn't realize you are working on the templates. I just noticed there is all this duplication that should be removed. Benwing2 (talk) 08:11, 5 April 2024 (UTC)

@RichardW57 @Benwing2 @JeffDoozan One thing that concerns me about the current set-up for manual parameter checking is that it completely disables automatic checking, meaning that every other parameter needs to be specified.

I can't think of any situations where you would want to exclude valid parameters (since that would mean a warning would be thrown when a legitimate parameter got used, which makes no sense), so I'll change the logic so that the manually-specified parameters are added in addition to the valid ones. I'll also add redundancy-tracking, since it's the kind of thing that'll show up after template edits, suggesting the manual parameters might need adjusting.

I'm still of the opinion that this functionality should be used sparingly, but it circumvents the awkwardness of manually specifying every parameter on a complex template (particularly if there's a {{{ {{{1}}} }}} situation, which the automatic checker is now capable of handling thanks to the template parser). Theknightwho (talk) 10:47, 5 April 2024 (UTC)

@Theknightwho I agree with this change. Benwing2 (talk) 10:48, 5 April 2024 (UTC)

@Theknightwho I'm okay with the change. I was originally worried that the parameter detection might be expensive in time or memory so the override could be used to disable it. JeffDoozan (talk) 14:27, 5 April 2024 (UTC)

@JeffDoozan It's lucky that templates and arguments have to be parsed at the same time, so all the optimisations and weird quirks of template parsing carried over automatically - it was just a case of telling it to return the arguments instead of the templates.

If you're curious, the comments on the template parser go into detail about some of the weirder aspects, many of which are totally undocumented (as far as I can tell). Theknightwho (talk) 14:36, 5 April 2024 (UTC)

The endings are sensitive to stress, though the templates unnecessarily fail to capture that. According to Mathiassen (https://theswissbay.ch/pdf/Books/Linguistics/Mega%20linguistics%20pack/Indo-European/Balto-Slavic/Lithuanian%2C%20A%20Short%20Grammar%20of%20%28Mathiassen%29.pdf, p41), the vocative singulars of nouns in -ias depend on the stress pattern. --RichardW57m (talk) 10:48, 10 April 2024 (UTC)

Using the template parser

@JeffDoozan It occurs to me that it would make sense for this module to use Module:template parser, since it has full support for template arguments (which can be really tricky to parse when they interact with adjacent templates). It would be very straightforward to add a function which iterated over every argument on a page. It also supports HTML comments, magic words, noinclude/onlyinclude tags etc, which should greatly simplify a lot of what this module is currently doing. For example, I suspect argument contructs like {{{{{!}}}}} wouldn't be recognised at the moment, but the template parser would know how to deal with it. Theknightwho (talk) 22:37, 3 April 2024 (UTC)

@JeffDoozan I went ahead and implemented this, since I'm reasonably sure the template parser is 100% accurate when it comes to parsing template/parameter braces, and I didn't notice any performance impact. Theknightwho (talk) 00:51, 4 April 2024 (UTC)

One other thing: the template parser will preprocess the contents of argument names for a more accurate parse (e.g. if the template had {{{1{{{2}}}3}}}, the text 1{{{2}}}3 would be preprocessed to get the "true" argument name). At the moment, it just resorts to default values, but it should be possible to modify the iterator so that the actual input argument list is used (e.g. if the template call had 2=foo, then the argument's name would be 1foo3). This kind of construct isn't terribly common, but I've certainly come across it before. Theknightwho (talk) 01:02, 4 April 2024 (UTC)

This now works. Theknightwho (talk) 01:19, 4 April 2024 (UTC)

Thanks! JeffDoozan (talk) 14:27, 5 April 2024 (UTC)

Categorisation in Template Documentation

As there were a large number of (named) parameters to {{lt-decl/boilerplate}}, I added a call to the module to check the list supplied. I have deliberately inserted an error ("|bid=6") in the call of that template in Template:lt-noun-f-tė-3/documentation, but I cannot see any sign of anything being added to a category as a result, though I do get the right warnings when I preview Template:lt-noun-f-tė-3/documentation. What should have been put in what category? --RichardW57 (talk) 12:27, 6 April 2024 (UTC)

 fixed this was a regression with the recently added call to Module:utilities/format_category. Template:lt-noun-f-tė-3/documentation is now properly categorized into Category:Pages using bad params when calling Template:lt-decl/boilerplate JeffDoozan (talk) 18:01, 6 April 2024 (UTC)

@JeffDoozan:Thank you. I have now removed the deliberate error, and now know where to monitor. --RichardW57 (talk) 18:22, 6 April 2024 (UTC)

Bad parameter detection

@Theknightwho The page Template:ajp-presconj/Aa is warning that {{ajp-presconj}} doesn't use |actp-p= and other params when it pretty clearly does, albeit embedded within a wiki table. Is this a bug in Module:template parser? JeffDoozan (talk) 22:24, 8 April 2024 (UTC)

@JeffDoozan They look to be commented out, so it's ignoring them. Theknightwho (talk) 22:26, 8 April 2024 (UTC)

Yeah, the error disappears if I uncomment it. Theknightwho (talk) 22:29, 8 April 2024 (UTC)

Yeah, my bad, I didn't look close enough, thanks! JeffDoozan (talk) 22:31, 8 April 2024 (UTC)