Wikipedia talk:Lua

Archives (Index)

1 2 3 4 5 6 7 8 9 10 11 12

This page is archived by ClueBot III.

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)

"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)

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)

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)

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)

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 [1] 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)

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. [2].--JohnBlackburne^words_deeds 03:22, 3 July 2014 (UTC)

User preferences language

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

The outputs of pages using Lua are cached between users, so there's no way something like that could ever work. Jackmcbarn (talk) 15:42, 13 July 2014 (UTC)

Thanks a lot. I know this is now off-topic, but is there anyway to get the output of a template to vary based on that user language preference? --Atethnekos (Discussion, Contributions) 17:08, 13 July 2014 (UTC)

No, and we'll likely never have one because the cache fragmentation would kill performance. Jackmcbarn (talk) 17:40, 13 July 2014 (UTC)

@Atethnekos: Also, can you tag Template:Lv and Module:Lv for speedy deletion-G7 if that kills plans for further changes to them? As they stand now, they're redundant to the {{CONTENTLANGUAGE}} magic word. Jackmcbarn (talk) 17:52, 13 July 2014 (UTC)

Yeah, I shall, I was just trying to build something, but since you're saying it's impossible I'll get rid of them. --Atethnekos (Discussion, Contributions) 17:54, 13 July 2014 (UTC)

commons:Module:Fallback gets the user language, but based on preprocess( "{{int:lang}}" ) with Mediawiki pages created for this purpose: commons:Special:PrefixIndex/MediaWiki:Lang/. --Vriullop (talk) 09:49, 14 July 2014 (UTC)

Wow. I understand Commons is eager to be multilingual, but this is ... risky. The preferences are supposed to be completely private, and this puts a little hole in that line. I see that here ⧼lang⧽ is producing "<lang>", but on Commons it can produce en, es, de etc. And where it gets interesting is how that works with the cache. So I tried on my talk page and found that when I set preferences to es and view es, I get a CURRENTTIMESTAMP for the first time that doesn't change thereafter (it's cached). If I log out and view the page in default English, I get en and another timestamp. If I log in and switch back to English, I get the _same_ timestamp, i.e. I now can know when the first en-reader viewed my talk page after I edited it. If I switch to de and view I get yet another timestamp, which then remains stable. So if we have a stable page on Commons, someone can see which language user preferences first viewed it when, which admittedly is interesting but not directly abusable. But... there's more.

Suppose Wikipedia enables this, and I want to hold an RFC on how Crimea is colored on a map. I wrap my RFC announcement in some template that I arrange to run Lua code to get the frame:preprocess of the language code. If the user language code is ru ... it doesn't display. Except maybe until after a certain amount of time passes (there are other ways to disable caching to ensure this would be checked). That way I could start an RFC and systematically skew the vote against Russian speakers, and by the time people got suspicious about it they'd see the page, people might well say 'replag' and move on if it were concealed with a good enough cover.

Bottom line is that Wikipedia should _not_ blur this boundary. There has to be some other way. Wnt (talk) 19:02, 14 July 2014 (UTC)

For reference, you don't need int: to see the timestamp thing. You can do the same thing on any page that has a table of contents. (ToC currently causes cache fragmentation based on user language). You don't even need {{CURRENTTIMESTAMP}} on the page to see if someone viewed it in that language, since render timestamp is included in an html comment on all pages. Bawolff (talk) 23:07, 14 July 2014 (UTC)

It forces multiple caches even for pages that don't use internationalization? I'd have thought there would be a way to avoid that... Wnt (talk) 01:57, 15 July 2014 (UTC)

Its so that mediawiki:toc is translated into user language. Arguably I consider this a bug, and it should be done in a post processing step to avoid cache fragmentation (like we do with section links and <mw:editsection ...>). But thus far nobody has done that yet. Probably many people find it scary to poke that deep into the bowels of the parser. Bawolff (talk) 02:07, 17 July 2014 (UTC)

Heh, I haven't looked into it and I already see how this might be "interesting". The page you linked is deleted. It also contains contents (namely, "Contents"), despite having no revision history. Wnt (talk) 12:19, 17 July 2014 (UTC)

@Wnt: The MediaWiki namespace is weird. If no revisions exist, but the message is a default MediaWiki message (both of which are true in this case), then the page is still considered to exist and has contents. Jackmcbarn (talk) 15:14, 17 July 2014 (UTC)

Please please please don't use {{int:}}. It's just a bad hack. Legoktm (talk) 22:45, 14 July 2014 (UTC)

I'm curious as to the reason that knowing user language would be useful here, actually. Jackmcbarn (talk) 23:16, 14 July 2014 (UTC)

Module:Fake object

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

@Mr. Stradivarius: What does that module let you do that rawset doesn't? Jackmcbarn (talk) 03:01, 17 July 2014 (UTC)

Now that's a good question. I can't think of anything - it looks like I just wrote that module for nothing. And if you use rawset, methods using a check self function still work. Well, it was good practice at writing metamethods, at least... — Mr. Stradivarius ^{♪ talk ♪} 03:08, 17 July 2014 (UTC)

I've gone ahead and deleted the module, as rawset seems to be generally superior. — Mr. Stradivarius ^{♪ talk ♪} 23:40, 18 July 2014 (UTC)

mw.log output is now visible

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

That's very useful, thanks. Johnuniq (talk) 01:34, 18 July 2014 (UTC)

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

mw.math library error checking

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

I haven't looked at this nearly hard enough to settle anything, but just thinking out loud: I see there's a suggestion to require at least one argument, but the unit tests list ideas like sum() = 0, product() = 1. I think there's some merit to having convenient behavior for the empty set, especially if it can be passed in as a table. Question: is there going to be a conflict if you're using custom numbers (tables with metatables) and you also accept that a table as the first argument indicates that the fields of the table are the arguments? I'm thinking that you could differentiate between the two if you check whether a metatable exists in that case, but it seems a bit odd. Wnt (talk) 11:58, 19 July 2014 (UTC)

Indeed, that is an issue. As the code is written now, the solution is that if you use tables-with-metatables-as-numbers, then you have to use the table form of the function call as well. Jackmcbarn (talk) 14:50, 19 July 2014 (UTC)

Hmmmm... personally I'm not a great fan of almost-but-not-quite synonyms. If there's not a way to make a(x,y,z) precisely equal to a{x,y,z}, would it be better just to have the second way? Wnt (talk) 20:43, 19 July 2014 (UTC)

That was my original idea. Jackmcbarn (talk) 02:14, 20 July 2014 (UTC)

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

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

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

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

Let's get rid of the Lua/todo page

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

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

I suppose as its creator I would say this, but I think it has a useful role to play in identifying templates that need to be converted. I admit that it hasn't had a very high level of activity, but that doesn't mean that it isn't serving its purpose. I've removed a couple of stale entries, but the others are all tasks that still need doing. — Mr. Stradivarius ^{♪ talk ♪} 03:04, 23 July 2014 (UTC)

After WT:Lua and WP:Lua/Request this is a third (fourth, ...) coordiantion place. That means sooner of later, but surely, information & communications will be lost. A Todo list could be in top of the Lua talkpage? -DePiep (talk) 19:42, 16 August 2014 (UTC)

How to use template parameter names as Lua variables.

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

Yes, that's easy.

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

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

Wow, I successed as you said, thanks for your help!--JamesQQ5 (talk) 16:08, 7 August 2014 (UTC)

Detect call context

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

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

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

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

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

Neolexx: I think for some of these things you can just use : local parent = frame:getParent(frame)

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

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

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

You currently can't get the grandparent. Jackmcbarn (talk) 23:12, 21 August 2014 (UTC)

Is there any other way to get the page that's using the template which is invoking a module? I can think of a lot of uses for this, such as allowing the template to automagically add some customization based on the page, without the need to tediously add a new argument on every single page that already uses the template. BigGreenCahuna (talk) 23:20, 21 August 2014 (UTC)

You can get the "root" page with mw.title.getCurrentTitle(), but if you have A -> Template:B -> Template:C -> Template:D -> Module:E, you'll get A. There's no way to get Template:B or Template:C. Jackmcbarn (talk) 23:51, 21 August 2014 (UTC)

• Thank you all for answering, and it may indeed help to explain my reasons. It is helpful(?) to keep an OP-like paradigm with small modules to do one exact task each but doing it right - rather than having all-in-one. And then depending on the task to collect needed sets by require() chains. The problem is that even small fully internal (by its purpose) module might be seem useful for someone's purpose as it is: straight from the page or from its own template. And things gets sometimes populated very quickly on wiki. So a month later one adjusts that module and suddently crashes thousands of pages around (s)he had no idea about. There are real cases I would like to not enumerate right now.

So instead of different spooky DON'T USE DIRECTLY or ONLY WITHIN... on the module page I was thinking of some more programmatical way of doing things. Like in Javascript we don't write PLEASE DO NOT CALL THIS CONSTRUCTOR AS A FUNCTION, there is this for this. Similarly I was thinking to distinguish a correct call context (from a given template or from a given parent module) from an incorrect one (straight from the page or as a stay-alone module). --NeoLexx (talk) 09:54, 22 August 2014 (UTC)

Doing that would be a bad idea. If you only want code to get called from one particular module, put the code in that module as a local function. Don't put it elsewhere and then try to detect what the caller is. Don't let "good" OOP trick you into writing bad code. Jackmcbarn (talk) 15:27, 22 August 2014 (UTC)

We may have very different ideas about "good" and good programming patterns. But I do respect your opinion and thank you for answering. --NeoLexx (talk) 09:00, 23 August 2014 (UTC)

Although it won't prevent someone from using your helper modules if they choose to ignore your documentation, you can make them subpages of your main module. This way you can document your main module as providing the external interface to templates or other modules, and all subpages below being conceptually private. isaacl (talk) 22:16, 1 September 2014 (UTC)

HtmlBuilder

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

Bug in mw.language.fetchLanguageName()?

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

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

{{cite book/new |title=Norwegian |language=no}}

Norwegian (in Norwegian). – see code no

ISO639-1 code km should produce Central Khmer

{{cite book/new |title=Central Khmer |language=km}}

Central Khmer (in Khmer). – see code km

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

{{cite book/new |title=Tonga (Tonga Island) |language=to}}

Tonga (Tonga Island) (in Tongan). – see code to

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

How to get this fixed?

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

@Trappist the monk: To clarify, exactly what parameters are you passing to mw.language.fetchLanguageName()? Are you passing 'no' as the first one and omitting the second one? Also, exactly what output do you expect, and what output do you get? Jackmcbarn (talk) 00:08, 2 September 2014 (UTC)

local name = mw.language.fetchLanguageName( Language:lower(), "en" );

where Language is the value assigned to CS1 parameter |language=. So, in this case |language=no

When the citation is rendered, it should contain (in Norwegian).

Norwegian (in Norwegian). – current live (correct) version of the CS1 module using the table in Module:Citation/CS1/Configuration

Norwegian (in Norwegian). – sandbox (wrong) version of CS1 using mw.language.fetchLanguageName()

Norwegian (in Norwegian Bokmål). – sandbox with code nb produces correct response

I think that I expect each of the two-character ISO639-1 codes to produce the preferred (first listed?) language name according to the Library of Congress.

Related? {{#language:no|en}} produces Norwegian which is the same wrong language name produced in the Norwegian language test above, and {{#language:km|en}} produces Khmer and {{#language:to|en}} produces Tongan, also both wrong according to LOC. More evidence that these issues are related: {{#language:nb|en}} produces Norwegian Bokmål which is correct and the same as the mw.language.fetchLanguageName() result above.

Have I answered your questions?

—Trappist the monk (talk) 00:56, 2 September 2014 (UTC)

@Trappist the monk: Almost. You're saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål). Do you want it to produce Norwegian or Norwegian Bokmål? Jackmcbarn (talk) 01:03, 2 September 2014 (UTC)

Yes, I am saying that mw.language.fetchLanguageName( 'no', 'en' ) produces Norwegian (bokmål) and I am saying that it is the wrong language name for code no. The correct language name and the one that I'm looking for is Norwegian because that is the language name associated with no in the list of codes at the Library of Congress website.

I am most concerned with no because it is most clearly wrong but it would be nice, barring any reasons unknown to me, if we could make sure that for all of the ISO639-1 two-character codes, mw.language.fetchLanguageName() (and {{#language:}} for that matter) returns the preferred name.

More clear?

—Trappist the monk (talk) 01:25, 2 September 2014 (UTC)

@Trappist the monk: I've figured it out. mw:Extension:CLDR has a specific override in place for that language, which you can see at [3]. It was added by Siebrand in mw:Special:Code/MediaWiki/31280. Jackmcbarn (talk) 01:37, 2 September 2014 (UTC)

Thanks for that. I'll drop a line to Siebrand.

—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)

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

List of Wikipedias doesn't use mw.language.fetchLanguageName() or {{#language:}}. There are three Norwegian language ISO639-1 codes: no, nb, and nn. no is the 'non-specific' or generic code that includes both nb and nn. mw.language.fetchLanguageName() produces correct results when nb and nn are specified:

Norwegian Bokmål (in Norwegian Bokmål).

Norwegian Nynorsk (in Norwegian Nynorsk).

—Trappist the monk (talk) 10:05, 2 September 2014 (UTC)

Sure, but the point I was making is that for whatever reason, "Norwegian (Bokmål)" is associated with "no" in more places than mw.language. Another example is Wikidata which uses nowiki as can be seen at d:Q14033926. Johnuniq (talk) 10:53, 2 September 2014 (UTC)

Understood. I don't know how that wikidata page got its language name but its form (norsk bokmål) is different from either {{#language:no|en}} → Norwegian or {{#language:nb|en}} → Norwegian Bokmål which implies that it was not taken from mw:Extension:CLDR.

—Trappist the monk (talk) 11:37, 2 September 2014 (UTC)

@Trappist the monk: That would be from {{#language:no}} (or the basically-equivalent {{#language:no|no}}), which yields norsk. Wikidata displays languages in themselves. Jackmcbarn (talk) 12:39, 2 September 2014 (UTC)

It occurred to me to wonder in my message to Siebrand how no, nb, and nn are handled when Dutch (nl) is the specified output language:

• {{#language:no|nl}} → Noors
• {{#language:nb|nl}} → Noors - Bokmål
• {{#language:nn|nl}} → Noors - Nynorsk

You can see that we get the correct results. It's the same if you do the experiment specifying other common language codes for the output language, for example de, es, fr, it, ru, and even yi all produce output equivalent to Norwegian, Norwegian Bokmål and Norwegian Nynorsk. This is the limit of my current experimentation but it seems that output for no with output language specified as code en and code no are wrong, or at the least completely inconsistent with output for other output language specifiers.

—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)

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

From this:

language codes: "...(mostly in accordance with ISO 639-3, except two-letter codes from ISO 639-1 for "established" locales)..."

can I infer that the two-letter language code no should be in compliance with ISO639-1? See code no.

RFC 5646, interestingly enough, specifically mentions no, nb, and nn as Norwegian, Norwegian Bokmal, and Norwegian Nynorsk respectively. From IANA language subtag registry (oft mentioned in RFC 5646) this for code no:

%%

Type: language

Subtag: no

Description: Norwegian

Added: 2005-10-16

Suppress-Script: Latn

Scope: macrolanguage

%%

All of this suggests to me that mw.language.fetchLanguageName() and {{#language:}} should not be returning Norwegian (Bokmål), Norwegian Bokmål, or norsk bokmål when the input is specified as code no regardless of output language code.

Am I missing something?

—Trappist the monk (talk) 14:41, 2 September 2014 (UTC)

Hmm. I see someone added "except two-letter codes from ISO 639-1 for 'established' locales" since last I read through that, which totally changes the meaning of the sentence. At any rate, the issue here is that the English name for MediaWiki language code "no" is currently "Norwegian (bokmål)", and if that should be changed to match ISO 639-1 then it needs to be changed in mw:Extension:CLDR. Anomie⚔ 23:20, 2 September 2014 (UTC)

Right. So how do we get that done?

—Trappist the monk (talk) 10:50, 3 September 2014 (UTC)

Well, you said you already tried talking to Siebrand. Next step would be to file a bug, and even submit a patch if you can. Anomie⚔ 12:56, 3 September 2014 (UTC)

Function names containing equals signs

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

Proposal to disable "Allow saving code with script errors"

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