we will make Cite a mandatory dependency.

My opinion:

• Allow the backslash as well as an empty line (as suggested above), but don't require either.
• However, enforce a space before the backslash in case a backslash is used. I find this important. Otherwise people would wonder what T1234\ is.
• I was thinking about disallowing the backslash in the last line. But I realized this is identical to the question in T222042: Add sniff to require trailing commas in multiline arrays. The loose consensus seems to be that the extra (but technically not needed) comma at the end is usually a good idea. I think we should do the same here and allow the backslash in the last line, but don't require it either.

Individual developers started collecting a few first candidates in https://docs.google.com/document/d/1svfo3L8aBirUPb0CR293TTUYxsHXd0S3AfdqqkPPdnk/edit#heading=h.80g64b9w7ejo:

• T349068: Cite: Argument 1 passed to Cite\AnchorFormatter::refKey() must be of the type string, null given
• T343230: Cite's use of dynamic Parser::$extCite should be rewritten/removed
• T298278: Broken links between marker and footnote when name contains certain HTML entities
• T299280: Message cite_error_ref_too_many_keys is confusing
• T297430: cite_ref shows different letter (თ) than cite_note (ჱ) on Georgian Wikipedia

We dug a bit deeper into this last week and found:

• The remaining issue with non-breaking spaces might be surprisingly easy to fix, see https://gerrit.wikimedia.org/r/977091.
• Turns out the web browsers require slightly different encodings in the href="#…" attribute vs. the target id="…".
  • The id attribute is pretty much plain text. Obviously " must be encoded as ", and any other character can be encoded as an &…; HTML entity as well. But that's normal HTML behavior and mostly unrelated. What matters is that % don't have a special meaning in the id.
  • This is different in the href where % do have a special meaning. The browser decodes %-sequences in the href once and only then tries to find the matching target id.
• This can be extra confusing because not every % does have a special meaning. Only % that are followed by a valid hex sequence.
• The Cite code generates the id once and uses it in both places, the href an the target id. What's notable is that Cite doesn't do any encoding. Instead it uses the MediaWiki parser to parse the two wikitext snippets [[#…]] and <li id="…">.
• The behavior of the wikitext parser is quite different when it comes to %-encoded entities. This is not wrong. It's just not the same behavior as in a pure HTML <a> tag.
  • Again, an id attribute is plain text.
  • MediaWiki tries to actively decode some %-encoded characters in a [[…]] wikitext link. The relevant code seems to be a self::normalizeUrlComponent() call in Parser.php. Ideally we can ignore this. The well-intended purpose of this code is to decode %-sequences that are irrelevant for the browser anyway and don't make a difference. The question is: Is the assumption MediaWiki makes here correct?
• We probably need to add an extra urlencode somewhere to fight one or both MediaWiki's as well as the browser's %-decoding.

I think this got resolved with the patches done as part of T317243.

I'm not sure how this is a problem with the generic escaping functions. A ! character alone is not valid syntax. Escaping the surrounding table syntax is sufficient.

Before/after comparison for the first patch https://gerrit.wikimedia.org/r/975767. The issue was that everything after the {{{ sequence was marked as a template variable (yellow).

This sounds like a super abstract project idea that didn't went anywhere. Or did it? As far as I can tell this is about potentially using features of Wikidata, TemplateData, and MediaWiki-extensions-Scribunto, but not about making changes to any of these codebases. The tags are misleading and should not be used. But if I remove them not much is left but a historic Hackathon tag.

I'm sorry, but I don't think it makes much sense to expect code that quite literally says "include this section" to not include the section. What you probably need is some kind of {{#ifsectionexists: … }}, as discussed in T337480. That's neither a bug in <ref> nor in #if, but in MediaWiki-extensions-LabeledSectionTransclusion.

Does this go along with T115894: The group argument to the references tag should be added as a class attribute?

I just tested this and it works as expected. Possibly a bug in the Citoid service we use that got fixed by now.

While not impossible this is extremely unlikely to ever be implemented. Good solutions exist via templates.

This is very similar to the behavior of #ifexists described in T14019.

We recently explored a few options in the Maps (Kartographer) extension. It's relevant over there because a single map can contain hundreds of labels and descriptions, and each is a tiny wikitext document that must be parsed.

• We assume that an empty string never represents anything meaningful.
• In https://gerrit.wikimedia.org/r/961826 we played around with the idea to skip parsing trivial strings that are short and pass PHP's ctype_alnum. One concern was that this might cause false positives for magic words like ISBN9608505402. Fortunately this is not valid wikitext syntax. It needs to be ISBN 9608505402, i.e. with a space, which is not part of the ctype_alnum character set.
• In https://gerrit.wikimedia.org/r/838243 we use wfEscapeWikiText to see if a string contains anything that remotely resembles a wikitext syntax feature. This is quite bulletproof, as it considers all kinds of configuration, e.g. namespaces, disabled magic words, and much more. It's also quite expensive because of this, but still significantly cheaper than actually calling the parser. In out tests it was 400 times faster than the legacy parser.

Oh, I'm sorry. I somehow expected this to list the Wikidata items that have the badge assigned. But that's not what the special page is designed to do.

Sure, that's one of the more important things we are responsible for as full-time developers. ☺️ Here is some of the code that does this: https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/includes/PopupsContext.php$204

We should not forget to undo https://gerrit.wikimedia.org/r/493409, i.e. remove the feature from what is now wgBetaFeaturesAllowList.