Jump to content

Wikipedia talk:Lua/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 10

User preferences language

Is there a way to get the Language object for the User language set in the Preferences? mw.message.getDefaultLanguage() and mw.language.getContentLanguage() are the only two I know about, and neither are the one I want. --Atethnekos (Discussion, Contributions) 06:34, 13 July 2014 (UTC)

The outputs of pages using Lua are cached between users, so there's no way something like that could ever work. Jackmcbarn (talk) 15:42, 13 July 2014 (UTC)
Thanks a lot. I know this is now off-topic, but is there anyway to get the output of a template to vary based on that user language preference? --Atethnekos (Discussion, Contributions) 17:08, 13 July 2014 (UTC)
No, and we'll likely never have one because the cache fragmentation would kill performance. Jackmcbarn (talk) 17:40, 13 July 2014 (UTC)
@Atethnekos: Also, can you tag Template:Lv and Module:Lv for speedy deletion-G7 if that kills plans for further changes to them? As they stand now, they're redundant to the {{CONTENTLANGUAGE}} magic word. Jackmcbarn (talk) 17:52, 13 July 2014 (UTC)
Yeah, I shall, I was just trying to build something, but since you're saying it's impossible I'll get rid of them. --Atethnekos (Discussion, Contributions) 17:54, 13 July 2014 (UTC)
commons:Module:Fallback gets the user language, but based on preprocess( "{{int:lang}}" ) with Mediawiki pages created for this purpose: commons:Special:PrefixIndex/MediaWiki:Lang/. --Vriullop (talk) 09:49, 14 July 2014 (UTC)
Wow. I understand Commons is eager to be multilingual, but this is ... risky. The preferences are supposed to be completely private, and this puts a little hole in that line. I see that here ⧼lang⧽ is producing "<lang>", but on Commons it can produce en, es, de etc. And where it gets interesting is how that works with the cache. So I tried on my talk page and found that when I set preferences to es and view es, I get a CURRENTTIMESTAMP for the first time that doesn't change thereafter (it's cached). If I log out and view the page in default English, I get en and another timestamp. If I log in and switch back to English, I get the _same_ timestamp, i.e. I now can know when the first en-reader viewed my talk page after I edited it. If I switch to de and view I get yet another timestamp, which then remains stable. So if we have a stable page on Commons, someone can see which language user preferences first viewed it when, which admittedly is interesting but not directly abusable. But... there's more.
Suppose Wikipedia enables this, and I want to hold an RFC on how Crimea is colored on a map. I wrap my RFC announcement in some template that I arrange to run Lua code to get the frame:preprocess of the language code. If the user language code is ru ... it doesn't display. Except maybe until after a certain amount of time passes (there are other ways to disable caching to ensure this would be checked). That way I could start an RFC and systematically skew the vote against Russian speakers, and by the time people got suspicious about it they'd see the page, people might well say 'replag' and move on if it were concealed with a good enough cover.
Bottom line is that Wikipedia should _not_ blur this boundary. There has to be some other way. Wnt (talk) 19:02, 14 July 2014 (UTC)
For reference, you don't need int: to see the timestamp thing. You can do the same thing on any page that has a table of contents. (ToC currently causes cache fragmentation based on user language). You don't even need {{CURRENTTIMESTAMP}} on the page to see if someone viewed it in that language, since render timestamp is included in an html comment on all pages. Bawolff (talk) 23:07, 14 July 2014 (UTC)
It forces multiple caches even for pages that don't use internationalization? I'd have thought there would be a way to avoid that... Wnt (talk) 01:57, 15 July 2014 (UTC)
Its so that mediawiki:toc is translated into user language. Arguably I consider this a bug, and it should be done in a post processing step to avoid cache fragmentation (like we do with section links and <mw:editsection ...>). But thus far nobody has done that yet. Probably many people find it scary to poke that deep into the bowels of the parser. Bawolff (talk) 02:07, 17 July 2014 (UTC)
Heh, I haven't looked into it and I already see how this might be "interesting". The page you linked is deleted. It also contains contents (namely, "Contents"), despite having no revision history. Wnt (talk) 12:19, 17 July 2014 (UTC)
@Wnt: The MediaWiki namespace is weird. If no revisions exist, but the message is a default MediaWiki message (both of which are true in this case), then the page is still considered to exist and has contents. Jackmcbarn (talk) 15:14, 17 July 2014 (UTC)
Please please please don't use {{int:}}. It's just a bad hack. Legoktm (talk) 22:45, 14 July 2014 (UTC)
I'm curious as to the reason that knowing user language would be useful here, actually. Jackmcbarn (talk) 23:16, 14 July 2014 (UTC)

Module:Fake object

If you ever find yourself doing testing with title objects, you might be interested in Module:Fake object. It puts a metatable wrapper round another object and allows you to overwrite its fields without generating errors. I'm using it in Module:Protection banner/testcases, where it is saving me from having to find actual pages with the namespaces and protection levels I need, and from having to fix the test cases when someone changes a protection level somewhere. Also, if anyone can see any ways to improve it, suggestions would be very welcome. — Mr. Stradivarius ♪ talk ♪ 02:57, 17 July 2014 (UTC)

@Mr. Stradivarius: What does that module let you do that rawset doesn't? Jackmcbarn (talk) 03:01, 17 July 2014 (UTC)
Now that's a good question. I can't think of anything - it looks like I just wrote that module for nothing. And if you use rawset, methods using a check self function still work. Well, it was good practice at writing metamethods, at least... — Mr. Stradivarius ♪ talk ♪ 03:08, 17 July 2014 (UTC)
I've gone ahead and deleted the module, as rawset seems to be generally superior. — Mr. Stradivarius ♪ talk ♪ 23:40, 18 July 2014 (UTC)

mw.log output is now visible

A change was deployed a few hours ago that makes mw.log output from pages visible. It will now show up in the parser profiling data when previewing. To see a useful example of this, look at the log output of one of the pages in Category:Location maps with possible errors - it will contain details about the problem that caused the page to be placed in the tracking category. Jackmcbarn (talk) 01:18, 18 July 2014 (UTC)

That's very useful, thanks. Johnuniq (talk) 01:34, 18 July 2014 (UTC)
I tried this; it is indeed useful. (For the uninitiated, you don't actually need to enable scripts to use this, but you do have to preview the page with the error on it) Though tracking and fixing these errors is still no picnic... Wnt (talk) 19:43, 18 July 2014 (UTC)

mw.math library error checking

Would anyone mind taking a look at gerrit:143678? We're in the process of adding a mw.math library to Scribunto to fill in the gaps from Lua's standard math library, but Jackmcbarn and I are disagreeing over whether to add type checking or not. The argument for type checking is that it will make debugging easier and that the other Scribunto libraries do it; and the argument against is that type checking would make it impossible to use mw.math to do advanced things involving metatables, etc. I don't want this disagreement to hold up the deployment of mw.math altogether, so some outside opinions would be very welcome. You can comment here if you want, or you can comment over at Gerrit if you make yourself a Wikitech account. We also need more reviewers in general, so feel free to look at the other submissions in the open changes queue. — Mr. Stradivarius ♪ talk ♪ 06:22, 19 July 2014 (UTC)

I haven't looked at this nearly hard enough to settle anything, but just thinking out loud: I see there's a suggestion to require at least one argument, but the unit tests list ideas like sum() = 0, product() = 1. I think there's some merit to having convenient behavior for the empty set, especially if it can be passed in as a table. Question: is there going to be a conflict if you're using custom numbers (tables with metatables) and you also accept that a table as the first argument indicates that the fields of the table are the arguments? I'm thinking that you could differentiate between the two if you check whether a metatable exists in that case, but it seems a bit odd. Wnt (talk) 11:58, 19 July 2014 (UTC)
Indeed, that is an issue. As the code is written now, the solution is that if you use tables-with-metatables-as-numbers, then you have to use the table form of the function call as well. Jackmcbarn (talk) 14:50, 19 July 2014 (UTC)
Hmmmm... personally I'm not a great fan of almost-but-not-quite synonyms. If there's not a way to make a(x,y,z) precisely equal to a{x,y,z}, would it be better just to have the second way? Wnt (talk) 20:43, 19 July 2014 (UTC)
That was my original idea. Jackmcbarn (talk) 02:14, 20 July 2014 (UTC)

FYI, the general pattern for a{x,y,z} = a(x,y,z) is: 

function a(x, y, z)
  if type(x) == "table" then
    x, y, z = unpack(x)
  end
end

--darklama 15:15, 25 July 2014 (UTC)

That's a nice trick, but I think the idea behind passing a table was to avoid the overhead of unpacking a table (on the assumption that the caller already had the numbers to be summed in a table). My opinion is that library functions should behave like Lua does, and a{x,y,z} means a({x,y,z}), so the table should not be unpacked as if that were standard behavior. If that were wanted, have a separate function to sum values in a table. Johnuniq (talk) 00:37, 26 July 2014 (UTC)

Let's get rid of the Lua/todo page

About Wikipedia:Lua/To do. It has little activity. And rightly so: we at wikipedia do not list one another jobs 'to do'. There is very little activity since its creation on November 2013. Also, and relevant to wiki, there is the danger of mis-communication: editors talking on page A, while on page B the same issue proceeds. (Links may be preserved).

For these two reasons, I propose to delete: Wikipedia:Lua/To do. -DePiep (talk) 01:40, 23 July 2014 (UTC)

I suppose as its creator I would say this, but I think it has a useful role to play in identifying templates that need to be converted. I admit that it hasn't had a very high level of activity, but that doesn't mean that it isn't serving its purpose. I've removed a couple of stale entries, but the others are all tasks that still need doing. — Mr. Stradivarius ♪ talk ♪ 03:04, 23 July 2014 (UTC)
After WT:Lua and WP:Lua/Request this is a third (fourth, ...) coordiantion place. That means sooner of later, but surely, information & communications will be lost. A Todo list could be in top of the Lua talkpage? -DePiep (talk) 19:42, 16 August 2014 (UTC)

Detect call context

Sorry if already answered or way too obvious. Are there ways and what is the best (if there are) to detect the call context?

Say for Module:B with function doB() to detect if it is

  • called sraight from a wiki-page like {{#invoke:B|doB}}
  • called from a template like {{doB}} from where {{#invoke:B|doB}}
  • called from Template:doB specifically and not from any other template
  • called from another module using require() in that module
  • called from Module:A using require() in that module and not from any other module

If possible at all I am not expecting all answers, a common general hint would be great as well. --NeoLexx (talk) 14:45, 21 August 2014 (UTC)

@Neolexx: That question sort of reminds me of the X-Y problem. What are you doing that needs to know the call context? The one use case I can think of is to allow arguments to be passed in different ways, but using Module:Arguments is a much better solution for that than attempting to write context-sensitive functions. Jackmcbarn (talk) 21:09, 21 August 2014 (UTC)
Neolexx: I think for some of these things you can just use : local parent = frame:getParent(frame)

And then get the parent's name as a string using : parent:getTitle()

For other cases (such as if the module is being invoked from a template which is within an article page, and you want to know the article page), you'd need to get the 'grandparent', which doesn't seem to work. If I try the following code, 'parent' and 'grandparent' are always the same no matter the circumstances: local parent = frame:getParent(frame) local grandparent = frame:getParent(parent)

But maybe I'm doing something wrong. Hopefully one of the more experienced editors can show us how to get the grandparent. BigGreenCahuna (talk) 22:43, 21 August 2014 (UTC)

You currently can't get the grandparent. Jackmcbarn (talk) 23:12, 21 August 2014 (UTC)
Is there any other way to get the page that's using the template which is invoking a module? I can think of a lot of uses for this, such as allowing the template to automagically add some customization based on the page, without the need to tediously add a new argument on every single page that already uses the template. BigGreenCahuna (talk) 23:20, 21 August 2014 (UTC)
You can get the "root" page with mw.title.getCurrentTitle(), but if you have A -> Template:B -> Template:C -> Template:D -> Module:E, you'll get A. There's no way to get Template:B or Template:C. Jackmcbarn (talk) 23:51, 21 August 2014 (UTC)
  • Thank you all for answering, and it may indeed help to explain my reasons. It is helpful(?) to keep an OP-like paradigm with small modules to do one exact task each but doing it right - rather than having all-in-one. And then depending on the task to collect needed sets by require() chains. The problem is that even small fully internal (by its purpose) module might be seem useful for someone's purpose as it is: straight from the page or from its own template. And things gets sometimes populated very quickly on wiki. So a month later one adjusts that module and suddently crashes thousands of pages around (s)he had no idea about. There are real cases I would like to not enumerate right now.
So instead of different spooky DON'T USE DIRECTLY or ONLY WITHIN... on the module page I was thinking of some more programmatical way of doing things. Like in Javascript we don't write PLEASE DO NOT CALL THIS CONSTRUCTOR AS A FUNCTION, there is this for this. Similarly I was thinking to distinguish a correct call context (from a given template or from a given parent module) from an incorrect one (straight from the page or as a stay-alone module). --NeoLexx (talk) 09:54, 22 August 2014 (UTC)
Doing that would be a bad idea. If you only want code to get called from one particular module, put the code in that module as a local function. Don't put it elsewhere and then try to detect what the caller is. Don't let "good" OOP trick you into writing bad code. Jackmcbarn (talk) 15:27, 22 August 2014 (UTC)
We may have very different ideas about "good" and good programming patterns. But I do respect your opinion and thank you for answering. --NeoLexx (talk) 09:00, 23 August 2014 (UTC)
Although it won't prevent someone from using your helper modules if they choose to ignore your documentation, you can make them subpages of your main module. This way you can document your main module as providing the external interface to templates or other modules, and all subpages below being conceptually private. isaacl (talk) 22:16, 1 September 2014 (UTC)

HtmlBuilder

See #mw.html library nil behaviour. Many modules still use the HtmlBuilder instead of the mw.html library. Once they are converted on this wiki, many other projects will benefit from them. --Ricordisamoa 06:05, 1 September 2014 (UTC)

Function names containing equals signs

In WT:Lua/Archive 2#Metatables will now work on export tables, Wnt pointed out that a function name containing an equals sign would cause later arguments to be misnumbered. I've submitted gerrit:158890 to fix this problem, which is now merged. Beginning September 18th, we'll have the ability to use the function name as a "free" parameter that users can use without worrying about escaping equals signs in it, which isn't currently doable in any other way. Jackmcbarn (talk) 19:46, 6 September 2014 (UTC)

I don't like the sound of that "'free' parameter" idea. That sounds like it'll be confusing. Anomie⚔ 00:47, 9 September 2014 (UTC)
Why not just forbid the equal sign in function names? Chillum 00:52, 9 September 2014 (UTC)
It has its uses, even if it's confusing. (Just like half of the parser's other obscure features, like msgnw and the reverse pipe trick, to name a few). Also, it's exactly the same as any other positional parameter now, just like all other parser functions (except #switch, sort of) take. Jackmcbarn (talk) 00:56, 9 September 2014 (UTC)

Bug in mw.language.fetchLanguageName()?

Module:Citation/CS1 supports ISO639-1 language codes in its |language= parameter. It currently does this with a table of codes and names that is in Module:Citation/CS1/Configuration. Earlier this year I did a quick experiment with mw.language.fetchLanguageName() that showed me that it might be possible to replace the translation table with calls mw.language.fetchLanguageName()

Just getting around to more complete experiments. It appears that mw.language.fetchLanguageName() is producing incorrect results for the ISO639-1 code for the Norwegian language, no. This simple citation uses the sandbox version of Module:Citation/CS1 (should produce Norwegian):

{{cite book/new |title=Norwegian |language=no}}
Norwegian (in Norwegian). – see code no

ISO639-1 code km should produce Central Khmer

{{cite book/new |title=Central Khmer |language=km}}
Central Khmer (in Khmer). – see code km

ISO639-1 code to should produce Tonga (Tonga Island)

{{cite book/new |title=Tonga (Tonga Island) |language=to}}
Tonga (Tonga Island) (in Tongan). – see code to

I presume, not having read the standard, that when there is more than one approved language name for a specific code, the first listed name would be the preferred name. There are several codes where this is the case: dv, ii, ki, kl, and os.

How to get this fixed?

—Trappist the monk (talk) 23:45, 1 September 2014 (UTC)

@Trappist the monk: To clarify, exactly what parameters are you passing to mw.language.fetchLanguageName()? Are you passing 'no' as the first one and omitting the second one? Also, exactly what output do you expect, and what output do you get? Jackmcbarn (talk) 00:08, 2 September 2014 (UTC)
local name = mw.language.fetchLanguageName( Language:lower(), "en" );
where Language is the value assigned to CS1 parameter |language=. So, in this case |language=no
When the citation is rendered, it should contain (in Norwegian).
Norwegian (in Norwegian). – current live (correct) version of the CS1 module using the table in Module:Citation/CS1/Configuration
Norwegian (in Norwegian). – sandbox (wrong) version of CS1 using mw.language.fetchLanguageName()
Norwegian (in Norwegian Bokmål). – sandbox with code nb produces correct response
I think that I expect each of the two-character ISO639-1 codes to produce the preferred (first listed?) language name according to the Library of Congress.
Related? {{#language:no|en}} produces Norwegian which is the same wrong language name produced in the Norwegian language test above, and {{#language:km|en}} produces Khmer and {{#language:to|en}} produces Tongan, also both wrong according to LOC. More evidence that these issues are related: {{#language:nb|en}} produces Norwegian Bokmål which is correct and the same as the mw.language.fetchLanguageName() result above.
Have I answered your questions?
—Trappist the monk (talk) 00:56, 2 September 2014 (UTC)
@Trappist the monk: Almost. You're saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål). Do you want it to produce Norwegian or Norwegian Bokmål? Jackmcbarn (talk) 01:03, 2 September 2014 (UTC)
Yes, I am saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål) and I am saying that it is the wrong language name for code no. The correct language name and the one that I'm looking for is Norwegian because that is the language name associated with no in the list of codes at the Library of Congress website.
I am most concerned with no because it is most clearly wrong but it would be nice, barring any reasons unknown to me, if we could make sure that for all of the ISO639-1 two-character codes, mw.language.fetchLanguageName() (and {{#language:}} for that matter) returns the preferred name.
More clear?
—Trappist the monk (talk) 01:25, 2 September 2014 (UTC)
@Trappist the monk: I've figured it out. mw:Extension:CLDR has a specific override in place for that language, which you can see at [1]. It was added by Siebrand in mw:Special:Code/MediaWiki/31280. Jackmcbarn (talk) 01:37, 2 September 2014 (UTC)
Thanks for that. I'll drop a line to Siebrand.
—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)

I guess it's not relevant here, but searching List of Wikipedias for "Norwegian" shows "Norwegian (Bokmål)" for nowiki and "Norwegian (Nynorsk)" for nnwiki (see Norwegian Wikipedia), so adding "(Bokmål)" is done in other places. Johnuniq (talk) 04:33, 2 September 2014 (UTC)

List of Wikipedias doesn't use mw.language.fetchLanguageName() or {{#language:}}. There are three Norwegian language ISO639-1 codes: no, nb, and nn. no is the 'non-specific' or generic code that includes both nb and nn. mw.language.fetchLanguageName() produces correct results when nb and nn are specified:
Norwegian Bokmål (in Norwegian Bokmål).
Norwegian Nynorsk (in Norwegian Nynorsk).
—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)
Sure, but the point I was making is that for whatever reason, "Norwegian (Bokmål)" is associated with "no" in more places than mw.language. Another example is Wikidata which uses nowiki as can be seen at d:Q14033926. Johnuniq (talk) 10:53, 2 September 2014 (UTC)
Understood. I don't know how that wikidata page got its language name but its form (norsk bokmål) is different from either {{#language:no|en}} → Norwegian or {{#language:nb|en}} → Norwegian Bokmål which implies that it was not taken from mw:Extension:CLDR.
—Trappist the monk (talk) 11:37, 2 September 2014 (UTC)
@Trappist the monk: That would be from {{#language:no}} (or the basically-equivalent {{#language:no|no}}), which yields norsk. Wikidata displays languages in themselves. Jackmcbarn (talk) 12:39, 2 September 2014 (UTC)
It occurred to me to wonder in my message to Siebrand how no, nb, and nn are handled when Dutch (nl) is the specified output language:
  • {{#language:no|nl}} → Noors
  • {{#language:nb|nl}} → Noors - Bokmål
  • {{#language:nn|nl}} → Noors - Nynorsk
You can see that we get the correct results. It's the same if you do the experiment specifying other common language codes for the output language, for example de, es, fr, it, ru, and even yi all produce output equivalent to Norwegian, Norwegian Bokmål and Norwegian Nynorsk. This is the limit of my current experimentation but it seems that output for no with output language specified as code en and code no are wrong, or at the least completely inconsistent with output for other output language specifiers.
—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)

While the language codes used by methods such as mw.language.fetchLanguageName() are similar to IETF language tags (which draw from ISO 639 codes, among other sources), not all MediaWiki language codes are valid IETF tags or vice versa. See mw:Extension:Scribunto/Lua reference manual#Language library for more. Anomie⚔ 11:50, 2 September 2014 (UTC)

From this:
language codes: "...(mostly in accordance with ISO 639-3, except two-letter codes from ISO 639-1 for "established" locales)..."
can I infer that the two-letter language code no should be in compliance with ISO639-1? See code no.
RFC 5646, interestingly enough, specifically mentions no, nb, and nn as Norwegian, Norwegian Bokmal, and Norwegian Nynorsk respectively. From IANA language subtag registry (oft mentioned in RFC 5646) this for code no:
%%
Type: language
Subtag: no
Description: Norwegian
Added: 2005-10-16
Suppress-Script: Latn
Scope: macrolanguage
%%
All of this suggests to me that mw.language.fetchLanguageName() and {{#language:}} should not be returning Norwegian (Bokmål), Norwegian Bokmål, or norsk bokmål when the input is specified as code no regardless of output language code.
Am I missing something?
—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)
Hmm. I see someone added "except two-letter codes from ISO 639-1 for 'established' locales" since last I read through that, which totally changes the meaning of the sentence. At any rate, the issue here is that the English name for MediaWiki language code "no" is currently "Norwegian (bokmål)", and if that should be changed to match ISO 639-1 then it needs to be changed in mw:Extension:CLDR. Anomie⚔ 23:20, 2 September 2014 (UTC)
Right. So how do we get that done?
—Trappist the monk (talk) 10:50, 3 September 2014 (UTC)
Well, you said you already tried talking to Siebrand. Next step would be to file a bug, and even submit a patch if you can. Anomie⚔ 12:56, 3 September 2014 (UTC)
It's been over a week and no response from Siebrand. Alas, I value my privacy so I'll not be filing any bug reports until bugzilla joins the 21st century. Wikipedia is already too much of a timesink and I fear that if I start making patches it will only become worse.
For the time being, I can craft a workaround in Module:Citation/CS1 so that rendered citations display the correct language name when |language=no
—Trappist the monk (talk) 14:05, 10 September 2014 (UTC)
As a Norwegian I can elaborate on this. One problem is that 'Norwegian' ('no') is not a written language, it's only referring to "some variant of Norwegian; either Norwegian Bokmål (nb) or Norwegian Nynorsk (nn)". Historically 'no' has been used for Bokmål, while 'nn' has always been used for Nynorsk, so even today one can generally assume that 'no' means 'Norwegian Bokmål'. But following ISO 639-1 strictly one should not, so the situation is a bit messy. The best solution is generally to deprecate 'no' where possible. We're unfortunately stuck with the 'no' prefix at no.wikipedia.org, but we use 'nb' as our content language. 'no' has also been removed from translatewiki. – Danmichaelo (talk) 20:12, 14 September 2014 (UTC)

Detecting when the edit link goes to a redirect page

would it be possible to track this problem? either through checking to see if 'name' matches the template name, or by checking to see if the value of 'name' is a redirect page. I am guessing that the first one isn't possible, since it requires going to a grand child ('module:navbox' → 'template:navbox' → 'template:international volleyball')? and, that checking to see if 'the value used for name is a redirect' is expensive? Frietjes (talk) 13:56, 9 October 2014 (UTC)

The proper fix for that problem is to make navbox templates call Module:Navbox directly, since the name parameter is unnecessary when doing so. Jackmcbarn (talk) 14:33, 9 October 2014 (UTC)
(edit conflict) @Frietjes: Your first option isn't possible with the current way the templates are set up, as Scribunto can't access grandparent frames. (Note that in Lua-speak Module:Navbox is the grandchild and Template:International volleyball is the grandparent.) So we can tell that we are being called by Template:Navbox, but we can't go any higher than that. However, you could do it if you used {{#invoke:Navbox|main|...}} directly on Template:International volleyball, as then it would be the parent, not the grandparent. In fact, if you did that you could just get rid of the name parameter altogether, as Lua would always return the correct name. Your second option is also possible, and you're right that it is expensive. You need to make a title object for that page and then the isRedirect property of the title object will tell you whether or not it's a redirect (see the manual here). It's the making of the title object that is the expensive part, so you can call mw.title.new with pcall if you have to avoid script errors (probably a good idea on Module:Navbox). — Mr. Stradivarius ♪ talk ♪ 14:43, 9 October 2014 (UTC)

Cleaning up Category:Pages with script errors

I found myself browsing Category:Pages with script errors earlier today, and I noticed it was full of sandboxes and talk archives that are distracting from the pages that really need fixing. However, when I started clearing the category out, Anomie pointed out that I shouldn't just go editing other people's sandboxes. He's probably right. So, how can we find the script errors that need attention without getting distracted by test pages? Off the top of my head, I have two ideas: 1) add a new category for script errors in the main namespace only, and 2) add a category for script errors that filters pages by regex to exclude "/sandbox" and "/Archive n" etc. Do these sound like good suggestions? Or perhaps someone has a better one? — Mr. Stradivarius ♪ talk ♪ 15:34, 16 October 2014 (UTC)

I'd say categorize by mainspace. Subpage name patterns are more volatile, and require more maintenance thinking. (WP:FLOW will change any talkspace beyond recognition). Mainspace script errors are the only ones you want to check (cat space, wp space, ...?). -DePiep (talk) 16:05, 16 October 2014 (UTC)

(edit conflict)

I support this. But, it would seem to me that it would be beneficial to construct a category set from the top down. For example:
Category:Lua
Category:Lua errors
Category:Lua errors in namespace
Category:Lua errors in namespace
...
Category:Lua errors in namespace
Category:Lua ...
And no Category:Pages with ... titles. We all know that categories contain pages, files, and other categories. It seems pointless to me to state that in the category title. Yeah, personal peeve.
I'm not sure that I see much need categorize errors the User namespace, or in /sandbox, /testcases, and /archive subpages. Perhaps none of the various talk namespaces should be categorized either. Probably no need to categorize pages in Module:Sandbox.
—Trappist the monk (talk) 16:29, 16 October 2014 (UTC)
@Trappist the monk: About the "Pages with" prefix: that is already customisable from MediaWiki:Scribunto-common-error-category. (You can see all the Scribunto messages here.) — Mr. Stradivarius ♪ talk ♪ 04:46, 17 October 2014 (UTC)
Also, I see that Scribunto already distinguishes between "Lua errors" and "script errors". From what I can tell, the difference seems to be that any error that happens inside Lua is a Lua error, and errors that happen elsewhere (such as invoking a non-existent module or a non-existent function) are script errors. So calling the error category "Lua errors" would imply that that it didn't contain non-Lua script errors. Theoretically there is also a possibility of more scripting languages being added to Scribunto, although this probably won't happen any time soon given the amount of effort that's gone into making Lua compatible with HHVM. — Mr. Stradivarius ♪ talk ♪ 05:10, 17 October 2014 (UTC)
It may be true that there is some sort of internal differentiation between Lua errors and Script errors but they both seem to end up in this category. I'm not sure that the distinction is all that important. If it becomes important, then we can worry about it.
—Trappist the monk (talk) 11:01, 17 October 2014 (UTC)

I haven't been paying attention—what magic is putting pages in the category? I agree with Trappist's remarks about there being no need for "Pages with" and no need to have a sandboxes et al in a tracking category. I frequently patrol Category:Convert error categories and it's much better now that the convert module only outputs a tracking category for articles—there were too many false alarms even on template pages. Johnuniq (talk) 00:37, 17 October 2014 (UTC)

I wouldn't like to see this category split up. I especially find it useful to see errors in sandboxes, talk pages, etc., as that allows me to spot errors in modules before they become a big problem. Note that it's already possible to filter by namespace if you want. For example, [2] will show you just articles that have errors. Also, to help clean out the category, I often look at [3] which shows me the newest errors first. Jackmcbarn (talk) 03:23, 17 October 2014 (UTC)
@Jackmcbarn: I agree that seeing those kinds of errors is useful, but what about the pages in the category that only contain something like {{#invoke:Sandbox|some function that doesn't exist}}? Or talk page archives that contain script errors because the module that they used to invoke has been moved? I don't think monitoring those kinds of errors would be useful in most cases. Also, using the API to filter the category by namespace is a neat trick, but most editors probably won't realise that they can do it. And we can always keep Category:Pages with script errors as it is currently, containing all the pages with script errors, and make the subcategories different subsets of those pages. Or perhaps we could add an option to MediaWiki to filter all categories by namespace, like we currently do for the watchlist or for contributions? — Mr. Stradivarius ♪ talk ♪ 04:37, 17 October 2014 (UTC)
If there is a standardized way to filter category content, then that is the proper thing to do; and no need for the individual namespace categories I suggested earlier. Until then, I have added Editor Jackmcbarn's API filters to the category page. It does make me wonder: why can't filtering be part of every category page?
—Trappist the monk (talk) 11:01, 17 October 2014 (UTC)
I agree that we should make namespace filtering accessible via the UI for categories. Jackmcbarn (talk) 14:54, 17 October 2014 (UTC)
@Johnuniq: The magic is contained in the Scribunto extension, so we can't change it from enwiki. To change the way categorisation of script errors works, some kind of change would be necessary in Scribunto itself. — Mr. Stradivarius ♪ talk ♪ 04:37, 17 October 2014 (UTC)

Module_talk:Wikidata#getDateValue_issue

Is there any Wikidata Lua programmer? We have a a little issue with getDateValue function. --Rezonansowy (talk | contribs) 10:16, 26 October 2014 (UTC)

How to use template parameter names as Lua variables.

For example, in a template: {{#invoke:Sandbox|function|{{{1|}}}|{{{2|}}}|...|{{{42|}}}|...}}, I need to define each template parameters one by one. Is there any way I just need to define template as "{{#invoke:Sandbox|function|{{{1}}}}}}", input "a|b|..." just as a normal template, then Lua recognize "1=" "2=" ... also as variables?--JamesQQ5 (talk) 06:07, 7 August 2014 (UTC)

Yes, that's easy. 

local pframe = frame:getParent()
local config = frame.args  -- arguments from the template definition
local args = pframe.args   -- arguments from the page calling the template

If a page contains {{example|abc|def}} and Template:Example contains {{#invoke:example|main|hello}}, and after the above code, config[1] is 'hello' and args[1] is 'abc' while args[2] is 'def'. Johnuniq (talk) 06:27, 7 August 2014 (UTC)

Wow, I successed as you said, thanks for your help!--JamesQQ5 (talk) 16:08, 7 August 2014 (UTC)
I'm not sure I understood this. Is there a template and module illustrating this? It seems to suggest that one can invoke a module from a template without explicitly passing it parameters, but letting it "grab" all, arbitrary parameters and values fed to the template? If so, does it do this only positionally? I have not experimented with Scribunto modules much, yet.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:51, 28 October 2014 (UTC)
Templates can only see parameters that were passed to them. Lua modules can see parameters that were passed to them, as well as parameters that were passed to the template that called them (referred to as their parent). Jackmcbarn (talk) 22:53, 28 October 2014 (UTC)
@SMcCandlish: Also, it works for all parameters, not just positional ones. I'm not aware of any simple example module out there - someone should probably make one. — Mr. Stradivarius ♪ talk ♪ 23:19, 28 October 2014 (UTC)
Thanks both; I'm going over Module:Arguments which I think is going to help me.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:24, 28 October 2014 (UTC)

Looking for small Lua tasks and mentors for Google Code-In - Got something in mind?

Hi everybody! Google Code-In (GCI) will soon take place again - a six week long contest for 13-17 year old students to contribute to free software projects. Wikimedia took part in 2013 already with great results. Tasks should take an experienced contributed about two-three hours (but "beginner tasks" are also welcome which are smaller) and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design.

Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, or any templates to port to Lua on your "To do" list but you never had the time? If yes, please go to mw:Google Code-in 2014, check out the "Mentor's corner", and add your task there (please add tasks until Sunday even if it's only a stub - we can still polish them until December 1st when the contest begins)! And if something is unclear, please ask on the talk page. Happy to help! --AKlapper (WMF) (talk) 21:13, 6 November 2014 (UTC)

Proposal to disable "Allow saving code with errors"

The "Allow saving code with errors" lets users save code even if it contains a syntax error that would prevent it from working anywhere. The reason that this feature was added was to let users of some wiki (not sure which) more easily save work-in-progress code. I've never had to use this checkbox, and as far as I know, no other Lua scripter here has either. Every time I've seen it used here, it was someone who didn't understand Lua screwing something up. Since it's easy enough to save WIP code by simply commenting it out, I propose that we disable that checkbox here. Are there any objections? Jackmcbarn (talk) 21:12, 8 September 2014 (UTC)

Yes I object. Didn't even know it existed, but I could have used it many times, e.g., when I wanted to save the page for the night, & more tomorrow. If commenting out for a single line would solve it, that would be great but that is not to be expected. Are there any damages known from saving bad code modules? -DePiep (talk) 20:41, 27 September 2014 (UTC)
Yes, there's damage. Clueless users have a way of finding modules with a good number of transclusions (but not enough to protect) and breaking them. Also, I talked to Tim about this, and he suggested that rather than even make it a config option, to just remove it altogether. (And the fact that you didn't know it existed shows how useful it is to legitimate users.) By the way, if you have multiple lines in progress, putting --[=[ at the beginning of your code and ]=] at the end will make a multiline comment and comment it all out. Jackmcbarn (talk) 20:44, 27 September 2014 (UTC)
(And the fact that you didn't know it existed shows how useful it is to legitimate users.) Bull shit. It caused me damage. And for logic, I wouldn't trust you programming for me.
Who's Tim? Anyway, if Holy Tim says so, why did you ask it here in the first place? You already decided the outcome. -DePiep (talk) 20:52, 27 September 2014 (UTC)
Tim is Tim Starling. I asked here in the first place because my original idea was to make having the checkbox be a config option, which we'd turn off here, but if we remove it altogether from the software, then it's not a config change anymore and doesn't need local consensus anymore. Also, I fail to see how a feature that you didn't know about, and only does anything if you know about it, caused damage to you, and why the fact that something caused damage to you is a reason to keep it. Jackmcbarn (talk) 21:50, 27 September 2014 (UTC)
While serious coders should not generally check the box, removing it wouldn't prevent anyone from damaging modules by causing a runtime error. --Ricordisamoa 03:32, 17 October 2014 (UTC)
@Ricordisamoa: True, but it would be harder for someone totally clueless to cause a runtime error than a syntax error. Jackmcbarn (talk) 03:44, 17 October 2014 (UTC)
It made sense to have this feature initially (to document if the parser threw an error on valid Lua code) but at this stage it may not be worth the nuisance value. Commenting does indeed sound like a reasonable work-alike that might be used more responsibly. OTOH I have a feeling the newbies will still find some way to cause you trouble, because that's just how it is. :) Wnt (talk) 06:48, 2 December 2014 (UTC)

Module alias

Hi to everybody! How to get aliass for module parameters? In wikicode it would be something like {{{foo1|{{{foo2|{{{foo3|}}}}}}}}}. I would like to include it the main module's page, not in some subpage like here. And how to create aliases, if there is automatic numeration of parameters? For example, there is infobox module, using which, I could use |header1= to |header...=, and I want, that |foo1= to |foo...= also works for headers. --Edgars2007 (talk/contribs) 08:48, 7 December 2014 (UTC)

See my comment above for how to define a variable called args that contains arguments from the page calling the template. Given that, you could do something like:
local foo = args.foo1 or args.foo2 or args.foo3 or ''
If args.foo1 is defined, its value is assigned to foo (if args.foo1 is an empty string, that becomes the value of foo). Otherwise, args.foo2 is used, and if that is not defined, args.foo3, and if that is not defined, an empty string (''). I'm not sure what exactly is wanted regarding Module:Infobox—do you mean to modify that module, or to make a template that could call the module but use different names for the parameters? That module is a bit too complex for me to want to examine it at the moment, but my guess would be that it has a loop to check for arguments named header1, header2, and so on, and that code would only work for those names. Working around that would probably be tricky and not worthwhile. If you have something simpler in mind, please give an example. Johnuniq (talk) 09:19, 7 December 2014 (UTC)
Thanks! About infobox module - no, I don't want to modify it, that was just an example. You kind of understood what I was trying to say, but currently I can't give an real example. I could describe in wikicode (in ..something.. there are some {{#if:}} and other stuff):
..something.. {{{foo1|{{{alias1|}}}}}} ..something..
..something.. {{{foo2|{{{alias2|}}}}}} ..something..
..something.. {{{foo3|{{{alias3|}}}}}} ..something..
..
..something.. {{{foo...|{{{alias...|}}}}}} ..something..
--Edgars2007 (talk/contribs) 10:43, 7 December 2014 (UTC)
@Edgars2007: Look at p.many in Module:Location map/multi. I think that's the same thing that you're trying to do. Jackmcbarn (talk) 16:43, 7 December 2014 (UTC)
Yes, it will be ok, thanks! --Edgars2007 (talk/contribs) 15:56, 8 December 2014 (UTC)

Change of mw.text.unstrip behavior

Starting December 10th, mw.text.unstrip will kill general strip markers instead of unstripping them. Nowiki strip markers will still be unstripped normally. See gerrit:171290 for details. This will break the following modules:

The following modules also use mw.text.unstrip, but they won't necessarily be broken by this change:

@Mr. Stradivarius, Wnt, Mxn, and Hellknowz: Ping, as each of you are the author of at least one of the above modules. Jackmcbarn (talk) 21:51, 1 December 2014 (UTC)

I still don't see why this is such a high priority. Perhaps unstrip is a mere hack, but it was a useful one, even with its substantial limitations. I don't understand why it is the exclusive right of external sites to keep track of a broad range of information like the list of items in a category (which unstrip wouldn't even do before), perhaps providing out of date reports via bot edits, rather than it being possible to keep track of such things from within Wikipedia in real time; but there is no denying this is the case. Wnt (talk) 03:16, 2 December 2014 (UTC)
The information isn't going away forever. I plan to add a proper way to retrieve it. Jackmcbarn (talk) 03:32, 2 December 2014 (UTC)
Bummer, unstrip() is essential to how wikt:vi:Mô đun:DynamicPageList works. It takes the output of <DynamicPageList> and adds anchor links and language tags based on some lookup tables that would be rather large to load client-side. It's used primarily on the Vietnamese Wiktionary's front page. (As for Module:Diff, the unstrip() call is meant specifically for use with <nowiki>.) – Minh Nguyễn 💬 08:25, 2 December 2014 (UTC)
@Mxn: You should ask for mw:Extension:DynamicPageListEngine to be deployed on that wiki. Jackmcbarn (talk) 15:54, 2 December 2014 (UTC)
Thanks for the tip. I filed T76844. Also, Kephir's wikt:Module:tagged but not listed is using the same unstrip() trick. – Minh Nguyễn 💬 09:47, 5 December 2014 (UTC)
Until T76844 is fixed, I've switched the Vietnamese Wiktionary's main page over to wikt:vi:Bản mẫu:Trang Chính/Mục từ mới, which avoids unstrip(). I'll look into applying the anchor links and language tags using JavaScript. – Minh Nguyễn 💬 11:08, 9 December 2014 (UTC)

How to #Invoke code in my user sandbox?

I have the "Hello, world!" code copied into User:Lesser Cartographies/sandbox/Bibliography of Paul Erdős/lua and thought I could get away with invoking this via {{#invoke:Module:User:Lesser Cartographies/sandbox/Paul Erdős/lua|hello}}, but that throws up "Script error: No such module". What's the approved method of invoking code that lives in Userspace? Alternatively, how do I #invoke code that resides on the same page?

(For those who are curious, the bibliography will have ~2k citations, which is well beyond the number of templates I can put in a page. It would also be nice to have a list of co-authors, a list of topics, etc., all of which I would much prefer to generate automatically from a table of citations. I has resigned myself to keeping this table offline, but taking a look at lua I might be able to construct a pretty nifty document where the data is kept on wikipedia.)

Lesser Cartographies (talk) 00:12, 15 December 2014 (UTC)

Lua code must reside in the Module namespace. There are two main ways that developers use to create their own sandbox version of modules:
  • Wikipedia:Lua#See also points to Module:Sandbox; you can create a subpage beneath this to hold your test module with the name "Module:Sandbox/<user name>/<module name>"
  • You can create a subpage within the Module namespace with the name "Module:User:<user name>/<module name>"
isaacl (talk) 00:26, 15 December 2014 (UTC)
@Isaac: That did the trick! Thanks for help, I really appreciate it. Lesser Cartographies (talk) 00:45, 15 December 2014 (UTC)
@Isaacl: ^ Isaac (talk) 03:42, 15 December 2014 (UTC)

Show preview

Just for curiosity, why there isn't "Show preview" button below editing window for modules? --Edgars2007 (talk/contribs) 15:59, 17 December 2014 (UTC)

Consider Module:String as an example. Which of those functions should be 'previewed'? And what parameters should Show preview pass to that function?
—Trappist the monk (talk) 16:08, 17 December 2014 (UTC)
Are we talking about the same button? :) I'm talking about this one. The "question" is - why can't I see how the code looks like, isn't there something screwed up (what isn't seen in the editing mode)? Just like for templates. Is it too much memory/resources consuming? --Edgars2007 (talk/contribs) 10:29, 18 December 2014 (UTC)
No formatting is possible at a module page so there is nothing that can be adjusted from a preview. A template may have stuff like noinclude or includeonly or default arguments, and these can affect what is displayed on the template page. For a module, however, the Lua code is pure text which either runs correctly or doesn't. I believe it is now not possible to save a module if it contains a compile error, so some blunders are prevented. Johnuniq (talk) 10:53, 18 December 2014 (UTC)
There is a Show preview button, next to an input box where you specify a page to display that makes use of the module. This lets you execute the code while passing it some parameters so you can test different inputs and see the output. The output from a Lua module is only visible by invoking it from a page, so it needs to be previewed using a regular Wikipedia page. Most modules need some input to display anything, so requiring you to specify a page where you can choose what input to provide is reasonable. Typically it is useful for a developer to write a test page that exercises different scenarios, and to preview this page during development. The traditional location for tests is the "testcases" subpage below a template; the "testcases" subpage below a module is also used by developers to write code that automatically verifies test cases (they typically then invoke this code on the talk page for the testcases subpage). isaacl (talk) 13:28, 18 December 2014 (UTC)
Forgot to say - thanks :) --Edgars2007 (talk/contribs) 13:45, 26 December 2014 (UTC)

Imagemap

I am about to extend our quickbar moduel with an imagemap. I can not create the parser tag imagemap with Lua as well as the tag <imagemap>...</imagemap> because they are not being parsed. It seems i should create a classic image map with <img>...</img> and <map>...</map>. Has anybody done it already? if not, i have a question. I think i will need the full url of a commons file that I put into the image-tag. How can i get the fullurl of a given commons file name with Lua? -- DerFussi 18:59, 19 January 2015 (UTC)

The problem you are having with <imagemap>...</imagemap> is that it is an extension tag, not an HTML tag. By the time Lua code is executed extension tags have already been processed, thus Lua code cannot use extension tags in its output text. However, your Lua code can use frame:extensionTag to invoke the ImageMap extension tag. See w:de:Modul:LRR for an example. —RP88 (talk) 22:03, 19 January 2015 (UTC)
Thanks. I haven't been aware of the frame:extensionTag. This should solve my problems.... -- DerFussi 04:40, 21 January 2015 (UTC)
It works... Thanks. -- DerFussi 07:42, 21 January 2015 (UTC)

Multiple functions shares the frame

For example - I know it can do easily in one function - just for example:

{{#invoke:example|main|Italic|Bold}} -> "Italic and Bold"

I tried below but failed: 

local p = {}
local getArgs = require('Module:Arguments').getArgs

local args = getArgs(p.frame)

local function func1()
    local t
    t = "<i>" .. args[1] .. "</i>"
    return t
end

local function func2()
    local t
    t  = "<b>" .. args[2] .. "</b>"
    return t
end

function p.main()
    local t
    t = func1() .. "and" .. func2()
    return t
end

return p

Declare args as global in p.main is okey, but that's not a better way. How to change local args = getArgs(p.frame)?--CAS222222221 07:37, 24 January 2015 (UTC)

A correct but not tested way of writing this would be as follows. 

local function func1(text)
    local t
    t = "<i>" .. text .. "</i>"
    return t
end

local function func2(text)
    local t
    t  = "<b>" .. text .. "</b>"
    return t
end

local p = {}
function p.main(frame)
    local getArgs = require('Module:Arguments').getArgs
    local args = getArgs(frame)
    local t
    t = func1(args[1]) .. "and" .. func2(args[2])
    return t
end

return p

By the way, if the purpose is to create html, see Module:HtmlBuilder. Johnuniq (talk) 03:43, 25 January 2015 (UTC)

Thank you, Johnuniq! --CAS222222221 06:09, 25 January 2015 (UTC)
@Johnuniq and CAS222222221: Please do not use Module:HtmlBuilder. Use mw.html instead. Jackmcbarn (talk) 19:52, 25 January 2015 (UTC)

Infobox challenge

I've put up a challenge at meta {{infobox}}. Enjoy. -DePiep (talk) 21:43, 25 January 2015 (UTC)

Lua support on Wikimedia

I whined about the lack of support of Lua on WM in Jimbo's talk page. And you guys gave me materials which aren't helpful. This is my scenario why the support manuals are lacking: I want to know how to use "for i". Tim Lua.pdf tells you there is an iterator for and the excerpt of the code without telling you what it means and what it does; mw:Extension:Scribunto/Lua reference manual only tells me the usage of "for" but doesn't say what result it gives. Then I searched external tutorial like this one and it tells you for i = 5, 11, 0.5 do will return 5,5.5,6,6.5.... When I try it in WP. Tada! It only returns the initial. This is why I'm getting so frustrated. Almost none of the tutorials on WM or MW teach novice something that basic. Many of them tell you the very basic then jump to the advanced specification which no novice would understand. And almost none of the external tutorials are applicable in WM. -- Sameboat - 同舟 (talk · contri.) 23:34, 27 January 2015 (UTC)

Yes, you're right. However, it would similarly be hard for someone with no experience to learn how to do tables or templates from the docs. The Lua information is more obscure than tables/templates because the latter have been around for years longer. If you want to learn Lua, the only way is to download and install Lua to a local computer. Then you can fiddle and work out the basics. An IDE like ZeroBrane Studio would help. However, after getting the code you want, you then have to put it into a module, and debug it here. That ain't easy. I don't know much about debugging here because I put all my effort into constructing tests that emulate what is needed, however I think you can put mw.log(x) or mw.dumpObject(t) in a module to see messages in the debug console (x is a variable like a string or a number, and t is a table). Johnuniq (talk) 00:40, 28 January 2015 (UTC)
I'd be interested to see how to make the debugging to work with ZeroBrane Studio for modules in pages, but I don't enough about Wikimedia pages to set it up. If you are running the site locally (and I don't know if that's the case), you only need luasocket support and ability to load modules (so one can load the debugger). I've posted remote debugging instructions [here]. If somebody is interested enough, I can help from the ZBS side to see if it works . Paulclinger (talk) 06:27, 22 February 2015 (UTC)
At least mw:Help:Extension:ParserFunctions tells you how to use those logical operation magic words and what results they give so I can learn by myself. I guess the parser functions manual is that concise because those magic words are invented by MW. The Lua reference manual on the other hand provides no instruction about all the "tokens" (if/else/for/do/while/repeat) AT ALL, the manual simply tells you they are there (for no obvious reason to novice). The manual has existed for more than 2 years but still no one attempts to explain all those tokens in the similar fashion as in the parser functions manual. -- Sameboat - 同舟 (talk · contri.) 01:17, 28 January 2015 (UTC)
For the record, the problem with Module:Sandbox/Sameboat/m1 only returning "the initial" value isn't with the for loop, it is with the "return" statement. The function exits once return is called, so the rest of the for loop is not being executed. One simple approach would be to create a local variable, append the result from each iteration of the loop to that local variable, and then return the local variable after the end of the loop. Dragons flight (talk) 01:40, 28 January 2015 (UTC)
I still don't understand how to get the result from the loop, either the results of all steps or one specific step (e.g. step 2, which should be "5.5"). How should that be written in the module? -- Sameboat - 同舟 (talk · contri.) 02:07, 28 January 2015 (UTC)
One issue is at User:Sameboat/x1 where {{{1}}} is used. That syntax only works in a template definition and is never useful or needed when invoking a module. See my comments above for how a module should get its arguments using standard Scribunto. I know that's a bit weird but experiments should eventually make its meaning clear.
In Module:Sandbox/Sameboat/m1 using f=tonumber(f)*i is not a good idea because the f on the right hand side is the first argument passed from the invoke (which is a string consisting of seven characters, namely {{{1}}}). Since f is not a number, tonumber(f) gives nil, and multiplying nil gives error "attempt to perform arithmetic on a nil value". The cure is to either provide a default, or to quit with an error.
Default: f = (tonumber(f) or 1) * i
Quit: local n = tonumber(f); if not n then return 'Error: not a number' end
In the invoke, replace {{{1}}} with, for example, 12 (a number) to avoid the error.
Simultaneously learning Lua and Scribunto (which means there is no easy way to debug) is near impossible. Installing Lua is fast and easy. Special:Version shows that Lua 5.1.5 is used here, and there would be subtle issues with a newer version of Lua, but the basics will be exactly the same, and they need to be mastered first.
After you try some of this, if you want I will edit the module so it returns all the values, concatenated. Johnuniq (talk) 02:35, 28 January 2015 (UTC)
That's how I did it, learned the two at the same time. I did it on test2 so my experiments would not cause any problems, but they went well enough that I ported them over to here to become Module:Zh learning more in the process. Now with so many examples, with improvements to the environment to enable basic debugging and testing, it should be even easier. It's probably especially easy as assuming you're learning Lua to write modules then that's what all the examples are; chances are for any problem you have a module already exists that's solved it, perhaps even one you can call to do the work directly. Saves you unlearning anything you pick up installing and becoming familiar with another environment too.--JohnBlackburnewordsdeeds 03:25, 28 January 2015 (UTC)

Module check

I want to add an modul via mw.loadData('Modul:ISO 3166-2/' .. foo). In that case foo is an option provided by the user. But firstly i want to check, whether the modul Modul:ISO 3166-2/foo exists. How can I check, whether a module exists to generate a hand made error message? -- DerFussi 19:52, 5 February 2015 (UTC) 

	local success, data = pcall(mw.loadData, 'Modul:ISO 3166-2/' .. foo)
	if not success then
		return "error message"
	end
I hope this works. Otherwise you can use title API and check whether the title exists. Paweł Ziemian (talk) 20:12, 5 February 2015 (UTC)
THanks. Going to try it today... -- DerFussi 07:04, 6 February 2015 (UTC)
Just confirming that yes, pcall is the standard way to do this. You shouldn't need to use the mw.title library to check for page existence, and even if you did it wouldn't guarantee that the target page was a valid data module. — Mr. Stradivarius on tour ♪ talk ♪ 08:05, 6 February 2015 (UTC)

Testing and validation help

I've made a very simple module to replace Archive list long performing an exponential search algorithm that should greatly reduce the number of expensive parser function calls, but I can't figure out how to properly fire up a testsuite or how to put up template tests, and I'm really out off my depth with parameter validation. Could someoneone see if they could lend me a hand with Module:Archives? Martijn Hoekstra (talk) 22:25, 13 February 2015 (UTC)

The usual thing to do is create a sandbox version of the template, which calls your module, and a testcases page which can be used for tests. You can use the links provided by {{documentation}} to create them, add that template to the sandbox and {{Testcases notice}} to the testcase page. You can arrange the latter how you like but it's usual to put examples of the current and sandbox template side by side, differing only in which template they call. Add as many as you need to test the new/changed version. See Template:Zh/testcases for an example.
(note the module can have a sandbox too. Once a module goes live changes that need testing should not be made to it but to its sandbox, which is then invoked by the template sandbox. But that's not needed for the first version of the module, which itself is the new implementation being tested).--JohnBlackburnewordsdeeds 05:25, 14 February 2015 (UTC)
I've added templates, additional testcases to the {{Archive list long}} subpages. No problems I can see with the examples but you are more familiar with it and will have a better idea of examples to test it I think.--JohnBlackburnewordsdeeds 05:41, 14 February 2015 (UTC)
Thank you very much for the help and the examples. The thing is, those are test transclusions of {{archives}} rather then {{archive list long}}. But as far as I can tell archive list long is never called directly. These test - which is the only way I found to test - introduce a dependency between the sandbox versions of different templates, which to me seems really inadequate for a solid test, but I haven't been able to figure out a better way to test. Martijn Hoekstra (talk) 11:13, 14 February 2015 (UTC)
If you're looking to test the module directly, we have two test case framework modules, Module:ScribuntoUnit and Module:UnitTests. My latest effort is at Module:Class mask/testcases, with the results at Module talk:Class mask/testcases, but there are several other examples of test case modules dotted around which shouldn't be too hard to find. — Mr. Stradivarius ♪ talk ♪ 12:38, 14 February 2015 (UTC)
Ah, I just took the one there and duplicated it with /sandbox added, then created another pair underneath with different parameters. It was only meant to be indicative of how it can be done. As for testing that's always how I've done it: created the Module then found some way of testing it, on test2 live, on en.wp in the sandbox. It sometimes means I'm checking in two, three, four times in a row to get a version that does what I want but it's at least quick with well constructed test cases; I need only save a version and refresh the test cases to see if it's doing what I want, or if not which tests it's failing so what's broken.--JohnBlackburnewordsdeeds 13:20, 14 February 2015 (UTC)

Template:Markup rewrite

Is the right place to discuss about modules' Lua rewrite? Anyway, I think it's time to make a rewrite of {{Markup}}. When you insert a table into it, the layout crashes. That's the main reason to switch it to Lua. --RezonansowyakaRezy (talk | contribs) 12:33, 18 February 2015 (UTC)

attempt to concatenate local 'rand_val' (a nil value)

Welcome.

I'm from Polish Wikipedia, and I was interested in this Lua language. I've copied the three modules from the English Wikipedia (original: 1., 2. and 3.). They were used in [ https://pl.wikipedia.org/wiki/Premier-liha_(2014/2015) this article] and the problem happened. The error has showed up, and said that:

Lua error in module "Moduł:Tabela sportowa/sub", in line 30: attempt to concatenate local 'rand_val' (a nil value).

Backtrace:
1.Moduł:Tabela_sportowa/sub:30: in function „hth”
2.Moduł:Tabela_sportowa/ZRP:62: in function „row”
3.Moduł:Tabela_sportowa:287: in function „chunk”
4.mw.lua:511: ?

Can you help me with this problem? Thanks for your support.

Here are the links:
[4]
[5]
[6]

77.95.54.166 (talk) 15:28, 2 March 2015 (UTC)

You forgot about two parameters ii_start and ii_end in /ZRP:62, which are declared in /sub ppp.hth. The last rand_val is passed in position of ii_start, and thus the real rand_val in the last function is nil. Paweł Ziemian (talk) 19:55, 2 March 2015 (UTC)

Breaking up Module:Citation/CS1 into multiple modules: How to?

Module:Citation/CS1 is now over 100kB. I'd like to split out parts of it into smaller pieces: a common utilies page, a page for the identifiers function (ISBN, PMC, arXiv, et), perhaps a page dedicated to presentation, etc.

Currently, Module:Citation/CS1/Date validation is 'required' in Module:Citation/CS1:

dates = require('Module:Citation/CS1/Date_validation').dates

which allows me to call function dates() from Module:Citation/CS1. Recently I added a new function to Module:Citation/CS1/Date validation/sandbox. I wanted to make it a separate function call but was unable to get it to work and have ended up incorporating it into the date validation code.

So, I guess what I want to know is:

What is the best way to make multiple functions in a module available to other modules? For example, a common utilities module might have functions a(), b(), and c(). If I want to call a() and c() from Module:Citation/CS1 and b() from Module:Citation/CS1/Date validation, how do I do that? Anybody have any examples of modules that do this sort of thing? Is there documentation for this someplace?

—Trappist the monk (talk) 16:32, 5 March 2015 (UTC)

Is this about defining them public in the utilities module?:
function p.b() -- callable from other module
local function c() -- not good
Made it work in module:Track gauge and module:Track gauge/autodocument (warning, not exemplary code). -DePiep (talk) 21:24, 5 March 2015 (UTC)
A module that has functions to be used elsewhere needs to include each exported function in the single table that is returned at the end. Conventionally people do what DePiep mentioned (and which I'm sure you know about), but I like to define all functions as local, then end the module with something like
return { convert = main_convert, validator = date_validator, adder = adder }
In the above, the rhs items (main_convert, date_validator, adder) are local functions, and the lhs items (convert, validator, adder) are the exported names that other modules or invoke will use.
It may sometimes be desirable to adopt a convention to show which exported names are intended for invoke, and which are functions (or tables) to be called from other modules (perhaps prefixing each of the latter with an underscore). I can't see that would be needed in citation/cs1.
You just need something like this (using made-up names):
local validation = require('Module:Citation/CS1/Date_validation')
local dates = validation.dates
local checker = validation.checker
The above would be in whatever module needed dates and checker. Some other module might use the following to access something a little different:
local validation = require('Module:Citation/CS1/Date_validation')
local dates = validation.dates
local formatter = validation.formatter
The Date_validation module would have to export dates, checker and formatter. If there is something specific you would like an opinion on, let me know. Johnuniq (talk) 01:35, 6 March 2015 (UTC)
Hmm, this works:
In Module:Citation/CS1/Date validation/sandbox I did this:
local p = {}
function dates(date_parameters_list) ... end
function year_date_check (year_string, date_string) ... end
return {dates = dates, year_date_check = year_date_check}
In Module:Citation/CS1/sandbox I did this:
date_val = require('Module:Citation/CS1/Date_validation/sandbox');
That variable date_val is never used which means that dates() and year_date_check() are global. Because of how Module:Citation/CS1 selects which files to mw.loadData() or require() (sandbox v. live), making dates() and year_date_check() local at the place where I require() the date validation module would necessarily limit their scope to z.citation(). Right?
So then, I changed to this:
In Module:Citation/CS1/Date validation/sandbox I now have:
local p = {}
function dates(date_parameters_list) ... end
function year_date_check (year_string, date_string) ... end
return p
and in Module:Citation/CS1/sandbox I have:
require('Module:Citation/CS1/Date_validation/sandbox');
This also works. It does mean that I should declare all functions except dates() and year_date_check() in Module:Citation/CS1/Date_validation/sandbox as local so that they can only be used within the scope of Module:Citation/CS1/Date_validation/sandbox which I have done.
I think that, for the time being anyway, I'm content with this solution. I don't know how well this will work when multiple modules need access to functions in yet another module. I'll get to that after the next update to the live CS1. Thanks for the insights.
—Trappist the monk (talk) 14:18, 6 March 2015 (UTC)
I like to avoid globals mainly because it's useful to check that no global variables have inadvertently been created with a typo (for example, code might have local count = 5 but later refer to cout instead of count, which would make cout a global). Module:Citation/CS1/sandbox has 71 globals and it would be hard to check which are intended (what is AirDate for example).
Re "would necessarily limit their scope": yes, it would. If wanted, the "correct" way to handle that is something like this:
Near the top of Citation/CS1/sandbox (not in a function):
local dates, year_date_check -- forward declarations
later in same module:
local validation = require('Module:Citation/CS1/Date_validation/sandbox');
dates = validation.dates
year_date_check = validation.year_date_check
Johnuniq (talk) 00:13, 7 March 2015 (UTC)
Hmm, didn't work (at least it didn't work as I implemented it): Lua error in Module:Citation/CS1/sandbox at line 2018: attempt to call upvalue 'dates' (a nil value).
How did you find out how many globals are in Module:Citation/CS1/sandbox? AirDate is used by {{cite serial}} and {{cite episode}} niether of which are currently supported by the module but are up next for migration from {{citation/core}}. AirDate is included in the call to dates() so that I don't forget about it.
—Trappist the monk (talk) 14:01, 7 March 2015 (UTC)
It didn't work because Date_validation/sandbox currently exports an empty table—it would work if that table exported the two functions (which should be local in Date_validation).
Do you want me to fiddle with the sandbox modules? I would try hard not to interfere with the style, but I could do what I hope would be fairly minor edits to remove the globals, or at least greatly reduce them. You are welcome to revert what I do if it doesn't suit, but I would need to know you wanted the job of checking my edits, and that we weren't going to conflict with each other (that is, you would stop editing until I'd finished in perhaps 24 hours).
Re finding globals: I have installed Lua on a local computer and written a script to do some funky stuff with luac (the Lua compiler). It finds all occurrences of GETGLOBAL and SETGLOBAL and extracts the name of the variable. I failed to find a lint program so wrote my script, but I see that there is an "Analyze" function in ZBS (see next), and there may be other tools available now (I set up my system in September 2012 and it's unchanged apart from a recent investigation of ZBS which was not available when I started).
I have a test system where I run Module:Convert (and its related modules) locally. I can do that in an IDE and insert breakpoints, watch variables and single-step the code—it's cheating, but it gets the job done! After changing the code, I run 25,000 tests on my computer (in under 5 seconds) then run diff on the output, and examine what has changed since the last run. The massive citation and convert modules are probably abuses of Scribunto, but they work, although I would not have the patience to debug on-wiki. I use Decoda (Windows) but am trying to switch to ZeroBrane Studio (ZBS, multi-platform) because the old version of Decoda that I use has a couple of frustrating bugs, mainly the fact that it cannot handle UTF-8. ZBS likewise has some glitches (there is no list of breakpoints), but it is actively developed and likely to improve (it was unusable when I first looked at it a year or so ago). The main part of my test system is a Lua program to crudely emulate what convert needs from the mw library (which is not much). I mentioned it a couple of years ago but there was no interest, so I have continued to tweak it for my own use. It would be possible for me to do a bunch of things to make it more generic, and you could run the citation modules locally in an IDE. Let me know if the hours of setting up and learning new software appeals and I'll see what I can do. One problem is that convert's input and output is short and simple, so my system is line-based (input template and expected output are on a single line). Citations would need more, although long single lines would work for debugging. My system has many limitations in that its emulation of mw is extremely limited, for example I have implemented mw.ustring.len, but mw.ustring.lower simply calls Lua's lower which does not work on UTF-8. Johnuniq (talk) 04:03, 8 March 2015 (UTC)
Doh! Yep, works now.
I don't think that I want to allow Wikipedia to consume any more hours of my life than I already give it, so I think I'll choose to not do what you have done but I do admire your willingness to help me do it.
If you have nothing better to do with your life, a second pair of eyes on the CS1 modules is a good thing and would be appreciated. I think that for the moment, I am at a convenient stopping place and expect to do nothing with them for the next little while. But let me repeat this: If you have nothing better to do with your life ... thanks
—Trappist the monk (talk) 15:38, 8 March 2015 (UTC)

#iferror

Hi! How to do iferror in Lua (or like below)? 

if isError( func(a) ) then
    ret = a
  else
    ret = func(a)
end

--CAS222222221 (talk) 04:38, 10 March 2015 (UTC) 

local success, ret = pcall(func, a)
if success then
    -- Don't need to do anything; ret = func(a)
else
    -- The call to func(a) failed.
    ret = a
end

Johnuniq (talk) 06:03, 10 March 2015 (UTC)

Thanks for your help :) --CAS222222221 (talk) 06:25, 10 March 2015 (UTC)

Can we preset a parameter in the template code?

Is it possible to add a parameter setting to the invoking template, and pass other parameters (from article page) just as well? For example:

Basic usage: Template:Convert 

{{#invoke:Convert|convert}}

Alternate template: Template:ConvertNoAbbr 

{{#invoke:Convert|convert|abbr=off}}

-DePiep (talk) 12:13, 20 March 2015 (UTC)

Yes, it is possible. The module has to be written in such a way to look for arguments in both the invoking frame and the parent frame. Module:Arguments is a general utility for doing things like that. Module:Citation/CS1 also contains an example of looking in both places (in function "z.citation") with some customization appropriate for that case. Dragons flight (talk) 17:42, 20 March 2015 (UTC)
Thanks. For me, consider this answered (more details now would be too much). From here I'll have to go to Template talk:Convert. -DePiep (talk) 18:59, 20 March 2015 (UTC)
@DePiep: Convert already handles configuration of abbreviations as that was required for other Wikipedias. See the transwiki docs which show that the convert template can force abbreviations on or off, or can make them default to on or off. The option is used at sl and zh, and was used at fa. Johnuniq (talk) 06:29, 21 March 2015 (UTC)
It's not about abbr. That is just a simple example to show the technique. I actually think of using this for radiowaves and Mach, see our discussion at template talk:convert. -DePiep (talk) 08:23, 21 March 2015 (UTC)
Using frame.args to store config and frame:getParent().args for the actual arguments isn't good practice, in my opinion. It's better to store the config in a separate config module so that it doesn't have to go through the PHP parser before it enters Lua. With a separate module you can also load it with mw.loadData so that it is only parsed once per page, not once per #invoke. — Mr. Stradivarius ♪ talk ♪ 14:37, 21 March 2015 (UTC)
And then, use that other config by calling an other function? {{#invoke:Convert|function2}} -DePiep (talk) 15:00, 21 March 2015 (UTC)
That's probably the easiest way of doing it, yes. You can also use different configs for different templates by detecting the template name with frame:getParent():getTitle() (the drawback of that approach is that it stops working if the template is moved). By saying "other config" you seem to imply that there would be a separate config module for each template, but that doesn't have to be the case. You can do it all with one config module - you just need to have a way to differentiate between templates, say a subtable with function names as keys. — Mr. Stradivarius ♪ talk ♪ 15:21, 21 March 2015 (UTC)
It's off-topic here but I may as well explain that I agree with your approach in general, however there is a reason for convert's config-by-template. Convert has a tremendous amount of stuff that is configurable, mainly for localization at other Wikipedias, and that is all in a module (for example, see bn:Module:Convert/text). However, some small wikis don't have anyone who is comfortable editing a module, even for something as simple as changing a couple of config settings, so a very small number of items can be configured via the template. They are things that people would probably want to experiment with to try the effect, such as whether abbreviations should be forced on or off, and they can't use another template because the whole idea is to see how a change looks in articles using convert. In practice there are very few adjustments made to convert so config-by-template may not be useful, although I noticed one adjustment at fawiki. Johnuniq (talk) 06:05, 22 March 2015 (UTC)

Proposal for moving discussion of modules to TfD

There is a pending proposal at WP:VPR#Templates to nominate Lua modules for discussion or deletion at WP:TFD instead of WP:MFD. Please comment there. (I assumed the Lua project had already been notified, but apparently it hadn't.) SiBr4 (talk) 12:21, 22 March 2015 (UTC)

How to separate ref tags?

Hi! I want to do something like {{#invoke:Example|func| Foo<ref>bar</ref> }} -> ''Foo''<ref>bar</ref>. But I can't separate <ref> from the parameter. I tried in there, and output appears it was failed. (See HTML sources, <ref>s are in <i>...</i>) Is there any way to deal with that? Thank you. --CAS222222221 (talk) 07:48, 5 April 2015 (UTC)

I edited the module. I'm not sure how you know that the previous code was failing to find references because there was no visible indication of that. To prove that the new code is finding the references I inserted "hello" before where they begin. Some tags such as <ref> do magic things in the wikitext, and they are replaced with strip markers (see WP:UNIQ). That is, each ref is removed from the wikitext (stripped), and is replaced with a complex string that is hoped will be unique. If that complex string appears in the final wikitext, it will be processed to generate a reference. Johnuniq (talk) 09:55, 5 April 2015 (UTC)
Thanks for your help~ --CAS222222221 (talk) 11:22, 5 April 2015 (UTC)
Johnuniq, I'd love to be able to strip & reuse refs from input strings. Is this method stable & acceptable? I remember it is not published by wm as externally available (ie not a documented feature). -DePiep (talk) 13:18, 5 April 2015 (UTC)
Strip markers are back-room stuff which could change, so if we write templates that muck around with them we should be prepared to rewrite them if the mechanism is altered. However, it is likely that strip markers will be stable for a long time. The edit I made would need work to be more general because the premise was that the input was of the form "text<reference>", and the question was to find the place where the reference starts. I'm occupied elsewhere and can't do anything on this now, but a more general solution would involve a loop to extract all text and reference pairs. That would handle something like "text1<reference1> text2<reference2> text3<reference3>". I think a pretty good reason would be needed to manipulate stuff like that—I guess you are thinking of extracting references from what people enter in infoboxes. I suppose something could be done, but the result would never be ideal because a module cannot parse anything that an editor types into an infobox field—someone could always write text that would cause an automated approach to give garbage output. Johnuniq (talk) 02:11, 6 April 2015 (UTC)

MfD nomination of Wikipedia:Lua/Modules

Wikipedia:Lua/Modules, a subpage within this WikiProject, has been nominated for deletion. Your opinions on the matter are welcome; please participate in the discussion by adding your comments at Wikipedia:Miscellany for deletion/Wikipedia:Lua/Modules and please be sure to sign your comments with four tildes (~~~~). You are free to edit the content of Wikipedia:Lua/Modules during the discussion but should not remove the miscellany for deletion template from the top of the page; such a removal will not end the deletion discussion. Thank you. Steel1943 (talk) 19:34, 20 April 2015 (UTC)

Article Splitting Templates @Wikiquote

There seems to be a programming issue that prevents Wikiquote editors from following the Wikipedia procedure for splitting articles (Wikipedia:Splitting) in order to preserve the article history track. That procedure is not being followed at Wikiquote due to the lack of necessary templates such as Template:Copied and Template:Split_from. I am assuming that the reasoning behind the procedure for preservation of the article history would be similar, if not the same, at both Wikipedia and Wikiquote. There was only one response to my inquiry about this matter at the Wikiquote Village Pump (Village pump: No "Template:Copied" or "Template:Split from" for Splitting?), which stated that these necessary templates depend upon other templates which do not apply to Wikiquote articles...

Matthew Dann suggested posting to you here as the experts, since, in response to the above inquiry, he imported what he could, but said that it's still throwing an error. Thank you, ELApro (talk) 20:05, 10 March 2015 (UTC)

Please provide a link to a page showing a problem, and briefly describe what it is at the page that is a problem. There would probably be better advice available at WP:VPT, but people don't want to spend time hunting to discover what the problem is. Johnuniq (talk) 22:05, 10 March 2015 (UTC)
The English Wikipedia has developed a complicated set of templates, modules, CSS files and so on working together. wikiquote:Template:Tmbox shows you are missing Module:Message box, but you probably also need a lot of other stuff to replicate us. Preview a page or section which is blank apart from using the template you want with parameters you want to work, for example at Template:Copied#Example. Then click on "Templates used in this preview" at the bottom. This gives a list of used templates and modules, but not CSS files with styling the display may rely on. The list may also depend on details like which namespace you are in and whether certain categories exist. And if you change parameters in the template use then different templates and modules will sometimes be activated so it can be rather complicated. PrimeHunter (talk) 01:23, 11 March 2015 (UTC)
I've rolled back to the last non-Lua version when I realised just how many dependence there were - just some css to update that way. Thanks all. Mdann52 (talk) 09:30, 11 March 2015 (UTC)

Just a few problem pages are listed at the link above (Village pump: No "Template:Copied" or "Template:Split from" for Splitting?) including God Is Not Great. There are many more. What it is at the pages that is a problem (not following Wikipedia procedural standards for article history tracking) is also described in the same referenced Village pump linked article. Thanks again for your response. ELApro (talk)

Template:Copied is now functioning within a limited capacity (with respect to Wikipedia). See wikiquote "Category:Pages using copied template" for a few example pages utilizing the template to date. I do not know about the rest of the Wikiquote community, but I am happy with this new capability, even as it now exists. Thanks for your help Mdann52 ! ELApro (talk) 12:00, 28 April 2015 (UTC)

Lua error: not enough memory

This morning I added a new function to Module:Citation/CS1/sandbox. A simple function, it is intended to replace similar inline code that appears in multiple places. But, this function is giving me the Lua error: not enough memory error message (clicking on the error message reveals that no further information available – not so helpful, that).

With the entire content of the function commented out, I don't get the error message. 

local function name_has_etal (name, etal)
--	local pattern = ",? *'*[Ee][Tt] *[Aa][Ll][%.']*$"							-- variations on the 'et al' theme
 
--	if name:match (pattern) then												-- variants on et al.
--		name = name:gsub (pattern, '');											-- if found, remove
--		etal = true;															-- set flag (may have been set previously here or by |display-authors=etal)
--		if true ~= Page_in_etal_cat then										-- if we haven't been here before
--			Page_in_etal_cat = true;											-- set a sticky flag (global)
--			add_maint_cat ('etal');												-- and add a category
--		end
--	end
--	return name, etal;															-- 
end

If I uncomment the return I get the error message. Am I doing something wrong here? Is the error message telling me that Module:Citation/CS1/sandbox has grown too large and that I've run up against some hard limit?

—Trappist the monk (talk) 10:53, 30 April 2015 (UTC)

I wouldn't think you have hit a limit—Barack Obama has a NewPP report saying "Lua memory usage: 7.97 MB/50 MB". Your code must be looping. If you have a sandbox showing the problem I'll have a look (although I have to go soon). Which revision of Module:Citation/CS1/sandbox has the problem, and is there a sandbox that invokes the module and which demonstrates the problem? That is, what is the input that shows the error? It's puzzling because I've looked at the code for a couple of minutes and cannot see how it could loop. I wondered if a bad pattern could cause the gsub to loop, but I don't see how (and the pattern looks fine). When it's fixed I'll offer a suggestion about removing variables like Page_in_etal_cat (function add_maint_cat should keep a set and ignore attempts to add the same key twice). Johnuniq (talk) 12:01, 30 April 2015 (UTC)
Thank you. I've created {{Cite_book/new5}} which uses Module:Citation/CS1/sandbox5 where I have enabled just the return name, etal; in name_has_etal (). Examples of this error message can be seen at Template talk:Cite_book/new5 compared to Module:Citation/CS1/sandbox in which name_has_etal () is as shown above.
—Trappist the monk (talk) 12:54, 30 April 2015 (UTC)
I fixed the problem and added some notes at Template talk:Cite book/new5. Johnuniq (talk) 01:49, 1 May 2015 (UTC)

Automating infoboxes from Wikidata

Hi. Do you have a category similar to this one on fr-wiki in English? I'm trying to populate fileds in a Wikipedia article automatically using info from Wikidata. Thanks. Llywelyn2000 (talk) 05:43, 6 May 2015 (UTC)

We no longer need to avoid reading arguments due to references getting out of order

gerrit:181112 was just merged and will be live here a week from today. Once it gets here, references will only appear in the reflist if they appear in the final page output, meaning that it's safe to read template parameters containing them without worrying about phantom references. Also, the numbering of references will depend only on the order they appear in the final page output, so reading template parameters "out of order" will no longer break anything either. The main takeaway of this is that using pairs(frame.args) will no longer cause any weird references behavior. Jackmcbarn (talk) 16:26, 13 May 2015 (UTC)

Hurrah! This means that we'll be able to simplify Module:Infobox without anything breaking. :) Thank you for your work on this. — Mr. Stradivarius ♪ talk ♪ 16:44, 13 May 2015 (UTC)
@Mr. Stradivarius: I've applied this fix (and a few others) in Module:Infobox/sandbox. Do you want to look it over before I deploy it? Jackmcbarn (talk) 15:32, 24 May 2015 (UTC)
@Jackmcbarn: Looks good to me. Feel free to deploy when you're ready. — Mr. Stradivarius ♪ talk ♪ 04:27, 25 May 2015 (UTC)

Update: With gerrit:216688, the above will no longer be true, so I've reverted the changes here that depended on it. Jackmcbarn (talk) 16:00, 8 June 2015 (UTC)

Template demo

I often need to write template demos in talks and documentation, like this.

In edit mode I write:

<code><nowiki>{{Convert|10|km|nmi|abbr=off}}</nowiki></code> &rarr; {{Convert|10|km|nmi|abbr=off}}

to produce in visible result:

{{Convert|10|km|nmi|abbr=off}} → 10 kilometres (5.4 nautical miles)

I wonder if it is possible to create a Module:DemoTemplate that has the intuitive input once

{{DemoTemplate|1={{Convert|10|km|nmi|abbr=off}} }}
or
{{DemoTemplate|Convert|10|km|nmi|abbr=off}}
or ...

to produce that same line. ping Johnuniq -DePiep (talk) 20:28, 10 June 2015 (UTC)

@DePiep: Done, with the latter case. Example: {{#invoke:DemoTemplate|Convert|10|km|nmi|abbr=off}} → {{Convert|10|km|nmi|abbr=off}} → 10 kilometres (5.4 nautical miles). Note that this probably handles edge cases like equals signs or pipes in parameters wrong. Jackmcbarn (talk) 20:52, 10 June 2015 (UTC)
(ec) Wow! Thank you, will need more to to play with this. -DePiep (talk) 20:56, 10 June 2015 (UTC)
So the diff by regular template input is, in red:
{{#invoke:DemoTemplate|Convert|10|km|nmi|abbr=off}} shows
{{Convert|10|km|nmi|abbr=off}} → 10 kilometres (5.4 nautical miles)
Can that be template-ised? -DePiep (talk) 21:10, 10 June 2015 (UTC)
I suppose it can, but it would make it harder to use, since saying (for example) 2=foo=bar would lead to 1=foo=bar then. Are you sure it's necessary, just to avoid a #invoke? Jackmcbarn (talk) 01:20, 11 June 2015 (UTC)
No, not necessary of course. It's the ease of use, without mistakes. Remember: a single intuitive input for those two outputs. What would Template:DemoTemplate look like? -DePiep (talk) 01:30, 11 June 2015 (UTC)
You'd call it just like in your original request (the second one), which is easier in "normal" cases, but is trickier in edge cases. Example: {{#invoke:DemoTemplate|1x|1=Some parameter with an = sign in it}} produces {{1x|1=Some parameter with an = sign in it}} → Some parameter with an = sign in it. You couldn't do that with the template version, because your "1=" would overwrite the name of the template you're demoing. Instead, you'd have to use "2=" which it would translate to "1=". This doesn't happen with direct #invoke, since the function call doesn't count as a parameter. Jackmcbarn (talk) 01:35, 11 June 2015 (UTC)
Anyway, thanks again. I'm happy using it. -20:25, 14 June 2015 (UTC)

Tabs

Hi, with the recent changes in mw:Extension:SyntaxHighlight GeSHi tabs are rendered in HTML as 8 space both for Lua (example Module:Purge) and JavaScript (example MediaWiki:Gadget-switcher.js). Is there a way to return to 4 spaces? --Rotpunkt (talk) 15:09, 26 June 2015 (UTC)

@Ori Livneh: ping. Jackmcbarn (talk) 15:58, 26 June 2015 (UTC)
The code rendering tabs as 4 spaces is in MediaWiki:Common.css (search for "geshi"). The class has changed from mw-geshi to mw-highlight, which is why the CSS has stopped working, but I don't trust myself to change it until I've had some sleep. — Mr. Stradivarius ♪ talk ♪ 16:48, 26 June 2015 (UTC)
Hi, thanks! @Mr. Stradivarius Actually I already used it in itwiki last year (diff) :) but as you said, it stopped working with the recent changes in the extension. --Rotpunkt (talk) 20:22, 26 June 2015 (UTC)

Proposed change to Module:Portal and subpages

Could someone please comment over at Template talk:Portal#Image function of Module:Portal? With such a heavily used module I'd like a second pair of eyes on my code instead of unilaterally moving it live. SiBr4 (talk) 22:55, 26 June 2015 (UTC)

Uncovered an obscure bug, possibly

Tracked in Phabricator
Task T14974

It would seem that, when: a Lua module is #invoked; and wrapped (transcluded) or substituted; and it follows any other text and a new line; and it returns an asterisk list; then, the return value is prefixed with a new line. You can see it happening here. If others could confirm that I'm not doing anything stupid, I'll report it on Prabricator. Alakzi (talk) 18:12, 16 July 2015 (UTC)

@Alakzi: That's actually one of the oldest and most infamous bugs in MediaWiki: phabricator:T14974. Jackmcbarn (talk) 18:25, 16 July 2015 (UTC)
Right. "For the record, as of today there are 23 duplicate bugs for this issue." Good thing I asked then. Alakzi (talk) 18:56, 16 July 2015 (UTC)

Right, so I've just tried linking up my account on Phab and made a typo in my email, and now the only option is to resend the confirmation email to the incorrect address. All software is broken. Alakzi (talk) 19:00, 16 July 2015 (UTC)

@Alakzi: Hop onto #wikimedia-devtools connect and tell them what happened. They should be able to get it sorted out. Jackmcbarn (talk) 19:38, 16 July 2015 (UTC)
Thanks, but I don't wish to reveal my location to strangers. Alakzi (talk) 23:28, 16 July 2015 (UTC)
@Alakzi: You can work around that by getting yourself an IRC cloak. But in the meantime, I'll file a Phabricator ticket for you to get the account's email reset. — Mr. Stradivarius ♪ talk ♪ 23:35, 16 July 2015 (UTC)
Ok, you are now tracked at phab:T106100. — Mr. Stradivarius ♪ talk ♪ 23:46, 16 July 2015 (UTC)
That is very kind of you, thank you. Alakzi (talk) 23:48, 16 July 2015 (UTC)

Help needed

Hello everyone! Hope somebody could help with a new module for another Wikipedia. In Latvian Wikipedia we quite often have to deal with grammar cases (technically in Wikipedia words sayin - switch into switch), I suppose it could be done much more better with Lua. So, as I said I would need a module, that does the switch into switch job. It should handle both one and unlimited cases. The a) code with parser functions (for easy converting), b) what I imagine the code in Lua would be and c) what the user input and output would be can be found here. --Edgars2007 (talk/contribs) 09:24, 16 July 2015 (UTC)

@Edgars2007: I have a couple of questions:
  1. Do you need just one template like this, or would you need several different templates that use the same basic format?
  2. Would any templates using this proposed module typically be used several times on the same page?
If the answer to both of those is "no", then Lua might not actually help that much. But if it is "yes", then there may be some benefits. Best — Mr. Stradivarius ♪ talk ♪ 23:32, 16 July 2015 (UTC)
Both answers are yes. Note: I fixed my mistake, I know this was quite stupid one :) --Edgars2007 (talk/contribs) 08:47, 17 July 2015 (UTC)
@Edgars2007: Ok, I have a working demonstration at Module:User:Mr. Stradivarius/Latvian declension. Take a look at the documentation and let me know if that's the sort of thing you were looking for. Best — Mr. Stradivarius ♪ talk ♪ 12:30, 17 July 2015 (UTC)
@Mr. Stradivarius: Yes - the module is cool and it's more flexible then it was in my idea :) I liked this one from my subpage (search for {{#invoke:Whatever|main|{{{1|}}}|{{{2|}}}), which could be directly used in templates (I just don't want to make data pages for all cases), but I suppose the data page makes things faster. --Edgars2007 (talk/contribs) 12:51, 17 July 2015 (UTC)
@Edgars2007: Yes, the template format and the data module format are both designed to make templates that use the module as fast as possible when there are many transclusions of the same template on the same page. If you use {{#invoke:Whatever|main|{{{1|}}}|{{{2|}}}}} then you have to pass the arguments from the template invocation, then to the module invocation, and then to the module; the module avoids the middle step by allowing the template content to be a simple {{#invoke:Whatever|main}}, and by getting the arguments directly from the template invocation. And the data module is cached between different #invokes when rendering a page, so it should be faster than using a #switch from the second #invoke onwards, particularly for large data sets. If you want to write a one-off template, you can just do it in a #switch - as you've probably realised, the amount of code for a switch-based template is about the same as for a data sub-module. — Mr. Stradivarius ♪ talk ♪ 13:34, 17 July 2015 (UTC)

@Mr. Stradivarius: Have two questions.

  1. For data page, where you have keys "foo" and "bar". In terms of keeping things fast, what I should use, if I want use "lorem" as alias for "bar":
    use ["lorem"] = "bar" (or something like that) (like here, search for ["PAOK Thessaloniki"] = "PAOK",)
    or just simply copy the "bar" case for new case - "lorem"?
  2. Will it be possible to use this module in some other module (with require, not with frame:expandtemplate Yes, I know something from Lua :), I'm not a complete newbie, I'm just starting learning) without big changes in data module pages. That's not for now, but for some time in far, far future. --Edgars2007 (talk/contribs) 10:17, 18 July 2015 (UTC)
There are some problems in there. For example, here it shows an error, but in doc page everything is OK. If you're not done yet and I'm rushing, then sorry. Just tell me, when you're done. --Edgars2007 (talk/contribs) 10:39, 18 July 2015 (UTC)

getContent

As getContent function isn't expensive, why not use it as a replacement in some cases for #ifexists? Or create module/template for it. --Edgars2007 (talk/contribs) 09:32, 1 August 2015 (UTC)

Why didn't I know about this before? Alakzi (talk) 10:12, 1 August 2015 (UTC)
It's a hack, and if it becomes widespread, it might become expensive. Jackmcbarn (talk) 15:10, 1 August 2015 (UTC)
Well, it's not a hack for my purposes. Alakzi (talk) 15:16, 1 August 2015 (UTC)
I wouldn't count on it staying inexpensive for long, especially if it starts to be widely used. Whether or not it's a hack for your purposes, it's a hack for Scribunto's purposes - site stability has to come before convenvience to template/module coders. — Mr. Stradivarius ♪ talk ♪ 15:29, 1 August 2015 (UTC)
To be clear, I'm using it for its stated purpose - to pull in the unparsed text content of another page. I'm also using it in a module which should never be transcluded. I can't imagine how I might ever come to compromise the stability of the site. Alakzi (talk) 15:42, 1 August 2015 (UTC)
That would be by writing a loop which pulls hundreds of thousands of different pages from the database. As long as you don't do that, you should be good. (Also, getContent counts as a transclusion in WhatLinksHere.) — Mr. Stradivarius ♪ talk ♪ 15:50, 1 August 2015 (UTC)
Ah, if you mean "is always substituted" by "should never be transcluded", then that's fine, of course. — Mr. Stradivarius ♪ talk ♪ 15:54, 1 August 2015 (UTC)
(edit conflict) Well, I wasn't planning on doing that, but thank you for the cautionary word. :-) Also, getContent counts as a transclusion in WhatLinksHere. Right, but the module is always substituted - see {{Parameters}} if you're curious. Alakzi (talk) 15:59, 1 August 2015 (UTC)

Infobox

At Latvian Wikipedia, I would like to track down those articles, which use |caption=, but don't have |image= (of course, also caption2, caption3 etc.). I added just a random category, but it isn't working as expected. When there is both image and caption (first example), the category shows up, but when there is caption without image (second example), category doesn't show up (second example). And yes, it is important - want to put images directly from Wikidata, when there is such, but it can't be done without such check. --Edgars2007 (talk/contribs) 20:39, 4 September 2015 (UTC)

The image variable you use in your check is never defined, so it always evaluates to false. Does the category check work after this change? SiBr4 (talk) 20:51, 4 September 2015 (UTC)
No. --Edgars2007 (talk/contribs) 20:56, 4 September 2015 (UTC)
A blank |image= is discarded earlier on, so it never loops through the image parameters. Furthermore, |caption= depends on |image= and is discarded if |image= is not set (line 373). Alakzi (talk) 21:04, 4 September 2015 (UTC)
Yes, I know, that caption is discarded. But if you get Wikidata image directly and there was some caption left in article (as it was here), then there will be incorrect caption, what I want to avoid. Just don't want to do such tracking job one infobox by one - want to centralise things. --Edgars2007 (talk/contribs) 21:22, 4 September 2015 (UTC)
Perhaps we need an image-caption property for Wikidata, to be used as a qualifier, and as monlingual text. Maybe "alt", too.Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 4 September 2015 (UTC)

Template:Country data Ahuachapán Department

  • {{#invoke:Flagg|main|isb|sz=35x23|Ahuachapán Department|image=Bandera del Departamento de Ahuachapán.PNG}}

Transclusions of Template:Country data Ahuachapán Department are being generated by Module:Flagg for some reason. It seems odd since the place where mw.title.new is being called is nested inside a branch of an elseif which is not being accessed, as far as I can tell (i.e, mi=="i" and mn=="b" in this example). Any ideas on how to fix this? @SiBr4:. 98.230.192.179 (talk) 02:38, 30 August 2015 (UTC)

I found this while cleaning up Wikipedia:Database reports/Transclusions of deleted templates/1. 98.230.192.179 (talk) 02:39, 30 August 2015 (UTC)
The "mw.title.new" part is only used to determine whether or not a template is a redirect in the d (data template) format. The transclusions are coming from the internally used Module:CountryData, which uses transclusion and string comparison to non-expensively determine whether or not a data template exists. I didn't think of it being counted as a broken transclusion in database reports for non-existing ones. I don't know if a similarly non-expensive alternative method exists, or if expensive functions must be resorted to (Flags of country subdivisions would most certainly hit the limit of 500 if so). SiBr4 (talk) 09:15, 30 August 2015 (UTC)
User:SiBr4, is the 'data' loaded from that module used when invoked with 'isb'? If not, perhaps you could wrap the loading of the data inside an if statement so it doesn't try to load it when it doesn't need it. this would seem to be even less expensive, and fix the issue? Frietjes (talk) 16:03, 30 August 2015 (UTC)
for example, if me is not equal to 'e' and the image parameter has been set, then it seems as though the data is not used (unless it is used by clink?). also, there appears to be a logic error where the internal variable clink is used before it is defined? Frietjes (talk) 16:08, 30 August 2015 (UTC)
The country data is used for the image name (and its size and border), the display name for e, and the country link ("clink"), each of which can be overridden. Only in the very rare case that "image" set and (name set or "e" not used) and ("clink" set or "link" set) (pseudocode) is it useful to add an internal switch to not load the data at all if it isn't used. I could add a format letter or parameter to not load a data template if it is certain to not exist, or to switch between direct transclusion and expensive existence functions.
I have fixed the "clink" issue, which prevented the altlink to be changed using the |clink= parameter. SiBr4 (talk) 18:04, 30 August 2015 (UTC)
User:SiBr4, I like the idea of having a letter which turns off the loading of the country data template as you suggested. although, I am having a hard time imaging a case where you would use |image= when the country data template exists. if you don't want the default image, you use the 'variant' parameter? it would seem odd that you would want to show a variant that isn't in the country data template, rather than just adding an additional variant. Frietjes (talk) 14:43, 1 September 2015 (UTC)
At Flags of country subdivisions I used {{flagg|isb|Akrotiri and Dhekelia|image=}} to replace the Union Jack with a blank flag. {{flagg|xsb|Akrotiri and Dhekelia}} would do the same thing, but would create an inconsistency between the format codes. I can think of hypothetical reasons to replace a flag image with one that should not be added as a variant, for example wanting to represent a subdivision or city with the respective national flag, like is common in lists of sister cities (e.g. " Albuquerque, New Mexico, United States"). One may also set |image= to not have to navigate to the data template to check if it exists, or to use a variant flag with known filename without having to find out the variant label.
My idea was to add a parameter that can go all three ways: trying to load the data template like now (which in case of non-existing templates works but causes appearance in maintenance reports), conditionally loading it by checking its existence (which is expensive), or not loading it. I'm doubting as for which of the first two should be the default. Not loading if |image= is specified and loading otherwise could work too.
Since a transclusion of a non-existing data template can indicate it is wanted, and doesn't actually break the flag template or display a redlink in case of {{flagg}}, I'm wondering if there is a way to simply exclude entries resulting from it from the database report. SiBr4 (talk) 21:46, 1 September 2015 (UTC)
the database report isn't for transclusions of non-existing templates, but transclusions of deleted templates. a template is deleted for a reason, although not always for a good reason. Frietjes (talk) 23:37, 1 September 2015 (UTC)
It seemed to include more than just deleted templates, because I didn't think so many of the nonexisting data templates "transcluded" on the subnational flags article did in fact exist years ago. Additionally, Template:Country data Ahuachapán Department has never been deleted, though I now see it isn't included in the database report at all (the OP's post is therefore kind of confusing). In that case, a parameter/format letter to either avoid loading or check existence (which would be better?) for just those entities whose templates have been deleted before would work. After your creation of these capital city and Indonesian province templates that's only the Taiwanese counties.
As a separate idea, usages of the |image= parameter where a data template exists could be collected in a tracking category (since in some cases that does indicate the custom image is already in, or should be added to, the template) instead of not loading the data template if |image= is set. SiBr4 (talk) 13:04, 2 September 2015 (UTC)

Proposal to restrict page moves in the "Module:" namespace to administrators

Moved from Wikipedia:Village pump (proposals)

Simply put, I propose that page moves of pages in the "Module:" namespace be restricted to administrators. In other words, I think that the entire namespace should be move-protected. There is one major reason why I think this is necessary, should have been done long ago, and why I don't believe that even template editors should be allowed to move the pages in that namespace. The reason is: when a page gets moved from a title in the "Module:" namespace, it never leaves a redirect. This situation is problematic since, for one, it is the equivalent of having access to the "delete" function while not being an administrator and, for two, if there are any pages that run the module by its previous name (such as pages in the "Template:" namespace), they all break after the move (and since there are no redirects in the "Module:" namespace, there is no way to avoid the pages that run the modules from temporarily going down after the page move.) Steel1943 (talk) 02:39, 18 September 2015 (UTC)

This sounds like a deeper problem. Why do Module: namespace pages not leave redirects when moved? That is what seems to be the issue. Dustin (talk) 02:47, 18 September 2015 (UTC)
For the same reason there are no redirects in the "MediaWiki:" namespace: the code on the page doesn't run if the request hits a redirect first. Steel1943 (talk) 02:55, 18 September 2015 (UTC)
A move can be done without breaking uses of the old module with a copy-and-paste to the new module name (which of course requires attribution back to the original module), and then modifying the old module to simply invoke the new one. isaacl (talk) 02:49, 18 September 2015 (UTC)
This solution is problematic since it breaks edit history attribution and in a case where the module may be renamed twice, then there will be a module invoking a module that is invoking a module, and that could blog up the site. Also, if this is the only resolution, it enforces the need to move-protect the namespace. Steel1943 (talk) 02:55, 18 September 2015 (UTC)
Yes, I noted the issue with edit history attribution. If a module is renamed again, all of the old module names can be modified to invoke the latest module name directly. I'm not suggesting this is the ideal way, but simply that it is not impossible with the current setup to rename a module without breaking uses of the old module name. isaacl (talk) 03:08, 18 September 2015 (UTC)
Right. I'm not doubting what you are saying as a resolution though; from what I see, it's the only resolution. And if this is the only solution, there should be almost no reason why a page move should occur since they will always break something if another page is set up to invoke the module. If anything, maybe a new speedy deletion criterion could be set up if there is proof that a "Module:" has been copied to a new title, and there is proof that there is no longer any pages set up to invoke the module at the old name. Steel1943 (talk) 03:36, 18 September 2015 (UTC)
  • I'm willing to believe you have identified a real problem, but I am not convinced this is the correct solution. The reason is that admins are not by any means experts on the module namespace. I've been an admin for six years and I don't even know what it is, or desire to find out. So, this will inevitably lead to persons who do know what this is and how it works asking for adminship so that there is somebody who is both able to deal with these moves and knows what they are doing, and they will be shot down as single-purpose candidates always are these days. And so these pages will be stuck where they are, or admins will make bad moves of them when someone asks, and the problem will persist, just in a different form. I would suggest that despite your misgivings this should be given to the technically-minded folks in the template editor group, who are more likely to understand the issues involved and respond appropriately than admins at large. Last time I checked, modules, whatever they are, have absolutely nothing to do with site administration. Beeblebrox (talk) 04:27, 18 September 2015 (UTC)
  • @Beeblebrox: That hits a point I meant to bring up in addition to my proposal; possibly an edit notice explaining to administrators performing these moves requirements that have to be met prior to a moving a page in the "Module:" namespace (an explanation that could be understood by any administrator, regardless their technical knowledge; the simplest start to the edit notice would ask the administrator to ensure that no transclusions of the old name exist.) In such a case, if an administrator doesn't feel comfortable that the requirements as outlined in the edit notice are met, then they should not be fulfilling the move request. In fact, on that point, it may just be best to never allow pages in that namespace to be moved, but I know that is kind of crazy and will never happen, so I'm trying to find an acceptable alternative. Steel1943 (talk) 04:44, 18 September 2015 (UTC)
  • Have there been any actual problems with moves by non-admins breaking modules? My first instinct is that this proposal isn't necessary, and that normal page protection will be enough to protect the modules most at risk. However, I could be persuaded otherwise if we are consistently having problems with this. — Mr. Stradivarius ♪ talk ♪ 04:32, 18 September 2015 (UTC)
  • @Mr. Stradivarius: Well, I can tell you that I messed up once, but then had enough common sense to revert myself after realizing that a redirect wasn't created. However, there's no way to guarantee that other editors may realize this if they make a similar mistake. If there is no way to technically move a module without causing problems without the "copy-paste" resolution above, then why should that option even be available? Steel1943 (talk) 04:38, 18 September 2015 (UTC)
I agree with Mr. Stradivarius, and was already thinking so much before I read his comment. I don‘t see any problem that needs addressing by this, such as lots of damaging moves. High usage modules are already protected which prevents them being moved, so the scope for damage is therefore minimal even in theory. And there may be good reason for a non-admin/non-TE to move a module. Perhaps they are working on it and need to move it from a temporary name to a permanent one, or for consistency with other modules. It is easy to move most modules without causing problems: just update the template or templates invoking them (which should have the same level of protection). I can't think of any that are invoked directly that this won’t work on. So I don’t see any problem that isn’t already dealt with our current protection policy.--JohnBlackburnewordsdeeds 04:56, 18 September 2015 (UTC)
  • @JohnBlackburne: Actually, there is no way to move a module without causing downtime for any templates that call them. As I stated above, since redirects in the module namespace do not exist, nor do they work since redirects cannot run the code, the only way to prevent any downtime is by the method that Isaacl suggested above (which is essentially a cut-and-paste move which causes WP:CWW issues. That, and I cannot see a valid reason for a module to be moved to another title is it is a module that is transcluded anywhere given these issues. Maybe we need a separate edit notice when a page is created in the "Module:" namespace to ask the editor "Are you sure this is the title you want this page? Afterwards, it cannot be moved." Steel1943 (talk) 05:11, 18 September 2015 (UTC)
You can move almost any module without causing problems: simply move the module and update the template at the same time. 'the template' as it is almost always just one. If there are more update them too. As for why one might be moved I gave you some reasons immediately above. Another might be a typo when creating the page. That is probably as likely as any other page but we don’t have special warnings, even though it is more problematic to tidy up after misspelling an article as the redirects need to be deleted. Another reason not to do this: modules are simply not targets of test or bad edits, that I’ve seen. Templates sometimes are, articles often are, but not modules. The module protection policy is based on number of transculsions, not which have been vandalism/disruption targets as none have.--JohnBlackburnewordsdeeds 05:45, 18 September 2015 (UTC)
Looking back at the previous discussion you initiated on this topic, it seems there has been progress in implementing a redirect feature, where the Lua code to effectively accomplish a redirect would be treated by the MediaWiki software as a directive to perform a redirect. Whether or not it gets implemented, though, perhaps the move capability can be modified to leave behind the appropriate Lua redirection code in the old module. isaacl (talk) 16:19, 18 September 2015 (UTC)
  • @Isaacl: By the way, I think that idea is genius. Jackmcbarn, is that the direction the above gerrit request is taking, or was another path discovered, or will this require a new request? (I'm really not familiar with how the gerrit boards work, though I have seen some if the requests fulfilled in action.) Steel1943 (talk) 17:26, 18 September 2015 (UTC)
    I'll see if I can get that here soon-ish. I'd much rather do that than lock down the Module namespace like this. Jackmcbarn (talk) 17:58, 18 September 2015 (UTC)

The same used to have happened with css and js pages, but now redirects are supported for those pages. A non-admin can only move css and js pages in his or her own userspace. 107.142.8.44 (talk) 00:17, 19 September 2015 (UTC)

css and js files are parts of the Mediawiki software, and can be used on all pages, so any edit or move would have massive impact. Apart from that they do not exist anywhere apart from in userspace, where they could be as disruptive an individual editor’s experience so can only normally be edited by that editor. I.e. they are nothing like modules.--JohnBlackburnewordsdeeds 00:23, 19 September 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Lua/Archive_3&oldid=1153604566"