Module talk:Message box

Latest comment: 1 year ago by Xover in topic Use strict module

Use strict module edit

{{editprotected}}

Please apply this change. I would also recommend unprotecting Wikisource:Protected against recreation since it's just a redirect now. Thanks! legoktm (talk) 00:28, 20 November 2022 (UTC)Reply

@Legoktm: Thanks. Done. We import most of these core templates and modules from enWP so we'll get these migrated by and by as enWP migrates. This module is the exception since we keep having to reapply this local change every time we resync, so normally we'd have waited for a significant amount of changes and expecting it to remain stable a while. But since the strict module change is a tiny one I've instead applied it manually (to avoid it showing up in your list :)).
Oh, and I just deleted the soft redirect instead. It serves no real purpose any more and had other little problems that weren't really worth fixing. --Xover (talk) 09:45, 20 November 2022 (UTC)Reply
Thanks! Nominated Module:No globals for deletion now. Maybe @Izno has a suggestion on how to incorporate your local change into the en.wp version? legoktm (talk) 16:44, 20 November 2022 (UTC)Reply
Could be merged 'upstream', but it's not applicable there and I know en.wp template editors have been generally leery of supporting stuff we don't use. (I don't have a good reason offhand why I'd personally object to it.) @Legoktm Izno (talk) 00:48, 22 November 2022 (UTC)Reply
@Izno, @Legoktm: Yeah, that's why we haven't proposed upstreaming it (as we normally prefer, for all the obvious reasons). The only realistic way it'd be tenable at enWP is by abstracting this logic into configuration, and I suspect that would be seen as unwarranted complexity for little practical gain there. Xover (talk) 07:25, 22 November 2022 (UTC)Reply
Oh, btw, while you're already getting pings from here… Thank you for all the work moving stuff out of Common.css and into TemplateStyles! We import a lot of that stuff and it's let us cut down on and clean up project-wide CSS here that we really appreciate! In fact, once {{infobox}} and friends are done we can delete MediaWiki:Gadget-enwp-boxes.css entirely (and start in on MediaWiki:Gadget-enwp-lists.css—sigh—cruft amasses at a rate far exceeding our ability to excise it). But, yeah, that work was noticed and appreciated over here, so many many thanks for spearheading that Izno! Xover (talk) 07:36, 22 November 2022 (UTC)Reply
Nothing of interest except Template:English case infobox which doesn't use the class anyway (it's that old; you should look into syncing that with the WP version which is currently w:Template:infobox court case).
I recommend moving the infobox CSS from boxes.css before en.wp (aka now) because 1) it's cheap and 2) there are lots of infoboxes on en to fix (4000) that you shouldn't be paying the price for some indefinite future. (I don't intend to mess with Infobox/styles.css until after I've got everything in there.) I'm pretty sure you can read CSS so I think you can figure out how to move it, but if you have questions ping me again.
MediaWiki:Gadget-enwp-boxes.css#L-81 "System messages styled similarly to fmbox" should probably move to one of the other sitewide styles you're loading in gadgets def if you're actually interested in coloring things the same way here (I think the colors adjustment is marginal in utility, at best):
The distinction of each of these is not obvious but apparently only SiteHeader.css loads on mobile, so that might influence you toward one of the two others. OTOH being consistent on mobile is important. (At some point a lack of targets will cause your gadgets to load in both places as the WMF works to remove it in the most work-deferring way possible.) Izno (talk) 19:36, 22 November 2022 (UTC)Reply
I can also work on the others if you want; I need a break from en.wp's neverending mass of styles for a while. Izno (talk) 19:37, 22 November 2022 (UTC)Reply
@Izno: We're perennially short on technical contributors, have a big load of technical debt amassed since the launch of Wikisource, and some complex needs not shared by other projects. We welcome all assistance on technical things with open arms, is what I'm saying! 😎
MediaWiki:Gadget-SiteHeader.css is specifically for {{header}}, which is in the middle of a transition to Lua that was halted due to a bad interaction between TemplateStyles and MediaWiki:Gadget-PageNumbers.js. {{header}} is mandatory on all mainspace pages, and shows on mobile, so loading that bit through a default Gadget instead of TemplateStyles is a reasonable temporary fix.
MediaWiki:Gadget-Site.css is the dumping ground for the old Common.css stuff, and at least the first half of it (everything above the Score stuff) will move to TemplateStyles in {{header}} (and a few related templates) eventually. But Site.css is supposed to be the mandatory styles enWS always needs; so Common.css except as a ResourceLoader module. MediaWiki:Gadget-enws-tweaks.css should eventually go away and the few (hopefully) remaining bits migrate to MediaWiki:Gadget-Site.css.
Yeah, mobile is a bit of a step-child here, because so much of our tools and content don't really work there (and too few technical bods). Xover (talk) 07:34, 23 November 2022 (UTC)Reply
Oh, and {{English case infobox}} was an old cut&paste import that had zero legitimate transclusions and will inherently fall afoul of our annotations policy in most plausible cases, so I've proposed it for deletion instead of wasting time updating it. Xover (talk) 14:12, 23 November 2022 (UTC)Reply
Could you set up a page like w:MediaWiki talk:Common.css/to do somewhere locally with a list of the sets of CSS that need transitioning in any and all relevant gadget pages + any assessed blockers for those? MediaWiki:Gadget-PageNumbers.js breaking is a good one but I couldn't help with it, but at least getting a list might help some software person actually do something to sort it out. And of course, I can work on the others. Izno (talk) 19:15, 23 November 2022 (UTC)Reply
@Izno: MediaWiki talk:Gadget-Site.css/todo. @Inductiveload: this is context for the pings you got from /todo. Xover (talk) 09:10, 25 November 2022 (UTC)Reply
Actually, I think we can just take that particular 'patch' directly since it will never trigger on en.wp since it's looking at the namespace, I'd just need to add a note that it's not for us over there. I think you'd still need to maintain whatever is in /Config here though? (Which is somewhat to be expected.) Izno (talk) 19:39, 22 November 2022 (UTC)Reply
@Izno: If I don't have to re-apply that patch—or more accurately: worry about remembering it every time I re-sync from enWP—I'll be a happy camper. But I had expected no bueno from a technical editprotected request since it's dead code for enWP to maintain. My luck in getting changes in that only benefit the little sisters is pretty chequered. Xover (talk) 07:38, 23 November 2022 (UTC)Reply
Before taking that upstream, could you assess the other Wikisources to see what would happen today and/or submit minimal change requests where relevant to ensure they don't break? Izno (talk) 19:17, 23 November 2022 (UTC)Reply