Module talk:Message box

Jump to navigation Jump to search

Making a small box with a custom width

I'm interested in making a small message box that's wider than the normal small box (to keep this from going onto three or four lines for pages with longer titles). Is there a way to do this, or could a parameter be introduced to allow for it? {{u|Sdkb}}talk 19:30, 23 April 2020 (UTC)

@Sdkb: See Special:Diff/952939847. It is possible, but making it too wide can cause problems in smaller screens. Ahmadtalk 21:36, 24 April 2020 (UTC)
Have you looked at the documentation for {{Ombox}} or {{Ambox}}? You can set a width using |style=. – Jonesey95 (talk) 21:48, 24 April 2020 (UTC)
@Ahmad252 and Jonesey95: Oops, I was overthinking that by a mile haha. I did look at the {{Ambox}} documentation but wasn't able to figure it out. I'll update it to help those confused in the future. Thanks for the help! {{u|Sdkb}}talk 21:52, 24 April 2020 (UTC)
@Ahmad252 and Jonesey95: sorry for my terrible HTML, but I just spent 15 minutes fiddling with min-content/max-width/etc. and couldn't figure this out: how do I set the box so that it adapts flexibly to the width of the text (so that there's no big margin on the right), and wraps onto a second line only if the reader's screen is too small for it to fit? max-width seems to solve the second part, but I have no clue about the first. {{u|Sdkb}}talk 23:27, 24 April 2020 (UTC)
Unfortunately, I don't know how this can be done. As far as I know, display: inline-block is supposed to do it, but given that there is already a width set in the module's default style, it still sets width to 238px (the default number) unless we can completely remove width. Maybe I'm missing something. Ahmadtalk 00:26, 25 April 2020 (UTC)
@BrandonXLF: this seems like something you might know how to fix? {{u|Sdkb}}talk 20:39, 25 April 2020 (UTC)
Sdkb, do you want it like this? BrandonXLF (talk) 22:57, 25 April 2020 (UTC)
@BrandonXLF: Yes! Thank you as always for your techno-wizardry! {{u|Sdkb}}talk 23:07, 25 April 2020 (UTC)

Talk should not be hidden in small boxes

The behavior that using a small box hides the talk link is pretty unintuitive, especially given the convention that many problem boxes (say, {{disputed section}}) are supposed to come with a talk link for discussion of a fix. Please perform the following edits:

  1. Replace if ( or self.fix) and not self.isSmall then with if ( or self.fix) then.
  2. Replace the block of if ... end starting with if talkTitle and talkTitle.exists then with the following:
    			if talkTitle and talkTitle.exists then
                    local talkText
                    if self.isSmall then
                        local talkLink = talkArgIsTalkPage and talk or (talkTitle.prefixedText .. '#' .. talk)
                        talkText = string.format('([[%s|talk]])', talkLink)
                        talkText = 'Relevant discussion may be found on'
                        if talkArgIsTalkPage then
                            talkText = string.format(
                                '%s [[%s|%s]].',
                            talkText = string.format(
                                '%s the [[%s#%s|talk page]].',
                    end = talkText

The result should be that a small version of the talk page is generated as a single parenthesized link. Feel free to change it if you feel that's not the best presentation.--Artoria2e5 🌉 05:28, 15 May 2020 (UTC)

 Not done: this will need some discussion. Please sandbox your changes and test them fully - see WP:TESTCASES. Then I suggest starting a discussion at Template talk:Mbox to see what others think — Martin (MSGJ · talk) 08:50, 20 May 2020 (UTC)

@Artoria2e5:, can you sandbox this? Mathglot (talk) 02:04, 20 July 2020 (UTC)

@Mathglot:, I put the stuff in Module:Message box/sandbox, but for some reason the test at Template:Ambox/testcases and Module talk:Message box/testcases aren't updating even after a purge. What am I doing wrong again... --Artoria2e5 🌉 06:24, 20 July 2020 (UTC)
@Artoria2e5:, thanks for getting back so quickly. I've only dealt with Template sandboxes, not Module ones, and I don't want to steer you wrong. Maybe someone here can help: User:MSGJ? Mathglot (talk) 06:39, 20 July 2020 (UTC)
@Artoria2e5: I see “(talk)” links at both Template:Ambox/testcases#talk=talk small=left text=text and Module talk:Message box/testcases#talk=talk small=left text=text. Isn’t this the difference you wanted to see? —Tacsipacsi (talk) 10:48, 20 July 2020 (UTC)
@Tacsipacsi: Yes! I must be getting confused by the different images. The config that specifies these seem to be leftover from some UI change test. The "fix" is also there for small=left, so I think I am ready to reopen this request. --Artoria2e5 🌉 11:15, 20 July 2020 (UTC)

Administrator note: did you post a message at a more watched paged than this? (I suggested Template talk:Mbox above.) If not, I am willing to make the change as it seems low impact, but on the basis that it may be reverted on request. Can I just confirm if any of the changes at Module:Message box/configuration/sandbox are related to this request? — Martin (MSGJ · talk) 14:29, 2 August 2020 (UTC)

@Artoria2e5: in case you miss this — Martin (MSGJ · talk) 14:38, 2 August 2020 (UTC)
@MSGJ: thanks! No, the configuration stuff is not involved in this. It looks like someone's attempt at using SVG icons. --Artoria2e5 🌉 13:35, 3 August 2020 (UTC)
 Done — Martin (MSGJ · talk) 15:49, 3 August 2020 (UTC)

Use TemplateStyles

Currently this module relies on CSS classes defined in MediaWiki:Common.css. While this is efficient considering the English Wikipedia alone, it leads to missing styles when people copy-and-paste the module to other wikis, without copying the styles with it (either because they don’t know about it, or because they don’t have the right to edit Common.css on the target wiki). Switching to TemplateStyles would resolve this issue (if the module containing the <templatestyles> tag is copied, but the TemplateStyles subpage isn’t, instead of silently not having styles, an error message appears, so the user is aware of the problem), makes the connection between the Lua and the CSS code stronger, and makes it possible for any administrator to fix eventual issues in the CSS code (instead of only interface administrators), with the possibility of lifting the protection even further (e.g. allowing template editors) as needed and considered appropriate. It also makes possible to use sandbox pages, so the module sandbox can load the TemplateStyles sandbox and thus CSS changes can be tested just like Lua changes. Thoughts? —Tacsipacsi (talk) 19:10, 30 May 2020 (UTC)

Just to add how I became aware the issue: multilingual wikis like have one more issue with the Common.css-based solution: Common.css styles are automatically modified by ResourceLoader (swapping “right” and “left”) based on user language—and this had to be disabled to present English pages correctly when the reader has e.g. Hebrew interface language—, while TemplateStyles uses page language. The Lua banner on mw:Template:Documentation/ar currently looks awful (floated to the wrong side, the Lua logo has margin on the wrong side etc.), which could be fixed by using TemplateStyles and not disabling the swapping functionality. —Tacsipacsi (talk) 19:15, 30 May 2020 (UTC)

Site-local configuration source for sisters importing from here

On English Wikisource we have a couple of extra namespaces (Page: and Index:, provided by Extension:ProofreadPage), and so have created a new "pmbox" message box. And on re-sync'ing changes from enwp recently we ended up overwriting the configuration for this message box. (we also caused other issues that we're still trying to track down, but that's to be expected for this type of deployment strategy)

In order to avoid that particular problem in future it would be nice if this module supported a Module:Message box/siteconfig configuration module that, when it exists, is loaded and merged with the data from Module:Message box/configuration. Bonus feature: letting site config override the standard (upstream) config in case there's a need to override something rather than just add to it. That way we can both maintain the "upstream" configuration through periodic imports from enwp, and have additional configuration that is enWS-specific, without having to re-merge our local changes on each import.

One of the reasons we import from enWP is that we (like many of the smaller projects) have very limited technical resources, so remembering and understanding the need to do this integration on each import, much less doing it correctly, is a relatively tall order. Having explicit support for site-local configuration in the upstream module would make this a lot easier for us.

PS. I'd offer to mock this up in the sandbox for your consideration, but this module is being a bit too clever (with the overridden __index method and dynamically generated function lookup table) for my limited Lua-fu. My assessment is that the proposed functionality shouldn't introduce excessive complexity or an unreasonable maintenance burden or performance hit here, but, again, the code is a little over the level of my Lua skills so I may be missing gaping pitfalls.

PPS. TemplateStyles, as requested above, would also be of help for this, for similar reasons.

PPPS. Come to think of it, it may be that support for site-local configuration could be beneficially added to mw.loadData() to make supporting this kind of thing "free" for simple cases (probably not this one, since I don't think you can generalise the merging for arbitrarily complex datastructures, but possibly some common cases with simpler configuration needs). If anybody has ideas about this I would appreciate thoughts before I (at some unspecified point in the future) try to write that up for Phabricator. --Xover (talk) 09:46, 21 August 2020 (UTC)

The article is a derivative under the Creative Commons Attribution-ShareAlike License. A link to the original article can be found here and attribution parties here. By using this site, you agree to the Terms of Use. Gpedia Ⓡ is a registered trademark of the Cyberajah Pty Ltd.