Wikipedia talk:Lua

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:Lua requests)
Jump to navigation Jump to search
Project talk
 To do
en: m: mw: external

Improving Template:Code[edit]

I'm wondering if it's feasible to re-do {{code}}, a wrapper for <syntaxhighlight>, in such a way that some parameter, perhaps |filter=y, could pre-filter and convert some of the input before it reaches the underlying <syntaxhighlight> process. [Inserting a code snippet for example purposes below: <span>.]

  • The issue: Sometimes it is not desirable to feed this template something literal. E.g., if you do {{code|lang=html|1=<span style="color: purple;">}} (without the closing tag for the span), then anyone using the edit-mode wikimarkup syntax highlighter by Remember_the_dot, available at Special:Preferences#mw-prefsection-gadgets and thus our most frequently used highlighter, will have their syntax highlighting in the editing window boogered by what Remember_the_dot's syntax highlighter sees as a real open and not-yet-closed <span> rather than as template content. [If you use that highlighter, and are reading this in edit mode, you should see this effect now, caused by the snippet I inserted before this bullet list. Most of my entire post should have a pink background as unclosed code content when it really is not.]
    • And one cannot escape this with &lt; to encode the exmaple span's leading < symbol; all input received by <syntaxhighlight> is treated as a literal.
    • This also makes it impossible to do something like {{code|lang=html|1=<span '''style'''="color: purple;">}} to emphasize something in the markup.
  • The idea: Use Lua and a table of entities and of select wikimarkup to pre-filter (and possibly post-filter) the content before (and maybe after) it hits <syntaxhighlight>:
    • Pre-filter so that things like < can be escaped in the visible wikitext with &lt;, converted to <, then passed to the parser function.
    • Possibly also tokenize a few things like ''...'' and '''...''' markup so they can be operated on after the fact:
    • Post-filter to de-tokenize those bits and actually perform their intent. Ideally this would also include <var>...</var> so that variables within code can be marked up as such (lack of ability to do that is a serious flaw in <syntaxhighlight>).

 — SMcCandlish ¢ 😼  22:12, 1 August 2018 (UTC)

@SMcCandlish: Unfortunately, post-filtering is impossible as the output from <syntaxhighlight> is not exposed to lua other than as an opaque strip marker. Pre-filtering could be done trivially using Module:String and/or Module:MultiReplace without creating a new lua module. {{3x|p}}ery (talk) 11:31, 18 September 2018 (UTC)
Correction: Post-filtering is not technically impossible, only impossible to do without relying heavily on undocumented implementation details of the SyntaxHighlight extension, which seems like it's not a good idea to do for such a heavily used template. {{3x|p}}ery (talk) 22:22, 18 September 2018 (UTC)
I should have known better than to call something impossible. {{3x|p}}ery (talk) 22:25, 18 September 2018 (UTC)
@Pppery: Well, what I suggested was that "some parameter, perhaps |filter=y, could pre-filter", so it sounds like you're telling me that the problem I'm reporting is in fact easily fixable.  — SMcCandlish ¢ 😼  11:10, 8 November 2018 (UTC)


I'm trying to understand Module:Infobox and see if the code there allows another infobox module to send it values and for it to return the required sub-infobox, but since it lacks in documentation, I can't seem to figure this out (it seems me that it doesn't support what I want). What I'm looking for is something similar to what has with fr:Module: Infobox. If anyone can help me figure this out, would really appreciate this. --Gonnym (talk) 13:04, 23 October 2018 (UTC)

Are you talking about embedding one infobox inside another?
Trappist the monk (talk) 13:12, 23 October 2018 (UTC)
No. What I'm trying to do (which is available in the french version) is to create a very small infobox module (in terms of code) which only lists the parameters it gets from a user (fr:Module:Infobox/Tapis persan), which then sends it to the main module (Module:Infobox), which it is responsible for actually building it. Basically eliminating all the code currently in the infobox templates. --Gonnym (talk) 13:19, 23 October 2018 (UTC)
As we currently have far more active editors familiar with template syntax than with Lua code, is it a good idea at present to shift so much of the development and maintenance of infoboxes onto a much smaller group? --RexxS (talk) 13:59, 23 October 2018 (UTC)
That is neither my call nor my intention, but I also don't believe that not testing better options just because not enough people can add to it, is correct either. Also, the french example I've linked to seems much easier to code than any infobox I've seen, including the need to keep that awful numbering system which forces you to change so many lines, if you need to add a new row somewhere at the top. --Gonnym (talk) 14:13, 23 October 2018 (UTC)
You may find User:Frietjes/infoboxgap.js useful in dealing with that awful numbering system. --RexxS (talk) 14:39, 23 October 2018 (UTC)
@Gonnym: As far as I'm aware the module is currently inaccessible from other Lua modules (the p.infobox function only accepts values from a frame object), although Mr. Stradivarius might be able to say otherwise. You might want to fiddle a bit with the p.infobox function in a sandbox to see how it'll let you input data from another module.
Parts of enwiki also have a weird thing for discouraging any more Lua modules than absolutely necessary because most editors can only read wikicode and therefore can't debug modules, although I do think the frwiki approach would have benefits for some templates like {{Singles}} (which already uses its own Lua module). Jc86035 (talk) 15:21, 24 October 2018 (UTC)
@Jc86035: I don't believe it will let me, but no harm in playing a bit with it. Also, I don't understand how anyone can read this code Template:Infobox album (the part before the actual start of the infobox code) and even more think that it's easier to read than Lua. --Gonnym (talk) 18:10, 24 October 2018 (UTC)
@Gonnym: My fault, because I wrote that part of the template. Most of the reason it's so complicated is because I was trying to replace and format about seven different templates' parameters by allowing their replacement through template substitution (example) and for some reason I thought it would be a good idea to do the formatting with parser functions and Module:String. If you take out the part between |prev_title= and |$flags=override (the part that formats the parameters) then it starts to look a little more like it was written by a normal sensible person. Jc86035 (talk) 18:18, 24 October 2018 (UTC)

───────────────────────── It's generally not too difficult to make Scribunto functions available to other modules. If you want to make p.somefunc(frame) available in a simple form, you can check what is used from the frame object, say frame.args.param1 and frame.args.param2, then amend the function definition be to something like function p._somefunc(param1, param2), and use param1 and param2 in place of frame.args.param1 and frame.args.param2 within the function. Finally write

function p.somefunct(frame)
    return p._somefunc(frame.args.param1, frame.args.param2)

to recreate the function that uses the frame object for use with #invoke. The _somefunc(param1, param2) will be available from require("Modulename")

There are alternative ways, for example passing a single table of parameters instead of each one individually (useful when there are lots of parameters), but the general principle is the same. --RexxS (talk) 22:05, 24 October 2018 (UTC)

Yes, that will work with a bit of moving around the meat of that function into the _function, but from what I can tell from the code, the infobox is eventually still waiting for values in the form of how an infobox template keeps them, and not in an easy to code FR style. --Gonnym (talk) 22:19, 24 October 2018 (UTC)

Navbox with collapsible groups[edit]

can someone help me debug Module:Navbox with collapsible groups which is being called through Template:Navbox with collapsible groups/sandbox? in particular, see Template:Navbox with collapsible groups/testcases. for debugging, I have appended the values of the 'sargs' which are used to build the subgroups, and I appended the values of 'targs' which is passed through Navbox._navbox to build the final result. the values for the sargs and the targs look great, but the actual navbox output has the academics group repeated 4 times :( I have never seen this pathology before. thank you! Frietjes (talk) 16:27, 24 October 2018 (UTC)

update, this edit appears to fix the problem. so, going through the template interface for the child boxes, instead of going through the module interface. I think it would be better to go through the module interface, and I have no idea why that doesn't work. Frietjes (talk) 21:05, 24 October 2018 (UTC)
I started looking at this but then I saw you were still working on it. Please post again if there is something specific I could look at. Johnuniq (talk) 04:15, 25 October 2018 (UTC)
Johnuniq, I found the problem in Module:Navbox, listnums was being initialized globally, but not emptied at the top of _navbox(), so each time you call the _navbox() it just appends more lists to listnums. it looks like this fixes the problem. I don't see any other entry points into the module, other than p.navbox(frame) and p._navbox(navboxArgs) so it looks like it is safe to initialize listnums at the top of p._navbox(navboxArgs) instead. Frietjes (talk) 13:20, 25 October 2018 (UTC)
That looks good. I vaguely remember some oddities about the module from the time I jumped into it. I would prefer to get rid of those effectively global variables at the top of the module but the refactoring effort might not be worth it. Johnuniq (talk) 09:33, 26 October 2018 (UTC)

teach Module:Graph some new tricks[edit]

background (long story - safe to skip): back in 2013, i created Module:Chart, to display bar and pie charts.

my motivation was mainly to make adding charts easier: the various charting templates that existed were limited (e.g., pie chart had max of 6 slices), none support "stacked" bar charts, and more importantly, they all used cumbersome (IMO) and inconvenient way of passing parameters: instead of, e.g., delimited list of numbers for each series, you had to pass a separate parameter for each data point, with different convention for each template. (there's a whole slew of other charts, using the "timeline" extension - those are even more difficult to use, and produce ugly charts, IMO).

(irrelevant, but interesting tidbit): this module uses an arcane and esoteric feature of html to display pie charts (which i copied from the brilliant template that already existed), exploiting the "border" element, giving it width and colors, and using the fact that 2 sides of html "border" are connected with a "bevel": by separately controlling the width of each side, you control the angle of the bevel, then you color one of the sides with he desired color, leave the other transparent, repeat for each segment of the pie, stacked on top of each other, do it separately for each of the 4 quarters of the axis system, and finish it all by covering the whole jumble with a circle, having transparent interior and white exterior. bizarre to the point perversion, and at the same time brilliant. the most amazing thing about it is the fact that it actually works...

relevant part

anywhoo, several years later, the "graph" extension was introduced (mw:Extension:Graph), and some time later, User:Mps created Module:Graph (maybe elsewhere (dewiki?), and imported to enwiki - not sure). some time after that, Template:Graph:Chart was created. at this point, my 2013 "chart" module became obsolete, but people are still using it.

so here is (finally) my actual request: there are some legit requests on Module talk:Chart, to which i usually respond "you should use the new stuff". the latest such request, asked for horizontal bar chart, which neither module supports. i have no doubt the "graph" extension can easily do it, but unfortunately, Module:Graph does not provide horizontal bar charts. can someone pick the challenge, and teach this module to draw horizontal bar charts? and, maybe, while you are at it, also teach it to do scatter chart?

peace - קיפודנחש (aka kipod) (talk) 16:55, 25 October 2018 (UTC)

Module error on Syrian Civil War map[edit]

I've noted what seems to be a strange bug on the module maps at Talk:Cities and towns during the Syrian Civil War#Some sort of module error causing extra marks. If someone who has more experience with module programming and such could take a look, that'd be great. (This was originally posted on VPT, but someone pointed out in an unrelated section that this is usually where Module questions are asked.) Thanks, ansh666 21:22, 4 November 2018 (UTC)

The above was posted at 00:45, 6 November 2018 and it looks as if the issue has been resolved according to the latest at the above talk link. Johnuniq (talk) 02:43, 6 November 2018 (UTC)

How do you look up which pages are directly calling given module?[edit]

I am looking for ways of tracking which pages directly call some module, in case I am altering the module interface. For example I have some Module:X intended to be accessed through Template:X and I would like to check if any other templates, modules or other pages call it. Special:WhatLinksHere with namespace filter is great but it is swamped by 'indirect calls through template. One can compare Special:WhatLinksHere for Module:X and Template:X and look for the differences, but that also mostly has pages which are there for unexplained reason. I only want to find pages with "{{#invoke:X|Y" so maybe I should write SQL query to look for that in page text? Or is there an easier way? --Jarekt (talk) 17:39, 7 November 2018 (UTC)

Enter insource:"invoke:X" in the search box. Click "Everything" to find results in all namespaces. PrimeHunter (talk) 17:52, 7 November 2018 (UTC)
(edit conflict) @Jarekt: If I go to Special:Search, then pick the namespaces and search for something like insource:/invoke:\s*WikidataIB/, I can find the pages that invoke WikidataIB. You'll probably be able to adapt that for what you need. Cheers --RexxS (talk) 18:04, 7 November 2018 (UTC)
insource:/.../ is an expensive regex search which shouldn't be used alone per mw:Help:CirrusSearch#Insource. A normal insource: search works fine here unless the module name often occurs after the word "invoke" in normal English text. PrimeHunter (talk) 18:16, 7 November 2018 (UTC)
As you don't know whether there are space characters between "invoke:" and the module name, your search will miss those. You need a regex to find all of them in one search. As usual, the documentation on mediawiki is a long way from realistic, and these sort of simple searches execute rapidly without problems.
If you feel you have to use a search domain to use the regex on, then something like insource:"WikidataIB" insource:/invoke:\s*WikidataIB/ will do the job almost instantly. --RexxS (talk) 19:11, 7 November 2018 (UTC)
I prefer to limit it to "hastemplate:"Module:X" insource:/invoke:\s*X/". --Izno (talk) 19:13, 7 November 2018 (UTC)
insource:"invoke:X" also finds cases with spaces and it's simple. PrimeHunter (talk) 00:21, 8 November 2018 (UTC)
You're absolutely right and I was wrong: your search works. The colon character is treated as greyspace, so of course it will also match invoke X, etc. But as you say, that's almost certainly not going to be a common expression in prose (unless you write a module called "BRD"). Cheers --RexxS (talk) 01:40, 8 November 2018 (UTC)

Thanks all for your help! --Jarekt (talk) 19:27, 7 November 2018 (UTC)

Knowing if being called from a disambiguation page[edit]

If a template/module needs to know if it is being invoked from a disambiguation page (without user input), is searching the page for the {{Disambiguation}} template (and redirects) the way to go, or is there another way? --Gonnym (talk) 23:54, 7 November 2018 (UTC)

It's pretty ugly, but searching the page content is all that's possible, I think. That's what I did at c:Module:Countries in function getRedirectTarget. It seems to be pretty fast. It was pointed out to me that I missed a few infrequently used redirects/templates but I thought targeting the main ones was good enough. Johnuniq (talk) 00:09, 8 November 2018 (UTC)
Thanks for the answer and for the code reference! --Gonnym (talk) 12:12, 8 November 2018 (UTC)
Doesn't mw.title.getCurrentTitle().isRedirect give you that answer?
Trappist the monk (talk) 13:05, 8 November 2018 (UTC)
Tested it out and no. It makes sense as redirect is not the same as disambiguation I guess. --Gonnym (talk) 13:33, 8 November 2018 (UTC)
Doh! brain fart. nevermind.
Trappist the monk (talk) 14:06, 8 November 2018 (UTC)
Wikipedia does know which pages are disambiguation pages though. It doesn't look like there is a method exposed in the Lua api but that would be a pretty reasonable request for Phabricator. --Izno (talk) 17:38, 8 November 2018 (UTC)

How can one track module dependencies[edit]

I am wandering is there some way of tracking module dependencies. Let me give an example, on commons we have c:Module:Fallback which according to Special:MostTranscludedPages is used on 44M pages, including many other modules like my c:Module:Artwork or RexxS' c:Module:WikidataIB. c:Module:Fallback implements mostly retired language fallback mechanism and should not be part of many of other Modules, so I am curious how those dependencies sneak in. Is there some tool or approach to track it down? --Jarekt (talk) 21:40, 8 November 2018 (UTC)

You might try this kind of search in the module namespace:
insource:/require *\( *["']module:fallback["']/i[1]
Trappist the monk (talk) 12:32, 9 November 2018 (UTC)
@Jarekt: Following up from PrimeHunter's tip above, searching for insource:"require module fallback" finds them plus a couple of extras like module:fallback/sandbox. There are few enough of those to manually pick the ones that interest you. --RexxS (talk) 13:37, 9 November 2018 (UTC)
c:Module:Fallback is used by couple abandon and unused modules and by subtemplates of c:Module:Wikidata (used on 2M pages), so 44M uses is a mistery as I can not find templates that use it either. --Jarekt (talk) 03:58, 18 November 2018 (UTC)

Validating date parameter is in a Template:Start date[edit]

I have a template which the documentation asks for the date parameter to be in a {{Start date}} template. The template code is in the template namespace and is not a module. I'm trying to add a tracking cat to it in the situations where the date is not in that format. I've tried using {{Str sub find}} and also invoking String.find directly, but can't get this to work. This fails either because of the "|" character, which I can escape in the static target value with {{!}}, but I'm not sure how to handle the user-entered value; or it fails because of the template itself. Alternatively, if there is a better option, I'm open to that as well.

Example code:

  • {{#if: {{str sub find|1={{start date|1993|02|24}}|2={{start date|}} }} | Substring is found | Substring is not found }} -> Substring is not found --Gonnym (talk) 10:34, 12 November 2018 (UTC)
I don't know if this would help (I have not investigated your issue), but {{extract}} can parse dates. Problem: It checks the date for validity and people often make mistakes such as 31 April so the result might cause clutter.
  • {{extract|show=format}} → error
  • {{extract|2001|2|28|show=format}} → dmy
  • {{extract|Feb 28, 2001|show=format}} → mdy
  • {{extract|2001|2|29|show=format}} → error
Johnuniq (talk) 22:10, 12 November 2018 (UTC)
This might work, but I'm running into issues with it:
  • {{start date|1993|02|24}} → February 24, 1993 (1993-02-24)
  • {{extract|1993|02|24|show=mdy}} → February 24, 1993
  • {{extract|{{start date|1993|02|24}}|show=mdy}} → Error: Need valid date
Any idea? This might be because {{Start date}} "also includes duplicate, machine-readable date (or date-time) in the ISO date format (which is hidden by CSS), for use inside other templates (or table rows) which emit microformats". --Gonnym (talk) 12:18, 13 November 2018 (UTC)
Also, I'm not sure this would really solve my issue, as it will accept correctly formatted dates, but not those using the template, which is a requirement. --Gonnym (talk) 12:22, 13 November 2018 (UTC)
Your problem rests on the fact that the parser will expand the template {{Start date}} before passing its value to your template. Perhaps something like this will be usable:
  • {{Posnq | {{start date|2018|November|30}} | bday dtstart published updated }} → 75
  • {{Posnq | 30 November 2018 | bday dtstart published updated }}
  • {{Posnq | {{start date|2018|November|31}} | bday dtstart published updated }} → 75
  • {{Posnq | 31 November 2018 | bday dtstart published updated }}
That accepts invalid dates as well, but still discriminates between having a template that has those microformats and one that doesn't. Obviously, you pass {{{date|}}} as the first parameter. --RexxS (talk) 14:24, 13 November 2018 (UTC)
Just to help check: Let's say you were looking for the parameter |airdate= in Template:Infobox television episode. You could search all articles on:
  • insource:"Infobox television episode" insource:"airdate" to find 9,240 occurrences; then on:
  • insource:"Infobox television episode" insource:"airdate" insource:/| *airdate *= *\{\{[Ss]tart date/ to find 3,775 that have the {{start date}} template; and on:
  • insource:"Infobox television episode" insource:"airdate" insource:/| *airdate *= *[^{ ]/ to find 5,674 that don't have a template.
  • insource:"Infobox television episode" insource:"airdate" insource:/| *airdate *= *[1-9A-Za-z]/ shows 5,648 articles. --RexxS (talk) 16:14, 13 November 2018 (UTC)
I always like to point out that insource:"name of template" is more fragile compared to hastemplate:"Infobox television episode", which catches all transclusions (some 120 through pass-through templates in this case). (I think I did that recently with you--just a friendly reminder.) It's also less expensive for the search in the event you have multiple templates with a single core template (as with the citation module for example). (I think it's marginally less expensive than an insource search even without regex but I could be wrong about that.) --Izno (talk) 17:18, 13 November 2018 (UTC)
Thanks for the reminder, Izno. I never spend enough time optimising searches and suchlike, and I'd be astonished if hastemplate: wasn't more efficient and less expensive than insource: when looking for templates. Cheers, --RexxS (talk) 23:07, 13 November 2018 (UTC)

@RexxS: - I've used your code and it works and I've also found another template that does it. However, {{posnq}} will fail if any text is placed before {{Start date}} (which technically is good, but not the way I'd like to catch "abnormal" additions, as that will include other cases) so hard-codding the result to "75" is a bit fragile here.

  • {{str find0}}: {{#ifexpr: {{str find0| {{start date|1993|02|24}} | dtstart }} != -1 | Substring is found | Substring is not found }} → Substring is found
  • {{str find0}}: {{#ifexpr: {{str find0| First released: {{start date|1993|02|24}} | dtstart }} != -1 | Substring is found | Substring is not found }} → Substring is found
  • {{posnq}} ok: {{#ifexpr: {{Posnq| {{start date|1993|02|24}} | bday dtstart published updated }} = 75 | Substring is found | Substring is not found }} → Substring is found
  • {{posnq}} fail: {{#ifexpr: {{Posnq| First released: {{start date|1993|02|24}} | bday dtstart published updated }} = 75 | Substring is found | Substring is not found }} → Substring is not found

I'm pretty sure if the template was in lua, this whole process would have been easier and cleaner. --Gonnym (talk) 10:29, 14 November 2018 (UTC)

@Gonnym: Template:Posnq is designed to return nothing if no match is found, so you only need to use an #if to test (since #if treats nothing as false and anything else as true):
  • {{#if: {{Posnq | {{start date|1993|02|24}} | bday dtstart published updated }} | | [[:Category:Parameter not using Start date template]] }}
  • {{#if: {{Posnq | 24 February 1993 | bday dtstart published updated }} | | [[:Category:Parameter not using Start date template]] }}Category:Parameter not using Start date template
All you need to do is add:
  • {{#if: {{Posnq | {{{airdate|}}} | bday dtstart published updated }} | | [[Category:Parameter not using Start date template]] }}
to the template in its tracking category section. --RexxS (talk) 14:40, 14 November 2018 (UTC)
Thanks RexxS, works great! --Gonnym (talk) 10:48, 18 November 2018 (UTC)

Lua "Beta" template[edit]

What is the template to say in Lua documentation: "This module is beta status/quality"? (alpha, etc). -DePiep (talk) 12:35, 17 November 2018 (UTC)

Found: {{Module rating}} - DePiep (talk) 12:41, 17 November 2018 (UTC)

Mystery script errors on Wikidata[edit]

Wikidata has 4K pages with d:Category:Pages_with_script_errors. Pages like d:Talk:Q100 where I can see the error details in html ( in <script> but not on the page itself. How do we debug such cases? --Jarekt (talk) 04:09, 18 November 2018 (UTC)

That is a really weird one. The error (translated from the HTML source) is:
Lua error: bad argument #1 to 'getAllStatements' (string expected, got nil).
in function "error"
libraryUtil.lua:11: in function "checkType"
mw.wikibase.lua:151: ?
(tail call): ?
Module:Wikidata:581: in function "getClaims"
Module:Wikidata/utils:44: ?
(tail call): ?
mw.lua:511: ?
Something is going wrong during the expansion of {{Item documentation}}. Interestingly, editing d:Talk:Q100 shows its contents is {{Item documentation}} and previewing the edit (without changing anything) shows d:Category:Pages with script errors at the bottom. However, replacing the contents with {{Item documentation|Q100}} and previewing shows there is no error category. Near the bottom of the preview page is "Lua logs" with some mumbo jumbo that I suspect is internal to mw.wikibase although I can't find it. Previewing {{Item documentation|Q5}} shows a much longer log corresponding to the longer tree of "parent classes". The "1>=10" stuff might be a log of a binary search? Or a sort? I don't have time to look more at the moment. If someone doesn't crack it soon, a developer might be needed. Johnuniq (talk) 06:44, 18 November 2018 (UTC)
Hmm. I put a temporary test in d:Module:Wikidata (preview only) and confirmed that everything works at line 581 which is the fail point in the error above. That is, entity and property are always strings. That makes me think that a developer is needed. Johnuniq (talk) 06:55, 18 November 2018 (UTC)
@Jarekt: I think I fixed the problem with an edit at d:Template:Item documentation. Try refreshing or purging affected pages and the errors might go away. Johnuniq (talk) 10:10, 18 November 2018 (UTC)
Johnuniq Thanks a lot for looking into it. I spent a while scrathing my head trying to figure it out. The number of pages in d:Category:Pages with script errors is now 448, down from 4k. So your elagant fix of the template worked. --Jarekt (talk) 02:54, 19 November 2018 (UTC)

Module request[edit]

I request that the code at Module:Sandbox/BrandonXLF/2 should be moved to Module:Module link. The purpose of this module is to create modules links. It is planned to be used on {{ml}}, {{mli}}, {{mlix}} and {{mlx}}. The advantage of the module is the error message (can be helpful) and it let's you use as many parameters are you need. BrandonXLF (t@lk) 18:36, 25 November 2018 (UTC)

@BrandonXLF:  Done, although to my knowledge you should have been able to do this yourself (bar some technical error). Jc86035 (talk) 16:21, 5 December 2018 (UTC)

Ordinal numbers[edit]

Hi. I want to add a function to the Dates module on Azerbaijani Wikipedia to create categories automatically. They are mandatory because of the Azerbaijani grammar. Formula will be year+ordinal number suffix, the word "ildə" which means "in year" and the rest will be dependents.

The ordinal suffixes are, 0-cı (not mandatory), 1-ci, 2-ci, 3-cü, 4-cü, 5-ci, 6-cı, 7-ci, 8-ci, 9-cu, 10-cu (the last digits are repeated), 20-ci, 30-cu, 40-cı, 50-ci, 60-cı, 70-ci, 80-ci, 90-cı, 100-cü... (hundreds are -cü), 1000-ci (thousands are -ci).

For the catogories they would be like Category:2018-ci ildə vəfat edənlər, Category:1976-cı ildə vəfat edənlər, Category:1900-cü ildə yarananlar.

Please help if interested. Thank you!--Toghrul Rahimli (talk) 11:21, 5 December 2018 (UTC)

@Toghrul Rahimli: If I've understood properly, here are some tests using Module:Sandbox/RexxS/Ordinal:
  • 1000-ci
  • 1900-cü
  • 1910-cu
  • 1920-ci
  • 1930-cu
  • 1940-cı
  • 1950-ci
  • 1960-cı
  • 1970-ci
  • 1980-ci
  • 1990-cı
  • 1991-ci
  • 1992-ci
  • 1993-cü
  • 1994-cü
  • 1995-ci
  • 1996-cı
  • 1997-ci
  • 1998-ci
  • 1999-cu
  • 2000-ci
Are those correct? You can use the local function in your own module. Obviously you can add on "Category:", " ildə", and the rest of the wording as needed. --RexxS (talk) 15:26, 5 December 2018 (UTC)

@RexxS: this was the exact function i tried to create, but failed obviously. I tested a lot of different numbers, it works how it should. Thank you for sparing your time and helping!--Toghrul Rahimli (talk) 17:05, 5 December 2018 (UTC)

@RexxS: excuse me, i faced a little bit of a trouble. Could you help me? I want to integrate inYear parameter to the ordinal one.

function inYear( year )
    if ( year >= 0 ) then
        return '' .. year .. ''
        return '' .. ( 0 - year) .. 'e.ə.'

Categories part:

    if categoryNamePrefix then
        if ( nd ~= nil and nm ~= nil) then
            datePart = datePart .. '[[Kateqoriya:' .. nd .. ' ' .. genitivusMonthes2[nm] .. ' ' .. categoryNamePrefix .. ']]'
        if ( ny ~= nil) then
            datePart = datePart .. '[[Kateqoriya:' .. inYear( ny ) .. ' ildə ' .. categoryNamePrefix .. ']]'

The result is obvious, 2018 ildə vəfat edənlər. Or i would be happy if you took a look at the module, and an example of an article is Corc Herbert Uoker Buş and the module is Dates.

@Toghrul Rahimli: I'm sorry, but I don't understand enough about how the Azerbaijani language works to see what is wrong with Corc Herbert Uoker Buş. Can you explain in simple terms what output you need and what output you are getting? --RexxS (talk) 01:04, 7 December 2018 (UTC)
@RexxS: The problem is the category. I implemented wikidata on the templates, and trying to adapt modules to our language. On the article you will see the red categories, they are not how they should be. For example, it shouldn't be 1924 ildə doğulanlar, it should be 1924-cü ildə doğulanlar which means people born in 1924. You created the algorithm for the suffixes. The main purpose of that was to implement them into categories, but i failed. This is the string in which the ordinal system will be implemented:
            datePart = datePart .. '[[Kateqoriya:' .. inYear( ny ) .. ' ildə ' .. categoryNamePrefix .. ']]'

By the way, b.e.ə means means BC, which is shown in the module. Cheers!--Toghrul Rahimli (talk) 05:39, 7 December 2018 (UTC)

@Toghrul Rahimli: I've amended az:Module:Dates so that it returns the ordinal instead of the cardinal for the year in the InYear function, but I don't see any change on az:Corc Herbert Uoker Buş. That might be a caching issue, so I looked at some others: az:Mustafa Kamal Atatürk and az:Əli Xamenei both seem to have correct categories, but my translation skills are not sufficient to get much further. Could you look at some articles that you know use the Dates module and see if they are right now, please? P.S. I'm not sure I have put the "b.e.ə" in the right place, could you check that as well, please? Cheers --RexxS (talk) 16:43, 7 December 2018 (UTC)
@RexxS: thank you for your edit on the module. The categories in some other articles are correct, because they are not added by the module, but a template. For example, if you remove
{{doğum tarixi və yaşı|1939|7|17}}
(which means date of birth and age), you will see the data will be filled by wikidata, and its category will be shown incorrectly (the year one). It means, the problem directly comes from the last string which is highlighted in my previous reply. if Kateqoriya: .. inYear( ny ) .. ildə .. categoryNamePrefix .. would be changed into a correct one, they will work perfectly. Cheers!--Toghrul Rahimli (talk) 06:32, 8 December 2018 (UTC)
@Toghrul Rahimli: The problem was that the function inYear() needed to be local to the Module:Dates, otherwise somewhere else another version of the function was being used which only returned the year. I've fixed that and now it's correctly using the ordinal function and the categories on az:Corc Herbert Uoker Buş are blue-linked. Would you check some other articles to make sure it's working properly, please? It especially needs to check someone with a date "b.e.ə" so that we know it's in the right place. Cheers --RexxS (talk) 12:29, 8 December 2018 (UTC)
@RexxS: I checked it, it's working how it should be now. Made a minor edit for e.ə so this is correct now. Thank you for your help, it contributed to Azwiki a lot. Cheers!--Toghrul Rahimli (talk) 13:03, 8 December 2018 (UTC)
nitpick: in the code
local function ordinal(number)
	local suffix
	if number % 1000 == 0 then
		suffix = "ci"
	elseif number %100 == 0 then
		suffix = "cü"
	elseif number %10 == 0 then
		local rem = number % 100
		suffix = suffixes[rem]
	if not suffix then
		rem = number %10
		suffix = suffixes[rem]
	return number .. "-" .. suffix
note that the scope of "local rem" does not span all the way to its 2nd appearance (so it becomes global at this point). personally, i prefer the and/or logic when writing lua, like so - i find it more readable. not everyone agrees...
local function ordinal(number)
	local suffix =
	    number % 1000 == 0 and "ci"
	    or number %100 == 0 and "cü"
	    or number %10 == 0  and suffixes[number % 100] -- the condition number %10 == 0 is not really needed, but is left for clarity
	    or suffixes[number % 10]
	    or '' -- safety. should never happen
	return number .. "-" .. suffix
peace - קיפודנחש (aka kipod) (talk) 21:50, 11 December 2018 (UTC)
Thanks for spotting the scope problem with the second rem. Had I taken the time, I would have simplified to:
local function ordinal(number)
	local suffix
	if number % 1000 == 0 then
		suffix = "ci"
	elseif number %100 == 0 then
		suffix = "cü"
	elseif number %10 == 0 then
		suffix = suffixes[number % 100]
		suffix = suffixes[number %10] or ""
	return number .. "-" .. suffix
While we're nit-picking, I think you'll find that the condition number %10 == 0 actually is necessary, otherwise 1910, 1920, 1930, etc. would all have the same suffix, which is incorrect. Cheers --RexxS (talk) 01:44, 12 December 2018 (UTC)
i don't see it. for 1910, mod 100 will return 10, and for 1930 it will be 30, which are different entries in the table. for 1934, mod 100 returns 34, which is nil, equivalent to false, in the table, so the boolean shortcut falls through to the mod 10 line, even without the "%10==0" condition. peace - קיפודנחש (aka kipod) (talk) 06:57, 13 December 2018 (UTC)
Yes, you're right! I misinterpreted what you meant, assuming you were implying that the whole line or number %10 == 0 and suffixes[number % 100] was redundant. I can see you were saying one could replace that line with just or suffixes[number % 100]. Cheers --RexxS (talk) 00:31, 14 December 2018 (UTC)
@RexxS: i simplified the code base on your last syntaxhighlight. The only thing left is the 0. It has to take -cı suffix, but the code returns -ci. For example, i applied the code to a year navigation template on AzWiki. See az:1 to see what i mean. Cheers!--Toghrul Rahimli (talk) 10:36, 17 December 2018 (UTC)
@Toghrul Rahimli: I'm not sure what the case is, because there was no year 0, but if you have a need for it, here is the revised code to take care of the year 0:
local function ordinal(number)
	local suffix
	if number == 0 then
		suffix = "cı"
	elseif number % 1000 == 0 then
		suffix = "ci"
	elseif number %100 == 0 then
		suffix = "cü"
	elseif number %10 == 0 then
		suffix = suffixes[number % 100]
		suffix = suffixes[number %10] or ""
	return number .. "-" .. suffix
So we get:
  • 0-cı
Will that fix it for you? --RexxS (talk) 16:33, 17 December 2018 (UTC)
@RexxS: i actually use the module seperately. The 0 works fine now. Thanks once again!--Toghrul Rahimli (talk) 17:48, 17 December 2018 (UTC)

List of parameters as one parameter[edit]

I have a general design/coding question which I hope someone here could shed some light on. I've seen several table modules which work in the style of 1 module for the table-header and 1 module for the table-rows with corresponding templates. I was wondering, is there a way for a template to accept a list of parameters as one parameter? So for example, instead of calling the table-row template for each row and passing it the parameters |a=, |b= and |c=, have a |row= parameter that gets the row parameters |a=, |b= and |c=? --Gonnym (talk) 08:05, 13 December 2018 (UTC)

It's not possible to do exactly what you suggest—you can't bundle parameters a=one, b=two, c=three together except by a redesign. I rewrote {{Football manager history}} because it used separate templates for the header, footer, and each row with the result that the crazy navboxes seen, for example here generated more than 2 megabytes of "Post‐expand include size". The template now calls Module:Football manager history to do all the work. The module has to parse each row to extract the implied row parameters. That can be messy and fragile although it has worked well in this reasonably simple case. Another example of a module doing a bunch of work to parse data is Module:Val/units which uses a giant text string to define required units, one per line, rather than a traditional Lua table. It turns out that parsing a giant string can be more efficient than using nested tables, and can be easier for editing the wikitext which was the motivation for Val. If you have a specific example I'll have a look. Johnuniq (talk) 08:44, 13 December 2018 (UTC)
Gonnym, Template:Routemap uses a similar approach, and Module:TemplatePar sends in the entire list of parameters as an "=" delimited list. so, it really depends on what you know about the values of |a=, |b= and |c=. for example, if you know they will never contain a "/" then you could use that as a delimiter, for example see Module:Sports rbr table. Frietjes (talk) 12:24, 13 December 2018 (UTC)
Module:Chart uses similar approach, passing multiple values as delimited list. by default the delimiter is colon, ":", but the module allows using any other delimiter, including "=", by supplying a "delimiter" parameter (this is so, in case someone needs to us the colon as part of one of the values). to use =, one would have to call the module with | delimiter = = |. personally, since mw introduced JSON parser, i find it more beneficial to bundle everything in a single json string and pass it as is. the module can then call something like local paramTable = mw.text.jsonDecode(args['your param name']). peace - קיפודנחש (aka kipod) (talk) 23:35, 27 December 2018 (UTC)

New parameter for Module:Article history[edit]

I proposed adding a parameter to Template:Article history (which merely invokes Module:Article history). There was no support or opposition to it after the requisite amount of time, and it was a relatively minor edit, so I would have gone ahead and implemented it myself. However, I do not know Lua. Could someone who does assist with this task (described at the template's talk page), which involves: (1) creating a new parameter and (2) tweaking the target of one of the wikilinks displayed by the template? Thanks in advance. Ergo Sum 02:53, 14 December 2018 (UTC)

Requested move 16 December 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: Moved all except RexxS: Pppery: I cannot use pageswap.js nor perform a manual round-robin move on this particular one because of technical restrictions owing to the fact the page already exists and is in the Module namespace. However, as consensus has been determined, please feel free to submit a technical request for the remaining one and somebody with a higher power level can come along and do it. (closed by non-admin page mover) SITH (talk) 02:03, 27 December 2018 (UTC)

– Centralize personal lua modules under Module:Sandbox {{3x|p}}ery (talk) 23:27, 16 December 2018 (UTC)

(Module:Sandbox/Angr pukhlya and Module:Sandbox/Shah Jahan Ishaq already exist, so the modules that I would otherwise move there are given a ? target. ) {{3x|p}}ery (talk) 23:27, 16 December 2018 (UTC)

  • Pinging @Angr pukhlya, Lotje, MjolnirPants, RexxS, and Shah Jahan Ishaq:. {{3x|p}}ery (talk) 23:29, 16 December 2018 (UTC)
    • There's also a number of pages under Module:Module:Sandbox/* and Module:User:* , so not everything is under Module:Sandbox/* , but yes, it's good to move those listed from where they currently are. -- WOSlinker (talk) 23:45, 16 December 2018 (UTC)
      • What should be done about naming conflicts (the cases I marked with a ?)? {{3x|p}}ery (talk) 23:48, 16 December 2018 (UTC)
        • Make sure all links are in the style of "Module:Sandbox/<username>/<module name>" - if there is a naming conflict and the author has not commented here with a name, then just add "1" and "2". --Gonnym (talk) 12:14, 21 December 2018 (UTC)
  • Oppose Sandboxes are useful for testing and trying out content. It makes sense for modules that are tests to be subfolders of Module:Sandbox. However, when it comes to other content, a registered user has their own userspace for essays, demos, etc. in addition to their user sandboxes for development work, but there is no user-modulespace. I'm quite happy to do development work in a subfolder of Module:Sandbox, but for completed projects and mature code, there is no user space where they can reside. I see reason why Module:Username should not serve that purpose for a user's completed work. What benefit is there in moving them? All that happens is that there going to be conflicts between Module:Username and Module:Sandbox/Username when the user already makes use of these titles for different purposes. In my case, I use Module:Sandbox/RexxS as a demonstration for students of Google Code-In, not as repository for completed work, which I use Module:RexxS to store. --RexxS (talk) 00:46, 17 December 2018 (UTC)
  • Support - the documentation at Module:Sandbox does indeed say to use the /sandbox/username/modulename naming style. For RexxS's specific scenario I really don't know what to say, but it really doesn't seem that using Module:sandbox/RexxS/completed/name or Module:sandbox/RexxS/name directly would change what you're trying to achieve, while still keeping the module namespace clean. --Gonnym (talk) 11:16, 17 December 2018 (UTC)
    • The documentation at Module:Sandbox makes it clear that "It exists to provide a convenient pseudo-namespace for code testing, and I'm all in favour of that – and I make regular use of it with about 30 demo and test modules in that namespace. What it does not imply is that finished, functional code, which is in use in areas of the wiki should be kept in the Module:Sandbox pseudo-namespace. This RM is being used to generate a naming policy for usable, completed modules by the back-door. I would be normal on wiki that such a decision should be taken as a result of informed, well-advertised debate. The alternative to having a Module:Username space would be to break out each individual function into main Module space once it is working and in use. I don't see that such a course would do anything but increase the proliferation of small modules, and ironically do the opposite of keeping the module namespace clean. --RexxS (talk) 15:30, 21 December 2018 (UTC)
      • I thought about making a comment below, but if it is ready for use, it shouldn't be kept under one's 'namespace' (e.g. Module:RexxS) or in the sandbox 'namespace' (e.g. Module:Sandbox/RexxS), it should be published with an appropriate name so people can find and use it. We can worry about where specific functions live later if we decide there are too many small modules. --Izno (talk) 17:03, 21 December 2018 (UTC)
  • Support. The subspace of Module:Sandbox is the module equivalent of the user space and if editors would like to make distinctions between different kinds of user modules they can use subsubspaces of that, as suggested by Gonnym. Just a note: given that moving a module doesn't leave a redirect, the moves have the potential to break things elsewhere (Rexx's comment above seems to suggest these might not all be on-wiki); therefore it seems best that when this discussion is closed, all the contributors are notified on their talk pages and given a grace period of a couple of weeks before the moves are performed, in case there are workflows they need to change. – Uanfala (talk) 11:53, 17 December 2018 (UTC)
    • No, the subspace of Module:Sandbox is the module equivalent of the user sandbox space as its documentation makes clear ("a convenient pseudo-namespace for code testing"). The off-wiki use in my case would be confined to Google Code-In, which has now ended for 2018, giving almost 12 months to sort out external incoming links before GCI 2019, so off-wiki use won't pose me a problem. On the other hand, I assume that whoever moves a module is responsible for fixing on-wiki all of the incoming #invoke instances which it will break? --RexxS (talk) 15:30, 21 December 2018 (UTC)
      • I think the relevant distinction is not between sandbox and everything else, but between modules that are ready for general consumption, and modules that aren't (regardless of whether they are mere experiments or not). – Uanfala (talk) 17:04, 21 December 2018 (UTC)
      • I wonder if someone shouldn't get a bot together or be on call for module name/function renaming so that we can make replacements. That seems like a broader issue. --Izno (talk) 17:08, 21 December 2018 (UTC)
  • support, easier to keep track of modules which are not ready for broader use. Frietjes (talk) 12:07, 21 December 2018 (UTC)
  • I support efforts for consistency, so I support these moves in the general case. --Izno (talk) 15:17, 21 December 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Requested move 27 December 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: consensus not to move the modules at this time, per the discussion below, which might also imply that the discussion above should be revisited at some point. Dekimasuよ! 08:27, 3 January 2019 (UTC)

– Centralize personal lua modules under Module:Sandbox (I nominated this one separately from the previous batch as these follow a consistent convention as Module:User:..., whereas the other batch didn't) {{3x|p}}ery (talk) 03:21, 27 December 2018 (UTC)

Module:Sandbox/WOSlinker already exists. {{3x|p}}ery (talk) 03:21, 27 December 2018 (UTC)
I've deleted both of my pages as they are no longer needed. -- WOSlinker (talk) 12:00, 27 December 2018 (UTC)
Pinging participants of previous discussion: @RexxS, WOSlinker, Gonnym, Izno, Uanfala, and Frietjes: {{3x|p}}ery (talk) 03:23, 27 December 2018 (UTC)
Pinging users whose modules I requested be renamed: @AmazingJus, Anomie, Awesomemeeos, Dcoetzee, DePiep, Doc Taxon, Dragons flight, Fred Gandt, Happy5214, Kephir, Ketil3, Legoktm, Lesser Cartographies, Martijn Hoekstra, Mr. Stradivarius, Mr rnddude, Mxn, Plagiat, TelComNasSprVen, Vuh, and Yair rand: {{3x|p}}ery (talk) 03:27, 27 December 2018 (UTC)
Discussion in Archive1 (2013), inconclusive. -DePiep (talk) 15:59, 27 December 2018 (UTC)
  • Oppose My WikiWork module in particular is not a sandbox. It is a module which backs a report in my userspace. -happy5214 03:53, 27 December 2018 (UTC)
    Do you oppose the renaming/moving of all the listed modules or only of the one you mentioned? Fred Gandt · talk · contribs 07:07, 27 December 2018 (UTC)
    I oppose renaming modules which are not sandboxes as sandboxes. The module I mentioned is such an example. Most of the modules listed are clearly sandboxes. I just wish the nominator had distinguished between user modules which are clearly sandboxes and those which possibly implement userspace templates, instead of a blanket move request. -happy5214 07:50, 27 December 2018 (UTC)
  • Weak support as long as everything works correctly afterwards; standardization is good IMO, but not at the expense of functionality, simplicity or efficiency. I should note though that several of the modules I created for various tests and demos should have been speedily deleted by now and were up unto this flurry of activity blanked. I never could figure out how to request their deletion due to the appropriate procedure (application of {{db-author}}) not working so I just blanked them and hoped that the next time they were noticed, they'd be killed. Purely to give a heads up - Module:User:Fred Gandt/sandbox/ chessDemo/move, data2, data3, data4 and data5 should be deleted not moved. Fred Gandt · talk · contribs 07:07, 27 December 2018 (UTC)
    @WOSlinker: could you help me out with deleting the unneeded Modules mentioned above? As I say above, I can't figure out how to add the usual template to submit them to the speedy deletion queue. Fred Gandt · talk · contribs 12:21, 27 December 2018 (UTC)
    @Fred Gandt: I've deleted them. -- WOSlinker (talk) 12:54, 27 December 2018 (UTC)
    Thank you WOSlinker :) Fred Gandt · talk · contribs 14:27, 27 December 2018 (UTC)
    @Fred Gandt: the easiest way I've found to ask for deletion of a user module is to put the {{db-author}}) on the talk page of the module, along with a polite note reminding the admin to delete the associated module page as well. It works most of the time. --RexxS (talk) 15:23, 27 December 2018 (UTC)
    Good idea RexxS; thanks :) Fred Gandt · talk · contribs 15:48, 27 December 2018 (UTC)
  • I don't really care what it's named as long as I have some place to put my sandbox/experiments. To me it seems pretty logical to have them under the pseudo userspace but whatever works for everyone else is fine by me... Legoktm (talk) 08:24, 27 December 2018 (UTC)
  • Oppose. Existing name is (also) a clear reference to user space, strongly stating that it is under control of the user. (Of course techically not possible in straight user space). Removing this indicator could leave others to think one can freely edit. Which is not exactly so for user space. OTOH, one could check for such name-constructs used in mainspace, which is undesirable. -DePiep (talk) 10:42, 27 December 2018 (UTC)
I add: name pattern "Module:Foo/sandbox" allows to automatically detect the sandbox page (and so to adds box message 'This is a sandbox etc.' in top) This is nicely similar with template space. The pattern is also used in {{Sandbox other}} e.g. to prevent categorising the /sandbox page). Examples: Module:Track gauge vs. Module:Track gauge/sandbox. Canonising the proposed pattern "Module:Sandbox/..." breaks this. And complementary, it does not allow to recognise the userpage-intention or -owner. So the new names will always pop up as weirdly used pages without explanation for the page's status or background. Expect lots of "MfD, because not used" claims, requiring to be argumented by the Username. -DePiep (talk) 16:21, 27 December 2018 (UTC)
  • Support - per the documentation at Module:Sandbox, which does indeed say to use the /Sandbox/<username>/<modulename> naming style, and per previous the just closed discussion in which consensus has agreed with the move to a more standard naming convention. If anyone has any issues, the most simple solution would be to add a sub-page of /Sandbox/<username>/completed/<modulename>. --Gonnym (talk) 10:58, 27 December 2018 (UTC)
    Then let's change that page instruction. As I described above, that pattern breaks (automatic) recognition of both ".../sandbox" page and "User:Example/subpage". Sandboxes are not an (informal) subnamespace as "Module:Sandbox" suggests, they are subpages in a 'userspace' or of a specific (parent) module. Parallel behaviour as with template space or userspace is best. --DePiep (talk) 16:25, 27 December 2018 (UTC)
    I'm not sure the "break" is actually really an issue. Why would you even categories a work-in-progress sandbox module? But even if that were a legitimate issue, {{Sandbox other}} does a simple check if two values are equal - changing that to check for Module/Sandbox shouldn't be any harder. --Gonnym (talk) 17:04, 27 December 2018 (UTC)
    No need to say "break" (i.e., use "so-called" quoting). It actually breaks stuff. -DePiep (talk) 22:15, 27 December 2018 (UTC)
    Then could you explain again what it breaks because I might have missed it as I only saw you mentioning the sandbox else template, which isn't an issue. --Gonnym (talk) 10:18, 28 December 2018 (UTC)
    Proposal breaks:
    1. Detecting sandbox pages: pagename ends with /sandbox. Used in {{Sandbox other}}, {{documentation}} (adds top box message, adds links to subpage .../sandbox page (create/edit) in bottom box). 1b. And introduces difference with Templatespace usage.
    2. Detecting module is in pseudo-userspace: per pattern Module:User:... (no examples of automated usage known to me). Module:Sandbox/FooBar/... is ambivalent wrt having a username.
    3. Proposed changes into name pattern Module:Sandbox/<Username>/... says it is a sandbox, which may not be the case (examples mentioned in this thread).
    -DePiep (talk) 14:51, 28 December 2018 (UTC)
    @Gonnym: Let's be absolutely clear about this. (1) The documentation at Module:Sandbox has no more force than any user-created essay. There is no policy yet created for naming modules beyond what can be extrapolated from WP:AT. (2) The documentation at Module:Sandbox actually states

    It exists to provide a convenient pseudo-namespace for code testing ...

    Please name your experimental modules in the following format

    Note the use of the words code testing and experimental modules. Of course it makes sense to test code and write experimental modules in sandbox space; but there is no sense in keeping working code in sandbox space, or even in a sub-subspace of sandbox space. The alternative of splitting out the 20+ working functions from Module:RexxS into 20+ separate modules just to satisfy some misguided sense of "tidiness" is laughable. The whole point of modules is that they allow multiple functions with something in common to be kept in a single container. The thing that the functions in a user: module have in common is that they are being maintained by the same editor, and that seems a perfectly good reason to me – at least until such time as the number of Lua programmers increases to the point where modules are no longer being maintained by a single editor. --RexxS (talk) 23:18, 27 December 2018 (UTC)
    Well since we don't have anything else, and that documentation has not been changed from the moment it was written 5.5 years ago and just now stood a RM, it is pretty compelling argument, even if you don't think so. Just to be clear, I don't technically mind a change of guideline, but if I have to choose between wild-west style creations (as can be seen from the nominated modules) and a naming style which bothers a few people, I'll go with the naming style. --Gonnym (talk) 10:18, 28 December 2018 (UTC)
    Have you considered the possibility that the suggestion in the documentation has remained since its inception because it's sensible advice for test code and experimental modules? – which is what the pseudo-namespace is supposed to contain. However, it says nothing about how we should name code which is no longer under test and modules which are not experimental, so it's unlikely a closer is going to find that relevant, let alone "compelling". All of the nominated modules have the consistent style Module:User:<Your User Name> and subfolders, completely analogous to the proposed renaming scheme, so are we swapping one "Wild-West style" naming convention for an equally "Wild-West" one? You're right on one point: when it comes to naming conventions for userspace modules, we don't have anything. --RexxS (talk) 13:01, 28 December 2018 (UTC)
    As has been shown by the list above, the above aren't all completed code, and in-fact most are sandboxes. Also finding a consistent style is not a new "Wild-west", it's the exact opposite. --Gonnym (talk) 13:20, 28 December 2018 (UTC)
    It would be more accurate to say that the above aren't all sandbox code, and in fact most are completed code. The style Module:User:<Your User Name> is consistent. You're the one who called it "Wild-West". --RexxS (talk) 14:10, 28 December 2018 (UTC)
    No, it would not be accurate to say that, I've spot checked a few and they were all "test" modules. Also, it's pretty amazing looking at this list and calling it consistent, when the whole list itself is the one which is inconsistent with all other modules (and even in this specific list, you have some using Module:<user>/sandbox). End note, since you seem to want to WP:BLUDGEON your point here, I ask you politly to stop commenting on my posts as I'm not going to reply. --Gonnym (talk) 14:33, 28 December 2018 (UTC)
    Yes, it would be accurate to say that, and my spot checks come to the opposite conclusion to yours. There's no problem with moving sandbox modules to Module:Sandbox/ space, but that isn't what this proposal aims to achieve, and you should recognise that and oppose changes that confuse userspace with modulespace for no good reason. The list entries all start Module:User:<user>, not Module:<user> as you claim, and the only thing that's amazing is that you don't seem to realise that everybody can see that. If you don't want to enter into a discussion, that's fine with me, but it does beg the question what you expected when you joined in the debate in an RfC. --RexxS (talk) 20:37, 28 December 2018 (UTC)
    This isn't a RfC, this is a RM which is attracting an atypically large amount of comments. {{3x|p}}ery (talk) 04:59, 29 December 2018 (UTC)
    Oh, but it is. You're trying to make policy by the back-door, and you shouldn't be surprised if the policy gets debated. Read the header for this RM and you'll see that it's a discussion, not just a parade of !votes. --RexxS (talk) 10:38, 29 December 2018 (UTC)
    I never claimed it wasn't a discussion, but the term "RfC" has a formal meaning referring to a specific type of discussion, which this isn't. By "atypically large number of comments", I meant "more comments than RMs usually receive", and didn't indicate I was surprised. {{3x|p}}ery (talk) 16:01, 29 December 2018 (UTC)
    Yes, an RfC is a request for comment, and that's the formal way we make policy. When you tried to create policy by using a RM, you really ought to have expected it to turn into an RfC, rather than a typical RM that decides requests based on already established policy. There is no policy specifically on titling modules; and certainly no policy that would underpin your requested move. --RexxS (talk) 18:04, 30 December 2018 (UTC)
  • Oppose. I'm not in favor of moving SuggestBot's two module pages into a sandbox, partly because as far as I know they've been tested and worked, and I'm hoping to find time in 2019 to start using them. The previous discussion about moving modules into the sandbox makes a reference to them being ready to be used broadly, but I'm not sure I understand how that would be determined for a user space module like this one? It seems to allude to some kind of approval process, which goes counter to the idea of user space modules, but maybe I'm reading too much into it? Cheers, Nettrom (talk) 13:44, 27 December 2018 (UTC)
  • Oppose the general migration of "Module:User:…" to "Module:Sandbox/…" per the arguments that they're not all "experiments". Those that are or were could be moved without my complaint, but those that would be more correctly categorized as "user-space" modules should either remain as named or I suggest a "Module:Userspace/…" prefix for tidiness, continuity and clarity. Speaking purely of my own that remain in the above list; they're not something I'm likely to work on again for a while but they're also not temporary experiments and given the ability to create them in my user-space, I would have. It wouldn't make sense for them to be recategorized as "sandboxy". Fred Gandt · talk · contribs 05:51, 28 December 2018 (UTC)
  • Oppose The pseudo-namespace Module:Sandbox performs a perfectly good service in providing a space for test code and experimental modules. The pseudo-namespace Module:User: provides an equally convenient and useful space for modules containing collections of functions that are now tested and working, but which would not benefit from being split into multiple tiny modules directly in the Module: namespace. These modules are invariably maintained by a single user, and labelling them by that username makes sense. What does not make sense is to move fully functional code into sandbox space. --RexxS (talk) 13:01, 28 December 2018 (UTC)
  • don't understand the value of suggested move. why is Module:Sandbox/Username/blah better than Module:User:Username/blah? looks like busywork to me. peace - קיפודנחש (aka kipod) (talk) 15:04, 28 December 2018 (UTC)
  • Oppose As noted above, moving Module:User:Jimbo/example to Module:Sandbox:Jimbo/example would have zero benefit. Some good reasons for the former have been given and they override any desire to impose "neatness". Johnuniq (talk) 22:59, 28 December 2018 (UTC)
  • Oppose I think "Module:User:Anomie/..." is more appropriate for "module userspace" purposes than the "Module:Sandbox/..." being pushed here. Anomie 15:55, 29 December 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Lua pattern issue with en dash[edit]

I'm trying to create a pattern to capture two sets of digits group that can be separated by various means such as "11-12", "11, 12", "11 / 12", "11 <hr /> 12".

This works for most of these:

local _, _, num1, num2 = episodeNumber:find("(%d*)%s*%p*%a*%s*%p*%s*(%d*)")

However I ran into two problems. The first was, why does


or even


not work? The documentation says that "%." is all characters, so shouldn't that catch them?

The second was, that when I tried "11–12" (En dash) did not work. Does %p not cover it as well? If it's possible, would appreciate some insights into this as I'm really confused. Thanks. --Gonnym (talk) 20:54, 9 January 2019 (UTC)

ndash is a unicode character so to find it use mw.ustring.find('12–23', '%p')
It might be better to look for single character separators and failing that look for <hr /> or <hr/>:
num1, num2 = mw.ustring.match (episodeNumber, '(%d+)%s*[%-–,/]%s*(%d+)') or episodeNumber:match ('(%d+)%s*<hr */>%s*(%d+)')
Trappist the monk (talk) 21:09, 9 January 2019 (UTC)
That actually doesn't quite work; the or operator only operates on the first of the two captures. So this instead:
num1, num2 = mw.ustring.match (episodeNumber, '(%d+)%s*[%-–,/]%s*(%d+)')
if not num1 then
	num1, num2 = episodeNumber:match ('(%d+)%s*<hr */>%s*(%d+)')
Trappist the monk (talk) 21:49, 9 January 2019 (UTC)

The cheat's way of extracting two (and only two) unsigned integers is:

    num1, num2 = episodeNumber:match('^%D*(%d+)%D+(%d+)%D*$')
  • %d+ matches one or more digits
  • %D* matches zero or more non-digits (including en dash)

The above works well for the given inputs but would be trickier if signed integers or numbers with decimal digits were wanted. Using (%d*) is no good because it matches zero or more digits so would often end up as an empty string. %. is an actual dot (period, full stop). Your last pattern includes .* which matches zero or more of any character (actually, any byte since using standard Lua functions), as many as possible. That will match everything up to the end of the string. You would have better luck with .- which matches zero or more of any byte, as few as possible. Johnuniq (talk) 01:30, 10 January 2019 (UTC)

Thanks both, helped a lot! --Gonnym (talk) 09:19, 10 January 2019 (UTC)

Followup question - I've ran into a problem if the range is more than 2. If it is possible, I'd like to catch the start and end of the range. So my current code is this:

		local num1
		local num2
		if (episodeNumber:match('(%d+)%s*<hr */%s*>%s*(%d+)')) then
			num1, num2 = episodeNumber:match('(%d+)%s*<hr */%s*>%s*(%d+)')
			--divider = "<hr />"
			num1, num2 = mw.ustring.match(episodeNumber, '(%d+)%s*[%s%-–,/&]%s*(%d+)')
			--divider = "–"

I also have an alphanumeric block for figures like A, B, or A1, B1:

				if (episodeNumber:match('(%w+)%s*<hr */%s*>%s*(%w+)')) then
					num1, num2 = episodeNumber:match('(%w+)%s*<hr */%s*>%s*(%w+)')
					--divider = "<hr />"
					num1, num2 = mw.ustring.match(episodeNumber, '(%w+)%s*[%s%-–,/&]%s*(%w+)')
					--divider = " – "

What I'm hoping is possible is that if the range is 1-2-3 (or 11-12-13-14, A-B-C, A1-B1-C1) to make it 1-3. --Gonnym (talk) 08:09, 11 January 2019 (UTC)

You might try this:
if (episodeNumber:match('^(%w+)%s*<hr */%s*>%s*(%w+)$')) then
	num1, num2 = episodeNumber:match('^(%w+)%s*<hr */%s*>%s*(%w+)$')
	--divider = "<hr />"
elseif (episodeNumber:match('^(%w+)%s*<hr */%s*>.-<hr */%s*>%s*(%w+)$')) then	-- 3 or more elements
	num1, num2 = episodeNumber:match('^(%w+)%s*<hr */%s*>.-<hr */%s*>%s*(%w+)$')
	--divider = "<hr />"
elseif mw.ustring.match(episodeNumber, '^(%w+)%s*[%s%-–,/&]%s*(%w+)$') then
	num1, num2 = mw.ustring.match(episodeNumber, '^(%w+)%s*[%s%-–,/&]%s*(%w+)$')
	--divider = " – "
	num1, num2 = mw.ustring.match(episodeNumber, '^(%w+)%s*[%-–,/&].-[%-–,/&]%s*(%w+)$')	-- 3 or more elements
	--divider = " – "
The ^ and $ anchors prevent false matches. This same can be accomplished by reordering to that the three-or-more-element tests are done first. You can also do mw.text.split() on separator patterns; if number of items in the resulting table is greater than 1 then take the first and last items and set divider to a string that matches the split pattern.
Neither of these solutions contemplate the possibility of episodeNumber separated by both %s*[%s%-–,/&]%s* and %s*<hr */%s*>%s*.
Trappist the monk (talk) 11:55, 11 January 2019 (UTC)
Thanks again, worked great! --Gonnym (talk) 17:03, 11 January 2019 (UTC)

If various kind of separator are equivalent, a good approach is to replace all possible separators with something simple, before splitting. This is fast and works en dashes (the last line) and more. Example:

episodeNumber = episodeNumber
    :gsub('%s*<hr%s*/?%s*>%s*', '-')
    :gsub('%s*–%s*', '-')

After the above, split episodeNumber on hyphens. Johnuniq (talk) 00:49, 12 January 2019 (UTC)

I like that, I'll test it out. Thanks! --Gonnym (talk) 09:45, 13 January 2019 (UTC)