One of the possibilities we discussed is to *allow* the orphaning to happen, but to then show warnings about this condition, eg. in the reflist. The task title should be tweaked to reflect this.

A related issue we still need to look into: when using VE section editing on mobile, we need to continue to support subrefs whose parent comes from another section. We also need to be able to reuse refs from elsewhere in the document.

I showed some of these issues to a RTL editor and he was able to verify the brokenness. Angle brackets and slashes should not move. He would be interested in seeing CodeMirror enabled on his wiki—and the new CodeMirror actually fixes some of the bidi issues. The LTR text with footnotes should not appear in the current order, basically a ref should stay next to its statement.

I'm very interested in getting bug reports about this area of Cite at the moment since work is active, as you can see, and it's easy to make mistakes when there are such a huge number of combinations of customization being applied. Thank you for taking the time to open a task!

Noting here that Kartographer is already broken for wikis that use LanguageConverter, but I can't find a good reference in Phabricator at the moment. The issue as I remember it was that language codes used to cache map snapshot images are simplified and couldn't distinguish between eg. zh-Hans and zh-Hant (or between zh and zh-Hans for that matter).

Yes, thanks I'll make sure to send an update in this week's Tech News!

@Quiddity Thanks for the nudge—I've been concerned about the lingering bug here, as I can see that there are more wikis affected than I expected, and the workaround hasn't been applied anywhere yet.

In T370512#10009993, @Escargot_rouge wrote:

Yes, what struck us at first were the lonely 0s, but the actual issue is that we want to remove the brackets. This applies to decimal counters, as well as to alphabetic and Greek ones.

cite_reference_link
9 wikis wrap the square brackets in extra <span> to be able to style them individually, different from the number.

Reopening because the cause and solution are different than in the other, closely related bug.

Thank you for the detailed bug report—yes this was definitely a result of my recent change. I would recommend as a first step that you remove the custom CSS, if that's acceptable?

One point which I feel is important to keep in mind when discussing deprecation or a major upgrade is that some good decisions were made early in the course of the project, which led to the map annotations being written in a standard format GeoJSON, plus light MediaWiki wikitext additions of course. And some ability to connect to Wikidata and OSM data sources. So the user data is quite portable, whatever we decide to do next.

@elukey I'll split off the usage investigation into a subtask. Some questions come to mind about exactly what we want to measure, for example whether we want to look at reader usage, and whether we want to compare against the other technologies for adding maps.

I've just attached a slight tweak which successfully builds on nodejs18 and uses upstream mapnik: https://gerrit.wikimedia.org/r/c/mediawiki/services/kartotherian/+/880495

These are indeed replaced using CSS, although they're static text as you pointed out. The rule is using content to replace text.

The last time we did an analysis of maps usage was June 2023, see this spreadsheet. The results were tainted by some problems with the Enterprise dumps at that time, but we can say the numbers here are the minimums. Maps are tallied in columns H-L, and you can see there are 5.1M pages which include a Kartographer map, most of which are directly coded into the article rather than transcluded with something like wikivoyage's {{mapframe}}. If it's helpful, I can run the analysis again, produce a list of pages, etc.

Sounds good, and I think that Tech Wishes can offer some emotional support and code review but just to be clear, I don't think we can offer to drive the main effort.

Yes, +1 this is the most problematic dependency. We'll need to use the upstream node-mapnik and libmapnik-3.1, see T327396: Migrate Kartotherian to node-mapnik v4.2.1 and unfork . We have multiple proofs of concept which successfully upgrade other versions of node, I think you're on the right track to make these changes in the blubberfile first.

In T370027#9981069, @Izno wrote:

You might want to take a look at https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Cite_CSS from a year or two ago. And the subpage https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Cite_CSS/Technical_details . CSS was mass-added in many Common.css pages to support this.