Module talk:String2

Now supports named parameters: source, target, plain, nomatch; and UTC characters:

* <code><nowiki>{{#invoke:String2 |posnq |source=This is a piece of text |target=ece}}</nowiki></code> → {{#invoke:String2 |posnq |source=This is a piece of text |target=ece}}
* <code><nowiki>{{#invoke:String2 |posnq |source=This is a piece of text |target=%s |plain=true}}</nowiki></code> → {{#invoke:String2 |posnq |source=This is a piece of text |target=%s |plain=true}}
* <code><nowiki>{{#invoke:String2 |posnq |source=This is a piece of text |target=%s |plain=false}}</nowiki></code> → {{#invoke:String2 |posnq |source=This is a piece of text |target=%s |plain=false}}
* <code><nowiki>{{#invoke:String2 |posnq |source=This is a piece of text |target=ece |nomatch=0}}</nowiki></code> → {{#invoke:String2 |posnq |source=This is a piece of text |target=ece |plain=false |nomatch=0}}
* <code><nowiki>{{#invoke:String2 |posnq |source=This is a piece of text |target=xyz |nomatch=0}}</nowiki></code> → {{#invoke:String2 |posnq |source=This is a piece of text |target=xyz |nomatch=0}}
* <code><nowiki>{{#invoke:String2 |posnq |This is a piece of text |" of" |true |0}}</nowiki></code> → {{#invoke:String2 |posnq |This is a piece of text |" of" |true |0}}
* <code><nowiki>{{#invoke:String2 |posnq |This is a piece of text |" of" |true |0}}</nowiki></code> → {{#invoke:String2 |posnq |This is a piece of text |" of" |true |0}}
* <code><nowiki>{{#invoke:String2 |posnq |source=Meet at Café Nero |target=afé}}</nowiki></code> → {{#invoke:String2 |posnq |source=Meet at Café Nero |target=afé}}

Any bug reports welcome. --RexxS (talk) 00:08, 8 December 2020 (UTC) [reply ]

Now deleted, per TfD outcome. Plastikspork _―Œ^(talk) 16:18, 7 January 2022 (UTC) [reply ]

I recently noticed a rather significant issue with uppercasing and lowercasing strings in Lua: it mangles strip markers. The built-in parser functions do not. See sample (now a mock-up):

INVOKE:STRING2|UPPER.'"`UNIQ--REF-0000001E-QINU`"'^[1]

invoke:string2|lower.'"`uniq--ref-0000001f-qinu`"'^[2]
USING UC:^[3]
using lc:^[4]

References

1. ^ A reliable source
2. ^ A reliable source
3. ^ A reliable source
4. ^ A reliable source

Is there any good reason to make this feature available to wikitext? It would be highly confusing for editors and template authors to see strip markers. Otherwise this module's upper and lower functions should be removed from anything using them and replaced with the uc:/lc: parser functions. User:GKFX ^talk 18:47, 15 April 2021 (UTC) [reply ]

Done These functions have been removed, and the sentence function has been made strip-marker safe. User:GKFX ^talk 19:36, 24 April 2021 (UTC) [reply ]

I implemented the behavior of {{Trunc }} in Lua, as function trunc() in the sandbox. This code is simpler and faster than the template code. I'd like to promote it to the main module (as opposed to having a small side module just for {{trunc }}). Any objections? — hike395 (talk) 09:12, 9 June 2021 (UTC) [reply ]

I’d like to delete {{Trunc }} entirely. We already have ample substring functions, {{#invoke:string|sub|1|n}} should be adequate (with or without ignore_errors as needed). User:GKFX ^talk 09:15, 9 June 2021 (UTC) [reply ]

{{Trunc }} is transcluded onto 4,400 pages and is used in a tangle of templates. Removing it would be painful. {{#invoke:string|sub|1|''n''|ignore_errors=1}} does not exactly implement the template (because it returns an empty string on error as opposed to the original untruncated string). If you'd like to bring it up at TfD and then be responsible for the cleanup of the mess, please go ahead. If you don't want to go down that path, I'd like to implement it in Lua, either here, or if necessary, in another Module (which I think would be less tidy). I think that would be a lot less work and still make the encyclopedia better. — hike395 (talk) 09:44, 9 June 2021 (UTC) [reply ]

There is Module:Ustring which removes the unhelpful error handling. I don't think it would be that painful to remove. Having multiple substring functions with random names is a product of the pre-Lua era; I don't think it's something that should be perpetuated. User:GKFX ^talk 17:14, 9 June 2021 (UTC) [reply ]

I agree that it would be better to just call {{#invoke:string|sub}} directly, if possible. If you have the spare time to clean up uses of {{Trunc }}, I would support deletion. I just don't have time to clean it up myself. — hike395 (talk) 17:47, 9 June 2021 (UTC) [reply ]

I’ve made some effort to refactor templates using old string functions in recent weeks, but the idea of actual deletion hasn't always gone down well at TfD. I’ll think about another nomination. User:GKFX ^talk 17:44, 10 June 2021 (UTC) [reply ]

As I just discovered when importing this module on a sister project, findpagetext will throw a big ugly (and misleading) Lua error when the wikipage in its first argument doesn't exist, because the module doesn't check that it exists before getting its contents and doesn't try to catch this kind of error.

If you see this text the bug was fixed.

Simply checking that :getContent() didn't return nil or empty and returning nomatch before handing it to mw.ustring.find() is probably enough. Xover (talk) 17:30, 26 October 2021 (UTC) [reply ]

I tweaked the sandbox to fix this. I'll leave updating the main module for a day or two in case anyone sees other issues. Here is a tweaked version of your test above.

• Module:String2 • Module:String2/sandbox • same content
• {{#invoke:String2 |findpagetext |text=Youghiogheny |title=NoSuchPage |nomatch=If you see this text the bug was fixed.}} → If you see this text the bug was fixed.
• {{#invoke:String2 |findpagetext |text=Youghiogheny |title=No[SuchPage |nomatch=If you see this text the bug was fixed.}} → If you see this text the bug was fixed.
• {{#invoke:String2/sandbox |findpagetext |text=Youghiogheny |title=NoSuchPage |nomatch=If you see this text the bug was fixed.}} → If you see this text the bug was fixed.
• {{#invoke:String2/sandbox |findpagetext |text=Youghiogheny |title=No[SuchPage |nomatch=If you see this text the bug was fixed.}} → If you see this text the bug was fixed.

Johnuniq (talk) 06:11, 27 October 2021 (UTC) [reply ]

Thanks! I tried a couple more random edge and gigo cases (empty regular wikipage, Special:BlankPage, Special:Watchlist) and nothing blew up.BTW, only vaguely related and not a bug as such, but I noticed that when you pass in an empty |text= you get empty output (because the check for this case returns nil) instead of the nomatch string, which was unexpected. My expectation for this would be that it is a nomatch, because an empty search string isn't really "invalid" as such, it just doesn't match anything. I could make the opposite argument too, of course, but it might be worth taking another look at when to return nil and when to use nomatch at some point. --Xover (talk) 08:10, 27 October 2021 (UTC) [reply ]

Yes, I wondered about that but decided to keep the original. I doubt if there is any usage of the "feature" but if a template used {{find page text }}, it might easily pass its parameter as |text=. In that case, templates often pass empty text to mean "no parameter" which sort-of makes an empty string result sensible. Johnuniq (talk) 09:01, 27 October 2021 (UTC) [reply ]

I updated the main module so the above checks now work. Johnuniq (talk) 06:35, 28 October 2021 (UTC) [reply ]

The posnq function from this template has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. User:GKFX ^talk 15:37, 31 December 2021 (UTC) [reply ]

Now deleted. Plastikspork _―Œ^(talk) 16:23, 7 January 2022 (UTC) [reply ]

When I try and use the One2a wrapper with convert on a faction such as {{one2a|{{convert|1/2|acre|spell=in}}}} it produces "a-half acre (0.20 ha)" with a hyphen, which isn't grammatically correct. Is there a way to change this to be a space? Thanks, --Voello _talk 13:55, 15 January 2022 (UTC) [reply ]

There is no good support for all variations like that. The simplest would be to give up and use:

• a half acre ({{convert|1/2|acre|disp=out}}) → a half acre (0.20 ha)

Johnuniq (talk) 23:27, 15 January 2022 (UTC) [reply ]

Currently ucfirst fails if you try to use it on for example 32nd or using html entites such as ×ばつ. Please update module with code from sandbox that fixes this. All ucfirst-testcases should be green afterwards. ×ばつ_or_32nd">Tholme (talk) ×ばつ_or_32nd" title="3 years ago">15:31, 12 May 2022 (UTC) ×ばつ_or_32nd">[reply ]×ばつ_or_32nd">

Done Looks good to me – thanks! User:GKFX ^talk 12:04, 14 May 2022 (UTC) [reply ]

If a page gets renamed, findpagetext no longer finds the text, and feels kinda lost. Can it be made to follow redirects (either using module:redirect or by itself)? — Guarapiranga ☎ 03:22, 7 June 2022 (UTC) [reply ]

Re: this discussion (permalink) at Wikipedia:Help desk.

I have tweaked ucfirst() in Module:String2/sandbox to account for that case. I have tweaked Module:String2/testcases to show that I didn't break anything and to show that the ~/sandbox version correctly renders the string of wikilinks where the piped link is not the first link.

Comments desired. Without anyone comments, I shall update the live module from the sandbox.

—Trappist the monk (talk) 00:07, 25 February 2024 (UTC) [reply ]

Good. See my edit at Module:String2/sandbox for a trivial issue. My head is not quite up to parsing the regexes at the moment but surely if first_text exists, that means it is not piped and you don't need to check for that? I think that's what is happening? Several of the mw.ustring could be plain string (faster) but that might be a bit tricky for subsequent editors. I suspect finding the start and end of the lowercase letter and replacing it with sub would be more efficient than gsub but I'm not up to that... Johnuniq (talk) 01:02, 25 February 2024 (UTC) [reply ]

Thanks for the fix. Everything I write from scratch and everything that I maintain has require('strict'). I forget that other modules don't always use that. I've added it to this sandbox.

The code doesn't actually check for unpiped links but does check to see if the link we found is a piped link – we want to upcase the piped link's display text, not the piped link's link text. If not a piped link, we fall into the code that upcases the unpiped link's link text.

mw.ustring.<whatever>() because unicode characters are allowed as article titles. I can imagine non-English redirect links for example.

You may be right with regard to mw.ustring.sub() vs mw.ustring.gsub() but I have never really liked mw.ustring.sub() because to me, it is more cryptic than patterns. I don't suppose it really matters that much because I suspect that ucfirst() isn't used all that often.

—Trappist the monk (talk) 02:00, 25 February 2024 (UTC) [reply ]

Oh. I had a look at what aroused my suspicion and see that I was imagining the "extract" regex at line 26 included a pipe in the "not these characters" part so it only found an unpiped link. A hallucination from non-artificial intelligence. Johnuniq (talk) 04:51, 25 February 2024 (UTC) [reply ]

In the time since my last post, I have hacked some more on ~/sandbox. I did that because it seemed odd to me that ucfirst() had specific code to handle <li> but no other tags. Why just that tag? So I've hacked ~/sandbox so that ucfirst() upcases the first letter character that is not in a stripmarker, an html-like tag, an html character or decimal/hexadecimal numeric entity, and strips the various list markup and miscellaneous punctuation. For example, non-English text wrapped in a {{lang}} template has multiple leading html tags:

{{lang|es|casa}} → <span title="Spanish-language text"><i lang="es">casa</i></span> → casa

So we want the 'c' in casa to be uppercased:

{{#invoke:String2/sandbox|ucfirst|{{lang|es|casa}}}} → Casa

The live version of the function can't handle that:

{{#invoke:String2|ucfirst|{{lang|es|casa}}}} → Casa

Miscellaneous other examples:

Anything I've missed? Is there anything glaringly wrong with the implementation?

—Trappist the monk (talk) 17:27, 3 March 2024 (UTC) [reply ]

There having been no comment (and after a bit of a fumble), I have updated the live module from the sandbox.

—Trappist the monk (talk) 18:48, 10 March 2024 (UTC) [reply ]

Thanks! Johnuniq (talk) 01:09, 11 March 2024 (UTC) [reply ]

I noticed that Module:String specifically does not have any dependencies, presumably so that it can be easily copied to other wikis. However, this module does, and the dependency it specifically requires is Module:GetParameters, which Module:String also uses: specifically, that module copies the function directly in its source to avoid any dependencies. (see: _str.getParameters)

I think it would be nice to do this also for this module, unless I'm misunderstanding the reasoning behind the original decision to omit it from Module:String. ClarFonThey (talk) 02:52, 5 July 2025 (UTC) [reply ]

The original decision had to do with risk levels, IIRC; Module:String was one of the most-used modules on the project with 11.7 million uses, and at the time it wasn't wanted to give a then-obscure module so many uses. Since then Module:String2 has also become high-risk, though, so that's moot. I personally think we should take a few of the higher-use functions here and move them to Module:String so this module doesn't end up used so widely. * Pppery * _{it has begun...} 19:05, 7 July 2025 (UTC) [reply ]