Module talk:String

This module was considered for merging with Module:HTMLDecode on 2020 May 8. The result of the discussion was no consensus.

Text or other creative content from this version of Module:String was copied or moved into incubator:Module:Wp/nod/String with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

	Archives: Index 1, 2
	This page has archives. Topics inactive for 90 days are automatically archived by Lowercase sigmabot III if there are more than 5.

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

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 {{#invoke:string|len|...}} 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 {{#invoke:string|len|...}} 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)Reply

 Not done: The value returned by a module function must always be a string is not true. mw:Extension:Scribunto/Lua reference manual#Returning text states The module function should usually return a single string; whatever values are returned will be passed through tostring() and then concatenated with no separator. 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)Reply

Alright, it seems then that I will have to fix that in {{#invoke:params|mapping_by_invoking}} and stringify whatever modules may return. --Grufo (talk) 13:35, 18 October 2024 (UTC)Reply

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

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

   ↳ Hello

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

   ↳ Hello

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

   ↳

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

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)Reply

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)Reply

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. @WOSlinker: Any thoughts? Johnuniq (talk) 04:37, 13 July 2025 (UTC)Reply

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)Reply

@WOSlinker: Unfortunately there are an arbitrary number of patterns that can match an empty string, e.g., ^X*$, X*, X? 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 replace text. Instead change the or to an and and change the return from source_str to replace. In fact, another optimization would be: inside if plain then add if pattern == source_str then return replace end. —Uzume (talk) 19:16, 16 July 2025 (UTC)Reply

@Trappist the monk, ⁠andrybak, Johnuniq, WOSlinker, and Uzume: Any updates on this? --Grufo (talk) 12:49, 27 July 2025 (UTC)Reply

I am having trouble searching for vertical bar (|) i.e., U+007C; |. (My RW app: find |- in tables to identify the beginning of a table row.) Here are some tests trying to match c|d 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}} ⟶ 0
2. {{#invoke:String|match|s=abc{{!}}def |pattern=c|d |plain=false |nomatch=0}} ⟶ 0
3. {{#invoke:String|match|s=abc{{!}}def |pattern=c\|d |plain=false |nomatch=0}} ⟶ 0
4. {{#invoke:String|match|s=abc|def |pattern=c{{!}}d |plain=false |nomatch=0}} ⟶ 0
5. {{#invoke:String|match|s=abc|def |pattern=c\|d |plain=false |nomatch=0}} ⟶ 0
6. {{#invoke:String|match|s=abc\|def |pattern=c\|d |plain=false |nomatch=0}} ⟶ c\
7. {{#invoke:String|match|s=abc|def |pattern=c\|d |plain=false |nomatch=0}} ⟶ 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}} ⟶ c|d
• {{#invoke:String|match|s={{/vbar test data}}|pattern=[a-z]{{!}}[a-z] |plain=false |match=2}} ⟶ k|l

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)Reply

@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:

c|d

and

c|d

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 {{!}}, 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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Weird lua error from Module:String when substing {{undated}} on active disagreements in 3O. Snowmanonahoe (talk · contribs · typos) 05:23, 24 February 2026 (UTC)Reply

Resolved there. PrimeHunter (talk) 13:10, 24 February 2026 (UTC)Reply

E.g.:

^{{#invoke:String|replace|source=*foo}}

^

• foo
  Not sure why this happens, but is there any way to prevent it? — Qwerfjkltalk 11:16, 5 August 2026 (UTC)Reply

Back in 2004, someone filed a bug (T2529) about templates that begin with start-of-line markup not rendering correctly if the template wasn't at the start of a line (e.g. in a table cell). The "fix" for that caused this problem, where it's not possible to have a template's output begin with certain characters because it's always interpreted as start-of-line markup (T14974). Possible workarounds include sticking something empty like <nowiki /> at the start of the output, or using HTML entities like {{#invoke:String|replace|source=*foo}} instead. Anomie⚔ 13:26, 5 August 2026 (UTC)Reply

Anomie, but the issue isn't that the asterisk is interpreted as markup; that's want I want. The issue is the leading newline before it - it occurs even when there's nothing else on the line, but I added ^ to make it more obvious. — Qwerfjkltalk 18:13, 5 August 2026 (UTC)Reply

What's the context then, where the newline is causing a problem? I'm having trouble thinking of one offhand. Anomie⚔ 20:40, 5 August 2026 (UTC)Reply

Anomie, User:Qwerfjkl (bot)/inform/middle. I've worked around it by removing a newline before the {{Replace}} template, but it feels like relying on what appears to be a bug is a bad idea. — Qwerfjkltalk 10:41, 6 August 2026 (UTC)Reply

There's probably not much else you can do. I see that with the subst you could do like

* Here are the refs:
<!-- -->{{SAFESUBST:<noinclude />Replace|{{{refs}}}|
| }}}}

which seems like it will do the right thing with and without the bug, although when not substed it breaks. P.S. I see your template does a wrong-seeming thing in a case like Special:Diff/1367921746 where more than one reference is involved. You might do better to drop the {{Replace}} entirely and have the bot do the reformatting itself. Anomie⚔ 13:17, 6 August 2026 (UTC)Reply

Anomie, oops, didn't think of that. I've moved the logic to the bot's code. — Qwerfjkltalk 17:06, 10 August 2026 (UTC)Reply