Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. 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.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Expanding class=wikitable to make tables accessible to blind, and to align cell text

Tracked in Phabricator
Task T2418

Expanding what class=wikitable does could instantly solve a lot of problems the blind and visually impaired have with hundreds of thousands of tables on Wikipedia. And it would align row header cell text to the left. For more info see: User:Timeshifter/Sandbox114 and 115. See related discussion. (later note: link to archive: Wikipedia:Village pump (technical)/Archive 183#class="wikitable aligned linked" for linked country lists with flags).

Standard class=wikitable table below. It includes style=text-align:right; overall, and align=left on first-column cells.

Correctional supervision rates by state, 2016.

Jurisdiction	Total		Community supervision		Incarcerated
	Total, 12/31/2016	Rate per 100,000 adults	Probation or Parole, 12/31/2016	Rate per 100,000 adults	In prison or jail, 12/31/2016	Rate per 100,000 adults
Alabama	99,800	2,640	60,700	1,610	40,900	1,080
Alaska	12,900	2,320	8,400	1,520	4,400	800
Arizona	137,500	2,570	84,800	1,590	55,000	1,030

The blind need scopes on all header cells. Added row headers, scope=row, scope=rowgroup, scope=col, scope=colgroup, class=plainrowheaders:

Correctional supervision rates by state, 2016.

Jurisdiction	Total		Community supervision		Incarcerated
	Total, 12/31/2016	Rate per 100,000 adults	Probation or Parole, 12/31/2016	Rate per 100,000 adults	In prison or jail, 12/31/2016	Rate per 100,000 adults
Alabama	99,800	2,640	60,700	1,610	40,900	1,080
Alaska	12,900	2,320	8,400	1,520	4,400	800
Arizona	137,500	2,570	84,800	1,590	55,000	1,030

Same as above. Added style=background-color:yellow; and style=background-color:lightyellow; - I made one cell light yellow to show a couple shades of yellow.

Correctional supervision rates by state, 2016.

Jurisdiction	Total		Community supervision		Incarcerated
	Total, 12/31/2016	Rate per 100,000 adults	Probation or Parole, 12/31/2016	Rate per 100,000 adults	In prison or jail, 12/31/2016	Rate per 100,000 adults
Alabama	99,800	2,640	60,700	1,610	40,900	1,080
Alaska	12,900	2,320	8,400	1,520	4,400	800
Arizona	137,500	2,570	84,800	1,590	55,000	1,030

class=wikitable - It could be expanded to add scopes to all header cells, including those spanning columns and rows (colspan and rowspan). And it could align row header text to the left as does class=plainrowheaders. The scopes would allow users of screen readers (the blind) to understand nearly all tables on Wikipedia, since nearly all use class=wikitable.

class=wikitable could also add a yellow or light yellow background to headers. That would solve Aréat's problem with dark grey as a header background due to his visual impairment. It would help all readers. Highlighter felt-tip markers usually come in some shade of yellow. That is because this background color behind black text is one of the most legible color combinations.

class=plainrowheaders does not use bolded text in row headers. Many people do not like default bolded row headers. Especially in wide country lists, and other tables, where the width matters due to long country names, etc.. Also, people sometimes prefer to bold selected words or phrases in row headers.

---

Wikitext below is for the above yellow table if class=wikitable did scopes, color, and plain row headers. It's much simpler to edit by the average editor. Compressed horizontal format is more intuitive without all the inline CSS, etc..

{|class="wikitable sortable mw-datatable" style=text-align:right;
|+ Correctional supervision rates by state, 2016.
|- 
! rowspan=2 |<br><br><br><br>Jurisdiction
! colspan=2 |Total 
! colspan=2 |Community supervision 
! colspan=2 |Incarcerated
|-
! Total,<br>12/31/2016 
! Rate per<br>100,000<br>adults 
! Probation<br>or Parole,<br>12/31/2016 
! Rate per<br>100,000<br>adults 
! In prison<br>or jail,<br>12/31/2016 
! Rate per<br>100,000<br>adults
|-
! {{flaglist|Alabama}} 
|| 99,800 || 2,640 || 60,700 || 1,610 || 40,900 || 1,080
|-
! {{flaglist|Alaska}} 
|| 12,900 || 2,320 || 8,400 || 1,520 || 4,400 || 800
|-
! {{flaglist|Arizona}} 
|| 137,500 || 2,570 || 84,800 || 1,590 || 55,000 || 1,030
|}

Wikitext below is the actual wikitext for the above yellow table, and includes all the inline CSS, etc.:

{|class="wikitable sortable mw-datatable plainrowheaders" style=text-align:right;
|+ Correctional supervision rates by state, 2016.
|- 
! scope=rowgroup rowspan=2 style=background-color:lightyellow; |<br><br><br><br>Jurisdiction
! scope=colgroup colspan=2 style=background-color:yellow; |Total 
! scope=colgroup colspan=2 style=background-color:yellow; |Community supervision 
! scope=colgroup colspan=2 style=background-color:yellow; |Incarcerated
|-
! scope=col style=background-color:yellow; |Total,<br>12/31/2016 
! scope=col style=background-color:yellow; |Rate per<br>100,000<br>adults 
! scope=col style=background-color:yellow; |Probation<br>or Parole,<br>12/31/2016 
! scope=col style=background-color:yellow; |Rate per<br>100,000<br>adults 
! scope=col style=background-color:yellow; |In prison<br>or jail,<br>12/31/2016 
! scope=col style=background-color:yellow; |Rate per<br>100,000<br>adults
|-
! scope=row style=background-color:yellow; |{{flaglist|Alabama}} 
|| 99,800 || 2,640 || 60,700 || 1,610 || 40,900 || 1,080
|-
! scope=row style=background-color:yellow; |{{flaglist|Alaska}} 
|| 12,900 || 2,320 || 8,400 || 1,520 || 4,400 || 800
|-
! scope=row style=background-color:yellow; |{{flaglist|Arizona}} 
|| 137,500 || 2,570 || 84,800 || 1,590 || 55,000 || 1,030
|}

--Timeshifter (talk) 19:13, 18 August 2020 (UTC)

Timeshifter, sorry, but i'm just really confused.. There is so much text and so much back and forth that went on, that i'm simply unsure what we are trying to achieve here... I think the idea is 'less inline styles'. Which I agree with. It seems you think you have solutions for multiple problems. It would benefit everyone to treat each problem separately to make sure that we have considered all upsides and downsides of any proposed solutions. But I think we can all agree that there is not a chance that we will ever see yellow headers as a default.

But lets start here:

1. The blind need scopes on all header cells that is simply not true. While good advice in general, all screenreaders I have worked with simply make their own header direction analysis for tables (because no one other than Wikipedia uses the scope attribute) or even completely ignore the direction of headers. So in practice it isn't really a thing. There is a difference between being a 'need' and an 'improvement/net benefit'.They can also be very useful for styling.
2. class=wikitable - It could be expanded to add scopes to all header cells I guess.. theoretically. By making the parser aware of wikitable class (it is only styling so far, not behaviour) and to dynamically analyse the generated HTML of the table and add scope attributes in a DOM post processing filter ? Is that what you are proposing ?
3. class=wikitable could also add a yellow or light yellow background to headers. not gonna happen. We cannot adopt to every single persons impairment (i don't know where and when Areat stated his impairment, that would have helped). Primarily because adaptations for impairments can actually clash with the impairment of others (especially with colorblindness this is a problem). There is a balance to be struck. If someone is so much impaired that even while passing WCAG contrast levels, they still have a problem, then we can think about slightly readjusting the hue or contrast, but yellow backgrounds are way out there. Browsers have zoom levels, ppl can use high contrast mode of their OS and/or browser, install custom stylesheets in their user profile or even with stylish in their browser
4. class=plainrowheaders does not use bolded text in row headers. I'm not sure what the proposal here is. You want to make plainrowheaders the default for row headers with scope=row/rowgroup ? Have we checked which tables depend on this behavior currently (like tables without column headers ?)
5. You are also mixing wikitable and mw-datatable I noticed.. not sure what you want there.

I hope I am making sense. —TheDJ (talk • contribs) 10:01, 19 August 2020 (UTC)

TheDJ, Thanks for replying. Are you visually impaired? You wrote that you use a screen reader. I would like to run some sandbox tests with you concerning tables with and without scope=rowgroup and scope=colgroup.

1. no one other than Wikipedia uses the scope attribute. Apparently, WCAG no longer requires using scopes on simple tables. It is unclear to me if a simple table includes tables with rowspan and colspan. If rowspan and colspan are still a problem for the blind, then maybe class=wikitable could add scope=rowgroup whenever it sees rowspan, and scope=colgroup whenever it sees colspan. I would think that would be fairly simple.
2. class=plainrowheaders does not work without scope=row. So if scope=row is not needed for simple tables, then there is also no need for class=plainrowheaders in class=wikitable.
3. class=mw-datatable is just in the table by habit of mine. It does not need to be in class=wikitable, though it would be nice because it is really useful for helping people follow a line across a table. Now that I think about it more, that is also something that helps the visually impaired even more. So maybe it should be in class=wikitable.
4. Browsers have zoom levels, ppl can use high contrast mode of their OS and/or browser. I don't think the visually impaired should have to adjust those levels constantly depending on whether a Wikipedia table has a column with a darker gray background or not. That is Aréat's problem, I believe, from reading his user talk page. Hopefully, he will explain it further here. A light yellow background is a lot better for everybody. Wikipedia has a mix of tables with and without rowheader columns (with the darker gray background). Right now I have my brightness turned down due to getting up from sleeping. That makes the background of the whole page light gray. In this case the additional gray darkening in header columns is a problem even for me. And I am not visually impaired other than needing glasses. But when I look at the above tables I have no problem with the header cells with a yellow background.
5. From what I read the colorblind would see light yellow as light pink. So for them they still see some header cell background shading. Also, yellow colorblindness is much less common than for other colors. See color blindness and this page. So I support a light yellow background for header cells. A light pastel yellow color versus a strong yellow color.
6. style=text-align:left; should be the default on rowheader columns. That is what most tables need. The relatively few tables that don't want it can add style=text-align:center; or style=text-align:right; to each rowheader cell. By the way I discovered that align=left does not work on rowheader cells on Wikipedia. It only works on data cells.
7. I think the idea is 'less inline styles'. Which I agree with. All of the above, other than light yellow backgrounds, would remove some clutter from table wikitext, and make table editing easier even for newbies.

Here are some relevant excerpts from Aréat's talk page. From looking at his user page I think Aréat may be a native speaker of French. So that may explain the confusion with some of his messages there and elsewhere. From Aréat's talk page:

I've read it, and seen nothing indicating the left column must be centered, bolded on dark grey background. It make it less easier to read in the first place. This is absurd. ... Look at the table you're proposing and honestly tell me it's easier to read a text that is black on dark grey? This [MOS] is obviously wrote by people who don't use it. You can't make it less easier to read on a whim. ... I have a very poor vision and I reverted the changes you made to a table that made it way more difficult to read, and that isn't used anywhere on the election pages I've been participating on for years, where the tables have been fine to read. I reverted the pages to the version they were before you went there, imposed your changes and kept reverting despite being asked to go to the talk page.

I really dislike that solid gray background of the above table using class=wikitable

Below is part of that Aréat info, but with a light yellow background. Turn down the brightness to 60% and 40% to see the difference even more. I use freeware CareUEyes Lite. It changes brightness levels instantly from a clicker icon on the system tray in Windows.

Look at the table you're proposing and honestly tell me it's easier to read a text that is black on dark grey? This [MOS] is obviously wrote by people who don't use it. You can't make it less easier to read on a whim. ... I have a very poor vision

--Timeshifter (talk) 17:47, 19 August 2020 (UTC)

Timeshifter, Are you visually impaired? You wrote that you use a screen reader. no, but as a developer I have an interest in accessibility and regularly test Wikipedia and esp. new features with VoiceOver and NVDA and then slap WMF for having written inaccessible widgets again. I'll get back on the other points when I have time. —TheDJ (talk • contribs) 08:35, 20 August 2020 (UTC)

1. if a simple table includes tables with rowspan and colspan Simple tables generally have only one level of headers for columns and/or one level of headers on the rows.
2. class=plainrowheaders does not work without scope=row well.. how would you separate the simple table from the 'non simple' table though ? CSS cannot determine this based on just a TH, because the TH can be everywhere in the table....
3. "it is really useful for helping people follow a line across a table" I don't mind row highlighting, but 1, what if it is not a datatable and 2. i think we shouldn definetly change the background color of TD cells inside wikitables in that case.
4. I don't think the visually impaired should have to adjust those levels constantly 1. why would that have to be constantly ? Set it and its done 2. I do think that our responsibility on accessibility stops somewhere. I'm pretty sure I can find evidence that a page with white background and black letters with a 24pt font size might be the most readable version of a website to a large portion of the populace. But there are also people who get blinded by white and most of us actually appreciate a bit of design esthetic. Everything is a balance. Lastly I will also point out that some ppl tend to use (oft not by choice) ridiculously cheap computer equipment which might be their bigger problem. If you have a 300 euro laptop, its like wearing 15 euro plastic glasses. You are better off getting 2nd hand, older but higher quality, equipment sometimes.
5. I won't argue that it isn't a good color for accessibility reasons. I just think too many people would hate it for it to be a realistic candidate.
6. should be the default on rowheader columns I agree.. but how to accurately detect row headers when some tables are complex ? I mean, we could ADD a rule that left aligns rows headers on simple tables, but that means that on 'non-simple' tables, you would get left aligned text in the first and middle aligned in the second, and in some ways, less predicatble behavior like that is worse than having a consistently working solution with "plainrowheaders". Instead, why not just make the current plainrowheaders (with scope) the actual default ? align=left that's because it is not supported in HTML5 any longer and therefore the default styling of our headers (center aligned) gets priority over any "align" instruction.

All in all, I agree with many of your points, but I think that with the diversity of Wikipedia's often highly complex tables and the limited styling options that HTML really gives to safely support those tables in a generic instead of a case by case way, you are overestimating the effectiveness of some of those proposals. Tables on Wikipedia are HARD, much harder than anywhere else on the web I would postulate. I'm also personally in favor of toning down the default background color of both TD and TH cells down considerably for accessibility reasons, but as one of the oldest color combinations of English Wikipedia (2006ish ?), I think that would require a separate discussion, with multiple variants for the community to vote on. —TheDJ (talk • contribs) 14:37, 23 August 2020 (UTC)

1. Thanks for replying, TheDJ. I think I am asking for too much change at once of class=wikitable. This much change needs paid staff working on getting consensus. Are you paid staff? I think it may be better to do smaller changes of class-wikitable. A step at a time. Otherwise nothing may get done.
2. Thanks for the link to the WCAG page with a clearer description of what a simple table is.
3. Do your screen readers recognize headers that span multiple columns (colspan)? Do they recognize headers that span multiple rows (rowspan)?
4. About row highlighting. I don't want permanent row highlighting. I want it like class=mw-datatable does it. Only when a cursor is over the row. As for the background color of the row, I want it to be a very light pastel color. Anything but gray.
5. Left-aligning of text in the first column is necessary in most tables regardless of whether that column consists of headers or not. A table template has been created (not by me) just to be able to quickly do daily updates of COVID-19 pandemic death rates by country. In order to have the first column text left-aligned. It uses this template stylesheet. Imagine if this happens on thousands of tables.
6. I think it is much easier to add left-alignment of the first column to class=wikitable. Of course then you would need something like data-sort-type except for text alignment. For those few first columns that don't need left alignment.
7. I wonder if all the class=wikitable CSS/JS could be placed in separate CSS and JS files that are uploaded to the browser only when class=wikitable is seen by the Mediawiki software. That would lower the CSS/JS loads to the Wikipedia articles without tables.
8. Or better yet would be separate separate CSS and JS files for any Wikipedia article containing signs of any kind of table: Via the mediawiki software spotting {| or <table>.

--Timeshifter (talk) 07:15, 24 August 2020 (UTC)

Comment. TheDJ, I see from your user page that you are not paid staff, and are a volunteer like me. It looks like major changes are not going to happen. At least not right away. I would be happy if something simpler like this below would happen. But instead of forcing a sorting type for a column it would set the text alignment for a column:

• Help:Sorting#Forcing a column to have a particular data type - data-sort-type="..."

It could be added to any column header: data-align="..." Text alignment in the column could be set for left, center, or right. Related discussions:

• Wikipedia:Village pump (technical)/Archive 183#class="wikitable aligned linked" for linked country lists with flags.
• MediaWiki talk:Common.css#CSS to left align the text in the first column of a table.

An example of a table with varying needs for text alignment is the main country table in this article:

• List of countries by intentional homicide rate - the country, region, and subregion columns need their text aligned left. The rate and count columns need their data aligned right. So there are 3 text columns aligned left, and 2 data columns aligned right. Inline CSS is currently used to align every data cell to the right. That is a lot of clutter, and unnecessary work.

I guess the next logical step is to propose this at Wikimedia Phabricator. --Timeshifter (talk) 02:40, 28 August 2020 (UTC)

Timeshifter, There is phabricator T2418 which may be of interest. -- WOSlinker (talk) 06:41, 28 August 2020 (UTC)

WOSlinker, thanks! I just subscribed to that task. I will post some ideas there. Hopefully soon. --Timeshifter (talk) 07:20, 28 August 2020 (UTC)

How to save settings for code editor

Tracked in Phabricator
Task T261118

Pressing Ctrl+, on the code editor opens a configuration panel, but the settings don't get saved, and the defaults get restored when you open another page with it. Is there any way to save the settings? Nardog (talk) 01:36, 20 August 2020 (UTC)

I'm actually not sure, on normal CodeMirror installs that should do it, but I'm unsure how it's set up here. You might want to ask or report a bug for mw:Extension:CodeMirror here Ed talk! 02:03, 20 August 2020 (UTC)

In case "the code editor" doesn't mean the one that you use for editing .js pages, then please see mw:Editor and see if you can figure out which editing environment you're using in the (aging) screenshots there. Whatamidoing (WMF) (talk) 02:33, 20 August 2020 (UTC)

@Ed6767 and Whatamidoing (WMF): Yes, I'm of course talking about CodeEditor, which is based on Ace, not CodeMirror (unless one is a fork of the other). Nardog (talk) 14:15, 21 August 2020 (UTC)

Whoa! Never knew about the configuration panel. I see that it even includes a "live autocomplete" option. But it's a shame that there doesn't seem to be any way to save the preferences for later. I think a feature request needs to be filed on phab. SD0001 (talk) 03:05, 20 August 2020 (UTC)

@SD0001: This page discusses ways to configure the editor through scripts. I wonder if a script could be written to save settings in a cookie or, failing that, configure the editor directly. Nardog (talk) 14:15, 21 August 2020 (UTC)

Tried it, but I couldn't figure it out how to do it (or if it's possible). We do have an ace object in global scope, but to tweak the pre-configured editor we need the editor object which isn't available in scope. SD0001 (talk) 08:10, 22 August 2020 (UTC)

@SD0001: Thanks, I filed a request. Btw I see it supports syntax highlighting for MediaWiki as well. I wonder if it can be the default editor for all pages; I love CodeEditor and I've never been a fan of other options like the 2017 editor or WikiEd... Nardog (talk) 12:41, 24 August 2020 (UTC)

Query about the look and feel of fr-wiki

Preview fr.wp in Vector skin

Not sure where the best place to ask this is, but I went to French Wikipedia today and found that it looks radically different from how Wikis usually look: [1] [2]. Initially I thought I'd landed on the mobile version by mistake! I don't think I like that look at all, the text appears too narrow and I hope we never go down that route here at enwiki... Anyone know what the rationale for the change was? Cheers  — Amakuru (talk) 11:55, 21 August 2020 (UTC)

Could you post a screenshot of what you're seeing (maybe side-by-side your en view)? I see the font a bit smaller but nothing too radical. –xeno^talk 11:57, 21 August 2020 (UTC)

Wikipedia:Village pump (technical)/Archive 183#New look? Nardog (talk) 12:16, 21 August 2020 (UTC)

It looks very different to me too. The most striking difference is a lack of borders separating the article/othercontent from the sidebar, and the replacement much larger whitespace. CMD (talk) 12:26, 21 August 2020 (UTC)

The difference is best seen on a wide screen. Currently English Wikipedia fills the full width, while the French Wikipedia seems to have a fixed maximum width. It does seem to be skin dependent and associated with the planned Vector upgrade. The preferences section has a note that says legacy Vector will still be available as an option. —  Jts1882 | talk  12:39, 21 August 2020 (UTC)

Ah, that's why I don't see a change. –xeno^talk 12:41, 21 August 2020 (UTC)

The French Wikipedia is currently testing out the new desktop improvements. Sam Walton (talk) 12:44, 21 August 2020 (UTC)

(edit conflict) This is mw:Reading/Web/Desktop Improvements, discussed a bit back at WP:Village pump (technical)/Archive 183#New look?. LittlePuppers (talk) 12:47, 21 August 2020 (UTC)

• Thanks all for the replies. So it sounds like this is going to be foisted on us at some point next year, whether we vote for it or not... Has anyone confirmed that the updated format really is beneficial? It's easy to say we should just stick with the old format, but honestly I don't see the benefit of restricting the width of the readable text. Just means more scrolling, and the layout of the other links looks more messy too. Comparing to other "modern" websites is misleading, because on most websites there isn't the same volume of text that you find here, and comparing to the mobile view is a very poor idea as the mobile view is already crap. I don't even use it on my mobile. 😏  — Amakuru (talk) 18:46, 21 August 2020 (UTC)

  Don't worry too much, there have already been several suggestions for a user script to fix the limited width. The smaller logo is good, but the option to hide the sidebar menu is just plain silly. I hope that there will be further changes yet... — GhostInTheMachine ^{talk to me} 18:58, 21 August 2020 (UTC)

  You don't need a script, a few CSS rules are sufficient. I provided one at Wikipedia:Village pump (technical)/Archive 183#New look?, but it's not enough on its own. You need all of these:

  .skin-vector-max-width .mw-page-container {
    min-width: none;
    max-width: none;
    padding: 0;
  }
  .skin-vector-max-width .mw-workspace-container {
    max-width: none;
  }
  .skin-vector-max-width .mw-content-container {
    max-width: none;
  }
  

  As mentioned before, to alter the widths for French Wikipedia only, these rules go in fr:Special:MyPage/vector.css (if you have one) or in fr:Special:MyPage/common.css (if you don't); or to alter for all WMF sites, put them in m:Special:MyPage/global.css. --Redrose64 🌹 (talk) 08:48, 22 August 2020 (UTC)

• Has anybody realised that the reason that many websites have a broad white margin is so that there is space available for advertising and clickbait? --Redrose64 🌹 (talk) 22:36, 21 August 2020 (UTC)

  There are optimal lengths of lines of text, see Line length. Thanks. Mike Peel (talk) 22:48, 21 August 2020 (UTC)

  The optimal length varies for different people. We shouldn't be forced to use somebody else's optimal length, and if people can't handle long lines, they have the window resize feature available (the technology has existed since the 1980s). Some people who have widescreen monitors may have chosen one in preference to a 4:3 monitor because they wanted to use the extra width - they don't want it wasting with big white rectangles. --Redrose64 🌹 (talk) 08:43, 22 August 2020 (UTC)

  This. I wouldn't object quite so much if there were a way to easily revert to full width for the typical reader who is not logged into an account. 24.151.56.107 (talk) 15:19, 24 August 2020 (UTC)

Logo overlaps article talk tabs

The examples provided at mw:Reading/Web/Desktop Improvements show the upper left Wikipedia logo 'overlapping' the Article and Talk tabs. However, the actual implementation does not do this, creating the large whitespace on the left of the article. To make matters worse, the horizontal length of the logo is extended by the positioning of the collapse sidebar button directly to the logo's left. This feels like a really easy thing to pick up on, so was it 1) missed and/or thought irrelevant, or 2) changed or accepted without updating the mediawiki page which should be explaining these changes? Either way this feels like poor form. CMD (talk) 07:06, 25 August 2020 (UTC)

Bug in list-defined references?

At the help desk, a user reported trouble fixing the cite error reported when editing this article: Special:Permalink/973392423. The reported error is "Cite error: A list-defined reference with the name "2011pdf" has been invoked, but is not defined in the <references> tag (see the help page).", but is not true – cite "2011pdf" is ref #2 ("LEADERS OF THE OPPOSITION ..."). Other symptoms of a problem include:

• ref "2" has backlinks "a" (to note "b") and "b" (to note "c"), but no backlink to note "d", even though note "d" has a (forward) link to ref "2".
• In the body, there is a (forward) link to note "b" from row 3 in the table, a backlink "a" from note "b" to row "3", a (forward) link to note "b" from row 4 in the table, a backlink "b" from note "b" to row "4". However, there is also a backlink "c" from note "b" that does not do anything (it should not exist, as there is no third use of note "b").

I fixed the spurious error and those symptoms by moving the list-defined notes out of the {{notelist}} up into the table (inline) at Special:Diff/974256349, but I can't see why that didn't work correctly as it was. Is there a bug here, or did I miss something? —[AlanM1 (talk)]— 01:23, 22 August 2020 (UTC)

I think this might be T125075. – Jonesey95 (talk) 05:10, 22 August 2020 (UTC)

Pinging Izno, who created that phab task. Does this look like a match to you? Should we document it at Help:Footnotes? – Jonesey95 (talk) 05:12, 22 August 2020 (UTC)

This has been covered at Wikipedia:Nesting footnotes#4. List-defined references since February 2017. --Redrose64 🌹 (talk) 08:56, 22 August 2020 (UTC)

I was just splitting a 4-task task in Phab (i.e. coming). The original is much earlier and I had nothing to do with that filing: phab:T24635. --Izno (talk) 11:25, 22 August 2020 (UTC)

@Redrose64: It's not clear that this (somewhat common) case is necessarily covered there, at least not as far as the interplay between groups. This case can be whittled down some to:

This is body text.

References

Note that it works fine with just NoteA and Ref1. When I add NoteB and its refs to Ref1 and Ref2 is when thing go sideways. —[AlanM1 (talk)]— 21:08, 27 August 2020 (UTC)

Trying to get Dylan Thomas' image to appear in the hover pane

For example, a photo of the subject appears when the cursor is hovering over this inserted link Sir John Powell but not when over the Dylan Thomas link. Is it just my pc/browser perhaps or are others also affected? Is there a fix to his infobox perhaps that can achieve this? Horatius At The Bridge (talk) 20:16, 22 August 2020 (UTC)

I see an image for both in Firefox, Chrome, Edge and Brave, but the format of the popup is different if I am logged in or not. On an iPad, I cannot hover on a link at all. — GhostInTheMachine ^{talk to me} 21:12, 22 August 2020 (UTC)

Image shows for me. Emir of Wikipedia (talk) 21:19, 22 August 2020 (UTC)

I seem to recall but can't find the previous thread that this relates to whether the image is free or not and NFCC images do not show up on hover especially on the mobile site. Nthep (talk) 21:23, 22 August 2020 (UTC)

Richard_Hughes_(British_writer) contains a Non Free image but the hover pane works for me unlike Dylan Thomas Horatius At The Bridge (talk) 21:40, 22 August 2020 (UTC)

Emir of Wikipedia do both images appear and can I ask what device/browser you are using and where i.e in UK? Horatius At The Bridge (talk) 21:43, 22 August 2020 (UTC)

The image which shows for me on Dylan Thomas is File:Dylan Thomas photo.jpg which is a non-free image. Emir of Wikipedia (talk) 21:45, 22 August 2020 (UTC)

on all the browsers you listed and in the UK - the exact reverse of my experience - this is very curious is it not? Horatius At The Bridge (talk) 22:08, 22 August 2020 (UTC)

Any other suggestions on why this issue is seen by some users and not others? Please check it out yourself - for me the Hover pane appears here John Powell_(judge) (CC) and Richard_Hughes_(British_writer) (NFCC) but not here Dylan Thomas (NFCC) or here Kingsley_Amis (CC) ?Horatius At The Bridge (talk) 08:25, 23 August 2020 (UTC)

Horatius At The Bridge, one set of people is referring to Navigation Popups and another to Page_Previews ? —TheDJ (talk • contribs) 13:41, 23 August 2020 (UTC)

OK thanks, good point. I'm solely concerned with the Notable People list in the Laugharne article where the hover pane works on some links with photos but not with others as explained above and also why some users don't get this variation at all - all the bios photos display the pic. (Whether it's called a navigation popup or a page preview - I'm afraid I don't know)Horatius At The Bridge (talk) 16:40, 23 August 2020 (UTC)

@Horatius At The Bridge: The relevant settings are as follows:

• at Preferences → Appearance, under the heading "Reading preferences" there is an item "⧼popups-prefs-optin-title⧽"
• at Preferences → Gadgets, under the heading "Browsing" there is an item "Navigation popups: article previews and editing functions pop up when hovering over links"

It's best to enable one or neither, but not both at once. --Redrose64 🌹 (talk) 10:03, 24 August 2020 (UTC)

I see the same. Photos with Powell and Hughes, no photos for Thomas and Amis. I'm in London and using Page Previews, without Navigation Popup enabled, in Firefox. Does this help at all? —  Jts1882 | talk  16:58, 23 August 2020 (UTC)

And if I switch off Page Preview and enable navigation popup, I see images for all four. —  Jts1882 | talk  17:02, 23 August 2020 (UTC)

I've just tried your last combo, it works but the preview boxes are in quite a different and less readable format. It's really the first simple image display option I want but for all the photo links. Thank you for reassuring me I am not alone with this anomaly btw Horatius At The Bridge (talk) 18:58, 23 August 2020 (UTC)

My user preferences are all set to default so this issue should afflict others with the same settings. It is not related to the infobox template - see John Perrot which has one and which produces the image in the hover pane - whereas Kingsley Amis and Dylan Thomas also have that syntax but do not display the image. Similarly links without infoboxes such as Richard Hughes do generate a hover pane image whereas Caleb Rees, also without an infobox, does not. All these examples are from the Laugharne Notable People list. Surely there must be an explanation and fix for this basic anomaly? Horatius At The Bridge (talk) 09:49, 24 August 2020 (UTC)

The Page Preview algorithm obviously excludes some images for a reason. The non-free image use seems the most likely cause, as the fair use justifications apply to use on a single page, not to popups on every page linking to it. Some are getting through, perhaps because they are tagged differently on the image page. If so, fixing it will probably mean excluding all the non-free images, including those now shown, rather than displaying them all. —  Jts1882 | talk  10:11, 24 August 2020 (UTC)

With navigation popups enabled (only possible without Reading/Page Preview enabled) all images are displayed for the user with that configuration but in a different and less readable format (imo). That is certainly a fix displaying CC and NFCC images but my objective is for both types to show in the clearer Page Preview mode. This cannot be a function of copyright designation or infobox inclusion since the examples cited above do already display in all combinations. There seems to be another parameter such as tags - as suggested - that is in play here. My issue is to identify if there is and determine whether it can changed to provide a fix to enable consistent image inclusion in the hover pane when Page Preview is selected. Horatius At The Bridge (talk) 12:15, 24 August 2020 (UTC)

I think the algorithm that scores images for Page Images may be involved, as described at mw:Extension:PageImages#How_are_images_scored?. Image score depends on size, aspect ratio, and possibly its licence. The images that don't show (Thomas, Rees, Amis) are below the optimum size (<400px), while images that appear (Hughes) are larger. Hughes might stop appearing when the bot resizes the image to follow with the free use criteria.—  Jts1882 | talk  14:51, 24 August 2020 (UTC)

I'm obliged, that looks like the culprit ;-) It would be rather odd for a bot to automatically degrade NFCC images to prevent their display in Page Preview but permit it in navigation pop up mode.Horatius At The Bridge (talk) 18:08, 24 August 2020 (UTC)

Sorting list of names by last name

I'm in the process of converting an alumni page from a bulleted list to a series of tables, so that readers will have the option to sort by name, not just year of graduation. The documentation for how to sort by last name, at Help:Sorting#Specifying a sort key for a cell, advises adding e.g. | data-sort-value="Pashgian, Helen" | [[Helen Pashgian]] for every row, as I did here. That seems like a terrible and duplicative way to store the information, though, since there are already sortkeys defined at all the pages for use in categories. Is there any way to tell the table to just automatically fetch the DEFAULTSORT value for each page listed, so that I don't need to write them all out myself? {{u|Sdkb}} ^talk 05:40, 23 August 2020 (UTC)

I believe you're looking for {{sortname}}. —Cryptic 06:07, 23 August 2020 (UTC)

Cryptic, I came across that template and was like "excellent!", and then I saw it has an orange deprecated notice, suggesting using the above method instead. I just looked through the talk page archives, and see that Scarabocchio has brought up similar concerns. So is the deprecation notice inappropriate? Courtesy pinging others who discussed on that page: @Redrose64, Jonesey95, and Erik:. {{u|Sdkb}} ^talk 00:22, 24 August 2020 (UTC)

Sdkb, it was deprecated. Then no one listened for years, so i found an alternative way to sort of make it work. But the other method is still better. —TheDJ (talk • contribs) 08:23, 24 August 2020 (UTC)

TheDJ, isn't it better to have some way to not have to repeat the name, though? Per don't repeat yourself. {{u|Sdkb}} ^talk 08:25, 24 August 2020 (UTC)

Sdkb, sortname also repeats, it is just hidden behind template logic. —TheDJ (talk • contribs) 09:31, 24 August 2020 (UTC)

TheDJ, looking at it, it doesn't seem to—{{sortname|Helen|Pashgian}} only includes "Helen" once, but the template is able to sort it by "Pashgian, Helen". That's what we'd want. {{u|Sdkb}} ^talk 09:43, 24 August 2020 (UTC)

Sdkb, just because it isnt visible, doesn't mean it isn't happening. Also the template doesn't sort. A script that reads the table content does the sorting. The template generates the hidden information that tells it which value to use for that. —TheDJ (talk • contribs) 11:37, 24 August 2020 (UTC)

TheDJ, what you're describing is still DRY, since it's generating (behind the scenes) the data-sort-value from the name itself, thus requiring only one instance of the name in the source code, not two. {{u|Sdkb}} ^talk 14:55, 24 August 2020 (UTC)

Sdkb & TheDJ The difference in user-friendliness between {{sortname}} and the alternative is immense. A new editor would be able to use {{sortname}} after glancing at the page source. The same editor would shy away from the contortions of the data-sort-value clause. It's counter-productive to require the editor to understand something of the mechanics behind the scenes - a properly written template would save them that, and allow them to move onto more productive matters. Scarabocchio (talk) 19:24, 24 August 2020 (UTC)

The templates I have seen that make this easiest are customized table row templates such as {{National football squad player (goals)}} and other templates in Category:Sports squad templates. – Jonesey95 (talk) 15:54, 24 August 2020 (UTC)

Jonesey95: Are you suggesting editors create such customized row templates for each table they want to make sortable? IMO the template sortkey works fine. -- Michael Bednarek (talk) 03:41, 25 August 2020 (UTC)

(ec) I agree that the template is necessary. Sdkb's point about duplication is not about the underlying code – it's about what the editor does/sees. The chances of the average editor correctly editing both the property and the displayed name is unlikely near the 100% accuracy produced by the template, in my experience, not to mention being extra work. I was surprised when I saw it was deprecated with no replacement, as it's transcluded over 41,000 times (and should be used much more, as I see routinely find tables that sort names incorrectly without it). —[AlanM1 (talk)]— 03:49, 25 August 2020 (UTC)

I'm not suggesting that anyone do anything they don't want to do, but just showing that people make lots of templates to ease the creation of standard table rows. As for {{sortname}}, should it really still be deprecated after TheDJ's modifications to use the data-sort-value attribute? – Jonesey95 (talk) 04:01, 25 August 2020 (UTC)

Given that we can't find any discussion leading to the deprecation and that the sentiment here seems to be it's useful, I'm going to go ahead and remove the deprecation notice. {{u|Sdkb}} ^talk 21:35, 25 August 2020 (UTC)

AlanM1, i'll note there is a replacement. Editors just refuse to use it. The downside to this template form, is that the sort key only applies to the template call itself, instead of to the cell. If you put any other content into the table cell, that content will be appended/prepended to your sort key, and might cause different behaviour from what people expect. Especially with date and number sorting that might be a problem. But this is one of those areas that just works sub optimally. Anyone is welcome to improve upon the status quo. —TheDJ (talk • contribs) 09:53, 26 August 2020 (UTC)

Toolforge

Does anyone know who or where to ask for admin help on Toolforge? Trying to restart or fix a tool for which we don't know who the maintainer is: https://translation-server.toolforge.org/ -- GreenC 21:40, 23 August 2020 (UTC)

GreenC, [3] doesn't help? --Izno (talk) 23:13, 23 August 2020 (UTC)

Other than that, I'd suggest filing a ticket at phab:project/profile/539/ saying you're looking for the maintainer so you can ask him for a restart. --Izno (talk) 23:16, 23 August 2020 (UTC)

GreenC, Pinging Smith609, the tool maintainer. May be worth to Special:EmailUser/Smith609 too. Ed talk! 00:02, 24 August 2020 (UTC)

The #wikimedia-cloud IRC channel is a nice place where you'll find WMCS employees as well as volunteers. SD0001 (talk) 04:36, 24 August 2020 (UTC)

It seems that the tool has not worked since the DNS move, and it has been restarted sense. AManWithNoPlan (talk) 14:39, 24 August 2020 (UTC)

Table sorting buttons coloring

As a bit of a follow-up to my question about coloring reference labels, at the U Michigan presidents table, the house coloring of the header row doesn't seem to apply to the up and down arrows used to sort the table, which remain black and thus mostly disappear. Is there any way to make them white, or is that just as impossible as with the reference labels? {{u|Sdkb}} ^talk 05:01, 24 August 2020 (UTC)

Sdkb sort of the same. Those are actually images. —TheDJ (talk • contribs) 08:19, 24 August 2020 (UTC)

TheDJ, images? Oh my. Well, I guess I'll consider my dreams of color-coordinated sorting arrows crushed for the foreseeable future. {{u|Sdkb}} ^talk 08:23, 24 August 2020 (UTC)

Looking for page transclusion templates

The normal way of transcluding a talk page, e.g., the way we handle discussions about promoting a page to Wikipedia:Good articles status, is just to stick the page straight into the wikitext: {{Talk:St. James Church (Queens)/GA1}} gets pasted into Talk:St. James Church (Queens), and it's done.

However, it appears that some folks use a template for this, so instead you would type something like {{Special transcluder template|1=Talk:St. James Church (Queens)/GA1}} or maybe even {{Special GA discussion transcluder|article=St. James Church (Queens)}} and it has the same effect as just doing it above (maybe with an added category or decorative border).

My question: I've seen one of these templates at the Korean Wikipedia. Does anyone here know of any others that are in regular use? In practice, I only care about transcluding pages that contain (current/active/you might want to join these today) discussions. Whatamidoing (WMF) (talk) 15:16, 24 August 2020 (UTC)

Tech News: 2020-35

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 August. It will be on non-Wikipedia wikis and some Wikipedias from 26 August. It will be on all wikis from 27 August (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

17:58, 24 August 2020 (UTC)

Halp with ugly very long URL

There is an eye sore at [4]. My wiki-fu is not strong enough to make it bearable, can you help? --Palosirkka (talk) 20:45, 24 August 2020 (UTC)

While this is more of a new problem (unless you have the same problem) than a solution, I see this URL all the way across the page, covering up information in different columns. It doesn't even happen in every line of the URL.— Vchimpanzee • talk • contributions • 20:50, 24 August 2020 (UTC)

I also see that, probably should've mentioned it. --Palosirkka (talk) 08:10, 25 August 2020 (UTC)

@Palosirkka and Vchimpanzee: I have hidden the stray note in an HTML comment: Special:Diff/974837864. --CiaPan (talk) 09:14, 25 August 2020 (UTC)

Thank you CiaPan, I think that was a good solution as the info does not need to be visible in the refs. --Palosirkka (talk) 09:26, 25 August 2020 (UTC)

@Palosirkka: Thank you for your comment. I wonder if the part I hid should remain there at all, or rather just be deleted. When hidden, it does not help our readers. It's not very useful when viewed with a text editor, either. If anybody wants to configure or parametrize the linked report, they can achieve that with controls available there in. Geek hints on URL hacking are quite outside the scope of encyclopedia... I think I'll delete that in a few days, unless someone tries to restore it or utilize in other way. --CiaPan (talk) 11:31, 25 August 2020 (UTC)

@CiaPan:I tried to take a look at the URL but it outputs nothing without JavaScript so it's impossible for me to say whether that snippet is of use or not. --Palosirkka (talk) 11:33, 26 August 2020 (UTC)

How to find contributions after a name change?

The link that doesn't work is here. The signature on this help desk question has a green link to the talk page, which for me indicates a redirect. That happens when a username is unacceptable and needs to be changed. Shouldn't there be a way to find the contributions of the person under the old name?— Vchimpanzee • talk • contributions • 20:46, 24 August 2020 (UTC)

Vchimpanzee, they are kept. My account was renamed, and all my contributions are still on my account - see Special:Contributions/Merluni_Moonfang Ed talk! 21:28, 24 August 2020 (UTC)

Yes, but look at what happens when you click on this link.— Vchimpanzee • talk • contributions • 21:35, 24 August 2020 (UTC)

Vchimpanzee, yes, that's because the account has been renamed, so technically you cannot access the contributions of a username which now has no user assigned to it, so you follow the user talk link to the new account. Ed talk! 21:55, 24 August 2020 (UTC)

When a user is renamed, the name shown against all of their existing contributions is adjusted to suit. So the contribs for the old name will be empty, and the contribs for the new name will also list all of the edits made prior to the rename. Follow the link to either the user page or the user talk page, and in the left margin, click "User contributions". --Redrose64 🌹 (talk) 11:20, 25 August 2020 (UTC)

Again, no solution is provided for finding the contributions made by the name that has been changed. It is probably a rare situation, but if you do encounter it, it seems there should be some method of finding out that the name has been changed when you go to the contributions. There is none. If you click on the link and that's all you have, you are led to believe the username has made no contributions, because there is nothing to indicate there is a new name.— Vchimpanzee • talk • contributions • 15:28, 25 August 2020 (UTC)

@Vchimpanzee: depending on the situation, when an account gets renamed the old name becomes available, and could be taken by someone else - meaning that the contributions of that "name" should be about the contributions made by that "account". — xaosflux ^Talk 15:33, 25 August 2020 (UTC)

That does complicate things. I suppose if the situation I encountered is that rare, it would be ... no, a name that has been reused would actually be less likely than one that had not. Radio and TV call letters are a good example of the same situation in Wikipedia article titles. We have hatnotes for those. I once added to the directions for how to handle a redirect after a move because call letters could be reused. Before my contribution, the directions said just go ahead and keep the redirect in links to the former article.— Vchimpanzee • talk • contributions • 16:09, 25 August 2020 (UTC)

How do I make a sidebar equal in width to an infobox?

I'm trying to make Template:Civil conflict sidebar equal in width to an infobox on an article page. For example, on Nashville sit-ins the sidebar is not equal in width to the infobox. I'm attempting to replicate the appearance shown at World War II that use Template:campaignbox. Mitchumch (talk) 22:19, 24 August 2020 (UTC)

@Mitchumch: I got it working with some horrible hackery: Special:Diff/974783257, Special:Diff/973457485/974785480, and Special:Diff/974782396. That's less than ideal, but I think it's as close as you'll get to how World War II does it. Jackmcbarn (talk) 00:53, 25 August 2020 (UTC)

I was thinking there was a template modification that would auto-adjust with the size of the infobox. There are an ever growing list of articles with comparable sidebar templates like this one. I didn't know how the military sidebars were able to always be the equal width of their corresponding infoboxes. I looked at the code, but I didn't see anything. I also looked at the template through the "edit" selection and I didn't see any parameter for "| width =".

I appreciate the work you did. I didn't know there was a way to manually manipulate the width of a campaignbox outside of coding. Mitchumch (talk) 07:38, 25 August 2020 (UTC)

Just as sidebars are not all the same width, infoboxes aren't either. Some have a fixed width, some have the width determined by the widest item that it contains, which is often an image. --Redrose64 🌹 (talk) 11:23, 25 August 2020 (UTC)

Redrose64 Are you saying all the military articles with campaignboxes are manually adjusting their infoboxes to match the width of campaignboxes? Mitchumch (talk) 17:04, 25 August 2020 (UTC)

Without examples, I can't tell. But I do know that in a situation where there are two boxes (perhaps produced by templates) neither of which is a child of the other, neither box can know the width of the other so cannot adjust its own width to match. --Redrose64 🌹 (talk) 23:20, 25 August 2020 (UTC)

Redrose64 What's the value of parameter "sidebox" in Template:Infobox civil conflict? Can that parameter be modified to inform the sidebar's width? Mitchumch (talk) 07:50, 26 August 2020 (UTC)

Issue with dynamic preview

When I have "Show previews without reloading the page" set to "on" for dynamic edit previews, the preview now hangs. It throws the following error: "Uncaught ReferenceError: t聨is is not defined" Wanted to flag in case it's a newly introduced typo somewhere. For now, I've toggled the dynamic preview off and I'm fine. czar 03:07, 25 August 2020 (UTC)

 Works for me However, the ajax preview feature is known to break due to presence of broken external scripts from your common.js. SD0001 (talk) 07:27, 25 August 2020 (UTC)

@Czar: Just a guess, but try replacing User:Svick/HarvErrors.js with the User:Trappist the monk/HarvErrors.js. SD0001 (talk) 07:28, 25 August 2020 (UTC)

Yeah that should definitely be it. See Module_talk:Footnotes#Multiple_invalid_harvnb's:_preview_hangs where this was reported before. SD0001 (talk) 07:37, 25 August 2020 (UTC)

@SD0001, between that and logging out, looks like I'm back to normal. Thanks! czar 23:16, 25 August 2020 (UTC)

Resolved

Article talk page

At Talk:Arameans, after making an edit [5], two sections are no longer visible in the table of contents, namely 32 Modern identity and 33 RfC about the modern Aramean identity, and the formatting appears to have merged them, see [6] for before. I've tried to add a topic to the page, but to no avail. Thank you. Mugsalot (talk) 19:08, 25 August 2020 (UTC)

@Mugsalot:  Fixed - an unclosed <ref> tag made the rest of the page disappear. -- John of Reading (talk) 19:23, 25 August 2020 (UTC)

HotCat's hidden failures

 You are invited to join the discussion at Wikipedia talk:HotCat § Doesn't always work. {{u|Sdkb}} ^talk 20:54, 25 August 2020 (UTC)Template:Z48

Bullet points in ref

 Note: Wikipedia:Help_desk#Bullet_points_in_ref.--Hildeoc (talk) 23:48, 25 August 2020 (UTC)

Template:Collapsible large category TOC

How can one fix the rendering of excess ("double") boldface of the term Contents:in that template? (I tried really hard, but just couldn't figure out how to fix that.) Thanks in advance for any support!--Hildeoc (talk) 13:01, 26 August 2020 (UTC)

PS: As can be seen from here, for instance, in transclusions there is also an excess blank line rendered above that template. How can that be fixed, too?--Hildeoc (talk) 13:06, 26 August 2020 (UTC)

The Contents: text is highlighted with strong tags (Contents:) rather than b tags (Contents:). These look the same to me, but do they show differently on your browser?

Re the category page. I have just moved the {{Commons category}} infobox up. Not sure if that is a "correct" thing to do, but it seems to remove the blank lines. — GhostInTheMachine ^{talk to me} 22:16, 26 August 2020 (UTC)

I am not a Lua or CSS expert, but it looks like the word "Contents" is assigned the CSS class "NavHead", which assigns "font-weight: bold;" in MediaWiki:Common.css, and the module also applies <strong>...</strong> tags. This may be the "double" boldface that Hildeoc is describing. – Jonesey95 (talk) 03:28, 27 August 2020 (UTC)

I believe you're right. I edited Module:Large category TOC/sandbox to remove the extra strong and the result can be seen at Template:Collapsible large category TOC/testcases. The second line shows "Contents:" without strong. It's a bit weak and perhaps some tweaking would be in order. Johnuniq (talk) 10:08, 27 August 2020 (UTC)

Scheduled down time

Just giving this wider visibility: Wikipedia:Village pump (miscellaneous)#Important: maintenance operation on September 1st. -- RoySmith (talk) 14:04, 26 August 2020 (UTC)

Hide transclusions doesn't?

I'm looking at https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Vinmont_Veteran_Park&hidetrans=1. There's a slew of links, but almost all of them are because those articles transclude {{Protected areas of New York City}}. What part of "Hide transclusions" am I not understanding? -- RoySmith (talk) 18:08, 26 August 2020 (UTC)

PS, there's a "Hide links" option, which makes everything go away. So, that's an option to show me "everything that links here, except for the things that link here"? -- RoySmith (talk) 18:10, 26 August 2020 (UTC)

I believe the 'hide transclusions' hides transclusions of the article, not links to the article from a transcluded template. As far as I can tell, every page linking to that article also carries the template [7]. There could also be direct links other than those in the template, but I'm not sure how to check for that. –xeno^talk 18:14, 26 August 2020 (UTC)

"Hide transclusions" is typically useful only for templates, which are transcluded using {double brace notation}. In this case, the article Vinmont Veteran Park is not transcluded in any other pages, so hiding transclusions does not change the list of pages that is displayed. Possibly of interest: T14396 and {{Source links}}. – Jonesey95 (talk) 18:38, 26 August 2020 (UTC)

Xeno, Ah, cool. The petscan tool does exactly what I'm looking for. Thanks. -- RoySmith (talk) 18:40, 26 August 2020 (UTC)

There is a transclusion that can be hidden. Do a text search for 'transclusion' (without quote marks) at this page: https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Vinmont_Veteran_Park&limit=500; 2× results. Now hide transclusions and do the text search again: 1× result. Vinmont Veteran Park transcludes itself because Module:Citation/CS1/Configuration reads the article's raw wikitext when it searches for {{use xxx dates}} templates.

—Trappist the monk (talk) 19:04, 26 August 2020 (UTC)

Stop forcing readers to use the ugly interface

Hello, I am a reader of the English Wikipedia who is angry because I have to click each time to switch the view to the "mobile view", that is the only view that is modern, and readable by current standards. However, I feel like the English Wikipedia community is disrespectful towards us readers, because we do not participate in the Bizantine discussions about the sex of the angels. I do not care which interface you choose when you are logged in, and you have made it to your 50th year as an editor with your x286. For us contemporary people, there is no doubt that what you call the "mobile interface" must be the default one. I am horribly upset and disgusted by the paternalistic attitude of older Wikipedia editors that want to force us, readers, to follow their interface preference. Please change that attitude, and change the default view to the mobile view for all non-logged-in users. Logged in users can keep using their preferred interface as usual.--DataAthlete (talk) 21:58, 26 August 2020 (UTC)

Go to your preferences and set your skin to "Timeless" and be free.--Jorm (talk) 22:01, 26 August 2020 (UTC)

Wikipedia continues to have separate mobile and desktop sites. Why?.--Moxy 🍁 22:04, 26 August 2020 (UTC)

Timeless is a very nice skin for reading; alternatively you may be interested in opting in to and following the improvements to the Vector skin. There is certainly a discussion to be had about whether editors' views have a disproportionate impact on aspects of the interface, but it is beyond the scope of this page. – Teratix ₵ 04:37, 27 August 2020 (UTC)

@Jorm, Moxy, and Teratix: Your answers are a reflection of what is becoming Wikipedia, a useless site run by people who do not understand basic requests. I have been very clear in my request, but since it did not come across the first time, I will try again. I want English Wikipedia editors to stop forcing English Wikipedia readers to use the ugly interface. For this reason I want the "mobile interface" to become the default interface for all non-logged in users. How do I make that happen?--DataAthlete (talk) 07:30, 27 August 2020 (UTC)

Being rude and unpleasant to volunteers who have answered your questions is unlikely to persuade them to follow up with clarifications. – Teratix ₵ 08:15, 27 August 2020 (UTC)

The problem with your suggestion is that it effectively forces non-logged in users to use the mobile interface - where the reader doesn't see things like infoboxes, navboxes etc, so they don't get the same information.Nigel Ish (talk) 08:20, 27 August 2020 (UTC)

@DataAthlete: You can't fix it for non-logged in users. You can only affect your own destiny. I tried for years to make this shit-interface better for everyone and it is simply not fucking possible to do. Save your energy and make your own life better. The Wikipedia I see is pleasant and usable. I have my own CSS rules that fix lots of ugly. Go with whatever deity pleases you.--Jorm (talk) 15:34, 27 August 2020 (UTC)

• @DataAthlete: - I am also concerned by the paternalistic attitude of certain Wikipedia readers that want to force everyone else, to follow their interface preferences, despite it concealing significant critical information, like infoboxes. I'm also at a loss on why your opening message (let alone your second) was so randomly hostile and rude, and also why you might think that is a good way to get the result you desire. Nosebagbear (talk) 08:27, 27 August 2020 (UTC)

Hi, DataAthlete. Could you, please, specify, how many 'contemporary people' are you, exactly? I think it would add appropriate weight to your request when other users see how many people you are. --CiaPan (talk) 09:51, 27 August 2020 (UTC)

• Wikipedia exists for its readers, but would not exist without editors, and our main way of getting new editors is for readers to click the edit button and start editing. So of necessity the skins we show readers are a compromise between something tuned for readers and something designed for editors. Currently the mobile skin is much more reader focused than the desktop skin, and as a result we have a mostly "desktop" or PC based editing community writing and maintaining Wikipedia for what is now a majority Mobile audience. So calls to replace the default desktop skin with the mobile one are likely to be resisted as they would greatly reduce our recruitment of new editors and put the editing community into decline. Eventually that would either have to be reversed, either by finding a new way to recruit editors or by going back to the compromise of Vector, or even the more editor focussed Monobook as the reader skin. People who only concern themselves with the short term needs of readers may have no doubt as to the best skin to use, but without editors there would be nothing to read. The real challenge is how to make the mobile skin more editor friendly. ϢereSpielChequers 10:08, 27 August 2020 (UTC)

  WereSpielChequers, I'd go a bit further than that. Right now, editing is mostly a text-based activity. Even with the VisualEditor, that's just a nicer way to enter text. Mobile (by which I mean things lacking a dedicated text keyboard) fundamentally sucks at entering large amounts of text.

  The next big advance is editing wikipedia on mobile will not be tweaks like mobile-friendly skins, but a fundamentally new way to interact, such as voice recognition. Voice is making progress, but it's a long way from being commodity software. There are even better technologies in the works, but they're even further away from being ready.

  And, yeah, DataAthlete, for somebody with 3 edits to their name, you might want to tone it down a little. -- RoySmith (talk) 17:38, 27 August 2020 (UTC)

  @DataAthlete: Regarding your comments the paternalistic attitude of older Wikipedia editors that want to force us, readers, to follow their interface preference and I want English Wikipedia editors to stop forcing English Wikipedia readers to use the ugly interface - interface changes are nothing to do with Wikipedia editors (among whom are everybody who has ever posted to this page, including you and me), they are made by the MediaWiki software developers. Their tasklist/noticeboard/discussion forum is at phabricator:. --Redrose64 🌹 (talk) 19:39, 27 August 2020 (UTC)

  That's a bit disingenuous. Many UI changes that at least I would consider as positive have been rejected by the community. I'm sure you can list them off also. The complaint holds some truth in the regard that the community has unfortunate keys to that door. --Izno (talk) 20:31, 27 August 2020 (UTC)

  @RoySmith In general, yes. Mobile and especially smartphones are slower for data entry than keyboards. My experience of the Mobile site is not recent, and it is possible it has been transformed without my noticing. But I think that unlikely as my understanding of Newbies and editor stats is that we are overwhelmingly a stable keyboard using community. I recently spent a while on Quora which is also a very text based site, but I had no problem using that on a tablet. I'm loathe to edit Wikipedia on a tablet, and when I do the first thing i do is switch to the desktop view. I suspect that our best short term route would be to go from two sites to three - smartphone, tablet and keyboard. Longterm I'm sure someone will crack voice recognition, my own first experience with that was over twenty years ago and at the time it seemed a few years away from usable. When and if it ever does become viable you then hit the problem that not everyone has a private office to edit in. It isn't just libraries where voice recognition may not be entirely viable. ϢereSpielChequers 21:52, 27 August 2020 (UTC)

  WereSpielChequers, I have it on good authority that voice recognition will be perfected soon. -- RoySmith (talk) 22:18, 27 August 2020 (UTC)

  Excellent, thanks for settling that beyond all possible response. I look forward to it, and also to the teleport that cometh with it. The prophets who gave us interracial kisses, satellite phones and automatic doors clearly know more of the future than I do. ϢereSpielChequers 18:55, 28 August 2020 (UTC)

• I translated @DataAthlete's complaint, and it came out as:

I, DataAthlete, prefer prefer the mobile interface, so I use that. I demand that all you useless idiots force everyone else to follow my choice.

For some reason, this hasn't produced a positive response. I wonder why? --BrownHairedGirl (talk) • (contribs) 10:34, 28 August 2020 (UTC)

Change that breaks layout

See m:Tech#Change_that_breaks_layout.--GZWDer (talk) 02:12, 27 August 2020 (UTC)

Featured/GA topicons for mobile

Tracked in Phabricator
Task T75299

There's currently no display of topicons for mobile readers, which particularly impacts things like GAs and FAs, where it would be very useful for readers to see the designation. There's even a blank space at the top right where the topicons could go. Are there any efforts underway to get topicons to be able to display on mobile? {{u|Sdkb}} ^talk 04:15, 27 August 2020 (UTC)

This is phab:T75299 but as far as I know it's not being worked on at the moment. the wub "?!" 13:21, 27 August 2020 (UTC)

There are hints about this issue at MediaWiki:Manual and MediaWiki:Help:Page status indicators, but I don't see any local CSS files that have relevant statements about the CSS classes that are involved. It is unclear to me where in the MW code or our local configuration that topicons are being displayed or suppressed. – Jonesey95 (talk) 13:42, 27 August 2020 (UTC)

They aren't really being suppressed, the issue is that MinervaNeue (the mobile skin) doesn't render the indicators at all in the template. I made some quick edits to the code earlier, as GA/FA not being on mobile bugs me too, to add them into the skin, but some design thought needs to go into where to place them; it looks quite ugly to have them to the right for articles with multi-line titles (pics on the phab ticket). ProcrastinatingReader (talk) 17:47, 27 August 2020 (UTC)

Double redirects

I have noticed that double redirects take way too long to fix. At the least, they can take several days. At most, they can take months or longer. This is a problem. We need a faster system to detect and fix them. The current bots are very slow, and the special page is slow to update. Is there any way that we can update the list faster? A bot should be created that looks at any newly created redirects. If they are double redirects, it will fix them instantly. This should be technically possible, after all, SineBot is able to monitor every talk page and sign posts almost instantly. Why doesn't such a bot exist? — Preceding unsigned comment added by I-82-I (talk • contribs) 01:53, 28 August 2020 (UTC)

@I-82-I: WP:BOTREQ is the place to ask someone else to build a bot. — xaosflux ^Talk 11:47, 28 August 2020 (UTC)

In my experience double redirects are fixed by bots in a matter of minutes, at most hours. EmausBot is currently very active. Can you name specific examples of double redirects which weren't fixed for "several days, ... months or longer"? I find it most likely the problem isn't that the bots are slow but that there are specific issues with such redirects that make them difficult for the bots to detect. Nardog (talk) 03:21, 29 August 2020 (UTC)

Charinsert problem

When writing User:Jo-Jo Eumerus/Gemmi Pass Fault I've noticed that the characters below the edit box cannot be inserted. I click on them and nothing happens. Jo-Jo Eumerus (talk) 11:59, 28 August 2020 (UTC)

That's mw:Extension:CharInsert (MediaWiki:Gadget-charinsert-core.js) we're talking about. ​ Which of those characters aren't working? All the ones I checked worked for me. SD0001 (talk) 12:48, 28 August 2020 (UTC)

None of these that I checked works. BTW, I think it's a Charinsert thing b/c shutting it off in Preferences causes all the buttons to disappear (and reappear upon switching it back on). Jo-Jo Eumerus (talk) 13:46, 28 August 2020 (UTC)

Jo-Jo Eumerus: You are importing quite a few user scripts in User:Jo-Jo Eumerus/common.js, some of them old or otherwise causing script errors. For example: if I enter

importScript( 'User:Ais523/adminrights.js' );

I get

You installed the userscript [[User:Ais523/adminrights.js]]
It has been deprecated and replaced with [[User:Amalthea/userhighlighter.js]]

and

importScript('User:Ohconfucius/script/MOSNUM dates.js');

yields . Nirmos (talk) 23:07, 29 August 2020 (UTC)

Image positioning changes on mobile?

I recently noticed that on mobile, an image always appears after the first text paragraph even if it's located at the top of the page (in Wikitext). This behaviour was previously only seen with infoboxes. Why was this change made? If people wanted the image to appear after the paragraph, they would simply add it like that in Wikitext. Forcing image positioning is unnecessary. Examples of affected articles: Jai Shri Ram, Ramnami Samaj. Regards, TryKid ^{[dubious – discuss]} 12:22, 28 August 2020 (UTC)

On Jai Shri Ram, the {{Confuse}} template, which appears in the wikitext after the first image but before the lead paragraph text, is rendered below the lead paragraph on mobile. That seems like a bug. I realize that the Confuse template may not be exactly in the right place, but it should render above the lead paragraph. – Jonesey95 (talk) 16:03, 28 August 2020 (UTC)

gutenberg: links broken

The English Wikipedia appears to have a special prefix, [[gutenberg:, to link to Project Gutenberg books. It is currently broken, apparently because PG has changed their URL structure from /etext/ to /ebooks/ without leaving a site-wide redirect. I'm sure that Michael Hart would have been appalled at this basic misstep in web practice, but here we are.

Does anyone know how to change the URL that is used by [[gutenberg:? I searched all namespaces at en.WP and at mediawiki.org and was unable to find anything that explained how this magical prefix works.

Please see this template talk discussion for the original thread. – Jonesey95 (talk) 16:28, 28 August 2020 (UTC)

@Jonesey95: It's at meta:Interwiki map and changes are requested at its talk. Johnuniq (talk) 23:33, 28 August 2020 (UTC)

Thanks. I left a note there. – Jonesey95 (talk) 02:34, 29 August 2020 (UTC)

Basic Lua help needed at Template talk:Bibleverse

Someone with pretty basic Lua skills is needed at Template talk:Bibleverse. Thanks. – Jonesey95 (talk) 17:18, 28 August 2020 (UTC)

Twinkle, RedWarn not showing up

Moved from WP:Teahouse. Ed talk! 20:18, 28 August 2020 (UTC)

I have Twinkle and RedWarn enabled, but they're not showing up for some reason. I think it started today or last night. Mvcg66b3r (talk) 19:45, 28 August 2020 (UTC)

Hi, @Mvcg66b3r can you open your Javascript console and check for errors? See Wikipedia:Reporting JavaScript errors Ed talk! 19:48, 28 August 2020 (UTC)

I'm using Chrome 85 with Windows 10 version 2004. This is the error message that came up:

Uncaught (in promise) Error: The message port closed before a response was received.

   at document_start.js:8 

Mvcg66b3r (talk) 20:12, 28 August 2020 (UTC)

Mobile diff overflow / scrolling

Recently (I first noticed it yesterday) diffs on mobile containing URLs don't add line breaks and instead just let the content scroll out to the side, making diffs really annoying. Is this a recent accidental change?  Nixinova   T   C   01:21, 29 August 2020 (UTC)

I think this new “feature” is what’s bothering me as well. In mobile view, which I use almost all the time, I used to have all the editing screens justified (with no need to scroll sideways) while using my phone upright. That has changed for the worse in the last few days. Gleeanon409 (talk) 15:35, 29 August 2020 (UTC)

Can we flag broken links to YouTube?

See Template_talk:YouTube#Broken_links_need_to_be_flagged where I noted the problem a few days ago (but I guess that is a low-visibility talk page). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:25, 29 August 2020 (UTC)

@Piotrus: not automatically, there is nothing special about youtube, it would be the same as any other broken web link. Some of the reference archive bots might look in to it - but really what would you want done with the link? — xaosflux ^Talk 02:02, 29 August 2020 (UTC)

The archive bots would not detect as dead because it returns 200 ie. a soft-404.

./header 'https://www.youtube.com/watch?v=QkWIN7SXowc'

HTTP/1.1 200 OK

It would require a specialized bot to detect. But even then, sites like archive.org don't save youtube videoes (with a few exceptions). Typically dead youtube videos are gone forever, which is to say, all in time will evaporate. -- GreenC 02:38, 29 August 2020 (UTC)

What I wold like to be done is for the dead YouTube link to be either marked as such (so it can be manually saved, since videos are sometimes reuploaded - like in the case of some public domain movies that first caught my attention) - or just removed. The first option is preferable as we need a human to decide whether a link can be rescued (public domain etc.) or is just gone. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:09, 29 August 2020 (UTC)

The web archive sites often have snapshots of everything in the page but the video. Thus when they get tagged with a {{dead}} the bots would add such an archive giving the false appearance of a "saved" video. For example from the article Google : https://web.archive.org/web/20100816150501/http://www.youtube.com//watch?v=soYKFWqVVzg -- GreenC 13:46, 29 August 2020 (UTC)

Intersection Observer alternative

Hi!

Wikipedia recently changed the way lazy loading is implemented. It now makes use of the Intersection Observer API.

Many devices (for example all iOS devices below 12.2) do not support this API, which renders wikipedia almost unusable to read certain types of articles, particularly math related, since the fallback solution has the user tap a tiny tiny grey box for every image in the article. When it comes to math a single character in a sentence might be an image.

This is quite sad, since it changes wikipedia from the fastest and most reliable source of information, to a website you only visit if you don’t have any other options.

Is there any way to make wikipedia usable again on older devices? Maybe a way to disable lazy loading altogether, or make wikipedia use the old algorithm which actually worked before falling back to the grey box solution. — Preceding unsigned comment added by Kilian Geronimo (talk • contribs) 15:55, 29 August 2020 (UTC)