Module talk:Chart

Text and/or other creative content from this version of Module:Chart was copied or moved into Module:MLB standings with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Text and/or other creative content from this version of Module:Chart was copied or moved into Module:MLB standings with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

I've developed a more automated template for population growth charts (intended for census data on geographical articles) at the Vietnamese Wikipedia. If anyone's interested, I'd be happy to port vi:Mô đun:Thời biểu dân số over to this wiki; just contact me. – Minh Nguyễn (talk, contribs) 16:53, 31 March 2013 (UTC)[reply]

i gave it a cursory look. first of all - very nice! second - the Vietnamese version currently is limited to a single dataset, so i am not sure it's The Answer™ (although it maybe can be used to develop "The Answer"). However, one thing that the Vietnamese module linked above did right (and i went wrong), is actually using mw:Extension:Timeline (i used divs with position:absolute - quite a disaster). for me personally, timeline has one huge deficiency that tramps (almost) anything else: its RTL support sucks (thogh, maybe Lua can help even here? i'll have to ponder it a bit). i am not all that familiar with the "Timeline" syntax, but it may actually be better.

So next mission is to develop a line-graph using the timeline syntax.

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

Hmmm. I was actually hoping that your next project would be developing a set of Lua modules to make the EasyTimeline extension obsolete. I've always found its output to be pretty awful (ugly rasterized image). --MZMcBride (talk) 02:05, 1 April 2013 (UTC)[reply]

Actually, Thời biểu dân số supports any arbitrary years (even BC), as seen at vi:Bản mẫu:Thời biểu dân số#Thành phố New York. I brought it up because it allows you to enter each data point as | yyyy = nnnn, so editors don't have to learn a special syntax. But obviously you're thinking about broader charting needs, and I would welcome any effort to obsolete EasyTimeline, because its un-antialiased fonts are hideous. – Minh Nguyễn (talk, contribs) 06:31, 2 April 2013 (UTC)[reply]

it's understood that it can support any year range,but it's still asingle data set. It can't show, for instance, life expectancy vs. Average weight, or crop size vs. Agriculture area, let alone three or four different variables. קיפודנחש (aka kipod) (talk) 12:39, 2 April 2013 (UTC)[reply]

It would be helpful to have a right align thumbnail option as well as a caption parameter. --JFH (talk) 20:06, 27 April 2013 (UTC)[reply]

if you mean containing the whole thing in a right-aligned thumb, i think it's better to do it in a template that uses the module, no? i think that in enwiki the consensus is not to use modules directly in articles and always pipe it through templates, so it makes more sense to me to leave all the enveloping of the actual chart to the template.

if you think it's useful, we can maybe add two new optional parameters for "class" and "style" for the outermost div containing the whole shebang. i'm not so sure about "caption", mainly because it's not clear to me where and how this optional caption should be displayed.

either way, if you can be more specific, neither of these is out of the question. peace - קיפודנחש (aka kipod) (talk) 23:06, 27 April 2013 (UTC)[reply]

I don't really know how these things work. I suppose I would like a template that uses this module to create something like template:pie chart. The problem with that template is that everything has to add up to 100. --JFH (talk) 13:16, 28 April 2013 (UTC)[reply]

you are correct. {{pie chart}} has several additional limitations which this module overcomes: there is a hard-coded limit to the number of slices (currently 10. it would be easy enough to raise it, e.g. to 15, but limitation of template syntax basically forces a hard coded limit). there is no "hint" (or "tooltip") on the slices, and there is no convenient way to introduce units to the legends.

it should be pretty easy to wrap all this in a template, and if nobody else does it, maybe i will, one of these days...

peace - קיפודנחש (aka kipod) (talk) 17:08, 28 April 2013 (UTC)[reply]

Can the 'Y' axis maximum be controlled in a stacked bar?

For instance, see User:Begoon/sandbox/casualties, where the 3rd chart (Total fatalities) has a large amount of "dead space" where it extends to 15,000,000 when 12,500,000 would be ample? I don't really understand why it does that, or if I can prevent it. Thanks. Begoon ^talk 04:00, 27 June 2013 (UTC)[reply]

it's always tricky to select a "round" number to serve as top y. i think anywhere between 1 and 1.5 (or 10 and 15, or 100 and 150 etc.) will use 1.5. the problem here is not just finding the appropriate top value, but also selecting the other y legends: for instance, if we would have selected 13 (or 13 million, for that matter), marking all the values of 1,2,3...12,13 would create too many marks, but nothing else seems very appropriate.

i guess i could teach the module to accept the y-legend values manually, so the editor will be able to force values when the current logic of the module does not produce good results, but this won't happen before the end of the week. peace - קיפודנחש (aka kipod) (talk) 12:52, 27 June 2013 (UTC)[reply]

Yeah, I know - I've done a fair few PHP routines to generate charts from SQL databases dynamically on websites I maintain (using things like flashchart). It's a pig to code for when the ranges can be anything from 1 to a zillion without getting odd division markers. No big thing, it's ok as it is really, and that's a prototype with imaginary data - so the final thing might use luckier numbers when I plug them in.

I'm also interested in the question above about thumbnailing. The charts are too big to include in full on the article page, so there'll be a separate chart page. At the moment I'm even thinking I might need to use an image screenshot in the article to link to the page with the full chart, which is OK here, because the data isn't likely to change - but not an ideal way of doing it if the data is regularly updated, because you'd need to update a new thumbnail image each time too. Thanks for the quick reply. Begoon ^talk 13:27, 27 June 2013 (UTC)[reply]

as the charts generated by this module are not images, proper "thumbnailing" will not work.

however, playing with "height" and "width" for the whole chart will produce smaller (or larger) versions. one drawback is that the legends text will still show at normal size, which might cause problems, like overlapping legends and such. maybe it should be possible to embed the whole chart inside a "div" with "style='font-size:50%;' " or somesuch:

also, note that the module will refuse to draw a chart if either height or width are less than 200 (i guess this could be changed...). total result is still somewhat larger than what you would normally call a "thumbnail". i also never found a good way to place the group legends - whatever i tried, i never found a trick to make them appear in the "right place" for all charts - if it works well with one chart, it doesn't with another. the compromise was to place them a bit far away - too far for most cases really, but if i place them closer they sometime overlap with the horizontal legends, and i did not find a good way to make it intelligent. (anyone is welcome to improve it).

peace - קיפודנחש (aka kipod) (talk) 14:11, 27 June 2013 (UTC)[reply]

That's very good. I played with something similar, but the font-size and overlap was the killer - never even thought of font-size:x% (duh...). I might be able to make that work. Thanks. The pseudo-thumbnail might not need group legends I suppose. How about an option to not display them "group names=none". Then we could drop coloured boxes/text in the template like:  Blue  and  Gold  if the position was awful - see above ? Begoon ^talk 14:25, 27 June 2013 (UTC)[reply]

Or, I guess I could cheat with height:220px; overflow:hidden; :

Begoon ^talk 15:00, 27 June 2013 (UTC)[reply]

seems workable. maybe i'll add "hide group names" parameter (i prefer it on "group names=none") later. for now, i think it can work. i am not familiar the with {{rbox}} you used - it seems that it has some undesired side effect (making the group legend a link?), but on the other hand, it seem you are not familiar with {{Spaces}}, so i guess we are even... ;) also, you might want to try embedding the whole thing inside {{Image frame}}.

קיפודנחש (aka kipod) (talk) 16:51, 27 June 2013 (UTC)[reply]

That, sir, is magnificent. I was just going to give it a border, but {{Image frame}} is perfect. Thanks for all the help. I've already got the individual chart templates set up, and they transclude data from a data template page, by section, so all I need do is copy the chart templates to Template name(s) thumbnail and add the formatting. Happy now. Great module, by the way, ideal for this job, in which there will probably be some pies too. Cheers. Begoon ^talk 17:19, 27 June 2013 (UTC)[reply]

maybe it would be better not to copy the data, but rather make the "height" and "width" parameters to your template, and then you can just use it (inside the envelope that thumbinize it) instead of copying the whole thing and tweaking just 2 fields. of course, it is very much possible i just did not fully understand what you said, and this is what you are doing anyway... maybe i just got hooked up on the fact you used the word "copy". peace - קיפודנחש (aka kipod) (talk) 18:41, 27 June 2013 (UTC)[reply]

Yes, I realised that last night after typing that. No point at all in trying to maintain 2 sets of template code, I was thinking (badly) out loud... Thanks again. Begoon ^talk 04:06, 28 June 2013 (UTC)[reply]

so i taught chart 2 new tricks: "tooltip value accumulation": this has effect only with "stack", and will cause the tooltip value to display the accumulation of all the block up to the current (including), and "hide group legends" which prevent displaying the group legends below the chart (the 2nd one works for pie chart also). peace - קיפודנחש (aka kipod) (talk) 21:30, 28 June 2013 (UTC)[reply]

Excellent - that's really cool. Both of those were things I was "working around", and now I don't need to. You can take a look at User:Begoon/sandbox/casualties, and the templates it uses if you're interested - but now, thanks to your hard work, I can simplify them a bit. Thanks for letting me know, and thanks for all of your work with Module:Chart which I think is a great addition to the wiki. Cheers. Begoon ^talk 01:51, 29 June 2013 (UTC)[reply]

@ קיפודנחש: One small problem, I think. I'm trying to use |hide group legends = {{#if:{{{hide group legends|}}}|{{{hide group legends}}}|false}}, and I'm pretty sure I'm passing true/false correctly - but it seems once you even specify the parameter at all it evaluates as true, and hides them, even if blank or false ? Or, I'm screwing up and tested it wrong, which is equally possible...

(tooltip value accumulation seems to behave the same, now I look - didn't notice that because I always pass 'true' to that) Begoon ^talk 05:04, 29 June 2013 (UTC)[reply]

See this:

{{ #invoke:Chart | bar chart
| height = 250
| width = 300
| stack = 1
| group 1 = 40 : 50 : 60 : 20
| group 2 = 20 : 60 : 12 : 44
| group 3 = 55 : 14 : 33 : 5
| colors = green : yellow : orange
| group names = Apple : Banana : Orange
| units suffix = Kg
| x legends = Before : During : After : Post mortem
| hide group legends =
| tooltip value accumulation = 
}}

you are absolutely correct when you note that the template does not care if you give it a value of "true", "false", "17" or "bla bla bla" - giving these parameters any value at all means "yes". originally, it was "param exists/param does not exist" logic, and did not pay special attention to test for "blank" value, which meant that blank was also treated as "true".

this was silly of me, because it makes controlling the bahavior through a parameter to the calling template much more complicated (i am not even sure it it's possible). so i tamed it a little bit to take a blank as "no". i also odified the test above, to demonstrate. any non-blank value still neams "yes", even if it's "false" or "no". peace - קיפודנחש (aka kipod) (talk) 13:44, 29 June 2013 (UTC)[reply]

That works great - thanks again! Passing a blank for "false" is no problem, and does the job perfectly well. The added functionality to do this tooltip accumulation saves a lot of pre-calculation, or maths in the chart template, and means I can use the default groupname:value tooltips instead of building them and passing them through - very useful. Cheers. Begoon ^talk 15:33, 29 June 2013 (UTC)[reply]

• Please add an option for this. It's silly to have percentages sum to 150 like here. Someone not using his real name (talk) 14:34, 14 December 2013 (UTC)[reply]
• Also, the option to display the legend as a gradient (instead of bits all over the place) would also be nice. Someone not using his real name (talk) 14:37, 14 December 2013 (UTC)[reply]

Hi. Currently the module visualizes units only as tool-tips. is it possible to show the units in the chart (e.g. Y axis in case of the bar chart)? --Haithams (talk) 00:51, 7 November 2013 (UTC)[reply]

there are 2 answers here: the first is that the source for this module is free, and anyone who wishes to improve it can do so. however, the darker side is the fact that some 6 months or so after i created the module, a whooping number of 9 articles use it, so the motivation of investing much more time and effort in this module is not huge. קיפודנחש (aka kipod) (talk) 04:11, 7 November 2013 (UTC)[reply]

In fact, I'm surprised to know that such a nice module is not as widely used as it should be. FYI, I copied it to metawiki, and I'm starting some efforts to encourage people use it in their reports ... etc please see here. I would love to improve on the it, but unfortunately I don't have yet enough lua experience to deal with such a complicated module. Perhaps some hints might help! --Haithams (talk) 22:03, 7 November 2013 (UTC)[reply]

There is a discussion involving this module at Wikipedia:Village pump (technical)/Archive 121#New column graphs on WP:Wikipedia with dislocated axis labels, regarding a difficulty with its use on our article about Wikipedia. – PartTimeGnome (talk | contribs) 01:16, 29 December 2013 (UTC)[reply]

The first entry in the group key is not aligned to the others. On the example shown here "Apple" is higher up than the others. MRSC (talk) 17:30, 24 February 2014 (UTC)[reply]

@MRSC: i believe this has to do with the way the browser displays lists in columns. i would venture a guess you are using google chrome (try to see if same problem exists with ff, ie or opera)... i think there is a problem in the list columns rendering in this browser. i will try to file in a bug report for google chrome. peace - קיפודנחש (aka kipod) (talk) 18:00, 24 February 2014 (UTC)[reply]

Bingo! Yes. It renders fine in IE11. Not switching from Chrome, though. Thanks. MRSC (talk) 18:12, 24 February 2014 (UTC)[reply]

Shouldn't this (sub)module be loaded using mw.loadData instead of require? Helder.wiki 15:38, 28 April 2014 (UTC)[reply]

in principle, i think yes. in practice, it doesn't really matter. this module have been there for years, and is used in < 30 articles, and i did not find an article containing more than one chart (did not go through *all* 22 articles using it). feel free to make the modification, though. peace - קיפודנחש (aka kipod) (talk) 00:23, 29 April 2014 (UTC)[reply]

Hi,

I'm wondering if there is any chance of adding a line chart option to this script.

Thanks in advance. 41.138.237.169 (talk) 08:21, 19 September 2014 (UTC)[reply]

is there something wrong with Template:Line chart? Frietjes (talk) 14:01, 20 September 2014 (UTC)[reply]

@Frietjes: unfortunately, yes. this template is very impressive, but the limitations of templating system makes it difficult to use: specifically having to pass the parameters as "S12V37 = 44" makes it not editor-friendly. Lua can help alleviate this difficulty - see how more convenient it is to fill in the values for this module ( 44 : 46 : 48 : 12 vs. "S02V01 = 44 | S02V02 = 46 | S02V03 = 48 | S02V04 = 12") the module even lets you copy values almost directly from a spreadsheet (you'll need to "export" it to CSV format), simply by setting the "delimiter" to comma. please see Wikipedia:Lua requests#overhaul Module:Chart. also, the template code is so complex that it's practically unmaintainable - for instance, see this attempt, while the module doesn't really care: the same code handles a single data series with 3 values, or 57 series with 82 values each. peace - קיפודנחש (aka kipod) (talk) 23:02, 22 September 2014 (UTC)[reply]

Now there is: it was killed. Fortunately survived by {{Graph}}, which does line charts too. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 01:03, 20 May 2021 (UTC)[reply]

These are really great functions. But I do have a problem with the legend area:

• for pie chart, the whole legend area is limited to the size of the pie, and changing it is only possible through |radius=. In addition, long texts don't wrap well. Take a look here – the text is at 88% size, and the radius is increased to 110 from normal 105. Or here where it's normal size but wraps. Wraps badly. Is there any possibility of parameterising the legend area, or forming it into a table?
• for (stacked) bar chart, there is a lot of white space to the left of the y-axis, and between the x-axis and the actual legend. see here. Can something be done about that? Also, the graphic is tight against the right edge of its container, and doesn't seem to want to shift.

Unbuttered parsnip (talk) mytime= Tue 21:04, wikitime= 13:04, 4 November 2014 (UTC)[reply]

the gap between the chart and the legend, comes from the chartHeight, which in that case is set to be 80 less than the height. some positive value is needed here to prevent the xaxis labels from overlapping the legend, but it could probably be variable. I put a simple hack in the sandbox which allows for some variability. Frietjes (talk) 19:43, 4 November 2014 (UTC)[reply]

the reason for the large gap (same goes for the one to the left of the Y axis) is that the legend can wrap, and the module does not really know if it will or won't, so i left (if i remember correctly) about 3 lines worth of gap for wrapping. similarly, the module has hard time calculating how many pixels do the Y-legends occupy.

it makes sense to allow this to be fed in as optional parameters, but some caution should be used, as this may be browser dependent, so the editor may be perfectly happy with the result, but it will still like crap for some readers, possibly having x-axis legends overlap the group legends, or y-axis legends either overflow to the left, or get its significant part truncated (so "1,000,000", "1,500,000" and "2,000,000" all get truncated to "00,000").

this is an in-built weakness of this way of plotting charts - the module has to use "absolute" positioning of various things (such as the bars, the axes, and the legends), but does not have the intelligence (or knowledge) the browser has regarding physical sizes of text strings.

i think the idea behind this module is a good one, but i'm not too happy with the implementation: it would have been better to consume the parameters in a similar way to this module, which i think is more convenient and natural than most "chart" templates, and then translate it to Extension:EasyTimeline construct. this may not be feasible for the piechart (easytimeline does not support piechart, even though the plotting software behind it does), but at least for bar chart i think easytimeline is better choice than the way the chart is built currently. see Wikipedia:Lua requests#overhaul Module:Chart. peace - קיפודנחש (aka kipod) (talk) 20:40, 4 November 2014 (UTC)[reply]

I have tried to import this module and import it in Wikidata, but somehow, the pie chart does not work in Wikidata. See d:User:Zolo/Wikipedia content. When previewed in en.wikipedia, the page shows correctly, but on Wikidata, the pie pieces are wrongly sized. Can that be a CSS issue or something ? --Zolo (talk) 10:20, 2 June 2015 (UTC)[reply]

There is a new tool at mw:Extension:Graph that can generate attractive graphs—it should be already available at Wikidata. I'm just letting you know about the extension because it has great potential, but I think you would need to produce about 100 graphs to make figuring out how to use it worthwhile. Johnuniq (talk) 12:00, 2 June 2015 (UTC)[reply]

Ok thanks, I'll try to have a look at it. Actually, as far as my immediate issue is concerned it was just because it needed the "transborder" class, I could have look better before asking.. --Zolo (talk) 12:33, 2 June 2015 (UTC)[reply]

@Zolo: using the graph tag is probably the better course of action, but in the meantime, i looked in d:User:Zolo/Wikipedia content, and did not understand the problem. what do you mean "pie pieces are wrongly sized"? what do you expect to see, and what do you see? peace - קיפודנחש (aka kipod) (talk) 17:36, 3 June 2015 (UTC)[reply]

@קיפודנחש: without the "transborder" class in the CSS, pie charts were odd-shaped, with broken lines. It works now, thanks. --Zolo (talk) 10:57, 8 June 2015 (UTC)[reply]

I've used the bar chart version to nice effect (after careful sizing of width and height). But quite some time later I was horrified to see the dreadful presentation on mobile Wikipedia in a high usage article, see here. The x legends are presented vertically rather than horiz, and overlap the article text - so the legend is unreadable and the article text messed up. Can anyone suggest a fix? Otherwise I think I will have no choice but to go back to less flexible .png charts. Thanks. Rwendland (talk) 16:02, 26 July 2016 (UTC)[reply]

Rwendland, try asking at WP:VPT. there are some CSS experts who could probably help. Frietjes (talk) 15:04, 9 September 2016 (UTC)[reply]

This is discussed at Wikipedia:Village pump (technical)##invole:Chart looks terrible in mobile Wikipedia. By the way, "Should be exatly" should be "Should be exactly". PrimeHunter (talk) 11:39, 17 May 2017 (UTC)[reply]

In the docs, it says "x legends" supports wikicode such as links to internal pages. But when I use a legend like "User:AbdealiJK/some/page" it things the color character ":" means that the next legend has started. And this gives me a lisp error saying: X legends expect N values only. How do I add links with a colon ? I tried escaping it with \ and also surrounding the wikicode with double quotes, neither worked.

--AbdealiJK (talk) 11:18, 11 August 2016 (UTC)[reply]

1. this module was created long before the graph extension was added to WP. i strongly recommend to switch from using this module to the more "modern" use of the graph extension. there are several modules and templates that help using it, such that it's as easy, if not easier, to create graphs and charts than with this module, and it's "the right thing to do" (tm).
2. however, this module solves this specific problem by allowing you to use an alternative delimiter: pass a "delimiter" parameter which does not appear in any of the values. it can be as simple as :: instead of : , or practically anything else - you can use &, *, #, the word "DELIM", the Arabic letter ث, the Khmer character ឃ - whatever your heart desires.

HTH. peace - קיפודנחש (aka kipod) (talk) 18:05, 11 August 2016 (UTC)[reply]

I was looking at Ariane 5#Statistics and thought a dot plot-like graph would be more appropriate (very few units). — Dispenser 01:13, 2 February 2017 (UTC)[reply]

The bar graphs should include a border. This would make it work with the Firefox extension Blank Your Monitor and improve printing where background-color is removed (lots of websites were white-on-black 20 years ago). — Dispenser 01:20, 2 February 2017 (UTC)[reply]

Firefox/Pale Moon will override authored colors when using High Contrast themes. Colors options dialogue. — Dispenser 16:05, 29 June 2017 (UTC)[reply]

Could we get rid of the drop shadows? They make the charts look so Microsoft Excel 95. Kaldari (talk) 07:16, 23 February 2017 (UTC)[reply]

@Kaldari: K. also, feel free tomake any other changes you see fit. peace - קיפודנחש (aka kipod) (talk) 15:33, 24 February 2017 (UTC)[reply]

I've reverted it since it made the bad printing situation (browser hide background colors to save ink) even worse. — Dispenser 03:08, 4 March 2017 (UTC)[reply]

I've added a 1px border (should help with accessibility) and force background-color printing on Safari/Chrome. — Dispenser 19:56, 4 March 2017 (UTC)[reply]

Thanks for adding the border. It looks like that alleviates the need for the drop shadow. Also, I tried various charts under Blank Your Monitor and it looks like the drop shadow is invisible when the monitor is blanked via BYM anyway (and unfortunately all the color data is lost). One other issue I noticed with the drop shadows is that the renderer creates a drop shadow even when there isn't a bar (i.e. the value is 0), so it's just a shadow of nothing. See Exploration of Mars#Yearly statistics for example. Kaldari (talk) 09:11, 11 March 2017 (UTC)[reply]

Feature request: influencing the Y scale.

See List of Proton launches. The chart is an integer count of rocket launches, but the Y scale puts tick marks and labels at a useless “2.5” interval. It would be nice to have any way at all to influence the Y scale, by setting some factor. For example, any one of these might be helpful:

• y interval
• y no. of subdivisions
• y no. secondary subdivisions (tick marks without a label)
• y max
• y integers only

 —Michael Z. 2017-03-30 15:07 z

+1 for this request, especially forcing integers. — JFG ^talk 00:51, 19 August 2017 (UTC)[reply]

Mzajac, try |y tick marks=5 or some other positive integer value. Frietjes (talk) 20:06, 5 June 2019 (UTC)[reply]

• "y tick marks" works to avoid decimal intervals (once you know it), but can need changing as the numbers change.

Currently the y axis jumps from 10->15, 20->30, and 100->150 as numbers increase. 10->12->15 & 20->24->30 etc would be nice.

y_interval would solve most problems and be easier to manage. Otherwise y_integers (rounding interval up ?) would help.

- Rod57 (talk) 18:07, 3 January 2024 (UTC)[reply]

See List_of_Falcon_9_and_Falcon_Heavy_launches#Launch_statistics for an example of this. There seems to be a bug here that displays a single line of colour even when the value input is zero for the given field. This makes the Charts look rather amaturish and unprofessional. Is there an easy fix for this or not? — InsertCleverPhraseHere 07:30, 26 June 2017 (UTC)[reply]

thanks. Fixed. קיפודנחש (aka kipod) (talk) 23:34, 28 June 2017 (UTC)[reply]

Nice work! — InsertCleverPhraseHere 00:12, 29 June 2017 (UTC)[reply]

This chart thing needs a title parameter. There is no way to add a title to the charts!--200.223.199.146 (talk) 13:49, 27 June 2017 (UTC)[reply]

there are too many stylistic options/possibilities for title. it's best left to the template invoking this module. peace - קיפודנחש (aka kipod) (talk) 23:35, 28 June 2017 (UTC)[reply]

Bars are not drawn properly when a chart includes negative values. Example, trying to graph the GDP growth for the Economy of Russia article:

@קיפודנחש: Could you possibly take a look? — JFG ^talk 00:44, 19 August 2017 (UTC)[reply]

@JFG: sorry. currently this module does not support bar-graphs with base (i.e., y-value of x-axis) other than 0, or negative y-values. i will repeat what i wrote above: this module was written before the "graph" extension was included in wikipedia (maybe even before the extension was written), so it was justified. nowadays, when we have graph extension, i do not see any justification of using it - it is here b/c some articles are using it, but any new graph should use the graph extension (see Module:Graph). of course, if someone chooses to further enhance this module they are welcome, but i do not think i will do any more work on it, short of fixing clear and blatant bugs. i do not consider this deficiency (not supporting negative values) to qualify.

it is somewhat unfortunate that the "graph" module documentation is lacking, and has no examples, but it's not enough to justify using this obsolete module. קיפודנחש (aka kipod) (talk) 19:58, 21 August 2017 (UTC)[reply]

(added later): actually, there are some nice documentation and examples in Template:Graph:Chart, so maybe my criticism of the documentation in the module is not justified. קיפודנחש (aka kipod) (talk) 20:12, 21 August 2017 (UTC)[reply]

Well, I've used both, and I much prefer this module to the standard graph extension. The syntax is much simpler to handle for updates, and the output quality is better in my opinion. I'd be glad to help fixing some issues. — JFG ^talk 21:04, 21 August 2017 (UTC)[reply]

See List_of_Falcon_9_and_Falcon_Heavy_launches#Launch_statistics. It is very odd that the Y axis displays numbers such as 2.5 and 7.5 in the Y axis, when you can't have half of a launch. I have been struggling to find a way to fix this... is there a way to force whole numbers, or else specify the scale on an axis for a bar chart? — InsertCleverPhraseHere ^{(or here)} 10:54, 20 August 2017 (UTC)[reply]

Feature was requested above at #Y scale. — JFG ^talk 13:47, 20 August 2017 (UTC)[reply]

Insertcleverphrasehere and JFG, try |y tick marks=5 or some other positive integer value. Frietjes (talk) 20:05, 5 June 2019 (UTC)[reply]

Many of the graphs are larger than the available space on mobile. To rectify this, we advise adding a noresize class to the element to add horizontal scrolling.

It's not perfect but it will make the chart readable on mobile. Please let me know if you have any further questions. Jdlrobson (talk) 21:18, 27 November 2017 (UTC)[reply]

Jdlrobson (talk) 21:18, 27 November 2017 (UTC)[reply]

Does this chart offer the option to determine the bar width like this one? Gun Powder Ma (talk) 01:50, 15 December 2017 (UTC)[reply]

afaict, the bar width is semi-automatic depending on the number of bars and the overall width of the chart. Frietjes (talk) 18:34, 15 December 2017 (UTC)[reply]

We need a vertical bar chart that can go negative.

Wikideas1 (talk) 09:29, 13 February 2018 (UTC)[reply]

sorry, there is no active development of this module at this time. if anyone wants to take over, they are more than welcome, but i, as the original developer, am unlikely to add features in the foreseeable future. sorry. peace - קיפודנחש (aka kipod) (talk) 23:51, 13 February 2018 (UTC)[reply]

Hello. I think that, in the case of the bar chart, it would be pretty useful to add the option for drawing an horizontal rule on a specific value. This way, it would be possible to show many values, one for each month of the year, and then add the year's average as a line. Or even add more than one line! --MisterSanderson (talk) 02:58, 2 May 2018 (UTC)[reply]

Hello. I am working on a new version of the module that would solve the problems with the excessive white space. You can check the current progress at Module:Sandbox/Ita140188/chart2. I would really appreciate some feedback! Thanks! --Ita140188 (talk) 09:47, 27 July 2018 (UTC)[reply]

@Ita140188: Thank you very much for this initiative. The output looks much better with legends aligned properly and no waste of space. Super happy you used some of my favorite charts at List of Falcon 9 and Falcon Heavy launches#Launch statistics as examples. — JFG ^talk 12:20, 27 July 2018 (UTC)[reply]

Horizontal space was unnecessary, but I think you should leave some "breathing room" as vertical space. Your current version has the charts glued to the text in section headings. — JFG ^talk 12:22, 27 July 2018 (UTC)[reply]

The next option that would be really useful is to specify the desired min/max values for the y axis. At least the max value. Also, avoid showing half-values on the y axis when listing only integer values in the data (happens quite often in rocket launch graphs with a small number of launches per year). Could auto-detect (hard) or use a new |integer=yes parameter (easy). — JFG ^talk 12:25, 27 July 2018 (UTC)[reply]

thanks for taking the time to improve this (almost) abandoned module. notice that in one of the charts (many blue thin bars), the legends got smooshed. peace - קיפודנחש (aka kipod) (talk) 17:28, 27 July 2018 (UTC)[reply]

Thank you for all the comments and feedback. This is still a work in progress. For now I worked on dynamic sizing of the width of the y axis and the height of x axis so that there is less empty space. Next step is working out the details of alignment etc. Also, for now it only works with one y-axis (since I've noticed the option for multiple axes is rarely used) and there are still problems with some cases such as the thin blue bars chart. I am not planning to work on the pie chart since it already looks ok on this module in my opinion. --Ita140188 (talk) 06:58, 28 July 2018 (UTC)[reply]

Didn't even notice there was an option to list multiple y-axes. Perhaps check if it's ever used before investing time in that. — JFG ^talk 08:26, 28 July 2018 (UTC)[reply]

Update

I solved the main problems with the x-axis labels and made the spacing better. Note that I removed the notch for the x values since most of the time the chart is used with bars that are wide enough to easily understand at which bar the text refers to (this may be added as an automatic feature when bars are too narrow, like in the last example). I also removed the pie chart and the multiple y-axis from the code to keep it simple. Next steps are the possibility of choosing only integers, allowing for negative values, and maybe min/max values. --Ita140188 (talk) 10:10, 29 July 2018 (UTC)[reply]

Very nice, thanks. The ticks on x-axis are often useful, see for example Timeline of spaceflight. Perhaps add ticks only when some x-legends are empty? (They are often skipped for lack of room to display text, and then the tick helps refer to the proper column). — JFG ^talk 10:46, 29 July 2018 (UTC)[reply]

Agree. I am planning to add them as an automatic feature when bars are too narrow (or in any case with skipped values), and also add a parameter to show/hide them manually. I think this is a better solution than making them always appear as there are so many cases where they are not necessary. --Ita140188 (talk) 11:13, 29 July 2018 (UTC)[reply]

Sounds like a good plan. — JFG ^talk 07:27, 30 July 2018 (UTC)[reply]

Also, do you know how to add CSS code to a module (without resorting to clumsy <style> tags in <body> or javascript? Certain behaviors cannot be specified inline, such as ":hover". --Ita140188 (talk) 11:16, 29 July 2018 (UTC)[reply]

With the very newly deployed WP:TemplateStyles, one can use a style sheet in a module/template with frame:extensionTag{ name = 'templatestyles', args = { src = '(css sheet name)'} } Galobtter (pingó mió) 12:07, 29 July 2018 (UTC)[reply]

I'd like to see some more options in the legend, to force single column for example. This would avoid issues like you see with the 'launch sites' graph in the examples, where the vandenberg item wraps over to the next line. — Insertcleverphrasehere ^{(or here)} 12:59, 29 July 2018 (UTC)[reply]

@Galobtter: Thanks a lot. I am not at all familiar with Lua and its integration with Wikipedia (first time I attempt to code in here). I tried to add what you suggested, but nothing really happens, and apparently now the page is in a category "Pages with TemplateStyles errors". Unfortunately I don't know what the error is. I could not make a CSS document as a subpage of the module since it gets interpreted as a Lua module rather than CSS so I had to link User:Ita140188/sandbox/styles.css. Maybe that's the problem. Anyway, if anybody could help, it would be much appreciated! Thanks!! --Ita140188 (talk) 13:06, 29 July 2018 (UTC)[reply]

You need to create the style in a subpage of a template, since only then is would it be created as a "sanitized-css" that <templatestyles>...</templatestyles> can use. Or you can get an admin to make a subpage of the module into a css page. Galobtter (pingó mió) 13:11, 29 July 2018 (UTC)[reply]

@Galobtter: Thanks. Now it makes sense. Can it be any page in the template namespace, or does it need to be a subpage of the template that is calling it? --Ita140188 (talk) 13:15, 29 July 2018 (UTC)[reply]

Any page that ends in ".css" in the template namespace should work Galobtter (pingó mió) 13:17, 29 July 2018 (UTC)[reply]

You can also move a css page created in the template namespace to your userspace and loading that should also work. Galobtter (pingó mió) 13:24, 29 July 2018 (UTC)[reply]

Thanks, apparently they just created a new sandbox for these cases, check Wikipedia talk:TemplateStyles#TemplateStyles in Modules. Now it works! --Ita140188 (talk) 07:36, 30 July 2018 (UTC)[reply]

@Insertcleverphrasehere: Forcing 1 column in the legend can be done easily I think. Other more advanced options are in my opinion unnecessary. One could always disable the legend and make it externally. (trying to keep the module simple) --Ita140188 (talk) 13:08, 29 July 2018 (UTC)[reply]

Update September

Hello Ita140188, I've seen your work until August 6, and it looks to me that you completely fixed the spacing issue for legends, and the integer rounding issue. These features look good to go and replace the module in production. However, the tick marks are missing on tight graphs. Could you restore them? See Module:Sandbox/Ita140188/chart2#Test case for numerous narrow columns. If it's too complex to decide when to place tick marks and when not to, just leave them always on for now, because that's the way those graphs have been displayed for ever; I don't mind losing some vertical pixels for tick marks. When that's done, I think we can publish the update. Then you are apparently still working on some other features (for examples negative vslues or specifying min/max), but those can wait. Let me know what you think. — JFG ^talk 10:39, 5 September 2018 (UTC)[reply]

I am very sorry I put the project on hold since I've been very busy lately. I am planning to continue working on it from next month, I should be able to make a working version by October. The real problem with replacing the current module is that right now people went around the white space by wrapping this module in divs with ad hoc margins. This makes it impossible to just update this module without breaking all the charts. I would suggest creating a new module (Module:Chart2 or similar) and recommending it for future use. With time current instances of the module could be migrated. Also the new module should be tested with different browsers/OS etc. to check for potential problems. --Ita140188 (talk) 04:50, 11 September 2018 (UTC)[reply]

Thanks for the update. I don't think we should introduce another module name just because of margin workarounds that have been used on some pages. Better look at the articles where this happens and remove the workarounds. I can help with that. There are less than 500 uses in articles, so it's manageable. I could start working on this while you're busy elsewhere, if only you could restore the tick marks first. — JFG ^talk 19:48, 19 September 2018 (UTC)[reply]

Latest update

So, over one year late I finally added the x-axis ticks and added back support for pie charts. I think the new version is now ready to replace the current version. Let me know your thoughts. I also came to the idea that adding other more advanced options is a waste of time, since the approach used in this template (working with DIVs) is really not flexible or scalable at all, and Module:Graph should be used in the future. --Ita140188 (talk) 10:21, 12 February 2020 (UTC)[reply]

For some articles like, solar power, wind power and possibly Moore's law which are about things that are growing exponentially and are likely to update every year, you'd probably prefer bar and line charts to have the option of having at least a log y-axis. But this doesn't seem possible right now. GliderMaven (talk) 01:17, 25 August 2018 (UTC)[reply]

cant recall ever seeing a log bar chart. all the log scale graphs i ever saw were line charts, which is not supported by this module. seems like a sensible idea for module:graph, though. peace - קיפודנחש (aka kipod) (talk) 13:49, 25 August 2018 (UTC)[reply]

Semilog graphs are rarer than linear anyway, but for things like yearly production of electrical power, which will change from year to year without anyone doing anything, and where there is underlying exponential growth, then a log bar chart seems to be the correct tool. Spreadsheets and matlab support this. Line charts should be used when there's an explicit connection between the data points, like installed power. GliderMaven (talk) 17:32, 25 August 2018 (UTC)[reply]

I was looking for a template to render a bar chart horizontally. This is sometimes helpful when there are many items to list, so that the chart can be expanded down the page and full item names can be displayed. Unfortunately the available tools are rather poor. I wonder how hard it would be to add a |horizontal=yes parameter to this module, which would flip the y and x axes while keeping the compact syntax for input data, and the handy bar stacking feature. @Ita140188: What do you think? — JFG ^talk 19:37, 24 October 2018 (UTC)[reply]

this may be a good idea, but the answer the question of "how much work", is, unfortunately, "substantial".

large potion of the code in this module went into physical arrangement of the chart, and especially placement and display of the legends, without which the graph is not very useful. horizontal presentation would require writing a set of completely new procs to handle arrangement and legends.

the code used to process the input parameters can be shared (it's shared today between pie and bar), but not much else.

as the original author of this module, let me repeat what i probably said on this page more than once: with the introduction of Template:Graph:Chart, there is little reason to use this module. i wrote it several years before the "Graph" extension was available, and of course, before Module:Graph was available, but they do better job at displaying charts than i did, while introducing more types (line, a and area. it's a shame they did not do scatter too - i think it's useful, and of course, it's a shame they did not do horizontal bar graph...)

peace - קיפודנחש (aka kipod) (talk) 15:36, 25 October 2018 (UTC)[reply]

Someone noted on the editing help page that the scale on List of Proton launches (2010–present) shouldn't be fractional. While the chart is technically correct, it's potentially confusing, since there will never be a fractional launch. Is there way to force the Y axis to be rounded numbers only? TimTempleton ^{(talk) (cont)} 22:28, 4 June 2019 (UTC)[reply]

Timtempleton try |y tick marks=5 or some other value. Frietjes (talk) 20:04, 5 June 2019 (UTC)[reply]

Frietjes 5 worked - there are whole numbers now. Thanks! TimTempleton ^{(talk) (cont)} 20:13, 5 June 2019 (UTC)[reply]

Hello, as discussed in a section above, I have been working on a new version of this module without the extra white space around the chart. You can check the new version at Module:Sandbox/Ita140188/chart2. Should we replace this module with the new version? Please let me know what you think. Thanks! --Ita140188 (talk) 04:43, 15 February 2020 (UTC)[reply]

@Ita140188: thank you for the improvements, but now the "Scale per group" functionality does not seem to work (see in doc page). it did work before your changes. if this isn't used anywhere, it should be removed, at least from the docs, and ideally from the code too.

otherwise (i.e., if it _is_ used), i think you should fix it - it seems that you are the one who broke it... :) peace - קיפודנחש (aka kipod) (talk) 19:49, 18 February 2020 (UTC)[reply]

@קיפודנחש: Hi, I have never seen the option "scale per group" used in an article, and from previous discussions I understood it was never used. This is why I proceeded to ignore the option when changing the module. As you can see from above, my initial idea was to create another module Module:Chart2 so that charts could be migrated if desirable, while keeping the previous functionality intact. Consensus was to instead replace the code. Unfortunately I have no time to put more work on this. However, I have no strong feelings about this change, so if you want to revert it, please go ahead. As for cleaning up the code, it would be helpful if the code was actively maintained, but given that there will probably be close to zero maintenance/improvements I don't think the extra effort to clean up is justified. As you said in a previous comment, I also agree that Module:Graph is the way to go in the future. --Ita140188 (talk) 07:16, 19 February 2020 (UTC)[reply]

@Ita140188: first, there are a few articles that _do_ use "scale per group", and this breaking change left them with borked charts - this needs fixin` (see Special:Search/insource:"scale per group"), and the onus is on whoever introduced the breaking change.

second, the documentation also still speaks of "scale per group": the actual example was purged, but it was done in a half-assed way, and left the section kind of in mutilated state, a senseless sentence, and an invalid section name (section talks about scal per group, and actual content is a chart with dozens of groups, but no "scal per group"). worse yet, the documentation still has this as a valid parameter in the table at the top.

and last, but not least: please note that this module has dozens of interwiki. since i originally wrote it on enwiki (though my "natural habitat is hewiki, really), it's a fair assumption that most copied it from here, and some of the maintainers, might want to keep up to date, and take your improvements. it is important, whenever there is a breaking change (and as it turns out, this _was_ a breaking change, even if it was not intentional), to make it clear, in the talkpage and maybe even as a comment in the module itself or the documentation, so each maintainer that considers upgrading, will know to check first that this deprecated parameter is not used on their wiki, or rather, check if it _is_ used, and make an informed decision whether or not to "get latest".

don't get me wrong - i do not object to your improvements, but the problem with "legacy code", like this, is that breaking changes need to be done carefully and with serious thought (even "planning", god forbid) - specifically, with more care than it was done here: for instance, this discussion would, ideally, take place _before_ the actual change, not after.

peace - קיפודנחש (aka kipod) (talk) 22:58, 19 February 2020 (UTC)[reply]

I completely agree that migration should follow after a wide consensus. As I have no more time to spend fixing the group option, if we decide to migrate, those few examples will likely need to be turned into module:graph or into another form. Updating the documentation does not seem to be a big problem. In the meanwhile, I reverted to the original version. --Ita140188 (talk) 02:05, 20 February 2020 (UTC)[reply]

Apologies for messing up. I tried to get a discussion going on charts and graphs in various places but nobody seemed really interested. In the end I replaced this code as nobody seemed to mind. I only noticed after the fact - when I updated the documentation - that the scale per group feature did not work anymore, so I wrote this into the documentation. I will see if I can find time to learn this language and update this scale per group feature for the new module. It would be a shame if the new version were just lost. KarlFrei (talk) 12:44, 20 February 2020 (UTC)[reply]

See Talk:2020_coronavirus_pandemic_in_Australia#Semilog_graph_option_enabled_for_the_states_graph. The main reason is that not only do many people have difficulties reading graphs, but some of those who can read linear graphs are unfamiliar with loglog or semilog graphs, even though the real world varies a lot on orders of magnitude scales, so the sooner they learn, the more informed people will be about the real world (such as pandemics). Boud (talk) 14:57, 26 March 2020 (UTC)[reply]

With a vertical bar chart (with dates as x values), is there a way to thin out the labelling such that only every n-th item is displayed, or some other way to keep labels from getting printed on top of each other? With large bar charts like these ones, label strings currently flow into each other, at least on my screen, in a way that makes the charts practically unreadable. It would be nicer if we could have just one label per week or something like that. Fut.Perf. ☼ 16:41, 23 August 2020 (UTC)[reply]

RTFM. search "If there are many values, x legends can be diluted by using delimiters with nothing in between:" for an example. peace - קיפודנחש (aka kipod) (talk) 22:05, 27 August 2020 (UTC)[reply]

ah, and at 2nd look, the example you link to does not use this module, it uses the Graph extension, so even though my answer is correct, in principle, it's not relevant to the problem (unless you want to convert the graph to use this module). peace - קיפודנחש (aka kipod) (talk) 23:05, 27 August 2020 (UTC)[reply]

Moved from Module talk:Chart/Default colors

 – * Pppery * _{it has begun...} 00:52, 4 October 2020 (UTC)

When you mousover this table List_of_Falcon_9_and_Falcon_Heavy_launches#Booster_landings for any entry that has [i] entries in them, you get gibberish printed. For example mousing over any of the "Ocean Test Failure" entries in the table, you get this as the highlight text "Ocean test failure?'"`UNIQ--ref-000000CF-QINU`"'?:" and yes there are non-printable characters in there as well. Edit this comment to see them. They are Unicode U+007F. Ergzay (talk) 15:24, 13 May 2021 (UTC)[reply]

I fixed that. Some group names included a reference which becomes a strip marker (WP:UNIQ) when passed to a module. The module has a large number of global variables which need to be investigated and fixed another time. Johnuniq (talk) 01:24, 14 May 2021 (UTC)[reply]

this may be improved in the module, but it's a solvable problem: the module allows defining "tooltip" per bar (see doc), and only when one is not defined, it tries to generate one based on the link or the legend. look for "tooltip" in documentation. not sure why Johnuniq says "The module has a large number of global variables". can you point to a single global variable? not saying there aren't any, but definitely not "large number", and none intended. peace - קיפודנחש (aka kipod) (talk) 22:33, 14 May 2021 (UTC)[reply]

The globals are: addRes + addSlice + analyzeParams + asGroups + barChart + calcHeightLimits + calcHeights + calcx + coordsOfAngle + createImageMap + createSlices + drawChart + drawSingle + drawSlice + drawXlegends + drawYScale + drawbar + extractParams + getArg + groupBounds + i + keyword + pieChart + roundup + sliceStr + testone + tooltip + validate. I could start fixing them but if you don't mind I would also replace the spaces used for indents with tabs as that is style used now. Johnuniq (talk) 23:42, 14 May 2021 (UTC)[reply]

I edited Module:Chart/sandbox, first to use tabs for indents, and second to clean the unintended globals. There is one left that needs fixing, namely sliceStr. Johnuniq (talk) 01:48, 15 May 2021 (UTC)[reply]

I guess that's pretty obvious: it should be slice but I'll leave it for now. Please fix, check my edits, and update the main module. Johnuniq (talk) 01:50, 15 May 2021 (UTC)[reply]

tbh, i did not know that nested functions are global. any non-function global in this module is a bug, and i don't think there are too many (unless i have even more holes in my lua-fu - apparently i do not fully grok "scope" in lua). thanks for the education. peace - קיפודנחש (aka kipod) (talk) 06:02, 15 May 2021 (UTC)[reply]

The way to think of it is that Lua regards the following as equivalent (it defines the first as the second):

function example(x) ... end

example = function (x) ... end

That is part of example being a first-class function. The above defines example as a global variable regardless of where the statement occurs. Johnuniq (talk) 06:43, 15 May 2021 (UTC)[reply]

That would be real game changer for Wikipedia, as charts would be automatically updated when tables received new data. Here is a good example of how to read data from tables. The module could be called with a page name (if not its own), a table id (if not the 1st one), and the columns for labels and values (if not the 1st and 2nd, respectively). It would certainly break if the table is oddly shaped or malformed, but that could be minimised ignoring header rows. This shouldn't be too hard, as this module already converts parameter values into values on tables. Here is my first crack at it. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 01:36, 20 May 2021 (UTC)[reply]

There appears to be a trend towards modules reading the content of a page, then trying to parse the wikitext and doing something with the result. That could be reasonable for something like Wikipedia:User scripts/Most imported scripts (the example given above) but I don't think it's desirable for articles. I have commented on that before and might try to say more but for now I'll just note that IMHO it would be better to have the data stored somewhere (in a module or in Commons structured data) and display the table and the chart from that data. That would be much more efficient and understandable, and would be much less fragile. Johnuniq (talk) 05:16, 20 May 2021 (UTC)[reply]

I also again iterate that this seems like something that is gonna break at some point. Besides, we already have Lua data tables and the Commons Data namespace. Make a template to turn that into a wikitable instead, seems way more efficient to me. —TheDJ (talk • contribs) 07:22, 20 May 2021 (UTC)[reply]

No doubt Wikidata and Commons:Data are the future, but as of now, I don't see data there being updated, do you? Look at commons:Data:Bea.gov/GDP by state.tab, the very first source there on Template:Graph:Stacked: the data is 5 years stale, whereas the data at the List of states and territories of the United States by GDP is freshly updated.

No doubt too that this is a much more fragile solution, yet much more flexible (as is typically the case with... everything in life?). Besides, not every wikitable warrants a database in Wikidata or Commons:Data, yet readers may benefit from seeing its data graphed in the article. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 08:09, 20 May 2021 (UTC)[reply]

i do not think it's a good idea to overload this module with data parsing or harvesting. however, it may be a good idea to export functions to be used by other modules. tbh, this is not even necessary - once you have the data structure, just join the series using the delimiter, and serve it to the existing functions. it's a bit of overhead, and also requires camouflaging as a "frame" (basically a table with one item called "args").

the main thing is that the this module should not be tasked getting the data, and be limited to the presentation side.

write a module to harvest the data, synthesize it with parameters passed by the template(s), package the data series by joining with the delimiter and assign them to appropriate fields in the "args" table, and call this module to produce the chart.

something like so:

-- this code is inside your exported function
local args = {}
-- synthesize args to be passed to the chart, from parameters passed to the module and harvested data
-- hack hack hack
-- "args" is ready
return require('Module:Chart').pieChart({ ['args'] = args } ) -- return chart to page

will be interesting to see something like this in action.

if it makes a big diff for you, it will not be too painful to export "for modules only" function which will take the parameters a native lua table through and through. peace - קיפודנחש (aka kipod) (talk) 00:11, 25 May 2021 (UTC)[reply]

Todah, קיפודנחש. Looks like it'll be a fairly thin wrapper, but... I'm stuck at Lua error in Module:Graph_table at line 15: attempt to call field 'pieChart' (a nil value).. What am I doing wrong? — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 06:13, 25 May 2021 (UTC)[reply]

I fixed Module:Graph table but now User:Guarapiranga/sandbox/5 has another error. Regardless of this module, I have not seen any support either here or where it was raised at WP:VPT for the idea of having a module parse the wikitext of a page to extract data from a wikitable. I wouldn't put much effort into that approach. Johnuniq (talk) 07:34, 25 May 2021 (UTC)[reply]

Thanks, Johnuniq. I fixed the regex, as you recommended, and it's pulling the data, but it seems this module needs each data point on a different line(?):

addSlice( i, mw.ustring.match( slice, '^%(%s*(.-)%s*%)$' ) )

But what's the deal with ^ and $, if Scribunto manual says that a '^' at the start of a pattern is not magic, as this would prevent the iteration, and that it is treated as a literal character? Is that why it uses mw.ustring instead? The ustring patterns section doesn't say anything about mw.ustring extending the controls to ^ and $. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 16:16, 25 May 2021 (UTC)[reply]

Before the addSlice(...) code you posted above is for slice in.... The for loop gets each "(...)" substring (any text in balanced parentheses) and passes it to addSlice. The ^ and $ you mention are redundant as slice will start and end with parentheses. However, they work because it's match, not gmatch. The code uses mw.ustring but it does not need to with the regex that it uses. Following that requires a bit of experience with UTF-8 but, in brief, it's only when you have a regex like [x◆]*, and probably some others, (with a Unicode character) that mw.ustring is needed. Scribunto implements mw.ustring by using Lua to replace the regex library which is a breathtaking accomplishment but which makes it slower than using plain strings. When I've got some time in a few hours I'll look at what's happening, bearing in mind that I still do not think parsing wikitext in Lua is sustainable. Johnuniq (talk) 22:44, 25 May 2021 (UTC)[reply]

Thanks, Johnuniq.

The code uses mw.ustring but it does not need to with the regex that it uses. ... Scribunto implements mw.ustring by using Lua to replace the regex library which is a breathtaking accomplishment but which makes it slower than using plain strings.

So I went ahead and created a copy of Module:Chart in its sandbox with string instead of mw.ustring. At least in the doc examples, it doesn't break. Should it be 'downgraded'? — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 23:00, 25 May 2021 (UTC)[reply]

Testing in Module:Graph table showed that Module:Chart requires a proper frame because it calls frame:preprocess(...). Adding that makes the chart work. The regex does not handle the 6.4e5 notation. Regarding removing mw.ustring from Module:Chart: The problem is that who ever does that is volunteering to maintain the module and I don't want to take that on, however I fixed Module:Chart/sandbox by using tab indents and removing unintended globals (including a couple of typos) and removing a couple of unused items. I checked the removal of mw.ustring and it is good although the getArg function could fail if it were ever used in a vastly different way from how it is used now. After testing and more thought, it would be ok to update Module:Chart because I don't want to fix the sandbox again. Johnuniq (talk) 05:20, 26 May 2021 (UTC)[reply]

Awesome! It lives!! That's proof of concept right there. Thanks, Johnuniq.

Testing in Module:Graph table showed that Module:Chart requires a proper frame because it calls frame:preprocess(...). Adding that makes the chart work.

No idea what that means. Totally above my pay grade. Would never have guessed it.

The regex does not handle the 6.4e5 notation.

Yeah, I expected that. Fixed

After testing and more thought, it would be ok to update Module:Chart because I don't want to fix the sandbox again.

Will do. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 (talk) 12:43, 26 May 2021 (UTC)[reply]

 Done — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 ☎ 04:05, 2 June 2021 (UTC)[reply]

If you look at bar chart in https://en.wikipedia.org/wiki/History_of_Tesla,_Inc.#Timeline_of_production_and_sales there are two types of visual glitches - one can be seen in Q3 & 4Q 2015 bars, where the grey part of the bar is both too thick (at least in Q3's case since on 6 cars ot of over 11.5k were Model Xs, so the grey part should have been only ~1 pixel thick) and in the wrong place (in looks the be inside the black part instead of on top of it) and in Q4 2018 bar there's a gap between grey and yellow parts.

Or at least it looks like https://i.imgur.com/FMFjYv6.jpg to me on my Android tablet.

Hello!

Can someone help me with the way the chart here is suddenly behaving?

I was guided here after this discussion. - Klein Muçi (talk) 22:34, 13 October 2021 (UTC)[reply]

Fixed via Special:Diff/1050400291 * Pppery * _{it has begun...} 15:57, 17 October 2021 (UTC)[reply]

As you can see in the example at right, the Chart module adds excessive whitespace below the chart when there is no legend. Could someone fix this? Nosferattus (talk) 01:13, 8 March 2024 (UTC)[reply]

I've just come across this module via the WikiProject article. Is there currently a way of adding a label to the x-axis in a line below the x-legends? In the Nuclear power example above, it would probably just say "Year" but it can be useful where the overall meaning of the x-legends is open to interpretation. I couldn't find it in the code but maybe there's currently a way of doing it with a linebreak or something. Thanks --Northernhenge (talk) 10:07, 4 April 2024 (UTC)[reply]

Hard-coding the legend columns width (column-width:12em) is not a great idea and doesn't allow using long group names (like here, where the legend had to be redone manually under the chart), while at the same time producing too few unnecessarily wide columns (like in the "basic" example, where it would be much better to show all 3 names in a single row). Please change the columns to automatic or allow overriding the column width or count. — Mikhail Ryazanov (talk) 03:11, 23 June 2024 (UTC)[reply]

hey, did anyone look at this thing in dark mode?

are there any issues with colors?

i noticed that the frwiki version added some code which i think solves some issues in dark mode, though i am not certain. peace. קיפודנחש (aka kipod) (talk) 05:08, 22 July 2024 (UTC)[reply]

one thing i noticed is that pie charts are embedded in white square in dark mode.

this comes from an svg file: File:Circle frame.svg (it's the square with a round hole, making the pie chart a pie). it defines its color as #FFF, and the circle color as #000. maybe some dark mode wizard can advise - i hope it's possible to use dark-mode aware svg with the same shape. קיפודנחש (aka kipod) (talk) 05:51, 22 July 2024 (UTC)[reply]

There seem to be a huge number of errors on articles caused by this module — Martin (MSGJ · talk) 09:09, 20 December 2024 (UTC)[reply]

I suspect that recent edits at {{PH poverty incidence}} by PH 0447 have led to problems such as at Aborlan#Economy which currently shows "Lua error in Module:Chart at line 301: bad argument #7 to 'max' (number expected, got string)." It is sucking in who-knows-what from Wikidata. Johnuniq (talk) 09:31, 20 December 2024 (UTC)[reply]

The pre-PH 0447 version is also showing a script error — Martin (MSGJ · talk) 09:35, 20 December 2024 (UTC)[reply]

But it doesn't at Aborlan. That's not conclusive but is a good clue. Johnuniq (talk) 09:38, 20 December 2024 (UTC)[reply]

Okay I have reverted PH 0447's edits to that template. Hopefully they can help to sort this out — Martin (MSGJ · talk) 09:41, 20 December 2024 (UTC)[reply]

my $.02: the poverty incidents template sucks stuff directly from wikidata and pass it to chart module without any test/sanitation. Edits on wd which do not adhere to what chart expect can trigger "lua errors" pointing to chart module when the real culprit(s) are either wd or the template. One contrived example is like so: the default delimiter this module expects is colon. The template does not override it, takes labels "as is" from wd and passes them to the module. If such label for some wd item contains a colon, the module will interpret it as a delimiter, which may trigger lua error.

Templates which suck data from wd should sanitize it before sending it to this (or any other) module. When they fail to do so and errors pop up, these errors will point to the module, even though it's really innocent, and the blame should be placed elsewhere.

Peace. קיפודנחש (aka kipod) (talk) 21:00, 21 December 2024 (UTC)[reply]

Whoops. Sorry my bad. I was trying to put a new column since we already have a data for 2023. Apologies to all editors if it causes errors. PH 0447 (talk) 02:46, 24 December 2024 (UTC)[reply]

The past two runs of Special:WantedCategories have featured a redlinked Category:Pages using the Chart extension with rendering errors that I cannot recall ever having seen there before — so I don't know if it's a genuinely new thing that this module only recently got coded to start generating, or an old thing that just never showed up because this module never saw errors before. (I suspect the former, because the above discussion does remind me of a different type of redlinked error category that I used to see frequently but haven't recently, but I don't know enough about the module to be absolutely certain of that.)

But either way, it needs to be created if it's a category you want to exist, or killed off so that it never happens at all if you don't want it to exist, because templates and modules shouldn't be autogenerating redlinked categories. So could you either create it or edit the module to prevent it? Thanks. Bearcat (talk) 15:53, 4 July 2025 (UTC)[reply]

Created. This actually comes from mw:Extension:Chart, not the module, but you had no good reason to know that. * Pppery * _{it has begun...} 19:11, 7 July 2025 (UTC)[reply]

The pie chart appears to have a white square in the background, which is noticeable against the green of the documentation. Could this be removed to make the background appropriately transparent? Sdkb ^talk 05:24, 28 November 2025 (UTC)[reply]

unfortunately, i'm afraid this is not possible, at least not without some serious operation.

explain: the "background" is not merely a background. it's an opaque image with a transparent circular "hole" in the middle, which is what's makes it a pie. without this "background", you'd see a rectangular image, with the "slices" of the pie continuing all the way to the edges of the square.

now, this may be solved with some creative use of SVG - make this "background" an SVG instead of PNG image, still with transparent hole in the middle, and convince the opaque part to assume a color passed as parameter.

pretty recently mediawiki / scribuntu added ability to generate SVG and add it to the page, so it may be possible, but TBH, if I would have started playing with SVG, i'd go all the way and create a whole new module to create the graph using SVG. personally I have no intention of doing something like this.

tl:dr: no, the white background cannot be removed.

peace. קיפודנחש (aka kipod) (talk) 19:33, 28 November 2025 (UTC)[reply]

on 2nd look (it's been a while since I created this module, I hope i'm forgiven): the "background" is not PNG - it's already SVG, called File:Circle frame.svg.

I never dived/dove too deeply into SVG rules or "programming" - it may be possible to replace this one with a different SVG where the color is passed as parameter. replacing the image used by the module is no big deal - merely changing this line, but one needs to find an alternative SVG with parametric color, and figure out how the param can be passed (AFAIK, this is done using CSS classes, so there can only be finite set of "backgrounds", and I guess they can be passed using "templatestyles"). I think it's doable, but "not for the faint of heart", and specifically, not I.

peace. קיפודנחש (aka kipod) (talk) 20:39, 28 November 2025 (UTC)[reply]

I realized that I was confusing the chart module with the chart extension, which handles the background issue as well as a number of other improvements. Given that, what I'm instead just going to add a notice to this template suggesting to use the chart extension instead. Sdkb ^talk 17:24, 30 November 2025 (UTC)[reply]