"Chart is currently unavailable"

There is this message: "Chart is currently unavailable."

Does it refer to a particular chart or to the Chart extension? Amir E. Aharoni {{🌎🌍🌏}} 06:03, 12 August 2024 (UTC)

It turns out this message is never used. I've submitted a patch removing it. Roan Kattouw (WMF) (talk) 16:42, 12 August 2024 (UTC)

Thanks ♥️ Amir E. Aharoni {{🌎🌍🌏}} 02:33, 13 August 2024 (UTC)

"Its development has not begun yet"?

If development has not begun yet then why does it say "Editors and volunteer developers interested in data visualisation can now test the new software for charts. Its early version is available on beta Commons and beta Wikipedia." here? Prototyperspective (talk) 22:39, 3 September 2024 (UTC)

This page was out of date, I've updated it to say that the extension is under development. Roan Kattouw (WMF) (talk) 23:28, 3 September 2024 (UTC)

Accessibility review needed

Please review this extension for possible accessibility issues:

1. Is there a way to produce alternative text on a graphic created with this extension? And a large amount of data would not be suitable for alt text anyway.

2. Graphic data would not be accessible to blind people. Depending on the amount of data, it may not be easy to use for mobile visitors either.

But...the data is all there. It would be used to make the chart.

Suggested resolution:

When generating a chart, also generate a text version, whether as a table or as a multi-level bulleted list. Automatically add a link to that text version, using visible link text in plain language, not the URL, below the image. Then add alt="" to the image tag.

The advantage of generating the text version from the same data as the graphic is that there is a single source of truth and you do not risk them getting out of sync with each other.

Thisisnotatest (talk) 06:43, 2 October 2024 (UTC)

This is a good point -- we have the underlying data available and could point to, or render, a table version as an alternate. phab:T382806 requests adding a link to the data page, which would provide a rendering for non-transformed cases, but I wonder if we could do something more integrated... Brooke Vibber (WMF) (talk) 16:45, 2 May 2025 (UTC)

y-axis range

Is there a way to set the y-axis to start from a number other than zero? I created a chart for the water level of the Sea of Galilee, but the data doesn't look good because the level ranges between -214 and -208. Is there a way to fix this? Thanks, החבלן (talk) 11:44, 29 January 2025 (UTC)

Right now there isn't, but I've created a task for this at phab:T385344. Thanks for the feedback! CCiufo-WMF (talk) 22:47, 31 January 2025 (UTC)

Thanks! החבלן (talk) 17:22, 1 February 2025 (UTC)

Versioning question

The infobox says the extension works only for MW 1.44 and up. The Github repo, on the other hand, has branches for MW 1.43. Does that mean that while they're there, they're not really suitable for production? Rand(1,2022) (talk) 19:00, 6 May 2025 (UTC)

@Rand(1,2022): The infobox reports what the current (development) version of the extension's manifest requires, which for Wikimedia-deployed extensions is (almost) always the current (development) version of MediaWiki. Versions are branched automatically for extensions whenever MediaWiki is.

For the Chart extension, this has so far happened for MW 1.43 but not before (as it's a new extension). That branched version is the one that was deployed to Wikimedia production until 7 months ago (plus some i18n back-ports and tooling updates). It may well work for third-party installations of MW 1.43, but there are few users of it so far. Jdforrester (WMF) (talk) 13:55, 7 May 2025 (UTC)

Thanks. I was wondering because I've seen other extensions' info boxes wrongfully or misleadingly declare '1.43' or '1.44' as the minimum version, so I was wondering if something like it happened here. If it's taken from extension.json, then that explains things but it does not necessarily help the user checking for compatibility. In this case though, with so much development being focused on 1.44, that seems justified. Rand(1,2022) (talk) 16:41, 9 May 2025 (UTC)

@Rand(1,2022): You might want to bring this up at Template talk:Extension or Module talk:ExtensionJson, but I fear adding a table of supported MW on a per-branch basis would be too complex to be useful to most users. Jdforrester (WMF) (talk) 13:29, 14 May 2025 (UTC)

But I wasn't referring to per-branch descriptions. The infobox usually shows a supported range like 1.35+, or 1.39-1.41. Cavila 18:55, 14 May 2025 (UTC)

No, the infobox for a handful of extensions is a range managed by hand, but usually (for a decade now) displays the supported version of the master/main/dev branch, pulled automatically from git. Hence why I suggest raising it centrally. Jdforrester (WMF) (talk) 22:03, 14 May 2025 (UTC)

Will Wikipedia pages with disabled graphs automatically be changed to use the Charts extension?

There are many articles and other pages in en:Category:Pages with disabled graphs – will those be somehow automatically be adjusted to use the new Chart extension so the charts show again? (It would then depopulate that cat and populate en:Category:Pages using the Chart extension.) If not, is that possible and anything like that planned?

Also see this new WikiProject on English Wikipedia that you may be interested in (sign up) and where you could also post something related to this subject on the talk page:

WikiProject Data Visualization
Prototyperspective (talk) 12:20, 15 May 2025 (UTC)

@Prototyperspective: I suggest two options below. #Using AI to convert old graphs to the Chart extension and #Script for importing data from an old Wikipedia graph. Tomastvivlaren (talk) 22:58, 20 May 2025 (UTC)

Using AI to convert old graphs to the Chart extension

I have successfully used ChatGPT 4o to semi-automatically convert the old graph code to code for the Chart extension. I believe this method saves some time and I found no change in the actual data. To prevent some syntax error and formatting issues, I used the following rather detailed prompt:

Convert the following Graph wiki code, extracted from the "EXAMPLE" Wikipedia page, into a diagram suitable for the Wikimedia Chart extension. Start by suggesting appropriate English file name for Wikimedia Commons, agreeing on the file name with me. Avoid years in the file name. Then continue by creating one .tab and one .chart JSON file for Wikimedia Commons "Data:" namespace. The file name of the .chart page should include the graph type (end with for example ".Line.chart" or ".Area.chart"). Provide url links for the .tab and .chart pages, and wikicode to be used in the Wikipedia page. Check that a .tab file with similar content does not already exist.

In the .tab file, transpose the data to one row per data point (each row as an array without labels, one row per date or year if applicable.). The .tab file must be complete and not simplified, also if the amount of data is extensive. The file must contain a "schema" object with a fields array (not fields at the top level), consisting of "name", "type" and "title". The field "name" should not include spaces or punctuation. "Type" must not be "date", but only "string" for dates or years, and "number" for values. Translate the multilingual "description" and field "title" into en, sv and it language. (Omit "primaryKey".) Include "license". Suggest existing "mediawikiCategories", as a list of objects with "name", including a category that includes the word "chart". Search for more existing sources with similar content, include "sources" with URL:s, as a single string separated by <br>.

The corresponding .chart file, should only state "license", "version": 1, "title", "source", "type", "xAxis" "title", "yAxis" "title" and "mediawikiCategories". (Omit "description" and "series".) The "source" must be the .tab filename without the "Data:" prefix, titles must be multilingual (en, sv, it).

The wiki code should replace the original code. It should produce the chart using the {{#chart:filename.chart}} magic word, and wrap it in {{Image frame|...}}. A caption should include "Data sources:" with links as footnotes, and a centered link to the "raw data" .tab, formatted as <center>[[c:data:... .tab|'''Raw data at Wikimedia Commons''']]</center>.

Original wiki code:

{{image frame |content={{Graph:Chart ... }} || caption= ... }}

At first, I tried providing example JSON files to ChatGPT, but a rather specific prompt appears to be more successful. I expect more simple prompts to be sufficient in the future.

Some MediawikiCategories may be made up, and must be replaced with existing categories. Some syntax errors may still occur, that you can try to address by copying the error messages into ChatGPT. If the amount of data is too extensive, ChatGPT may interrupt or produce an incomplete and simplified .tab file. ChatGPT seems to be unable to check if a .tab file with similar content already exists, with a file name in another language, so you should do that manually, for example by checking the same MediawikiCategories, or by checking up translated versions of the same Wikipedia article.

ChatGPT can also be utilized to extend or replace data in an existing .tab file with data from a table that is pasted into the ChatGPT prompt.

What are your experiences? Please provide further developed prompts. Any experiments with other generative AI/LLM:s? Are there any method to even more efficiently convert graphs to charts, without the use of AI? Tomastvivlaren (talk) 22:55, 15 May 2025 (UTC)

Controlling height, aspect ratio and zoom level, and allowing expansion of the plot

One issue with this is that graphs can have width and height, and this doesn't account for that. This can lead to bad layouts when 4 graphs are meant to be right next to each other. GalStar (talk) 22:59, 3 June 2025 (UTC)

@GalStar: Agree! The very tall plots can trick the viewer into thinking there's a faster change and bigger variation than there really is. In these fake news times this is a serious draw back. I think the plots should keep their aspect ratio independently of the width. The width can easily be controlled by embedding the #chart call in an image frame, ChartDisplay or a table cell, and things like the number of tics and the resolution of the xaxis grading automatically adjusts smoothly utilizing SVG. It should also be possible for the yaxis.

Another thing: I hope that we soon will be able to click on the plot to see the full window version at commons, and from there, access the tabular view of the data. Then we should not always have to add a link to "raw data" under each plot. If expanding the plot was possible, it would be okay to sometimes show a small (zoomed out) preview of some plots. The text in the preview image does not always have to be readable, as long as the preview still gives some overview, and you can click on it to expand it. From accessibility point of view, being able to expand is more important than to force us to always show visible grading and plot details. Tomastvivlaren (talk) 14:41, 9 June 2025 (UTC)

Maximum file size of .tab file?

Currently, the chart at c:Data:Markov constant chart data.Line.chart fails to render and shows the message: "There was an error rendering the chart." Could the issue be that the linked data file c:Data:Markov constant chart data complete.tab is simply too large? Perhaps a coincident, but at about the same time as these files were created, Wikimedia Commons temporarily reported problems due to too many database calls.

The .tab file is currently 945,338 characters according to the MediaWiki file history, and 1,502,442 characters across 92,842 lines according to my plain text editor. Or 23201 2D datapoints. The original dataset, extracted from en:Template:Markov constant chart, was slightly larger. When attempting to upload the full dataset to the Commons Data namespace, the upload dialog reported a hard limit of 2048 kilobytes (likely meant to be 2048 kibibytes = 2 MiB), so some datapoints had to be removed.

Given that a hard limit is implemented on the data file size, and the Apache Echarts renderar (used by Extension:Chart) has no documented rendering limit lower than this, I would expect the .chart to be able to render that size. Are there some undocumented performance limit? Tomastvivlaren (talk) 21:15, 18 May 2025 (UTC)

We're taking a peek at this, it may be related to some internal resource limits on the rendering service. We can get it to render on a local server, so it's likely a config issue we can work out shortly! --Brooke Vibber (WMF) (talk) 17:05, 19 May 2025 (UTC)

Turns out the service runner had an aggressively small default maximum return data size of like 100kb :D

We can probably bump that up closer to the 2mb limit on wiki pages sizes, but since the entire data set will be _sent on to the client_ for zoomable rendering do consider using a decimated data set that's smaller. :D

We'll see what limit we decide on after checking in internally...

(At least the numbers in the JSON should compress well in the HTML! :D) Brooke Vibber (WMF) (talk) 17:47, 19 May 2025 (UTC)

Thanks for the report, we are now tracking this in https://phabricator.wikimedia.org/T394725

Tracked in Phabricator
Task T394725

Jon (WMF) (talk) 18:23, 19 May 2025 (UTC)

Script for importing data from an old Wikipedia graph

I made an attempt to develop a user script that semi-automatically extracts data from Wikipedia graphs that are based on en:Template:Graph:Chart and converts the data to a .tab JSON file.

An early version lives here: c:User:Tomastvivlaren/graphDataImport. Feel free to test it or improve it.

To try it out:

1. Edit or create your https://commons.wikimedia.org/wiki/user:<yourusername>/common.js file (replace <yourusername>).
2. Add this line:
   
   mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Tomastvivlaren/graphDataImport.js&action=raw&ctype=text/javascript');
   
   
3. Start editing or creating a .tab file in the Data namespace. For example c:Data:Chart Example Data.tab -> Edit source. A button called "Import graph wikicode" should appear.

Tomastvivlaren (talk) 22:50, 20 May 2025 (UTC)

Now the script also can suggest code for the corresponding .chart definition page. What remains to turn this user script into a gadget and make it available in the user preferences? Tomastvivlaren (talk) 01:09, 25 May 2025 (UTC)

Support for annotations?

Old graph had useful "annotation" features, see vAnnotationsValues / hAnnotationsValues keywords. Are they supported now? --Викидим (talk) 21:06, 25 May 2025 (UTC)

Charts don't currently support annotations, but if you're feel free to open a Phabricator task describing your use case for them. CCiufo-WMF (talk) 17:30, 26 May 2025 (UTC)

Feature request: Enable data selection for y-axis

Feature summary: Select specific data from a tabular data file to be displayed in the y-axis of a chart definition. Additionally, being able to filter with a WHERE clause.

Benefits: Looking at the current documentation, it seems that all of the data in a .tab file is displayed. Furthermore, it appears that it needs to be in the right format to be displayed, with some chart types requiring special data formats. This means that there will basically be a 1:1 relationship between charts and underlying data files. At best a 4:1 relationship given the (currently) 4 different chart types. If all one can do is change the chart and axis title (which are already defined in the data file in multiple languages), this does not seem to allow true re-use of data files across use cases and therefore we will end up with duplicate data files resulting from different display choices.

My particular use case / example is rebuilding the population graph in Demographic history of Detroit. I have put the data into a .tab file and I now want to display an area chart of only the absolute population numbers. I would also like to add a separate Y-axis data point of the total population which is not stacked like the others. Right now, neither are possible (or the features are not documented). I think it makes sense to keep the relative values in the same file which can also be included in the article as a table (as it currently is).

Note: I see there is a way to do this via Transforms but it seems a bit much to expect Wikipedia editors to create a Module file with code just to select data. I think a query language like the one used in the Tabular Module would work well. Gumgl (talk) 22:08, 29 May 2025 (UTC)

And immediately after posting this I ended up on the other talk page which lead me to task T388616 tracking the work. Gumgl (talk) 22:16, 29 May 2025 (UTC)

Do I get it right that this will allow to select specific data (say, rows) to display in the chart, without having to create separate code? Julius Schwarz (talk) 07:44, 3 June 2025 (UTC)

Yes? @Gumgl Julius Schwarz (talk) 08:50, 23 June 2025 (UTC)

@User:Julius Schwarz. Yes, now the column (or curve) selection seems to work. See Extension:Chart/Transforms.Tomastvivlaren (talk) 00:37, 9 July 2025 (UTC)

Thanks a lot for this @Tomastvivlaren, it works wonders. But for those reading too quickly like me, let's underline that you need to add TabUtils to the chart (even if that chart itself does not need column selection) for the column selection to work elsewhere. As it says:

If the .chart page default should show all curves, but allow selection of curves in the wikicode as in the above example, it is sufficient if the .chart json code includes the following:

    "transform": {
        "module": "TabUtils",
        "function": "select"
    }

Julius Schwarz (talk) 07:41, 9 July 2025 (UTC)

Where do we find the list of published / official modules and there use? — GhostInTheMachine ^talk 09:31, 9 July 2025 (UTC)

Actually, @Tomastvivlaren, unless I am mistaken, using a "where" clause for y-axis selection (as done [[European Christian Political Party#Funding|here, for instance) automatically changes the y-axis baseline -- in the example, it moves from the usual 0 to 200,000. Is there a way to avoid this? In this example, it does not make a huge difference, but in other cases it can be very misleading, and it would feel disingenuous to display a chart like that. Julius Schwarz (talk) 10:05, 9 July 2025 (UTC)

Usability of this extension is lacking

Seems kind of wasteful to create a .tab and then a .chart, why not add an option to embed the data into the chart? Also there is no way to set the width/height of the chart, even though this was highly used in the prior graph extension. Without the second one, porting graphs to charts is next to impossible, and the first one would be a great way to reduce spam in the Data namespace. GalStar (talk) 22:57, 3 June 2025 (UTC)

Hi @GalStar, thanks for the feedback. The reasoning behind keeping the data and the chart configuration separate is so that multiple different charts could use the same source data set for different purposes. We are hoping this actually reduces the amount of files needed in the Data namespace. Support for also inlining the data in the chart was considered but not implemented as part of the initial version.

Regarding width/height: Currently charts fill the available space, so will adapt if placed inside of a container template. Explicit width and height options are being considered in T376845. CCiufo-WMF (talk) 16:09, 4 June 2025 (UTC)

What container can be used? en:template:Image frame template only allows to set width, which makes this extension practically unusable for anything that is not full-screen charts (a niche use of the previous extension) Ita140188 (talk) 11:08, 6 June 2025 (UTC)

The result is the opposite: we need to create one .tab and one chart definition per graph we want to add, a redundant way of creating complexity. Theklan (talk) 15:07, 8 June 2025 (UTC)

Ability to configure axis

I see the following image, this makes it rather misleading, and exaggerates the change. There needs to be a way to atleast lock the scale to include the origin. A preferable addition would be the ability to configure the axis (and perhaps choose between linear and logarithmic as well).

GalStar (talk) 23:58, 3 June 2025 (UTC)

@GalStar we decided for the initial release to autoscale the axes as the most appropriate default. Configuring axis scaling options is captured in T385344. CCiufo-WMF (talk) 16:12, 4 June 2025 (UTC)

Graphs still broken, as this is Charts doesn't solve the issue

We have two graphs in many articles, let's say this one: eu:Altsasu. How should we proceed to make the charts work? As far as I know, these can't be done. Theklan (talk) 18:09, 4 June 2025 (UTC)

Option 1) Here is an example through creating commons:Data:Weather_monthly_history_Altsasu.chart.

Option 2) Extension:Chart/Transforms (about 1-3 weeks away) should let you update the chart to certain columns and modify your existing Graph module to do this more dynamically.

Happy to answer any questions you have. Jdlrobson (talk) 02:12, 5 June 2025 (UTC)

Sorry, but the created chart doesn't have any resemblance with the graph that we had. It had an slider, pluviometry, interactivity... all of that is gone and now we have a line graph that doesn't fill any need for climate research.

Also, there's a second graph there that is still broken and will be broken, as data was extracted from the most logical place to extract data: Wikidata. Theklan (talk) 13:34, 5 June 2025 (UTC)

As far as I understand, if I want to create a chart with the population data of one place, I have to create a .tab and a graph definition for each of the places, instead of just creating one graph and pulling the data from Wikidata. This approach will ask for the creation of millions of pages to show the population of each of the places in the world. Theklan (talk) 09:56, 7 June 2025 (UTC)

An example of all that is wrong with this extension

You can see how the new chart is rendered in this page: w:en:Renewable_energy_in_the_European_Union

1. There is no way to fix the height of the image, resulting in this ridiculously tall chart. Before we could just specify the size of the chart.

2. There is no link to the actual chart, so it's very confusing to understand where the code is (especially since it's not even on Wikipedia). Before the data and code was in the same page.

3. No way (as far as I can tell from the documentation) to remove the stupid "y1" legend which takes space and has zero informative value

4. The title of the chart is too long and does not fit. It does not create a new line, and as far as I can tell cannot be made smaller to fit in the space.

This for me is an extension that is (relatively) good on paper but it's not meant to be used by actual people in actual pages. This is without even mentioning how complex it is to create a new chart. Even finding where the extension is in the first place (to check documentation) is complicated Ita140188 (talk) 11:29, 6 June 2025 (UTC)

Thanks for identifying and reporting the issues here. Re 1 I think templates are used for that or not? For example or maybe w:Template:Image frame and w:Template:ChartDisplay (if currently only width can be specified maybe these could be changed so that height can also be set?). Prototyperspective (talk) 13:21, 6 June 2025 (UTC)

I could not find a way to specify the height. Even including the chart into a <div style=height:400px> will just produce a div of that size with a scroll bar, with the chart still with the same height inside it. Ita140188 (talk) 13:45, 6 June 2025 (UTC)

1. I added a phabricator issue about controlling the aspect ratio. See https://phabricator.wikimedia.org/T397009 .

3. There is an undocumented workaround to get rid of the legend. This is reasonable in case of a single curve. (Despite the strange decision to remove the showLegend chart definition option, according https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Chart/+/1079560). Tomastvivlaren (talk) 09:35, 16 June 2025 (UTC)

It would indeed be great to be able to manually disable the legend from the inline code. For instance, I have charts about parties. On individual party pages, I display the charts with just the party under consideration -- as a result, showing a legend with the name of the party (which is obvious from the article) is utterly not needed; at the same time, that does not apply to the chart itself, just to its display on specific pages. Julius Schwarz (talk) 08:57, 9 July 2025 (UTC)

Wishlist

Following 3 topics are highest on my wishlist:

1. Make the height adjustable, not only the width
2. Make the legend position configurable (and also let it switch off)
3. Select which rows from a table table you want to plot

--McBayne (talk) 19:47, 6 June 2025 (UTC)

Are there issues on phabricator for these? If so, I'd recommend linking them and if not, to create them. Prototyperspective (talk) 21:51, 20 July 2025 (UTC)

Wish #3 is implemented meanwhile using the Extension:Chart/Transforms-Feature. There are also examples for it available. Wish #1 seems to be https://phabricator.wikimedia.org/T376845. For Wish #2, I don't know if one exists.--McBayne (talk) 22:01, 30 July 2025 (UTC)

Could you or somebody else who has a good example for this and more concrete input about where why how they'd like to reposition the legend please create the issue?

Same for the legend overlapping the chart bug you reported below with a good example (also there is lots of white space beneath the pie chart so it seems to be too high up where changing sth so that it's moved down and remaining whitespace is trimmed would fix this). Prototyperspective (talk) 22:51, 30 July 2025 (UTC)

I hope the legend thing has a phabricator already, but I'm too much of a beginner on this topic so I hope somebody more experienced can help here and create tickets as needed.--McBayne (talk) 23:00, 30 July 2025 (UTC)

Unexpected behavior

On Windows Desktop, Chrome browser, I was looking at the John McCain article on English Wikipedia. There's a chart there in the "Cultural and political image" section showing his approval. At first, it looked fine. When I reduced my window width, it adjusted alongside the rest of the content, becoming "squished". However, when I then increased my window width, trying to bring the page back to normal, the Chart remained "squished" and basically unreadable. It seems to lock in at its smallest display size and never return to its original width. Ganesha811 (talk) 22:09, 11 June 2025 (UTC)

Just confirming it happens with Firefox too on Linux, both reducing the window width or magnification. The chart is embedded in a template to force a downscale and that's what mangles the rendering when the size changes. Tactica (talk) 23:43, 11 June 2025 (UTC)

I was playing around with en:Template:ChartDisplay and found the same thing. If you don't specify a width, it will remember its smallest width, so if a width is specified it needs to be fixed (e.g. "400px"), not a percentage or any other attempt to make it responsive. Ahecht (talk) 14:27, 12 June 2025 (UTC)

mediawikiCategories missing from JSON schema

The JSON schema at doesn't have mediawikiCategories. Why not? --2806:2A0:1412:91A2:C9CC:7410:B163:13F1 23:45, 12 June 2025 (UTC)

Problem with loading the chart

I have a table with data — that part is fine. I also have a chart created, and it renders without any issues there.

However, when I add the chart to an article like this: {{#chart:1993_Canadian_federal_election.chart}}

I just see raw HTML code.

Here’s what my config looks like:

wfLoadExtension( 'JsonConfig' );

wfLoadExtension( 'Chart' );

// Konfiguracja tabular data

$wgJsonConfigModels['Tabular.JsonConfig'] = 'JsonConfig\JCTabularContent';

$wgJsonConfigs['Tabular.JsonConfig'] = [

    'namespace' => 486,

    'nsName' => 'Data',

    'pattern' => '/.\.tab$/',

    'license' => 'CC0-1.0',

    'isLocal' => true,

];

// Konfiguracja chart data

$wgJsonConfigModels['Chart.JsonConfig'] = 'MediaWiki\Extension\Chart\JCChartContent';

$wgJsonConfigs['Chart.JsonConfig'] = [

    'namespace' => 486,

    'nsName' => 'Data',

    'pattern' => '/.\.chart$/',

    'license' => 'CC0-1.0',

    'isLocal' => true,

];

// Ścieżka do lokalnego CLI renderera

$wgChartCliPath = "$IP/extensions/Chart/chart-renderer/cli.js";

$wgHooks['BeforePageDisplay'][] = function( $out, $skin ) {

    $out->addModules( 'ext.chart.loader' );

    return true;

}; 91.199.25.153 07:03, 16 June 2025 (UTC)

CC License for Imported Wikipedia Content? Attribution Needed?

If we automatically import content from existing Wikipedia graphs or tables, should we license the resulting .chart and .tab files under CC0-1.0 or CC BY-SA-4.0? And if it's the latter, do we need to credit the original source—like stating a permanent URL to a specific Wikipedia page version in the .tab file’s “sources” field or in the edit summary?

By default, .chart and .tab files created from scratch use CC0, which doesn’t require attribution. This is usually fine because .tab files mostly hold structured data—info like numbers, terms, or categories, arranged into a machine readable schema such as a list, form, table or JSON object with a specific format. Since .chart files are just JSON (not considered as actual code), they’re also generally treated as structured data.

However, both .chart and .tab files often include human-written sequences of words, like titles, descriptions, column titles, or reference lists. CC0 is considered sufficient in the default case since these are either rewritten in the contributor’s own words, or copied as short, descriptive phrases—not full paragraphs or expressive text.

Automatically imported content typically pulls the .chart title or .tab description from things like the Wikipedia page name, the graph title, and/or a yAxisTitle—rarely full sentences with subject and verb. Sometimes the .tab sources is the copied image caption or reference notes.

Under copyright law in both the EU and US, short phrases, labels, titles, and headings aren’t protected by copyright if they’re just factual, common, or purely descriptive. So quoting titles or short phrases—even from books or newspapers—is usually fine. But full sentences or paragraphs do require permission, unless exceptions like fair use (US) or quotation rights (EU) apply.

Are there sufficient uncertainty here, that our automatic tools should act cautiously and always use CC BY-SA-4.0 and require a Wikipedia source? @GalStar: .Tomastvivlaren (talk) 18:00, 18 June 2025 (UTC)

Chart title

The title should be treated as "real" wiki text so that bold, italic and links are possible. See c:Data:GhostInTheMachine/Test.chart — GhostInTheMachine ^{talk to me} 09:10, 22 June 2025 (UTC)

Namespaces

I guess that it is far too late, but ... The chart data is logically held in the "Data" namespace. However, the chart definition is also in the Data namespace. It logically should be in the "Chart" namespace — GhostInTheMachine ^{talk to me} 09:16, 22 June 2025 (UTC)

Agree, this is quite confusing Ita140188 (talk) 12:11, 25 June 2025 (UTC)

Strategy for page names

Since all charts and their data are defined in the "data" namespace on Commons, there will be clashes. For example: an article called "AAA" on the English WP includes several charts and an unrelated article called "AAA" on the German WP needs charts as well. The English WP names the charts "AAA-1", "AAA-2" etc. What strategy is advised for naming the data pages and the chart pages so that the various WPs have a reasonable chance to maintain a logical pattern of pages names for their charts? — GhostInTheMachine ^{talk to me} 09:26, 22 June 2025 (UTC)

I understand that this is a multilingual platform, but I would prefer page names in English—also when charts are imported from non-English Wikipedia pages. This helps reduce the risk of creating duplicate .tab and .chart pages with different names but similar content.

To prevent duplication, it’s good practice to first check whether a chart already exists on the corresponding English Wikipedia article before importing from another language version. If a defunct graph still exists in the English article, consider to also replace that with the new chart. Improved categorization also helps: it increases the likelihood that already existing resources are found through the Commons category tree.

When a single .tab dataset is reused across multiple .chart visualizations—such as different plot types, curve selections (via column filtering), or other transforms—a naming convention is needed to help distinguish the .chart pages. Examples include using a slash (/) or a dot (.) to differentiate the variants:

• c:Data:Example.Bar.chart, c:Data:Example.Pie.chart, c:Data:Example.Area.chart, c:Data:Example.Line.chart
• c:Data:Orbital launches by country.Lines.chart, c:Data:Orbital launches by country.Area.chart
• c:Data:Sweden - yearly population and population changes/filter men and women deaths.chart, c:Data:Sweden - yearly population and population changes.chart
• c:Data:Bls.gov/US Women's weekly earnings as a percent of men's by age, annual averages/age 25-44.chart, c:Data:Bls.gov/US Women's weekly earnings as a percent of men's by age, annual averages.chart
• c:Data:Climate Paris/transformed.chart, c:Climate Paris/example.chart

Suggestions on how to improve these page names? More examples? Tomastvivlaren (talk) 15:56, 22 June 2025 (UTC)

Wouldn't having AA-1, AA-2, AA-3, etc. would make porting very automated/simple. Maybe en-AA-1 is a better convention in this regard ([language]-[article-name]-[y1title/number]). GalStar (talk) 18:19, 2 July 2025 (UTC)

I think the data pages naming should follow the same naming directions as for files: "To prevent collisions, it is encouraged to add strongly distinguishing information such as a source, date, or catalogue identifier, although it is not always necessary."

So in case the page name that you suggest already exists, you just add information in the name. Often it can contain the name of the Wikipedia article where the chart is supposed to be inserted, or the corresponding English name, perhaps combined with last section header above the chart, and/or of part of the caption or the yaxis title. A semiautomatic tool can use these. This principle can also applied in the semi-automatic generation of .tab page description and .chart page title.Tomastvivlaren (talk) 22:52, 2 July 2025 (UTC)

Printing problems

Printing a page with a chart only shows the wiki-text, the charts do not appear (in Firefox and Vivaldi). Exporting to PDF ditto. Only "Printable version" in menu "Print/export" works. - Erik Baas (talk) 00:51, 12 July 2025 (UTC)

gerrit.wikimedia.org

All links to https://gerrit.wikimedia.org/ result in an "error 403: Forbidden". - Erik Baas (talk) 00:52, 12 July 2025 (UTC)

Android

Firefox 136 on Android 11 does not show the charts, unless it is switched into "desktop" modus. - Erik Baas (talk) 01:16, 12 July 2025 (UTC)

The how-to guide is not very accessible

I would venture that many of us not so technically savvy users find the current how-to guide a little inaccessible. For example, I don't know what a .json file or a parser function is, or how to download a JavaScript library. The new extension might well be easy to use, but the complexity of the guide will put a lot of people off from even trying to use it.

I think most Wikipedia editors who primarily contribute content would be super grateful for a step-by-step guide that assumes less prior technical knowledge (or at least attempts to explain the jargon used)—we're here to contribute content, not for a crash course in coding. :) Tserton (talk) 19:13, 14 July 2025 (UTC)

I wish someone who speaks better English than me could make a video guide on how to convert old graphs using tools such as the graphDataImport script.Tomastvivlaren (talk) 20:41, 14 July 2025 (UTC)