Project:Village pump (technical)

Start new section button, in editor's talkpage

Template:Tracked Template:Moved from Has the "+" (start a new section) button been disabled on user talkpages? Mine no longer works. GoodDay (talk) 02:49, 6 August 2022 (UTC)

Template:Works for me Template:Ping what happens when you push it? Which skin are you using? It it not working on all pages (like this one), only a specific page, or only user talk pages for you? — xaosflux ^Talk 09:45, 6 August 2022 (UTC)

If "Enable quick topic adding" is enabled at Special:Preferences#mw-prefsection-editing then try to disable it. PrimeHunter (talk) 11:16, 6 August 2022 (UTC)

Now, it doesn't seem to work on any talkpages. GoodDay (talk) 14:44, 6 August 2022 (UTC)

Red alert: The new topic edit feature is not working in Wikipedia talk, Template talk, Help talk, and MediaWiki talk namespaces. For example, on page Wikipedia talk:Administrators, mouse over the new section "+" and the link is https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Administrators&action=edit&section=new; but that page is simply the talk page itself, not the new section page. Mouse over Click here to start a new topic. and the link is https://en.wikipedia.org/wiki/Special:NewSection/Wikipedia_talk:Administrators, but that page is again simply the talk page itself. On page Template talk:AfD in 3 steps, mouse over the new section "+" and the link is https://en.wikipedia.org/w/index.php?title=Template_talk:AfD_in_3_steps&action=edit&section=new; but that page is simply the talk page itself, not the new section page. Article talk, User talk, File talk, and Category talk pages all allow adding new sections in the normal manner. I use Windows 10, Firefox, and the MonoBook skin. —Anomalocaris (talk) 04:35, 9 August 2022 (UTC)

Is it possible that this is a similar problem to Wikipedia:Village pump (technical)/Archive 198#New section tab not working when JavaScript is disabled? The new "quick topic adding" is a JavaScript-only feature, but when JavaScript is disabled, it should redirect you to the old form. However, it is possible for some browser extensions to prevent this redirection, which would cause the behavior you describe. Matma Rex talk 18:15, 9 August 2022 (UTC)

Works for me still? I was able to add new topic, with the new topic tool enabled and also with it disabled. — xaosflux ^Talk 18:29, 9 August 2022 (UTC)

It works for me. The mentioned mouse over url's are the same when it works. The only url difference is that when it works, clicking the link doesn't change the url from the page you are already on, but just adds a form. For example, if you click the new section link on https://en.wikipedia.org/wiki/Wikipedia_talk:Administrators then you are still on https://en.wikipedia.org/wiki/Wikipedia_talk:Administrators, but at the bottom in a form. PrimeHunter (talk) 18:37, 9 August 2022 (UTC)

I just got a new computer today. The problem is still there. However, it goes away if I go to Preferences and on the Editing tab, uncheck Enable quick topic adding and save. I have not intentionally disabled Javascript in Firefox. If I disabled Javascript in Wikipedia, how would I have done that? —Anomalocaris (talk) 05:12, 10 August 2022 (UTC)

Enable quick topic adding again. Does it work if you log out? Does it work in safemode? The tab will say "New section". PrimeHunter (talk) 09:23, 10 August 2022 (UTC)

Are you running script-blocking extensions, such as NoScript? — xaosflux ^Talk 10:14, 10 August 2022 (UTC)

No, as I say, I just got a new Windows 11 computer and installed Firefox on it, with no extensions so far. If I log out, my preferences won't be in effect. If I enable quick topic adding, safemode does not solve the problem. —Anomalocaris (talk) 18:35, 10 August 2022 (UTC)

Quick topic adding is enabled for logged out users. Does it work if you log out? PrimeHunter (talk) 19:30, 10 August 2022 (UTC)

Oh no, I think I see what's happening – if you have "Enable quick topic adding" enabled, but "Enable quick replying disabled", and the page would have any reply links, all of the tools don't work correctly. This is filed as T314707, I didn't immediately connect the dots that it's the same issue. Matma Rex talk 20:06, 10 August 2022 (UTC)

@GoodDay @Anomalocaris This should be fixed now (you might need to purge the cache of affected pages first), can you try? Sorry about the issue. Matma Rex talk 14:17, 11 August 2022 (UTC)

Yup, it's kickin' in, now. But not for some editors' talkpages. But, it'll gradually smooth out :) GoodDay (talk) 15:14, 11 August 2022 (UTC)

Matma Rex: New topic edit is working now. However, the URL of the editing page is the same as the URL of the production page, and the back button takes you back, not to the production page but to the page before the production page. That isn't what I expect. —Anomalocaris (talk) 05:35, 12 August 2022 (UTC)

Anomalocaris, I already knew about this, I knew it wouldn't go well, and it didn't.
This is DiscussionTools' aggressive hostile takeovers coming back to bite them in the ass. Needless to say, Bawl has none of these issues. Better yet, by default it actively patches out that problem you mentioned by altering the URL. (development would have been easier if I wouldn't have to worry about DT's escapades) — Alexis Jazz (talk or ping me) 13:23, 13 August 2022 (UTC)

How can a template calculate the diff between year-and-month dates?

I'd like a citation template to calculate how old a publication is, because if it's > 3yrs, doi-access should be set to 'free'. Publication is quarterly, and the publisher's dates in their DB are YYYY/MM, so it would be nice if the notice for free access turned on the month. But I can't just subtract the date param from a truncated CURRENTTIMESTAMP, because neither is decimal. I assume this has been done before, just don't know where to look. — kwami (talk) 23:37, 9 August 2022 (UTC)

You could probably do the calculation using Julian days. Or, something like the following usage of {{time interval}} might help. show=d gives a number of days and disp=raw gives just the number. You could use show=y for years but I would need a fair bit of time to experiment or recall how it rounds.

• {{time interval|1 Jan 2001|March 4, 2002|disp=raw|show=d}} → Template:Time interval

Johnuniq (talk) 00:00, 10 August 2022 (UTC)

Thanks! I think I can take it from there. If I get stuck I'll ping you. — kwami (talk) 01:13, 10 August 2022 (UTC)

That works! If I plug in 2019-08, it displays as free access; if 2019-09, it doesn't. — kwami (talk) 01:27, 10 August 2022 (UTC)

Template:Ping I had a look at Template:Cite JIPA. The date/age modules are complex and not fully documented and I have forgotten exactly what partial=on does as far as date differences go, so I'll just mention that using partial=on makes {{time interval}} accept incomplete dates such as "2001" or "March 2001". In a quick test, I couldn't make sense of the resulting number and I can't take the time at the moment to dive in deeper. Ask me in a couple of weeks if you want that investigated (I should do it!). However, what I am confident about is that omitting a date means the current date is used. For example, these give the same result and this may be of use:

• {{time interval|2020-8-10|{{date}}|disp=raw|show=d}} → Template:Time interval
• {{time interval|2020-8-10||disp=raw|show=d}} → Template:Time interval

Johnuniq (talk) 07:32, 10 August 2022 (UTC)

Thanks! That simplifies things quite a bit. I'll play around with it tomorrow. — kwami (talk) 08:12, 10 August 2022 (UTC)

That allowed me to cut a fair amount of clutter in the code and end up being more forgiving of date formats. Enough that I could reduce the documentation. — kwami (talk) 09:23, 10 August 2022 (UTC)

Logging in to OTRS

I was trying to read an OTRS ticket, but found myself unable to log in to do so. I followed this link and was asked for my username + password, but was told the password was wrong when I supplied it. So I said I'd lost it (not true, but there didn't seem to be anything else to do) and was told I'd been sent password reset instructions by e-mail. No e-mail arrived. Help? I suppose it's possible that I created a separate password for the OTRS thing years ago and failed to make a note of it and failed to both save it in my Firefox privacy thing and to link an e-mail to it (though I don't think so), but what can I do now? I'm really scared to test my Wikipedia password by logging out and then back in, but sooner or later of course I will simply be logged out - you know it happens. Will I at that time ever be able to get back in to my Wikipedia account? And what's wrong with "Wikimedia vrt" that it won't let me log in to read the ticket? Bishonen | tålk 08:30, 11 August 2022 (UTC).

@Bishonen, you could try logging in, in an incognito window, so that it won't log you out. ― Qwerfjkltalk 10:54, 11 August 2022 (UTC)

Sorry, what? How do I get an incognito window without first logging out (which I'm now scared to do)? Please make all explanations in "for dummies" mode. Bishonen | tålk 11:03, 11 August 2022 (UTC).

Template:Replyto Follow the instructions here or press control-shift-p on Windows/Linux or command-shift-P on a Mac. Graham87 11:40, 11 August 2022 (UTC)

Right. I have now tried that, but got exactly the same result. Bishonen | tålk 11:56, 11 August 2022 (UTC).

@Bishonen Are you a VRT agent? If not then you can't access Wikimedia vrt. Nthep (talk) 12:27, 11 August 2022 (UTC)

I'm not. But I used to be able to read OTRS tickets all the same. Did I use the wrong kind of link? Another admin sent it to me because they wanted my opinion on the unblock request. Bishonen | tålk 13:25, 11 August 2022 (UTC).

@Bishonen I don't see you on the otrswiki:List of accounts (or the List of accounts/closed list). Note, vrt-wiki, and ticket.wikimedia.org don't use your WMF SUL logon, but a different account. If you have a different username there, we can look for it; otherwise this seems to be working as expected? Perhaps you are thinking about the Wikipedia:Unblock Ticket Request System tickets where unblock requests normally go, that uses SUL logon. — xaosflux ^Talk 13:32, 11 August 2022 (UTC)

Oh. Yes, maybe I was thinking of UTRS. I think I'll just decide it wasn't really important to look at the request. Thanks, everybody, for your help. Bishonen | tålk 15:07, 11 August 2022 (UTC).

Содержание

Strange one I've seen a few times already. In the Special:NewPagesFeed display of the first lines of an article, I get things like

"The men's tandem sprint B at the 2022 Commonwealth Games is part of the cycling programme, and took place on 31 July 2022. Содержание 1 Records 2 Schedule " (emphasis mine). This text is not visible in the article[1]. The meaning is "content". It isn't restricted to one editor either, I e.g. also see it at Swimming at the 2022 European Aquatics Championships – Men's 400 metre individual medley. But it does seem to be restricted to sports articles? An inobox issue or somethinhg else? Fram (talk) 09:22, 11 August 2022 (UTC)

Strange, it's like it's picking up the Russian translation of MediaWiki:Toc for some reason. But that message hasn't changed at all recently so far as I can tell. the wub "?!" 10:15, 11 August 2022 (UTC)

Yes, the text appears in place of "Contents" in the standard ToC header. it's as if Special:NewPagesFeed is suddenly running in a Russian-language "context" (in a vague, non-technical sense). It's Thursday, but there is no new MediaWiki version this week. Certes (talk) 10:23, 11 August 2022 (UTC)

It appears that Special:NewPagesFeed picks up the language of the editor who created the page. For example, for Swimming at the 2022 European Aquatics Championships – Women's 200 metre backstroke at Special:NewPagesFeed I see Template:Tq (emphasis mine). The page was created by Template:Noping, whose userboxes suggest that his English Wikipedia interface might be in Russian. —⁠andrybak (talk) 13:21, 11 August 2022 (UTC)

Similar situation with Cycling at the 2022 Commonwealth Games – Women's tandem 1 km time trial B by Template:Noping. Quote from feed: Template:Tq. —⁠andrybak (talk) 13:26, 11 August 2022 (UTC)

Special:NewPagesFeed changes quickly here and all reported examples were with Russian so I made a test with Danish at testwiki:NewPagesFeed language test. testwiki:Special:NewPagesFeed shows the Danish "Indholdsfortegnelse" instead of "Contents". PrimeHunter (talk) 16:13, 11 August 2022 (UTC)

The language at Special:NewPagesFeed appears to not be determined by the page creator but the most recent editor. I created the page with Danish as language and it displayed in Danish. I made an edit with English as language and it displayed in English. I made another edit with Danish as language and it now displays in Danish again. PrimeHunter (talk) 16:23, 11 August 2022 (UTC)

Sounds like a WP:BUG to report over at phab. — xaosflux ^Talk 16:26, 11 August 2022 (UTC)

Bug report filed: T315082. Rummskartoffel 14:38, 12 August 2022 (UTC)

Category appears to be empty?

Template:Tracked Is there a reason Category:Brooks & Dunn songs has a warning at the top saying "this category appears to be empty" when it's clearly not? I tried a null edit and nothing fixed it. Anyone know what might be causing this? Ten Pound Hammer • ^{(What did I screw up now?)} 18:34, 11 August 2022 (UTC)

Template:Re It's caused by Template:Songs category. How to fix that, I don't know. DuncanHill (talk) 18:42, 11 August 2022 (UTC)

Because *{{PAGESINCATEGORY:{{PAGENAME}}}} there is currently outputting 0, in error. — xaosflux ^Talk 18:43, 11 August 2022 (UTC)

Because {{PAGENAME}} is producing Brooks & Dunn songs rather than Brooks & Dunn songs * Pppery * _{it has begun...} 18:45, 11 August 2022 (UTC)

Possible bug on pages with "&" in the title — xaosflux ^Talk 18:49, 11 August 2022 (UTC)

I updated Template:Songs category/core with the workaround suggested on mw:Help:Magic_words - better now? 18:52, 11 August 2022 (UTC) — xaosflux ^Talk 18:52, 11 August 2022 (UTC)

Template:Ec According to the wayback machine, the "empty" warning has been present since at least 2016. The behavior of {{PAGENAME}} encoding certain special characters has been documented on MediaWiki.org since at least 2011 (originally added at mw:Help:Magic words, later moved to mw:Manual:PAGENAMEE encoding). Looks like a misfeature rather than a bug. * Pppery * _{it has begun...} 18:53, 11 August 2022 (UTC)

Seems to be phab:T37746. — xaosflux ^Talk 18:54, 11 August 2022 (UTC)

Full width of page

Hi, in browsing in Vector 2022 mode when I click hide contents on the left, I want the article to span the whole width of the page but it leaves an empty gap. I don't see the point in it. Why can't I shrink the left side and broaden out the page? That seems the best option from shrinking the contents.♦ Dr. Blofeld 21:26, 11 August 2022 (UTC)

Limiting the display width is deemed to be the best way. See Limiting content width There are several (many?) user scripts to fix this width issue, but yes, it really would be better if full width was just a standard Skin preference. — GhostInTheMachine ^{talk to me} 23:07, 11 August 2022 (UTC)

We have a gadget, but it still isn't getting that space back. I left a note in phab:T307901; if anyone has a clue (and hopefully not a lengthy javascript hack) input would be welcome. Here is a random article, in vector-2022, with the "wide" gadget on: <https://en.wikipedia.org/wiki/2010_Kilkenny_Senior_Hurling_Championship?useskin=vector-2022&withgadget=wide-vector-2022>. Notice, that even with both the sidebar and TOC collapse, that space is still wasted over there. That space does helpfully get deleted at widths under 1000px as a hint. — xaosflux ^Talk 23:26, 11 August 2022 (UTC)

Thanks. Where was the place to contact the site developers again? It goes the full width on pages without a table of contents but the table of contents on the left disrupts the shrinking of the side which is rather silly. Ensuring that you can broaden out to the page to the full width should be a development priority. ♦ Dr. Blofeld 09:59, 12 August 2022 (UTC)

The need for a full width option is explicitly not being addressed. See the other VP page — Issues that are not part of the Desktop Improvements project — GhostInTheMachine ^{talk to me} 10:07, 12 August 2022 (UTC)

@GhostInTheMachine I understand that the skin devs don't care about building that, which is why it will fall on to other volunteers. — xaosflux ^Talk 13:01, 12 August 2022 (UTC)

@all above: Go to Template:Myprefs, select "MonoBook" (it's first in the list) and save. Goodbye to most problems. --Redrose64 🌹 (talk) 20:22, 12 August 2022 (UTC)

That's been my default for most of the 16 years I've been here  :-). Even Monobook doesn't have the full page width option, with the task bar down the left. I can't believe that on small devices maximising the full width of the page for reading isn't a development priority!! It would be one of the first things I would look into if trying to maximise the usability of Wikipedia on smaller devices! ♦ Dr. Blofeld 08:04, 13 August 2022 (UTC)

I see a number of others have complained about it at here! I agree with them that the wide vector 2022 version should be default or at least an option in preferences instead of having to use java script. ♦ Dr. Blofeld 08:31, 13 August 2022 (UTC)

Issue with striking text

Just now I attempted to strike out an RfA vote and associated discussion here. Even though I added the correct <s>...</s> tags it managed to strike out everything after the opening tag. I managed to get around it with this, but something still seems off. Was it something I did (wouldn't surprise me), or is there some kind of glitch? (Side note: if there's a way of collapsing it without whacking out the vote tally I'd like to know it) The Blade of the Northern Lights (話して下さい) 00:02, 12 August 2022 (UTC)

# and : (and * and ;) start html elements that end at the end of the line they're on. Each <s> tag within one has to end in a matching </s> tag on the same line. If you really mean to strike the blocked user's comments and all replies - and I don't think that's justified - you have to put a separate <s>...</s> on each line. —Cryptic 00:27, 12 August 2022 (UTC)

Ah, that makes sense. Yeah, I'm fine with just striking the individual vote, I'll go do that now. But good to know for the future. The Blade of the Northern Lights (話して下さい) 00:35, 12 August 2022 (UTC)

Another way of putting it is that <s>...</s> is an inline element, lists are block elements. Block elements may only be enclosed by other block elements, but may enclose anything. Inline elements, by contrast, may be enclosed by anything, but may only enclose other inline elements. The <li>...</li> element is somewhere between: it may only be enclosed by <ol>...</ol> or <ul>...</ul> elements, there is no valid HTML syntax that permits one or more individual <li>...</li> elements to be enclosed unless you enclose the whole list, that is, outside of its <ol>...</ol> or <ul>...</ul> elements. --Redrose64 🌹 (talk) 20:42, 12 August 2022 (UTC)

How to force a screen reader to ignore the label for an OO.ui.ButtonWidget?

I have three buttons in my script labeled "B", "I" and "XYZ". They are styled as bold, italic and struck text respectively. They work fine. The have "bold", italic" and "strikethrough" respectively in their title attribute which is also good.
Unfortunately, not all screen readers are picking up on the title here. They should frankly ignore the label in this case, but how? https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.ButtonWidget only provides a solution for the opposite: to hide the label from view while allowing screen readers to still use it. I need the opposite.
I can only think of one way currently: to turn the "B", "I" and "XYZ" into SVG images so screen readers have no choice but to fall back on the title attribute. But the actual letters being used depend on the language and text rendering within SVG is a known PITA.
Isn't there another way to indicate the label isn't very useful for screen readers and they should fall back on the title? — Alexis Jazz (talk or ping me) 12:21, 12 August 2022 (UTC)

@Alexis Jazz There isn't a built-in way to do it in OOUI, but you can do it using the usual HTML attributes, like this: buttonWidget.$button.attr( 'aria-label', 'Blah blah' ). You shouldn't rely on title for screen reader accessibility, it works fine in some cases but not others, here's a long article about this: [2].

I would actually recommend doing the approach with image icons. OOUI includes icons for bold, italic and strikethrough, and they automatically adapt to the user language – see the "editing-styling" section in the demos: [3]. If you use an icon, you can add an accessible label to the OOUI button like this: invisibleLabel: true, label: 'Bold' (in addition to the title for sighted mouse users who hate icons). Matma Rex talk 19:02, 12 August 2022 (UTC)

Matma Rex, thanks, I'll use aria-label. Will read the article later.
I've considered using those icons. For a short while I actually did. There are several issues with them though. For one, my script works with just oojs-ui-core. In one benchmark I found that adding any icon dependency increased the load time by 300ms or so. Embedding some SVGs for the few icons I did need was faster. Another consideration was licensing: my script is public domain. Using only original icons, any screenshot of it can also be PD.
But probably most importantly: the OO.ui icons for bold/italic/strikethrough aren't that good. The strikethrough is particularly unclear. There were some regional issues as well. For example, using C for italic or V for bold is uncommon and confusing in Dutch. IIRC for my own version I looked mostly at which letters MS Word uses in its toolbar and made some considerations of my own. For example, using ABC for strikethrough (ABC) is common. It's a poor choice though. It's quite hard to see if the A and B are struck. No such problems with XYZ. And once I decided the strikethrough icons from OO.ui were really not acceptable for me, I had to do bold and italic as well to maintain consistency.
Thanks again for pointing me towards aria-label! — Alexis Jazz (talk or ping me) 20:34, 12 August 2022 (UTC)

Working with date & time magic words

Hi all, I am trying to find out how to use date & time magic words and add/subtract a specific number of days or hours to them and then represent them in the format we use for signature. [I thought of using {{CURRENTTIMESTAMP}} and, adding, for example, 5000000 for 5 days, but that should not work properly at the end of a month.] Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:36, 12 August 2022 (UTC)

CX Zoom, you need to use UNIX time: 1732236621. Five days from now: 2024-11-27T00:50:21+00:00
As for the signature format, must be a system message that comes after MediaWiki:Signature. Can't remember what it is though. — Alexis Jazz (talk or ping me) 12:46, 12 August 2022 (UTC)

See mw:Help:Extension:ParserFunctions##time. You may want something like {{#time:H:i, j F Y (e)|now + 5 days}} which displays as 00:50, 27 November 2024 (UTC). You'll need to check that the timezones displayed by e and asssumed by H etc are both the one you want. Certes (talk) 12:52, 12 August 2022 (UTC)

Thank you! —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:04, 12 August 2022 (UTC)

Certes, CX Zoom, that would only work for English Wikipedia and projects with the same timestamp format. There's a lot of variance across languages though. Well, I found the origin: https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/parser/Parser.php#4636: $d = $this->contLang->timeanddate( $ts, false, false ) . " ($tzMsg)";. Not sure if the format can be retrieved on-wiki at all. — Alexis Jazz (talk or ping me) 17:06, 12 August 2022 (UTC)

Div problems?

The behavior at Wikipedia talk:Manual of Style#Wikilawyering over passive voice surprised me. Maybe Template:Archive top is incompatible with <poem>...</poem>? WhatamIdoing (talk) 15:43, 12 August 2022 (UTC)

The poem tag is buggy. It wants to close a div early when being indented.

See [4].

<div class="test">
Agreed
:<poem>foo</poem>
True
</div>

Generates

<div class="test">
<p>Agreed
</p>
<dl><dd><div class="poem"></div></dd></dl>
<p>foo
</p>
</div>
<p>True
</p>

0xDeadbeef 16:00, 12 August 2022 (UTC)

<div>...</div> tags don't belong in <dd>...</dd> definition list markup. To indent <poem>...</poem> tags, this works:

<div class="test">
Agreed
<poem style="margin-left:1.6em">foo</poem>
True
</div>

which gives:

<div class="mw-parser-output"><div class="test">
<p>Agreed
</p>
<div style="margin-left:1.6em" class="poem">
<p>foo
</p>
</div>
<p>True
</p>
</div></div>

—Trappist the monk (talk) 16:37, 12 August 2022 (UTC)

Template:Replyto The fix was Template:Diff. --Redrose64 🌹 (talk) 13:26, 13 August 2022 (UTC)

There's nothing simple about that, unless you mean "The fix was asking you to fix it for me". ;-) Thank you for your help. WhatamIdoing (talk) 17:50, 13 August 2022 (UTC)

The addition of the style="margin-left: 1.6em;" attribute has nothing to do with the real fix, which was to remove the colon. That style attribute is there merely to simulate the indent that the colon had been intended to carry out. --Redrose64 🌹 (talk) 19:36, 13 August 2022 (UTC)

Template:Replyto There is nothing wrong with <div>...</div> tag in <dd>...</dd> definition list markup; this is demonstrated by the above use of <syntaxhighlight>...</syntaxhighlight> (which emits a div) following one or two colons perfectly satisfactorily (if you were to enclose this thread in {{atop}}/{{abot}} there would be no breakage). Indeed, the HTML spec explicitly allows a dd element to contain flow content, and a div element can be used where flow content is expected. --Redrose64 🌹 (talk) 13:37, 13 August 2022 (UTC)

If you all settle things and decide that there needs to be a change, then I'm willing to write up any needed Phab tickets, but I think you'll need to tell me what to say. WhatamIdoing (talk) 17:51, 13 August 2022 (UTC)

The bug will be in the poem extension, but I'm not a PHP coder. --Redrose64 🌹 (talk) 19:39, 13 August 2022 (UTC)

Perhaps I think that <div>...</div> tags don't belong in <dd>...</dd> definition list tags because {{reflist talk}} (which is wrapped in <div>...</div> tags) doesn't work in indented discussions. Here is a <ref>some text</ref>:

Template:Reflist talk

Special:ExpandTemplates gives this:

<div class="mw-parser-output"><p><sup id="cite_ref-1" class="reference"><a href="#cite_note-1">&#91;1&#93;</a></sup>
</p>
<dl><dd><dl><dd><dl><dd><dl><dd><style data-mw-deduplicate="TemplateStyles:r1044749286">.mw-parser-output .reflist-talk{margin:auto 2em;border:1px dashed #AAAAAA;padding:4px;padding-left:1em}.mw-parser-output .reflist-talk-title{font-weight:bold}</style><div class="reflist-talk"></div></dd></dl></dd></dl></dd></dl></dd></dl>
<p class="reflist-talk-title">References</p>
<style data-mw-deduplicate="TemplateStyles:r1011085734">.mw-parser-output .reflist{font-size:90%;margin-bottom:0.5em;list-style-type:decimal}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}</style><div class="reflist">
<div class="mw-references-wrap"><ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-1">^</a></b></span> <span class="reference-text">some text</span>
</li>
</ol></div></div>
</div>

What actually renders in my browser is this:

<dd><style data-mw-deduplicate="TemplateStyles:r1044749286">.mw-parser-output .reflist-talk{margin:auto 2em;border:1px dashed #AAAAAA;padding:4px;padding-left:1em}.mw-parser-output .reflist-talk-title{font-weight:bold}</style><div class="reflist-talk"></div></dd></dl></dd></dl></dd></dl></dd></dl>
<p class="reflist-talk-title">References</p>
<style data-mw-deduplicate="TemplateStyles:r1011085734">.mw-parser-output .reflist{font-size:90%;margin-bottom:0.5em;list-style-type:decimal}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}</style><div class="reflist">
<div class="mw-references-wrap"><ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-1">^</a></b></span> <span class="reference-text">some text</span>
</li>
</ol></div></div>

Is it the style element (which is not flow content) that breaks this (common) use case?

—Trappist the monk (talk) 11:58, 14 August 2022 (UTC)

No, it's the part of the MediaWiki software that nowadays does the job that was formerly carried out by HTML Tidy. What seems to happen is that if all of the "untidy" HTML is on one line, the tidying routines are happy. If you have

<poem>Line one
Line two</poem>

placed hard left, what this generates is

<div class="poem">
<p>Line one<br>
Line two
</p>
</div>

and if we take that, remove all the newlines, and indent it, it works as expected:

Line one
Line two

But if there's a newline in there somewhere (it doesn't really matter where), some of the end tags are moved from their correct position to a point that is semantically too early, thus terminating certain elements that should have been left open. Consider this simple example:

This is a div and it's formatted correctly

This is a div

and it's broken

The MediaWiki software is assuming that the newline should terminate the div and the five enclosing dl/dd pairs, and that the phrase "and it's broken" should be enclosed in <p>...</p> tags. --Redrose64 🌹 (talk) 16:25, 14 August 2022 (UTC)

I stripped all of the newlines out of {{reflist-talk/sandbox}} and got the same result as the live version above so if the issue is newlines, it doesn't appear to be fixable by tweaking the template.

—Trappist the monk (talk) 16:55, 14 August 2022 (UTC)

Enabling zebra stripes when previewing edits

Hey guys. I'm trying to add to my JavaScript so that I can see zebra stripes on sortable tables with the zebra class added, which I've successfully been able to do so far per this article. The code provided in the article only enables me to see the zebra stripes when the page is loaded and when I sort a column, but does anyone know what the code would be so that I can see the zebra stripes when previewing edits? At the moment, I can only see the zebra stripes when previewing once I click on a column to sort it, but I'm wondering if there's a way that you can see them immediately upon previewing edits so that I don't have to sort a column to see the zebra stripes each time I want to preview an edit – more than happy to admit that JavaScript isn't my strong suit, so thought I'd see if anyone had a rough idea of what the code might be. Thanks! 4TheWynne (talk • contribs) 16:10, 13 August 2022 (UTC)

You don't need JavaScript for this. Try

.sortable tr:nth-child(odd) {
	background-color: #EAECF0;
}

(This is just for you, obviously. Don't add zebra or any class that's not supported by the site in wikitext.) Nardog (talk) 18:34, 14 August 2022 (UTC)

What's the difference between API lists gblrename/promote and gblrename/rename?

Where can I get an information about Mediawiki API? I'm an interesting in what's difference between this API lists:

• https://meta.wikimedia.org/w/api.php?action=query&format=xml&list=logevents&leaction=gblrename%2Frename
• https://meta.wikimedia.org/w/api.php?action=query&format=xml&list=logevents&leaction=gblrename%2Fpromote

MBH (talk) 04:17, 14 August 2022 (UTC)

The MediaWiki API includes its own documentation under api.php?action=help. In your case, that would be at https://meta.wikimedia.org/w/api.php?action=help&modules=query%2Blogevents, but individual leactions don't seem to be documented there. Rummskartoffel 10:42, 14 August 2022 (UTC)

I knew all this before posting here.MBH (talk) 18:19, 14 August 2022 (UTC)

rename is where all renames get logged these days. promote was used as a part of the SUL finalization workflows, except there was a bug earlier this year which caused some requests made with Special:GlobalRenameRequest get logged there instead. Those 'broken' renames also have a log entry that appears that it was performed by myself when we fixed that issue. Taavi (talk!) 12:05, 14 August 2022 (UTC)

Thanks. MBH (talk) 18:19, 14 August 2022 (UTC)

Question about <math> markup element bug

There is a known bug in the <math> markup element. The bug is: https://phabricator.wikimedia.org/T268279 This bug is a couple of years old. The bug is: when a mobile user is viewing a Wikimedia page in dark mode (white text on a black background), the <math> element sometimes draws black text on a black background. That is bad, because the formula is invisible. I suppose this bug doesn't get much attention because (a) it only happens when a user has Dark Mode enabled; (b) only on phones & iPads; and (c) only if the <math> element is used in certain ways.

One solution I found that works in many cases is to change the markup from <math display="block> to :<math> . That fixes the issue in my test cases. This change is only proposed for simple formulae that take a single line (so the "block" display option is not significant). The change appears to have no downsides (provided the formula is a single line).

My question is: is there an expert in the Wikimedia <math> markup element that I can ask to confirm that my suggested solution won't impact the display of formulae? And also to ask why adding display="block" changes the text color? I posted a note in https://phabricator.wikimedia.org/T268279 , but how can I ask the folks responsible for the <math> markup element about this? Noleander (talk) 21:21, 14 August 2022 (UTC)

I looked thru the archives of Village Pump, and found this discussion: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)/Archive_138#Math_block_display This was a proposal to prohibit indenting <math> with a colon, but the proposal was not adopted. The consensus seems to be that <math display="block"> is generally desirable (for accessibility reasons) but is not a requirement, and :<math> is acceptable. That discussion aside, my key question remains: why does adding display="block" to <math> change the text color in dark mode within Wikipedia app? Noleander (talk) 23:11, 14 August 2022 (UTC)

Please avoid posting in multiple locations. For others, see discussion at template talk:Math. Izno (talk) 04:43, 15 August 2022 (UTC)

Discussion subscriptions

Template:Tracked Is there a way to subscribe to project discussions? I see that section subscription are available at WP:ANI, but, it would be nice to also be able to subscribe to discussions at, WP:CFD or Wikipedia:Afd, WP:FFD and the like. - FlightTime (open channel) 23:22, 14 August 2022 (UTC)

Template:Re not today. The primary reason is that "subscribe" only works on level 2 headings, and those pages are using level 3 or 4 headings. phab:T298617 may be a good place to leave more feedback on that. — xaosflux ^Talk 02:19, 15 August 2022 (UTC)

Odd image placement and effect on bullets

The article Danger Lights is about an old movie whose copyright has expired. The wikitext starts with

 {{short description|1930 film}}
 {{Use mdy dates|date=August 2017}}
 {{Infobox film ... }}
 [[File:... |thumb| ...]]
 [[File:... |thumb| ...]]

Both of the File: links point to full versions of the movie. (Below, I will call them the "first" and "second" thumbnails.) Next in the wikitext is the text of the lead section, then a section header for the Plot. That's all fine. But before the actual text of the plot there is another link,

 [[File:... |left|thumb| ...]]

which links to a screenshot of the movie's title. And what I'm talking about here is the positioning of the "third" thumbnail, the one for that screenshot; note that this one is left-aligned.

If I view this article and vary the width of the window, I see that the infobox is always at top right, with the first two thumbnails also on the right and immediately below it. The third thumbnail may appear at the top of the Plot section (as the wikitext suggests) if the window is so narrow that that is below the bottom of the second thumbnails. As the window is widened, the third thumbnail always stays below the bottom of the second thumbnails (thus causing it to fall in the middle of the Plot section) until the window is widened to the point where text can reasonably go between the left- and right-aligned thumbnails. Then the third thumbnail jumps up so that its top aligns with the bottom of the first thumbnail.

Okay, that's a little weird to watch, but I can see why it might be reasonable. Still, it seems to me that once the window is wide enough, the third thumbnail could be placed at the top left of the section as the wikitext indicates; it doesn't need to be aligned in relation to the other thumbnails.

And now, more important, look what happens if you keep widening the window so that the entire Plot section fits higher in the window than the bottom of the first thumbnail. At this point the third thumbnail finds itself down in the following section, the Cast. Note that this section consists of a bulleted list. Well, as I see it in Firefox, whichever bullet item aligns with the top of the third thumbnail is broken: the bullet itself aligns with the bullets above the thumbnail, but the content of that bullet point aligns with the ones below. So the list ends up formatted something like this:

    •  actor 1
    •  actor 2
    •              actor 3
                •  actor 4
                •  actor 5

And that's clearly a bug.

(If you want to reply, please do it here, not to the talk page for my IP address.) --174.95.81.219 (talk) 02:52, 15 August 2022 (UTC)

It's a known issue, fixed with {{stack}}.[5] PrimeHunter (talk) 03:50, 15 August 2022 (UTC)