Wikipedia:Lua/Requests/Archive 4

(ec) Parser functions strips whitespace (so do template parameters for that fact). The only thing I am interested in is the first character being [*#;:]. — Edokter (talk) — 22:54, 10 March 2014 (UTC)

Only named parameters strip outer spaces (and the whitespace tabs): "#Parser keeps lead spaces in unnamed parameters". -Wikid77 17:51, 11 March 2014 (UTC)

Here's my effort:

local function isList(s)
	-- Returns true if s starts with the characters "*", "#", ";" or ":".
	-- Otherwise returns false. Will produce an error if s is not a string.
	if s:find('^[*#:;]') then
		return true
	else
		return false
	end
end

That's all you need to detect strings starting with [*#;:]. — Mr. Stradivarius ^{♪ talk ♪} 23:28, 10 March 2014 (UTC)

And thinking about it, you could do that in even less code:

local function isList(s)
	-- Returns true if s starts with the characters "*", "#", ";" or ":".
	-- Otherwise returns false. Will produce an error if s is not a string.
	return s:find('^[*#:;]') ~= nil
end

Not sure if there's any merit in doing that over the one above, though. — Mr. Stradivarius ^{♪ talk ♪} 23:34, 10 March 2014 (UTC)

Nice and short. What happens if an error is raised? — Edokter (talk) — 23:38, 10 March 2014 (UTC)

If an error is raised when running from #invoke, you get the lovely big red "script error" message. :) To avoid that, you have three basic options. The first is to make sure that you will only pass strings to the function. This is actually not so hard, as argument values passed from #invoke are always strings. (Argument keys can be numbers, however.) The second is to check the type of s before doing the matching. You can make it return nil if s is not a string, and true or false otherwise. That works like this:

local function isList(s)
	-- Returns true if s starts with the characters "*", "#", ";" or ":".
	-- Otherwise returns false. Will return nil if s is not a string.
	if type(s) ~= 'string' then
		return nil
	end
	return s:find('^[*#:;]') ~= nil
end

Or this:

local function isList(s)
	-- Returns true if s starts with the characters "*", "#", ";" or ":".
	-- Otherwise returns false. Will return nil if s is not a string.
	if type(s) == 'string' then
		return s:find('^[*#:;]') ~= nil
	else
		return nil
	end	
end

In a similar vein, you can also convert s to a string before matching it, by using s = tostring(s). But type checking is more elegant. The third is to try and catch the error by using pcall - although I think just checking the type of s is neater. — Mr. Stradivarius ^{♪ talk ♪} 23:59, 10 March 2014 (UTC)

about "neatness": it is very common (and neat, if you ask me) in lua to use boolean shortcut for this purpose exactly: so instead of if..then..else..end, one can simply write

return type(s) == 'string' and s:find('^[*#:;]')

this will return either false (not a string), 'nil' (not a list) or the first character. usually this is good enough, but if you prefer "true" rather than the found character, use

return type(s) == 'string' and s:find('^[*#:;]') and true

this pattern is very common in lua, it makes the code shorter and more concise, and getting familiar with it is helpful. i use it all the time - maybe sometimes to a fault... peace - קיפודנחש (aka kipod) (talk) 23:23, 11 March 2014 (UTC)

Parser keeps lead spaces in unnamed parameters

Note how the unnamed parameters retain any leading spaces/tabs, when invoking a Lua function:

f1. {#invoke:String|find|*bullet|target=^[*#:;]|plain=false}} = 1

f2. {#invoke:String|find|   *bullet|target=^[*#:;]|plain=false}} = 0

f3. {#invoke:String|find|source=   *bullet|target=^[*#:;]|plain=false}} = 1

f4. {#invoke:String|find|   *bullet|target=^%s*[*#:;]|plain=false}} = 1

In case f2, the find() is unable to match with the lead-spaces and gives result "0" as a no-match, but in case f3, with the named parameter ("source="), the parser has omitted the outer spaces/tabs. To handle extra spaces/tabs, before a list-item, the

This is the Lua pattern documentation: mw:Extension:Scribunto/Lua_reference_manual#Introduction, and [3]. Is there a pattern documentation that does not say "like the regex we all know, except ..."? I need a 101 documentation, so in chapters 1 to 4 the word "greedy" does not appear. If such a documentation exists for regex, that would be great too. -DePiep (talk) 14:50, 7 March 2014 (UTC)

Start with article "Regex" and remember percent '%' for literals: Because there are so many features, it would be best to tell people to read page "

square brackets

in a string, each bracket must be escaped as '%[' and '%]' because regex brackets specify a single-character set. Compare examples:

• 1. {#invoke:String |find|source= aabbcc |target= [.*] |plain=false}} = 0
• 2. {#invoke:String |find|source= a[ab]bcc |target= \[.*\] |plain=false}} = 0
• 3. {#invoke:String |find|source= a[ab]bcc |target= %[.*%] |plain=false}} = 2
• 4. {#invoke:String |find|source= aab[bc]c |target= %[.*%] |plain=false}} = 4

Note how the brackets only matched (in lines 3 & 4) once they were escaped as Lua '%[' and '%]' and that is bizarre, compared to the typical POSIX backslash format, as '\[' and '\]'. Page "

implicit declaration" of misspelled variable names, as likely to cause horrific bizarre results. -Wikid77 (talk

) 05:36, 9 March 2014 (UTC)

@DePiep: Try the lua-users wiki. If that's hard to understand, post back here with whatever you're having trouble with, and someone should be able to help you out. Good luck. :) — Mr. Stradivarius ^{♪ talk ♪} 08:06, 9 March 2014 (UTC)

Also, for regex, I found regular-expressions.info useful. — Mr. Stradivarius ^{♪ talk ♪} 21:44, 9 March 2014 (UTC)

Thanks. I've added the links to the Lua resources page. -DePiep (talk) 16:50, 10 March 2014 (UTC)

I don't understand the complaint about greedy pattern matching. If I do {{#invoke:LuaCall|main|x=abaabaaab|y=b(.*)b|string.match(x,y)}} -> aabaaa, sure, that's greedy. But I can do {{#invoke:LuaCall|main|x=abaabaaab|y=b(.-)b|string.match(x,y)}} -> aa just as easily. And the greediness still uses a left to right search; it just doesn't stop until it has to. But it is annoying that the Lua format doesn't accept a number of the Javascript options, so that it's not easily possible to reuse Javascript patterns here. Wnt (talk) 03:21, 13 March 2014 (UTC)

I tried redigesting the Scribunto manual at [4] - I'm not sure I made anything clearer or in any way better though. Wnt (talk) 03:04, 14 March 2014 (UTC)

I'm going to reiterate Module talk:LuaCall#I sincerely hope that no one ever actually uses this: I really don't think using that is something we should encourage use of. Anomie⚔ 10:31, 14 March 2014 (UTC)

I don't understand the criticism. First, to be honest, I don't understand what load(func, chunk) is actually used for. And certainly I don't see any comparison to obfuscated C. What I know is that I find myself making use of this fairly often - most commonly for a string.len measurement of a DYK-related item. I assume it would be legitimate to write a dedicated module for purposes like this, but why bother having a separate module for each one? To be clear, I do understand that going back to LuaCall repeatedly within a single template would quickly become inefficient. Wnt (talk) 14:24, 14 March 2014 (UTC)

Wnt, I guess you refer to my complaint about greedy. I meant to say that, when starting Lua patterns (or Regex for that matter), explaining "greedy" should not be the first topic. And so, a little hyperbolic, it should be "not in chapter 1 to 4". That is because when I want to learn Patterns from scratch, that is not the essence. To illustrate this with the demo you gave yourself: I first need to know what the meaningful symbols are you use (that is *().). Now please don't explain them to me here, it's just to show that I need to learn that first. -DePiep (talk) 14:41, 14 March 2014 (UTC)

Wnt, sounds like you're looking for Module:String#len? — Mr. Stradivarius ^{♪ talk ♪} 15:24, 14 March 2014 (UTC)

You're right, that is useful in this case. But I still don't see any reason why that is good but LuaCall is bad. Wnt (talk) 19:56, 14 March 2014 (UTC)

this template is apparently very expensive, mainly due to excessive use of parser functions, i think. (some of the pages and templates using it clock at 15 and 20 seconds for parsing(

it's also super complicated. i do not suggest, necessarily, to replace it with something that would use the exact same syntax, though this may not be so bad also.

my suggestion/request is more about thinking, finding and defining better syntax to this functionality, that would make it easier for the editors to create those charts. ideally, the editor would use some "language" to define the relationship between the nodes, without having to worry about the precise layout of the boxes and lines.

unfortunately, i can't think of such syntax myself.

looking at the template's source code, it's clear that this is an unmanageable nightmare - prime candidate for scribunto, IMO.

peace - קיפודנחש (aka kipod) (talk) 20:11, 23 March 2014 (UTC)

How about this:

{{autochart
|node1 = fred
|node2 = jane
|node3 = joe
|fred-text = [[Fred Bloggs]]
|jane-text = [[Jane Bloggs]]
|joe-text = [[Joe Bloggs]]
|fred-sister = jane
|fred-child = joe
|jane-child = joe
|fred-jane-line = dashed
}}

That would produce something like:

That would require a lot more processing in the module than the current system. It would also have to deal with multiple ways of specifying the same information, e.g. fred-jane-line and jane-fred-line would refer to the same thing. It would also have to detect conflicting data, and probably throw errors for it, e.g. fred-jane-line = solid and jane-fred-line = dashed. Or another example: fred-child = joe, fred-sister = jane and joe-child = jane. And probably the hardest part would be working out where to draw the lines, as there are a lot of different possibilities. Thoughts? — Mr. Stradivarius ^{♪ talk ♪} 00:46, 24 March 2014 (UTC)

not sure. it makes sense, but i think there are a few things supported by current template that may not be possible (it's hard to say, b/c currently the editors have to create the line-art: much more tedious, but also much more freedom).

also, i think we can get away from limiting ourselves to template syntax (name=value, separated by | ): sometimes you want more elaborated tupples, and the fact that the module can examine the values programatically, allows us do this.

not to claim that what i did is perfect or even good, but look at the syntax i created in module:chart for the slices in a pie chart: you can use a single parameter, namely "slices", enclose each slice in parenthesis, and define some mandatory and some optional fields. i am not sure this is necessarily better, but it might be: for instance, in your example, there are multiple parameters pertaining to fred:

|node1 = fred
|fred-text = [[Fred Bloggs]]
|fred-sister = jane
|fred-child = joe
|fred-jane-line = dashed

maybe we can have a syntax where all the information about a specific node is in a single argument:

( name=Fred : val=Fred blogs : siblings=Jane{solid}; Zoe{dashed} : descendants-Jane=Joe; Jill : descendants-Zoe = Heironimus; Nefertiti )

this is not a full example, nor a correct one, it's just an illustration to the idea that each node can be fully defined in one place instead of many. i think this would be good, but others may disagree.

BTW - it may be better not to list the "child" nodes as part of the parent info, and instead list the parents nodes as part of the child info, b/c, as far as i saw, a "child" has at most 2 parents with "Chart" or "Family tree", but a parent can have many children. so a node will look like so:

(name=Node name : content=Node content : parents=parent1; parent2; line type : siblings=sibling1 (line type); sibling2.... : maybe some more stuff)

this way, the actual tree may look like so:

{{autochart
| some generic option = some value
...
| nodes =
( Node 1 info as above )
( Node 2 )
( Node 3 )
...
}}

"generic" here means "option that affects the whole chart".

my point is that if all the information about a specific node is in one place, it makes life easier to the editors, i believe. peace - קיפודנחש (aka kipod) (talk) 02:22, 24 March 2014 (UTC)

At nl-wiki we do not have much Lua users active, so I hope you can help me with a request.

We need a module in Lua that splits a certain string and returns the value of specific pieces of that string. The input is for example type:forest_scale:25000_region:NL.

• If the template asks for type, then it returns 'forest' (and if none a '0' or empty), if it asks for scale, it returns '25000' (and if none a '0' or empty), and if it asks region it returns 'NL' (and if none a '0' or empty).
• The order in which the pieces of the string are can be different and should not matter, for example type:forest_scale:25000_region:NL should give the same results as scale:25000_type:forest_region:NL.
• It is possible that some string will not contain all of them, if for example type: is missing, a '0' or an empty answer should then be the result.
• It is possible users made a mistake and did add something unrecognisable to the string. If we ask for 'error' it then should give back the unknown part(s) or give '1' as output if there are problems/unrecognisable parts in the string.
• It is possible that the type: is city(...) with on the ... a number, for example type:city(20000)_region:NL. Then if the template asks for type, then it returns 'city' and somehow we should be able to extract that number separately. Like with a second parameter or with city/20000 so we can split it with a parserfunction.

Who can help me with this request? Thanks! Romaine (talk) 18:16, 24 March 2014 (UTC)

I've had a go at creating this at Module:User:Mr. Stradivarius/sandbox5. I'll post usage instructions here in a little while. — Mr. Stradivarius ^{♪ talk ♪} 00:18, 25 March 2014 (UTC)

In the mean while Martijn Hoekstra was so kind to write a module for me. Thanks for all the efforts. Romaine (talk) 01:21, 25 March 2014 (UTC)

So, it works like this:

• {{#invoke:User:Mr. Stradivarius/sandbox5|main||scale}} → Error: no input code specified
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL}} → Error: no field specified
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL|scale}} → 25000
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL|field=scale}} → 25000
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL|type}} → forest
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL|region}} → NL
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|foobar|region}} →
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|foobar|error}} → Error: the scale, type and region fields are missing
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:forest_region:NL|error}} →
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:city(30000)_region:NL|type}} → city
• {{#invoke:User:Mr. Stradivarius/sandbox5|main|scale:25000_type:city(30000)_region:NL|type|citydata=yes}} → 30000

Feel free to use my version or Martijn's version, whichever suits you better. If there's anything about my version that you want me to change, just ask. And if you're happy with it, I can make it configurable to work in different languages too. Best — Mr. Stradivarius ^{♪ talk ♪} 01:45, 25 March 2014 (UTC)

I have one function that add some values to the list. And other function should return that values.

Is there any way to do it?

As for now I can't find any mechanism to save some data between different module calls on the one page (using #invoke).

Can you help me please?.. Vitalik (talk) 17:53, 23 March 2014 (UTC)

No, there is no way to save a value between separate #invoke calls. This is by design, so that individual parts of a page can be parsed separately from other parts. This means that there is no possibility of this ability being added to Scribunto in the future, either. — Mr. Stradivarius ^{♪ talk ♪} 00:17, 24 March 2014 (UTC)

Oh, it's a really pity.. But great thanks for the answer!
I'm sory, can I ask one more question (it is about this subject but not about Lua).
There is an extension: Extension:Variables, that allows to use variables through template lagnuage (so it will be possible to save some information between template calls). Is it possible to activate this extension and what should we do for this? (I'm from russian wiktionary and this possibility can be very useful for us). Vitalik (talk) 21:11, 24 March 2014 (UTC)

I'm pretty sure the answer is no, for the same reason - the WMF technical people want to be able to parse individual parts of articles without those parts being dependent on parsing the other parts. — Mr. Stradivarius ^{♪ talk ♪} 23:44, 24 March 2014 (UTC)

There is deliberately no way to do this. If such a way is found, it will be considered a bug, and will be "fixed" (removed). mw:Extension:Variables will not be deployed here either. See bugzilla:7865 for the reasons why not. Jackmcbarn (talk) 20:59, 27 March 2014 (UTC)

i was asked on hewiki, and as of now, could not think of something useful rnough, simple enough for editors, and doable.

here is the deal: the user wants to create a template to be used in articles about athletes, more specifically footballers (as in the game played with a ball kicked by feet, not the game played with a "football" thrown by hand). this user would like to be able to create "stats" tables, with special rows for "subtotals" and "totals". for instance, imagine one row of the table for each year in the footballer's carre, and columns for "goals", "assists", "saves", "red cards" etc. if the footballer played in several clubs, for each club the columns should be totalled (these are the "subtotal" rows), and then the last row is the total for the whole thing (either total the "subtotal" rows, or else total everything *but* the subtotal rows). the template should work reasonably well for players that switched club many times (let's say 10), but also for players who played in few or even just one club.

for some historical athlete, be it Puskás or The Babe, i guess it doesn't make too much of a difference - use lotus 123 (or visicalc, or quattro or something) to calculate the totals and enter it as static data. however, for an active player, updating the stats after each season and re-calculating the subtotals and totals is both a drag, and a reliable source of bugs, errors and mistakes, so the automatic summing looks very attractive.

now, i would hate to create a module custom made just for this, because it makes sense that a "summing table" can be used in other contexts, maybe for other athletes, and maybe for other things also (who knows what - say, the amount of different kinds of wood chucked by some notable woodchuck over different decades or something). does such a template/tool exist? is it worthwhile to create it? can you suggest a syntax that makes sense and will be convenient enough to the editors? peace - קיפודנחש (aka kipod) (talk) 05:30, 1 April 2014 (UTC)

Is it possible to localized (number localization) Weatherbox

I don't have time to take on a new project at the moment, but I did something for hiwiki a few months ago that may be of interest. They wanted a module to translate between Hindi and English digits. Frankly I never understood why they wanted some of the requested features, but I gather they wanted something they could drop in a template/infobox that would accept numbers in either format, and produce results in a specified format (by format, I just mean using Hindi or English digits, and with correct group separators). The weather template/module appears to need something much more complex, but bear in mind that some simple tweaks to the hiwiki module may be useful for other purposes. See hi:User:Johnuniq/number which has relevant links. Johnuniq (talk) 22:40, 7 April 2014 (UTC)

I can hazard a guess as to the "why": they probably wanted to be able to use Hindi numerals in the #expr and #time parser functions. — Mr. Stradivarius ^{♪ talk ♪} 05:19, 8 April 2014 (UTC)

I'm not a expert. so it is very difficult for me to understand :( . it would be great, if someone take this. :) Anyway, Thanks for answer. --

talk

) 16:44, 8 April 2014 (UTC)

Hello!

So if you look at the various subpages of

So, does this sound like a good idea for a Lua module? And if so, would someone be willing to write the necessary code? If not, I'm just going to write a bot to do it; but I would prefer not to. ;) Thanks, Legoktm (talk) 07:51, 12 April 2014 (UTC)

That's not a job for a module. While certain ugly tricks are possible, essentially a module produces output from the input that it is given—it cannot (without hacks) read text from elsewhere on the page. What would be possible would be to devise some new syntax, and get people to use that syntax rather than doing what they are doing now. There would be one template per section, and the items would be passed as arguments to the template. The template would pass the arguments to a module which would generate the wikitext, including the trailing count. Johnuniq (talk) 09:37, 12 April 2014 (UTC)

Agreed. Doing text parsing like that with Lua is quite resource-intensive, so it makes sense to just have a bot to do the work once rather than to do it on every page parse. I actually tried to do this with

♪ talk ♪

11:42, 12 April 2014 (UTC)

Is 0.7 seconds really worth worrying about? Especially when it's imposed only on the rare occasions when someone edits a page? Especially when it's a page edited as seldom as these? I mean, when you try to debug a loop you can be imposing 10 seconds every time you do a preview, and I didn't think you really had to sweat that. I still remember Wikid77 going on about pages that took more than a minute to preview overall, due to templates. Wnt (talk) 21:09, 16 April 2014 (UTC)

@Legoktm: The simple way to do what is wanted would be to change the way those pages are constructed. For example, WP:Good articles/Natural sciences#Mineralogy currently has this wikitext:

=====Mineralogy=====
[[Kauri gum]] –
[[Nassak Diamond]] –
[[Vanadinite]] –
<small> (3&nbsp;articles)</small>

That could be changed to something like:

=====Mineralogy=====
{{#invoke:join|ga
|[[Kauri gum]]
|[[Nassak Diamond]]
|[[Vanadinite]]
}}

And someone would write the ga function in Module:Join (I'll do it). It would output the required wikitext. Johnuniq (talk) 02:03, 13 April 2014 (UTC)

Also agreed - if we're going to do it in Lua then this is probably the most painless way. We should get a consensus from the editors involved with GAs before we refactor all of the lists, though. — Mr. Stradivarius ^{♪ talk ♪} 16:08, 13 April 2014 (UTC)

On an implementation note, I think from an abstraction point of view, it would be better to create a new module to implement this feature (perhaps one that can be generalized to different classes of articles). It could of course internally call the join module if necessary. isaacl (talk) 17:08, 13 April 2014 (UTC)

• I think that the entire header and footer can be transferred to a module, which provides a good opportunity for the text in between to be run through it en masse. But I don't really understand all the places this is used from - in particular, why the subpage needs to be checked. Since there are a bazillion links to it, it's hard for me to see where it's transcluded. (I've just fiddled about with this at Module:Good Articles - that isn't really right yet; I still haven't really understood the data I'm messing with. But it should be proof of principle.) Wnt (talk) 23:18, 15 April 2014 (UTC)
• What about algorithm that wraps whole page, where paragraphs and simple wikilinks to good articles are passed as separate positional arguments i.e.:

{{#invoke:join|count|
...bla bla bla...
=====Mineralogy=====
|[[Kauri gum]]
|[[Nassak Diamond]]
|[[Vanadinite]]
|
... bla bla bla ...
}}

Each argument that match simple wikilink pattern ([[good article]]) is counted and printed in decorated form between next such item. Before every other item the counter is flushed to output and reset to zero, and the other item is simply copied to output. If the wikitext include some pseudo magic words they can be replaced in post processing (i.e. __TOTALGOODARTSINTHEPAGE__) with some statistics collected during generating the page. There is also a way to pass some named arguments to define i.e. separator to define the decorative separator between links, format with presentation of the counter, total with the pseudo magic word to replace in post processing etc. Paweł Ziemian (talk) 18:49, 16 April 2014 (UTC)

Wrapping an entire page in a #invoke isn't really a good idea. Jackmcbarn (talk) 18:58, 16 April 2014 (UTC)

This is the approach I started to take in Module:Good Articles, but indeed it involves some decision making that may come to be too constrictive, or else not really add much convenience. Johnuniq's first approach above is the same thing on a smaller scale that might turn out to be more manageable. The trade-off to consider is that if we have to stud the article full of "pseudo magic words", maybe those should just be calls to separate modules rather than parameters in some all-encompassing module with delusions of grandeur. Wnt (talk) 20:16, 16 April 2014 (UTC)

I did some tests on plwiki with wrapping whole page and I must admit that this is not good idea. There is an error Out of time error for LUA (the limit is set to 10 seconds). However, if I wrapped a few top level sections everything went fine within 3 seconds. I did this with passing whole contents as argument #1, and splitting the parameter to separate lines with analyzing them directly in Lua script. So the wikicode in the page looks like this:

{{#invoke:test|counter|
...bla bla bla...
=====Mineralogy=====
[[Kauri gum]] • 
[[Nassak Diamond]] • 
[[Vanadinite]]

... bla bla bla ...
}}

There was 13 main sections (= 13 invokes) and about 2200 lines of text. I used very simple test to determine number of links, looking for [[ at the beginning of line except [[File:, which points to picture that is sporadically used to decorate the page. If such wrapping method would be used on every set of links separately, then the script code might be simplified even more to determine number of lines in the argument, assuming that there is one link per line. Paweł Ziemian (talk) 21:25, 16 April 2014 (UTC)

I implemented the algorithm for this wiki. You may try to wrap a section from list of good articles within {{#invoke:Sandbox/Paweł Ziemian/test|goodCounter|...}} and see preview of the article. The Biology section took more than 7 seconds in Lua, so analysing the wikicode is not good idea, but works for small set of data. Paweł Ziemian (talk) 21:56, 16 April 2014 (UTC)

Well, my example wrapping the page at Module talk:Good Articles takes about 1.6 seconds -- it would be faster, except for some reason I can't get gsub to accept false or nil as the third parameter to avoid doing any substitutions when all I want to do is count with it (which is what the documentation says it can do). Wnt (talk) 03:05, 17 April 2014 (UTC)

Please just implement what I wrote above, which would be close to instantaneous, not to mention robust and comprehensible. Johnuniq (talk) 07:35, 17 April 2014 (UTC)

I just finished up my version of

WP:GA/NS at Module talk:Good Articles. Mine took 2.1 seconds compared to the original's 1.8 seconds on preview. There is now not a single div in the page source. Admittedly there are a lot of parameters to keep track of though. Wnt (talk

) 14:17, 17 April 2014 (UTC)

I think the best solution is using the essential replace function from Wnt code in the way the Johnuniq proposed initially:

=====Mineralogy=====
{{#invoke:tools|countLinks|
[[Kauri gum]] –
[[Nassak Diamond]] –
[[Vanadinite]] –
}}

which can be visible in action as

I did some tests on plwiki using the same page as above with 132 invokes and the Lua time usage is 0.203/10.000 seconds. Paweł Ziemian (talk) 19:31, 17 April 2014 (UTC)

The Lua time usage from previewing Module talk:Good Articles just now was 0.179/10.000 seconds, but admittedly this isn't a direct comparison since I'm not sure exactly what you previewed. In any case it should be clear that the time is not really a factor here - at this point, the question is what syntax the people who actually edit these articles would prefer to upkeep. If they want to make the conversion to one of these formats we also can write a module to do that automatically too. Wnt (talk) 15:08, 19 April 2014 (UTC)

There are always pro and cons. The clue is what are the weights. Your solution looks good for me, however it designed only for one very specific usage. The solution presented as first is simpler and more generic, and can be used anywhere where the counter seems to be interesting, but suffer from the fixed presentation format. Next argument is usability. If the module is wrapped in some template it can be easy usable by most people, which are familiar with wikikode or use visual editor. The last factor is maintainability. Whenever any change in presentation form is required it is always easier to make it in wikicode, which is more robust for many mistakes. Formating wikicode from Lua script is difficult, due to remember both the wikicode syntax wrapped in Lua syntax. Paweł Ziemian (talk) 19:27, 19 April 2014 (UTC)

Someone pointed me that generating whole sections in templates or #invoke causes that you have to always edit whole page. There is no [edit] link near to section title at any level. Paweł Ziemian (talk) 12:42, 20 April 2014 (UTC)

Hi,

I am wondering if it would be possible to make something like Module:Chessboard that can be used to make shogi diagrams. There is a shogi diagram template being used to create such diagrams on Japanese Wikipedia, but I am unable to get it to work on English Wikipedia. A shogi board looks sort of like a chess board, but there are some important differences:

1. A shogi board is 81 'squares' (9 files by 9 ranks)
2. Each 'square' is not really a perfect square; it is more rectangular with the height (or length) about 1.2 or 1.3 times the width.
3. Each 'square' is the same color. In a typical shogi diagram, this is usually the color white (or the color of the paper), and the borders/lines are typically black. Actual shogi boards can come in a variety of colors, but they are usually in a natural wood (beige/tan) color. Very similar to
   go
   boards in both style and color, just with less 'squares'.
4. Files are typically labeled usually the arabic numerals "1" through "9". Although ranks are typically labeled using Japanese kanji numerals, some English-language publications use the lower case letters "a" through "i" instead. Files are labeled from right to left, and ranks are labeled from top to bottom. Each square is indicated by a number-letter combination so the uppermost-right square is "1a", the bottommost-left square is "9i" and the long diagonal from right to left, top to bottom would be "1a, 2b, 3c, 4d, 5e, 6f, 7g, 8h, 9i". Unlike chess diagrams, labels for files and ranks in shogi diagrams only typically appear at the top and right sides of the board respectively.
5. On a tradition shogi board that are 4 dots at the intersections of certain 'squares' to indicate piece-promotion zones. These are are located at the intersection of the following squares: 3g-3f-4g-4f, 6g-6f-7g-7f, 3d-3c-4d-4c, and 6d-6c-7d-7c. See here for an example of what I am referring to.
6. Shogi pieces are usually indicated in a single kanji character. I believe the files used for the pieces in shogi diagrams in Japanese Wikipedia articles are available in Wikicommons. I am only interested in a diagram for traditional shogi and not any shogi-variants so the following pieces would have to be displayed: p="pawn", l="lance", n="knight", s="silver", g="gold", b="bishop", r="rook", and k="king". Since some shogi pieces can promote, the following are also needed: d="promoted rook", h="promoted bishop", t="promoted pawn", ps="promoted silver", pn="promoted knight" and pl="promoted lance".
7. Unlike chess, shogi pieces are all the same color so there is no "black" or "white". The player who moves first is called "sente" and the player who moves second is called "gote". Typically, sente's pieces are located at the bottom of the board (like the white pieces in chess) and gote's pieces are located at the top of the board (like the black pieces in chess). In , sente is indicated by the letter "s" and gote by the letter "g" so the sente's king would be "ks" and the gote's king would be "kg".
8. Captured shogi pieces are called "pieces-in-hand" and can be used on subsequent moves. In show diagrams, pieces-in-hand are usually shown on the sides of the board: the right side for sente and the left side for gote; however, they can be shown at the top (for gote) and bottom (for sente) if it is easier to do.

Well, I hope that's enough information for anybody interested in doing something like this. Please feel free to leave a message on my talk page, if you have any questions or need any further info. Thanks in advance - Marchjuly (talk) 07:34, 22 April 2014 (UTC)

I figured out a way to get the template I mentioned above to work on English Wikipedia so I guess there's no need for a Module:Shogiboard to be created. However, if somebody wants to take a crack at making one and has any shogi related questions, then please let me know and I'll answer what I can. Thanks again. - Marchjuly (talk) 04:07, 23 April 2014 (UTC)

For those interested, there is a discussion open about a possible change in behaviour of the mw.html library at the main project talk page. — Mr. Stradivarius ^{♪ talk ♪} 13:16, 22 April 2014 (UTC)

Hi, Maybe it already exists but could not fid it. But I'm looking for a for next loop possibility for something like this:

{{Result|races=5}} that translate to:

For x := 1 to races

||Race {{{x}}}

Next x

And produces: Race 1 Race 2 Race 3 Race 4 Race 5

How do i request this? Thanks in advance.NED33 (talk) 11:21, 9 April 2014 (UTC)

{{for loop}}? Jackmcbarn (talk) 12:07, 9 April 2014 (UTC)

Not quite i think. This is the result I need for a variaty of no of races with and without a medalrace variant. like these examples.

NED33 _/) 12:50, 9 April 2014 (UTC)

I wrote at Wikipedia:Help desk#Counters in a template that the goal could be achieved with something like 16 repetitions of {{#ifexpr:{{{races}}}>N|colspan=2 {{!}} '''Race N''' {{!!}}}} where N runs from 1 to 16. Such repetition is common in templates and I still doubt it's worth a module if there isn't a general for loop which can be used. PrimeHunter (talk) 13:35, 9 April 2014 (UTC)

The current situation is different but simular. The major problems that I have with it are: riged in case there are 17 races and that the code is hardly human readable/maintainable. But if there is no other solution I leave it like it is. However I am hoping on a more elegant solution than the current.NED33 _/) talk 14:18, 9 April 2014 (UTC)

It's quit silent on this one:-) Is there anyone coming for the rescue or do I leave it as it is.NED33 _/) talk 18:27, 11 April 2014 (UTC)

This is sort of frustratingly trivial, yet invites a really involved response. We certainly can hack together a simple for loop to output columns like this - it would make a good first Scribunto module if you want to try yourself. On the other hand, it just about begs us to write up a "Django" module that implements some substantial subset of the features in Django (web framework)/Jinja style templates, so that editors could wrap part of their text in an invoke and be free to do increments, for and while loops, substitute parameters, etc. Possibly a middle approach, with fewer features, is most viable, but then we have to make decisions about the syntax. It's just kind of tickling away, asking for a good general approach. Wnt (talk) 22:39, 18 April 2014 (UTC)

Would this be a starting point for the syntax?

{{ForNext|from = expr1|to = expr2|increment = expr3|statments = statm}}

So that the coding of above example could look like something like this:

{{ForNext|from = 1|to = races|increment = 1|statments = '

{{#ifeq|{{{counter}}}|{{{races}}}

|Medalrace

|Race {{{counter}}}'

}}

}}

I'm available to do tests or help but I have no experience with Scribunto not Django what so ever. Regards _/)_/)_/) ˷˷˷˷˷˷˷˷ _/) NED33^talk 08:58, 20 April 2014 (UTC)

Well, to begin with, Django templates use a {% whatever %} syntax which fortunately is ignored by the Wikitext processing. The article gives a few examples. But covering a large subset of it would be quite a lot of work, and I'm reluctant to dive into it right now - I have too many old projects I've left hanging already that I ought to finish... Wnt (talk) 06:06, 25 April 2014 (UTC)

I'm trying to write a lua script that will generate an "Awards and decorations" table for military officers (something like this. I wrote a draft script (still needs tweaking) at Module:Sandbox/DD4235/Military Decorations, but weird stuff happens when I try to #invoke it. User:DD4235/Military Decorations shows what's happening: first is the wikitext generated; seems fine. Then is what the wikitext renders as; something is wrong with the templates. Finally is what happens if the wikitext is copy-pasted back into a page; it works perfectly fine. Can anyone show me what I'm doing wrong? Thanks. DD4235 (talk) 04:19, 21 April 2014 (UTC)

This is because wikitext passed from Lua is not expanded. So if you return the text {{done}} from a Lua module, it will display as {{done}}, not as  Done. This is for performance reasons - the major reason for enabling Lua on Wikimedia wikis is to avoid the need to expand a lot of templates, which have a heavy performance penalty. To work around this, you can use frame:expandTemplate or frame:preprocess to expand the wikitext while in Lua. However, a better solution performance-wise would be to convert Template:Ribbon devices to Lua and use the require function to call that Lua module from your sandbox module. Hope this helps. — Mr. Stradivarius ^{♪ talk ♪} 06:55, 21 April 2014 (UTC)

Having said that,

substituting the module should work without using frame:expandTemplate, as substitution happens at an earlier stage of processing. Try using {{subst:#invoke:Sandbox/DD4235/Military Decorations|makeTemplate|...}} to see what I mean. — Mr. Stradivarius ^{♪ talk ♪}

07:01, 21 April 2014 (UTC)

Thanks. I'll try both of those solutions. I didn't realize that modules could be substituted.DD4235 (talk) 02:38, 23 April 2014 (UTC)

Frame:preprocess() which is generally deprecated as a slow solution, but has the advantage that it works on pretty much any wikitext without having to think about the specific syntax. You can refine processing of the individual items later on as you see fit. Wnt (talk) 01:31, 25 April 2014 (UTC)

I am working on a template that I'd like to be able to move into other language wikipedias with the minimum of recoding. A fragment of the English template looks like this:

{{{2|{{Title without disambig|{{PAGENAME}}}}}}}

In French this becomes:

{{{2|{{Titre sans précision|{{PAGENAME}}}}}}}

What I would really like to do is invoke the relevent code of {{

it:Template:Pipetrick
{{safesubst:#if:{{{2|}}}|{{{2}}}|{{safesubst:Str prima|{{safesubst:#if:{{{1|}}}|{{{1}}}|{{safesubst:PAGENAME}}}}| (}}}}

fr:Modèle:Titre sans précision
{{#Invoke:String|simpletitle|{{#if:{{{1|}}}|{{{1}}}|{{FULLPAGENAME}}}}}}

es:Plantilla:Título sin coletilla
{{#Invoke:String|replace|{{{1|}}}|%s%(.*%)||plain=false}}

Lua certainly looks like a promising direction. So, to cut out the 'external' template invocation for consistency and for transportability reasons, what should my first code fragment look like if I use Lua? and will Lua work on every single language Wikipedia? Thanks! Scarabocchio (talk) 09:06, 26 April 2014 (UTC)

Sometimes you re-read a posted question and the answer just jumps out at you

• {{#Invoke:String|replace|{{{2|{{FULLPAGENAME}}}}}|%s%(.*%)||plain=false}}

Will this work on all language Wikipedias? Scarabocchio (talk) 09:13, 26 April 2014 (UTC)

I would put all of your code in a Lua module to start with. Then I would implement {{

Title without disambig}} as a function in the Lua module, so that it is guaranteed to be the same in each wiki. Then you can just call that function instead of trying to find the proper template name, as the template may or may not exist, and if it exists it may or may not do what you want. What your first code fragment should look like depends on what you want your code to do. So we would need to know more about the specifics of your situation before we can give you a good answer. And yes, Lua will work on every language Wikipedia - and even Wikimedia wikis that aren't Wikipedias. :) — Mr. Stradivarius ^{♪ talk ♪}

09:21, 26 April 2014 (UTC)

Also, the code in your second post will work if every wiki uses the same version of Module:String. They probably do, but it's not guaranteed. And a better Lua pattern to use would be {{#invoke:string|replace|{{{2|{{FULLPAGENAME}}}}}|%s*%(.-%)$||plain=false}}. That is anchored to the end of the title, whereas yours might match something in the middle. And yours would match more than one set of brackets, if there are more than one for some reason. — Mr. Stradivarius ^{♪ talk ♪} 09:29, 26 April 2014 (UTC)

Many thanks! Scarabocchio (talk) 10:04, 26 April 2014 (UTC)

FYI. Your {{#invoke:string|replace|{{{2|{{FULLPAGENAME}}}}}|%s*%(.-%)$||plain=false}} doesn't work in French WP (though it does work in enWP). The variant that I gave in my second message (lifted from {{

Ignore that! I hadn't stripped the trailing spaces off the positional parameter, so the anchored regexp comparison failed, while the unanchored one "worked". Apologies. Scarabocchio (talk) 10:47, 27 April 2014 (UTC)

Could someone make that Module:it-conj in Wiktionary gives every page which uses any third parameter (e.g. leggere) the Category Italian irregular verbs? Compare this discussion. Thank you --Bigbossfarin (talk) 19:54, 3 July 2014 (UTC)

@Bigbossfarin: I'm not totally sure what you're asking for, but would

if args[3] and mw.text.trim(args[3]) ~= '' then
	table.insert(data.categories, 'Italian irregular verbs')
end

work? Jackmcbarn (talk) 20:23, 3 July 2014 (UTC)

Thank you for you help Jackmcbarn, but I think that doesn't work if any special parameter like "pastp=letto" appears. Is there any way to make that any additional parameter is filtered by this category?--Bigbossfarin (talk) 23:23, 4 July 2014 (UTC)

@Bigbossfarin: What about this?

for k,v in pairs(args) do
	if k ~= 1 and k ~= 2 and mw.text.trim(v) ~= '' then
		table.insert(data.categories, 'Italian irregular verbs')
		break
	end
end

Jackmcbarn (talk) 23:48, 4 July 2014 (UTC)

Thank you I will try it! --Bigbossfarin (talk) 12:25, 5 July 2014 (UTC)

It works! Thank you you very much for your help --Bigbossfarin (talk) 12:38, 5 July 2014 (UTC)

I'd like to talk about replacing {{

I note that the existing templates use a lot of switching to deal with the fact that they are covering six sports. Would it make sense to have a different version of each module for each sport? I'm thinking yes, but I'll defer to those with more expertise. If the answer is yes, the obvious question is whether to further subdivide between sex? I'm thinking no, but again, will defer to experts. Even if it makes sense to have nine separate modules, several still need to identify whether "Men's", Women's" or neither should be included, but I think that can be done simply, by having a sex parameter allowing "none" as a variable. (Unless that parameter drives anything else, in which case we need a second parameter, such as sextitle.)

What can I do to help write specs?

FYI, this template has 8296 transclusions.--S Philbrick(Talk) 21:55, 14 July 2014 (UTC)

This looks like a good candidate for Lua conversion. However, I'm a little reluctant to convert infoboxes to Lua right now, as once

♪ talk ♪

08:04, 23 July 2014 (UTC)

I was just appalled by a situation with

The root of it is that Template:Infobox military conflict has some byzantine syntax required to use a location map, referring to the documentation of other templates to explain its own documentation, and at least in any short period of time I can't figure out how to put a mark on it. Judging by a dozen battles I picked out, nobody else seems to know either, because none use the feature. It's impossible to simply import a map from, say, Farafra, Egypt and move the mark, because Template:Infobox settlement uses a whole different set of parameters. Now I realize that in the end we can just go with Template:Location map and try to ignore the rest, or better yet, just set up a div and set the mark about where it looks right ... but what we want really is a standard interface. I see that Module:Location map has made some heroic strides in this direction e.g. Module:Location map/data/Abkhazia (unfortunately we don't have one for Egypt, which may be part of the problem). But I'm thinking maybe what we really need is some way to make things more modular overall, i.e. a standard parameter that allows you to pass in the entire innards of the image frame preformatted, whether by transclusion or by calling another template etc., that bypasses more specialized (and variable) syntax. Maybe not - my thinking on this is admittedly confused, and I'm sure some here have tackled these situations often. But I want someone to come up with some kind of general philosophy to organize the approach rather than just diving in and making yet another divergent template or module. Wnt (talk) 15:43, 22 July 2014 (UTC)

Updating rankings on individual national football team articles has become an overly tedious task and I think it would be easier if {{Infobox national football team}} drew rankings from a single module and returned them on individual articles depending on the infobox's |Name= parameter (the value given in the parameter is always the same as "[name] national football team" in the article's title). Users, preferably members of the national teams task force, can then update these rankings every time new revisions are released. There should be a separate list for women's national teams, which would return rankings if |type=women in the infobox is active.

So basically, one central module should pull data from separate lists containing men's and women's rankings. For men, there should be two lists for

It would be bad for the job queue to have all soccer pages pull rankings from the same page. Jackmcbarn (talk) 04:33, 23 July 2014 (UTC)

With only 1237 articles using {{Infobox national football team}}, it wouldn't be that bad on the job queue. Another option though might be a wikidata item. Would still mean having to update a number of pages, but the rankings could then be used over all languages. Another thought is that the rankings could be done with a normal template #switch statement rather than needing to use lua and just placed as subpages of the template. -- WOSlinker (talk) 07:08, 23 July 2014 (UTC)

It can quite easily be done on different subpages in Lua as well. Storing the data in Wikidata sounds like the best idea to me, though. —

♪ talk ♪

07:57, 23 July 2014 (UTC)

Well, I'm absolutely stunned to see that a few days ago action was taken that might permit this to be possible (Bugzilla, merge) - still, my understanding is that Wikidata doesn't just let you add any old thing you want, everything takes approval. Also, I don't think it's live yet, because the examples from [5] (,) still don't produce any text. It would be a lot easier to do it with a WP based data file first, and then if someone cares he can look into coordinating the data files later. Wnt (talk) 13:28, 23 July 2014 (UTC)

Some broader issues concern this. First,

WP:NOTNEWS is usually misapplied in support of deleting anything that might compete with commercial news outlets, such as articles about recent events; but it actually does say that we shouldn't value the rankings for, say, July 17 more than we value those for some time in June. This is an encyclopedia and our goal isn't actually to produce continually-updated rankings. Also, there could be copyright issues over taking every single judgment call FIFA has ever made and putting it into a database. I ended up losing List of Forbes Global 2000 companies to such concerns and this seems pretty similar. So while we can write the module I don't know if you should really use it. Wnt (talk

) 13:34, 23 July 2014 (UTC)

@Wnt: The point isn't to produce continually-updated rankings. FIFA rankings are updated once every month or so anyway. Elo ratings however are updated almost everyday, but we could just update them the same time new FIFA rankings are released. Besides that I don't see how copyright issues would affect this. Davykamanzi → talk • contribs • alter ego 17:13, 23 July 2014 (UTC)

Have you considered using the FIFA API (See PDF )? I am thinking someone could design a Wikidata standard for the necessary information, populate on regular intervals using the API, then populate Wikipedia articles with links to the Wikidata elements.--S Philbrick(Talk) 18:29, 23 July 2014 (UTC)

{{Line chart
| color_background = white
| width = 600
| height = 350
| padding_left = 40
| padding_right = 15
| padding_top = 10
| padding_bottom = 20
| number_of_series = 2
| number_of_x-values = 11
| label_x1 = Ep. 1/2 | label_x2 = Ep. 3 | label_x3 = Ep. 4 | label_x4 = Ep. 5 | label_x5 = Ep. 6
| label_x6 = Ep. 7 | label_x7 = Ep. 8 | label_x8 = Ep. 9 | label_x9 = Ep. 10 | label_x10 = Ep. 11/12 | label_x11 = Ep. 13/14
| y_max = 5000
| scale = yes
| points = yes
| color_series_1 = blue
| color_series_2 = black
| thickness_series1 = 1
| thickness_series2 = 1
| S01V01 = 4550 | S01V02 = 3550 | S01V03 = 4080 | S01V04 = 3780 | S01V05 = 3880 | S01V06 = 3450 | S01V07 = 2980 | S01V08 = 3580 | S01V09 = 3540 | S01V10 = 3680
| S02V01 = 2600 | S02V02 = 2190 | S02V03 = 2380 | S02V04 = 1100 | S02V05 = 1950 | S02V06 = 1730 | S02V07 = 1730 | S02V08 = 2470 | S02V09 = 2220 | S02V10 = 1870 | S02V11 = 2090 |
}}

{{Line chart
| color_background = white
| width = 600
| height = 350
| padding_left = 40
| padding_right = 15
| padding_top = 10
| padding_bottom = 20
| delimiter = ,
| x-labels = Ep. 1/2 , Ep. 3 , Ep. 4 , Ep. 5 , Ep. 6 , Ep. 7 , Ep. 8 , Ep. 9 , Ep. 10 , Ep. 11/12 , Ep. 13/14
| scale = yes
| points = yes
| colors = blue , black
| group names = Book One: "Air" (2012) , Book Two: "Spirits" (2013)
| thickness = 1 , 1
| group 1 = 4550 , 3550 , 4080 , 3780 , 3880 , 3450 , 2980 , 3580 , 3540 , 3680 
| group 2 = 2600 , 2190 , 2380 , 1100 , 1950 , 1730 , 1730 , 2470 , 2220 , 1870 , 2090 
}}

function string.foo ()
	return 'Hello!'
end

local s = 'I am a string.'

-- This will log 'Hello!' to the console:
mw.log(string.foo(s))

-- This will produce an error "attempt to call method 'foo' (a nil value)."
mw.log(s:foo())

local aliases = {
	['에피소드 번호'] = 'EpisodeNumber',
	['에피소드 번호 2'] = 'EpisodeNumber2',
	['제목'] = 'Title',
	['제목 주석'] = 'RTitle',
	['부제'] = 'AltTitle',
	['부제 주석'] = 'RAltTitle',
	['예비1'] = 'Aux1',
	['감독'] = 'DirectedBy',
	['각본'] = 'WrittenBy',
	['예비2'] = 'Aux2',
	['예비3'] = 'Aux3',
	['본방송일자'] = 'OriginalAirDate',
	['방송일자 2'] = 'AltDate',
	['작품번호'] = 'ProdCode',
	['시청률'] = 'Viewers',
	['예비4'] = 'Aux4',
	['요약'] = 'ShortSummary',
	['선색'] = 'LineColor',
	['윗색'] = 'TopColor',
	['열색'] = 'RowColor',
}

local function local_args(args)
	-- Return a new table of arguments using any given local options.
	local result = {}
	for k, v in pairs(args) do
		result[aliases[k] or k] = v
	end
	return result
end

function padmiddle( source, len )
    local nodigits = ustring.match( source, "^%D*" )
         , digits = ustring.match( source, "%d*$" )
         , padlen = len - ustring.len( source )
         , zero = mw.language:formatNum( 0 )
    return nodigits .. string.rep( zero, len ) .. digits
end

{{#invoke:String|match|{{{P}}}|^%D*}}{{#invoke|string|rep|0|{{#expr:{{{L}}}-{{strlen|{{{P}}}}}}}}}{{#invoke:string|match|{{{P}}}|%d*$}}