Template talk:MultiReplace

Template-protected edit request on 12 April 2018

Please add {{{|safesubst:}}} before the #invoke to make the template subst cleanly. {{3x|p}}ery (talk) 19:02, 12 April 2018 (UTC)

 Done by Ahecht {{3x|p}}ery (talk) 20:59, 12 April 2018 (UTC)

Superfluous input sanitization

@Ahecht: I see that you have added the following lines:

			if args[1] == '' then
				args[1] = frame:getParent().args[1]
			end

I cannot understand the purpose of this check. Empty input is perfectly valid and nothing should be done about it. If this assignment takes place, then argument 1 is taken from the parent frame, but other arguments are taken from the current frame. This appears incorrect to me and I suggest that it should be removed. Petr Matas 13:10, 25 April 2018 (UTC)

The intent was to allow for a template to invoke the module with the form {{#invoke:MultiReplace|main|findtext|replacetext}} without having to do {{#invoke:MultiReplace|main|{{{1|}}}|findtext|replacetext}}. If both the module invokation and the template call are blank, it will still be processed as a blank input. It's syntax I copied from other modules, where it's used because it allows the module to distinguish between blank (|1=) and missing input in the template call, but if there isn't a need to do that here, it can be removed. --Ahecht (TALK
PAGE) 15:15, 25 April 2018 (UTC)

^{Forgot to ping Petr Matas. --Ahecht (TALK
PAGE) 15:16, 25 April 2018 (UTC)}

Thank you for your explanation. Distinguishing between blank and missing input will not work here, because the assignment args[1] = nil does not work as expected (args is not an ordinary table). Therefore the better readable invocation {{#invoke:MultiReplace|main|{{{1|}}}|findtext|replacetext}} becomes equivalent to the shortened one.

What I dislike about your solution, is that the behavior is different when the input happens to be empty. Consider someone using in their template {{#invoke:MultiReplace|main|{{{2|}}}|findtext|replacetext}}. Now if the template's parameter 2 is empty or missing, MultiReplace will use the template's parameter 1 instead, which is unexpected and incorrect.

A cleaner way to distinguish between empty and missing template input: Enable a module to be invoked like this: {{#invoke:MultiReplace|main|inputparam=1|findtext|replacetext}}. Such invocation is self-explanatory and the module needs no hacks, which could cause unexpected behavior. Petr Matas 18:35, 25 April 2018 (UTC)

@Petr Matas: That's fine. I'll go ahead and remove it. --Ahecht (TALK
PAGE) 18:41, 25 April 2018 (UTC)

I don't get why any of these changes were necessary, as opposed to keeping the system "everyone invokes the module through {{MultiReplace}}" {{3x|p}}ery (talk) 23:51, 28 April 2018 (UTC)

An important improvement is the provision for a simple call require('Module:MultiReplace').main{input, findtext, replacetext} from lua, because calling templates from there is not so straightforward. The provision for a call using {{#invoke:MultiReplace|main|input|findtext|replacetext}} was added just for completeness, because it was simple to do so. The rest really serves no purpose, because the input always has to be provided and therefore there is no point in distinguishing an empty one from a missing one. Consider it to be just a "what if..." speculation with no direct consequences. Petr Matas 09:33, 29 April 2018 (UTC)

Template-protected edit request on 14 November 2022

There is a global variable that should be fixed, as I did here. Thanks in advance. Od1n (talk) 00:44, 14 November 2022 (UTC)

Requesting an additional change. Currently, if the pattern contains some HTML code, and an error message is displayed, the HTML code is interpreted, whereas it shouldn't be.

For example, {{MultiReplace|1=haystack|2=<span style="color:green">foobar</span>}}

• Currently outputs:
• But it should be:

Another example, wiki markup is interpreted as well : {{MultiReplace|1=haystack|2=''foobar''}}

• Currently outputs:
• But it should be:

To fix this issue, a mw.text.nowiki() should be added, like I did here. Od1n (talk) 01:14, 14 November 2022 (UTC)

 Done both * Pppery * _{it has begun...} 20:58, 15 November 2022 (UTC)

Edit request 20 August 2024

Module:String, and subsequently all templates based on it, supports 'false' / 'no' / '0' and conversely 'true' / 'yes' / '1' values, case-insensitive (and unrecognized values are handled as "true"), for the "plain" parameter in particular. (note the module can be used only through template #require's, not from other modules)

However, this module Module:MultiReplace (used by {{MultiReplace}} and many other templates, see search) only supports 'yes', case-sensitive. For convenience and security, we should support more values, mainly 'true' (which is very often used in template #invoke's of Module:String), and case-insensitive.

Note the module function can be called from other modules, though currently it seems to be called only from template #invoke's.

Below are two implementations, that support 'yes', 'true' (string), '1' (string), true (boolean) and 1 (number):

local argPlain = args.plain
if type(argPlain) == 'string' then
	argPlain = argPlain:lower()
end
local plain = (argPlain == 'yes' or argPlain == 'true' or argPlain == true or tonumber(argPlain) == 1)

local argPlain = tostring(args.plain):lower()
local plain = (argPlain == 'yes' or argPlain == 'true' or argPlain == '1')

Lua's string.lower() is very fast, thus I would prefer the 2nd implementation.

Module:Yesno could have been used, but for performance reasons, I prefer to avoid require()'ing it.

Od1n (talk) 06:45, 20 August 2024 (UTC)

Using "yes" seems just fine. I don't see a strong reason to support lots of aliases. People can read the documentation — Martin (MSGJ · talk) 07:35, 20 August 2024 (UTC)

It's confusing because all templates based on Module:String can use true or yes (and true is the common one), but then in {{MultiReplace}} only yes works… (edit, case in point: 1241264158) Od1n (talk) 07:49, 20 August 2024 (UTC)

At the very least, could you please add support for the 'true' value, case-sensitive?

local plain = args.plain == "yes" or args.plain == "true"

Od1n (talk) 01:45, 3 September 2024 (UTC)

I would just use Module:Yesno. Accepting a standard parameter set and not reinventing the wheel beats performance here. * Pppery * _{it has begun...} 20:30, 5 September 2024 (UTC)

I consider that the string manipulation templates and modules may be used many times on a given page, and for sure, they are used many times on the wiki as a whole. And numbers add up. Therefore, I am bit hesitant about adding a "require", as I'd prefer to keep the modules really lightweight. However, most of the execution time is not spent in the Lua code, but in the overhead of the #invoke (i.e. bootstrapping the execution environment), see T357199.

I can think of two solutions:

• Just add support of 'true' for the time being. This could always be expanded later.
• Implement the Module:Yesno, but in that case, also implement it in Module:String for consistency.

Od1n (talk) 06:54, 7 September 2024 (UTC)

@Od1n Or the third option, since Module:String is used 10 times as much as this module:

• Use local plain = args.plain and require('Module:String')._getBoolean(args.plain) or false for consistency with Module:String

--Ahecht (TALK
PAGE) 21:39, 16 September 2024 (UTC)

As denoted by the leading underscore, the _getBoolean method is intended as private, and I think it should be respected. Case in point, in my local sandboxes for fixing this issue in Module:String, my best solution so far involves modifying the _getBoolean method (namely, adding it a second parameter to provide the default value).

By the way, your code should rather be -- NO, see next message -- local plain = args.plain ~= nil and require('Module:String')._getBoolean(args.plain) or true

So, provided we adopt Module:Yesno here, the code could be:

-- NO, see next message -- local plain = args.plain ~= nil and require('Module:Yesno')(args.plain, true) or true

Yes, the default value "true" is written twice. We have to support inputs "nil" (parameter absent), "empty string" (parameter present but empty), and for extra robustness, unrecognized input falls back to "true" instead of "nil".

Od1n (talk) 00:15, 17 September 2024 (UTC)

No, just encountered (again) the usual pitfall with Lua's "pseudo-ternaries" (see "Standard solution: and/or" section in this page): if require('Module:Yesno')(args.plain, true) gives "false", then args.plain ~= nil and require('Module:Yesno')(args.plain, true) or true gives "false" instead of the expected "true"…

So… we would have to write no less than this:

local plain
if args.plain ~= nil then
    plain = require('Module:Yesno')(args.plain, true)
else
    plain = true
end

Od1n (talk) 00:21, 17 September 2024 (UTC)

@Od1n You don't need args.plain ~= nil because there's no need to distinguish between it being missing ("nil") or false since we're emulating Module:String which passes new_args['plain'] or false to _getBoolean. And I'm not buying that the underscore indicates a private function -- if it were private it would use local function _getBoolean( boolean_str ). The underscore is commonly used on Wikipedia to indicate functions that should only be called from Lua and not invoked from wikitext (see mw:Manual:Coding conventions/Lua#Naming conventions). --Ahecht (TALK
PAGE) 15:51, 17 September 2024 (UTC)

• Please, let's not mix up nil with false, just because "hey, it also works in this specific case". It won't do any good. Too much trouble already…
• I rather guess the original module developer overlooked to use local functions. Notice there are also _getParameters(), _error(), _escapePattern(); at the very least, the first two are definitely not meant to be used anywhere else. Od1n (talk) 16:30, 17 September 2024 (UTC)

Od1n (talk) 16:30, 17 September 2024 (UTC)

For the record, I agree with od1n here on the second point - the functions with underscores in Module:String appear to be intended to be private, not to be called from Lua. But I agree with Ahecht on the second point - that including explicit nil checks here is just wastage.

We've gotten to the point where months in, there still isn't any consensus on what, if any, edit to make to a module with 200,000 uses. Which means this request will have to be closed as not done for lack of agreement on what to do. Which is a shame, since everyone agrees something should be done, but it's the state we've come to. * Pppery * _{it has begun...} 22:30, 19 October 2024 (UTC)

Deactivating per my previous comment. * Pppery * _{it has begun...} 02:50, 4 November 2024 (UTC)