Jump to content

Wikipedia:Lua/Requests

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by MZMcBride (talk | contribs) at 15:30, 31 May 2013 (→‎Module:RFX report: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Template:WikiProject Lua/header

Lua scripts on Wikipedia are similar to templates but useful for performing more complex tasks for which templates are too complex or slow. Common examples include numeric computations, string manipulation and parsing, and decision trees. You can use this page to request help from Lua developers in writing a Lua module for a specific task on Wikipedia or another Wikimedia Foundation project. Both debugging help and full implementation are available.

To start a request, just make a new section below and describe what you need. You may wish to first check Special:PrefixIndex/Module: to see if you can find a suitable existing script.

It may help developers to provide examples of where the task is likely to be useful within Wikipedia. If the proposal would replace or improve upon existing templates, please note which ones.

Charts

I was thinking about a module that will allow creation of charts from templates. Currently, I can only think of a way to implement bar charts (e.g., using <div> elements, with absolute position, background color and forced dimensions). I thought of three types of graphs: one with a single data type (say, population in 1970, 1972, 1974...), and multiple data types: e.g. population of 4 different towns in 1972, 1974, 1976...

The 2nd case also divides into two sub-cases: whether all the data uses the same scale, or different scales: for instance, one may want to display a chart that will show population and phosphor concentration in the water, so two (or more?) separate Y-scales will be needed.

Implementation is not that difficult, the hard part is selecting a reasonable syntax that will be sane and convenient to use, yet powerful enough to allow creating useful charts.

RFC: bar-chart syntax

This is what I have now. The idea is to use keys in the form of "Key n" or "Key n m" where n and m represent numbers.

So here goes:

{{ bar chart
| width = 
| height =
| value 1 1 = 
| value 1 2 =
| value 1 3 =
| value 2 1 =
| value 2 2 =
| value 2 3 =
| color 1 = 
| color 2 = 
| title 2 1 =
| x legend 1 =
| x legend 2 =
| x legend 3 =
| y legend 1 =
| y legend 2 =
}}

so this example is for two different groups, with 3 data points each. each group has a color and y-legend, and each data-point has x-legend. mapping to the example above, the groups represent town A and town B, and the data points represent 1972, 1974 and 1976. in the 2nd example the groups represent population and phosphor concentration.

each bar has a tooltip. if there is a "title x y =" for this bar, this will be the tooltip. otherwise, the tooltip will be the numerical value of the bar.

I do not like the proposed syntax all that much, I just could not think of a better one. will love to hear a better proposal.

Bar-chart Comments

I would suggest that it would be much more friendly to editors to consolidate values as lists rather than adding a new key for each value. For example:

{{ bar chart
| width = 
| height =
| group 1 = value1, value2, value3
| group 2 = value1, value2, value3 
| color 1 = 
| color 2 = 
| x legend = label1, label2, label3
| y legend = label1, label2
}}

That would require the module to parse the comma separated (or otherwise delimited) lists, but Lua is certainly capable of that, and it should be less of a pain for editors. Dragons flight (talk) 18:35, 21 March 2013 (UTC)[reply]

this makes sense. 2 comments though: the first is that comma is not a good delimiter: we should allow people to feed values in "language formatted numbers", e,g, 13,542.44 i tend to go for a colon as delimiter, but senicolon will also do. the the reason i did not use this syntax to begin with (i did think of something similar) is the desire to allow skippage: some of the values may be available to some of the groups only. however, after seeing your comment i realized that this was just silly: we can easily provide for missing values by repeating the delimiter.
bottom line: i like your improvement, with the stipulation of changing the delimiter. (same reservation for the labels - we don't want to disallow commas or other punctuation marks in the labels. peace - קיפודנחש (aka kipod) (talk) 19:02, 21 March 2013 (UTC)[reply]
I like semicolons more than colons, but I don't think it is a big deal either way. More significantly, one could easily add a parameter that allows users to configure the delimiter, as long as the default value is something sensible. Dragons flight (talk) 19:16, 21 March 2013 (UTC)[reply]
Maybe allow for an escape character (traditionally the \)? then you can have Django\: Unchainded as a label. You know, when we want to use the wrong name for a movie. Martijn Hoekstra (talk) 20:19, 21 March 2013 (UTC)[reply]
I would very much enjoy building a prototype, but my html/css-fu is weak. Could someone whip up a fiddle with an example? If I try to align those bars one more time to the bottom of the div, I think I might start crying. Martijn Hoekstra (talk) 21:30, 21 March 2013 (UTC)[reply]

There are quite a few examples of bar charts made with HTML/CSS here. As for the data format, I think comma-separated values would be a good starting point, as an editor with a large dataset is likely to already have it in CSV format, or be able to easily export it as CSV. We could write a general CSV parser module a la Apache Commons CSV that can be configured with different delimiter characters, escape characters, fixed-width formats, etc., as it could come in handy with other templates for displaying rich data sets. Toohool (talk) 23:20, 21 March 2013 (UTC)[reply]

My Module:ImportProtein is sort of like a bar chart. The key is to have an outer div with position:relative and an inner div with position:absolute. Use top: and left: to position. I did mine with all absolute px values - I'm guessing % would work. Note that this is the reason why I suggested setting a forum for html help in coding above. Oh, and Module:Plotter was a really simple case (scatter, not bar). Wnt (talk) 01:06, 22 March 2013 (UTC)[reply]
I've now expanded Module:Plotter with a "bar" function. However, I haven't touched the labels yet, which are probably the most aggravating part of all. Wnt (talk) 03:30, 22 March 2013 (UTC)[reply]
Update: after an amazing number of blunders, I finally got simple legends working also. Wnt (talk) 23:18, 23 March 2013 (UTC)[reply]
Well, I had a fun run trying to get the basics to work, but still chocked on the HTML/Style: It's just not my thing. I'll get cracking on the general purpose CSV stuff though. Martijn Hoekstra (talk) 01:56, 24 March 2013 (UTC)[reply]
I'm not sure where you were doing this, so I can't comment specifically, but: the core aggravation with html styling is that with many kinds of error you don't see anything at all. It is good to add lots of bits of unique text wherever you can put them in your divs and spans, and look for them in the HTML source code when you load the page to see if you get them at all and what the style being output really is. We really should have a help forum for HTML - come to think of it, there might be something at Wikiversity - freelance website design is a skill, even an occupation that WMF should be teaching to large numbers of people. Wnt (talk) 14:39, 26 March 2013 (UTC)[reply]
The code I was using is at http://pastie.org/7130472 , which generates http://jsfiddle.net/rj7KC/1/ It probably already has way too much "I know, it needs another DIV as a container!" going on. Martijn Hoekstra (talk) 23:02, 26 March 2013 (UTC)[reply]
Hmmm... among other things, it seems like the scroll bar on jsfiddle hates me, and v.v. I think I'd have to play with the code here for a while; it seems fairly complex with some useful general functions (we definitely should have a transpose standard, shouldn't we). Meanwhile I'm being aggravated by "losing altitude" on my Module:ColorAlphabet ... seems like no matter how many times you think you are past some HTML bug it'll just be right back again next time. Wnt (talk) 23:45, 26 March 2013 (UTC)[reply]
I would certainly like a matrix library with among others transpose, but also the sort of 'scalar product' ( f({'s', {a, b, c}}) => {{'s', a}, {'s', b}, {'s', c}}), but actually also a functional library with at least map and reduce/fold (I'm lost without map). I'm not sure if that sort of stuff should be somewhere in mw.something or in a local Module on en.wiki. Also, this is the first time in my life I named a function bar without it being a placeholder name ;). Anyway, play with it as you please, consider it CC-0 for licensing purposes (which means, if you get it working and want to upload you don't need any attribution, which is a lot easier on the edit summaries). Martijn Hoekstra (talk) 00:16, 27 March 2013 (UTC)[reply]

Bar chart progress report

so i think i'm close to finish on processing the parameters and drawing the graph itself, i.e. the bars. still missing placing the scales, validating the input with reasonable error messages, and testing.

currently 2 main modes are supported: regular barchart, and "stack", in which the different groups are stacked on each other, which can be used, e.g., to show market share distribution _and_ market growth.
in the "normal" mode, three scale systems are provided: uniform (i.e., one scale for all values), or per-group (which makes sense when the different groups are in different units - let's say town population vs. town budget over time). per group scale can be automatic or "manual", where the editor enters the scales.

you can see a demonstration by opening Special:TemplateSandbox, and feeding "User:קיפודנחש/sandbox" as Sandbox prefix, and "User:קיפודנחש/sandbox/testbar" as Render page. Here is a link.

peace - קיפודנחש (aka kipod) (talk) 06:34, 27 March 2013 (UTC)[reply]

Stage 2: see Module:Chart

i think i'm pretty much done, modulo bugs. please see Module:Chart. peace - קיפודנחש (aka kipod) (talk) 21:05, 30 March 2013 (UTC)[reply]

What went wrong

So the thing is more-or-less written, but i just discovered this pretty powerful-and-difficult-to-work-with extension, called mw:Extension:Timeline.

This extension is pretty powerful on one hand, but uses a very difficult and cryptic syntax: to some extent, it feels like going back to write in Assembly language all over again.

So here is what i think now: The main task of this page, is to come up with the best (i.e., most convenient and easy for the editors) syntax possible for providing the parameters. once we do this, writing a lua module that will translate this to something "Timeline" can consume should be a breeze.

I suggest at least 2 if not 3 dfferent chart types. First off, we have line vs. bar. then, we have single-data vs. multiple data. not sure if the timeline extension can do area charts also, but if it can, i suggest we do this too. personally, i ma not crazy about what seems to be enwiki standard mode of operation, which is to create one gargantuan template that can handle all cases based on dozens and dozens (in some cases hundreds) of parameters. i much prefer having one template per each specific task, or at least for each close enough set of tasks, with much more limited set of parameters.

either way, as i said above, i think the purpose of this page is to define and come up with good, sane and simple "syntax", i.e. defining the parameters that this template should accept, and defining clearly what each means and how it behaves. once good definition of syntax is achieved, we can go on to program. i will take the first shot defining the basis for line graph:

{{#invoke:Chart | line graph 
| y legend = 50 : 100 : 150 : 200
| x legend = 1920 : 1940 : 1960 : 1980 : 2000 : 2020
| line 1 = color:blue, thickness:2, points:* (1920 : 70 : description ) (1925 : 77 ) (1930 : 88 : bla bla ) (1936 : 60) .....
| line 2 = ditto
}}

exaplain: data points appear in parenthesis, separated by colon (numbers can be given as 2000 or as 2,000, so separating the X and Y by a comma is unacceptable). each point is either a pair or a trinity, where the 3rd optional item is text to be either displayed or used as a hint (timeline graph is also an imagemap). optionally, we can allow separate definition for legend and tooltip: (xval : yval : legend : tooltip). enclosing the tupples in parenthesis seems very natural, with the added benefit that unlike brackets and braces, parens have no special role in wiki syntax.

this is not a full fledged proposal - more like a teaser, to get the ball rolling. if someone thinks it's appropriate, we can move this whole discussion elsewhere, as long as i'm not the only one blabbering in this "elsewhere".

peace - קיפודנחש (aka kipod) (talk) 19:29, 31 March 2013 (UTC)[reply]

Numerous prior templates

Other editors have created several, very fast chart templates, such as Template:Bar_chart, which formats a bar chart in 1/14 second, or 7 charts per 0.5 second, with 1 or 2 or 4 columns of bars. There is not much need for faster charts. See also:

Previously, the <timeline> tag has been used, for charts with hard-coded numbers (no data from parameters) in an article page (see: Help:Bar_chart). -Wikid77 16:16, 4 April 2013 (UTC)[reply]

you keep on harping on the "speed" issue. this is absolutely not the issue here. most articles are unlikely to have large enough number of charts that the speed will be meaningful. the source of this request has nothing to do with speed. the main problems with existing chart templates are:
  1. poor readability of the charts themselves - this is typical to charts based on "timeline extension".
  2. convoluted syntax that makes it difficult to actually use them. again, one can create a chart without vanilla "timeline extension", using no template whatsoever, but the syntax is so difficult and convoluted that it's not practical.
  3. limitations: because of wiki template limitations, each of these is limited with hardcoded "left1", "left2" "left3" parameters or somesuch, vs. lua's flexibility of interpreting its parameters, which allowed me to support "group n" with no hardcoding of the "n" values.
  4. convoluted, difficult to change and maintain template code. this is not the fault of the brilliant people who created these templates - it's the need to squeeze out of the very limited wiki template syntax some functionality it was not designed to have.
individual issues with the charts you pointed to:
  1. {{historical populations}} is not a chart. i do not know why you even included it in this discussion
  2. {{bar box}}: nice, but very limited.
  3. {{Pie chart}}: ingenious. i wish i had the html/css-fu to make something like that. this is exactly the kind of template that could and should be done in Lua. in addition to losing the artificial limitations (why 10 slices?), and the awkward coding. after seeing that it can actually be done, i'm almost tempted to create a "pie" function in Module:Chart. here is a list of _some_ if the limitations of this brilliant tool that would be very easy to overcome if it was done in lua:
    • only 10 values (more can be added even without lua, but some artificial limit will always exist, and every time you want to add another slice the template becomes more complex)
    • input must be in percentage, so the editor must calculate the total and the percentage of each slice, which is more difficult than desired
    • no control of chart size: it-s always 200x200
  4. {{brick chart}} - bizarre. maybe ingenious, but this is not a standard way to display numerical data in graphical form
  5. {{Vertical bar chart}}: this one uses the "timeline" extension, and falls short on several fronts: it's very limited, it is not very convenient to use (only 10 articles use it currently), and the result suffers from all of "timeline" limitations (poor aesthetics and readability).
none of the examples allow for stacked bars, which is a standard way to display data. just to illustrate, see if any of the existing chart templates you pointed to can show something like this. also, please open it in edit mode and see how convenient it is to create it. there might be some kinks and bugs, but thanks to the fact that is' a sane lua code of less than 300 lines (including comments), it's much more manageable than most of the templates you linked to.
Medal distribution in some imaginary Olympic games


25
50
75
100
125
150
again, focusing on speed alone show you did not get the point for this module. it's not about speed, it's about creating an easy to use and capable charting tool. if you, or anyone else, have suggestions to help make the syntax clearer and more convenient to use, or more capable, or just point to plain simple bugs - i'm eager to hear them. if you want to talk more about speed, please don't - it's completely besides the point here. קיפודנחש (aka kipod) (talk) 18:11, 4 April 2013 (UTC)[reply]
* The prior markup-based chart templates are tested to work on many browsers: More important than ignoring speed, is ignoring to support a wide range of browsers. In particular, Template:Brick_chart (which has horizontal "stacked bars") works on any browser, probably even IE 5 on archaic Windows 98. So, people might re-argue "what counts" but working on any browser is the main priority, and other features which also do not work on those browsers are a unfortunate side-show. However, the Lua chart could be used to write a markup-based chart for any browser, with similar parameters. -Wikid77 00:02, 25 May 2013 (UTC)[reply]
i really do not know how to relate to these nonsense. what do you mean "markup based"? you talk as if you do not actually understand how these things work. the lua code runs on the _server_. this is not javascript. there is absolutely no relations between the lua code and the browser. the browser receives pure markup, just like with any template. if you mean to say that it's my "job" to test with older browsers, this is equivalent to asserting that anyone who create a new template should test it with all browsers. if you have any evidence that this does not work with any specific browser, let's discuss it. otherwise, please stop with this nonsense. (and btw: is your claim that brick chart works with "any browser" based on any evidence? who tested it? can you ask them to test _this_ module with those browsers? קיפודנחש (aka kipod) (talk) 02:50, 25 May 2013 (UTC)[reply]
Obviously קיפודנחש is correct—the wikitext required to generate the above chart is stunningly simple, and that's what counts (it's also very fast and provides good results: a bonus). It might be helpful to point out any features that are provided by other templates which are not available in Module:Chart, but focusing on speed misses the point. One feature that might be difficult be to implement would be clickable wikilinks. I won't bother looking for examples at the moment, but I have seen some super-ugly charts with very useful information that includes lots of links, and it would be wonderful if they could be replaced with something simpler and more attractive. Johnuniq (talk) 23:40, 4 April 2013 (UTC)[reply]
Again, "what counts" is for the chart to show on any browser as the main priority. -Wikid77 00:02, 25 May 2013 (UTC)[reply]
i think that this can be done, by overlaying transparent images on top of the bars, and using the "link=" feature of the images. let me ponder it a little, but in the meantime, try to think of reasonable syntax. maybe the same syntax we use with "tooltip"? i.e., replicating the "group 1", "group 2" with "link 1" "link 2", where everything is optional? please come with some suggestions for syntax that will be most useful.
btw - i think that you can already use links for the x legends and group names, though i admit i did not test it. testing now... peace - קיפודנחש (aka kipod) (talk) 00:10, 5 April 2013 (UTC)[reply]
huh! now i just gave myself an answer for the question i asked down in this page - "give me a usecase for delinker"... i made the "group names" links, but now the toolips are screwed... peace - קיפודנחש (aka kipod) (talk) 00:17, 5 April 2013 (UTC)[reply]
ok, so i added the ability to make specific bars links. check Module:Chart/doc. קיפודנחש (aka kipod) (talk) 04:09, 5 April 2013 (UTC)[reply]
I've set up a Lua piechart function for Module:Plotter (though it still uses the Legend template and isn't yet resizable). At least it isn't limited to 10 items. Wnt (talk) 05:15, 5 April 2013 (UTC)[reply]
can you add some examples to the /doc page, so we can see what this can and can't do? thanks, peace - קיפודנחש (aka kipod) (talk) 14:01, 5 April 2013 (UTC)[reply]
I added two examples. In the one it looks like the limitations are showing - my browser renders a 1% slice with some blurring. Wnt (talk) 20:38, 5 April 2013 (UTC)[reply]

another progress report

So i added "pie chart" capability to Module:Chart. it is not all that different from the pie chart Wnt created in Module:Plotter (i actually appropriated his submodule that gives default colors, namely Module:Plotter/DefaultColors ). the main difference is that i think my code is clearer and more readable (although it is very possible that Wnt will think *his* code is clearer...), and the way my module takes its parameters: i used "tupples", that provide the slice value, the slice name, optional color (otherwise the default will be used, at least for up to 26 slices - after that there's no more defaults...) and finally a link, so the whole thing looks more or less so:

| slices =
( Val1 : Name1 : Color1 : Link1 )
( Val2 : Name2 : Color2 : Link2 )
( Val3 : Name3 : Color3 : Link3 )

"Color" and "Link" are optional. in the example above i placed one tupple per line for readability, but this is not required, so it can be

| slices = (Val1:Name1)(Val2:Name2)(Val3:Name3)...

of course, both Wnt and myself owe the idea and the solution to the brilliant people who created Template:Pie chart, but i think the module has several advantages over the template:

  1. not limited to 10 slices (10 is probably enough in most real world uses, but it's still good to remove artificial limitation)
  2. do not have to provide the numbers in percents (i.e., the numbers do not have to add up to 100 - adding up to five billion or to 0.001 is perfecly fine)
  3. can define the pie's radius - not hardcoded any more like in the template
  4. can provide the input in localized number format. this means that the values can be writter like so: 12,402.67 (note the comma), which makes the page more readable.
  5. utilizes "imagemap" to provide tooltips and optional links from the slices
  6. more convenient way to feed the parameters (at least i think it's more convenient)

The pie chart could use a bit more testing, but i think it is good to use. Currently this module is not used in the main space, but i think both the bar graph and the pie chart are now better than what's currently in use in enwiki, if i say so myself, both in appearance/functionality, and also in convenience and more sane syntax.

do you guys think it's ready for "big time", and if so, how do you suggest we can go about it?

regarding "what's next": i'm not sure i am interested in continuing with more charts, but i think it would be good if someone would create a nice horizontal bar-chart. the advantage of horizontal chart is that this makes room for large number of legends, and allows large number of bars - for some type of data it's very useful.


peace - קיפודנחש (aka kipod) (talk) 05:21, 13 April 2013 (UTC)[reply]

I think it's high time we have a "WP:Lua/Announcements" or something. We should have two sections - one where you can announce "beta versions" that seem ready to be tested in some articles to see if anything goes wrong, and one for "production versions" that have been reviewed by multiple editors, used in many of the target articles, have all their t's crossed and i's dotted (and spaces inside their parentheses, even if it seems silly). If several of us got together and made this page we might make a more effective periodic announcement at VPT, in the Signpost etc. by referencing it and reporting a few highlights. Wnt (talk) 15:58, 16 April 2013 (UTC)[reply]
+1 (i also think i forgot to mention that i appropriated the Module:Plotter/DefaultColors from Wnt's work). in the meantime, i translated Module:Chart to Hebrew - you can see the hebrew version in he:Module:גרפים, and some other users have improved on it a bit - specifically we taught "bar char" to (optionally) display the numerical value inside each bar, and we also taught it to (optionally) rotate the x-axis titles, to allow squeezing in more titles in a certain graph. peace - קיפודנחש (aka kipod) (talk) 16:54, 16 April 2013 (UTC)[reply]
How do you do the rotate? I was under the impression the rotate property was an HTML5 thing that Wikipedia doesn't support (or allow). Wnt (talk) 17:04, 16 April 2013 (UTC)[reply]
"html5" is not well defined. there are some features of html5 that are supported by most browsers (euphemism to "all but IE") for a long time now, such as "Canvas" (support was added to ie in ver.9) or lists in columns (which enwiki is using for several years now in footnotes, all sane browses support it for a long time now - even ie added support in ver. 10).
specifically, it's done with somewhat long incantation:
style='-webkit-transform:rotate(90deg);-moz-transform:rotate(90deg);-ms-transform:rotate(90deg);-o-transform:rotate(90deg);transform:rotate(90deg)'
wikipedia does not block it, and all browsers support it (including ie, though i do not know which versions. i believe 7 does, and i guess 6 does not). peace - קיפודנחש (aka kipod) (talk) 18:14, 16 April 2013 (UTC)[reply]
Excellent! I can think of a few uses for this... Wnt (talk) 21:15, 16 April 2013 (UTC)[reply]
http://caniuse.com/#search=transform can I use is nice. Martijn Hoekstra (talk) 22:34, 16 April 2013 (UTC)[reply]

Total newbie can't get a basic script to work

Hi everyone,

See:Module:Sandbox/Yaris678 and User:Yaris678/Sandbox

I am just trying to write a script that concatenates the word "test:" in front of the string that is input but I can't get it to work. I would really appreciate a pointer.

Yaris678 (talk) 20:51, 1 May 2013 (UTC)[reply]

Seems to be working fine now I'm on a different machine. I guess it was either a caching issue or the really old browser that was on the previous machine. Yaris678 (talk) 22:37, 1 May 2013 (UTC)[reply]
Oh... It was because of this change! Thank you Dragons Flight! Yaris678 (talk) 06:23, 2 May 2013 (UTC)[reply]
Your problems were due to the way the interface between Lua and MediaWiki works. I also had problems understanding it at first, as it is quite a jump from doing template coding. Basically, Lua modules on Wikipedia have to be set up in a very specific way for them to be accessible from normal wiki pages. First, the modules have to return a table. This is the part of the module that goes:
local z = {}
-- Module code
return z
Next, that table has to contain a function. This is the part of the module that goes:
function z.test( frame )
    -- Function code
end
Note that you can have functions that aren't items in the table, but that those functions aren't directly accessible from normal wiki pages. Now, if you have a function that is a member of the table that the module returns, and you give that function a parameter (in this case, the text "frame" inside the brackets), then the software does some magic that lets you interface between Lua and MediaWiki. The software makes your parameter a frame object, which is a Lua table that contains information about the #invoke command used to call the module, as well as a few other things. It doesn't matter what you call the parameter, whether it is "frame", "n", or "monkeys" - it will always be a frame object. So your previous parameter "n" was actually a table, not the value of "ABC" that you thought it was. Because you tried to concatenate a table to a string value, you got an error. The usual way of doing this is as Dragons flight showed you:
local z = {}

function z.test( frame )
    return "test:" .. frame.args[1]
end

return z
Here, frame.args is a sub-table of the frame object that contains the arguments passed to #invoke, and frame.args[1] is the first field in that table. (Or in other words, frame.args[1] is the first positional argument passed to #invoke.) This could also work with your parameter "n", like this:
local z = {}

function z.test(n)
    return "test:" .. n.args[1]
end

return z
And finally, if you passed a named argument to #invoke, e.g. {{#invoke:Sandbox/Yaris678|test|foo="ABC"}}, then you would need to use frame.args.foo instead of frame.args[1]. Hope all of this sheds some light on the situation. :) — Mr. Stradivarius ♪ talk ♪ 10:31, 2 May 2013 (UTC)[reply]
That's really helpful. Thanks.
I am currently trying to work out the order that MediaWiki does stuff. See my sandbox.
It seems that MediaWiki will mostly parse the output from the Lua script but the <nowiki> tag is left as is.
Is this sort of stuff explained somewhere? I notice that mw:Extension:Scribunto/Lua reference manual#Returning text indicates that curly brackets aren't processed but it doesn't mention <nowiki>.
Is there a way to get MediaWiki to process the <nowiki> tag?
Yaris678 (talk) 12:50, 2 May 2013 (UTC)[reply]
<nowiki> tags are a special case. They can't be used as-is in Lua because that would break the software, so instead they (and their content) are converted to a "strip marker". Strip markers are mentioned here in the manual and you can see a little bit more detail at Wikipedia:Strip markers. — Mr. Stradivarius ♪ talk ♪ 13:28, 2 May 2013 (UTC)[reply]
Interesting. Thanks. I was hoping to use Lua to create a version of {{Nowiki}} that could be transcluded, rather than substituted. But maybe that's not possible. Ultimately, what I want is to be able to put a nowiki on the input to a template. This would allow us to remove an input to {{markup}} that is basically a repeat of another input. Yaris678 (talk) 17:15, 2 May 2013 (UTC)[reply]
The Lua function mw.text.nowiki( string ) should give visually the same results as &lt;nowiki&gt;string</nowiki> in most cases. One issue is that template and tag expansion happens before Lua is called, so one can't use Lua to nowiki a block that contains templates or tags (e.g. &lt;ref&gt;). Dragons flight (talk) 17:28, 2 May 2013 (UTC)[reply]
Awesome! That's exactly what I need. See below. Yaris678 (talk) 08:12, 3 May 2013 (UTC)[reply]
Markup Renders as
[markup]

[rendering]

If anyone is interested, I have documented some cases where this does and doesn't work. It can be seen at User:Yaris678/Markup. There is also some discussion at User talk:Yaris678/Markup. Yaris678 (talk) 00:19, 8 May 2013 (UTC)[reply]

Json

Is there any native support for json?Smallman12q (talk) 02:14, 3 May 2013 (UTC)[reply]

Not that I know off, but why would you want to do that? The only things I can think off is pulling in external data through some API, and - if that is even possible - sounds like a terrible idea to me, or to create on-wiki pseudo-databases with json content, which, if they are even reachable, sounds equally horrible to me. Martijn Hoekstra (talk) 17:05, 8 May 2013 (UTC)[reply]
No. See mw:Module:JSON and d:Module:JSON for possible workarounds. Legoktm (talk) 12:19, 12 May 2013 (UTC)[reply]

Hello. Is it possible, to add a new function to this module, which counts the list items? This could be used in templates where before or behind the list appears an information about the number of list items. The function "count" could return the number of items. Greetings --Tlustulimu (talk) 11:57, 11 May 2013 (UTC)

I copied the message from the template discussion page. --Tlustulimu (talk) 13:19, 11 May 2013 (UTC)[reply]
Hello. I just created a sandbox.
{{#invoke:listify/sandbox|input|;|what is this; i don't even}}
{{#invoke:listify/sandbox|count|;|what is this; i don't even}}

{{#invoke:listify/sandbox|input| .. |1 .. 2 .. 3 .. 4 ..}}
{{#invoke:listify/sandbox|count| .. |1 .. 2 .. 3 .. 4 ..}}
returns

Script error: No such module "listify/sandbox". Script error: No such module "listify/sandbox".

Script error: No such module "listify/sandbox". Script error: No such module "listify/sandbox".

It works! --Tlustulimu (talk) 21:45, 12 May 2013 (UTC)[reply]

Parameter input: separate value from reference

Please see {{infobox californium}}, using {{infobox element}}. The input parameter requires the value (measure), the unit is added (like "K" for Kelvin). |boiling point K=1743<ref>...</ref>Boiling point | 1743[3] K. Not, as intended: 1743 K[3]. Is it possible to distinguish and separate the <ref></ref> from the value, so that we can set the sequence right (value -- unit -- reflink)? I guess separation (recognition) should happen for all possible ref forms (like {{cite web}} too). Secondary, also <span> tags could be catched, to allow text additions same way: 1743 K (estimated). -DePiep (talk) 08:38, 14 May 2013 (UTC) (fixes -DePiep (talk) 09:16, 14 May 2013 (UTC))[reply]

The ref tags are converted to strip markers before they enter Lua. You can process the strip markers using a search and replace (search for "Remove any [[Help:Strip markers]] representing ref tags" in Module:Delink for an example where I remove them). You should be able to move the strip markers around without affecting the reference content, so I don't think you should have any problems with what you want to do. I've not tested it myself, though. You can also remove the strip markers, which removes the superscript link but doesn't remove the reference from the reference section. It is also possible to filter out strip markers that represent references from strip markers that represent other kinds of content by searching for the "-ref-" text in the middle. (Module:Delink does this.) Hope this helps. — Mr. Stradivarius ♪ talk ♪ 09:08, 14 May 2013 (UTC)[reply]
Thanks. Will research this route. -DePiep (talk) 09:16, 14 May 2013 (UTC)[reply]
Will sandbox this, to remove the ref (keep the value) and, mirrored, to extract the ref (to add in the end of the output). Anything on alpha-stability of the module? -DePiep (talk) 08:13, 15 May 2013 (UTC)[reply]
The module still needs a lot of testing, although the basics are there. There are a ton of edge cases that I need to get handled correctly, and I still have to add support for stripping file links. I also want to remove the expensive parser functions so that it can be used in more performance-critical applications, e.g. for citation templates. I've been tied up with mediation stuff lately, but that is set to finish very soon, so I might look into making it more stable in the next few weeks. — Mr. Stradivarius ♪ talk ♪ 15:48, 23 May 2013 (UTC)[reply]
  • Hide reftags in div-tags then {choptext}: Hopefully, the Lua module can be written to exclude the reftags, but meanwhile, using a div-tag, to encapsulate a reftag, will enable Template:Choptext to remove the tag, leaving a valid number for calculations, while also allowing the footnote to appear:
  • For value 45 with div-tag, 45<div><ref>xx</ref></div> → 45
  • Choptext value 45 with reftag:   {{choptext|45<ref>xx</ref>|<}} → Template:Choptext
  • Choptext value 45 with div-tag: {{choptext|45<div><ref>xx</ref></div>|<}} → Template:Choptext
The peculiar encoding of reftags with strip-markers causes many bizarre problems which will confuse most editors, and so such parsing of reftags is an unfortunate nightmare in the design of the wiki-markup text. -Wikid77 (talk) 08:17, 17 May 2013 (UTC)[reply]
So far I'm able to catch the well-formend refs at end of text, using the delink module. Problems arise when there are more tags like <span> in the string. to be continued. -DePiep (talk) 08:52, 17 May 2013 (UTC)[reply]

License templates

Is it feasible to create a Lua module that will judge (the best it can) a copyright status in different countries according to some parameters fed: the date of the first publication, the date of the author's death, the country of the first publication? --DixonD (talk) 13:58, 14 May 2013 (UTC)[reply]

I would say that this is possible. I am looking at this matter from an copyright standpoint and whether there is an possibility to calculate whether an work an possible copyright infringement or not. I am thinking about calculating that then from an standard copyright term, when possible. For most countries the following formula can be used:
death of author + x years = copyright expiry date
Those x years depend on the country where the work was first published. I assume that could be pulled from an list, an lua switch, maybe. Then, when we have the copyright expiry date, it´s just a matter of comparing it with the current date. If the copyright expiry date is in the future, then the file is an possible copyright infringement, else it is perfectly legal.--Snaevar (talk) 14:36, 17 May 2013 (UTC)[reply]
I'm trying now to implement this on Ukrainian Wikisource: s:uk:Module:PD-auto. The idea is that for each country of the original publication we can have a separate submodule which would calculate if it is in public domain or not in this country and if it was in public domain before URAA date which may vary for each country. Then basing on this information we can calculate the copyright status in the United States and produce the final message. I have some tests here: s:uk:Обговорення модуля:PD-auto/тести. Sorry, messages are in Ukrainian but I think it would help you to get the design idea. If you are willing to join, I can port existing code somewhere here, on English Wikipedia. --DixonD (talk) 04:42, 22 May 2013 (UTC)[reply]

File extension

What would be the easiest way to get the file extension into a template? "jpg" if you are in "file:foo.jpg", etc. I do not think we can do it with parser functions so the next thing to try would be Lua. It probably can be done with string functions, but may be it is already written somewhere. --Jarekt (talk) 02:46, 21 May 2013 (UTC)[reply]

{{#invoke:string|match|s=file:foo.jpg|pattern=%.([^.]+)$}} → jpg
I hope that is a satisfactory answer to the question. --darklama 14:54, 23 May 2013 (UTC)[reply]
Could also use a replacement (gsub) - str:gsub("^(.*)%.","") -- removes everything up to the last period and get remaining file extension jpg, png, svg etc. Matroc (talk) 05:26, 26 May 2013 (UTC)[reply]
Thanks, that worked great. I created Commons:Template:File extension. --Jarekt (talk) 11:32, 28 May 2013 (UTC)[reply]

Hi. If anyone is bored, I think Template:Loop could use a rewrite. :-) --MZMcBride (talk) 13:57, 31 May 2013 (UTC)[reply]

this was discussed in the past. i added a "rep" function to Module:String, which can easily be used to implement "loop": like mapping {{loop|25|test}} to {{#invoke:String|rep|test|25}} or somesuch. there is some work, of course (including some testing), but no new lua coding needs to be done - it's all in the realm of the template itself. peace - קיפודנחש (aka kipod) (talk) 14:16, 31 May 2013 (UTC)[reply]
Oh, right. So we just need to update the template. Okay, that's good to know. Thanks! --MZMcBride (talk) 15:28, 31 May 2013 (UTC)[reply]

Hi. If anyone is looking for a silly project to pass the time, Module:RFX report could use a lot of love. It's an attempt to largely replace the need for a bot to update User:Cyberpower678/RfX Report. --MZMcBride (talk) 15:30, 31 May 2013 (UTC)[reply]

  1. ^ xx