Module talk:parameters

Lua error in Module:parameters at line 130: attempt to call global 'remove_holes' (a nil value)
I think you need to change 'remove_holes' to 'export.remove_holes'. — Игорь Тълкачь 22:11, 16 May 2015 (UTC)
 * +1 For example fad is currently completely out of order. JackPotte (talk) 22:42, 16 May 2015 (UTC)
 * Fixed. Sorry for not noticing this sooner. —CodeCat 22:43, 16 May 2015 (UTC)

Two proposals

 * 1) Add description to parameter tags and include it in the error text generated if it is absent. It will be much more descriptive especially for unnamed parameters.
 * 2) Get rid of the initial words of the error message (Lua error in Module:parameters at line) by not using builtin   function. --Dixtosa (talk) 17:59, 23 April 2016 (UTC)
 * what are your thoughts? --Dixtosa (talk) 19:03, 10 May 2016 (UTC)
 * What alternatives are there for ? —CodeCat 19:11, 10 May 2016 (UTC)
 * Simply not using it at all and having  function return the error data and letting the caller decide what to do with it. This module could provide some default behaviour on the returned data (again not exiting the script with the builtin error function but returning a string). The caller code would look like this if the error code is not desirable:

--Dixtosa (talk) 20:07, 10 May 2016 (UTC)
 * We can do that with the  function, too. It's possible to "catch" an error and repackage it. —CodeCat 20:15, 10 May 2016 (UTC)

Quoting of %d
There is a problem with how the module performs the substitution of parameters. The %d needs quoting, as explained in the string.gsub documentation:

The character % works as an escape character: any sequence in repl of the form %n, with n between 1 and 9, stands for the value of the n-th captured substring. The sequence %0 stands for the whole match, and the sequence %% stands for a single %.

It just happens to work because the Scribunto extension does not exactly behave like the underlying lua implementation. Should this get changed our code will break.

Line 47:

should read:

likewise, line 57:

should read:

This can be verified in the lua console: Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio > print(string.gsub("=input", "=", "%d")) dinput 	1 > print(string.gsub("=input", "=", "%%d")) %dinput	1

Lua 5.2 actually reports an error in the first case (invalid use of '%' in replacement string).

– Jberkel (talk) 18:38, 24 August 2016 (UTC)
 * This is now fixed. – Jberkel (talk) 21:41, 29 August 2016 (UTC)

Parameters corresponding to other parameters
It seems to me that there should be a way to indicate that, for instance, the lua, lua, and lua in and its sisters correspond to the lua, and to make Module:parameters return an error when there are more lua, lua, or lua parameters than lua parameters. Thus, if you had, the module would return an error, because there are three  parameters, but only two   parameters for them to correspond to.

This could be invoked by a lua tag in the table for the lua, lua, and lua parameter, similar to the current tag lua. Module:parameters would return an error if lua, lua, or lua is greater than lua.

I'll see if I can implement this myself; but not sure if I understand the module well enough, and if someone else would do it, I would appreciate that. — Eru·tuon 19:51, 14 February 2017 (UTC)
 * I don't think it's necessary. It's perfectly valid for one of them to be empty, and its module handle this case just fine. —CodeCat 19:52, 14 February 2017 (UTC)
 * It's not about parameters being empty (that's handled by  or  ), it's about there being n term parameters, but n + x transliteration, translation, or link text parameters, meaning that x of the transliteration, translation, or link text parameters will not be displayed, but there will be no error telling someone that they have added undisplayed and unnecessary parameters. — Eru·tuon 19:56, 14 February 2017 (UTC)
 * There shouldn't be an error. There's just be a request for a missing term, provided by Module:links. —CodeCat 19:57, 14 February 2017 (UTC)
 * That may be true in Module:nyms, but not in if you have entered 2 terms but 3 alt parameters. — Eru·tuon 19:59, 14 February 2017 (UTC)
 * Then that's an unexpected behaviour of . The known behaviour of is to display "[Term?]" when the term is missing but some other parameter is provided, like say .  also has well-defined behaviour. Other templates should replicate this, or better yet, just let Module:links do its job. —CodeCat 20:02, 14 February 2017 (UTC)
 * It's also the behavior of, isn't it? If you enter , the last  is undisplayed: . Okay, I guess not. Indicating an element without an entry is allowed.
 * Alternatively: lua could automatically make lua be equal to the highest index of the parameters that correspond to it. So, if there is an, or  , or  , then lua would be lua rather than lua in the example above, and calling lua would be unnecessary. — Eru·tuon 20:22, 14 February 2017 (UTC)
 * Or what would make more sense is requiring lua to have lua set, or else return an error if lua is less than the  of the args that correspond to it, since such a situation implies that lua is missing at least one value. — Eru·tuon 20:28, 14 February 2017 (UTC)
 * While the idea makes sense, it also breaks the invariant that  shows the maximum index of the current list. Really, what might be desirable instead is a "record"-type parameter. This would be a parameter that consists not of just a single value, but a set of named values. If such a parameter is also a list, it would be a list of such records. It would be more involved to implement it though, and I'm not sure how the parameters should be named. Consider also that an item within a record could be a list itself, an example is the ,  ,   etc parameters of , which specify the various genders of an individual form. —CodeCat 20:36, 14 February 2017 (UTC)
 * Hm, you're right, so perhaps the variable could be given another name: lua. Could you show an example of what you mean with your record idea? It would be an interesting challenge to figure out how to make the module able to interpret it. — Eru·tuon 00:12, 15 February 2017 (UTC)

Module errors
Lots of new module errors- I think it's related to your recent changes here but I'm not sure. DTLHS (talk) 15:14, 11 March 2017 (UTC)
 * My first edit caused errors, but I think my second edit should have solved the problem. I suspect the errors were caused by to, which  fixed. — Eru·tuon 16:42, 11 March 2017 (UTC)

New table keys set during iteration
It seems to me that the code  at line 54 is setting a new key in a table while it is being iterated over, which may lead to problematic behaviour (unless things have changed). --Njardarlogar (talk) 12:41, 10 June 2017 (UTC)

Aliases of required parameters not working
Having aliases of required parameters doesn't seem to work (see e.g. this module code and use 1 and use 2). --Njardarlogar (talk) 08:12, 19 July 2017 (UTC)
 * Okay, I think I fixed it. Now, the required parameter can have aliases (and they will satisfy the requirement of the required parameter), but the aliases can't be required. — Eru·tuon 17:13, 19 July 2017 (UTC)
 * There's an error on immortalis. —CodeCat 18:38, 19 July 2017 (UTC)
 * Thanks. Module:la-headword is fixed to comply with the changes now. — Eru·tuon 18:42, 19 July 2017 (UTC)
 * Seems to be working now, yes. Good stuff. --Njardarlogar (talk) 19:33, 19 July 2017 (UTC)

Oddity in Module:headword/templates
asked for my help in getting the ts parameter to work in. When he added  to the table of parameters that is passed to Module:parameters, the f N alt parameter would vanish from the output. I did some experimentation and the parameter is present in the parameters table when Module:parameters receives it, but it is not seen by the iterator function returned by  in the   loop that interprets the parameters table. As far as I can tell, that indicates a bug in the function returned by. But I this in Module:sandbox, so maybe there's something I'm missing. — Eru·tuon 05:48, 12 March 2018 (UTC)
 * I fixed this. The problem was that when processing params with = signs in them, the `params` table being iterated over was modified. Modifying a table while iterating over it leads to unpredictable results, including entries never being iterated over or being iterated over twice. Benwing2 (talk) 01:40, 1 March 2019 (UTC)

Avoiding mutating params
There were a bunch of errors after your, so I reverted it. The error I noticed first was the failure of  to clone a table loaded with   in the declension tables in θάλασσα, but there were errors in Module:headword/templates that I didn't understand. Probably there is a way to repair your edit so that it doesn't cause errors. — Eru·tuon 01:37, 1 March 2019 (UTC)
 * I put back the change without the call to mw.clone. The reason for the errors in Module:headword/templates is because you reverted the bug fix that allowed my change to Module:headword/templates to work. (See the previous entry on missing "falt".) Benwing2 (talk) 01:41, 1 March 2019 (UTC)
 * Benwing2 (talk) 01:42, 1 March 2019 (UTC)
 * Ouch, sorry about that. Seems I misread what was going on in CAT:E. — Eru·tuon 01:46, 1 March 2019 (UTC)
 * No prob, should all be fixed now. Benwing2 (talk) 01:51, 1 March 2019 (UTC)

Acceptance of non-ASCII numbers in parameter names
In, an Arabic-Indic digit ١ in was accepted by the Lua pattern used to handle list parameters.

The parameter happened to be treated correctly. It was put at index 1 in the list as expected. Calling  on it returns , and the module replaces   with   (basically, assumes the parameter is tr). But the module shouldn't accept non-ASCII numbers.

Handling parameter names with the  patterns would fix this. I think it should be safe. Most templates don't use non-ASCII parameter names, and anyway I don't think handling parameter names ever requires features of  patterns: non-ASCII character sets or quantifiers acting on non-ASCII characters. But I'll have to think about this more.

Another fix would be replacing  with   in all the patterns in the module. But using  functions could also improve performance. — Eru·tuon 20:54, 29 August 2019 (UTC)