• By default make the chart 100% width, and 448px height. If both must be expressed in terms of pixels, I'd suggest using 1000px as that's consistent with the maximum content size on Vector 2022. For non-fullscreen use 512px x 448px.
  • In Data namespace if height is present, use that instead of the default. Ignore the width option. Don't allow that to be modified.
  • Default to full screen
  • Update the parser function so it only accepts a fullscreen parameter and doesn't accept width or height parameters e.g.

Created a follow up tasks:

Just a technicality, the labels are for the grid values along the axis (e.g. 1950, 1953 ...)

Should the chart definition have a title property? The chart definition is more of a "template" that can be combined with various sets of tabular data so the title could be more specific to the invocation of the parser function, thus a parser function option.

In apache echarts, when rendering an svg, we need to provide some dimensions. This is required for svg (SSR) whereas client-side rendering can have automatic sizing based on the DOM container.

Parser tag version of the chart syntax, with ignoring anything inside the tag:

I could be missing something, but it looks like the VisualEditor does not appear to support parser functions as well, compared to parser tags.

Follow up todo items:

https://zod.dev/ could be useful for validation in the service

Add the chart-renderer service to the list of trusted projects:

Here is the task for the symbol size and symbol shapes option in the chart definition:

The graph template also has an option for setting line width

The only remaining part of the chart definition to support is the interpolation option.

@Pietrasagh For the initial demo, we are limiting showSymbols to true and false, but will consider if/how we can support the other options for symbol size, line width etc.

So far, here is what the script can render :

the patch doesn't yet handle these options in the chart definition:

For building this as a node service, is it still recommended to use service-template-node? I noticed that it has some security issues, seems a bit outdated and not sure how well maintained it is.

alternatively, a new, separate project for multi-content revisions would be okay

interwikis work now among hifwiktionary and other wiktionary projects:

(re)populated the sites table.

this still happens :/

In T182326#3821144, @Addshore wrote:

In T182326#3821139, @daniel wrote:

@Addshore in which way would it be confusing? Who would be confused? What is test2wiki used for, specifically?

Test2 is primarily used to trial and debug global and cross-wiki features in conjunction with https://test.wikipedia.org and https://test.wikidata.org.
Test2 has been in gorup0 for rather a long time, and if people expect that and we change it, well, confusion follows.

Adding a wiki is not as easy as it should be, so I suppose Ladsgroup is trying to avoid that trouble. If it was easy, I would also opt for a new wiki with a more descriptive name... though I can't think of one off-hand.

@greg Both make sense, but making a new wiki is more overhead. The only reason to do that is to avoid confusion, as Adam says. Not sure how bad that confusion would actually be though.

If making a new wikis is too hard then lets use something we have, but I think a new site would be the 'best' option.

fixed by https://gerrit.wikimedia.org/r/#/c/394642/ (in review)

MediaInfo is no longer included in the build and we are killing the build anyway

@hoo ok :/

we had dispatch lag again today (enwiki especially lagged).

such css rule could be added to https://www.wikidata.org/wiki/MediaWiki:Common.css if this is something most users want. Otherwise it can be added to user css or maybe a gadget

@Krinkle is it okay for this to wait to go out w/ the train next week or should we consider a backport?

we can disable the notifications for wikibase changes sent to the clients

Wikidata.localisation.php uses $wgWikidataBaseDir, which could be set/managed outside the build

looks like the spam has stopped