Following-up to this commit,

We had a related issue on frwiki (see talk, involving template Liste éléments):

@thiemowmde Your benchmarks are above :)

1. Volunteer developer at frwiki.
2. For me the main issue is that some scripts are just maintenance nightmares.
   • Examples:
     • In Lua: Module:Wikidata
     • For perspective, scripts that are smaller but are already hard to maintain: Module:Date, Module:Unité
     • In JavaScript: LiveRC.js
   • The issues are, more precisely:
     • Very few people are able to work on these codes (or are willing to spend dozens of hours to understand the whole script and to investigate the interactions with the other scripts).
     • We are close to a bus factor 1. When the creator of a script leaves the project, there's no one else crazy enough to carry on such script.
     • It's nearly impossible to make any change without breaking something (in the script, or in interacting scripts), also without making the code even more complicated. Making a "clean" change requires a lot of skills and time.
   • Thoughts about improving this:
     • Anything that would improve modularity and decoupling would be good to take. Slicing these monolithic monstruosities into smaller codes that could be worked on separately, sanely.
     • Same with things like unit testing, automated reports, and such. Anything that would help spotting any regressions immediately, or at least before they become difficult to fix.

$text = str_repeat( 'lorem ipsum dolor sit amet', 1000 );
$space = ' ';

@cscott I see you have improved it even further :)

The code could be optimized as so:

frwiki has been updated:

• MediaWiki:Gadget-CommonEdit.js (+ MediaWiki:Gadgets-definition)
• MediaWiki:Gadget-ExternalSearch.js
• Also Utilisateur:Gratus/superVis.js (see talk)

Ok, I got the point of, basically, not duplicating the API documentation into the page ResourceLoader/Core modules, and just making the latter link to the former. Entirely agree with this.

@Krinkle:

• If I documented something private/internal that should be by mistake, as it's something I would like to avoid too. Maybe you found an example of this?
• Indeed I have noticed your maintenance work on this page (amongst all the rest of course). That's very appreciated.

Great explanation by Krinkle above, in particular the following:

Just to mention the "de facto" documentation hadn't been updated.

Just as a kind reminder, ResourceLoader/Core modules documentation would need updating.

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

In T228604#5352013, @Iniquity wrote:

Do not forget that to use TemplateStyles in Editnotices (messages that display while editing) you need to add <div class="mw-parser-output"> wrapper :)

Note that previously the preferences had been fixed, by using in the message a nbsp character (instead of a html entity), and it was working fine.

On the other hand, there is for sure a bug in the parser...
So even if this one resulting issue may be ignored, we have here an open gate for other issues.

Same for docblock of Window::open, which should be updated according to WindowManager::openWindow.

Return value in docblock of Window::close should be updated accordingly, copying the return value from docblock of WindowManager::closeWindow.

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

Closing, per the explanation above :)

For the deduplicated styles, do we really need the <link> tags? Couldn't we completely remove the tag?

Just to clarify, I was precisely concerned about TemplateStyles in small templates invoked many times. More precisely:

• Server-side: all processing time for parsing, deduplicating, etc. (CPU/RAM usage)
• Client-side (which I'm more worried about): cost of markup bloat with the numerous added <link> tags (page size, also CPU/RAM usage)

This makes sense. I am just uncomfortable with removing the "nowiki" from the sub (and main) template {{Titre en italique}}. That one "nowiki" fixes many cases of empty <p>.

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Wow, that's quite an impressive reply! Thank you. Pinned.

I'll just also mention toolbar customization, which has been modified several times, and has become a real pain for users.

Not strictly deprecation/removal, but off the very top of my head:

I just found it was cumbersome to manage different versions of scripts, depending on MediaWiki version, swimming on short intervals like 6 months.
Moving to forward-compatbility implying to break backward-compatibility even for recent and supported MediaWiki versions.

I think the legacy "mediawiki.api.*" modules should be removed later than in MediaWiki 1.33.

So, there is still Modern to fix.

Looks like it's solved, the patch having been merged.

Indeed, duplicate.
Apparently the whole thing was just broken, and the fix is to be deployed soon.

I have just updated a few links, there are probably more remaining.

Thank you for these explanations :)

Bump :) Is there someone able to do it? Is the task easy or not?

At least, the self links shouldn't be blue, using some a:not([href]) CSS as it has been done for Minerva.

By the way, I checked on Timeless, and the self links are blue, as regular links. That is wrong for sure.

I mean that the bold removal and the underline on hover are by design ;) But I may be mistaken.

I think it is by design.

@MusikAnimal I figured it out exactly at the same time ;)

@MusikAnimal I've noticed your revert. Actually, there might be something missing in the extension implementation in MediaWiki. Compare the two following sets of Lua debug outputs:

Yes, please uncomment it, so you can at the very same moment check if it is running fine.

@MusikAnimal I have implemented this extension in the module.

I made the patch, but the Gerrit Patch Uploader currently fails to submit it (and there is no error message).

One week already, I got no more reports about this. If there is no one willing to nonetheless fix it, I think this ticket can just be closed.

Just to clarify, the patch that has just been merged is not for the issue of this ticket, but for a related issue.

This needs more than the single rule above. I had to add the following to fr.wiki: https://fr.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=prev&oldid=143649876

Thank you for this addition. But as I stated a bit above, these missing styles are simply an overlook from T160480. There is just no reason not to add them.

If template returns #ccc and is used as style="color:{{template}}", {{#balance:inline}} would break the template, as it wraps the output with <span>...</span>.

For convenience, refs https://phabricator.wikimedia.org/T31157 (relocation of bugzilla 29157).

Phabricator's Contributing Code:

Even in this "Browse Projects" modal, there is no link to go to the tag page!

Fixed by this edit, yet I have removed this code just after as it's no longer needed.

Has been fixed in this edit (search setTimeout).

Should be working again, see notably this edit.

Any news on this?

For the demo above, note the CSS has been fixed locally.

How about just escaping all ! characters? It would escape more than necessary, but the code would be much simpler (in particular the PHP one).

So, you don't think there is the same issue with the 2nd do/while of the for loop? I haven't checked it thoroughly, but it just looks very similar, with these n+2 steps. That's why I added the "overflow fix" after the for loop in my demonstration patch, to cover the two do/while's.

Thank you for your work on this.

I was about to completely agree with Jdlrobson, but actually such links are HTML5's "placeholder links" and seem to be the recommended way…