Once this is deployed on the beta cluster, this page should display an area chart: https://commons.wikimedia.beta.wmflabs.org/wiki/Data:2022_US_energy_consumption.chart

I was still getting the old styles, so I manually purged https://fa.wikipedia.org/w/load.php?lang=fa&modules=ext.dismissableSiteNotice.styles%7Cext.echo.styles.badge%7Cext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cext.wikimediamessages.styles%7Cmediawiki.ui.button%7Coojs-ui.styles.icons-alerts%7Cskins.vector.icons%2Cstyles%7Cskins.vector.search.codex.styles&only=styles&skin=vector-2022 (using the instructions for one-off purging). That fixed it for me too.

This is now working on some page views but broken on others, presumably because the old stylesheets are still cached. I'll see what we can do to purge whatever cache is in play here.

Fix is scheduled for deployment on Monday September 2nd at 20:00 UTC.

In T373676#10106614, @matmarex wrote:

FWIW, I see the issue described in your first comment at all three of the links provided. The icon has a margin-right on both LTR and RTL, when presumably it should be flipped to margin-left on RTL.

Codex has its own flipping implementation: https://gerrit.wikimedia.org/g/mediawiki/core/+/b5a1f97c2eee8dc47c5f20d63eaf6c263083e5af/includes/ResourceLoader/CodexModule.php#213 so this is probably best left for the team to debug.

This request is now ready to be acted on

Updating this a year and change later:

• inset, inset-block-start, etc. are now well supported in all browsers (since April 2021)
• border-start-start-radius etc. are now well supported in all browsers (since September 2021)
• Support for float: inline-start and float: inline-end was added to Chrome somewhat recently (October 2023)
• background-position still doesn't have logical versions of the left and right keywords, and this isn't even in the spec yet. The CSS Working Group is still trying to figure out how to do this, and has been off and on since at least 2015. Right now keywords like x-start and x-end are included in the current draft of CSS Backgrounds 4, but that draft isn't ready yet, and figuring out how to make start/end work is one of the things holding it up.
• The other complains in the article @TheDJ linked to relate to top-to-bottom languages, and while it would be nice to get support for those too, we're focused on just LTR/RTL for now so they're not relevant to this task. (Support for vertical writing modes would be great, but there are likely to be bigger problems with that beyond logical properties.)

In T370378#10089242, @Krinkle wrote:

The reduced scope LGTM. But, the name and description implies it would be re-used for other transclusion-like semantics as well. That seems fine, except that it assumes unrelated transclusion-type features would be hosted only on Wikimedia Commons. Do we want to commit to that?

Probably not. @Jdforrester-WMF mentions Wikidata and Wikifunctions, which both involve transcludable content hosted on wikis other than Commons.

In T370378#10094335, @Ladsgroup wrote:

Random further notes on the schema but they are clearly on the details. General idea looks good. I agree with krinkle and either direction he suggested sounds good to me (I slightly prefer the first one since overhead of extra tables is large but if they are per wiki, central tables, specially the ones in x1, don't have any extra overhead):

Now that :dir() is finally available in all browsers (since December 2023), maybe we could bypass this entirely, and use :dir( ltr ) and :dir( rtl ) instead. That would solve a lot more problems: it would eliminate the need to carefully manage dir attributes, and would support nested directionality.

I agree with Eric, I prefer option 0. I don't think making the selection a full MenuItem object makes sense.

@aude suggests using https://zod.dev/

In T370378#10084787, @Ladsgroup wrote:

Actually, it's much easier to maintain three large tables than one gigantic one. From DBA perspective it's better to keep them separate.

Understood. Instead I'll just propose one global links table for transclusion-style usage then (revised schema below). We can then use a similar schema for images, but that wouldn't be in scope for this task.

Here's how I would suggest we could most productively explore this:

• Think about what an event type registry in MW core would look like. This would be something that Echo events could be ported to, and that Enotif could also use.
• Implement this registry in a proof of concept patch in MW core, but don't implement the behavior behind it yet. In other words, allow event types to be registered, but don't actually implement the logic for recording and delivering events etc, only implement the registration mechanism.
• Do the same things for a delivery type registry
• Design the event firing API (and maybe implement a mock one, but don't spend time trying to make notifications actually work)
• Sketch out how Enotif would use these things
• Sketch out how things that currently use Echo would use these things

I did that because it was also blocking merges in the Charts extension, e.g. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Chart/+/1063857 . FWIW the Chart extension doesn't contain any ResourceLoader modules and doesn't affect how much code is loaded on page views, so I found this bundlesize failure blocking the CI there unexpected to say the least.

This breaks all attempts to create a wiki with the default set of extensions on the new PatchDemo

Notes from my initial look at this in July:

• I think the menuItems reactivity issue might be because Menu sets a shallow watcher on menuItems, not a deep watcher. We could either fix this by setting a deep watcher, or we could document that reactivity for modifying individual menu items in-place (meaning, modifying one of the individual MenuItemData objects without modifying the overall menuItems array) is not supported and a computed ref must be used.
• initialInputValue is not reactive by design, because of the "initial" part of its name. We could consider supporting reactivity for this prop but I think that would be tricky, because we wouldn't want a change to initialInputValue to have any effect if the user has already modified the value of the input

@Ladsgroup while I'm already picking your brain here... do you think it would make sense to normalize link targets in this new table, similar to how this works in MW core?

In T370378#10059305, @Ladsgroup wrote:

I've been meaning to migrate global usage table to a shared table in x1 to reduce the confusion of other wikis reading and writing to s4 database and also reduce the size of overly large s4. Even though the new table won't take much space I suggest using virtual domains put it in x1/wikishared, the only downside would be that you wouldn't be able to join with core tables and it won't be replicated to the cloud (we will fix the latter eventually but not right now). That would make the future migration of the globalimagelinks table easier too.

In T370378#10053729, @Tgr wrote:

Core has multiple tracking tables because you might want to record different relationships for the same pair of pages (an article can include an image, transclude the image description page, link to the image description page...). Should the generalized global usage tracking table have a "type" or "purpose" field? There is no overlap between image usage and tabular data usage, but in the future we might want to track things that aren't separated by distinct namespaces.

This is a good point, I think there should be a type/purpose field. MediaWiki core recognizes the three types of relationships between pages that you listed (A links to B; A transcludes B; A embeds B as an image) and one more (A is in category B), but it tracks these three things separately using almost identical DB tables and ParserOutput APIs (the pagelinks and templatelinks schemas are identical; imagelinks differs only in that the namespace is implicit, and categorylinks has some extra data). Merging these tables into one is probably too ambitious for now, but I think it makes sense to create one global table for this purpose rather than three, and use a field to distinguish the different relationship types.

My opinion is that it probably doesn't make sense to allow local chart/tab pages to be created. I think it would be confusing, would discourage sharing them on Commons (which is something we want to encourage, not discourage), and I think it wouldn't be worth the engineering effort (which is likely significant, because I don't think the JsonConfig extension wants to be set up this way).

See the patch attached to this task and some of the test cases in it. There are missing state transitions for yield in expression-related states right now, so in my mind that has to cause bugs.

Thank you for weighing in everyone! I think we've gotten enough useful advice here that we can close this task and move forward with building a service based on service-runner and Express, and deploying that using a Docker container image built with Blubber and Github CI per this wiki page.