Sharing what I posted in that other topic. Interestingly, we have autocomplete working in our front page InputBoxes on LIMSwiki.org. However, the problem we're encountering is even when we tell InputBox to limit the search to a specific namespace, the autocomplete does not also limit its suggestions to that specific namespace. I found an old inactive extension (Extension:FormInputMik) that advertises "autocomplete is provided on predefined namespace," which is exactly what we're looking for, but the extension is soooo old. We very much would like to see any autocomplete on an InputBox with namespaces="foo" limit autocomplete specifically to "foo."

In T318060#9451386, @cscott wrote:

So I'd be inclined to close this as working-as-designed aka wont-fix: if you want "scary" transclusion *as wikitext*, prepend "raw". I think we can have a longer discussion about how transcluding arbitrary HTML from an external site "should" work, but there's probably not one universally correct answer to that, and the existing documentation already describes some known bugs, like how links to the external wiki will be rendered as "blue links" not as "external links" as they should. All the CSS applied will be that of the "local wiki" and not the "foreign wiki" as well, and since the transcluded HTML on the foreign wiki can include javascript and style modules, those will be missing in the transcluded HTML as well. "Just treating the HTML as stripped content" doesn't address any of these fundamental issues. There's a reason this is called scary.

In T318060#9425075, @Physikerwelt wrote:

I personally find scary transcluding too scary and would also assume that WMF does not officially support this feature. However, the patch to be reviewed has nothing to do with either Math nor scary transclusion, but claims to fix a bug with HTML tag output. In addition, I assume the patch does solve the problem of @Lostraven, but I would guess the patch will never be merged in the main product line. My private opinion is that we should move away from strip markers, and not add more complex processing rules for strip-markers. At least from the math perspective our goal is to get rid of them until the end of 2024, as they caused a lot of trouble and regressions in the past.

In T318060#9420470, @WelpThatWorked wrote:

I tested the changes on top of the latest MW core and they seem to still be effective/necessary. However, I notice the issue is absent on the limswiki page, unless you've already done the splice I'm not sure why that is.

Understood, and thanks. I tried just updating those lines in 1.36.1, but it had no effect. I'll consult stakeholders to see if upgrading to 1.39 can get approved, and if so, retest with the complete file change.

I wish this all weren't so obtuse. We're running MW 1.36.1. When I go to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/853462, it's not obvious what version(s) these changes would support. They were made over a year ago, that much I can tell, but I can't tell what code version @WelpThatWorked modified back in November 2022 to get it to work. Supremely frustrating.

In T318060#9414656, @Physikerwelt wrote:

I think the patch is ready for review. Then someone with +2 rights for MediaWiki needs to merge change. Then the change gets merged to master and will be included in the next release. However, if you feel brave, you can change the respective lines in your instance and check if that does it solve your issue? Be sure that you know how to undo your chances in case anything goes wrong or try on a test install first, if you want to avoid downtime.

Hey, all. It's been a little over a year here. I admit to being not-so knowledgeable about the back-end workings of trying to get a fix live in the MediaWiki code. That said, I see "Patch-For-Review," with a URL. When I click that URL, I see a page on Wikimedia Code Review, which I admit looks super cluttered and confusing to my untrained eyes. I can't fully tell what the status of this is, to be honest. Is this potential fix still in the "Ready for Review" state? If so, what's the next step to verify this fix works? If it's not in review, how do I decipher what was done with this potential fix? I'm really just an end user trying to get our wiki fixed. We continue to have the need to transclude pages with math, that don't display correctly. A year later, and we'd REALLY love to get this fixed. Help?

Checking in here. Any new news? Still happening for us.

In T318060#8247017, @Physikerwelt wrote:

I changed the second equation in https://github.com/wikimedia/mediawiki-extensions-Math/blob/b08776747133a2d49fcac56f338abce046d0bf2b/src/MathMathML.php#L467-L471 to real display math, and it also does not work. So it is probably not about span vs div. For formula that do render, the math is wrapped into <dl><dd> tags. So really the question is what does dl do to the math?

And I can confirm that this is happening in 1.36.1. Bueller?

I added a section to the citoid documentation page about this formatting. I reused some of your language, @matmarex . I hope you are not bothered by that.

THANK YOU, matmarex. Your timely post is appreciated heartily! I tip my cap to you.

In T265354#7261377, @matmarex wrote:

The spaces can be customized by editing the "format" specified in TemplateData of each citation template, as described here: https://www.mediawiki.org/wiki/Help:TemplateData#Custom_formats

For example, Polish Wikipedia's universal citation template uses an extra-spacey inline format: https://pl.wikipedia.org/w/index.php?title=Szablon:Cytuj/opis&action=edit&section=9 (specified at the bottom: "format": "{{_ |_ = _}}").

I just posted about this on Talk:Citoid thinking that Citoid handles the output of the citation code to the MediaWiki text editor. An hour later, I stumbled on this ticket, which seems to suggest VisualEditor is responsible for that output?

I'm noticing this happening in 1.36.1:

The search query generated is therefore not valid. I'd echo T225517#5257171, in that dropping the single character as a search condition is probably for the best. Wrapping it with double quotes likely won't have the desired effect, as apparently the search engine does not strictly match nonword characters. As explained in the link above, "test phrase" matches "test, phrase", and there's probably going to be other weirdness in matching "-".

Is this lost in the fold still? This has been an ongoing issue for a while. It's been affecting our wiki for a long while, and it's frustrating. I see this is medium priority at the moment, though I have little concept of what that means in terms of this getting resolved. Here's someone posting about it back in 2014!

In T19168#2115960, @Nemo_bis wrote:

Useful experiment! Do you have InstantCommons enabled? Interwiki trasclusion users action=render, which of course hotlinks whatever thumbnail URL is used on the source page. You should check if the image which "appears normally on the wiki" also exists locally (i.e. you can see it on a "File:" page with the same title).

We've tried to do something vaguely similar, though we have a different problem. We've tried to just interwiki transclude then add that new page to the book. When we interwiki transclude a Wikipedia page to our wiki, the content appears normally on the wiki. When we output the interwiki transcluded page (render) it to a PDF, only the text appears. We don't have the faintest clue why the Wikipedia text appears but the images don't in the PDF.