Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.


Full width of page[edit]

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)Reply[reply]

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)Reply[reply]
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://wiki.alquds.edu/?query=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)Reply[reply]
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)Reply[reply]
The need for a full width option is explicitly not being addressed. See the other VP pageIssues that are not part of the Desktop Improvements projectGhostInTheMachine talk to me 10:07, 12 August 2022 (UTC)Reply[reply]
@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)Reply[reply]
@all above: Go to Preferences → Appearance, select "MonoBook" (it's first in the list) and save. Goodbye to most problems. --Redrose64 🌹 (talk) 20:22, 12 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Thanks for the MonoBook suggestion...earlier this summer I switched from plain Vector to Vector2022 & it is different. I must say that MonoBook is noticeably faster both for viewing & edits, so it will be my "go-to" preference. JoeNMLC (talk) 20:17, 15 August 2022 (UTC)Reply[reply]

Div problems?[edit]

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)Reply[reply]

The poem tag is buggy. It wants to close a div early when being indented.
See [1].
<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)Reply[reply]
<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)Reply[reply]
@WhatamIdoing: The fix was somewhat simpler. --Redrose64 🌹 (talk) 13:26, 13 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@Trappist the monk: 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)Reply[reply]
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)Reply[reply]
The bug will be in the poem extension, but I'm not a PHP coder. --Redrose64 🌹 (talk) 19:39, 13 August 2022 (UTC)Reply[reply]
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>:[1]

References

  1. ^ some text
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Enabling zebra stripes when previewing edits[edit]

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)Reply[reply]

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)Reply[reply]
Nardog, just saw this now – thanks for getting back to me. To clarify, I'm not simply wanting to do this as a personal thing for all sortable tables (for what it's worth, I did try your method, and the stripes go all over the place in sortable tables with rowspans, which is still a lot) – I'm specifically looking to use this method for statistics tables in AFL/AFLW player articles. Currently, all tables have zebra stripes manually added, but when you sort a column, the zebra stripes move/bunch up and look messy, which is why I wanted to try removing the manual stripes, adding the zebra class and adding the stripes this way, and then discuss it at WT:AFL as something that could be implemented project-wide. 4TheWynne (talk contribs) 19:16, 15 August 2022 (UTC)Reply[reply]
zebra stripes manually added Um, yeah, please remove them asap. What you're looking for is feasible with TemplateStyles, but is there a WikiProject consensus for this? Nardog (talk) 22:52, 15 August 2022 (UTC)Reply[reply]
Nardog, no, I don't have a consensus for this at WT:AFL yet – that's why I mentioned I wanted to try and find the correct way to add the stripes first and then bring it up at WikiProject level, that way I can show them the right method and then discuss implementing it project-wide. See Dane Swan#Statistics, as an example of where I'm coming from, but if the manual stripes are a big no-no, I'll definitely bring this up – we've made other improvements (mostly accessibility-related) to statistics tables via discussions at WikiProject level in the past, but this is clearly one that's just gone unnoticed until I brought it up here. 4TheWynne (talk contribs) 04:20, 16 August 2022 (UTC)Reply[reply]
Turns out there already is {{Alternating rows table}}. Nardog (talk) 06:11, 16 August 2022 (UTC)Reply[reply]

Awesome. I've looked into it, and it appears you can only add one |style element to the template (there are two which apply to the table, the font size and alignment); I've gone with the font size (which would be applied to all of the AFL player statistics start templates), given you can easily align a whole row in the table itself. As an example, this is what Tony Lockett's table would look like with the changes applied:

Tony Lockett amended table
Legend
  G  
Goals
  K  
Kicks
  D  
Disposals 
  T  
Tackles
  B  
Behinds 
  H  
Handballs 
  M  
Marks
  †  
Led the league for 
the season
Season Team No. Games Totals Averages (per game)
G B K H D M T G B K H D M T
1983 St Kilda 37 12 19 17 76 26 102 44 1.6 1.4 6.3 2.2 8.5 3.7
1984 St Kilda 14 20 77 44 146 19 165 108 3.9 2.2 7.3 1.0 8.3 5.4
1985 St Kilda 14 21 79 22 146 32 178 112 3.8 1.0 7.0 1.5 8.5 5.3
1986 St Kilda 14 18 60 29 119 36 155 85 3.3 1.6 6.6 2.0 8.6 4.7
1987 St Kilda 14 22 117 52 226 49 275 164 16 5.3 2.4 10.3 2.2 12.5 7.5 0.7
1988 St Kilda 4 8 35 19 65 19 84 44 6 4.4 2.4 8.1 2.4 10.5 5.5 0.8
1989 St Kilda 4 11 78 24 122 18 140 92 5 7.1 2.2 11.1 1.6 12.7 8.4 0.5
1990 St Kilda 4 12 65 34 112 16 128 84 11 5.4 2.8 9.3 1.3 10.7 7.0 0.9
1991 St Kilda 4 17 127 51 190 33 223 140 7 7.5 3.0 11.2 1.9 13.1 8.2 0.4
1992 St Kilda 4 22 132 58 214 30 244 157 12 6.0 2.6 9.7 1.4 11.1 7.1 0.5
1993 St Kilda 4 10 53 12 85 26 111 63 7 5.3 1.2 8.5 2.6 11.1 6.3 0.7
1994 St Kilda 4 10 56 26 100 16 116 76 7 5.6 2.6 10.0 1.6 11.6 7.6 0.7
1995 Sydney 4 19 110 44 176 42 218 139 16 5.8 2.3 9.3 2.2 11.5 7.3 0.8
1996 Sydney 4 22 121 63 212 45 257 168 21 5.5 2.9 9.6 2.0 11.7 7.6 1.0
1997 Sydney 4 12 37 21 65 23 88 50 7 3.1 1.8 5.4 1.9 7.3 4.2 0.6
1998 Sydney 4 23 109 36 167 41 208 121 9 4.7 1.6 7.3 1.8 9.0 5.3 0.4
1999 Sydney 4 19 82 38 141 27 168 112 15 4.3 2.0 7.4 1.4 8.8 5.9 0.8
2002 Sydney 46 3 3 0 5 2 7 1 3 1.0 0.0 1.7 0.7 2.3 0.3 1.0
Career 281 1360 590 2367 500 2867 1760 142 4.8 2.1 8.4 1.8 10.2 6.3 0.7

Feel free to compare it to the current table at the article, but this version also includes the other stylistic changes that have not yet been applied to this table but been applied to other tables. I think this might be the best way to go, but let me know if there's an easier way/workaround that I might have missed – thanks. 4TheWynne (talk contribs) 07:04, 16 August 2022 (UTC)Reply[reply]

you can only add one |style element No you can just write |style=font-size:90%; text-align:center. Nardog (talk) 07:28, 16 August 2022 (UTC)Reply[reply]
Ah, OK – I initially thought it would have needed to be formatted as |style="font-size:90%; text-align:center" but it didn't work, so I wasn't sure, but I suppose that makes sense that it would be formatted that way given it's a template parameter. Thanks for the help! 4TheWynne (talk contribs) 08:19, 16 August 2022 (UTC)Reply[reply]

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

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

MBH (talk) 04:17, 14 August 2022 (UTC)Reply[reply]

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)Reply[reply]
I knew all this before posting here.MBH (talk) 18:19, 14 August 2022 (UTC)Reply[reply]
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)Reply[reply]
Thanks. MBH (talk) 18:19, 14 August 2022 (UTC)Reply[reply]

Question about <math> markup element bug[edit]

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)Reply[reply]

I looked thru the archives of Village Pump, and found this discussion: https://wiki.alquds.edu/?query=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)Reply[reply]
Please avoid posting in multiple locations. For others, see discussion at template talk:Math. Izno (talk) 04:43, 15 August 2022 (UTC)Reply[reply]

Discussion subscriptions[edit]

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)Reply[reply]

@FlightTime: 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)Reply[reply]

Odd image placement and effect on bullets[edit]

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)Reply[reply]

It's a known issue, fixed with {{stack}}.[2] PrimeHunter (talk) 03:50, 15 August 2022 (UTC)Reply[reply]
So it was! Thanks. But now I wonder if there are other circumstances (not fixable by {{stack}}) where a thumbnail can float down into a bulleted list and break its formatting in the same way. --174.95.81.219 (talk) 17:56, 15 August 2022 (UTC)Reply[reply]
This can happen whenever you alternate left and right aligned elements. Stack fixes this, because it basically turns multiple floated elements into one single floating element. Generally bulleted lists are not floated, so it cannot break in that way. There is however another weird issue with bulleted lists. A bulleted list places its bullets outside of the normal content flow (this is just how the CSS and html has defined and implemented this). This can cause bullets to overlap with other elements, including left floating items. For this problem there is {{flowlist}}, although that too has a downside if the list is longer then the item being floated. —TheDJ (talkcontribs) 18:51, 15 August 2022 (UTC)Reply[reply]
When there are box-type objects (perhaps images, but not necessarily) that are narrower than full width and also floated (left or right), the sequence that they occur in the page source governs the sequence that they are displayed. Another way of putting it is that if you have this markup:
[[File:Example A.jpg|right|Image A]]
[[File:Example B.jpg|left|Image B]]
the top edge of image B cannot be any higher than the top edge of image A. So if image A is displaced down the page, perhaps by an infobox, image B must be displaced by a similar amount. Most browsers behave like this: but there was one, perhaps IE (around about versions 6/7/8), which allowed the "later" left-aligned image to move up the page to the expected position. --Redrose64 🌹 (talk) 20:33, 15 August 2022 (UTC)Reply[reply]

Length of audio files[edit]

I noticed a difference of one second in the displayed length of audio files. Example: Houston, we have a problem contains this file with a length of 2:59 minutes:


The white arrow opens a player which displays a length of 2:58 minutes. I think this is confusing. As far as I can see this 1 second difference happens for all media files. Kallichore (talk) 17:30, 15 August 2022 (UTC)Reply[reply]

When you begin playback, technically it doesn't display the duration, it displays the "remainder". The file is actually 2:58.something. Remainder will show 2:58 (a floored int) and duration will show 2:59 ( a ceiled int). —TheDJ (talkcontribs) 18:44, 15 August 2022 (UTC)Reply[reply]
Ok, that sounds logical. The effect is easier to understand using short audio files like this one. I never noticed this effect before, has there been a recent change? --Kallichore (talk) 21:43, 15 August 2022 (UTC)Reply[reply]

Tech News: 2022-33[edit]

21:06, 15 August 2022 (UTC)

MonoBook skin - How change button colors for "Publish changes" "Show preview"[edit]

Recently, I changed skin to MonoBook, and am unable to change these editing button colors. I searched Archive and did not find a solution.

Below css works okay for these two skins

User:JoeNMLC/vector.css

User:JoeNMLC/vector-2022.css

CSS

input#wpSave { background-color: #ff8080; }

input#wpPreview { background-color: #98fb98; }

As a test, I added above to User:JoeNMLC/common.css and it is ignored. What would be good css change for Monobook? JoeNMLC (talk) 21:27, 15 August 2022 (UTC)Reply[reply]

Omit -color. PrimeHunter (talk) 22:22, 15 August 2022 (UTC)Reply[reply]
 Done - Thanks so much. I would never figured that out in a million years. JoeNMLC (talk) 00:24, 16 August 2022 (UTC)Reply[reply]
Explanation: The background in MonoBook is actually an image. You could have said input#wpSave { background-color: #ff8080; background-image:none} to remove the image so background-color becomes visible. background can set all background properties at once, where no image part means no image. PrimeHunter (talk) 00:55, 16 August 2022 (UTC)Reply[reply]

Strange error message[edit]

Earlier today I clicked on a link in my contributions and got this message on a pink background:

[cd667484-97b2-47bd-842c-52b225e4dd26] 2022-08-15 20:28:20: Fatal exception of type "TypeError"

I got a similar message the second time and then somehow everything worked all right.

Vchimpanzee • talk • contributions • 22:31, 15 August 2022 (UTC)Reply[reply]

I have gotten that occasionally for years in different places and just ignored it when it's temporary. A phab: search finds many reports about various situations where it has happened. PrimeHunter (talk) 22:58, 15 August 2022 (UTC)Reply[reply]
Interesting. I got one of those yesterday afternoon as well, must have been some system-wide but transient glitch. Wikipedia is a big system with lots of moving parts. Shit happens. -- RoySmith (talk) 14:03, 16 August 2022 (UTC)Reply[reply]

Color differentiation in reference numbering[edit]

Wikipedia seems to provide single (blue) color regime without option of color differentiation.

Say we have one color for a reference where WP community finds citation perfect, and other color options may be gray / violet or orange / red for different level of imperfections. Why such differentiation is not available in WP?

  • Is that because it is technically not possible in wiki software?
  • Or was it a consensus policy decision to not to have such differentiation? If it was a consensus policy decision then link to the discussion.


Where I am coming from? An on going discussion @ Wikipedia:Village pump (miscellaneous)#Mass addition of Cleanup bare URLs template. One alternate solution to the issues raised there would have been color differentiation. A separate color for technical imperfections in referencing and a separate color for concerns of substandard content referencing. Was such color differentiation was never thought of by community ever seriously?


What were previous discussions,if any, just want to understand. If not then inputs for such possibilities.

Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 03:30, 16 August 2022 (UTC)Reply[reply]

@Bookku using only color to differentiate the meaning of text is not accessible to all of our readers. If some sort of "quality of a reference" indicator was needed, it would need to also at least have symbols or text. As this is VPT, tech wise there isn't a mechanism for the software to color-code portions of text based on "imperfections" today - and I'm not even sure where that would begin design-wise. (What are all the user stories related to such an ask?) — xaosflux Talk 13:43, 16 August 2022 (UTC)Reply[reply]
WP:UPSD might be related to what you're looking for, but keep in mind the very very big warning at the top of the page. Headbomb {t · c · p · b} 15:27, 16 August 2022 (UTC)Reply[reply]

Database error[edit]

Resolved
 – JCrespo (WMF) (talk) 18:24, 18 August 2022 (UTC)Reply[reply]

I got this error while trying to save an edit:

[c42d457a-4fe1-4b6f-b69f-0cf0ad0ab0b9] 2022-08-16 04:08:56: Fatal exception of type "Wikimedia\Rdbms\DBTransactionError"

-- 64.229.88.43 (talk) 04:10, 16 August 2022 (UTC)Reply[reply]

And then [11857e39-c6b5-4941-93c0-a4aed63ca40a] and other new codes as I try to save the same edit or modify my edit and save -- 64.229.88.43 (talk) 04:12, 16 August 2022 (UTC)Reply[reply]
There's an ongoing issue — try saving the edit again in a few minutes Face-smile.svgTheresNoTime (talk • she/her) 04:15, 16 August 2022 (UTC)Reply[reply]
UPDATE: I'm able to save this edit now. It seems to have cleared up about the same time as the CAPTCHA error I reported below? -- 64.229.88.43 (talk) 04:48, 16 August 2022 (UTC)Reply[reply]
I wanted to share with you the wiki page including the detailed incident report: wikitech:Incidents/2022-08-16_x2_databases_replication_breakage. Apologies for the disruption- error messages appeared during 36 minutes for some users, preventing or making more difficult edits and certain actions, such as probably the ones mentioned on the section below. This was quickly detected by automated monitoring and a fix was implemented. Technology measures have been put in place and more are planned soon to avoid the same or similar issues from happening in the future. Again, sorry for the issues, and happy editing! --JCrespo (WMF) (talk) 18:24, 18 August 2022 (UTC)Reply[reply]

CAPTCHA missing[edit]

Resolved
 – JCrespo (WMF) (talk) 18:27, 18 August 2022 (UTC)Reply[reply]

On a different edit that triggers the CAPTCHA mechanism, the CAPTCHA image is missing, so one is unable to respond to the CAPTCHA challenge as there is no image to interpret.

I assume this is related to the database problem I reported above? (this edit is unrelated to that one) -- 64.229.88.43 (talk) 04:21, 16 August 2022 (UTC)Reply[reply]

That I'm not sure about.. which page & is it consistently not appearing? (i.e. close the tab, re-open, refresh the page etc.) — TheresNoTime (talk • she/her) 04:39, 16 August 2022 (UTC)Reply[reply]
Yes, it's consistently not appearing. It happens when I try to use {{subst:submit}} on any draft article -- 64.229.88.43 (talk) 04:42, 16 August 2022 (UTC)Reply[reply]
UPDATE: It just cleared. After reloading a couple of minutes after my last set of tries, the CAPTCHA is now loading properly -- 64.229.88.43 (talk) 04:46, 16 August 2022 (UTC)Reply[reply]
I can also save the edit I was having problems with with the database error reported above... so it seems interlinked? -- 64.229.88.43 (talk) 04:47, 16 August 2022 (UTC)Reply[reply]
Please see my comment on the previous section. Apologies again. --JCrespo (WMF) (talk) 18:27, 18 August 2022 (UTC)Reply[reply]
wikitech:Incidents/2022-08-16_x2_databases_replication_breakage is interesting, though I don't see the connection between what the DBAs did to strip cached edits and in-process atmoicized writes, and the generation or display of CAPTCHAs. Perhaps I'm missing something since I'm not a DBA fluent with how MediaWiki uses MariaDB to generate squiggly images for verification challenges. Thanks for the info -- 64.229.88.43 (talk) 05:12, 19 August 2022 (UTC)Reply[reply]
Hi, thanks for your question. I am certainly not a MediaWiki expert, but there is a dependency between captcha functionality for enwiki and mainstash, which was what temporarily had a disruption:
     root@db1152[mainstash]> select count(*) FROM objectstash where keyname like 'enwiki:captcha:%'\G 
     *************************** 1. row *************************** 
     count(*): 13604 
     1 row in set (0.012 sec)
Mainstash used to live on Redis but now lives on MariaDB servers.
This, added to the temporal coincidence of both the start and end of the issue, based on error logs, make me quite sure both issues were related. This is why I mentioned on the report edit-related activities, as things beyond pure wiki content edits were potentially affected, but not reads.
Again, sorry for the disruption. --JCrespo (WMF) (talk) 09:00, 19 August 2022 (UTC)Reply[reply]

Can't delete file[edit]

Resolved
 – File deleted. — xaosflux Talk 13:38, 16 August 2022 (UTC)Reply[reply]

Hi, I can't delete File:Asmaa Galal 28909190103378.JPG. After hitting the delete button, I get the following error message: "Error deleting file: Could not acquire lock. Somebody else is doing something to this file." A bug? plicit 12:26, 16 August 2022 (UTC)Reply[reply]

@Explicit: I was able to delete the file for you; may have been something temporary like thumbnail generation going on. — xaosflux Talk 13:38, 16 August 2022 (UTC)Reply[reply]

Map missing border.[edit]

When I view the map at Northeast Conference#History the border between Maryland and Pennsylvania is missing (the continuation of the border that is between Pennsylvania and West Virginia is fine). When I click the "Interactive Fullscreen Map", it is there. (It looks wierd to have the state of Maryvania. :) )Naraht (talk) 14:22, 16 August 2022 (UTC)Reply[reply]

I suspect what you're seeing is T288897. In fact, I'm almost certain it is, because I can make the effect come and go by looking at the interactive map in various zoom levels. @TheDJ: you closed this phab as resolved, but it's clearly not. Do you know what real status is? -- RoySmith (talk) 14:40, 16 August 2022 (UTC)Reply[reply]
Actually, it looks like the currently active issue is T218097 -- RoySmith (talk) 14:42, 16 August 2022 (UTC)Reply[reply]

Copy-paste article title also gets edit links[edit]

Screen shot of article title selected.png
Screenshot of pasted text showing edit tags.png

When I triple-click on the title of an article, it looks like the correct text is selected. But, when I copy-paste that, I find that I've also got the "edit" and "edit source" links. It's not just article titles; the same thing happens on any header.

Well, sometimes. See the second screenshot. The first line, with just "Columbia University" was pasted when I was in the source editor. The second line with the edit links was after I switched to the visual editor and pasted the same text. If I Command-Shift-V (Paste and Match Style), I just get the "Columbia University" part.

Any idea what's going on here? I'm sure this is at least partially platform-dependent (I'm on MacOS, Chrome), but perhaps there's some different markup which might give the browser/OS a better hint about how much text to include when doing copy-paste? -- RoySmith (talk) 14:28, 16 August 2022 (UTC)Reply[reply]

@RoySmith which skin are you using? — xaosflux Talk 14:42, 16 August 2022 (UTC)Reply[reply]
Vector. -- RoySmith (talk) 14:45, 16 August 2022 (UTC)Reply[reply]
@RoySmith one thing I notice is that you have that text there are all, that is not default. I'm assuming you are using a gadget (perhaps MediaWiki:Gadget-edittop.js) or a userscript that is inserting those extra links in to the title? That along with many of your other scripts (e.g. from User:RoySmith/common.js) may be causing portions of the page to load at different times. To troubleshoot, turn off all your scripts and see if you can narrow this down to a conflict between scripts first. — xaosflux Talk 14:53, 16 August 2022 (UTC)Reply[reply]
Hmmm, I seem to remember that was the same advice you gave me last time :-) Anyway, I tried it with an empty common.js, which didn't change anything. I disabled "Add an [edit] link for the lead section of a page" (which I assume is Gadget-edittop?), no effect there either. Well, it made the link on the lead section go away, but I still had the same issue on section heads. -- RoySmith (talk) 15:19, 16 August 2022 (UTC)Reply[reply]
@RoySmith thank you, that you are getting it on section headers too is useful - as having the links there are "standard". — xaosflux Talk 15:21, 16 August 2022 (UTC)Reply[reply]
BTW, not that this is any surprise, but if I paste into TextEdit or Stickies, I get the "edit" and "edit source" links (and they work when you click on them). Here's the RTF that's generated if I paste into TextEdit:
{\rtf1\ansi\ansicpg1252\cocoartf2639
\cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fswiss\fcharset0 Helvetica-Bold;\f1\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;\red255\green255\blue255;\red0\green0\blue0;\red66\green71\blue75;
\red9\green47\blue157;}
{\*\expandedcolortbl;;\cssrgb\c100000\c100000\c100000;\cssrgb\c0\c0\c0;\cssrgb\c32941\c34902\c36471;
\cssrgb\c2353\c27059\c67843;}
\margl1440\margr1440\vieww11520\viewh8400\viewkind0
\deftab720
\pard\pardeftab720\partightenfactor0
\f0\b\fs28\fsmilli14400 \cf0 \cb2 \expnd0\expndtw0\kerning0
\outl0\strokewidth0 \strokec3 22 June 2022
\f1\b0\fs20 \cf4 \strokec4 [{\field{\*\fldinst{HYPERLINK "https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&veaction=edit&section=1"}}{\fldrslt \cf5 \ul \ulc5 \strokec5 edit}}\'a0|\'a0{\field{\*\fldinst{HYPERLINK "https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&action=edit&section=1"}}{\fldrslt \cf5 \ul \ulc5 \strokec5 edit source}}]
\f0\b\fs28\fsmilli14400 \cf0 \strokec3 \
-- RoySmith (talk) 15:27, 16 August 2022 (UTC)Reply[reply]
I haven't been able to duplicate this yet. There are a few new tickets open about having extra newline characters in some cases, but that's different. — xaosflux Talk 15:34, 16 August 2022 (UTC)Reply[reply]
Well, this has gotten even more interesting. I can reproduce this Safari, but not Firefox. That in itself isn't hugely surprising since Chrome and Safari share the same Webkit heritage (at least originally). What is astounding to me is that I can repro it in a Chrome incognito window, not logged in! It only happens if you triple-click to select. If you drag-select, or double-click on a single word heading, you don't get the "[edit]".
At this point, I'm leaning towards this being a Webkit bug. On a Mac, triple-click means something like "select the entire paragraph". In a browser, I guess that means something like, "select the entire enclosing element which meets some criteria". I'm not quite sure what that criteria is, but it looks like what it's doing is grabbing everything in the enclosing h1 (h2, etc) tag, which includes the "[edit]" link. I can't fault Webkit for having a different definition of how much text to select than other browsers do, but it certainly seems wrong that the range of text copied should differ from the range of text highlighted.
Now I need to figure out how much further I want to go down this particular rathole :-) -- RoySmith (talk) 17:54, 16 August 2022 (UTC)Reply[reply]
Correct. Triple click is a paragraph select. The H1 is interpreted to be the paragraph. Everything within that block is selectable text and that includes the edit links. It's just that the links are visually positioned 'out of band'. Because of the weird positioning it is difficult for the browser to show that the edit links were also selected. You can actually see it slightly on H2 headers, the selection color creates a line just above the underline in that case. As far as I know this has always been like this. —TheDJ (talkcontribs) 08:31, 17 August 2022 (UTC)Reply[reply]
This happens to me in Chrome+Monobook when using the reply tool. (And I also get the annoying "Convert formatting to wikitext? You pasted content with rich formatting. Would you like to convert this formatting to wikitext?" popup. I never ever want to paste content with rich formatting. Is there a way to disable this?) —Kusma (talk) 20:26, 16 August 2022 (UTC)Reply[reply]
.mw-editsection is set to user-select: none;. I assume it's overridden by something on your end. Nardog (talk) 10:07, 17 August 2022 (UTC)Reply[reply]
User-select has a whole let of edge cases however. So when you drag to select, you probably cannot copy the edit section indeed, because according to the spec those items are not selectable if the selection was "started" before those items. Select all, similarly has conditions determining if such user-select none items are copied or not. But with a triple click paragraph select, I suspect there is no 'start point' of the selection and no specific behaviour has been defined and/or implemented to enable the hiding of the content.
The reason for these additional rules is that they wanted to protect consumers from websites that attempt to make the whole page non-copyable, as well as websites that try to manipulate the content of your pasteboard (consider someone using select none, to turn a inconspicuous command line example into a command that does something dangerous when pasted and execute..) —TheDJ (talkcontribs) 12:45, 17 August 2022 (UTC)Reply[reply]
Ah, this is all starting to make more sense now. If I examine the HTML (i.e. "Elements" pane in Chrome), the edit link is:
<a href="https://en.wikipedia.org/w/index.php?title=Charles_Bathgate_Beck&veaction=edit&section=1" class="mw-editsection-visualeditor" title="Edit section: References">edit</a>
Chrome says the computed style for the anchor tag includes user-select: none, inherited from mw-editsection. So, it doesn't look like anything is overriding it per-se as Nardog suggests. On the other hand, the MDN page on user-select says, "WebKit ... violates the behavior described in the spec", which does seem to be what's happening here. -- RoySmith (talk) 13:22, 17 August 2022 (UTC)Reply[reply]
Screen Shot showing incorrect text highlighting in Chrome.png
PS @TheDJ regarding your edge cases, if I go to Charles Bathgate Beck and drag-select over both the page title and the "An unassessed article..." line below it, the edit links don't show as selected. But when I copy-paste that, they're included in the pasted text. -- RoySmith (talk) 13:30, 17 August 2022 (UTC)Reply[reply]

Preferences history?[edit]

This is prompted by the above #Copy-paste article title also gets edit links thread, but I'm breaking it out as a new section because it's a different question. Is there anyway to see your history of what preferences you've enabled/disabled and roll back to a previous state? Testing which user scripts might be doing something is fairly easy because each change to my common.js is logged and it's trivial to just roll back to the original state. When I'm playing the "which preference caused this?" game, not so much. I end up just keeping manual notes of what I'm turning off, but that's a pain and error-prone.

Also, is there any way to map from the user-visible strings ("Add an [edit] link for the lead section of a page") back to the associated gadget (MediaWiki:Gadget-edittop.js)?

And since I'm in whining and complaining mode, it would also be nice if scripts could be made to confess what they've done by adding a comment to the HTML they produce. That way, I could look at the HTML in a browser developer window and instantly see, "Oh, that link was added by Foo.js". As opposed to rummaging through different preferences pages (plus my common.js) trying to guess which it might be. -- RoySmith (talk) 15:47, 16 August 2022 (UTC)Reply[reply]

For the last part, depending on what is being added a script could add an additional class to it. — xaosflux Talk 15:52, 16 August 2022 (UTC)Reply[reply]
  • Is there anyway to see your history of what preferences you've enabled/disabled and roll back to a previous state? No.
  • Also, is there any way to map from the user-visible strings ("Add an [edit] link for the lead section of a page") back to the associated gadget (MediaWiki:Gadget-edittop.js)? I have previously suggested that every gadget description should have a link to its documentation or script page. Int admins (including me) are apparently lazy on the point. I will accept edit requests though if you'd like to work through the list of gadgets. :)
Last per Xaos. That seems like a per-script thing you can request. Izno (talk) 16:01, 16 August 2022 (UTC)Reply[reply]
is there any way to map from the user-visible strings ... back to the associated gadget - perhaps the easiest way is to go to Special:Gadgets which shows the descriptive text for each gadget, together with links to the JavaScript and CSS pages that the gadget primarily uses. --Redrose64 🌹 (talk) 21:39, 16 August 2022 (UTC)Reply[reply]
While it's not history, you might appreciate that there's a link on Special:Preferences to download "My account data from this project", and it includes your current preferences. You could treat it as a backup copy. Now someone just needs to write a gadget to restore it ;) Matma Rex talk 02:09, 19 August 2022 (UTC)Reply[reply]

Unhiding Hidden Errors in References via the CSS Question[edit]

The help for this error says that I can ask questions about Cascaded Style Sheets here, rather than at the Help Desk. If I should go to the Help Desk, then I will. I am trying to edit an article that is extensively referenced. On a Preview of my edit, I get the message that:

Script warning: One or more {{cite book}} templates have maintenance messages; messages may be hidden (help). I viewed Help:CS1 errors and tried to do what it said.

So I went to User:Robert McClenon/common.css, or rather, to the empty subpage that might have been there. I put in the content that the Help said, beginning with .mw-parser-output and tried to Preview the output. It says that there is a warning because Warning: Element (span.cs1-hidden-error) is overqualified, just use .cs1-hidden-error without element name.

What is overqualified? What should I do?

Robert McClenon (talk) 11:01, 17 August 2022 (UTC)Reply[reply]

@Robert McClenon: You can safely ignore the warning.
It is a linter warning meant to assist in writing stylistically good (in the opinion of the people who programmed the linter) CSS, but it will work just fine despite the warning, and is not something you need to concern yourself with.
"Overqualified" in this context means that (if your coding style is the same as the linter's author's) it should be specific enough to use .cs1-hidden-error, which means "find any element that has the class cs1-hidden-error", instead of span.cs1-hidden-error, which means "find any element of type span that has the class cs1-hidden-error. Rummskartoffel 12:38, 17 August 2022 (UTC)Reply[reply]
The code at Help:CS1 errors#Error and maintenance messages is:
.mw-parser-output span.cs1-hidden-error {display: inline;} /* display hidden Citation Style 1 error messages */
The higher specificity with span is actually necessary here to override this in Module:Citation/CS1/styles.css:
.cs1-hidden-error {
	display: none;
	color: #d33;
}
For example, consider 3D pose estimation#cite note-7 (permanent link). The last reference has a hidden error message: {{cite journal}}: Cite journal requires |journal= (help). It is only displayed if span is included in the code. @Robert McClenon: In User:Robert McClenon/common.css you changed span. to span- and omitted what to do: {display: inline;}. As Rummskartoffel said, you can safely ignore the warning you get with the correct code. PrimeHunter (talk) 01:40, 18 August 2022 (UTC)Reply[reply]

mbox is now TemplateStyled only[edit]

Please report any issues you see at MediaWiki talk:Common.css#mbox is now TemplateStyled only. Thanks! Izno (talk) 17:50, 17 August 2022 (UTC)Reply[reply]

Congrats! 🥳 Jon (WMF) (talk) 21:23, 18 August 2022 (UTC)Reply[reply]

FizzBuzz doesn't work[edit]

I've tried to write a FizzBuzz program in wikimarkup (no particular reason). Obviously, this isn't a serious project, but if anyone can see a.problem in my (incredibly messy) wikicode, it's at User:Qwerfjkl/sandbox/27. ― Qwerfjkltalk 20:12, 17 August 2022 (UTC)Reply[reply]

Here's a cleaner and working version using Template:For nowiki:
{{for nowiki|<br />|<nowiki>{{#ifeq:{{mod|{{{1}}}|3}}|0|Fizz|{{#ifeq:{{mod|{{{1}}}|5}}|0|Buzz|{{{1}}}}}}}</nowiki>|count=100}}
Your original {{for loop}} based code doesn't work because, first, you have too many levels of escaping of curly braces and pipes, and second, by the time {{replace}} gets called, the templates in its argument have already been evaluated so it's already done the calculation based on the literal string "%1" * Pppery * it has begun... 20:56, 17 August 2022 (UTC)Reply[reply]
PpperyJust curious, how would you change this so that the fizz rule is "divisible by 3 or has a 3 in it" and the buzz rule is "divisible by 5 or has a five in it" (with fizz still being checked for first).Naraht (talk) 21:22, 17 August 2022 (UTC)Reply[reply]
{{for nowiki|<br />|<nowiki>{{#if:{{#ifeq:{{mod|{{{1}}}|3}}|0|x}}{{#ifeq:{{#invoke:String|find|{{{1}}}|3}}|0||x}}|Fizz|{{#if:{{#ifeq:{{mod|{{{1}}}|5}}|0|x}}{{#ifeq:{{#invoke:String|find|{{{1}}}|5}}|0||x}}|Buzz|{{{1}}}}}}}</nowiki>|count=100}}
. This gets really ugly really fast. * Pppery * it has begun... 21:29, 17 August 2022 (UTC)Reply[reply]
Using a Scribunto module seems like it should be considered a loss. (At that point what's stopping you from coding it entirely in Lua?) Nardog (talk) 22:07, 17 August 2022 (UTC)Reply[reply]
It's a reasonable programming challenge (which is what this is, presumably), to treat the existing set of modules as the baseline of an esoteric programming language and build up from that. That baseline is no less arbitrary than the no-Lua baseline of whatever functions the developers saw fit to install in PHP, unless you are saying we should regress all the way to {{qif}}.
Note that all versions, even the original in Qwerfjkl's sandbox, use Lua somewhere, although Qwerfjkl's version and my first version hide it behind template wrappers, which I could have done in my second version if I saw fit to.
{{for nowiki|<br />|<nowiki>{{#if:{{#ifeq:{{mod|{{{1}}}|3}}|0|x}}{{#ifeq:{{strfind short|{{{1}}}|3}}|0||x}}|Fizz|{{#if:{{#ifeq:{{mod|{{{1}}}|5}}|0|x}}{{#ifeq:{{strfind short|{{{1}}}|5}}|0||x}}|Buzz|{{{1}}}}}}}</nowiki>|count=100}}
. * Pppery * it has begun... 23:04, 17 August 2022 (UTC)Reply[reply]
@Pppery, thanks, I had no idea {{For nowiki}} existed. ― Qwerfjkltalk 06:28, 18 August 2022 (UTC)Reply[reply]
...but it needs to be {{for nowiki|<br />|<nowiki>{{If then show|{{#ifeq:{{mod|{{{1}}}|3}}|0|Fizz|}}{{#ifeq:{{mod|{{{1}}}|5}}|0|Buzz|}}|{{{1}}}}}</nowiki>|count=100}} to output FizzBuzz when divisible by 15. ― Qwerfjkltalk 06:33, 18 August 2022 (UTC)Reply[reply]
Kindly, what is the point of this? If this were a real world case, you would be told to use Lua and to move on. This board is not for self-exploration unless it has the purpose of improving Wikipedia.
Please move on. Izno (talk) 06:59, 18 August 2022 (UTC)Reply[reply]
I dunno how you template gurus do it. Whenever I see code that looks like this, I always get a very strong itch to rewrite it in lua. –Novem Linguae (talk) 21:56, 18 August 2022 (UTC)Reply[reply]

Regarding upcoming talk page improvements[edit]

I realise that the upcoming talk page is live on some wikis (example: bn:আলাপ:ভারত). Currently, it is only in Article talk pages, but all other talk and pseudo-talk pages retain old design. I like everything about new talk page except that the new level 2 headings (default) appears like level 3 & below headings separated from each other using ---- (4 hyphens), which I don't appreciate. Where should I report this? Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:06, 18 August 2022 (UTC)Reply[reply]

mediawikiwiki:Talk:Talk pages project/Usability is probably the right place, but it's less focused on appearance than it is on usability. Izno (talk) 07:25, 18 August 2022 (UTC)Reply[reply]
Thanks! CX Zoom[he/him] (let's talk • {CX}) 09:16, 18 August 2022 (UTC)Reply[reply]

Deactivating certain global scripts per local project[edit]

Hello!

Is there a way to have some globally activated user scripts (Meta - global.js) not affect certain local projects (exclude them)? - Klein Muçi (talk) 09:04, 18 August 2022 (UTC)Reply[reply]

if (mw.config.get('wgDBname') !== 'enwiki') {
    mw.loader.load('Script1');
    mw.loader.load('Script2');
    And any other usual js stuff
    // + Any message you wish to keep
}
Change enwiki to the wiki you want to disable scripts. You can see a working example at my global.js (from line 55 until end) but it's a mess tbh. CX Zoom[he/him] (let's talk • {CX}) 09:15, 18 August 2022 (UTC)Reply[reply]
@CX Zoom, thanks a lot! Exactly what I wanted. And thank you for the detailed example! :) - Klein Muçi (talk) 10:17, 18 August 2022 (UTC)Reply[reply]

Template font size[edit]

{{Who's Who}} generates reduced size font. There are over 2,000 transclusions and the majority seem to be uses within the references section, where the font is already 90%, so the further reduction violates MOS:SMALL (e.g Maggie O'Farrell ref #8). What's the best way to resolve this? There could be a template parameter to specify font reduction when the template is used in normal-size text (if there are any, someone would have to find those and edit them). Is there a better way? MB 17:45, 18 August 2022 (UTC)Reply[reply]

MB, a similar issue is present in template {{Cite OED}}, used for example in ref #10 in Alchemy#References. The problem comes from Template:Link note, which has hardcoded CSS font-size:0.95em; font-size:90%;. I think the best solution is just to remove this bit of the CSS – output of {{Link note}} is already A) wrapped in parentheses and B) also has CSS color:#555 (which some people don't like either). —⁠andrybak (talk) 17:57, 18 August 2022 (UTC)Reply[reply]
It looks like there are 34k more from {{subscription required}} that would also be fixed. MB 18:05, 18 August 2022 (UTC)Reply[reply]
95% (Link note) times 90% (references) is sufficiently sized for MOS:SMALL (>85%). There is a way that this could depend on where the text appears (TemplateStyles).
That said, our MOS:SMALL probably needs to be adjusted to point out the absolute minimum in pixels/pts, as text sizes on Wikipedia have generally increased with each new skin. There is also CSS min() which is newer but could be used later in the future (or double declared even today e.g. font-size: 95%; font-size: clamp(14px, 85%, 1em); or some such). Izno (talk) 18:35, 18 August 2022 (UTC)Reply[reply]
I think using a percentage as guidance is still preferable, under the assumption that readers will use their browser zoom capability to set the base font size to a comfortable size for them. (I know this is not universally true, but it's a reasonable default assumption, as teaching someone how to use their browser zoom feature will enable them to set their desired font size on Wikipedia and other sites.) isaacl (talk) 21:44, 18 August 2022 (UTC)Reply[reply]
Pixels being an example of "the minimum font size is actually X size, and we should not let anything go lower than that, percentages or otherwise". Our 85% rule is based on computing what the minimum font size was in Monobook, but Vector, new Vector, and Timeless all have larger font sizes, so it stands to reason that we can use smaller fonts and that really, it should be defined by the absolute minimum. Pixel-based sizes still respond to zoom anyway. Izno (talk) 22:06, 18 August 2022 (UTC)Reply[reply]
Yes, precisely because pixel-based sizes zoom, I think a percentage is still preferable. A user will use the zoom function to adjust the base font to a comfortable size, no matter what pixel size the skin has set. Thus specifying a reasonable minimum size as a percentage of the base font size will automatically scale to the user's preference. isaacl (talk) 22:14, 18 August 2022 (UTC)Reply[reply]
Then I don't see what issue you have with font-size: clamp(14px, 85%, 1em);. And anyway, that was illustrative. Izno (talk) 22:45, 18 August 2022 (UTC)Reply[reply]
I apologize for not being clear. I wasn't referring to your code sample, but your statement our MOS:SMALL probably needs to be adjusted to point out the absolute minimum in pixels/pts. isaacl (talk) 23:01, 18 August 2022 (UTC)Reply[reply]

Page previews displaying vandal images long after vandal edits were reverted[edit]

Some time ago today, the article Kharijites, today's featured article, was vandalised with vulgar images edited over the entire lead section. This resulted in this image (warning: graphic) becoming the page preview image for over an hour now. I'm fairly confident this is some server-side issue, as I've cleared my cache, and purged the article, the image, and the main page, and yet still the explicit image from the vandal attack is still showing up in the page preview on the main page of the site. I find it completely unacceptable that such a quick vandal edit could have such long-lasting effects. Is there anything that can be done about this on the technical side of things? Hecseur (talk) 19:22, 18 August 2022 (UTC)Reply[reply]

I don't see the graphic image. I hadn't attempted the preview until seeing this thread. Killiondude (talk) 19:25, 18 August 2022 (UTC)Reply[reply]
I carried out a dummy edit on the article, which seems to have sorted it out. Or maybe it was the recreation of a transcluded page without the images in question. *shrugs* Sdrqaz (talk) 19:31, 18 August 2022 (UTC)Reply[reply]
Traditionally a Null edit is required in these circumstances. -- zzuuzz (talk) 19:34, 18 August 2022 (UTC)Reply[reply]
I did do one before trying a dummy edit, but it didn't seem to have the desired effect. Sdrqaz (talk) 19:37, 18 August 2022 (UTC)Reply[reply]
I am still seeing the image on mobile preview and header after accessing the article in the app yesterday, so more work may be needed to force clearing the cache on mobile. I'm unfamiliar with editing so not sure how to do it, but read this
How can I purge a bad image?
The pageimage only changes when a link in an article changes. For emergencies, please add/remove links from the page, reverting if necessary. Purging will not work. For larger emergencies please file a Phabricator ticket. MelitaJay (talk) 17:30, 19 August 2022 (UTC)Reply[reply]
I removed a link from the page and reverted it. This has solved the problem. MelitaJay (talk) 17:37, 19 August 2022 (UTC)Reply[reply]

Page tab problems[edit]

Is anyone else having issues with their tool tabs - when I open my page tool tab, the bolded options no longer provide drill down options when I hover over them. It would be good to know if this is an issue that has just cropped up or a known long-term problem related to script incompatibilites or some other issue. Iskandar323 (talk) 19:46, 18 August 2022 (UTC)Reply[reply]

I've made a hotfix for MoreMenu, which I believe is what you're referring to. phab:T315418 is in fact what caused this. For those using Vector legacy + MoreMenu, you should soon see MoreMenu behaving normally, but the native "More" menu will still require a click to expand. MusikAnimal talk 20:27, 18 August 2022 (UTC)Reply[reply]
@MusikAnimal: Great! Yep. That was the one, and it seems to be working again now. Thanks. Iskandar323 (talk) 06:03, 19 August 2022 (UTC)Reply[reply]

WP:Contents issue[edit]

I am in the process of redesigning the WP:Contents page. At the bottom of the page, where it says content listings, there is a vertical line that I can't seem to get rid of. I tried editing the page a lot to see if I can get it, but to no avail. I'm hoping to get some help regarding how I can fix this. Interstellarity (talk) 21:41, 18 August 2022 (UTC)Reply[reply]

it looks like this line is a border added by the intro to single template. adding "|noborder=y" (after "|padbottom=20px", for example) should resolve your issue. dying (talk) 22:11, 18 August 2022 (UTC)Reply[reply]
@Dying: Thank you, that resolves the issue. I would also like to get rid of the whitespace between Category:Contemporary history by country and the Content listings. What can I do to fix that? Interstellarity (talk) 22:18, 18 August 2022 (UTC)Reply[reply]
i think that is just the space that the template inserts after what is defined as the lead, and before what is defined as the top. right now, the top is not defined, but most of the text is in the lead, so the space appears between the lead and the bottom. the space can be shifted up by adding "| top =" somewhere (on the line above "== Vital articles ==", for example). dying (talk) 22:40, 18 August 2022 (UTC)Reply[reply]

#Anchors in links appear to be broken on all wikis, all skins[edit]

Looks like this could be a big bug that eventually gets questions here. Creating this section to help centralize discussion. Phab ticket created. –Novem Linguae (talk) 21:59, 18 August 2022 (UTC)Reply[reply]

Fixed. –Novem Linguae (talk) 23:21, 18 August 2022 (UTC)Reply[reply]
I saw your edit on my watchlist and ironically, the section link in the edit summary didn't work. Same in the page history and Special:Contributions/Novem Linguae. It apparently happens because the section name starts with #. The automatic edit summary link goes to Wikipedia:Village pump (technical)#Anchors in links appear to be broken on all wikis, all skins instead of Wikipedia:Village pump (technical)##Anchors in links appear to be broken on all wikis, all skins with double ##. I don't know whether it's an old bug or related to the current issue. PrimeHunter (talk) 00:45, 19 August 2022 (UTC)Reply[reply]
Good catch. I created a ticket. phab:T315631. –Novem Linguae (talk) 01:47, 19 August 2022 (UTC)Reply[reply]

Running js via url[edit]

I remember seeing that a certain string when appended to a page url can run javascript on a one-time basis. I don't recall that. Can someone please help? Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:35, 19 August 2022 (UTC)Reply[reply]

You are looking for ?withJS=MediaWiki:Pagename.js or ?widthgadget=gadgetnameTheDJ (talkcontribs) 08:42, 19 August 2022 (UTC)Reply[reply]
That second one, of course, should be ?withgadget. The ?withJS only works for scripts in the MediaWiki namespace. For other scripts, see a similar question I answered about how to use the DYKcheck tool without installing it: Wikipedia talk:Did you know/Archive 186#Wikipedia:Did you know/DYKcheck. The same method could be used to run other scripts. It's not exactly what you asked for, but it may do what you need.  MANdARAXXAЯAbИAM  17:14, 19 August 2022 (UTC)Reply[reply]
(edit conflict) It's withgadget and it only allows gadgets with supportsUrlLoad at MediaWiki:Gadgets-definition, e.g. https://wiki.alquds.edu/?query=Example?withgadget=UTCLiveClock. withJS can load any js page in the Mediawiki namespace, e.g. https://wiki.alquds.edu/?query=Example?withJS=MediaWiki:Gadget-UTCLiveClock.js. There is a similar withCSS. withgadget is part of MediaWiki since December 2021. withJS and withCSS rely on code in MediaWiki:Common.js. There is also a version in mw:Snippets/Load JS and CSS by URL. PrimeHunter (talk) 17:16, 19 August 2022 (UTC)Reply[reply]

dashes script malfunction[edit]

Of late, the dashes script and various mirrors have stopped performing, and the button that calls the script in the dropdown menu (More tab) has been replaced by auto ed. At the same time, the script functionality has also disappeared. However, none of the core AutoEd modules seems to have changed. What could be causing this issue?  Ohc revolution of our times 09:47, 19 August 2022 (UTC)Reply[reply]

The importScript call at line 150 is (I know not why) no longer returning a truthy value, so various things are not being set. I created a version of the script without that condition at User:William Avery/dashes.js, and it seems to work on my sandbox. William Avery (talk) 12:40, 19 August 2022 (UTC)Reply[reply]

Table not updating[edit]

Wikipedia:List of administrators/stat table - Wikipedia Wakelamp d[@-@]b (talk) 10:27, 19 August 2022 (UTC)Reply[reply]

@Wakelamp: Wikipedia:List of administrators/stat table is not automatic, or bot updated. You can updated it by editing. I've templated it as out of date. — xaosflux Talk 12:45, 19 August 2022 (UTC)Reply[reply]

Is there an update to Vector-2022 today/yesterday?[edit]

Not sure if there is an update to Vector-2022 on 18 August 2022 and/or 19 August 2022, as Xtools and Shortdesc helper are suddenly no longer functional despite both already enabled in gadgets. Both gadgets were working fine on 17 August 2022 and before. Paper9oll (🔔📝) 12:40, 19 August 2022 (UTC)Reply[reply]

Paper9oll, I fixed XTools Article Info gadget on bnwiki in my own way. Yahya (talkcontribs.) 14:50, 19 August 2022 (UTC)Reply[reply]
@Yahya Haven't tried your script, but this isn't really a permanent solution. But any idea, if it's due to an update to Vector-2022 that rolled out probably in past 2 days, that causes both tools to suddenly stopped functioning in Vector-2022? Not sure, if the update removed or renamed some css classes that causes both tools to no longer function/display. Paper9oll (🔔📝) 16:35, 19 August 2022 (UTC)Reply[reply]
The XTools gadget has now been fixed, both here on enwiki as well as the global script. Ironically, I was asked how the gadget worked so that the team would not break it, but it looks like that inquiry was for a different project (DiscussionTools), and unrelated to the change in Vector 2022. MusikAnimal talk 19:41, 19 August 2022 (UTC)Reply[reply]

Multiple Table options when editing slowing down pages[edit]

Is anyone else getting the Tables options appearing just above the edit box multiple times when editing? I've got rows and rows of this, but only in the last 24 hours or so. It's really slowing down the page loading, practically making editing impossible, with the page crashing on some browsers. Iveagh Gardens (talk) 14:38, 19 August 2022 (UTC)Reply[reply]

@Iveagh Gardens: I suddenly had that problem today, and tracked it down to my common.js being imported into itself. Fixed by this edit: https://en.wikipedia.org/w/index.php?title=User:William_Avery/common.js&diff=prev&oldid=1105258013 I have no idea 1/ how that happened, 2/ why it didn't cause a problem before, or 3/ why the behaviour changed. You too seem to have that problem in https://wiki.alquds.edu/?query=User:Iveagh_Gardens/common.js William Avery (talk) 15:06, 19 August 2022 (UTC)Reply[reply]
@Iveagh Gardens You need to undo this edit: Special:Diff/1030376399. --Ahecht (TALK
PAGE
) 18:51, 19 August 2022 (UTC)Reply[reply]

History split[edit]

Could an admin move/remove the oldest two revisions of https://en.wikipedia.org/w/index.php?title=Honor_walk&action=history? This was someone's sandbox, and two revisions for an unrelated article seem to have been moved along with the history for the current page. Thanks, WhatamIdoing (talk) 18:29, 19 August 2022 (UTC)Reply[reply]

Doing...xaosflux Talk 18:38, 19 August 2022 (UTC)Reply[reply]
 Done split to User:Drewmutt/sandbox/Baby cage. — xaosflux Talk 18:45, 19 August 2022 (UTC)Reply[reply]