How would you like to be notified about project updates?

I think I'm going to create a newsletter similar to Newsletter:Web team's projects which would send an Echo notification with a link to the updates page. It seems to be simpler, less spammy, global by default (since Echo is global), and thus better than mass message on user talk pages. So let me know if you strongly prefer to get mass message on your user talk page anyway. I need to pick one method, can't promise both. (Posting messages about major milestones on village pumps is a different topic, we will be posting those too.) Thanks! SGrabarczuk (WMF) (talk) 02:30, 3 July 2024 (UTC)

Echo notification is good to me. Thanks Pamputt (talk) 20:57, 7 July 2024 (UTC)

Data source

Requiring data to be in the Commons Data namespace is a quite effective way to ensure Charts will not be used. I don’t have figures, but I’m pretty sure many, if not most, uses of Graph don’t use the Data namespace, but rather inline data, template or module subpages, or Wikidata (via SPARQL or via the Wikibase Scribunto interface). If the only data source would be inline, all of these except for SPARQL could be used (including the Commons Data namespace, via modules using its own Scribunto interface); if the only data source is the Commons Data namespace, anything but Data namespace pages becomes unusable, and the project will be a failure. —Tacsipacsi (talk) 09:25, 6 July 2024 (UTC)

That's the same concern I have. If I had to create a graph with the data namespace on Commons as middle man, I'd simply not bother. That's too much effort. I'd rather see it take in-line data first, also considering I have never seen a graph using the data namespace "in the wild" before. DarkShadowTNT (talk) 21:48, 10 July 2024 (UTC)

@Tacsipacsi @DarkShadowTNT this feedback has been noted and we're in the process of analyzing how different data sources were used in Graphs. For the purposes of our upcoming prototype, we will pursue the Commons tabular data approach. While sourcing data from MediaWiki APIs or Wikidata Query Service is not the focus for this initial project, we want to ensure the extension is designed in a way that those sources can be supported in the future without requiring any Lua code. CCiufo-WMF (talk) 19:23, 26 July 2024 (UTC)

The problem is exactly that: not having a purpose. When the project fails, no one won't blame it on a poor scope, we will read how "editors are not using it". Theklan (talk) 21:04, 26 July 2024 (UTC)

I can only repeat myself: this predestines this project to fail. You can spend a lot of money and work hours on this project, but if you build something people don’t need, it’s just throwing out that money and time. No problem, I’ve mostly given up the hope anyway that we’ll have a usable graph implementation ever again. —Tacsipacsi (talk) 09:38, 27 July 2024 (UTC)

Re-reading your reply once again, I noticed that there may be a misunderstanding. I didn’t ask for the ability to get data from the APIs or Query Service directly. I asked for the ability to specify data inline, where the parser tag is placed. That inline data could come wherever the wiki editor wants. This would make the graphs at least not less powerful than the current CSS-based hacks. —Tacsipacsi (talk) 09:43, 27 July 2024 (UTC)

Inline is very relevant, indeed. But having data from the Wikidata Query Service is a must, because up-to-date data can be found there for a lot of things. Anyway, the team decided to make something sub-optimal from the start, so it can be justified on the low usage not improving it in the future. Theklan (talk) 10:23, 27 July 2024 (UTC)

Many (though not all) WDQS queries can be replaced by data queried via the Wikibase Lua interface – and data queried via the Wikibase Lua interface can be specified inline. Lua code may not be as expressive as SPARQL, but it gives you more freedom (e.g. you can add a summarizing table below the graph), and has built-in change propagation, which also means it’s easier on the servers (data isn’t re-queried from Wikidata on every page view) while it’s still guaranteed that if data does change, it propagates within a reasonable time. (WDQS is at its limits, so I’d avoid using it wherever a reasonable alternative exists.) And being able to specify data inline allows not only Wikidata data to be displayed, but also data stored in templates or actually inline in the article text. —Tacsipacsi (talk) 16:41, 28 July 2024 (UTC)

Thanks for the clarification @Tacsipacsi, I hear you on the flexibility that inlining data provides. We are trying to avoid depending on Lua and Templates this time around which is why I was suggesting a path to being able to use WDQS or APIs directly in the future instead. We're going to think about this a bit more and will keep you updated. Do you have specific examples of the types of charts you'd want to be able to create? That would be really helpful. I'd like to explore options that don't make you lose hope in the project! We're open to adjusting our approach as we learn more :) CCiufo-WMF (talk) 00:36, 7 August 2024 (UTC)

I also agree. It may seem harsh to say that a chart without data-points given in the transclusion would be a deal breaker, but that is just the reality of it. There should be an option to give data-points like {{#chart:format=1993 Canadian federal elections.chart|x=1,2,3|y=1,2,3}}. Having the data-points in a json is not simpler. I can see how a programmer would think, "I and my programmer friends know json, so that should be an easy way of doing it", but it is not. A layperson does not know much at all about json. Snævar (talk) 12:38, 3 August 2024 (UTC)

I agree the tabular data pages are not the easiest to work with right now. Making that experience better is something we're considering. Like I mentioned in the thread above, we're going to think about this a bit more and will keep you updated. It would be helpful for us if you could share some examples of the types of charts you'd like to create. Thank you! CCiufo-WMF (talk) 00:45, 7 August 2024 (UTC)

It should be pretty easy to see examples of use by just accessing the tracking category for the graph extension. A few of the charts I created over the years:

en:Nuclear_power#Fukushima_accident

en:Growth_of_photovoltaics#Solar_overcapacity_(2009–2013)

en:Growth_of_photovoltaics#Growth_by_year

en:High-speed_rail_in_Italy#History

Many more have since been deleted because of the broken extension Ita140188 (talk) 01:52, 30 August 2024 (UTC)

Not much to say other than +1. This decision pretty much ensures Chart extension will be useless in many circumstances it gets used, or harder to track vandalism in (since most Commons data pages are not actually protected, even high-use ones). If at least a way to create charts from Lua isn’t provided, this pretty much ensures that any usage of the new extension would be limited to a few cases where people might hack around the unnecessarily rigid extension requirements.
I also think it would’ve been much more courteous to announce these plans properly, so people who might be interested in Graph extension replacement would know that this extension was shot in the foot like this by its developers. stjn^[ru] 11:31, 16 October 2024 (UTC)

Just wanted to echo the concern with not having more ways to source data for graphs. I understand that convenience for developers the present setup affords by giving them total visibility into usage of the feature, and potentially allowing for easily mass-editing the graph data to accommodate breaking changes in the JSON grammar. But I feel that requirements of users need to be kept first.

Some of the priorities of this project seem rather ill-conceived. we want to ensure the extension is designed in a way that those sources can be supported in the future without requiring any Lua code. @CCiufo-WMF But why? Especially when that comes at the cost of making the extension highly inflexible for the short term? It may well be the case that you are planning to add more ways in the "future" – but WMF products have a long history of being developed for a limited time and then effectively abandoned, so that "future" may never come.

Being able to provide graph data inline opens up the ability to templatize them – so that multiple places which use the same graph data with minor variations can specify just those variations as parameters to a template. But for some reason, use of templates seems to have been considered undesirable without any reasons being provided. SD0001 (talk) 12:19, 30 November 2024 (UTC)

So my worries about being unable to use it on my wiki (to which I got no reply here) has been confirmed with this comment. I'll be unable to use it in the same way, by simply calling for data parameters that will fill in a chart according to it by the help of a template.

That would be beyond disappointing. Rasputin 93 (talk) 13:43, 30 November 2024 (UTC)

• Agreeing with all others in this thread. I didn't even realize the fact that this means data can't be templated before the above comment. If I'm understanding it right, just to create a simple bar graph, you will have to actually create two extra pages (the json chart definition and the data itself), which is a very convoluted process that none bar the most dedicated editors will go through, when previously it could all be edited from one page. The only advantage to this approach is it is usable on all languages/wikis, which is good, but not necessary in many cases. There should be the option for both. There also seems to be no updates about how, whether and when existing graphs, missing totally for 1.5 years now, can show anything and make users not have to resort to the source code or web archive. It seems like a herculean effort would be required to create a json and data page for every graph on English Wikipedia. This entire process seems misguided to me: I feel like it should have been, first, create something that requires little adjustment or bots to fit within the current system so that existing graphs can be restored, then begin creating this new system. I was previously hesistant to begin my own personal project to create SVGs for articles, especially high view articles, such as en:World War II or en:2020 United States presidential election, given the redundancy concerns, but I think I am now going to look into this, given I have no confidence this project will be completed any time in the near future for existing graphs. MarkiPoli (talk) 14:05, 30 November 2024 (UTC)

There are over 6,000 villages, towns and cities in my country and even more historical units. In the past 10 years, we have spent much effort on importing information about their historical population to Wikidata and developing templates that can mirror this data in the articles, both as tables and charts. We lost the latter option for valid reasons, but now it's about time to bring it back. Unfortunately, to present the data in a chart using the current solution, you have to copy the data over from Wikidata to Commons, and when an authority releases new data, the data need to be updated in both Wikidata (because that's where they are expected) and Commons (for the charts).

Why to introduce such redundancy, especially when sustainability of Commons is now being discussed? Why not to support embedding the chart data in the wikitext (possibly using a template), eliminating the need for implementing updates tracking when Wikidata already supports this? --Matěj Suchánek (talk) 09:29, 6 January 2025 (UTC)

Indeed, a visualization tool to replace Graph will be great but only if it is actually used and thus actually replaces it. If the sources of the data are severely restricted and it becomes little used, can it really be called a replacement? Commons Data is nice in some ways but how does that translate so non-WMF Mediawiki users, etc.? Commons Data is not really that heavily used currently (especially compared to other forms of linked data such at Wikidata and even structured data at Commons). Perhaps you should consider that before deciding that it is the basis of your minimal viable product (MVP) you are to deliver (i.e., the base before future technical upgrades). I appreciate wanting to move away from local data as that ties one down and we end up with hard to manage and hard to move data like the EN-WP country/flag, species, and currency conversion data (all based on local "template" data) but I think there are better more flexible alternatives when considering remote data sources. The largest one being linked data ontologies which have well defined schema. Perhaps a much better solution would be to support linked data and then make an interface to allow Commons Data to be seen at a linked data source. As far as I know there is no good means to "query" Commons Data sets (not to mention edit/update/develop them). —Uzume (talk) 20:35, 12 February 2025 (UTC)

Personally, I think managing the data separately from the chart presentation is a great idea. This makes the data more reusable. Having data inline on every wiki separately is short-sighted. Sure, it makes the creation of the chart slightly easier, but it means that every wiki has to maintain that data separately. I also like this approach better than relying on data from Wikidata, as you can actually track changes to the dataset. For all those people complaining about this new architecture, have you considered how it might actually make things more efficient and manageable in the long run? Nosferattus (talk) 20:06, 5 April 2025 (UTC)

The point is that allowing the data to be inline doesn't mean the data must be inline. The "inline" part can very well be transclusion of a template or a lua interface call that fetches from Commons. Not all kinds of data has scope for reuse. SD0001 (talk) 14:28, 7 April 2025 (UTC)

We have had a central venue for data management since 2012. It's somewhat odd to build another one.

have you considered how it might actually make things more efficient and manageable in the long run I have, and I concluded the opposite: #c-Matěj_Suchánek-20250106092900-Tacsipacsi-20240706092500.

--Matěj Suchánek (talk) 15:47, 7 April 2025 (UTC)

• So what's the short-term plan for third party wikis? Should they start uploading tabs to Commons as they see fit even with data that is only relevant for those wikis? And this assuming the data can be made public in the first place... I couldn't agree more with Tacsipacsi's views on this matter. --Tactica (talk) 16:57, 6 May 2025 (UTC)

Dream usage: mapping plane destinations

It is not a top priority but you did ask "If you have ideas on what criteria we should consider"...

Every English Wikipedia article has an "Airlines and destinations" section packed with useful data: Example.

Will the new Chart extension be able to map this?

Vega can do something like it, see Mapping Airport Connections Tutorial. Commander Keane (talk) 23:57, 8 July 2024 (UTC)

Thanks for the suggestion @Commander Keane. While this specific example might not be one of the first chart types available, it should be possible within the architecture we are envisioning. CCiufo-WMF (talk) 19:10, 26 July 2024 (UTC)

Usage on private wiki

Hello, I've been following the evolution of this ever since I've added the Graph extension to my wiki only to discover it has been shut down few weeks prior and therefore rendered unusable. I'm now lost on whether the future Chart extension will be usable on a private wiki in a simple way. I've read here and there about data to be stored in Commons, but I'm unsure if this is compatible with the way I envision potential charts to work, since I have regularly updating data stemming from templates. Meaning I change some value in an article's infobox, which will therefore change another value on a different article through templates using the DynamicPageList3 extension and this would be reflected on a chart (or multiple across the wiki). It's a very dependent automation that updates my entire wiki by just changing one value on one page. Currently, I use the same workflow with some very basic pie chart replacement that some user here wrote, but it's just a temporary solution. I don't know if my use-case is too niché or not, hence my question here so I can finally rest my thoughts about this once I get an answer. Rasputin 93 (talk) 02:17, 30 August 2024 (UTC)

• Rasputin1493 how was it rendered unusable? Why can you not still choose to have it on your private wiki... Sj (talk) 16:25, 30 August 2024 (UTC)

  The Graph extension just won't display any graphs whatsoever. Rasputin 93 (talk) 16:29, 30 August 2024 (UTC)

  Maybe I don't know what you mean by 'private'. A private wiki on Wikimedia servers? Or on your own home server? Sj (talk) 16:37, 30 August 2024 (UTC)

  I manage these wikis, they are hosted elsewhere.

  https://rammwiki.net

  https://linkinpedia.com Rasputin 93 (talk) 16:38, 30 August 2024 (UTC)

We should have a complete-ish table of Graphs and Charts

Ita mentioned above that some of his charts made over the years have been deleted since the extension was shut down; that may be a common experience for people who were devoted and expert curators of the genre. I would find a complete list of past graphs/charts to be more useful than the anecdata resulting from surveys and discussions. and it would let us run an archival script to render and save snapshots of them.

This involves:

1. a query across the full wiki dump as of the day Graphs were shut down, for Graph usage specifically
2. a query across the current wiki dump, for any of a range of graphs and charts rendered in various ways (images w/ a caption describing the graph, easytimelines, pie charts, &c)

CCiufo-WMF: is that possible on your end, as part of the background research? Sj (talk) 16:37, 30 August 2024 (UTC)

I don't have this list readily available to share right now, but it is something we're going to look into again as part of preparing to support editors with migrating from existing graphs usage. From what I remember, getting the archival data (from the day graphs were turned off) was more of a challenge. I will get back to you on this, to inform your request below as well. Getting a current dump (or at least at the time we're ready to migrate) should be much easier. CCiufo-WMF (talk) 14:06, 24 September 2024 (UTC)

Archiving old Graphs

Since noone is monitoring the old Graphs pages, posting this here:

• I'd like to make snapshots of all Graphs from last April. Ideally with the output of a query of that database dump (above) to know how many to expect :)
• Tgr I think you mentioned that you had a test server set up that could render this? but that you didn't think we would need it if the extension was fixed soon. Since it's not being fixed, and the Chart: does not have a timeline for identifying and restoring large swaths of old graphs, let's just make the snapshots. Do you still have a server that could be used for this purpose? (If not, can we do this in the wmf cloud / does it need to be on our own server somewhere else?)

Cheers, Sj (talk) 16:41, 30 August 2024 (UTC)

I don't have one but AFAICS it should be simple to set one up on Wikimedia Cloud. Tgr (talk) 22:48, 30 August 2024 (UTC)

I know this was a while ago, but I would strongly agree with doing this. There seems to be no real timeline about when the old graphs will be available, so the snapshots should be made and for lets say all articles with more than X amount of views per day they should be bot replaced, with, obviously, the numerical data either kept and commented out, or deleted in the article and saved to a master server somewhere, ideally both, ready to be re-uploaded to commons as table files (if that's the only way it is able to be done in the future). This shouldn't be impossibly hard for simple charts such as bar, line and pie. Sure, if you're bot replacing, probably not all can be checked for being correct and not malformed, but even a malformed chart is better than a totally non existent one, as it is currently. MarkiPoli (talk) 14:16, 30 November 2024 (UTC)

Labels on hover or tap-click

Seems like there are no labels for data (tooltips shown on hover and tap). Is this planned or should I file a request for that? Labels should contain something like x-y values for simple charts. Maybe configurable for other types of charts (see some examples of labels on my css piechart module).

I can see on beta that there a currently some click regions on the graph near data points, but they seem to do nothing. Not sure if the click-regions are a placeholder for future function or just something that came out of the library being used? Nux (talk) 12:32, 4 September 2024 (UTC)

The way we're rendering the charts right now on the server don't add the type of hover tooltip you're describing. The library we're using to render does support this though, among other interactive features we're hoping can be added in later. Feel free to file a task -- at least investigating how we can add support for this is something we plan to do. CCiufo-WMF (talk) 14:10, 24 September 2024 (UTC)

@CCiufo-WMF: Hi. The addition of tooltips is necessary for the readability of graphs, especially line graphs, particularly when there are several lines. And especially when there is a lot of data. A graph should not just give an idea of how the data are changing, but should also provide direct access to the data. I see that the task could be planned, but is there a deadline?Roland45 (talk) 14:40, 26 October 2024 (UTC)

@Roland45 We are working on adding interactive features like hover tooltips right now, and I hope it will be available on the beta cluster soon. I can ping back here once it is. CCiufo-WMF (talk) 15:21, 1 November 2024 (UTC)

Will .chart edition be limited?

I have seen that the translations are hard-coded inside the .chart at (Beta) Commons. I don't think this is the best approach, as it will have lot of redundant translations, but, anyway... will any user have the ability to edit any given .chart page or will it be limited to certain kind of users? If the later is true, is there a workaround for translations? Theklan (talk) 16:42, 4 September 2024 (UTC)

We're planning to keep charts editing open to everyone, especially to support the translation edits you're describing. We're open to suggestions on how we can improve the editing workflow for multilingual support. I agree the hardcoded translation in the chart definitions could get a bit messy, but it's the best option available to us right now to get things fully working. CCiufo-WMF (talk) 14:17, 24 September 2024 (UTC)

Stacked lines

For this chart i would like to use stacked lines. It looks like it could be possible.

Ainali (talk) 08:22, 11 October 2024 (UTC)

Hey @Ainali, yes this is possible, I've updated your example to use the "area" chart type, which is stacked by default. Let me know what you think! CCiufo-WMF (talk) 20:43, 15 October 2024 (UTC)

That is excellent, thanks! Ainali (talk) 09:41, 17 October 2024 (UTC)

Can't find any September update for this project

@SGrabarczuk (WMF): Is there any later update for this project than the one from August 30, 2024, i.e. almost seven weeks ago?

If so, where can I find it? Isn't Extension:Chart/Project/Updates the correct place to look for updates?

If not, when is the next update/newsletter planned to be available?

Where is the current time plan for this project, stating what and when for the planned project deliverables, published? Larske (talk) 10:33, 15 October 2024 (UTC)

Hey@Larske, these are all excellent questions! We are working on a project update. Normally I'd say it'd be published this week. Given the circumstances (Monday was a holiday for many of us, and I'm taking Friday off) I'm not 100% sure, but I believe this week is doable. There will be a new section on the /Updates page, I will send a notification via the newsletter, and the update will also be mentioned in Tech News. SGrabarczuk (WMF) (talk) 14:25, 15 October 2024 (UTC)

Possibility to have timeline support

The old EasyTimeline have several problems including not rendered in SVG, require font set up for non-Latin script. It would be good to have the functionality in Chart. -- 122.100.88.150 06:47, 26 October 2024 (UTC)

Hey there, replacing EasyTimeline isn't in scope for this project, but it may be a potential future enhancement (see phab:T137291). CCiufo-WMF (talk) 15:15, 1 November 2024 (UTC)

Letting you know :)

"Let us know if you'd like your wiki to be one of the first to receive the new extension." I would like it enabled on Swedish Wikipedia, please. Ainali (talk) 09:08, 26 October 2024 (UTC)

@Ainali Thanks for letting us know! In the meantime feel free to continue testing in the beta cluster, and then on test wiki once we've deployed there. CCiufo-WMF (talk) 15:16, 1 November 2024 (UTC)

Fr-Wikipedia application

I can confirm what was said above, namely that accessing json is not as easy as all that, especially when there is a huge amount of data to transpose. You need suitable tools, which not everyone has. However, this is the route I had envisaged in 2020 to internationalise country demography data, by creating tables in Commons such as this one. A module written in lua would then have processed the data. But the project failed. In fact, the main advantage of having the tables in Commons is precisely the possibility for any wikipedia to use the data.

That's why I'm applying to have the tool developed on the FR-Wiki as a test.Roland45 (talk) 14:53, 26 October 2024 (UTC)

@Roland45 thank you for the historical context, and I'm glad to hear you'd like to see Charts on FR-wiki. Being able to easily reuse Charts in any wiki is exactly why we chose Commons as the central store. And yes I agree, there can be more done to make it easier to work with the Data namespace. CCiufo-WMF (talk) 15:19, 1 November 2024 (UTC)

it.wiki

I would like to point out that Italian Wikipedia is one of the projects in the forefront with testing features like Charts, being one of the group 1 wikis regarding MediaWiki releases. we will be very interested to get the feature (even in beta) on our project. Valepert (talk) 11:14, 3 November 2024 (UTC)

@Valepert good to know, thanks! CCiufo-WMF (talk) 17:15, 7 November 2024 (UTC)

wuu.wiki

It will be nice if wuu.wiki is involved in first sites to receive the new extension. Lt2818 (talk) 14:27, 4 November 2024 (UTC)

Thanks for letting us know @Lt2818 CCiufo-WMF (talk) 17:15, 7 November 2024 (UTC)

Rationale behind Data: on commons

I'm excited for charts being back on pilot wikis! I get that it's kind of late now, but I wonder why Commons was chosen as the source for data instead of Wikidata, the existing wiki for collating data? Aaron Liu (talk) 20:14, 29 November 2024 (UTC)

It's a fair question why we don't turn on the Data: namespace on Wikidata. But for transclusions that look like media, we currently store all of the associated structured data on Commons. We definitely have two major different use cases for tabular data: structured metadata and chart data. Both have been stored on Commons since SDC, so changing that would be a more abstract discussion not specific to this extension :) Sj (talk) 15:54, 30 November 2024 (UTC)

Hey @Aaron Liu, as @Sj points out, the Data namespace already exists on Commons and is configured to store this type of data (e.g. map data). At least for now, we felt it was also the best place to keep charts and associated data too. CCiufo-WMF (talk) 17:14, 13 December 2024 (UTC)

Meta

Hoping to see this on Meta-wiki as well. Sj (talk) 15:56, 30 November 2024 (UTC)

Can make dashboard based on statistics in Meta. A big leap in impact study and participation in events. Ranjithsiji (talk) 11:09, 9 December 2024 (UTC)

Hey @Sj, we're planning to deploy to Meta-wiki (now tracked in T382012), but it will have to wait until the new year. CCiufo-WMF (talk) 17:09, 13 December 2024 (UTC)

Customization of the charts

I think the customization of charts will be enabled soon so that I can customize this chart to include only 3 lines. ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 13:16, 9 December 2024 (UTC)

Hi @Gnoeee, yes we'll be exploring how we can support this in T382011, which we will likely not pick up until the new year. CCiufo-WMF (talk) 17:10, 13 December 2024 (UTC)

I'm not sure if this is the same thing, but I'd like to be able to specify min and max values for the axes, or use the echart magic "dataMin" and "dataMax" values to use the dataset's min and max values, e.g. this chart on Commons (or perhaps I am missing something?) — Jonathanischoice (talk) 23:58, 19 January 2025 (UTC)

This is not quite the same, but I've filed a task at phab:T385344 to track the functionality you're describing. The chart in question that you linked might be especially strange because of a known issue we're aware of with rounding/truncation of numbers, tracked at phab:T383109. CCiufo-WMF (talk) 22:53, 31 January 2025 (UTC)

Cheers! I've subscribed. If it helps, I can code? Jonathanischoice (talk) 07:39, 1 February 2025 (UTC)

List of pages using extension

Is there like a namespace ID such that I could use a page such as all pages to list the charts? I know it available on the Swedish Wikipedia, but I don't know how to find an example chart. Ysangkok (talk) 14:00, 14 December 2024 (UTC)

The charts themselves are on commons. A list over pages on swedish wikipedia that have Chart graphs is sv:Kategori:Sidor som använder diagramtillägget. As for the charts, there is https://commons.wikimedia.org/w/index.php?search=intitle%3A%22.chart%22&title=Special:Search&profile=advanced&fulltext=1&ns486=1, they might get a category in phab:T382023. Snævar (talk) 20:33, 15 December 2024 (UTC)

Will this ever be completed?

In April it is 2(!) years that the graph feature doesn't work anymore. But still the bugfix is not ready. What did you do all this time? If other firms would take so long to fix such a broadly used feature the outcry would be immense. Unbelievable. Btw. in the FAQ at the frontpage you still promise September 2024... Chaddy (talk) 20:08, 10 January 2025 (UTC)

There is obviously no real interest in fixing things, or even engaging with these comments here. This is despite the enormous financial resources that the WMF has at its disposal. I wonder what they spend this money on, since their financial reporting is also not very transparent at all. Ita140188 (talk) 09:51, 27 January 2025 (UTC)

More constructively: is there a timeline for the broad rollout to all wikis? Sj (talk) 22:59, 31 January 2025 (UTC)

The FAQ says "end of September 2024". Chaddy (talk) 23:18, 31 January 2025 (UTC)

Thanks for calling out that the FAQ was out of date. I've updated it to reflect the latest progress on the extension, which has so far been deployed to 3 pilot wikis (hewiki, itwiki, and svwiki). We are planning to roll out to additional wikis before April, but it may take a bit longer to roll out to all wikis. CCiufo-WMF (talk) 23:40, 7 February 2025 (UTC)

April? With not even a plan for that? T383079 -Theklan (talk) 08:35, 8 February 2025 (UTC)

Are charts fixed height?

Or is there some way I can limit how tall they appear? Belteshassar (talk) 21:05, 31 January 2025 (UTC)

Hi @Belteshassar, right now charts fluidly take up the available space unless they are bound by some sort of container (like a template with fixed dimensions). There is an existing task for this at phab:T376845. It would be helpful if you could share an example of a chart you have in mind and where you are trying to embed it. CCiufo-WMF (talk) 22:56, 31 January 2025 (UTC)

Static versions of old charts

Can we please get static versions of the graphs that were in use just before it was switched off? This could be a category on Commons with a note left on article talk pages pointing to their associated images. Sj (talk) 22:59, 31 January 2025 (UTC)

A workaround which isn't particularly efficient, but which is better than nothing, is to use the Internet Archive to obtain the rendered graph from the article concerned from a date just before the big switch off. It seems that the JavaScript still renders the content in the archived article, and you can then obtain the rendered image in your browser. As an example, see the image in this article section. PaulBoddie (talk) 15:28, 9 February 2025 (UTC)

It doesn't seem like the Internet Archive was actually able to archive these graphs, at least not in April of 2023. For example see this archived page on Sweden's immigation policy, which shows an infinite spinner for me. --Ysangkok (talk) 20:27, 16 February 2025 (UTC)

This older version renders successfully for me, unlike the version you've referenced. I would have to remind myself when the extension was disabled, but that might be an influence here. PaulBoddie (talk) 15:12, 17 February 2025 (UTC)

Preparing for the second anniversary

Hello @CCiufo-WMF. I want to thank you for the newsletter thing that pings all of us interested no solving this issue from time to time. As we are entering February 2025, and this is a short month, I would like to know if we can start preparing for the second anniversary of this software being broken, or we are going to have it solved before we have two full years of having a "this software is broken" message in thousands of pages. Are we going to have the graphs we used to have in the next 8 weeks? Thanks. Theklan (talk) 08:46, 1 February 2025 (UTC)

@Theklan it says in the FAQ (updated since your comment, I believe) that it will be deployed to more wikis by April. So probably not. Qwerfjkl (talk) 20:00, 20 February 2025 (UTC)

Which, according to the T383079 ticket, is not going to happen. Theklan (talk) 20:17, 20 February 2025 (UTC)

April is here! Charts are not! Theklan (talk) 14:35, 2 April 2025 (UTC)

WhatLinksHere not populated

The source of commons:Data:Svartrå_migration.chart links to commons:Data:Svartrå_migration.tab.

But commons:Special:WhatLinksHere/Data:Svartrå_migration.tab is empty.

Global search works, but is slow:

Given that so many tab files could easily be graphed, it would be nice to have a convenient way to see if they already have graphs. --Ysangkok (talk) 21:24, 15 February 2025 (UTC)

Programmer contributors, boot up your bots

It would have been nice if any amount of backwards compatibility was provided, but given the low amount of resources allocated to this feature (a couple of commits per week isn't very much), I don't think the community should rely on WMF for this migration. @Arvelius did author a Python script that could help with migration. I have yet to try it out, but I will, when Extension:Chart rolls out to the wikis I am most active on. I think this the only realistic approach. A perfect migration program can't be done because of the large differences between Graph and Chart. So hacky scripts will need to be written to handle a subset, and the results have to be vetted for each individual diagram that is migrated. As @Snævar notes above, the JSON representation is too technical to rely on non-programmers being able to ever figure this out. --Ysangkok (talk) 19:29, 16 February 2025 (UTC)

To be fair, Extension:Chart has simpler syntax than Extension:Graph. I did say chart data json was unnecessarily complex, I did not say the same with graph json. Stating that I thought all JSON representation is too technical is taking my response out of the context of the tread and blatantly wrong. In my example there even was an reference to the graph json. Wether all graphs can be transferred to charts depends on whether just the mapped variables are available or also the Apertium eCharts variables - the ones that do not correspond to the mapped variables. Snævar (talk) 20:35, 16 February 2025 (UTC)

I may take a look at the script beyond a brief perusal, but I also wrote a script that parses the extension syntax and produces a data file and a gnuplot script. The challenge with gnuplot is getting measurements right, which requires manual intervention.

I also considered what kind of automated process might be undertaken by progressively paging through search results for the affected pages and processing their graphs. That wouldn't be very efficient - far better that such a process would be done against the database directly - but it would get the job done eventually.

Even though the graph generation was itself insecure, probably the easiest approach would have been to change the extension itself to generate data files, perhaps also producing well-formed metadata, so that people would be saved the bother of parsing some ad-hoc syntax.

Then, the above process could have been run to at least make those files available, perhaps in Wikimedia Commons or another venue that at least some people might be satisfied with (given the arguments about it in this discussion). PaulBoddie (talk) 15:23, 17 February 2025 (UTC)

Wikidata usage

Hi, is it my comprehension that "Chart" will never source data from Wikidata ? Bouzinac (talk) 06:34, 4 March 2025 (UTC)

@Bouzinac: There is the task T381194 for this feature. -- ZandDev (talk) 13:43, 11 March 2025 (UTC)

Newsletter update

Hi, I know this has been a long-running project and many people are impatient to see it completed despite all the great work that has already gone (and continues to go) into this. I personally that it helps to manage my impatience/expectation to receive the newsletter and see the progress being made. I note that the latest one was back in January and would love to know what has happened since then. Thanks a lot and keep up the great work! Julius Schwarz (talk) 09:54, 23 March 2025 (UTC)

An unoffical update is that further deployments are blocked on fixing the formatting for years and tooltips, in addition to supporting Visual Editor. All of these tasks are being worked on. See phab:T369944 and it's subtasks for further information. Snævar (talk) 23:26, 25 March 2025 (UTC)

Thanks @Snævar. Good to know, best of luck, and thank you so much for all the precious work! Julius Schwarz (talk) 07:51, 26 March 2025 (UTC)

Related extension: OWID Gadget

Could not find any mention about it. People here may also be interested in that extension: m:OWID Gadget (for datagraphics from Our World in Data). Prototyperspective (talk) 19:29, 27 March 2025 (UTC)

Lua Module

Hi. Your latest update about tabular data transformation via Lua modules is great! If possible, the next logical step would be to allow the creation of entirely new data objects within the same module. This doesn’t seem much more difficult; it could be imagined as taking an existing Commons tabular page and replacing all its fields. Implementing this would definitely address the biggest limitation of Chart—the inability to generate graphs on the fly—which currently prevents converting 80–90% of Graph graphs to Chart. What do you think? Thank you! IKhitron (talk) 18:54, 1 May 2025 (UTC)

Ooh, very cool ideas there. :D We're starting relatively conservative with an initial .tab page being started from (but you can replace all its data and field definitions, so it can be just a skeleton!), and the arguments for the transform are specified in the .chart definition page.

There's potential to stretch that to invocation-time argument overrides in future if that's useful... Brooke Vibber (WMF) (talk) 15:13, 2 May 2025 (UTC)

Very useful. Think for starters about the pageviews graphs that can't be used for now in dozens of articles, for each language Wikipedia (for example, article about French Wikipedia and article about Spanish Wikipedia, both on enwiki), because the template uses API for today's data. And there are many other uses. IKhitron (talk) 15:19, 2 May 2025 (UTC)

Nice, those'd make good examples to check out... Can you link to a specific one to compare with?

In general we don't have a good way to fetch remote API data unless it's specifically baked in, or to handle polling historical data over time, unless someone's doing updates to a data set manually or with a bot (which I think is how that NUMBEROF template works?) in which case selecting and formatting the data is the key job for the chart transform... :D Brooke Vibber (WMF) (talk) 17:03, 2 May 2025 (UTC)

Sure, here you can see 5149 random examples. IKhitron (talk) 17:20, 2 May 2025 (UTC)

Thanks, looks like the old template is w:Template:Graph:PageViews; it seems to be referencing a direct client-side load of data from a REST API endpoint, which is going to be a difficulty with our current model because I don't think we have a good way for Lua code to query those resources.

I'm not sure we want to add arbitrary URL loads to Lua (eg just adding Extension:ExternalData :D) so we'd probably want to talk about a clean way of querying allow-listed internal APIs, or having clean interfaces specifically for them. Brooke Vibber (WMF) (talk) 18:51, 2 May 2025 (UTC)

(I'll make some notes on what that might look like, even if we don't get to this in the first release it's very much worth investigating for a follow-up.) Brooke Vibber (WMF) (talk) 19:07, 2 May 2025 (UTC)

I really hope you'll find the solution, because it's the most important part that makes users say about Chart "It's not good enough yet". IKhitron (talk) 19:27, 2 May 2025 (UTC)

I also would like to have such functionality. One use case I have is to show campaign participants on dewiki how many photos are uploaded to a certain category on Commons. I want to add one remark: If modules can be used across all wikis through charts we should also have the modules directly available across all wikis without using them in a chart. GPSLeo (talk) 06:44, 6 May 2025 (UTC)

Feedback from pilot wikis?

Now that charts will be deployed on more projects, could there be a summary of the feedback from the pilot wikis regarding the usage of the Chart extension? I'm not talking about the technical side with reported bugs and so on, it would be more interesting to hear if there is significant use of the technology for new charts, if the new charts replaced old graphs (how many?), if the layout constraints caused problems, if wrapper templates were developed, ... Regards, hgzh 06:32, 7 May 2025 (UTC)

Charts does not use templates. It is a global system, meaning once one wiki has ported a template over to a chart and data page, it is just a matter of adding translation strings to it in your language and start using it. As far as I know, no major global templates have been translated, like Template:Graph. Charts has limited layout customization and can not fetch data from anything other than Wikimedia Commons. The backend, Apache eCharts, is capable to take anything Extension:Graph offered, but since Extension:Chart has an translation layer, we can only utilize part of it. Simple graphs can be ported over. A list of pages with Extension:Chart graphs on Swedish Wikipedia is sv:Kategori:Sidor_som_använder_diagramtillägget. Snævar (talk) 21:36, 7 May 2025 (UTC)

I meant wrapper templates, e.g. templates that wrap the chart output to allow some layout adjustments/data source linking/whatever.

Thanks for the link to the category, seems like it's not very much in use right now and all the charts have a rather big height. hgzh 09:33, 9 May 2025 (UTC)

Adding the tracking categories for itwiki and hewiki as well. Uptake was highest on itwiki, though still limited. None of the pilot wikis were heavy users of the Graph extension though. I'm not aware of any wrapper templates being widely used. CCiufo-WMF (talk) 19:51, 9 May 2025 (UTC)

Display table of data

Hi, I am slightly new to all this, but I have been following progress and have started to deploy charts where possible. However, I was wondering whether there is a possibility to simply display a table of the data tab alongside the charts. When displaying complex charts (think of a line chart when many overlapping lines), it is useful to also have a table. It would be useful if this extension could do that, so that the table would display in the same style as the chart. Julius Schwarz (talk) 09:18, 7 May 2025 (UTC)

@Julius Schwarz: This can currently be done by transcluding the data tab page. Since interwiki transclusion is not admitted, this is possible only within the same wiki, i.e. Commons. The extension therefore should be configured to address this limitation and should match the same data used for the chart. -- ZandDev (talk) 11:04, 7 May 2025 (UTC)

Thanks @ZandDev. Do I therefore understand correctly that this is feasible? Any idea whether this is/can be planned? Julius Schwarz (talk) 11:46, 7 May 2025 (UTC)

@Julius Schwarz: I don't know if this would be feasible outside Commons. I hope (with you) so in the future. I think that a Phab ticket for this should be created, as this is a new feature request. -- ZandDev (talk) 11:56, 7 May 2025 (UTC)

Done! :) Julius Schwarz (talk) 13:14, 7 May 2025 (UTC)

If you were antsy about this, you could use lua, fetch the data with mw.ext.data.get and then use Extension:Scribunto/Lua_reference_manual#HTML_library to create a table. That will work on any WMF wiki using data from Wikimedia Commons. Snævar (talk) 21:20, 7 May 2025 (UTC)

Thanks a lot for this @Snævar; I will keep that possibility in mind. In the meantime, I have enough on my plate to keep me satisfied and busy, so I will give devs all the time they need! :) Julius Schwarz (talk) 07:03, 8 May 2025 (UTC)

I always place a link to the raw data below or above the plot. For example Raw data. Why is that not sufficient in your case?

To present data from Commons as a table in a Wikipedia article, you may install and utilize c:Template:Json2table and c:Module:Json2table. (If deleted there, it is also available at sv:Template:Json2table and sv:Module:Json2table, but with documenation in Swedish). If installed on your wiki, you may just write <code>{{Json2table|dataset=Chart Example Data}}</code> to generate a table. @Julius Schwarz: . Tomastvivlaren (talk) 00:04, 9 May 2025 (UTC)

Thanks for the tips. This is for use across several Wikipedias where this charts using this extension would also be displayed, so I cannot separately install things and it would just all fit nicely together :) Julius Schwarz (talk) 06:56, 9 May 2025 (UTC)

Hi @Julius Schwarz, thanks for filing the phab task (T393597 for reference) -- it makes sense. We prototyped an approach for supporting this previously but it needs some more work before being ready for use on wikis. As others have said, the best option in the meantime is to transclude the tab data. I understand that has its limits though, notably that you'd have to transclude it everywhere the chart is invoked to get the same effect. We'll use the update the Phab task if there's any progress on this. CCiufo-WMF (talk) 19:25, 9 May 2025 (UTC)

Thanks for the update @CCiufo-WMF, much appreciated! Nothing too urgent here and I do not need to create tables everywhere manually just to remove them once this is ready; happy to wait until this is available! Julius Schwarz (talk) 20:34, 9 May 2025 (UTC)

Link back to raw data. Formatting image frame, caption and link?

I have five questions:

1. I think that the .chart page at Wikimedia Commons should include a link back to the raw data at the .tab page. It takes too many clicks to find the corresponding .tab page.

2. I also think that it is a good habit to always place a link back to the Raw data near each chart on Wikipedia, for example by means of the code <center>[[c:data:Chart Example Data.tab|'''Raw data''']]</center>. Or using a pen, or just calling it "Data"? Centered or right adjusted? Should it be placed immediately after the plot, or after the caption? Or sometimes above the chart, to the right of of the heading on the top of the image frame or a table?

3. How should the caption, including a citation, below the chart typically be formatted? "Source: Title^[1]"?

4. I often include the chart in an image frame or a table. Sometimes with a local heading. On the desktop version it is shown to the right of the text. I have to be careful that it is also visible on mobile devices. Is this a good habit?

5. I believe that local templates will be created to harmonize the formatting of links, citations and image frames, if the ¤chart magic word can not handle links to raw data.Should it be called Template:Chart if that is available on the local Wikipedia? I got the impression that you guys dislike templates. You prefer advanced html code and wiki code near every chart in every article? Tomastvivlaren (talk) 12:49, 9 May 2025 (UTC)

Hi @Tomastvivlaren, I'll try my best to answer your questions. Apologies for the formatting.

1. I think that the .chart page at Wikimedia Commons should include a link back to the raw data at the .tab page. It takes too many clicks to find the corresponding .tab page.

Agreed, this is tracked in T382806.

2. I also think that it is a good habit to always place a link back to the Raw data near each chart on Wikipedia, for example by means of the code <center>[[c:data:Chart Example Data.tab|'''Raw data''']]</center>. Or using a pen, or just calling it "Data"? Centered or right adjusted? Should it be placed immediately after the plot, or after the caption? Or sometimes above the chart, to the right of of the heading on the top of the image frame or a table?

Yes, makes sense. If I'm understanding correctly, this is the same request captured in T393597.

3. How should the caption, including a citation, below the chart typically be formatted? "Source: Title^[1]"?

My thinking is that the solution to T382806 should also solve attribution, so a dedicated caption is not needed. In the meantime, what you suggested makes sense.

4. I often include the chart in an image frame or a table. Sometimes with a local heading. On the desktop version it is shown to the right of the text. I have to be careful that it is also visible on mobile devices. Is this a good habit?

It's a bit difficult to provide guidance without specific examples. Right now Charts should fill the container they are placed in, so if that container is responsive to both desktop and mobile screens, then I think it should be fine. Support for additional sizing options is captured in T376845.

5. I believe that local templates will be created to harmonize the formatting of links, citations and image frames, if the ¤chart magic word can not handle links to raw data.Should it be called Template:Chart if that is available on the local Wikipedia? I got the impression that you guys dislike templates. You prefer advanced html code and wiki code near every chart in every article?

I'm not sure if I fully understand the question, but as I mentioned above the goal is to not need things like additional links and citations to be added because they'll be rendered and localized as part of the Chart. We're not against templates, we just don't want to have to rely on them for key features because they are scoped to the wiki. Could you provide an example of what you mean by advanced html code and wiki code near every chart in every article? CCiufo-WMF (talk) 19:42, 9 May 2025 (UTC)

Thankyou for a well-informed answer!

2. What I suggested is a clickable link back to the .tab page, for example called "raw data", or a pen, near the chart. That is normally preferable over a table in the article, since it allows users to edit the data, download as spreadsheet, etc, and since the tables typically could be too large. Could the chart magic word allow something like: {{#chart:... .chart|datalink="center below/right above/only/off"}}?

An alternative to a raw data link is that clicking on the chart would lead to a full screan view of its .chart page, where you will find a link to the corrensponding .tab page. That would require two clicks instead of one.

But, support for creating collapsible tables near the the plot using the #chart magic word might also be interesting. You can already now can do this using the sv:template:Json2table template and module. Does T393597 imply that I have to create a .table page on Commons for each table view (each subset of rows and columns) that you may view in various articles? That is tidious work.

4. Great. Now, most plots are way too high. And some of them have too many curves. So, imho, allowing heights and a choice of subesets of columns and rows (I.e. choosing curves), are the two most important things that should be fixed before Extension:Chart is made available on all Wikipedias. Otherwize there will be a lot of unncecessary work to do after these issues are fixed.

5. Example of advanced html noe included in some Wikipedia articles, to make the link right adjusted: <div style="float: right;">[[c:Data:Example.tab|'''Raw data''']]</div>. You can see it in the following article: https://sv.wikipedia.org/wiki/Polismord_i_Sverige#Statistik . Advanced code should always be avoided in the articles, and the layout should be harmonized. That is why a chart template will be created on each local Wikipedia, as soon as #chart are more stable - at least if #chart does not support layout options.

Tomastvivlaren (talk) 12:04, 10 May 2025 (UTC)