Wikipedia talk:Lua/Archive 2

Wikitext tables?

Apparently "it's an absolute nightmare coding wikitext tables in Lua". But a table opened with HTML <table> cannot have wikicode for any of its cells (try it in a sandbox if you don't believe me). So can we not convert to Lua templates that open tables until this is fixed? Otherwise we end up breaking an unknown number of articles. --NE2 07:07, 14 January 2014 (UTC)

Why should I have to deal with concatenations and string.format() calls to produce wikitext when I can just use Module:HtmlBuilder instead? It's certainly possible to use wikitext tables, but it's nowhere near as clean and simple as coding the HTML equivalent within Lua. In either case, NE2 is attempting to use the template/module in question, {{jcttop/core}}, contrary to its design. It is supposed to be used with templates of the {{jctint/core}} family, which properly uses HTML syntax. The use of wikitext with this template is unsupported, and otherwise violates the internal standards of the projects that use this template. Therefore, I don't feel I should have to design modules to support a technique that is destined for oblivion anyway. -happy5214 07:33, 14 January 2014 (UTC)

@NE2: I'm pretty sure you can actually use wikitext table syntax and html table syntax together. Could you give us an example of a page where this isn't working? — Mr. Stradivarius ^{♪ talk ♪} 08:00, 14 January 2014 (UTC)

Here's an example:

Heading 1	Heading 2
Foo	Bar

— Mr. Stradivarius ^{♪ talk ♪} 08:03, 14 January 2014 (UTC)

I may have missed the point, but it looks as if NE2 is saying that a module is creating a table that starts with the html <table>, and that wikitext cannot then be used in the table. If I had time I would have a look at the module because there should be a way to conveniently build a table using wikitext. Johnuniq (talk) 08:51, 14 January 2014 (UTC)

I was just going to reply saying that you're right and doing it the other way around doesn't work. For example, this is what I get when I tried doing it that way round on this page:

<table class="wikitable">
<tr><th>Heading 1</th><th>Heading 2</th></tr>
|-
| Foo
| Bar
</table>

However, then I tried it inside {{collapse top}}, and something in that template's CSS makes it work:

same template inside {{collapse top}}
<table class="wikitable"> <tr><th>Heading 1</th><th>Heading 2</th></tr> |- | Foo | Bar </table> Heading 1 Heading 2 Foo Bar

This makes me think that there must be a hack that we can use in the Lua module to make the insertion of wikitext table markup work somehow. — Mr. Stradivarius ^{♪ talk ♪} 09:12, 14 January 2014 (UTC)

Ok, now I see - {{collapse top}} itself uses wikitext table syntax, which is why the wikitable syntax works inside it, even when surrounded with HTML table markup. Happy5214, if you don't want to convert the whole of your module to use wikitext tables, you might be able get away with just replacing the opening and closing <table>...</table> tags with {| and |}. Although probably it would be best for someone to write Module:TableBuilder, which would do the same thing as Module:HtmlBuilder, only for wikitext tables rather than HTML. — Mr. Stradivarius ^{♪ talk ♪} 10:00, 14 January 2014 (UTC)

I added the change to the sandbox, which can be accessed with {{jcttop/core/sandbox}}. I'll hold off on changing Module:Jctbtm until we know if this fix works right. I second creating a TableBuilder module for these situations. -happy5214 10:17, 14 January 2014 (UTC)

Wikitext tables with Lua don't seem like all that big a problem. I've done some in things like Module:ImportProtein and Module:Module overview; I've even done one using rowspan in Module:TemplateTools. The big advantage of sticking with Wikitable format is that you can have an argument to produce nowiki output and wrap it in pre tags, and a human editor can copy the output table and more easily customize it further if the module output is somehow insufficient or inaccurate. Wnt (talk) 15:39, 14 January 2014 (UTC)

Any update? It shouldn't be hard to either change the single template {{jcttop}} to use wikicode, or alternately revert it to non-Lua until that's done. --NE2 18:12, 22 January 2014 (UTC)

It would make more sense to take {{jcttop}} out of articles that don't use the rest of the corresponding templates, since they are using the template incorrectly. No need to be a mule about this, use it correctly, as the documentation lays out. - Floydian ^τ _¢ 20:25, 22 January 2014 (UTC)

Who's to say what's correct usage? A bunch of self-selected template popo? --NE2 20:38, 22 January 2014 (UTC)

In any case, the sandbox code fixing this has been live for a week. If you're still having issues, try purging the page. -happy5214 06:33, 23 January 2014 (UTC)

So it is. Awesome. --NE2 00:56, 26 January 2014 (UTC)

Updated CodeEditor

I just updated the version of ACE in our CodeEditor. If you use this editor often, take a minute or two to test it out. Most interesting change is most likely the new improved Find and replace. Use ctrl-F or cmd-F to access it. There are options for case sensitivity, regexp etc. You can start typing and it will highlight all the matches as you type. Pressing ctrl-G brings you to the next match, ctrl-shift-G for the previous match. Pressing ctrl-F a second time brings up the replace dialog. cmd-, brings up the settings dialog (non-persistable). I'm in the process of writing a patch to add a 'show invisible characters' persisted toggle button to the CodeEditor. If there are other options in the settings dialog that you think we should offer in the toolbar with persisted settings, then please file a bug report with your idea. —TheDJ (talk • contribs) 07:41, 10 January 2014 (UTC)

This is excellent news - the search is now actually useful, which will be a great help when I am away from my main computer. (On the main one I use GVim, and I don't think it's possible to pry me away from that now.) Thank you for your work on this. :) — Mr. Stradivarius ^{♪ talk ♪} 08:32, 10 January 2014 (UTC)

One little peeve, and it's time for me to start taking care of stuff like this myself: I'd like to change "this" to "self" in ace/mode-lua.js line 216. I've signed up for an account on that server, and I've cloned CodeEditor in git and edited the file. I think I'm supposed to use the commit tool, set my identity as wnt, put in an email address, and push changes, but I haven't seen a style guide or set of do's and don'ts and I'm a bit worried I'll cause some sort of disturbance. (Also I'm not sure every tom dick and harry who signs up is authorized to propose changes to CodeEditor?) I'm not asking you to do this one for me; I want to figure out how to do it myself. Wnt (talk) 13:16, 15 January 2014 (UTC)

Yes, every Tom, Dick, and Harry who signs up is authorized to propose changes. Then people will (hopefully) review your changes, and if your change is good then someone with "+2" access will eventually merge it. Style guides are at mw:Manual:Coding conventions, and an introduction to the whole process is at mw:How to become a MediaWiki hacker.

In this particular case, though, it might be better to go upstream so it doesn't get undone the next time ACE-in-CodeEditor is updated. Anomie⚔ 13:44, 15 January 2014 (UTC)

Well.... I'd honestly been half hopeful that there might be some way to make a commit like a Wiki edit and preview it on one of those wmflabs projects, but that was wishful thinking. Instead I feel like I've been mugged on the pons asinorum, because the outcome of "vagrant up" is always an error that "AMD-V is disabled by the BIOS". Turns out that apparently the virtual Ubuntu relies on a feature which, though it is present on the chip, has quietly been turned off by many/most cheap manufacturers at the software or motherboard level. Leaving me to attempt the now not recommended manual installation... let's just that I'm not feeling so hopeful right now. Wnt (talk) 17:44, 15 January 2014 (UTC)

I should mention that I was able to get 1.23alpha running under XAMPP "the old way", so hopefully I should be able to continue. Wnt (talk) 21:55, 17 January 2014 (UTC)

@Wnt: I had this issue when I was trying to install Vagrant as well, and I just fixed it today. All I needed to do was turn on virtualisation in my BIOS, then do a fresh install of MediaWiki-Vagrant. After that, everything worked. — Mr. Stradivarius ^{♪ talk ♪} 13:49, 28 January 2014 (UTC)

That works great, if you can do it. (Incidentally, though my efforts were set back again by a disk failure on the computer I'd been using, I'm pretty sure the old way is the way I'll be doing it, because none of the cheap computers I've been using have an option to enable virtualization) Wnt (talk) 17:04, 28 January 2014 (UTC)

You should definitely do this upstream. And actually, since it is github it is EXTREMELY easy. Just sign up, then go to here. Click Edit at the top right. This will create a fork in your 'own' github space and open a JS based editor. Change the line in question and then add a commit summary and description and say "Commit changes". After that at the top there will be a "Compare and review" button that you can click to submit your changes to ACE itself. After that, we can do the MediaWiki part, which indeed is a bit harder. —TheDJ (talk • contribs) 18:08, 15 January 2014 (UTC)

Well, the plan was to move toward being able to contribute to Wikipedia, not the ACE project, but I ought to make a trip over there at some point, it's true. Wnt (talk) 19:13, 15 January 2014 (UTC)

I do apologize, but since I was working on a few other CodeEditor issues in ACE, I also fixed this issue. I hope to have all of this working properly in the next round of deploys. But there is quite a bit more that can be fixed in CodeEditor. Especially adding some toolbar options for a few of the ACE options would be very welcome. See also bugzilla:59924 and other CodeEditor issues. —TheDJ (talk • contribs) 22:14, 17 January 2014 (UTC)

Hey, no need to apologize for fixing that! I know I actually tried saving an edit with "this", no matter what the manual said, just because of the editor ... you just spared somebody else the effort. I'm not so sure about starting with these ACE options though - connecting two pieces of software can be a trickier exercise, and I might look for an even smaller bug to fool with. Either that, or (probably) waste my time trying to see if there's any way we could transclude a .SVG file after all. :) (I really want to be able to relabel those things on the fly, in the Wiki) Wnt (talk) 22:36, 17 January 2014 (UTC)

Wikidata calendarmodel

Hi, on Wikidata some dates are shown as Julian Calendar (internally instead they use Gregorian Calendar), documentation here. Is there some Lua utils/library for Gregorian=>Julian conversion? --Rotpunkt (talk) 21:28, 24 January 2014 (UTC)

A quick search turned up Module:JulianDay and Module:Sandbox/DixonD/Datetime/Julian, although neither of them appear to be in wide use, and I can't vouch for their contents. — Mr. Stradivarius ^{♪ talk ♪} 06:52, 26 January 2014 (UTC)

Thanks Mr. Stradivarius. Wikidata uses Julian calendar, but these modules seem to be related to Julian day. I found Conversion between Julian and Gregorian calendars, and I am not sure about the conversion: (1) gregorian calendar => julian calendar or (2) gregorian calendar => julian day => julian calendar. I could look at Wikidata code. --Rotpunkt (talk) 07:11, 26 January 2014 (UTC)

Actually the module you found, Module:JulianDay, converts also julian day => julian calendar, so the way to go seems to be: gregorian calendar => julian day => julian calendar.Thanks again. It would be nice to know if direct conversion is another choice or not: gregorian calendar => julian calendar (without julian day step). --Rotpunkt (talk) 08:16, 26 January 2014 (UTC)

The first of the links posted by Mr. Stradivarius appears to be from fr:Module:Date. I was tangentially involved in the latter because I wrote Module:Age which led to a discussion on my talk (here). Another discussion was here. I was going to get more involved but other work got in the way; I'm just offering these links in case they have anything that may interest someone who feels like investigating. Johnuniq (talk) 09:09, 26 January 2014 (UTC)

I will look into it, thanks. --Rotpunkt (talk) 10:55, 28 January 2014 (UTC)

Wikidata claims

Hi someone knows if entity.claims[property] is for sure a Lua sequence, and it remains a Lua sequence also after editing/removal from the wikidata web interface? I know entity.claims[property] has the oddity that it starts from 0 instead of 1, but apart from that:

• can I always count the claims with: #entity.claims[property] + 1 ? ("+ 1" because claims starts from 0)
• can I always iterate the claims with: for i = 0, #entity.claims[property] do ?

Thanks in advance. --Rotpunkt (talk) 11:11, 28 January 2014 (UTC)

I have asked on irc and I was told it's a sequence. The starting index (0 instead of 1) is meant to be changed (on a new interface). --Rotpunkt (talk) 12:45, 28 January 2014 (UTC)

Using require conditionally

At Template talk:Time ago#Suggesting to Module:TimeAgo there was a suggestion that we should move one of the require statements at the top of Module:TimeAgo inside an if block in the module body. The rationale is that this would prevent it appearing as a transclusion when it is not needed in the module. Is this a desirable thing to be doing, and would it have any appreciable effect on performance? — Mr. Stradivarius ^{♪ talk ♪} 10:37, 30 January 2014 (UTC)

Two words: job queue. Keφr 11:20, 30 January 2014 (UTC)

Efficiency is always good, provided it doesn't have a significant cost (such as making the code ugly or harder to maintain). I think it depends on the situation, but I commented at the above talk that doing require only if needed seems desirable. Johnuniq (talk) 11:38, 30 January 2014 (UTC)

Good points, both of you. Require on demand it is, then. (Also, @Kephir: that's short.) — Mr. Stradivarius ^{♪ talk ♪} 12:46, 2 February 2014 (UTC)

NaN question

Can anyone who knows their NaNs have a look at Module talk:TableTools? I'm wondering whether I should change the duplicate removal function based on Verdy p's post there. Thanks. :) — Mr. Stradivarius ^{♪ talk ♪} 12:49, 2 February 2014 (UTC)

Threads copied from Wikipedia talk:Lua/To do

The following subthreads were all copied from Wikipedia talk:Lua/To do per my suggestion above. I've redirected that page here to keep discussion centralised. — Mr. Stradivarius ^{♪ talk ♪} 14:00, 4 February 2014 (UTC)

Simpler templates?

Hi, converting wikitext templates into Lua templates is an interesting work for mw:Google Code-in. However, the templates listed here are very complex, and embed other templates. It would be great if we could split the tasks into smaller pieces. For instance, among the transcluded templates is there any that would be interesting to convert first?--Qgil (talk) 21:46, 3 December 2013 (UTC)

While sometimes subtemplates should go into different modules, most of the time they should all go into the same module. The main reason for having subtemplates is because that is the only way it is possible to call the same template code multiple times. If this is the case, it is usually best to implement the subtemplate as a function in the main module. For example, all the templates called from {{documentation}} could be implemented as functions, with the exception of {{pp-template}} and {{fmbox}} (the latter has already been converted to Lua anyway). I can see how converting these hugely complicated templates might not be the best for the students, though. :) I'll see if there are some easier ones lurking out there that I can find. — Mr. Stradivarius ^{♪ talk ♪} 08:04, 4 December 2013 (UTC)

Hi Mr. Stradivarius and Wnt, the two EASY templates have been already rewritten in Lua, while the same student (Theopolisme) has just claimed Template:Multiple_issues, tagged as MEDIUM. Do you have more easy templates for other Google Code-in students? Also, let me know if you think any of the "Other tasks" is suitable for GCI students.--Qgil (talk) 20:34, 8 December 2013 (UTC)

Grand plan?

Hi! I'm very new here - got to Lua templates from a hackaton, so I have no Idea what I'm talking about. If there is a wish to convert all templates to modules - I think that that's a great way to get people not currently in wikipedia involved. Unlike most open-source coding missions, template conversion is very easy to get into, it's a small app you do from scratch (most small missions are debugging other people's code, which no-one likes), and it will actually be used by wikipedia. It's a perfect programmer-version of maintaining wikipedia values. Collecting conversion candidates, testing modules (to match templates), and converting approved templates can be done by simple python-bots. All in all - great hackaton materia. Let me know if that makes any sense. Tsahee (talk) 08:22, 27 December 2013 (UTC)

Absolutely, that sounds like a great idea. :) The more people we can get involved, the better. How about bringing this up on the main project talk page? This page is meant for discussion about the To do page, rather than for discussion of Lua in general. Best — Mr. Stradivarius ^{♪ talk ♪} 08:39, 27 December 2013 (UTC)

External libraries?

So one nice thing about Lua is that there is some open-source code out-there that may prove useful for wikipedia too. I looked at [[1]] which may not be a perfect example but it's close enough. How do we feel about trivially converting external libraries to modules? Can there be a licensing problem? Most request at least that "this disclaimer / license" is included when copying the code - is that o.k? Tsahee (talk) 08:22, 27 December 2013 (UTC)

Yep, that's all good. As long as the licence is compatible with Wikipedia's, then we can use it. You just need to copy the code over and make sure you do whatever is necessary to comply with the licence. A lot of Lua code is licensed with the MIT licence, and we can use that with no problems. If the licence allows the freedom to copy, modify, and distribute the software, including commercially, then we should be able to use it. But if you have any doubts, please ask. :) Also, this kind of thread will go better at the protect talk page at WT:Lua. — Mr. Stradivarius ^{♪ talk ♪} 08:37, 27 December 2013 (UTC)

Parameter listing

I've just begun Module:TemplateTools, and I've got working a feature that automatically lists all the parameters actually used by a template, and their default values (i.e. {{{parameter|default}}}). It's still at a very early stage, but maybe people doing translations could find it useful. Wnt (talk) 07:36, 8 January 2014 (UTC)

Looks interesting - I'll have a play around with it later. If you're looking to parse wikitext and don't want to reimplement the entire parser, you could try cribbing from mwparserfromhell, a wikitext parser written in Python that is already stable and used in some well-known Wikipedia bots (Legobot, for a start). Also, if you're looking for more AI-level tasks you could add automatic generation of metatables for memoisation. And maybe you could add a 5.5, "automatically convert subtemplates". Anything over number 5 or 6 sounds like a PhD-thesis-level task to me, though. :) — Mr. Stradivarius ^{♪ talk ♪} 08:03, 8 January 2014 (UTC)

Actually, I'm even reduplicating some of my own efforts from Module:FormatTemplate going about it a different way ... this is a bit of an exercise so far. (Also there's Module:TemplateDataGenerator which I haven't really looked at). I think my practical goal here is to split up the work of rewriting a template into several independent parts, so that you can do some one day and some the next, or have several volunteers work on different pieces, but I'm really not going to be sure how hard it is to do a nearly full conversion minus a small percent of leftover slag (like obscure parser functions) until I get neck deep in it. :) Wnt (talk) 16:29, 8 January 2014 (UTC)

Speaking of "neck deep in it".. I've gotten to the point where there's something almost resembling Lua code in places at Module talk:FormatTemplate. My, but it's a beast, and it's been a struggle. Still... I wouldn't give up hope yet. Wnt (talk) 00:00, 22 January 2014 (UTC)

Dts template

Hi! I made some progress with DTS template, and I have some questions. The best way seemed to be to write them down in Module_talk:Sandbox/Dts and ask you here to take a look. Thank you! Tsahee (talk) 20:45, 19 January 2014 (UTC)

Suggestion

How about Template:Val? It has limit issues too. --JulesWinnfield-hu (talk) 12:04, 1 February 2014 (UTC)

Anyone taking that on may want to review a discussion at my talk because {{convert}} is now able to show a unit name, optionally linked. I think {{val}} is still using some tricky logic and the old convert templates for that. Johnuniq (talk) 01:54, 2 February 2014 (UTC)

Redirect to Wikipedia talk:Lua

I've proposed redirecting this page to the main project talk page at Wikipedia talk:Lua. If anyone is interested, please join the discussion. — Mr. Stradivarius ^{♪ talk ♪} 12:54, 2 February 2014 (UTC)

Module localisation

I got a message on my talk page today suggesting that I put the message() function from Module:Documentation in a separate meta-module so that it can be reused by other modules. The message function works a lot like (a simplified version of) MediaWiki messages - it fetches a localised version of the message from a data table, and then swaps parameters $1, $2, etc. with their values. Unlike string.format, parameters can be specified in any order, which is necessary when putting the parameters in the "English order" would be unnatural in a given language. I think it would be useful to have a standardised way of localising modules like this, and I'd like to hear people's thoughts on how best to do that. Is the message() function a good model, or would you change it? Could this be integrated with the mw.message library? Let me know what you think. — Mr. Stradivarius ^{♪ talk ♪} 05:28, 4 February 2014 (UTC)

That's a great function. I have done similar stuff in Module:Convert but I was too tired to think about doing it properly with $1, $2 etc. I'm just using %s which displays multiple parameters in a fixed order. One point is that it seems people want all messages localized, including the "should never happen" messages like "message: no value found for key". That is not easy to do in a reasonable way, and I haven't done it (if the table-lookup fails, I just use "?"). I did some Q&D localization for hi:Module:अंक परिवर्तन and put unknown_error and mtext_hi at the top of the module.

The expectType parameter is pretty strange. I see it gets a workout with 'boolean', but if expectType is given and is not 'string', then valArray must be nil or there will be a runtime error. Is it really needed? For example, the 'boolean' usage could be replaced by having magic text like 1 (or 0) in the cfg table to represent true (or false).

For convert, I found it convenient to have a single "thing" for an error message, so convert has cfgKey and valArray in a single table. For example, where your code has message('doc-subpage'), convert would have message({'doc-subpage'}) (which can be just message{'doc-subpage'} but I'm not ready to go there).

While integration with mw.message library may be desirable, I suspect it might get complex quite quickly. I'm not sure what else would be in a localization module, although convert has some code for translating a number (a string of digits) to or from English (very similar to the code in the hi link above, although I had to use "to_international" and "from_international" to suit the Hindi wiki, whereas convert uses "to_en" and "from_en"—apparently even "en" is a bit sensitive over there).

By the way, I guess you know that it is not necessary to use ugsub (mw.ustring.gsub) if searching for ASCII text like $2 in a valid UTF-8 string (and if it's invalid, ugsub could do anything). Johnuniq (talk) 10:23, 4 February 2014 (UTC)

Well, Anomie's reply below has left much of this moot, but I'll just answer a couple of points. I was actually thinking of just forcing every message to be either a string, a number, or a boolean, but then I wanted a way for users to specify arguments to {{pp-template}} easily, which means using a table. After {{pp-meta}} gets converted to Lua, I'll probably remove the parameter. Also, I think there does need to be some type checking, otherwise for some messages, if the translator makes a mistake and deletes a message, it would just be dropped from the module output and wouldn't show up as an error.

About the mw.ustring.gsub thing, I will admit that I'm still a little hazy on the details of dealing with unicode. My modus operandi so far has been "if it might touch unicode, use the ustring library", although I'm guessing from your comment that using normal gsub to replace ASCII text with unicode text wouldn't cause any problems. I should probably read up on that some more. — Mr. Stradivarius ^{♪ talk ♪} 13:52, 4 February 2014 (UTC)

If your pattern is not using the percent-letter character classes listed at mw:Extension:Scribunto/Lua reference manual#Ustring patterns or their uppercased versions (%a, %d, and so on), bracketed character classes involving non-ASCII characters, %b or %f with non-ASCII characters, or quantifiers attached to non-ASCII characters, you should be fine to use string.gsub instead of mw.ustring.gsub. Anomie⚔ 16:36, 5 February 2014 (UTC)

Doesn't something like mw.message.newRawMessage("text"):params("$1", "$2", "etc"):plain() already do this? Anomie⚔ 12:51, 4 February 2014 (UTC)

Aha. I thought there might have been something I was missing there. I was under the impression that the mw.message library was only for parsing MediaWiki's existing messages or messages in the MediaWiki namespace, but I do remember thinking that it would be a bit odd to not have some easy way of localising modules that people were writing. Asking earlier might have saved me from reinventing the wheel. I think what we need here is a Scribunto guide for new and relatively new coders who need lots of examples to see how all of this works. I'm sure I would have got it straight away if I had seen an example or two. (Thinks - perhaps I should try and get a WMF grant to write it myself.) — Mr. Stradivarius ^{♪ talk ♪} 13:43, 4 February 2014 (UTC)

To test my understanding of Anomie's advice, I put some code at Module:Sandbox/Johnuniq/message. Johnuniq (talk) 00:26, 5 February 2014 (UTC)

(ab)use of mw.message

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The ability to use these techniques was an unintended consequence of exposing the message library to the parser and, as discussed below, resulted in several odd behaviors when used in this way. Effective February 20, mw.message will only be able to output messages in the plain format, rendering both of these techniques ineffective. Jackmcbarn (talk) 22:53, 6 February 2014 (UTC)

"Hacking" into Wikidata to get properties of miscellaneous articles

I just noticed the interesting mw.message library in the Scribunto documentation, and even though the syntax documented on the Meta page doesn't work, this does: I was able to get the thing to tell me that the capital of Germany was in Bonn while running from the sandbox.

p.misc = function(frame)
    msg = mw.message.newRawMessage("hmm {{#property:capital}}"):title("Germany"):text()
    local out = msg .. "{{#property:capital|of=Germany}}"
    return out
end

Delivers "hmm Bonn, Berlin{{#property:capital|of=Germany}}" while running from Module talk:User:Wnt/Sandbox. Without nowiki, that tag "" still delivers nothing for me.

Is someone in the process of fixing this or should I make it a module? Wnt (talk) 19:17, 12 January 2014 (UTC)

On second thought, it looks like the message library was added last February, I just didn't pay attention to it until recently. So I doubt any change in #property is coming soon ... I should just write up Template:property, which is actually a redlink right now. Wnt (talk) 19:55, 12 January 2014 (UTC)

@Wnt: It sounds like you're looking for mw:Extension:WikibaseClient/Lua. It's a little hard to work with, and the documentation could be better, but it will let you access all the Wikidata properties you want from Lua. — Mr. Stradivarius ^{♪ talk ♪} 20:06, 12 January 2014 (UTC)

Ah, wait a second - you need to get the properties of arbitrary articles, but the mw.wikibase library doesn't allow for it, right? This sounds like something to submit to Bugzilla, or perhaps for something for one of us to actually fix ourselves. Anyway, this is probably Wikipedia's way of telling me that I need some sleep. :) — Mr. Stradivarius ^{♪ talk ♪} 20:10, 12 January 2014 (UTC)

There is a reason it is not available. It does not track this stuff, so if you would update the property, the pages that use this Lua module would currently not be updated. This is a known problem that the WikiData team is still working on. 'Hacking it' would be ill advisable. —TheDJ (talk • contribs) 20:38, 12 January 2014 (UTC)

I didn't try mw.wikibase - actually, I hadn't seen it until now - but I don't see a ready way to access another page's data there. The lack of updating doesn't seem very important for many articles (Actually, the "Bonn" bit it returns isn't very up to date at all). And if an article is edited fairly often, won't it be updated then? Worst come to worst, you could transclude some special page to abolish caching ... 😈. Wnt (talk) 20:53, 12 January 2014 (UTC)

No worst come to worst Anomie will take your toys away :) —TheDJ (talk • contribs) 11:28, 13 January 2014 (UTC)

Acessing other pages data from Wikidata has been reported at bugzilla:47930, by the way.--Snaevar (talk) 14:38, 13 January 2014 (UTC)

Nice hack :). Please just consider it a hack and wait for us to implement this properly, we have good reasons for not enabling this right now. Stay tuned... I'm currently totally overhauling Wikibase's Lua interface (these changes will get deployed within the next couple of weeks, probably). This wont yet include the ability to access "foreign" entities, for that please see bugzilla:47930. Cheers, Hoo man (talk) 18:41, 19 January 2014 (UTC)

Ifexist alternative

Reviewing mw.message library pointed out in the message above, I tried an alternative to parser function #ifexist solving bugzilla:12019. It does not create pagelinks anymore and I think it is not expensive. See my sandbox. Any thought about it? --Vriullop (talk) 11:06, 13 January 2014 (UTC)

Hmm. That'll have to be fixed. Anomie⚔ 11:24, 13 January 2014 (UTC)

As I understand it, #ifexist needs to make an entry in the links table so that it gets updated by the job queue if the corresponding page is created or deleted. With your alternative this won't happen, so if the page being tested is created or deleted, your function won't be updated until the page it is run on is next edited. (Purging the page cache would also do the trick.) A proper solution would have to be more integrated with the database, I would think. — Mr. Stradivarius ^{♪ talk ♪} 11:51, 13 January 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Module localisation

I got a message on my talk page today suggesting that I put the message() function from Module:Documentation in a separate meta-module so that it can be reused by other modules. The message function works a lot like (a simplified version of) MediaWiki messages - it fetches a localised version of the message from a data table, and then swaps parameters $1, $2, etc. with their values. Unlike string.format, parameters can be specified in any order, which is necessary when putting the parameters in the "English order" would be unnatural in a given language. I think it would be useful to have a standardised way of localising modules like this, and I'd like to hear people's thoughts on how best to do that. Is the message() function a good model, or would you change it? Could this be integrated with the mw.message library? Let me know what you think. — Mr. Stradivarius ^{♪ talk ♪} 05:28, 4 February 2014 (UTC)

That's a great function. I have done similar stuff in Module:Convert but I was too tired to think about doing it properly with $1, $2 etc. I'm just using %s which displays multiple parameters in a fixed order. One point is that it seems people want all messages localized, including the "should never happen" messages like "message: no value found for key". That is not easy to do in a reasonable way, and I haven't done it (if the table-lookup fails, I just use "?"). I did some Q&D localization for hi:Module:अंक परिवर्तन and put unknown_error and mtext_hi at the top of the module.

The expectType parameter is pretty strange. I see it gets a workout with 'boolean', but if expectType is given and is not 'string', then valArray must be nil or there will be a runtime error. Is it really needed? For example, the 'boolean' usage could be replaced by having magic text like 1 (or 0) in the cfg table to represent true (or false).

For convert, I found it convenient to have a single "thing" for an error message, so convert has cfgKey and valArray in a single table. For example, where your code has message('doc-subpage'), convert would have message({'doc-subpage'}) (which can be just message{'doc-subpage'} but I'm not ready to go there).

While integration with mw.message library may be desirable, I suspect it might get complex quite quickly. I'm not sure what else would be in a localization module, although convert has some code for translating a number (a string of digits) to or from English (very similar to the code in the hi link above, although I had to use "to_international" and "from_international" to suit the Hindi wiki, whereas convert uses "to_en" and "from_en"—apparently even "en" is a bit sensitive over there).

By the way, I guess you know that it is not necessary to use ugsub (mw.ustring.gsub) if searching for ASCII text like $2 in a valid UTF-8 string (and if it's invalid, ugsub could do anything). Johnuniq (talk) 10:23, 4 February 2014 (UTC)

Well, Anomie's reply below has left much of this moot, but I'll just answer a couple of points. I was actually thinking of just forcing every message to be either a string, a number, or a boolean, but then I wanted a way for users to specify arguments to {{pp-template}} easily, which means using a table. After {{pp-meta}} gets converted to Lua, I'll probably remove the parameter. Also, I think there does need to be some type checking, otherwise for some messages, if the translator makes a mistake and deletes a message, it would just be dropped from the module output and wouldn't show up as an error.

About the mw.ustring.gsub thing, I will admit that I'm still a little hazy on the details of dealing with unicode. My modus operandi so far has been "if it might touch unicode, use the ustring library", although I'm guessing from your comment that using normal gsub to replace ASCII text with unicode text wouldn't cause any problems. I should probably read up on that some more. — Mr. Stradivarius ^{♪ talk ♪} 13:52, 4 February 2014 (UTC)

If your pattern is not using the percent-letter character classes listed at mw:Extension:Scribunto/Lua reference manual#Ustring patterns or their uppercased versions (%a, %d, and so on), bracketed character classes involving non-ASCII characters, %b or %f with non-ASCII characters, or quantifiers attached to non-ASCII characters, you should be fine to use string.gsub instead of mw.ustring.gsub. Anomie⚔ 16:36, 5 February 2014 (UTC)

Doesn't something like mw.message.newRawMessage("text"):params("$1", "$2", "etc"):plain() already do this? Anomie⚔ 12:51, 4 February 2014 (UTC)

Aha. I thought there might have been something I was missing there. I was under the impression that the mw.message library was only for parsing MediaWiki's existing messages or messages in the MediaWiki namespace, but I do remember thinking that it would be a bit odd to not have some easy way of localising modules that people were writing. Asking earlier might have saved me from reinventing the wheel. I think what we need here is a Scribunto guide for new and relatively new coders who need lots of examples to see how all of this works. I'm sure I would have got it straight away if I had seen an example or two. (Thinks - perhaps I should try and get a WMF grant to write it myself.) — Mr. Stradivarius ^{♪ talk ♪} 13:43, 4 February 2014 (UTC)

To test my understanding of Anomie's advice, I put some code at Module:Sandbox/Johnuniq/message. Johnuniq (talk) 00:26, 5 February 2014 (UTC)

Test Case fail?

I've written a new module called NumberUsers and I'm having a problem with my test case. It says that it fails, but it looks identical. Could someone figure this out? Techman224^Talk 05:16, 11 February 2014 (UTC)

I'll mention that in general the way to investigate would be to put the following into Special:ExpandTemplates:

"{{#invoke:NumberUsers | users}}"

"{{NUMBEROFUSERS}}"

However, in this case, that's no use because the outputs are identical. My guess is that Module:UnitTests is seeing the text {{NUMBEROFUSERS}} and giving "failed" because that text does not match. However, something is expanding that to give the number when it is displayed on the results page. Johnuniq (talk) 06:04, 11 February 2014 (UTC)

 Fixed The proper method to use is preprocess_equals_preprocess. The second argument wasn't being parsed within Lua. -happy5214 07:28, 11 February 2014 (UTC)

mw.loadData

Hi, I have a question about this function. I would like to know if loading the same module multiple times from the same module has performance issues (or instead it's the same for some internal cache). Example:

local a = mw.loadData("Module:MyModule")
-- ... in the same module, somewhere else ...
local b = mw.loadData("Module:MyModule")

is it more expensive or is it just the same than:

local a = mw.loadData("Module:MyModule")
...
local b = a

Thanks in advance. --Rotpunkt (talk) 12:45, 20 February 2014 (UTC)

mw.loadData evaluates the module only once per article. I'm assuming that means the module data is cached internally, so the performance of both of your examples shouldn't be appreciably different. -happy5214 13:05, 20 February 2014 (UTC)

The second might be slightly more efficient, because it doesn't create a new wrapper object for the loaded data. It's probably not worth worrying about though. Anomie⚔ 22:18, 20 February 2014 (UTC)

Thanks to both of you, and thanks Anomie for the detailed informations. --Rotpunkt (talk) 23:56, 20 February 2014 (UTC)

Redirect Wikipedia talk:Lua/To do here

While I'm thinking about it, would anyone object to redirecting Wikipedia talk:Lua/To do to this page? At the moment, I think the discussions are too fragmented. We already have two talk pages - here, and Wikipedia:Lua requests. A third seems too much. — Mr. Stradivarius ^{♪ talk ♪} 12:52, 2 February 2014 (UTC)

No objection here. — Edokter (talk) — 13:20, 2 February 2014 (UTC)

Good idea. Johnuniq (talk) 01:23, 3 February 2014 (UTC)

Good, improvement. -DePiep (talk) 04:58, 2 March 2014 (UTC)

Code editor not showing up?

On my work computer the code editor shows up fine, but my home computer doesn't load it at all (no toolbars, no syntax highlighting, no line numbers). Both computers are running Chrome, but the work computer is on XP and the home computer is on Win7. I would expect the newer home computer to load better but it's been the other way around :/ Any ideas why this is happening and how this can be fixed? Thanks. _dk (talk) 16:38, 28 February 2014 (UTC)

You need Javascript enabled in your browser, and the code editor needs to be enabled if it has been disabled. There is an icon at the left of the toolbar just above the edit window which can be clicked to enable/disable. Johnuniq (talk) 22:28, 28 February 2014 (UTC)

Javascript has always been on (the toolbars are right above me as I type!), but in the Module namespace the toolbars don't even show up, let alone the enable/disable button. _dk (talk) 15:49, 1 March 2014 (UTC)

We need to get specific. If I enable Javascript and edit Module:Sandbox/Johnuniq/message, I see the following at the top:

Content that violates any copyrights will be deleted...

Toolbar with "/*" icon at left.

Toolbar with "Heading" and "Format" and more.

First line of code: "-- Adapt message() from..."

The "/*" icon is the enable/disable button. On mouse-over it shows "Toggle code editor". There is possibly something in Special:Preferences that controls this, but I can't see it. In my preferences, under the Editing tab, I see "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar", but I have both of those off. If you can't find anything, please try WP:VPT. Johnuniq (talk) 01:35, 2 March 2014 (UTC)

Going from your example, this is what I see:

Content that violates any copyrights will be deleted...

Preview of the code

First line of code: "-- Adapt message() from..."

I suspect it's a memory issue, like how gadgets on Wikipedia will just shut down and not load when I don't have enough RAM? I found that it loads once in a while if I refresh a few times. Thanks for the help anyways. _dk (talk) 18:23, 2 March 2014 (UTC)

If it shows up every once in a while, then it sounds like either a connection problem or a lack of system resources on your computer. Sometimes on slow connections the page takes long enough to load that the browser gives up on trying to download the JavaScript, and CodeEditor is implemented in JavaScript, so that means that it won't be run. Also, if your system doesn't have the necessary memory or other system resources to run the JavaScript, then that means it won't be run either. If you are experiencing the same kind of issues with Wikipedia gadgets, then the system resources explanation would make the most sense. You could dry disabling some of your user scripts and see if that helps. — Mr. Stradivarius ^{♪ talk ♪} 00:38, 3 March 2014 (UTC)

Page-global variables

Is there a (documented) way of defining a variable whose value is kept in subsequent invocations of a module? For instance, say that I have a module MyTableGenerator. I would first call {{#invoke|MyTableGenerator|set_default_background_color|red}} and then, every call to {{#invoke|MyTableGenerator|generate_a_table|...}} would generate a table with a red background.

On the French Wikipedia, some modules simulate this by calling getContent() on the page itself and doing a regexp search in the source code. I am looking for an alternative.

Orlodrim (talk) 21:38, 5 March 2014 (UTC)

There is no mechanism for allowing information to persist from one invoke instance to the next. Dragons flight (talk) 21:45, 5 March 2014 (UTC)

In fact, it is specifically intended that there not be a way to transfer information from one invoke to the next. VisualEditor and Parsoid want to be able to reparse portions of the page without having to worry about reparsing the whole thing. Anomie⚔ 22:21, 5 March 2014 (UTC)

• Even worse, there (wa|i)s a way when there is not suppose to be. This will be fixed very shortly if it has not already been fixed... — {{U|Technical 13}} ^{(t • e • c)} 23:04, 5 March 2014 (UTC)

os.date() not working properly?

A week or so ago as the result of a new topic at Module talk:Citation/CS1, I did and experiment in the debug console using this: =os.date("Y") which returned the current year. Today, after adding that code to Module:Citation/CS1/sandbox, I got series of script errors that eventually showed that os.date("Y") is returning Y. I didn't test them all, but the several format characters that I did test simply returned the format character.

If the functionality of os.date has been changed, then the os.date documentation is also in need of change.

I got round the problem with os.date("*t").year.

—Trappist the monk (talk) 15:28, 7 March 2014 (UTC)

I doubt =os.date("Y") ever worked. os.date uses the same syntax as strftime, as is documented, so you'd need =os.date("%Y"). Anomie⚔ 19:34, 7 March 2014 (UTC)

Argh! Facepalm. Thanks.

—Trappist the monk (talk) 19:44, 7 March 2014 (UTC)

Minor bug

I noticed that if I add a strip marker for <references /> with nothing in front of it, it generates no text, but adding an "x" in front of it makes it spit out the last reference in an unused variable. [2] There are a bunch of things that could affect that, and I know the code was being worked on because of side effects from ref tags carrying from one routine to the other. I doubt it matters to real-world examples unless it's something more general, but might as well ask if anyone recognizes the problem. Wnt (talk) 18:14, 21 March 2014 (UTC)

I see what's going on. Calls to frame:preprocess are cached somewhere, so the first time you run frame:preprocess("<references />") it caches the blank result, then the next time, instead of actually parsing it, it returns the blank result again. When you do frame:preprocess("x<references />"), it doesn't have it cached, so you get the right result. If you change both functions to frame:preprocess("x<references />"), then it's cached again, so it stops working again. @Anomie: ping. Jackmcbarn (talk) 19:37, 21 March 2014 (UTC)

(Also, as a side note, you have to unstrip it to see it). Jackmcbarn (talk) 19:38, 21 March 2014 (UTC)

Thanks - I verified the bug does behave as you suggest (I should clarify that the unstrip is not required to see the change in output, though it may be useful in debugging it) Wnt (talk) 21:42, 21 March 2014 (UTC)

I just tried a different test [3] that doesn't use strip markers, and those aren't cached: a set of frame:preprocess() of things like "#. Pennsylvania" doesn't repeat the numbers. So far I can't think of a strip marker other than <references /> that should change while the page is put together (well, the system timestamp should change a little, but it's neither predictable nor guaranteed...), so maybe a very specific fix would work, and it may indeed be quite minor of a bug anyway. Wnt (talk) 21:54, 21 March 2014 (UTC)

I think you're correct that as of right now, only <ref> and <references /> have side effects. This is a general issue with Extension:Cite that there's really no good fix for. Jackmcbarn (talk) 22:30, 21 March 2014 (UTC)

I tried to fix it, but the Parsoid people wouldn't go for it. They'd rather add a whole extra pass to the parser, basically re-parsing the page to handle the references after the normal parse put in placeholders. Anomie⚔ 03:26, 22 March 2014 (UTC)

Wow. Looks like this bug has been known a long time and does have a very serious effect, if you still can't use {{reflist}} twice on the same ordinary wiki page without bugged output. I'm surprised people have put up with that. Your reaction reminds me a little of when I was on about those beloved mw.message hacks before -- I think those words "not encourage" tend to have that effect on a person -- though admittedly life with multiple developers revising a mountain of code with a Freddy Krueger pedigree may teach people to think differently about these things. But... to me that last comment by GWicke "I guess it *is* different if you see this as just a temporary and internal flag to be used by Cite only. I'm fine with that if documented clearly." sounds like it was leaving the door open a crack, maybe? Wnt (talk) 14:55, 22 March 2014 (UTC)

CodeEditor Feedback desired

Please read and give your input about what you are looking for in the CodeEditor toolbar —TheDJ (talk • contribs) 00:14, 26 March 2014 (UTC)

Module:Yesno update

I'm thinking of updating Module:Yesno from the version at Module:Yesno/sandbox - please see Module talk:Yesno#New version if you're interested in commenting. — Mr. Stradivarius ^{♪ talk ♪} 15:25, 7 April 2014 (UTC)

Trouble of template inheriting module parameters

I've created module:MTR and its "icon" function is invoked by {{HK-MTR icon}}. The icon function apparently looks OK when the arguments "text" and "link" are given values directly as shown in the module doc. But when I transclude the module in the said template with parameters 2 and 3 inheriting arguments "text" and "link" of the module respectively with parser function #IF:, the values for these 2 arguments are seemingly ignored completely. Please help. -- Sameboat - 同舟 (talk) 08:40, 10 April 2014 (UTC)

I've simplified the template invocation. Let me see what I can make of the module. — Mr. Stradivarius ^{♪ talk ♪} 09:45, 10 April 2014 (UTC)

Hmmm, I should retire. I took a quick look at the template and thought that there was no reason to pass the template's parameters in that fashion, and then blanked that out of my mind and used what "should" have worked (local args = frame:getParent().args), but that failed with the way it is actually used. I started just before you replied here, so I'll leave this to you. Johnuniq (talk) 10:13, 10 April 2014 (UTC)

(edit conflict) Ok, I've finished. I actually had second thoughts and used frame:getParent, so there are now no parameters in the template invocation. I've also moved the data to Module:MTR/data so that it can be loaded with mw.loadData. @Sameboat: using frame:getParent means that the arguments are passed straight through to the module from template invocations like {{HK-MTR icon|IL}}. And using mw.loadData means that we cache the data so that it only has to be processed once per page, rather than once per #invoke, which should boost performance. It also has the bonus that we can put the data in a more easily-readable format. Let me know if it's all working as it should, and feel free to ask if you have any questions about the code. You've made a great start programming in Lua, and I'll be happy to help you improve. :) — Mr. Stradivarius ^{♪ talk ♪} 11:35, 10 April 2014 (UTC)

Sadly your simplification for the template doesn't work. You can see the result in the examples of the template doc (may need purge). -- Sameboat - 同舟 (talk) 11:24, 10 April 2014 (UTC)

@Sameboat: Ah, sorry about that. That's because I made it so that accessing the module directly via #invoke won't work, but accessing it through a template will. That's easy to fix, but it will make the module slightly slower, and should probably be avoided if it's going to be used many times on one page. I've updated the examples on the module page to use the templates rather than to use #invoke. — Mr. Stradivarius ^{♪ talk ♪} 12:02, 10 April 2014 (UTC)

Thank you very much. I'm relatively new to lua and this is the first ever real module I've ever created as you can tell from the original layout, so I need some time to catch up to your optimization. -- Sameboat - 同舟 (talk) 12:34, 10 April 2014 (UTC)

@Mr. Stradivarius: Just one more thing. The "colorbyname" function also needs to change the argument value to all caps as in "icon" function. I simply copy code = code:upper() to the "colorbyname" table. Is it possible to simplify this step so the same uppercase command doesn't need to repeat in case more functions are implemented to the module later? -- Sameboat - 同舟 (talk) 14:40, 10 April 2014 (UTC)

Yes, you can put something like this in the makeInvokeFunction function:

local code = args[1] or ''
code = code:upper()
args.code = code

That way you only have to do it once. It also means that args[1] will always be retrieved from wikitext, but that's fine here as it's going to be used in both functions anyway. — Mr. Stradivarius ^{♪ talk ♪} 14:57, 10 April 2014 (UTC)

ucfirst

What would be the code to produce an {{ucfirst:}} (first character into uppercase)? I am expecting string functions and patterns. -DePiep (talk) 20:29, 13 April 2014 (UTC)

@DePiep:

mw.ustring.upper(mw.ustring.sub(str, 1, 1)) .. mw.ustring.sub(str, 2)

Jackmcbarn (talk) 20:36, 13 April 2014 (UTC)

Aaahrgh ... no pattern needed. Thanks. (I consider, my last frustrating hours & edits were a "learning experience"). -DePiep (talk) 20:43, 13 April 2014 (UTC)

You can also use mw.language.getContentLanguage():ucfirst(str). — Mr. Stradivarius ^{♪ talk ♪} 12:30, 22 April 2014 (UTC)

The Lua editor

What is a (the) basic Lua editor, and how do I get one? Right now, I can't even search & replace, and irregularly (or Byzantine) every next Lua edit mode alters editor. -DePiep (talk) 22:28, 30 March 2014 (UTC)

The default is CodeEditor, which loads automatically when you edit a module page (or a .js or .css page). Do you see it when you edit a module page? It looks like this, although the colour scheme has changed since that screenshot was taken. A lot of the settings are only available through keyboard shortcuts at the moment - for example, search and replace is accessible by pressing CTRL+F twice (CTRL+F once is just search). See here for a list of default shortcuts. Myself, I use a combination of GVim and It's All Text, but the setup process for that is fairly involved, and GVim has a steep learning curve. — Mr. Stradivarius ^{♪ talk ♪} 02:04, 31 March 2014 (UTC)

One subtle point is that if you ever click the "/*" icon at the top left of the "looks like this" link from Mr.S's post, you will switch the code editor off, and it stays off until you click that icon again. On the point of an external editor, I saw the recent discussions regarding enhancements to the amazingly feature-rich CodeEditor, and personally I would worry a lot about the prospect of using a browser for a serious coding session. Like many people, my network and computer and software are very reliable, but I would never spend more than five minutes editing in a browser edit window because the slightest glitch would cause everything to disappear. I once investigated things like "It's All Text", but in the end decided that copying between browser and editor was sufficiently simple that I wouldn't bother with another layer. Johnuniq (talk) 03:15, 31 March 2014 (UTC)

I agree about the external editor point. When I've edited with CodeEditor in the past, I've lost my work on more than one occasion by pressing CTRL+R instead of CTRL+F. In most browser setups, CTRL+R refreshes the page, which means that you lose everything that you've done since your last edit. I understand that there's a fix in the works to bring up a dialogue in CodeEditor if you try and navigate away from the page, but in general it is still safer to stick with an external editor. — Mr. Stradivarius ^{♪ talk ♪} 04:20, 31 March 2014 (UTC)

I also use an external editor for most coding. I'm partial to Vile instead of Vim, but that is only because of starting to use it a long time ago. At this point, Vim is probably a better choice, given its popularity (implies more developers). However, I have not really compared the two.

I have not done a large amount of editing using the CodeEditor. For normal Wikipedia page editing I rely on the Firefox extension Textarea Cache to auto-save the textbox data. It appears to work reasonably well. Recovering from a Firefox crash – dramatically more frequent for me starting about 2 months ago – is easy and results in minimal loss. It, unfortunately, does not work on the CodeEditor edit box. I must admit that I had assumed that Textarea Cache would save the text area when using CodeEditor. However, I just tested it and it does not. I have not looked for an automatic solution to auto-saving the CodeEditor text area yet. If I don't find something easily, I'l probably hack Textarea Cache. On the other hand, I'll probably end up just using Vile.

As to the ctrl+R issue in CodeEditor: At least on Firefox, once you have clicked on either "Show preview" or "Show Changes" the ctrl+R will result in a pop-up asking if you want to resend the data instead of automatically re-loading the page. Thus, a workaround for that issue is to click "Show changes" every time you start editing a page with CodeEditor. For most other pages, Firefox already pops up a confirm dialog if you are leaving the edit page once the contents of the textbox change. — Makyen (talk) 05:52, 31 March 2014 (UTC)

Thank you all for your careful replies. Still, I am not looking for any 'external' solution, nor for a CE manual. I just want the default editor for modules to function. CE does not. And up in the tree (via WP:VPT to mw:) I have not met a single interest about for this. One peculiar recent branch is Wikipedia:VPT#CodeEditor_Feedback_desired OP by TheDJ, which shows activity but does not gave me a single useful link. -DePiep (talk) 20:26, 13 April 2014 (UTC)

CodeEditor is the default. If you have a problem, please come talk to me about it and I'll see what I can do. The above and earlier comments don't really give me enough context. There is a known problem with WikEd leading to unexpected behavior, and that will eventually be solved. If you have OTHER problems (so you have fully disabled the WikEd gadget in your preferences and still have problems), then please describe them, tell me your browser/OS version, file bug reports in bugzilla, make screenshots or basically ANYTHING that makes it actionable instead of vague remarks. Also, don't expect me to solve it within a week, I'm a volunteer and I don't always have time to solve complicated problems within short notice. But currently, i simply still don't understand what your problem is, proving that in 3 threads you have not done enough to explain it to me. —TheDJ (talk • contribs) 12:47, 23 April 2014 (UTC)

@DePiep: Yes, it's very hard for us to know what the problem is if you don't do some troubleshooting first. Try and disable WikEd, bypass your cache, and then see if CodeEditor works. If not, try and disable other gadgets and user scripts until you find what the conflict is. — Mr. Stradivarius ^{♪ talk ♪} 13:00, 23 April 2014 (UTC)

Or look in the console. If CodeEditor fails to load, then it'll probably throw an error and that's shown in your browser's JS console. — lfdder 13:19, 23 April 2014 (UTC)

Creating a central, CS1-like Module to standardize Infobox template code?

At the moment, the way analogous tasks in different Infobox templates are done seems diverse and arbitrary. Take, for example, listing the non-English name of a (thing) in that (thing)'s Infobox. I've seen non-English names put in the same parameter as the English one, but with a <br> in the middle; put in a separate, non-language-specific parameter; and put in separate, language-specific parameters. All these different ways of performing what is essentially the same function, but in different templates, is (a) difficult to master for the editor, and (b) will surely lead to style inconsistencies somewhere or other. Would it be feasible to assimilate all Infobox templates to be based off a central Module, so that (a) we could have a standard set of parameters/parameter names for doing things for editors, and, consequently, (b) a set format that they would appear in for readers (w.r.t. font size, emboldening, and so on)? Thanks. It Is Me Here ^{t / c} 21:01, 5 April 2014 (UTC)

References

I'd like to point out that user Hoo man has been working on an extension with a lua module called Capiunto, that makes it easier to build Infoboxes in a more consistent method for sites (not every wiki has an active template community, able to handle all of these problems themselves). Taking this up to the level of content, parameter naming conventions and value validation goes a bit further then what Capiunto was envisioning so far, but it might be something to keep an eye on. —TheDJ (talk • contribs) 12:32, 23 April 2014 (UTC)

Odd problem with new template/module

Tracked in Phabricator
Task T19988

I'm having an odd problem with a module/template I'm working on at {{zh/sandbox}} and Module:zh . When it appears on its own in a paragraph, i.e. with blank lines either side, it seems to swallow white space.

Chinese: 香港

Chinese: 中国

Chinese: 北京

Compare that with the current template {{zh}} used identically

Chinese: 香港

Chinese: 中国

Chinese: 北京

This likely isn't much of a problem given how it's used, normally inline with text, e.g. Beijing (Chinese: 北京) is the capital of China (Chinese: 中国), which means an obvious 'fix' of generating blank lines (e.g. para breaks) within the template would only make things worse. I can't see anything though that's causing this. It only seems to happen with white space - I used lists here: Template:Zh/testcases with no problems.--JohnBlackburne^words_deeds 16:58, 26 April 2014 (UTC)

@JohnBlackburne: It's doing that because the lines end with [[Category:Articles containing Chinese-language text]] (which seems like it may be a bug). Jackmcbarn (talk) 17:02, 26 April 2014 (UTC)

Indeed, it's bugzilla:17988. Jackmcbarn (talk)

OK, thanks. Yes, It's different from the current template that embeds them more deeply in output, given the logic they seemed more sensible at the end but i can easily 'fix' it. The use of categories here is perhaps a bit unusual but then again citation templates do something similar, so it's odd if it's not been noticed before. Maybe people have just worked around it.--JohnBlackburne^words_deeds 17:13, 26 April 2014 (UTC)

I'd delegate lang-tagging and categorisation to {{lang}}, personally. In fact, why can't {{zh}} be just a wrapper for lang/lang-x? Anyway, you might be interested in contributing to Module:Language. — lfdder 17:27, 26 April 2014 (UTC)

Metatables will now work on export tables

Effective June 5th, metatables (specifically, the __index metamethod) will work properly on modules' export tables. For example, I've set up Module:Effective protection level to work this way. With this, you will be able to use {{#invoke:Effective protection level|edit}}, even though no "edit" function is exported by the module. You can try this functionality now on the beta cluster. Jackmcbarn (talk) 00:51, 27 May 2014 (UTC)

Nice work - this should make a lot of module code neater and more efficient. Will metamethods other than __index be available? (And will the __call metamethod enable Wnt to finally realise their dream of using #invoke with no function name?) — Mr. Stradivarius ^{♪ talk ♪} 05:07, 27 May 2014 (UTC)

I would think that __index should be enough. But is this live presently? I see this is used in the Effective protection level module above, and that module is linked from all sorts of places like Talk:England, but all I get trying to invoke ( for example) is errors. Wnt (talk) 07:30, 27 May 2014 (UTC) Also, trying to add the page on the beta server gets me "Exception from line 832 of /srv/common-local/php-master/includes/jobqueue/JobQueueRedis.php: Redis server error: Could not insert 1 cirrusSearchLinksUpdatePrioritized job(s)." Maybe it's just down for now? Wnt (talk) 07:38, 27 May 2014 (UTC)

@Wnt: It doesn't work here because the functionality hasn't been deployed here yet. I fixed the link I gave to the beta cluster, so it should work there now. Jackmcbarn (talk) 12:55, 27 May 2014 (UTC)

@Mr. Stradivarius: The issue with not using a function name isn't that the __call metamethod wasn't being used, but rather that it wouldn't be able to tell whether you specified a function name or just the first parameter. I do have an idea for that, though, which I'll probably submit something for soon-ish. Jackmcbarn (talk) 12:55, 27 May 2014 (UTC)

I had a pass at it at [4]. So far as I know __call shouldn't be used - the invoke looks up which function to run out of the table rather than calling the table. I had one revision where I actually tried setting the __call method but nothing happened; this is all __index. Wnt (talk) 15:31, 27 May 2014 (UTC)

Right. __call has nothing to do with this. Jackmcbarn (talk) 15:42, 27 May 2014 (UTC)

This syntax may be especially nice with nice simple modules that take one parameter. With those the function name field will still parse correctly even if it contains "=", rather than being split into a parameter name and value unless you do "1=" at the beginning. However, you can't do that if there are other unlabeled parameters (I think) ... at least, strange things happened when I tried recently, with the first unlabeled parameter value (after the function name) seeming to go missing. And of course, the other (real) parameters won't work with "=" in them. Wnt (talk) 20:20, 27 May 2014 (UTC)

Move this page

Hi,

Scribunto it's a little bit different than Lua. In Wikipedia, we have Scribunto, not Lua. In consequence it's beter to name this page Wikipedia:Module.

Thanks to say me what do you think about that,

Regards,

--Juanes852 (talk) 11:49, 16 May 2014 (UTC)

P.S Excuse-me for my bad english, but I'm a French speaker.

If I understand this topic well: in the future, Scribunto could cover other script languages as well. Next to Lua. So focussing on Lua is OK. IN the future, there could be a Scribunto-handled script "HollywoodScript" sitting next to this Lua.

It is not so that the Lua-in-wiki language is called Scribunto.

PS A HollywoodScript language probably would be useful for vapor, vanity, tinsel and non-existing topics ;-) . -DePiep (talk) 12:14, 16 May 2014 (UTC)

Maybe one day this will change but right now Scribunto is Lua on Wikepedia. Yes, WP:Lua is not the same thing as Lua, but WP:Verifiability is not the same as Verifiability. If you want to learn about Lua go to Lua. If you want to learn about, or participate in, Lua on Wikipedia come to Wikipedia:Lua. Meanwhile redirects help anyone expecting to find this page at another plausible location such as WP:Scribunto.--JohnBlackburne^words_deeds 13:22, 16 May 2014 (UTC)

Instead of "Hollywoodscript", how about brainfuck? Barnstar for the first editor who makes a Mindfuck module that runs faster and takes less space than an existing template. (I remember one template that searched for articles for future years that would have been a good candidate...) Wnt (talk) 02:23, 28 May 2014 (UTC)

Versioning the scripts and modules

It seems to me that the Lua programming scene here is relatively new, so I am wondering if anyone has thought of versioning the scripts? I was looking over the archives and came across some comments about how Lua scripting could get a bit harry depending on the libraries chosen. Wouldn't it be fair to assume that at some point in the future, an update to Lua or its dependencies could break old code, and that code writers should specify which version of Lua is required to run the script? I was even thinking that Lua itself could determine this by a comment field based on a UTC date code. Maybe a simple lookup could be done to determine what version of Lua was active on that date, and run the proper version at that time. I would also suppose that version changes would be relatively few, so the same Lua would be active for 6 to 60 days at a time.

An old saying that I recall about programming and code versions was to "keep the tree green," meaning to ensure that everything in a codebase continues to compile and run whenever the tree is updated with new code.

If such a system is implemented, a system-wide change could be implemented at any time without notifying a thousand code maintainers to watch for any new scripting issues! People maintaining large codebases (Template:Convert always comes to mind) could verify the new version in their next sweeping update of the underlying template or script.

So let me give an example. Let's say that there is a call to Module:Yesno, Module:Sort, and Module:Compare on a particular Lua script called Oldie. The YesNo module changes in 2015 due to some expansion of the codebase unrelated to the script. There's no danger there. But in 2016, the Sort Module gets a major facelift and rewrite from scratch which would break or incredibly slow down Oldie. In 2017, someone asks why every page with Oldie has this strange bug or warning or glitch or slowdown... it takes another couple of years to realize that Oldie was broken years ago and no one was maintaining it. But if Oldie had been time-stamped or versioned, all of those problems would be eliminated because it would have

1. Been using old versions of the Module:Sort all along
2. Been on the "radar" of Lua scripters who were watching for potential problems when Sort changed
3. Been on the "radar" of site administrators when they saw that Oldie was still using code from 2014 and it needed to be tested with the latest version of Lua

By versioning the scripts, there can be a database of script age and version, along with statistics about what scripts use what version of Lua and which ones would be likely candidates to be human-edited. For example, if a very large and very widely deployed script is using ancient code, then it would be a higher priority than small scripts used on 10 or 20 user pages.

I guess a drawback would be whenever there is a need to create both a Module and a script that depended on the module. A person would need to somehow specify that it depended on a particular module unconnected to the version of Lua running. So it would need to call the module explicitly, perhaps specifying the module's version until the module was acquired by the system-wide Lua. I like to saw logs! (talk) 06:46, 29 May 2014 (UTC)

This seems like a strange case of serendipity, but it just so happens that I came across a borken module. I have no idea when it borked, or why, but my guess is that when it was produced in January 2014, whatever the codebase and situation was at the time caused this module to work:

{{#invoke:Module overview|getTable}}

.... but now it no longer does what the writer intended. I found at this page: Wikipedia:Lua/Modules a few minutes ago. I immediately realized that the module code was borked, so I reverted it to a previous version. Is this happening to other Modules? Is this coderot? And would versioning help? Or I am I just a crazy outsider sticking her nose into things? I like to saw logs! (talk) 07:48, 29 May 2014 (UTC)

The module hadn't been changed since January. I think what happened is that {{Special:AllPages|namespace=828}} used to return a list of groups of pages that you could view page by page, but now it just delivers the full alphabetical list starting from the beginning, confusing the module. Wnt (talk) 12:25, 29 May 2014 (UTC)

I don't really see a benefit to this type of versioning, and like Wnt said, it was a change to MediaWiki that broke it in your case, not a Lua upgrade. Jackmcbarn (talk) 14:34, 29 May 2014 (UTC)

I think Uruiamme may be onto something though. It would be nice to have a verification that "this module worked with Mediawiki version N". Right now there is a Category:Pages with script errors. I think it would be a useful routine system maintenance step to save the contents of that category before each Mediawiki upgrade, and compare the list afterward. A bot could check every entry (at least in Module talk: space) and give a notification to the last person to edit it if there is a script error there after the upgrade that wasn't present before. Or maybe there's a way to integrate that directly into the round of page reparsing that I assume must occur after an update? Unfortunately, with the cool mw.message functions taken out, there's no way within Lua to scan all of your module talk pages to see if there are script errors in the cached version without actually parsing them all, which would run afoul of time limits. Wnt (talk) 18:03, 29 May 2014 (UTC)

I don't see how Lua scripts are going to be maintained on such a decentralized system like Wikipedia unless you take this type of criticism at face value. A "normal" codebase is often managed by overseers and team leaders, even those open-source large codebases out there. And even those usually have some method of determining who gets the keys to make major system changes. In a place where "anyone can edit," at what point does someone either maliciously or erroneously throw a monkey wrench into a script or two and cause a meltdown at the front end? A meltdown that could make the evening news broadcast... Wikipedia crashes due to code glitch... Website see garbled mess of errors and frozen screens. I was just thinking you could make it a little more difficult to kill off the hard work of others by forcing coders to EXPLICITLY specify their assumptions. Code writers make assumptions, and one of those is that the set of ingested modules and called functions will not change but be essentially static.

My plan would be to have an automated way of maintaining backward compatibility as the underlying modules and functions get updated over the years. I am trying to put the burden on the frontend (a simple version spec in the code) rather than on the back end (2018, when the script breaks and no one who wrote it is around to fix it). I like to saw logs! (talk) 18:22, 29 May 2014 (UTC)

I think you're trying to do the impossible. Jackmcbarn (talk) 18:37, 29 May 2014 (UTC)

Yes. One 'problem' with being the encylopaedia that anyone can edit is stuff gets changed all the time, by literally thousands of editors making many thousands of edits. No-one sets out to break stuff but stuff breaks all the time. It gets fixed as it's noticed but the old version is still broken. You look at any reasonably old version of a page and it's often a complete mess with missing images and categories, missing or broken templates, dead links. I've seen suggestions that these pages should be maintained so they keep working but that would not only be a massive amount of work but would require major revisions to policies on deletion, moving and renaming (e.g. categories), to no real benefit.

Lua now is mostly compatible as it's all new. But give it a few years and APIs will change, be added and old one deprecated and removed. Coding standards might develop for performance reasons or consistency in formatting. New languages might be added alongside Lua requiring new interfaces and inter-script communication methods. Modules will be updated accordingly and there's no guarantee old versions will still work. As for articles keeping them working would potentially be a massive amount of work, require at least the deletion policy to be revisited, for no real benefit.--JohnBlackburne^words_deeds 19:08, 29 May 2014 (UTC)

Just to clarify, I wasn't talking about someone in 2018 going back to a 2014 revision of an article. I was talking about a regular page with a Lua script in which the script stays unchanged for those 4 years. In that time, the output of the Lua script rots, and in 2018 the output is erroneous. However, in 2018, visitors to the page cannot perhaps easily detect that a change of output occurred, so they see what appears to be a factoid (like a numerical "200") that was originally something else (like a numerical "243"). I don't see that there is a lot of work involved, especially given the possibilities of unintended consequences. A more dire result would be an error that involved something that actually overloaded or crashed something, like using up to the maximum amount of processor time permitted. This borders on a security issue because of the way resources could be over-used. Imagine this happened to one script that was embedded in 100 pages, 1000 pages, or more.

I am looking for the Lua equivalent of a Windows compatibility mode or something, like you see made available when Windows updates their operating system, and due to version declarations, the software must be run with a different set of run-time parameters.... or when you have multiple versions of mysql installed, and you specify the full path to the executable each time. I like to saw logs! (talk) 08:42, 2 June 2014 (UTC)

This is in theory already a problem though. WP's been around far longer than 4 years and things are changing all the time. We cope. Changes to e.g. the WP software go through a process of identifying a need, writing the code, reviewing it, optionally testing it (on e.g. a test wiki or as an opt-in feature) before wide roll out. Problems still occur, as they often are only apparent on a live wiki. But they get fixed. They get spotted and reported to a noticeboard. Or the problem adds the page to a tracking category. Or someone downloads the database dump and runs a program to find problems.

Lua makes this all much much easier. warnings make it much easier to spot and fix code problems. Problems are easier to identify in source as it's so much more readable than parser functions. The better flexibility of the code makes it easier to add things to spot problems, such as tracking categories (see e.g. the work that's been done to fix citation templates since the conversion to Lua). As a standard language Lua's better documented and understood, so problems caused by obscure language behaviours shouldn't happen so much. Lua's better performance means hacky workarounds likely to break are less needed. And so on. It really should make it much easier to find problems and I don't think we need to do anything more.--JohnBlackburne^words_deeds 10:09, 2 June 2014 (UTC)

Lua exposes "_VERSION" which can be used to check what version of Lua is running. However, I think feature detection is a better option. For example to set the environment in a version independent way:

function set_env(env)
  if _G ~= nil and type(_G.setfenv) == "function" then
    setfenv(1, env);
  elseif _G ~= nil and _G == _ENV then
    _ENV = env;
  end
end

A set_env that depends on _VERSION may fail to detect all working or non-working occurrences. --darklama 15:40, 31 May 2014 (UTC)

Duplicated template parameters

One of the most common errors I find in templates is the duplication of parameters, like this:

{{Foo
|Year = 1900
|<cut>
|Year =
}}

The second "Year" shadows the first one, so inside the template (and inside a module implementing the template) I read an empty string instead of "1900".

AFAIK there is no way of catching this type of error, so I was wandering if it would be possible to add a new frame sequence table, like frame.duplicatedArgs containg the list of parameters duplicated, just the names. In this way when #frame.duplicatedArgs > 0 I can show an error and/or add the category "Pages with template Foo and duplicated parameters". --Rotpunkt (talk) 08:47, 29 May 2014 (UTC)

I don't think it's likely you'll ever get a duplicatedArgs table, but what you may eventually get is the raw text in its entirety used in the template invocation. Jackmcbarn (talk) 14:31, 29 May 2014 (UTC)

Hi, you say that because the parser doesn't have this information? BTW I also don't understand why the parser allows the duplication of a template parameter... am I missing something? --Rotpunkt (talk) 16:07, 29 May 2014 (UTC)

Right, that information gets thrown away too soon to give it in the format you'd want it in. The parser only "allows" it because one of the design requirements for the parser is that it allows everything. It's not allowed to fail parsing a page. Jackmcbarn (talk) 16:17, 29 May 2014 (UTC)

Thanks for the explanation. Actually I did not think to a parser failure but it could be simply a warning like MediaWiki:Parser-template-loop-warning, MediaWiki:Parser-template-recursion-depth-warning or a category like MediaWiki:Expensive-parserfunction-category. --Rotpunkt (talk) 16:34, 29 May 2014 (UTC)

That's actually a good idea. I'll see if I can implement that. Jackmcbarn (talk) 16:35, 29 May 2014 (UTC)

It would be great, thanks in advance. --Rotpunkt (talk) 16:46, 29 May 2014 (UTC)

This is a good idea overall, but you'll need to be careful not to break legacy templates that might intentionally override parameters for some reason tied to the restrictions of the template "language". So you may need to explicitly mark templates to show warnings for this to happen, at least at first. Wnt (talk) 18:15, 29 May 2014 (UTC)

All my patch does is add pages to tracking categories if they do that. It doesn't change how they parse. Jackmcbarn (talk) 18:17, 29 May 2014 (UTC)

The categorizing breaks a page in this situation: [[History of foo|{{Foo|Year=1900|Someparam=bar|Year=}}]] (the wikilink is not rendered as expected, wikicode shows). -DePiep (talk) 18:01, 31 May 2014 (UTC)

No it doesn't. When the preprocessor adds the category, it doesn't have to emit the text [[Category:Pages with duplicated arguments]], like a template would have to. It just tells the parser to place the page in the category, without affecting the output at all. Jackmcbarn (talk) 18:14, 31 May 2014 (UTC)

Aha. Clear. -DePiep (talk) 18:51, 31 May 2014 (UTC)

Announcing Module:File link

I've just finished writing Module:File link, which is used to format links to multimedia files. For instance:

local fileLink = require('Module:File link')
local obj = fileLink.new('Example.png')
return obj:width(220):alt('Some alt text'):caption('The image caption'):render()

This will return the following wikitext:

[[File:Example.png|220px|alt=Some alt text|The image caption]]

I'd appreciate it if people could look over the module syntax to see if the method names etc. make sense, and if anything could be improved. After we have a finalised syntax I plan to write some test cases to make future updates to the code easier. — Mr. Stradivarius ^{♪ talk ♪} 10:53, 1 June 2014 (UTC)

Use cases for frame.uargs

Currently, with frame.args, a call like {{#invoke:Bananas|main|{{bar|5}}}} only shows Module:Bananas the expanded contents of Template:Bar. A new feature, frame.uargs, would cause it to be able to see the string {{bar|5}}. Notably, a call like {{#invoke:Bananas|main|<ref>whatever</ref>}} would allow the code to be able to see the argument without immediately adding the reference to the reflist. This feature is currently undergoing review, and I was asked to find more use cases for it. Can anyone think of use cases for this? The main one I've thought of is implementing the special-casing of Template:Orphan inside Template:Multiple issues. @Mr. Stradivarius: @Wnt: ping. Jackmcbarn (talk) 23:51, 3 June 2014 (UTC)

It would allow us to convert Template:Ubxdisplay/random. Without uargs, a module would have to expand every single userbox to find out how many userboxes there were. — Mr. Stradivarius ^{♪ talk ♪} 00:10, 4 June 2014 (UTC)

I'm not sure how convincing a userbox template would be. I think they'd rather see something that gets used in articles. Jackmcbarn (talk) 00:18, 4 June 2014 (UTC)

Module:Category handler does something very similar, come to think of it. It expands all the namespace arguments to find out if any namespace arguments were used (that's the nsParamsExist function), but it only actually needs two of them in the output - the "all" argument and the argument for the current namespace. Using uargs would save expanding the unneeded namespace parameters - and {{category handler}} is used in 2.5 million pages. — Mr. Stradivarius ^{♪ talk ♪} 02:58, 4 June 2014 (UTC)

@Mr. Stradivarius: The way the preprocessor works, it halfway-parses the arguments before Lua even starts running, then finishes parsing them if you look at them in frame.args. With frame.uargs, the unparsed arguments are already gone before Lua starts, so it has to un-parse the halfway-parsed arguments when it's called. This means that if the arguments are simple, uargs is basically the same speed as args (but if there's arguments that do take a long time to expand, like big templates, then uargs is much faster). Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

That's more complicated than I imagined. I seem to remember that sometimes {{category handler}} is passed templates as input rather than just category wikitext, but I can't remember off-hand anywhere where this is done. — Mr. Stradivarius ^{♪ talk ♪} 03:47, 4 June 2014 (UTC)

Sounds inefficient to me. I suspect you meant to type that "args" is much faster and not "uargs", unless I misunderstood your comment. I think the mediawiki parser needs a hook or something that passes the unparsed state to extensions early before the parser has discarded it, which would avoid having to recreate the unparsed state, and allow for additional features. --darklama 13:18, 4 June 2014 (UTC)

@Darklama: No, I meant uargs would be faster. Here's an example: Suppose there were a page with Here's some text{{foo|{{bar|3}}|baz|<ref>qux</ref>|paramname=paramvalue}}<ref>here's a reference</ref> as the contents. When MediaWiki first starts parsing it, it goes over the whole thing and turns it into <root>Here's some text<template><title>foo</title><part><name index="1"/><value><template><title>bar</title><part><name index="1"/><value>3</value></part></template></value></part><part><name index="2"/><value>baz</value></part><part><name index="3"/><value><ext><name>ref</name><attr/><inner>qux</inner><close>&lt;/ref&gt;</close></ext></value></part><part><name>paramname</name>=<value>paramvalue</value></part></template><ext><name>ref</name><attr/><inner>here's a reference</inner><close>&lt;/ref&gt;</close></ext></root>. If you request, for example, frame.args[1], it takes the contents of that value tag, <template><title>bar</title><part><name index="1"/><value>3</value></part></template>, and finishes parsing it, actually expanding Template:Bar here. If you were to instead request frame.uargs[1], it takes the same contents, but instead turns them back into the text {{bar|3}}. If Template:Bar is trivial to expand, these take about the same amount of time, but if Template:Bar takes a long time to expand, then args is a lot slower than uargs, since uargs doesn't have to expand it. It can't save the unparsed version, because until it parses into that format, it doesn't know which argument is which. Jackmcbarn (talk) 14:31, 4 June 2014 (UTC)

@Jackmcbarn: I definitely misunderstood. I wasn't thinking about xml output at all. I thought by half-parsed you meant templates were replaced with their wikitext content without parameter, magic word, or other substitutions, and from that half-parsed state un-parsing involved somehow extracting how templates were called. --darklama 15:40, 5 June 2014 (UTC)

Sounds like this could be useful for the tl templates to simplify demonstrating examples.

Unit testing frameworks could benefit by allowing template-like arguments with custom data that exposes more information about the passed template to generate test cases for you. {{#invoke:unit tester|run|{{template|arg1[number,optional]=|arg2[string]=|arg3[default=foobar]=}}}}

Modules could see {{{arg#}}} in the invoke and know to look for arg1, arg2, arg3, etc. from the calling template. --darklama 00:35, 4 June 2014 (UTC)

The tl example is the best I've heard so far, and the others are good too. Thanks. Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

{{convert}} needs to parse input values which can have weird syntax, mainly for fractions. People sometimes put a reference next to the number, and that gives an error like this: {{convert|12<ref>whatever</ref>|m}} → 12 metres (39 ft) A subtle feature of the error message is that hovering the mouse over it shows the specific problem. That's done by function message in Module:Convert which receives "12" followed by a strip marker. The function has to look for and remove the strip marker because it interferes with the mouseover title. I mention all that in case it's of any interest, but I am satisfied with the workaround the code implements, and I don't think convert would need uargs. Sometimes (rarely) people use a template or {{#expr:...}} to pass a value to convert, and it's good to receive the result of the evaluation.

References

Hmmm, something in MediaWiki has changed because the mouseover is showing 12... instead of 12<ref>...</ref>. Johnuniq (talk) 00:50, 4 June 2014 (UTC)

I didn't look up the commits, but the feature I'd most want would be a single unprocessed arg containing everything in the call. That way a module can ignore any use of "=" other than in SomeArgIRecognize = something; i.e. you would never have to say 1=, 2= again, or worry that an #invoke would break if edited an "=" into some previously working text. If it did the same for the parent, the same would be true of templates designed to use it. Wnt (talk) 02:01, 4 June 2014 (UTC)

I haven't looked closely yet, but I think enough information gets thrown away early enough that this isn't feasible. Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

Anyone else having trouble with CodeEditor?

Over the past couple of days I haven't been able to get the code editor to come up, or even expand a script error, despite enabling scripts. Firefox gives me an error on index.php line 36 that GetElementById('wpPreview') is null, and indeed, I don't really see any such element. I'm using NoScript, but I've set it to allow scripts globally, so in theory that shouldn't be the reason. Wnt (talk) 20:10, 8 June 2014 (UTC)

I haven't seen it for at least couple of weeks. It's a week since I did any coding but I look at modules fairly regularly and it's just not appearing. Latest version of Safari with Javascript enabled and no errors in the log.--JohnBlackburne^words_deeds 20:34, 8 June 2014 (UTC)

It's working fine for me. John, have you tried clicking the "/*" button at the top left of the editing window on module pages? That toggles CodeEditor on and off. — Mr. Stradivarius ^{♪ talk ♪} 21:33, 8 June 2014 (UTC)

The button's missing, has been for as long as the CodeEditor. I just have the edit toolbar with a √ in the top left corner.--JohnBlackburne^words_deeds 22:00, 8 June 2014 (UTC)

OK, after a lot of fiddling I fixed the problem, at least for me. (re) enabling the 'enhanced editing toolbar' checkbox at the editing prefs made the CodeEditor re-appear. No idea when or why that was disabled. I've been testing the VisualEditor, and earlier the Typography Refresh; I don't know if either switched it off. I don't ever remember doing so manually and can't think why I would.--JohnBlackburne^words_deeds 22:11, 8 June 2014 (UTC)

This does work - thanks! I feel sure I didn't turn it off in preferences either. In any case the preferences could use a specific mention of "CodeEditor" in the text to help others. Wnt (talk) 17:59, 9 June 2014 (UTC)

Actually, tonight I've been having a lot of inconsistency with the code editor. Roughly 50% of the time it doesn't work, with the same error as before. I can be on the module page and hit "Edit this page" twice and have no code editor to play with, hit it the third time and it works. I can do a preview using the talk page from a working code editor window and it won't expand "script error"; hit the button to preview again and after another run it tells me what the error is. It seems totally random. Wnt (talk) 07:13, 12 June 2014 (UTC)

The CodeEditor requires WikiEditor framework. Before we ignored the "Enhanced toolbar" setting, now we respect it. I want to improve it a bit in the future, to decouple the selection of the editors, but with the amount of time i have available right now, that's gonna take like 2 months. —TheDJ (talk • contribs) 11:57, 12 June 2014 (UTC)

Infinite loop not cut at 10 seconds ... more like 141.

I just managed to hang a module on preview, and the parser profile data said it had taken 141.129 seconds of CPU time, 140.829 seconds of real time (and it seemed like it), 136.755/10 seconds Lua time usage, 18.98/50MB memory usage, other stats look normal. Obviously this is a problem. Wnt (talk) 05:54, 12 June 2014 (UTC)

I should note that (despite thinking I'd jerry-rigged it with a backup to avoid looping) I looped it again anyway, and this time the 10 second limit held. So it's not that reproducible, at least... Wnt (talk) 06:08, 12 June 2014 (UTC)

Do you have a link to the code that caused the loop? — Mr. Stradivarius ^{♪ talk ♪} 06:15, 12 June 2014 (UTC)

I didn't save that precise preview code, but in general it was Module:Module overview with one of the while loops in (now) p._getAll never terminating. The times that the timeout worked properly (and I had four or five later on) were not because of a loop after all, just inefficient code and a lot of data. Wnt (talk) 07:10, 12 June 2014 (UTC)

"Three-column" table

What would be the code to create a three-column table, and then edit and read a cell? In other languages, I am used to something like array t1[i, j]. (A link to a good example module is welcome too). -DePiep (talk) 11:15, 11 May 2014 (UTC)

What do you mean by "three-column"? If you want to create a 3x3 grid, you can do it by nesting tables:

local grid = {
	{'a1', 'a2', 'a3'},
	{'b1', 'b2', 'b3'},
	{'c1', 'c2', 'c3'}
}

To read the "b3" value, and then write a new value to it, you would do this:

local b3 = grid[2][3]
mw.log(b3) -- gives "b3"
grid[2][3] = 'foo'
b3 = grid[2][3]
mw.log(b3) -- gives "foo"

Was that the kind of thing you had in mind? — Mr. Stradivarius ^{♪ talk ♪} 13:29, 11 May 2014 (UTC)

Yes, exactly this. Thanks. (In initiation the curly brackets are nested, and in approaching the coordinates [2][3] are linear -- that's what I could not figure). -DePiep (talk) 17:44, 11 May 2014 (UTC)

This isn't strictly the same as some of the antediluvian languages in that there's no actual allocation of a 2-dimensional array. Not merely can you say grid[2] = function(foo) return bar*foo end and still have grid[3][3] = "foo"; you can say grid[2] = grid[3], change grid[3][3] and have grid[2][3] change. Wnt (talk) 07:46, 27 May 2014 (UTC)

Thanks Wnt. As you can understand, this expansion is too complicated for my question, but it helps my thinking. I ;-) -DePiep (talk) 21:14, 12 June 2014 (UTC)

Another "I don't get this"

Can someone change code (explain by bold edit), so that Module:User:DePiep/element shows the most simple tests OK as in User:DePiep/sandbox? I can't even get the frame to be recognised. (do not explain verbose). -DePiep (talk) 23:43, 12 June 2014 (UTC)

Looking at it, I think you're trying to just get parameters at a very basic level? But missing that frame doesn't contain the parameters - they're in frame.args and frame.getParent().args for the page/template that invoked the module and whatever transcluded that page/template respectively. Worse, AFAIR the stuff coming in from frame is in a goofy mode where pairs() and # and so forth don't work on it to begin with. Wnt (talk) 23:58, 12 June 2014 (UTC)

Yes what you think is what I want (and expect). Please edit my code so that it works, as simple as possible (I'll learn). Again: don't explain verbose. (I do appreciate your contribution) -DePiep (talk) 00:11, 13 June 2014 (UTC)

I did an edit. Is that what was wanted? Johnuniq (talk) 00:32, 13 June 2014 (UTC)

Thx. Now I will learn. -DePiep (talk) 00:36, 13 June 2014 (UTC)

I've added some examples to show how metatables work on the args table too. — Mr. Stradivarius ^{♪ talk ♪} 03:43, 13 June 2014 (UTC)

Get mw.wikibase.entity object of non-current page

Is there anyway to get mw.wikibase.entity object of non-current page, like getting it from page title or mw.title object? --Nullzero (talk) 09:03, 14 June 2014 (UTC)

Not now, but it's planned. Jackmcbarn (talk) 14:31, 14 June 2014 (UTC)

It was planned last year and the year before that. If you have a site on the web and you want to scrape Wikidata's APIs, go ahead; otherwise try to forget you heard of it. Wnt (talk) 23:41, 14 June 2014 (UTC)

mw.html library nil behaviour

Tracked in Phabricator
Task T64982

There is an interesting discussion on Bugzilla now about the mw.html library. The question is, should the mw.html methods like attr, css, cssText and addClass accept nil values as input? At the moment, passing a nil value to those methods generates an error. This is because nil is not a valid css value, attribute or class. It prevents module writers from making mistakes where they may have assumed a variable always has a string or number value, whereas sometimes it is in fact nil. The counter-argument is that not accepting nil values prevents module writers from call-chaining as easily. With accepting nils, a call chain might look like this:

local root = mw.html.create('table')
root
	:tag('tr')
		:tag('td')
			:css('color', args.color)
			:wikitext('some text')
return tostring(root)

Without accepting nils, the same call-chain might look like this:

local root = mw.html.create('table')
local cell = root:tag('tr'):tag('td')
if args.color then
	cell:css('color', args.color)
end
cell:wikitext('some text')
return tostring(root)

You can see more details at bugzilla:62982. What would people prefer to do? Is the error-checking more important than the call-chaining, or is it more important that call-chaining should work without using if statements? Please leave your opinion below if you are interested. — Mr. Stradivarius ^{♪ talk ♪} 13:14, 22 April 2014 (UTC)

Surely I prefer that the library accepts nil values ​​to allow call-chaining. --Rotpunkt (talk) 13:53, 22 April 2014 (UTC)

According to my request. Hlm Z. (talk) 16:18, 22 April 2014 (UTC)

yes, allowing nil makes it much more readable. or, at the very least, have a value which can be passed which causes it to do nothing. I am currently using args.color or '' which creates an empty "color:;", which is suboptimal. Frietjes (talk) 17:02, 22 April 2014 (UTC)

If preserving the principle only is the point ("there is no tag 'nil'"), then default to: accept nil for 'blank'.

If the 'nil' value serves anything, then keep it (for example, in argument processing it could mean something).

But for sure we should not, asap, introduce another blank=/=undefined parsing. -DePiep (talk) 20:11, 30 April 2014 (UTC)

Let me add. The {{#if:{{{1|}}}|a|b}} code issue has cost me thousands of edits & puzzles & hours without being productive. (Then enter the question of {{{1}}} vs. {{{paramname}}} in subtemplates). The reversed "nil=blank & you can code otherwise" solution is better. -DePiep (talk)

Let's not get the code examples get too terrible

local root = mw.html.create('table')
local cellcolor = args.color or 'black' -- or something else, but at least the default is explicit
root
	:tag('tr')
		:tag('td')
			:css('color', cellcolor)
			:wikitext('some text')
return tostring(root)

seems reasonable to me, and fairly sound. Another option is making css(, ) a nop, at the cost of an extra local. Or even

local root = mw.html.create('table')

root
	:tag('tr')
		:tag('td')
			:css('color', args.color or 'inherit')
			:wikitext('some text')
return tostring(root)

Martijn Hoekstra (talk) 20:53, 30 April 2014 (UTC)

Our edits must have crossed.

I state: "nil=blank & you can code otherwise" (contrary to current {{#if:{{{1|}}}|a|b}}. The horror). -DePiep (talk) 21:02, 30 April 2014 (UTC).

Using args.color or 'black' isn't ideal, as you're setting an explicit style in the module that now can't be styled using user stylesheets without using "!important" overrides. Using args.color or 'inherit' is a lot better, and could be very useful - thanks for pointing it out. That doesn't help with addClass or attr, though, which don't have similar non-nil fallback values, as far as I'm aware. Conditional classes and attributes would still have to be added using if/then statements. — Mr. Stradivarius ^{♪ talk ♪} 10:32, 1 May 2014 (UTC)

All options look fairly unappealing to me to be honest. Making a function with invalid arguments a nop is terrible. Appending non-functional (and even somewhat harmful) css because the code looks better is also terrible. Isolating different elements to make if statements happy is also terrible. Other options are even insanely more terrible (patching the metatable to do smart things that are incomprehensible, or doing a conditional over the if up front and passing either the css or identity function down the code, other lovecraftian horrors). I guess it's somewhat user dependent what one considers the most and least terrible. Martijn Hoekstra (talk) 12:58, 1 May 2014 (UTC)

Actually, args.color or 'inherit' is a bad idea as well, because there's a lot of styles that don't get inherited by default. Jackmcbarn (talk) 13:16, 1 May 2014 (UTC)

Hence the 'and even somewhat harmful'. I fully concede that this too is terrible. Martijn Hoekstra (talk) 13:20, 1 May 2014 (UTC)

Another terrible idea might be to introduce methods that make explicit noop is an intentional possibility:

return tostring(mw.html.create('table')
	:tag('tr')
		:tag('td')
			:if_css('color', color)
			:if_wikitext(text)
)

--darklama 19:38, 8 May 2014 (UTC)

I very much support the proposed change. The entire purpose of HtmlBuilder was to reduce and simplify the code needed to generate HTML. Nil values were accepted as a NOP in HtmlBuilder to support the extremely common use case of a module that accepts optional arguments, and reduce the boiler-plate if clauses. The only justification for the input checking is some paternalistic view that programmers should check for valid values before passing them to a function. But the values are only invalid if they violate the contract of the function. If the contract of the function is to accept nil values as a NOP, then everything is fine. It seems to me that changing the contract now would make mw.html easier to use, would not break any currently working code, and would improve compatibility with HtmlBuilder. Toohool (talk) 04:55, 9 May 2014 (UTC)

Well said. Otherwise, why not require a check for input being unicode too? -DePiep (talk) 06:15, 9 May 2014 (UTC)

I don't thing "a check for input being unicode" means anything. Martijn Hoekstra (talk) 14:37, 9 May 2014 (UTC)

I agree values are only invalid if they violate the contract of the functions. The contracts of the mw.html functions are incompatible with the HtmlBuilder functions, which makes switching to mw.html harder then most people probably assume. If mw.html's contract is to return an error-free string then mw.html must depend on the mediawiki parser to validate tag names, attribute names, attribute values, CSS property names, CSS property values, and wikitext passed as arguments. I think nil, false, and "" should be interpreted as wanting to remove a HTML attribute or CSS property, and should silently do nothing if the HTML attribute or CSS property hasn't been set yet. My example above is meant as an alternative to satisfy any view that functions should do as the function names suggest, if that is the reason for not maintaining HtmlBuilder's contract. --darklama 14:15, 9 May 2014 (UTC)

The buzilla discussion, and the intro by mr. Stradivarius here, centers around "This is because nil is not a valid css value, attribute or class". However, that same argument is not applied to input like :tag('sapn'). For this situation, the argument "you must check your input beforehand" is not applied. -DePiep (talk) 11:52, 10 May 2014 (UTC)

Yes, the argument to check input beforehand is not being consistently applied, when applied at all that argument should be consistently applied. Another problem with the check input beforehand argument is the way the argument is being applied means checks are performed twice, once beforehand and again within each function call, which at the most optimized is still O(n*2). If checks beforehand are to be expected, mw.html should instead include validate(input, type) or individual validateType(input) functions to use before passing the input to the other functions, and let the other functions fail horribly and silently when passed invalid input. --darklama 14:46, 10 May 2014 (UTC)

There's no such complexity class as O(n*2). Twice as long as O(n) is still just O(n). There is an O(n^2), but that's definitely not what would happen in that case. Jackmcbarn (talk) 14:51, 10 May 2014 (UTC)

O(n*2) is a correct writing, and it describes the point made. And O(n) is not a complexity class. -DePiep (talk) 16:30, 10 May 2014 (UTC)

Of all terrible ideas, IMO that one is the least terrible. Kudos for finding it :) Martijn Hoekstra (talk) 16:33, 10 May 2014 (UTC)

Even if complexity was the wrong word, you still don't use coefficients in big-O notation. Jackmcbarn (talk) 17:23, 10 May 2014 (UTC)

Almost right: in this case, don't use the big O(), and keep the factor two. But the topic is something else. -DePiep (talk) 11:22, 11 May 2014 (UTC)

I believe I have an interesting solution that would allow error-checking and call-chaining at the same time. The solution is to raise an error when nil is used as a value, but not when false is used as a value. With this solution, we still have error checking (if it is not expected that a value will be nil, an error will be raised, and if it is expected, the module writer will have added or false and mw.html will not raise an error) and Mr. Stradivarius’s example becomes:

local root = mw.html.create('table')
root
	:tag('tr')
		:tag('td')
			:css('color', args.color or false)
			:wikitext('some text')
return tostring(root)

This is not ideal, but I think it is less horrible than all the other suggestions so far. ― Rastus Vernon (talk) 13:48, 18 June 2014 (UTC)

Allowing false is a bad idea, since some attribute values can be "false", and then people would be putting false instead of "false" and wondering why it's not working. Jackmcbarn (talk) 15:46, 18 June 2014 (UTC)

Fixed

My patch at gerrit:137659 just got accepted. It will be live here either on the 26th or the 3rd, depending on whether wmf10 got cut yet. Jackmcbarn (talk) 16:57, 19 June 2014 (UTC)

Lua module needed at the Tigrinya Wikipedia (TI.WIKIPEDIA.ORG)

Hi! I imported some templates to the Tigrinya Wikipedia: ti:Template:Side_box and ti:Template:Commons - But they do not work because there is no Lua module in this Wikipedia. What needs to be done? WhisperToMe (talk) 00:47, 3 July 2014 (UTC)

Just import the modules too. Jackmcbarn (talk) 00:52, 3 July 2014 (UTC)

Where may I find the modules? I use the same filename on Tigrinya Wiki, right? WhisperToMe (talk) 00:55, 3 July 2014 (UTC)

Just export and import them the exact same way as the templates. Jackmcbarn (talk) 00:57, 3 July 2014 (UTC)

Ok. What are the filenames of the modules? That way I can locate them. I don't see anything at Module:Lua WhisperToMe (talk) 01:12, 3 July 2014 (UTC)

The thing after the #invoke: is the name. For example, Template:Side box uses Module:Side box. Jackmcbarn (talk) 01:16, 3 July 2014 (UTC)

Click the Edit tab at Template:Side box and then "Templates used in this preview" at the bottom to see which other pages are used. Both templates, modules and other pages can be listed. In this case most of them are only used by the documentation page. Remove {{documentation}} from the edit box and click "Show preview" to see the much shorter list: Module:Side box, Module:Yesno. Import those. I haven't examined it but it's possible other pages are used when Template:Side box is called with certain parameters. It's also possible for a template to depend on some of the code in MediaWiki pages like MediaWiki:Common.js and MediaWiki:Common.css. PrimeHunter (talk) 01:17, 3 July 2014 (UTC)

Actually, the easiest way to see is just to click on the "Script error" message. The popup will tell you the name of the missing module. Jackmcbarn (talk) 01:18, 3 July 2014 (UTC)

I just had a look and they were still giving errors despite the module being there, but purging fixed it, e.g. [5].--JohnBlackburne^words_deeds 03:22, 3 July 2014 (UTC)

Most-used Lua modules

Special:MostLinkedTemplates is now called Special:MostTranscludedPages and has support for listing things other than templates, meaning it now lists the most highly used modules. Jackmcbarn (talk) 23:07, 30 June 2014 (UTC)

1. It's a good step forward, (though a shame another geeky camel case has slipped through).
2. However if it's only run twice a year it is of limited value.
3. There are a bunch of non-module-non-template pages in the list. I have addressed some of them, with a little luck. the rest are listed here, some are legitimate, some indicate issues:
   1. MediaWiki:Toc‏‎ (used on 64,023 pages)
   2. Talk:Devil Survivor 2: The Animation/GA1‏‎ (used on 57,490 pages)
   3. Talk:Dishaster/GA1‏‎ (used on 25,829 pages)
   4. Talk:Drakengard (series)/GA1‏‎ (used on 57,473 pages)
   5. Talk:F-Zero Climax/GA1‏‎ (used on 57,396 pages)
   6. Talk:Fez (video game)/GA1‏‎ (used on 56,802 pages)
   7. Talk:Final Fantasy X/X-2 HD Remaster/GA1‏‎ (used on 38,014 pages)
   8. Talk:Hundreds (video game)/GA1‏‎ (used on 50,758 pages)
   9. Talk:Infamous Second Son/GA1‏‎ (used on 26,724 pages)
   10. Talk:Lost Luggage (video game)/GA1‏‎ (used on 47,755 pages)
   11. Talk:Makoto Yuki (Shin Megami Tensei: Persona)/GA1‏‎ (used on 57,490 pages)
   12. Talk:Music of Final Fantasy XIV/GA1‏‎ (used on 57,492 pages)
   13. Talk:QuackShot/GA1‏‎ (used on 48,412 pages)
   14. Talk:Saints Row 2 (mobile)/GA1‏‎ (used on 56,733 pages)
   15. Talk:Silent Hill: Origins/GA1‏‎ (used on 48,819 pages)
   16. Talk:Sonic Advance 3/GA1‏‎ (used on 25,251 pages)
   17. Talk:Tony Hawk's Underground/GA1‏‎ (used on 54,901 pages)
   18. User:ClueBot NG/Warnings/FPReport‏‎ (used on 1,007,538 pages)
   19. User:ClueBot/Tracker‏‎ (used on 198,711 pages)
   20. User:COIBot/Additionlist bottom‏‎ (used on 54,819 pages)
   21. User:COIBot/Additionlist top‏‎ (used on 54,819 pages)
   22. User:COIBot/EditSummary‏‎ (used on 54,337 pages)
   23. User:COIBot/linksaverdatabases‏‎ (used on 51,164 pages)
   24. User:COIBot/OtherLinks‏‎ (used on 54,171 pages)
   25. User:COIBot/Summary/LinkReports‏‎ (used on 105,569 pages)
   26. User:JL-Bot/Project content‏‎ (used on 248,466 pages)
   27. Wikipedia:Teahouse/Invitation‏‎ (used on 41,529 pages)
   28. Wikipedia:WikiProject Film/Coordinators/Banner‏‎ (used on 137,693 pages)
   29. Wikipedia:WikiProject Food and drink/Open tasks/tasks‏‎ (used on 29,391 pages)
   30. Wikipedia:WikiProject Geography/to do‏‎ (used on 79,784 pages)
   31. Wikipedia:WikiProject Japan/ToDo‏‎ (used on 54,122 pages)
   32. Wikipedia:WikiProject Ohio/tasks/Under review/FAC‏‎ (used on 25,131 pages)
   33. Wikipedia:WikiProject Ohio/tasks/Under review/FLC‏‎ (used on 25,131 pages)
   34. Wikipedia:WikiProject Ohio/tasks/Under review/FSC‏‎ (used on 25,131 pages)
   35. Wikipedia:WikiProject Ohio/tasks/Under review/GAN‏‎ (used on 25,131 pages)
   36. Wikipedia:WikiProject Ohio/to do‏‎ (used on 25,129 pages)
   37. Wikipedia:WikiProject Olympics/to-do‏‎ (used on 94,473 pages)
   38. Wikipedia:WikiProject Tennis/to do‏‎ (used on 24,685 pages)
   39. Wikipedia:WikiProject Texas/tasks/Under review/FAC‏‎ (used on 31,013 pages)
   40. Wikipedia:WikiProject Texas/tasks/Under review/FLC‏‎ (used on 31,013 pages)
   41. Wikipedia:WikiProject Texas/tasks/Under review/FSC‏‎ (used on 31,013 pages)
   42. Wikipedia:WikiProject Texas/tasks/Under review/GAN‏‎ (used on 31,013 pages)
   43. Wikipedia:WikiProject Texas/to do‏‎ (used on 31,011 pages)

All the best: Rich Farmbrough, 19:53, 5 July 2014 (UTC).

How to round?

How to round numbers in Lua? I'm looking for the equivalent of {{#expr: 1/6 round 5 }}. Could not find hints in the math library . -DePiep (talk) 10:38, 2 July 2014 (UTC)

@DePiep: use Module:Math#round. — Mr. Stradivarius ^{♪ talk ♪} 10:49, 2 July 2014 (UTC)

That obvious. :-) -DePiep (talk) 11:03, 2 July 2014 (UTC)

Because of the potential for pages needing to be reparsed when a basic module is fixed, I'd avoid doing a require for Module:Math unless you want to do something non-trivial. For rounding you can use math.floor(n-1/2) or something. Wnt (talk) 19:04, 7 July 2014 (UTC)

There will probably soon be an mw.math.round function available, which will address Wnt's concern. Jackmcbarn (talk) 19:50, 7 July 2014 (UTC)

Nice! Though I wonder... You have:

function p.round( n, decimals )

local multiplier = decimals ~= nil and 10^decimals or 1

return math.floor( n * multiplier + 0.5 ) / multiplier

end

I'm thinking that every time you do an ordinary humdrum round to integer, you check decimals ~= nil, set multiplier to false, or with 1, set multiplier to 1, take n * 1, take the integer / 1. Because someone might round tens of thousands of times in a module, I think I'd prefer:

function p.round( n, decimals )

if decimals then

local multiplier = 10^decimals -- still need this to avoid expensive exponentiation twice

return math.floor( n * multiplier + 0.5) / multiplier

else

return math.floor( n + 0.5)

end

But I'll admit, I don't know if it matters really, and this does use more lines of code. A chipmunk at the back of my brain is wondering, what if we calculated the decimals by creating an appropriate string with string.rep and doing a tonumber() on it :) Wnt (talk) 20:58, 7 July 2014 (UTC)

I'm guessing that the performance difference probably isn't all that great, and that it's better to write the code for maintainability. But why don't you run some tests on it? You can test it in the debug console with some code like this:

local start = os.clock()
for i = 1, 1000000 do
    -- test code goes here
end
= os.clock() - start

I'd be interested to see your findings. :) — Mr. Stradivarius ^{♪ talk ♪} 23:26, 7 July 2014 (UTC)

I didn't use the debug module - out of 8 runs on page preview, plus a few initial attempts, the Lua script-based editor came up only twice; the rest of the time I could have had javascript disabled for the same effect, due to the usual error. But on preview, your version came up as 0.37, 0.23, 0.23, 0.37, and mine came up as 0.19, 0.19, 0.15, 0.26. Then I tried running both in the same script as an "internal control" but it was still all over the place: the ratio of mine/yours was 0.78 0.91 1.30, 0.84. Saved this as [6] Meanwhile, I don't actually know if the severely restricted Lua for running scripts has anything to do with the Lua used internally by the server. Getting this data may be a bit frustrating. :) Wnt (talk) 00:17, 8 July 2014 (UTC)

The time difference between different runs depends on a few things, chiefly the server that your request gets sent to, and how busy it is. So you need to average things out to get meaningful results. But if the code is running at that speed, there shouldn't be a problem. Your fastest result was running at 6.7 million a second, and the slowest at 2.7 million a second, so the speed difference will only be noticeable for people making millions of calls to the round function. I can't see many modules needing to do that. — Mr. Stradivarius ^{♪ talk ♪} 04:47, 8 July 2014 (UTC)

Random question: Why are there no redirects in the Module: namespace?

As my section header states, random question: Why are there not any redirects in the Module namespace, and why can they not be created? Steel1943 (talk) 22:51, 23 June 2014 (UTC)

@Steel1943: Modules aren't wikitext, and #REDIRECT is a wikitext construct. Jackmcbarn (talk) 22:54, 23 June 2014 (UTC)

A counter question: why would they be needed? Modules are not like pages which can be linked by anyone and everyone, or templates that can be transcluded in a multitude of articles. Modules typically are invoked in only a handful, often only one, template. These can be easily updated as a module changes location. Which should happen rarely anyway: as modules don't get invoked in articles there's no need for them to have editor-freiendly names which might need updating from time to time or might need redirects creating for common abbreviations.--JohnBlackburne^words_deeds 00:12, 24 June 2014 (UTC)

You never know when someone may want to rename a module (yay for Module:Rfd, my failed experiment)... Either way, I'm thinking this needs to be added to Wikipedia:Lua for those who don't know ... Steel1943 (talk) 02:52, 24 June 2014 (UTC)

I presume return require('Module:NewModuleName') should do the trick? isaacl (talk) 08:44, 24 June 2014 (UTC)

Is it possible to add a warning in move page for module namespace? At Mediawiki:movepage-summary or Mediawiki:movepagetext-noredirectfixer. A module should not be renamed if there is any require from other modules or invoke from templates. --Vriullop (talk) 09:18, 24 June 2014 (UTC)

Modules are often protected to prevent careless edits which also prevents careless moves. If it's needed I'd suggest just move protecting the lot of them: they don't need to be moved and it will break stuff so make it so it requires an admin and an edit request. But I don't think it's needed; I don't think there's a problem with moves which needs addressing.--JohnBlackburne^words_deeds 11:46, 24 June 2014 (UTC)

I don't think any special protection for moves would make sense. Unlike editing an article, any small change in a module can completely screw it up, so there's nothing intrinsically more serious about a minor edit than a move. Either the editor is being careful, or not. Wnt (talk) 01:18, 27 June 2014 (UTC)

I think we should ask for the faeture. Lots of the module names are in camel case, and should IMHO be moved. Christian75 (talk) 11:47, 27 June 2014 (UTC)

First of all, what's wrong with camel case names? Second, assuming there is consensus to move, just move them and fix the templates that call them. Jackmcbarn (talk) 15:25, 27 June 2014 (UTC)

All the templates has been renamed so they arent camel case any more, so why should module names be named that way? Do you have an easy way to detect which pages (templates/user pages/and so on) who #invoke a given module? Christian75 (talk) 22:44, 28 June 2014 (UTC)

If you don't believe modules should be named with camel case, I'm unclear what the reason would be to leave behind a redirect from the camel case name when moving the module to a new name, since the redirect would allow the camel case name to continue to be used. In any case, the syntax I specified above should do the job, I believe. isaacl (talk) 04:26, 29 June 2014 (UTC)

Which ones and what problems do they cause? All I can think of inherited the name or a name based on the template(s) they implemented. If other names have been chosen I'm sure they too made sense for that module: modules only called by other modules and so that aren't based on templates for example.--JohnBlackburne^words_deeds 22:54, 28 June 2014 (UTC)

Quick how-to for moving modules or functions: 1) copy it to new location, 2) replace each moved function with return require('Module:NewModuleName').newFunction(selfArgs) and, if possible, with a tracking categoy, 3) replace all invoke or require from old name to new one, 4) delete old functions or module. In the long term it is not a rare stuff. I think it makes nonsense a wiki page redirect in modules, but it makes nonsense either to advise fixing double redirects. It would be better to advise moving modules to inadverted users, specially in smaller comunities with less experimented users and modules not always protected. --Vriullop (talk) 09:50, 29 June 2014 (UTC)

re Jackmcbarn. "Move" is a basic WP feature, "Redirect" a basic support solution. But you keep pinpointing to isolated half-answers as "why would they be needed?" (yeah, sure, can someone answer: why would a redirect be needed?). Today I was looking for (preparing) a move, and I did not find primary answers. So instead of making the whole module namespace an exception in a talkpage section, we better make it a normal ns as any other (with its exceptions described, as with any other ns). Check these for ns "Module": WP:MOVE, WP:REDIRECT, WP:DELETE. -DePiep (talk) 21:01, 6 July 2014 (UTC)

Initiated #Guidelines_for_ns:Module_exceptions below. -DePiep (talk) 21:16, 6 July 2014 (UTC)

I've submitted gerrit:146608 which will add redirect support to the Module namespace. Jackmcbarn (talk) 21:21, 15 July 2014 (UTC)

Guidelines for ns:Module exceptions

At the moment, there are no WP:guidelines that specify Module namespace ("ns:Module") exceptions. This is also true for the wider policy, processes, templates, [[WP:..]], [[HELP:...]], XfD and what you have for an ns. As far a ns:M is a regular ns, in whatever situation, that's fine. But when ns:M needs an exception, there is no support. (For example: how to put a module page up for speedy, or ModForD? How to handle redirect-after-move?). We need ns:Module to be incorporated in WP:... full weight. (Suggestion: for ns:M we can check: WP:MOVE, WP:DELETE, WP:ModForD, WP:SPEEDY). -DePiep (talk) 21:14, 6 July 2014 (UTC)

@DePiep: Easier said than done. Do you have ideas for how to do any of those things? Jackmcbarn (talk) 21:31, 6 July 2014 (UTC)

No, I don't have a how. Never wrote a WP:guideline or WP:ns definition ever. Now, do you agree we need them? (From there, there must be a wiki way). -DePiep (talk) 21:38, 6 July 2014 (UTC)

You can't do those things just by writing a guideline. Support for them needs to be added in code. I agree they'd be nice to have, but we don't need them, any more than we need any of them for user CSS/JS, which is broken in just about all of the same ways. Jackmcbarn (talk) 21:42, 6 July 2014 (UTC)

I disagree. Yes we need them. How else could an editor find or know how to ModForD/Speedy/Move/.. a module page? Exacty today I did not find the process to follow for such a primary action that has ns:M exceptions. -DePiep (talk) 22:01, 6 July 2014 (UTC)

If you want to delete a module use Wikipedia:Miscellany for deletion (WP:MFD). Christian75 (talk) 15:02, 7 July 2014 (UTC)