Module:String

Protected edit request on 25 October 2023

Template:Edit fully-protected Please, add r to the word fist (resulting in first), line number 61. Nishimoto, Gilberto Kiyoshi (talk) 18:11, 25 October 2023 (UTC)

Protected edit request on 3 September 2024

All of the Lua pseudo-regex special characters are in the ASCII range. See en:UTF-8#Encoding. Therefore, we don't need at all to use the (costly) mw.ustring.* functions in some parts I have reviewed.

My request is to replace:

function str._escapePattern( pattern_str )
	return mw.ustring.gsub( pattern_str, "([%(%)%.%%%+%-%*%?%[%^%$%]])", "%%%1" )
end

with:

function str._escapePattern( pattern_str )
	return ( string.gsub( pattern_str, "[%(%)%.%%%+%-%*%?%[%^%$%]]", "%%%0" ) )
end

(I am also removing the capture group, which is unneeded as we can use the "%0" whole capture)

(edit: I am also taking the opportunity, for extra robustness, to add parentheses in order to discard the 2nd value (number of replacements) returned by these gsub() functions, then subsequently by _escapePattern(). The more I encounter this "multiple values returned" Lua feature, the more I think it was a terrible design idea)

Second change: line 409, we can similarly replace:

replace = mw.ustring.gsub( replace, "%%", "%%%%" ) --Only need to escape replacement sequences.

with:

replace = string.gsub( replace, "%%", "%%%%" ) --Only need to escape replacement sequences.

These changes would significantly decrease the overhead of having the "plain mode" enabled in this module's functions.

Od1n (talk) 03:26, 3 September 2024 (UTC)

1243840019, thanks. Od1n (talk) 22:38, 3 September 2024 (UTC)

Protected edit request on 18 October 2024

Template:Edit fully-protected The value returned by a module function must always be a string, however some functions here return numbers (these are len, str_find, find and count). Could you please apply this diff? You can just copy and paste the code at this permanent link.

Although unnoticeable when used in normal wikitext, this can create problems when Module:String is invoked using other modules.

For instance, focusing on the len function, for each argument passed, a template named mytemplate containing the following code

{{#invoke:params|mapping_by_invoking|string|len|mapping_by_replacing|^.*$|%0 mod 3|1|for_each|[$#:$@]}}

should print [PARAMETER-NAME:LENGTH-OF-PARAMETER mod 3]

The code above invokes Template:Mfl for each parameter passed. Then it attempts to replace the lengths saved with %0 mod 3, i.e. by adding  mod 3 at the end of each parameter. And so, for instance, {{mytemplate|hello|world|foo|bar}} should print

[1:5 mod 3][2:5 mod 3][3:3 mod 3][4:3 mod 3]

However, since Template:Mfl returns a number, any attempt to do string manipulation with the number returned will generate an error. --Grufo (talk) 05:17, 18 October 2024 (UTC)

Template:Not done: Template:Tq is not true. mw:Extension:Scribunto/Lua reference manual#Returning text states Template:Tq Further, when calling a module function from other Lua code even that doesn't apply; in that case it's like any other Lua function. I also note this change may well break other code that calls these functions (if it for some reason calls functions from this module instead of calling Scribunto's string manipulation functions directly) that expect a number from len or the like. Anomie⚔ 11:12, 18 October 2024 (UTC)

Alright, it seems then that I will have to fix that in Template:Mfl and stringify whatever modules may return. --Grufo (talk) 13:35, 18 October 2024 (UTC)

Bug in replace: empty strings are not recognized

Hi. I noticed that the replace function is unable to recognize empty strings (see third example):

1. {{#invoke:string|replace|Foo|^.*$|Hello|1|false}}

   ↳

2. {{#invoke:string|replace|Bar|^.*$|Hello|1|false}}

   ↳

3. {{#invoke:string|replace||^.*$|Hello|1|false}}

   ↳

--Grufo (talk) 10:47, 12 July 2025 (UTC)

Because of lines 402–404. The reasoning for that code is not, so far as I can tell, documented. There is similar code, also not documented, in find() but that code makes some sort of sense – find anything in an empty string should return 0. Makes me wonder if replace() was created after find() and used find() as an armature upon which to construct replace(). Seems to me that line 402 could be rewritten as: if '' == pattern then. But, are there any templates out there that rely on this anomaly?

—Trappist the monk (talk) 13:24, 12 July 2025 (UTC)

Function replace() was added on 24 February 2013, two days after function find() was added. The early return in if source_str == '' or pattern == '' [...] was added in between those edits: Special:Diff/540073010. —⁠andrybak (talk) 14:10, 12 July 2025 (UTC)

With some work ({{#invoke:string|replace|2=^.*$|3=Hello|4=1|5=false}}), it is possible for there to be no parameter 1. I don't know what _getParameters would do with that but the code in str.replace should handle a situation where parameter 1 is nil. For convenience, the code treats nil and empty as the same and that might be part of the reasoning for returning an empty string. I agree that ^.*$ should match an empty string although, as mentioned above, it is possible that someone has taken advantage of this undocumented behavior. Template:Ping Any thoughts? Johnuniq (talk) 04:37, 13 July 2025 (UTC)

Yes, I think I must have just copied find and updated the code to do replace. There only seems to be 24 occurences of ^.*$ so won't take long to check if the undocumented behaviour is used. -- WOSlinker (talk) 07:39, 13 July 2025 (UTC)

@WOSlinker: Unfortunately there are an arbitrary number of patterns that can match an empty string, e.g., Template:Code, Template:Code, Template:Code and of course an empty string will match another empty string, etc. There are certainly better ways to replace empty strings with nonempty ones but the logic is valid. The suggestion Trappist the monk made is not the right solution either because it ignores the Template:Code text. Instead change the Template:Code to an Template:Code and change the return from Template:Code to Template:Code. In fact, another optimization would be: inside Template:Code add Template:Code. —Uzume (talk) 19:16, 16 July 2025 (UTC)

Template:Re Any updates on this? --Grufo (talk) 12:49, 27 July 2025 (UTC)

How to search for vertical bar

I am having trouble searching for vertical bar (|) i.e., U+007C; |. (My RW app: find Template:Kbd in tables to identify the beginning of a table row.) Here are some tests trying to match Template:Kbd in a string containing abc|def that do not work, but I'm not sure how to specify the vertical bar either in the pattern. (Or, for that matter, in the string in the tests below; note that some of these use | or | although they render as vbar even embedded in nowikis, so what appear to be duplicate tests below are actually different):

1. {{#invoke:String|match|s=abc{{!}}def |pattern=c|d |plain=false |nomatch=0}} ⟶
2. {{#invoke:String|match|s=abc{{!}}def |pattern=c|d |plain=false |nomatch=0}} ⟶
3. {{#invoke:String|match|s=abc{{!}}def |pattern=c\|d |plain=false |nomatch=0}} ⟶
4. {{#invoke:String|match|s=abc|def |pattern=c{{!}}d |plain=false |nomatch=0}} ⟶
5. {{#invoke:String|match|s=abc|def |pattern=c\|d |plain=false |nomatch=0}} ⟶
6. {{#invoke:String|match|s=abc\|def |pattern=c\|d |plain=false |nomatch=0}} ⟶
7. {{#invoke:String|match|s=abc|def |pattern=c\|d |plain=false |nomatch=0}} ⟶

According to mw:LUAREF#Character class, | just represents itself, because it is not one of ^$()%.[]*+-?), but you can't place it into a pattern in {{#invoke:String|...}} because the invocation will treat it as a param separator. So, how do I search for it using string match, or in any of the other string functions that take patterns?

Using transcluded file /vbar test data, I was able to do it, thus:

• {{#invoke:String|match|s={{/vbar test data}}|pattern=[a-z]{{!}}[a-z] |plain=false}} ⟶
• {{#invoke:String|match|s={{/vbar test data}}|pattern=[a-z]{{!}}[a-z] |plain=false |match=2}} ⟶

But I wasn't able to do it inline without transcluding a file. Is there a way? Mathglot (talk) 22:01, 6 October 2025 (UTC)

@Mathglot: These two solutions

#1

{{#invoke:string | match
	| s = abc{{!}}def
	| pattern = c{{!}}d 
	| plain = false 
	| nomatch = 0
}}

#2

{{#invoke:string | match
	| s = abc{{!}}def
	| pattern = c{{!}}d 
	| plain = true 
	| nomatch = 0
}}

yield:

and

Since you don't use Lua patterns, I suggest you use the second one (i.e. {{tjp2|plain|true}}). P.S. Template calls, parser functions and module invocations are expanded before parameters are passed; so if you write Template:Mwl, the match function will simply receive | and will have no idea you ever called a parser function. --Grufo (talk) 22:35, 6 October 2025 (UTC)

Thank you for this. Actually, your top version was my initial attempt and got a match, but I couldn't tell what was being matched (i.e., the curlies and all match, but not what I was seeking) so I didn't think that was valid. But given your explanation, it sounds like it is a valid match, so that's good to know. I will actually be using Lua patterns; these are simplified examples for the question. Thanks again! Mathglot (talk) 22:50, 6 October 2025 (UTC)

@Mathglot: I am glad it helped. An important exception to the expansion order happens in substitutions. If you write,

{{subst:#invoke:string | match
	| s = abc{{!}}def
	| pattern = c{{!}}d 
	| plain = true 
	| nomatch = 0
}}

you will still get a match, but the match function will actually receive {{!}} instead of | (this is because substitutions are expanded before transclusions). And so, to pass | to the match function in substitutions you will have to write:

{{subst:#invoke:string | match
	| s = abc{{subst:!}}def
	| pattern = c{{subst:!}}d 
	| plain = true 
	| nomatch = 0
}}

--Grufo (talk) 16:24, 8 October 2025 (UTC)

Wow, thanks for that. The core of both of your responses here should be added somewhere at mw:Extension:Scribunto/Lua reference manual, as I looked all over and couldn't find anything like this about vertical bar. Mathglot (talk) 16:40, 8 October 2025 (UTC)

That's probably because the documentation considers Lua code mostly from the perspective of Lua, rather than trying to detail all the idiosyncrasies of MediaWiki's wikitext processing before the arguments get passed into Lua. Anomie⚔ 00:00, 9 October 2025 (UTC)