Jump to content

Wikipedia talk:Lua

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Lua (talk) Help To do Resources Reference manual
Shortcut

Regex help

[edit]

Any LUA Regex experts who might be able to help me? Trying to write a regex with an or statement in it but my understanding is that LUA doesn’t support or statements in their regexes. So for example if I’m trying to detect a month in a date I would normally do something like: 

\d+\s*(Jan|January|Feb|February|…)\s*\d{4}

How can I achieve the same result with a regex in LUA? —Zackmann (Talk to me/What I been doing) 18:36, 17 September 2025 (UTC)[reply]

The first idea that comes to my mind is just using a regular (%a+) catch and then manually checking the content of the group in lua code to see if it matches a known month, since lua regex is far more simplistic than standard regexes. Aidan9382 (talk) 18:44, 17 September 2025 (UTC)[reply]
As did I:
string.match ("17 September 2025", "%d+%s*(%a+)%s*%d%d%d%d") – validate the returned value as a next step
Or one of these:
mw.language.getContentLanguage():formatDate ("M", "17 September 2025") – returns Sep
mw.language.getContentLanguage():formatDate ("F", "17 September 2025") – returns September
mw.language.getContentLanguage():formatDate ("m", "17 September 2025") – returns 09
mw.language.getContentLanguage():formatDate ("n", "17 September 2025") – returns 9
—Trappist the monk (talk) 18:57, 17 September 2025 (UTC)[reply]
Thanks!!! —Zackmann (Talk to me/What I been doing) 19:00, 17 September 2025 (UTC)[reply]
What are you actually trying to do? Maybe {{extract}}. Johnuniq (talk) 04:24, 18 September 2025 (UTC)[reply]

Enhanced testing for page existence

[edit]

From Wikipedia:Village pump (technical)#Tech News: 2025-40:

Lua modules will be able to use the mw.title.newBatch function to look up the existence of up to 25 pages at once, in a way that only increases the expensive function count once. See mw:Extension:Scribunto/Lua reference manual#mw.title.newBatch. Johnuniq (talk) 00:04, 30 September 2025 (UTC)[reply]

That will be really useful. Thanks for the tip — Martin (MSGJ · talk) 08:13, 30 September 2025 (UTC)[reply]

Lua programmer needed for short project related to Perennial sources page

[edit]

We are looking for a volunteer to help expand (or redo) a module that takes a dozen params and builds a wikitable row from it. We have a very rudimentary version at Module:RSPTest that reads a data file and dumps just two of the dozen (and as an enumerated list, not a table row). This would be used to recreate a large table without templates, that currently uses a lot of templates and therefore sometimes exceeds WP:PEIS limits.

The Wikipedia:Reliable sources/Perennial sources page contains a large table with a summary of Wikipedia editor opinion about source reliability derived from previous discussions and rfcs at the WP:Reliable sources/Noticeboard. (Example: WP:BALLOTPEDIA ⟶ direct link to the table row.) The Perennnial sources table is at 498 rows and is bumping up against PEIS limits because of numerous templates in each table row, and has exceeded the limit several times. Various stopgaps have been employed to rescue the table from the brink, but it has been clear for some time that a more permanent solution is needed, and this has been under intense discussion for a month at WT:RSP#Addressing hard template limits. We have identified several possible approaches going forward which will end up at an Rfc soon for community feedback, but we need assistance in demonstrating one of them, that we call the "row-builder module approach", and in particular, measuring how well it does with PEIS reduction, so that we can inform participants in an Rfc how many more rows we would likely have room for in the table if that approach were implemented, and therefore how long that approach might be viable.

We could use some assistance from a Lua volunteer to help build this row-builder module. The module would take a dozen or so parameters containing things like: source name (e.g., 'Ballotpedia'), status (nc for 'no consensus'), discussion links, rfc links, a synopsis, and so on, and emit a table row that would render as closely as possible to the way that the current table row renders, only with greatly reduced use of templates, thus significantly lowering WP:PEIS and allowing the table to expand further. (There is also a non-table approach among the options, but that is not relevant here.) The complete Talk page discussion about reducing PEIS is very long, but the part about the row-builder module approach is digestible; some of the earlier comments are out of date from evolution later. Jump down to subsection WP:RSP#Python demo to see where we are now, or run {{RSPTest}} in ExpandTemplates for a mini-demo.

I suspect it would not take a Lua programmer very much effort to create a row-builder module. If you can help out, please let us know, it would be for a good cause! Mathglot (talk) 05:56, 14 October 2025 (UTC)[reply]

To clarify as a participant, IIRC the current plan is for the full module to be invoked like {{RSP row|name=Aaron Is Awesome|alias1=AIA|status=gu|deprecated=y|summary={insert wikitext here}|domain1=example.org|domain2=example.com|discussions=[[link|1]]<br/>[[VGRS link|A]]|last=2018}}, with RSP row as a wrapper template for the module. Aaron Liu (talk) 12:52, 14 October 2025 (UTC)[reply]
Why do that? Why not create a module that reads the data file and spits out an html table? When PEIS is a problem, templates like {{RSP row}} are contributors to that problem.
—Trappist the monk (talk) 13:58, 14 October 2025 (UTC)[reply]
Indeed, it's better just to have the module do Everything. But at the end of the day, PEIS is going to win no matter what. You're going to need to either 1) give up templates or 2) split the page. And giving up templates is only going to take you so far because you will eventually hit max page size. That's the story. Izno (talk) 16:53, 14 October 2025 (UTC)[reply]
The hope is to make editing easier. For example, this would allow editing with VE and associated syntax highlighting of Wikitext.
We could also build a toolforge site interface to edit the data module read from, but at that point I personally would go for the landing pages for each source + toolforge site that coverts them into a table approach instead. Aaron Liu (talk) 18:30, 14 October 2025 (UTC)[reply]
Could someone explain why we have the following messy modules and clarify which are being used?
I am happy to history merge or whatever but this is a bit past the point of reasonable.... Izno (talk) 16:51, 14 October 2025 (UTC)[reply]
Honestly these should've been under Module:Sandbox. Aaron Liu (talk) 18:28, 14 October 2025 (UTC)[reply]
No histmerge needed; what you see at Module:RSPTest (and sandbox) is my first (ever) Lua module, so "messy" is going to be a defining characteristic (except for the bits added by Aidan9382 – thanks!). I had not seen Module:RSP before, but it is by Audiodude who recently joined the effort and has already made major contributions; that module appears to be used in his User:Audiodude/RSP demo, invoking it once per row. I think it's fine that there are competing modules attempting to find the best solution. Neither of them is in use in the live perennial sources table. (As a procedural matter, if Module space isn't the place for an in-progress development please lmk, I can move mine to user space as well; it is however being used at the Talk page WT:RSP as part of the discussion about developing an Rfc about the PEIS issue.)
Regarding the inherent limitations of giving up templates, we are well aware. There is a two-fold involvement of templates in building the Perennial sources table:
The row-builder module approach attacks the first, and the One giant table approach approach attacks the second. I should add that we have tested the latter at WP:RSPGIANT and found that a huge table would still be viable at 94% PEIS with an additional 600 rows. Now we are testing the former, hence this request. (The third approach avoids tables entirely.)
This comment is just by way of a quick intro to what has been going on at WT:RSP#Addressing hard template limits over the last month, and any substantive contributions to the topic should be made there. It is quite long, and I am happy to summarize or answer questions about it here if that would help. For now, the need is most great in the row-builder approach which requires Lua chops, and Aidan has been helping out there. Contributions to the Module, its TP, or at WT:RSP are most welcome. (edit conflict) Mathglot (talk) 19:19, 14 October 2025 (UTC)[reply]
For "I'm testing still and have no idea what I'm doing", Special:Prefixindex/Module:Sandbox/ is the right place. I can say confidently that what currently lives at Module:RSP would normally live there.
As for the other three, it's unusual to sprout two modules at the same time doing the same thing. (And certainly we prefer not to deal with forks generally.) Please figure out which module between the two of you you want to keep "alive" as it were and/or consider merging the other there (and if not, decide which can be a reasonable sandbox and move it to a sandbox of the other). Naming is an issue with the current batch, so whenever you do please rename that one to something that can be understood at a glance.
The alternative is to move those over also to some module sandbox pages as with the currently primary-named module. I would favor that here I think, as it makes it obvious these are experiments with potentially no further use after they're done. Izno (talk) 19:30, 14 October 2025 (UTC)[reply]
Yes I am responsible for Module:RSP and Module:RSP/sandbox. I was not aware of Module:Sandbox and thought that Module:RSP/sandbox was the proper place for experimental code. audiodude (talk) 21:41, 14 October 2025 (UTC)[reply]
Module:RSP/sandbox probably is a reasonable title for a sandbox for Module:RSP. Module:Sandbox is documented as being a namespace for user sandboxes. OTOH, Module:RSP itself is pretty sandboxy and could reasonably go under Module:Sandbox until it's ready to be used in production. Anomie⚔ 22:02, 14 October 2025 (UTC)[reply]
We have a problem to solve with PEIS, and we would keep the one that best helps solve it. Merging would defeat the purpose. Or, we would abandon both of them, if a different approach is chosen. If one of the module approaches does become the solution of choice, then it would become integral to the display of a live Perennial sources table.
Have we exposed what these developing modules are actually doing? This one is not a finished product – and not meant to be; the underlying data file isn't complete, either – but here it is, applied to one of the eight subtables (#5) of the Perennial sources (which happens to start with 'M' sources):
but it's changing all the time. I am fine with moving Module:RSPTest to userspace, some sandbox (of what? Module:Sandbox/sandbox?), or anywhere else if its current location is suboptimal. (edit conflict) Thanks, Mathglot (talk) 22:23, 14 October 2025 (UTC)[reply]
Module:Sandbox/Mathglot/whatever subpage name you want since it's your module user space.
Merging would defeat the purpose. Modules can expose multiple end points for use, which is one way in which they differ from templates. A second way they are different is that they are not penalized for expansion size so long as you keep everything in Lua space (i.e. the output of a module's endpoint is all that matters for PEIS, not how large the module itself is). Module:Perennial sources (which is perhaps the name that I think I favor now, since not all of them are reliable) could expose a function row which does the thing you are looking at and also a whole_table for the thing you're also looking at. (A module that does this in production today is Module:Sidebar, one endpoint for {{sidebar}} and another for {{sidebar with collapsible groups}}.) The only tradeoff with a single module is the potential for edit conflicts, but I expect those would be rare if there are two people working on two separate sets of functionality.
Where you do pay with a module is if you decide to invoke it through a template, i.e. Page uses template row calling Module:Perennial sources.row(), rather than Page calls Module:Perennial sources.row() directly. Izno (talk) 23:31, 14 October 2025 (UTC)[reply]
I agree with this and agree prototyping should be under Module:Sandbox, but I do not understand your last sentence. Aaron Liu (talk) 01:25, 15 October 2025 (UTC)[reply]
I understand it to mean that invoking the module directly (ie., coding {{#invoke: Row-builder |...}}) does not incur a PEIS cost, but invoking the module via a template (i.e., coding {{Row builder|...}}, where {{Row builder}} contains the line {{#invoke: Row-builder |...}}) does incur a PEIS cost. Mathglot (talk) 03:50, 15 October 2025 (UTC)[reply]
Ish. You still have a PEIS cost either way, but going through the template hits this known cost. Izno (talk) 03:57, 15 October 2025 (UTC)[reply]
Whew; thanks for that. There are more subtle twists and turns involved with PEIS than I knew about. All the more reason to have a test module to get some RW data rather than trying to guess at it. Mathglot (talk)
Ultimately, there's a maximum page size, regardless if the bytes are written out manually or created by a template or module. As the generated text from Lua modules is not parsed further to expand templates, the byte count contributed by the module towards the maximum page size is the same as the actual number of bytes produced, as I understand it. So if you can define the intended (template-less) output, you can count the bytes to determine the effect regarding page size, without writing the code. (Of course, to get an idea of performance, a prototype of some sort would be needed.) isaacl (talk) 05:57, 15 October 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Lua&oldid=1316913613"