Wikimedia Hackathon 2024 (chat via Telegram at https://t.me/wmhacks) is ongoing. I hope this be given some attention and collaboratively discuss a path to a resolution.

For those attending the hackathon, please find @Catrope if you'd like to discuss the proposed new path forward for graphs.

Just updated few broken links. Sorry for extra notification.

Wikimedia plans to develop Charts as a replacement of Graph.

Ciao

Ciao

@Emanuel2010Nikolli: This is not a chat forum. Please refrain from adding such comments - thanks!

Its been TWO YEARS and you guys haven't fix the problem?

In T334940#10757050, @Andrewbdfe wrote:

Its been TWO YEARS and you guys haven't fix the problem?

See Charts

To summarize a bit for those who may not have been following developments: The Graph extension, as it previously existed, will not be re-deployed to Wikimedia sites as it is not possible to do so securely. It is being replaced for some uses with the Chart extension. As a pilot, an initial version of the Chart extension has been deployed to mediawiki.org, Commons, the test wikis, and the Hebrew, Italian, and Swedish Wikipedias. You can see some example charts at https://www.mediawiki.org/wiki/Extension:Chart#Types_of_chart. While testing on those wikis, some problems were identified that have delayed the rollout to further wikis, which was previously expected for this month. You can read the plans for the continuing development of this system at https://www.mediawiki.org/wiki/Extension:Chart/Project and follow updates at https://www.mediawiki.org/wiki/Extension:Chart/Project/Updates.

The Charts extension has now been deployed also to English Wikipedia. For those interested in re-enabling interactive charts by converting graphs to the new Chart extension, see this tool graphDataImport which makes this quick & easy and also the alternatives in the See also section there. Anything related to any of this can be asked in this new WikiProject.

This will fix graphs with static data. We still need a solution for pageview graphs.

In T334940#10883822, @Prototyperspective wrote:

The Charts extension has now been deployed also to English Wikipedia. For those interested in re-enabling interactive charts by converting graphs to the new Chart extension, see this tool graphDataImport which makes this quick & easy and also the alternatives in the See also section there. Anything related to any of this can be asked in this new WikiProject.

this solution is limited to a small subsets of graphs.

In T334940#10893051, @Theklan wrote:

this solution is limited to a small subsets of graphs.

See T396269: [Epic] Charts should work at least for the use cases graphs had instead.

The Graph extension is being archived. Should we keep this task open? There's lots of wishes in this, but not listed as specific sub-tasks; many are explicitly tasks in the Charts extension, like T393500: Support page view graphs in Charts extension (Graphs parity request) or T396269: [Epic] Charts should work at least for the use cases graphs had. I think it would be better to focus efforts on those Phabricator tasks and not try to also keep this open.

I believe we need to be able to migrate pages still using <graph> tags.

As this is still broken, and no solution is given to most of the graphs used, it should remain open.

In T334940#11213506, @Bugreporter wrote:

I believe we need to be able to migrate pages still using <graph> tags.

Absolutely. However, is tracking edits to the wikis something reasonable to track in Phabricator? Would an on-wiki project post on each wiki work better?

The problem is that the solution given can't be used to replace the broken graphs, at least at euwiki. So this is not an on-wiki project, this is a core issue of a deficient solution.

I lean towards closing this ticket now that we know that 1) Graphs will never be re-enabled and 2) Charts has been created and is deployed.

I think it'd be more organized. The replacement for this ticket would be to file smaller tickets (corresponding to missing features) and tag the Charts extension. I imagine a bunch have already been filed.

Perhaps a new ticket "New Charts extension should achieve 100% feature parity with old Graphs extension" should also be created, and any features that are missing in Charts and were present in Graphs should be made sub-tickets of that. It could be tagged "Epic" and help to track the missing features.

Perhaps a new ticket "New Charts extension should achieve 100% feature parity with old Graphs extension" should also be created

T396269

The issue remains.

On the Czech Wikipedia, a discussion took place in technical Village pump (see here) on whether the Chart extension could fully replace the Graph extension. The conclusion was negative: many functions are missing, and several others work only with significant problems.

In T334940#11213588, @Novem_Linguae wrote:

any features that are missing in Charts and were present in Graphs should be made sub-tickets of that

Well yes, but also no, as i don’t think feature parity should be a goal in itself. Useful features, that scale and will be well used by many people, sure, those can be considered.

In T334940#11213978, @Jklamo wrote:

many functions are missing, and several others work only with significant problems.

Many isnt really a useful description. I advise filing tickets for specific features and bugs, together with examples of how to use and/or what the expectation is that is not being met by the current feature set.

There are a good bunch of tickets filled with those, but the problem is a design problem: the team solved something without looking first on how the software was used. That's why the new charts thing is not able to replace the old graphs. You can see that there's still a huge amount of broken graphs.

The Charts extension does a lot of things right that Graph did wrong (no XSS-by-design, mobile-friendly, can do cache invalidation, separates data and presentation...). The flip side of that is that it is less flexible, so recreating every single thing somebody did once with Graph is not going to be feasible. No harm in making tasks about those things but IMO (personal opinion etc etc) the expectation should be that most things that aren't supported today in Charts will remain unsupported, and people should look for alternative approaches (in many cases, plain old images aren't that much worse than their superficially-interactive variants).

most things that aren't supported today in Charts will remain unsupported

Are you saying that our engineers took a software that will be unable to do "plot a point at x=2, y=5 and another one at x=3, y=6". Because that's a very wild declaration.

people should look for alternative approaches (in many cases, plain old images aren't that much worse than their superficially-interactive variants).

We should focus on T334372: Add support for inline SVG which will potentially solve most use cases - I believe it would be the solution to what Chart can not solve.

Could someone say, what exactly the problem to recreate PageViews charts, that worked on Graph? They can't be implemented by datatables on Commons (because this data updates every day), but what's the problem to got data from the source where Graph got this data? Ruwiki has had pageviews graph for every page on "About this page" special page and on many talk pages, and all of these graphs was destroyed by disabling Graph and wasn't restored even now. What. Exactly. The. Problem?

In T334940#11214099, @MBH wrote:

Could someone say, what exactly the problem to recreate PageViews charts, that worked on Graph? They can't be implemented by datatables on Commons (because this data updates every day), but what's the problem to got data from the source where Graph got this data? Ruwiki has had pageviews graph for every page on "About this page" special page and on many talk pages, and all of these graphs was destroyed by disabling Graph and wasn't restored even now. What. Exactly. The. Problem?

Please note even we can already recreate most charts with HTML+CSS via Lua module (e.g. https://en.wikipedia.org/wiki/Module:Sandbox/Bawolff/canvas), until we resolved T298310: Way to access pageview data via wikitext, we can not recreate pageview graph in pure Wikitext+CSS.

Why this is needed for recreation of pageviews? Graph worked without this magic word.

we can already recreate most charts with HTML+CSS via Lua module (e.g. https://en.wikipedia.org/wiki/Module:Sandbox/Bawolff/canvas)

One point to note is it is just a hack instead of a proper solution - the "chart" created via div+css is not a proper image you can download. A large number of similar templates exist (e.g. https://en.wikipedia.org/wiki/Template:Pie_chart), but they suffer from the same problem.

Graph allowed basically-arbitrary data sources, with all the security/privacy/stability risks that entails. Charts doesn't.

Adding pageview graphs to the about page should be straightforward to do inside the PageViewInfo extension (using d3 or whatever), someone just needs to do it. (The task is T43327: Add page views graph(s) to MediaWiki's info action for Wikimedia wikis.) No point in involving the Charts extension in that.

The task for Charts support is T393500: Support page view graphs in Charts extension (Graphs parity request). (Personally I'd question the need. Graphs are pretty, but are they actually useful? 99% of the time you don't care about pageviews; for the 1% the talk page can just link to toolforge.)

In T334940#11214130, @MBH wrote:

Why this is needed for recreation of pageviews? Graph worked without this magic word.

Graph could invoke external data source (e.g. pageview and WDQS), where Wikitext can not.

I'd just like to remind everyone that WP:IDONTLIKEIT complaints are unlikely to change hearts and minds. Individual tasks for individual missing features along with justification as to why that particular feature would be useful will be more likely to yield results.

Why not allow to use external data? External data could easy be safe, for example if it's in JSON (and mediawiki API returns pageviews data in json and XML, also MW API couldn't return destructive data at all).

In T334940#11214087, @Theklan wrote:

most things that aren't supported today in Charts will remain unsupported

Are you saying that our engineers took a software that will be unable to do "plot a point at x=2, y=5 and another one at x=3, y=6". Because that's a very wild declaration.

Folks have already figured out how to do that: https://commons.wikimedia.org/wiki/Module:Graph:Chart (β).

In T334940#11214150, @Tgr wrote:

(Personally I'd question the need. Graphs are pretty, but are they actually useful? 99% of the time you don't care about pageviews; for the 1% the talk page can just link to toolforge.)

+1

In T334940#11214179, @MBH wrote:

Why not allow to use external data? External data could easy be safe, for example if it's in JSON (and mediawiki API returns pageviews data in json and XML, also MW API couldn't return destructive data at all).

Different kinds of external data have different nature, so please specify which one. For pageview please discuss further at T393500 (for charts) and T298310 (out of charts), not here.

In T334940#11214179, @MBH wrote:

Why not allow to use external data? External data could easy be safe, for example if it's in JSON (and mediawiki API returns pageviews data in json and XML, also MW API couldn't return destructive data at all).

I imagine there are concerns over potential stability and performance risks of depending on data sources that might not have the same service guarantees as prod does.

[More so for wdqs than page views]

For WDQS: The eventual solution is queries be stored in some pages with cached query result. Please discuss this long-term solution at T67626: [Epic] Support for queries on-wiki (automated list generation) and T248442: Provide option to embed Wikidata query service result on-wiki, not here.

Are you saying that our engineers took a software that will be unable to do "plot a point at x=2, y=5 and another one at x=3, y=6". Because that's a very wild declaration.

Folks have already figured out how to do that: https://commons.wikimedia.org/wiki/Module:Graph:Chart (β).

That's great news. I wonder what else is neede to have those x and y imported from Wikidata QS, instead of hardcoded there.

Honestly, it is hard to understand this chart for an an average or less technical user compared to graphs.

In T334940#11214778, @Exec8 wrote:

Honestly, it is hard to understand this chart for an an average or less technical user compared to graphs.

At least Chart will not involve Vega syntax and for chart with static data it is more easy to build. What is the problem today is to support data sources that are not static dataset.

The Graph extension is being archived.

Crosslink for future reference: T405550: Archive the Graph extension

T405861: Add support for generating non-interactive SVG images via Scribunto are able to replace several kinds of graphs and charts. The only problem nowadays is graphs with off-wiki data (e.g. pageview and WDQS).

In T334940#11292320, @Bugreporter wrote:

T405861: Add support for generating non-interactive SVG images via Scribunto are able to replace several kinds of graphs and charts. The only problem nowadays is graphs with off-wiki data (e.g. pageview and WDQS).

SVG graphs needing to access pageviews seems like an easily fixable problem: T362937.