New task: T397786

I did try to change the error output to something like <wiki-chart data-mw-chart='{"error":true}'><div class="cdx-message--error" ....</div></wiki-chart> to make regular charts and error charts use the same tag name, but unfortunately Parsoid breaks that because it believes <wiki-chart> is an inline tag and can't contain block tags (which is inaccurate, custom elements are allowed to contain block elements).

This wasn't actually related to T393306. Error charts have the same RDFa type and data-mw information as regular charts. The issue was that the chart node type inherited from MWTransclusionInlineNode, but error charts are <div>s, and inline nodes can't match block elements. But this was wrong anyway, because <mw-chart> elements are styled as display: block, so we should have been using MWTransclusionBlockNode all along. Fixing this also fixed this bug.

In T374061#10929291, @bvibber wrote:

Two issues I notice trying to implement this:

1. Changing it to pass all items in the source not already handled by the base class will alter our output to potentially include other data that we currently strip. Is this fine or a problem? (I think it's fine.)

I think that's fine. The service will ignore things it doesn't understand.

Was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/JsonConfig/+/1162031 (but I merged that before I realized this task existed, so it's not tagged with this task)

Client-side rendering failures per hour (computed as number of renderStart events minus number of renderEnd events)

Well that didn't work great. Because the renderStart and renderEnd events don't happen at the same time, and sometimes fall in different hours, the "rendering failures per hour" metric that I tried to derive is sometimes negative. So I'm just going to instrument failures separately, rather than trying to derive them.

In T397018#10921505, @Alladyn21 wrote:

I made a docker with 1.44 and I confirm that everything works like a charm. Sorry for the confusion.

No problem! I'm sorry for the inconvenience, and that MW didn't give you a clearer error for whatever reason.

In T397018#10918533, @Alladyn21 wrote:

mediawiki:1.43.1
Charts latest.

My suggestion:

• Set a default X-axis directionality for each language. For LTR languages this would be LTR, and for most RTL languages it would probably be RTL, but it might depend on each language's conventions (it's possible that Hebrew might want the default to be LTR for example)
• Allow users to override the directionality of the X-axis for each individual chart invocation, something like {{#chart:My thing.chart|dir=ltr}}

My 2 cents: I see charts as content, so I think they should be in the language that matches the content around them, not the language the UI is in.

@aude and @CDanis this task is pretty old, how much of this has been done by now, and what if anything is still needed here?

@bvibber Is there anything left on this task, or is this done? Could you close it if so?

Unfortunately the i18n string mapping isn't a simple lookup, it involves language fallbacks, and those fallback chains are most easily available in PHP. See the implementation of JCUtils::pickLocalizedString().

So sorry for the extremely late response!

In T395462#10881033, @bvibber wrote:

The chart-renderer-side patch appears not to match the client-side patch, which I didn't catch until deploying it., leading to all client-side rendering failing on new page renders. chart-renderer was outputting data-mw-chart="true" and data-chart="...json data..." but the client-side code was looking for JSON data inside data-mw-chart.

I've reverted the chart-renderer patch and restored the previous version to production for now.

Another different but related use case is what DiscussionTools does, where it holds itself back from sending certain notifications (or sending them to certain people) if it knows that other notifications about the same edit are already going to be sent. In the new system we'd probably want to achieve this by batching the notifications for the same domain event, and sending them through the middlewares together, so that the middlewares can make these kinds of deduplication decisions.

The .chart page syntax looks good to me. I think a good way to start would be to build that part first, because we know we'll want that regardless of what we do for invocations.

Looks like the first and third paste are identical (except for the comment distinguishing them), so that's great!

[2025-02-12 12:01:17 PST] catrope:~/tmp$ colordiff -u Codex_Design_Tokens_export_before_after_stylelint_3.9.2_→_4.3.3 Codex_Design_Tokens_export_after_stylelint_3.9.2_→_4.3.3_without_.reverse\(\) 
--- "Codex_Design_Tokens_export_before_after_stylelint_3.9.2_\342\206\222_4.3.3"	2025-02-12 12:01:09.938469760 -0800
+++ "Codex_Design_Tokens_export_after_stylelint_3.9.2_\342\206\222_4.3.3_without_.reverse()"	2025-02-12 12:01:17.424764127 -0800
@@ -1,5 +1,5 @@

In theory we shouldn't have code in core that checks if an extension exists. In practice, we do have that in a few places, although those tend to have TODO/FIXME comments lamenting the hackiness of that approach.

Yes, this is done. It's still used in one place but its use is discouraged elsewhere, that's good enough for me.

Whoops sorry, I missed the previous exchange between you and Anne about the demo, ignore me.

The attached patch looks good to me. @bmartinezcalvo could you review the new demo here?

Related: T341351, T312142

Remaining questions/explorations:

• Handle CSS without a FOUC, and render any CSS at all when JS is disabled
• Should we use Vite, or switch to Rollup? Can we support CJS .vue files with either?

In T313945#10511079, @SD0001 wrote:

In T340460, there are three patches awaiting review that make it easier to use Vue in gadgets. Is someone be able to review them?

It's hacky but it looks like it should work for now. I think we should consider making menu headers a real feature in the future so that RCF doesn't have to do these kinds of hacks, but that doesn't have to be a blocker for RCF anymore.