@Lina_Farid_WMDE We have the very similar task T380979: Block nesting <ref> tags in the details syntax and a proof of concept patch for that. That's relatively straightforward inside of the details="…" syntax.

@Dabao_qian I'm afraid I'm missing some context here. Can you help to clarify?

• There is no code that adds a lang attribute to the mwe-popups-extract. I can only suspect what you see is possibly from the browser or a browser plugin.
• When I play around with your example <ref>这是一个参考资料</ref> there is no lang attribute generated as part of the reference list item. The content of this reference really is only plain text. That's all the popup can show. How should the popup know if the popup content is in a different language? Communities usually solve this with templates.
• One thing the popup could do is to copy the lang attribute from the entire article. In other words: The content language of the article, in contrast to the user's interface language. But the content language I can see in my experiments is lang="zh". Where does "zh-Hans-CN" come from?

The WMDE-TechWish team isn't really using this logo for anything important. It might appear on a shirt, but I don't think that poses a problem for the upstream MediaWiki logo. We are a very small, local team with not much visibility.

I would argue this is long done, even if the follow-up task T210281 is still open.

For reference, the text in the image says "This file has been imported into Wikimedia Commons" in green and "Failed to automatically remove the file uk.wikipedia.org. Please go back to the original file and remove it manually" in yellow. Unfortunately no specific details.

I have an awkward idea what it could be then. When I use the mobile simulation mode it is using a fixed pixel resolution. This can not even be zoomed any more. When the resolution is larger than what fits in the browser's viewport it will be cut off at the bottom, with no extra scrollbar. Picking another resolution as well as making sure extra elements like the debug console are disabled solves this for me.

26 files is not a "mass" as far as I'm concerned. 😇

@awight said there was nothing on the console, no. I also cannot reproduce this, unfortunately. The screenshot looks like this happened on enwiki while being logged out. But it works for me both logged in and logged out.

Why did I argue so hard back then in T203312? It doesn't make sense to block the useful effect of this suggestion just because I want to avoid a few rare phpcs:ignore in my code. 😅 I can live with that. Guess I'm getting older. 😇

Aren't these all more or less one option? 😅 Individual authors are usually free to decide if they want to mark (rare) exceptions with phpcs:ignore or refactor them another way.

Yes, that works. It's very unlikely PHP will ever disallow such characters in the second parameter just because they are already escaped. Still a '{' is technically dead code. I would probably use phpcs:ignore for more clarity.

As argued in T203312 using preg_quote without the 2nd parameter can technically be valid. There is just nothing to escape when the delimiter characters are e.g. {…}. Here are some examples in real-world code (note this is an incomplete search result). Such cases would need to be marked with a // phpcs:ignore. Maybe that's fine. I don't know.

@awight, I would like to suggest the following plan to fix the originally reported issue:

• Remove anything but the arrow character from the message.
• https://gerrit.wikimedia.org/r/1268943 helps clarifying how the message is intended to be used.
• The community can use CSS to restore the bold formatting in the WikiEditor (2010) help panel. See the suggestion T422458#11808183 above.
• This leaves the preview where the bold formatting might still be missing. This can as well be fixed by removing the bold formatting from https://en.wikipedia.org/wiki/MediaWiki:Cite_references_link_one as well as https://en.wikipedia.org/wiki/MediaWiki:Cite_references_link_many_format and replacing it with CSS.

This is more an investigation ticket at the moment and doesn't need to be declined. The WMDE-TechWish team currently checks all possible error cases (with a focus on but not exclusive to Cite (Sub-referencing)). Our questions are, roughly speaking:

• Is the different behavior acceptable?
• Or do we favor one of the two behaviors?
• If so, can we bring the behavior of the two parsers closer together with reasonable effort?
• Should Parsoid warn the user when a stray, unclosed <ref> is found in the middle of another <ref> tag?
• Is this situation really relevant in the real world, i.e. how often do users make the mistake of missing the slash in wikitext like <ref>body<ref>?

Dev note: I believe this can be fixed by implementing the TODO here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/1271763/8/src/Parsoid/References.php#704

@Johannes_Richter_WMDE, heads up! We just merged https://gerrit.wikimedia.org/r/1271763 which makes an entire class of errors visible in Parsoid. This is about all the errors that happen inside of <references>…</references>, which includes multiple that are about sub-refs. This should already be on the beta cluster.

@SBisson Thanks! Yes, we will make sure to let your team know what we came up with when we are there. Might take a while, though. 😇

While I understand the confusion I believe this was a deliberate design decision. The problem is that the email is generated once, but the link is possibly clicked much, much later. The user can change their preferences any time. Who knows if they accept emails right now? The receiver of the email can only learn this when they visit the email page.

I just found that the currently developed Article-Guidance feature is using a different naming pattern: ref1, ref2, …

Note this is almost the same as T380979. However, T380979 is about nesting inside of the details="…" syntax while this ticket here is about nesting in normal main references.

Adding a few people. Maybe they have a good idea which WMF team could add this to their review queue?

Thanks a lot for the quick responses, @Izno and @jhsoby. Both en and no are fixed for the moment and can stay like that.

The reason for reusing the methods is that I have no reason to make the paging links, count message, etc., any different from what is generated by MediaWiki core. In fact, I want those components to be exactly the same as in vanilla MediaWiki.

I'm tempted to point the finger at the Cite extension […]

I do have a few questions:

• The current PictoCategoryViewer class doesn't look complicated. How would that benefit from being able to reuse code from core's CategoryViewer class?
• The patch https://gerrit.wikimedia.org/r/1258362 exposes 4 methods. Neither looks complicated, in my opinion. What is the benefit of reusing them rather than making your own custom version? Doing so gives you the chance to customize the code exactly to your needs without the need to add extra complexity to the base class.
• Why does https://gerrit.wikimedia.org/r/1258362 expose 2 previously private properties?
• The LanguageConverter should be changed to dependency injection via a constructor parameter.
• Generally it sounds more like what you need is a hook that allows you to modify the presentation of each page link. Isn't that what the CategoryViewer::generateLink hook already does? Maybe it's just missing something and your problem can be solved by adding one or two new parameters to the hook?

Note for demo time: The current solution skips the category in rare edge-cases when the sub-ref has errors that lead to the sub-ref not being rendered as a sub-ref. Here is one example that's different in the two parsers:

<references>
<ref name="a" details="d">a</ref>
</references>

This is probably acceptable in real-world scenarios because this can only happen when there is an error. The page is tagged with the error category then.

Hey @STei-WMF! Next week is fine, I believe. The main reason for us posting this is T420938: sub-references will become available on Italian and Czech Wikipedia, probably on April 8. I hope this helps. @Johannes_Richter_WMDE might have more information.

The failing code does a loop over an array that comes from a cache and can contain deprecated flags for – as far as I'm able to tell – very legitimate reasons.

foreach ( $jsonData['OutputFlags'] ?? [] as $flag ) {
	$this->setOutputFlag( $flag );
}

I think this loop needs to be excluded from raising deprecation warnings.

According to the stack trace this is the result of an extension not using the ParserGetVariableValueSwitch hook correctly. In an ideal world there should always be exactly one extension thats responsible for a magic word and sets the out-parameter &$ret to a string.

Not a useful ticket when the only tag is "other". It looks like nobody is actively maintaining the extension.

Same as T291333. I find this ticket underspecified and not actionable, sorry. What would be the motivation to include the leading picture from one article in another article instead of, you know, just using the existing [[File:…]] syntax?

I find this ticket underspecified and not actionable, sorry. What would be the motivation to include the introduction from one article in another article?

Thanks for the report. I believe this is a known limitation and doesn't have much to do with references. Whenever you add new parameters to an existing template the new parameters will visually appear in the correct position in the VisualEditor template dialog, but not in the final wikitext.

@JnpoJuwan Thanks for the feedback. I would like to understand better what you mean. Where else would you expect it? Maybe this is a misunderstanding? I just noticed that the feature probably didn't make it for last weeks rollout and will only become available on the Wikimedia wikis this Wednesday. Maybe that's where the confusion comes from?

Well, it's currently broken and unusable anyway, at least in Parsoid. Maybe we are talking about two different classes of "nesting"?

Proposal for Tech News: Moved to https://meta.wikimedia.org/wiki/Special:Diff/30303156.

Current state:

• Nesting refs via the main content is possible with and without the details= attribute being involved.
  • With details: {{#tag:ref|Outer ref<ref name="a" details="Inner details" />|name=a|details=Outer details}}
  • Without details: {{#tag:ref|Outer ref<ref name="b">Inner ref</ref>|name=a}}
  • Technically unrelated to this ticket. Just for reference.
• Refs can be nested in the details= attribute: {{#tag:ref|Outer ref|name=a|details=Outer details<ref name="b">Inner ref</ref>}}
  • ☠️ The legacy parser actually renders this. But in a weird order that feels backwards.
  • ☠️ Parsoid displays an unresolved strip marker from the legacy parser: UNIQ--ref-00000000-QINU.
• When I use the #tag function for the inner ref: <ref name="a">{{#tag:ref|Inner ref|name=a|details=Inner details}}</ref>
  • ✅ The rendering is the same in both parsers.
  • ☠️ Parsoid doesn't show any error message.

Some additional notes:

• All Cite browser tests fail for the same reason, not only the reuse test mentioned in the commit message.
• It looks like this started over the weekend. So it's most likely related to https://gerrit.wikimedia.org/r/1251423. Possibly https://gerrit.wikimedia.org/r/1251477?
• I noticed there is a ve-init-mw-desktopArticleTarget-… selector in the test code that only exists on desktop.

I'm afraid there is not much we can do when the community mushed two customizations (the ^ and the [) into one line of code. They should please edit their https://sv.wikipedia.org/wiki/MediaWiki:Gadget-referenser.css as follows.

span[rel="mw:referencedBy"]::before {
    content: "^ [";
}
span[rel="mw:referencedBy"]::after {
    content: "]";
}

span[rel="mw:referencedBy"]::before {
    content: '^ ';
}
span[rel="mw:referencedBy"]:not(:empty)::before {
    content: '^ [';
}
span[rel="mw:referencedBy"]:not(:empty)::after {
    content: ']';
}

When we rely on Parsoid it might be possible to detect the template that was used to generate the reference and infer the Popup type from that template via cite-tool-definition.json. There should be something like data-mw='{"parts":[{"template":{"target":{"wt":"Cite_book","href":"./Template:Cite_book"},… in the HTML we could use in Popups' frontend code. That's impossible with the legacy MediaWiki-Parser though.