Wikipedia:Village pump (technical)/Archive 184

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)

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)

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

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)

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)

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)

Up until a few days ago my iPhone view was automatically set to the correct width (I almost exclusively use it vertically).

Now frustratingly the screen width seems to be auto set for a tablet width so no view of mine shows the full text on the screen.

Help! Gleeanon409 (talk) 02:40, 30 August 2020 (UTC)

Hey all - I'm trying to document some of the workings of LinksUpdateHookHandler.php in a user space essay and I don't know gerrit well enough to know if I'm looking at the most current version. I'm trying to find the equivalent of what used to be here https://github.com/wikimedia/mediawiki-extensions-PageImages/blob/master/includes/LinksUpdateHookHandler.php

Can anyone help? And/or could you point me to some information to get me up to speed on gerrit? - Scarpy (talk) 05:31, 30 August 2020 (UTC)

Scarpy, I personally browse on the Phabricator mirror ( https://phabricator.wikimedia.org/diffusion/EPIM/ particularly) since I know it syncs close to daily (I do not know the Github cadence) and the search interface is simple enough for me to navigate. I think from a browsing perspective on gerrit you want https://gerrit.wikimedia.org/g/mediawiki/extensions/PageImages (you can find it from Browse in the new GUI with some effort).

The file in question is at includes/Hooks/.. rather than at includes/.. (per PSR 4 move I believe). I would guess Github is reasonably up to date since I can find the file in the same directory in all three repo/mirrors. --Izno (talk) 06:08, 30 August 2020 (UTC)

I discovered this doozy today: File:Rogemar Ecaranum.jpg. Somehow, this was submitted as a jpg, instead of Draft:Rogemar Ecaranum. I can't move it to the correct place. Not sure what to do, or how this was even possible.--Auric talk 10:16, 30 August 2020 (UTC)

I mean, we should know what to do for the future, but in this case I'm rather inclined to just delete it and let the author know where to attempt to recreate it. Ian.thomson (talk) 10:28, 30 August 2020 (UTC)

Thanks. Tagged for CSD under F2, F10 and G8.--Auric talk 10:45, 30 August 2020 (UTC)

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 Uncaught ReferenceError: ohc_US_slash_dates_driver is not defined. Nirmos (talk) 23:07, 29 August 2020 (UTC)

Ha. @Nirmos:, removing these scripts did in fact resolve the issue. However I wonder where you see the "ohc_US_slash_dates_driver is not defined" issue as I can't see it. Jo-Jo Eumerus (talk) 07:41, 30 August 2020 (UTC)

Jo-Jo Eumerus: In the browser console. You should be able to open the console in most browsers (Chrome/Edge/Firefox) by pressing f12. Nirmos (talk) 08:26, 30 August 2020 (UTC)

Well, F12 does open the console but not that warning. I suspect that it's not clear which console on which URL. Perhaps someone who sees the warning can file a request at User talk:Ohconfucius/script/MOSNUM dates to fix the problem. Jo-Jo Eumerus (talk) 09:16, 30 August 2020 (UTC)

@Jo-Jo Eumerus: You also have the discontinued User:AWeenieMan/furme.js installed in your vector.js. It or some other script not mentioned by Nirmos may be interfering with Charinsert. Nardog (talk) 23:04, 30 August 2020 (UTC)

As I posted in Template talk:WikiProject Biography#Free Image Search Tool error a month ago, the link to the Free Image Search Tool generated by {{WikiProject Biography}} generates a 404 error. Is this something that can be fixed? Thanks! GoingBatty (talk) 05:01, 30 August 2020 (UTC)

GoingBatty, you will need to contact the tool maintainer, who is Magnus Manske. --Izno (talk) 05:45, 30 August 2020 (UTC)

@Izno: Thanks - I opened an issue for Magnus Manske at https://bitbucket.org/magnusmanske/fist/issues/15/free-image-search-tool-link-generates-a GoingBatty (talk) 00:44, 31 August 2020 (UTC)

Oops, I've already fixed the link in the template. But the current location of the tool is quite redundant and most likely not intended (which is a result of the recent move of Toolforge tools to subdomains), so it should probably be fixed anyway. Nardog (talk) 00:52, 31 August 2020 (UTC)

Nardog, yeah, I didn't think it necessary to call out the issue with the link since I tried with the good link and found the service did not work. --Izno (talk) 01:05, 31 August 2020 (UTC)

GoingBatty, conisder emailing him as well. I don't know how much he checks BB, even though that is the ostensible place to bug him. --Izno (talk) 01:05, 31 August 2020 (UTC)

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)

Kilian Geronimo, I have filed: T261609 —TheDJ (talk • contribs) 08:50, 31 August 2020 (UTC)

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)

Nixinova, this is likely related to an effort where they are trying to bring the mobile diff and the desktop diff together again in the same view. I've made note of this problem (which is likely unintended) in the ticket phab:T240622. —TheDJ (talk • contribs) 08:59, 31 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)

There is an eye sore at [1]. 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)

Deleted: Special:Diff/975951798. --CiaPan (talk) 10:09, 31 August 2020 (UTC)
Notifying @Palosirkka and Vchimpanzee:.

Hi! I was wondering if it would be possible to develop a tool which allows (1) numbered lists whose numbering continues throughout the article and (2) an automated way of referring back to earlier examples. I would find this enormously useful for linguistics articles, and another editor at the help desk suggested that this might be useful for many other math/science related articles as well. Speaking just for linguistics articles, many of them currently format their examples in ugly or confusing ways, and have to use text that “breaks the fourth wall” in order to achieve a minimum standard of clarity. My idea is that editors could write markup like this (or perhaps less cumbersome!):

Example <exref = “donkey” /> shows that donkey anaphora exists. Example <ex ref = “donkeyRC”> uses a relative clause, while Example <ex ref = “donkeyif /> uses a conditional.

<ex name=“donkey” /> Donkey Anaphora:

<subex name = “donkeyRC” />Every farmer who owns a donkey beats it.</subex>

<subex name = “donkeyif” />If a farmer owns a donkey, he beats it.</subex>

</ex>

Blah blah blah imagine this text runs for several paragraphs, perhaps with a section break in the middle. Now compare the pair shown in <ex ref = “donkey” /> to the completely unrelated ones in <exref = “kangaroo” />.

<ex name=“kangaroo” /> Counterexample to Antecedent Strengthening:

<subex name = “kangarootail” />If Kangaroos didn't have tails, they would topple over.</subex>

<subex name = “kangaroojetpack” />If Kangaroos didn't have tails, but did have jetpacks, they wouldn't topple over.</subex>

</ex>

And this would render as:

Example (1) shows that donkey anaphora exists. Example (1a) uses a relative clause, while Example (1b) uses a conditional.

(1) Donkey Anaphora:

a. Every farmer who owns a donkey beats it.

b. If a farmer owns a donkey, he beats it.

Blah blah blah imagine this text runs for several paragraphs, perhaps with a section break in the middle. Now compare the pair shown in (1) to the completely unrelated ones in (2).

(2) Counterexample to Antecedent Strengthening:

a. If Kangaroos didn't have tails, they would topple over.

b. If Kangaroos didn't have tails but did have jetpacks, they wouldn't topple over

Crucially, the numbers would all update consistently if the page is edited to change the order of the examples, or to stick in intervening examples. I imagine that something like this could be built based on whatever currently handles reference numbering, and if any further inspiration is needed, the LaTeX package “linguex” has this functionality. Botterweg14 (talk) 16:51, 31 August 2020 (UTC)

Read this in another language • Subscription list for this newsletter

The Reply tool has been available as a Beta Feature at the Arabic, Dutch, French and Hungarian Wikipedias since 31 March 2020. The first analysis showed positive results.

• More than 300 editors used the Reply tool at these four Wikipedias. They posted more than 7,400 replies during the study period.
• Of the people who posted a comment with the Reply tool, about 70% of them used the tool multiple times. About 60% of them used it on multiple days.
• Comments from Wikipedia editors are positive. One said, أعتقد أن الأداة تقدم فائدة ملحوظة؛ فهي تختصر الوقت لتقديم رد بدلًا من التنقل بالفأرة إلى وصلة تعديل القسم أو الصفحة، التي تكون بعيدة عن التعليق الأخير في الغالب، ويصل المساهم لصندوق التعديل بسرعة باستخدام الأداة. ("I think the tool has a significant impact; it saves time to reply while the classic way is to move with a mouse to the Edit link to edit the section or the page which is generally far away from the comment. And the user reaches to the edit box so quickly to use the Reply tool.")[2]

The Editing team released the Reply tool as a Beta Feature at eight other Wikipedias in early August. Those Wikipedias are in the Chinese, Czech, Georgian, Serbian, Sorani Kurdish, Swedish, Catalan, and Korean languages. If you would like to use the Reply tool at your wiki, please tell User talk:Whatamidoing (WMF).

The Reply tool is still in active development. Per request from the Dutch Wikipedia and other editors, you will be able to customize the edit summary. (The default edit summary is "Reply".) A "ping" feature is available in the Reply tool's visual editing mode. This feature searches for usernames. Per request from the Arabic Wikipedia, each wiki will be able to set its own preferred symbol for pinging editors. Per request from editors at the Japanese and Hungarian Wikipedias, each wiki can define a preferred signature prefix in the page MediaWiki:Discussiontools-signature-prefix. For example, some languages omit spaces before signatures. Other communities want to add a dash or a non-breaking space.

• The new requirements for custom user signatures began on 6 July 2020. If you try to create a custom signature that does not meet the requirements, you will get an error message.
• Existing custom signatures that do not meet the new requirements will be unaffected temporarily. Eventually, all custom signatures will need to meet the new requirements. You can check your signature and see lists of active editors whose custom signatures need to be corrected. Volunteers have been contacting editors who need to change their custom signatures. If you need to change your custom signature, then please read the help page.

Next, the team will be working on a tool for quickly and easily starting a new discussion section to a talk page. To follow the development of this new tool, please put the New Discussion Tool project page on your watchlist.

Whatamidoing (WMF) (talk) 18:47, 31 August 2020 (UTC)

In the Bengali language article all the images in the top section have, for some reason, pushed downwards. I have tried fixing it to no success, have posted to the Teahouse, with no success (here and here). May be I am phrasing the request for help inadequately.

If you take a look at the article, I tried using one image with History, another image with the following section, and a third image in the next section, followed by a multiple image template in the next (all aligned to left, as the right side is taken over by infoboxes). But all of them has been pushed down, and now they are all bunched around toward the bottom end of {{Bengalis}} infobox.

I tried a similar thing in another article – putting one image in the first section. That one was pushed down a bit too. I was suggested that too many floating objects may be the problem, but the second article has only two floating objects at the top of the article – one image and one infobox – while the remedy suggested by Extended image syntax page didn't work (i.e. "alternating between left and right in aligning images or other floating objects").

How can I get the images at Bengali language article to appear where they were placed? Aditya^{(talk • contribs)} 06:44, 30 August 2020 (UTC)

Ahem. Did I, in my foolishness, come to a wrong page or posted a wrong question? I really thought I would get a solution either at Teahouse or here. Well... my bad. :( Aditya^{(talk • contribs)} 21:10, 30 August 2020 (UTC)

Aditya Kabir I don't know if I exactly understood, or helped. Let me say that the image spacing looks entirely different in my Firefox browser, than it does in Chrome. So, that might be one factor. Also, sometimes I see where an image has pushed down into another section, because there is not enough section wording to even it out. In this case, I inserted the template {{clear}} after the first three images. If that resulted in what you wanted, then good. If it didn't, just revert my edits. That's the only thing I can think of to do. — Maile (talk) 22:53, 30 August 2020 (UTC)

This is a common problem. What you have here is three floating objects in the lead section - {{Infobox language|...}}, {{Contains special characters|Bengali}} and {{Bengalis}} each of which is right-aligned, and naturally the second and third are pushed down by those above. Later on (in the History section) you have a fourth floating object, File:East-magadhan-proto-languages.png. Even though this is left-aligned, its upper edge cannot be any higher than the upper edge of the previous floating object, the {{Bengalis}}. If you want the image to be displayed higher up than {{Bengalis}}, the latter needs to be moved to some point after the image. --Redrose64 🌹 (talk) 23:17, 30 August 2020 (UTC)

@Redrose64: Thanks. I get it now. This is what I was afraid of. Multiple infoboxes on the right makes it impossible to put an image in the top section across Wikipedia. But, even with Bengali Language forgotten, this looks like a problem for way too many articles (unless editors decide to give up and put no image in the top sections). Isn't that so? Aditya^{(talk • contribs)} 02:03, 31 August 2020 (UTC)

It's a limitation of CSS, not of Wikipedia. --Redrose64 🌹 (talk) 19:19, 31 August 2020 (UTC)

20:08, 31 August 2020 (UTC)

Is there a tool that allows you to see all moves a page has gone through? Special:Log is useless because it only lists moves when you enter the old name (if only it accepted a page ID...). Nardog (talk) 01:11, 31 August 2020 (UTC)

The logs only exist for the "old" page names. So, assuming no other loggable actions such as protection, if a page starts of at A and is moved to B and later on moved to C, the log for A will show a create and one move (to B); the log for B will show one move (to C); the log for C will be empty. To track a chain of moves it's usually necessary to look at the edit history of the page. --Redrose64 🌹 (talk) 19:25, 31 August 2020 (UTC)

@Redrose64: I know, that's exactly what I meant and I'm specifically asking for a way to automate that process. Disentangling the move history of a page can be quite a hassle especially when the page has a large number of revisions or when the same name has been occupied by multiple pages (e.g. "Cantonese"). Nardog (talk) 20:34, 31 August 2020 (UTC)

Yeah, it would be really nice if there were a way to log these. The nearest thing I know is the way previous RM discussions are normally tracked in the {{old RM}} banner on talk pages (but this practice hasn't been consistent over time). One way of getting the move history of a given page (not title), is to load its history (all of its history, possibly altering the &limit= bit in the url to move past the 500 limit), and then searching for the string moved (note the spaces on either side), which should fish out the moves by their automated edit summaries (this doesn't help with moves from the earlier days of Wikipedia when there were no such summaries). – Uanfala (talk) 15:43, 1 September 2020 (UTC)

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)

I love snark that needs no tags. -- llywrch (talk) 22:12, 1 September 2020 (UTC)

I just noticed in my Chrome Developer Tools window, I'm loading a bunch of js files from various WMF projects:

https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript
https://de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-revisionjumper.js&action=raw&ctype=text/javascript
https://meta.wikimedia.org/w/load.php?modules=ext.gadget.MoreMenu
https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-DotsSyntaxHighlighter.js&action=raw&ctype=text/javascript
https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-modrollback.js&action=raw&ctype=text/javascript

I've never noticed these before. They don't get loaded in an incognito window, but blanking my common.js doesn't prevent them from being loaded. So, I'm assuming something changed in some gadget I have enabled. Any ideas? -- RoySmith (talk) 12:48, 2 September 2020 (UTC)

I don't think anything changed; these gadgets (HotCat, etc.) are just loaded from external Wikimedia sites. Based on their edit history (for example, HotCat's), they've done so for years now, since 2012 or before. Perhaps Chrome has made a change with how it displays external scripts? Writ Keeper ⚇♔ 13:27, 2 September 2020 (UTC)

RoySmith, some of the en.wp gadgets are proxy gadgets which load code from other wiki's yes. This is to ensure centralised maintainability of these gadgets. If you had any of these gadgets enabled before, then you simply never realised this was happening, it is not new. —TheDJ (talk • contribs) 13:29, 2 September 2020 (UTC)

TheDJ, OK, thanks. It's certainly possible that I've just never noticed it. -- RoySmith (talk) 13:38, 2 September 2020 (UTC)

Hi, recently a user made vandalism on my article by subverting names of the title. Due to some technical restrictions, I cannot revert his/her destructive edit; while some expert users use Twinkle. How to use this technique? The Supermind (talk) 13:45, 2 September 2020 (UTC)

The Supermind, Give us a hint: which article are you talking about? A link to the page, and specifically which change you're talking about? -- RoySmith (talk) 14:21, 2 September 2020 (UTC)

Kiev Day and Night. Now I fixed manually. User:Bozhena last edition. The Supermind (talk) 14:34, 2 September 2020 (UTC)

Despite diligently studying Help:Watchlist, I cannot work out what determines the filled or unfilled bullet at the start of each line in a watchlist. I am figuring it must signify something - but I have no idea what. Can someone help me out?ThoughtIdRetired (talk) 15:38, 2 September 2020 (UTC)

@ThoughtIdRetired: depending on the version of the watchlist you display this may look different - but it should be signifying if the page has changed or not since you last read it - is that what you are experiencing? — xaosflux ^Talk 15:49, 2 September 2020 (UTC)

Thanks - I should have thought of that. I cannot check if that is what is happening as I have been in and out of my watchlist (and articles on it) trying to work out what was going on. I'll let the dust settle and check for this behaviour in a day or so.ThoughtIdRetired (talk) 15:55, 2 September 2020 (UTC)

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)

I found that double-redirects caused by page moves are fixed up quite fast; typically the bot interrupts me in the middle of me fixing them up manually after a move. However, redirects accidently created pointing to another redirect instead of the actual target page often take days or weeks to be fixed. So, perhaps the bot needs some more hooks triggering its fixup work. --Matthiaspaul (talk) 12:36, 2 September 2020 (UTC)

Yes, double redirects resulting from moves get fixed fast. In fact too fast, and that leads to problems. – Uanfala (talk) 17:57, 2 September 2020 (UTC)

I have seen several edits like this where someone creates a citation that has nonsense information, usually for authors. Other examples have things like "first1=James" with "last1=Cameron,Lewis,Rebekah,Schultz,Peter,New York Times columnist Web exclusive" or somesuch. I have asked the editor who added this why and how he did and he ignored me. Can anyone figure out how this is happening and how we can avoid it? ―Justin (koavf)❤T☮C☺M☯ 20:56, 1 September 2020 (UTC)

"How this is happening" is called Visual Editor. It has over 2,000 open tasks in Phabricator, including many bugs that were reported over three years ago (e.g. T162291 and T174303) and that still cause gnomes to have to clean up after editors who don't know that they are using software that is so buggy. We can avoid it by going to Preferences - Editing and checking the box labeled "Temporarily disable the visual editor while it is in beta". Welcome to the party! – Jonesey95 (talk) 04:02, 2 September 2020 (UTC)

gnomes have always done cleanup work. beginning editors generally don't fully write out references... we like references don't we ? —TheDJ (talk • contribs) 09:13, 2 September 2020 (UTC)

It is not VisualEditor, the same incorrect names are produced for [5] when using the RefToolbar in the wikitext editor. The problem is with the Citoid/Zotero service which attempts to automatically extract metadata from a URL. It probably needs some fixes to the translator for Der Spiegel as described at mw:Citoid#Troubleshooting_the_citoid_service. the wub "?!" 09:55, 2 September 2020 (UTC)

BTW. Anyone can test what the citation extraction platform (backed by Zotero) generates, by using the Wikimedia api directly as mentioned on that page. And Zotero (also used by many researchers around the world to keep track of sources when writing their papers) is always looking for contributors to their translators, to help both Wikipedia and all researches around the world to have better output ;) —TheDJ (talk • contribs) 12:20, 2 September 2020 (UTC)

I wasn't able to figure out the problem with the Der Spiegel translator myself, so have created an issue at the Zotero project [6] for someone to look into it. @Koavf: if you have more examples, please share them and I'm happy to take a look and file further issues if required. the wub "?!" 21:34, 2 September 2020 (UTC)

The wub, I have seen several and they are all of the same sort. If it's really worth tracking down repeats of the same kind of problem, let me know. ―Justin (koavf)❤T☮C☺M☯ 23:29, 2 September 2020 (UTC)

The "Page information" menu option sometimes reports Lint errors. So I installed WPCleaner and gave it a try.
The first page I tried was Wikipedia:WPCleaner/Installation. Page information reports 1 lint error. WPCleaner said it was OK. The embedded function in WPCleaner to use CheckWiki also said it was OK.

— What is CheckWiki?

— How do we ask Page information to show us the errors that it has found? — GhostInTheMachine ^{talk to me} 20:41, 3 September 2020 (UTC)

The Page Information lint error count is unreliable (see T246403). To see Lint errors on each page, install User:PerfektesChaos/js/lintHint. You will then see a yellow LintHint button at the top right of each page. It will generate a list of errors. If you click it in Preview mode, it will generate a list of errors, along with an arrow that takes you to each error's (approximate) location in the text.

Activating a syntax highlighter, like the one in Preferences - Gadgets, also helps. Feel free to post at Wikipedia talk:Linter if you have further questions; there are a handful of us gnomes working on fixing the errors. – Jonesey95 (talk) 21:09, 3 September 2020 (UTC)

Thanks. LintHint does help. — GhostInTheMachine ^{talk to me} 21:39, 3 September 2020 (UTC)

For context, see Wikipedia_talk:Teahouse#Edit_Request_Wizard. Sam-2727 put together an edit request wizard (= a user-friendly form to make edit request).

If a user wants to make a paid editing disclosure, they are brought to Wikipedia:Edit_Request_Wizard/Paid. The page will then bring them to User:(whatever they filled the box with) and preload a {{paid}} template. This means both that they could go to the wrong page if they type the incorrect username (in which case there is no easy clean-up), and also that they have to type something the software probably could take care of. Is there a way to link to the viewing user's page? (Assume a logged-in user if needed.) Tigraan^{Click here to contact me} 08:34, 3 September 2020 (UTC)

@Tigraan: I haven't looked at the mechanics of this at all, but Special:MyPage always links to your own userpage. — xaosflux ^Talk 11:47, 3 September 2020 (UTC)

@Tigraan: OK so that's not going to work for that - a withJS link may work, depending on how people get to that page - if they only get to it from another link a javascript could be invoked to help fill out that form. Would editors ever go to that page directly, or always land somewhere else first? — xaosflux ^Talk 11:49, 3 September 2020 (UTC)

What's wrong with a button like this: Disclose payment? Nardog (talk) 13:29, 3 September 2020 (UTC)

@Nardog: that should work for a button-based solution (and there is also Special:MyTalk if this needs to target the userpage) - and I'm not seeing they really need a "form" for this so should be the simplest. — xaosflux ^Talk 13:33, 3 September 2020 (UTC)

Nardog and xaosflux, thanks for the simple solution! I forgot that special page existed. Sam-2727 (talk) 23:17, 3 September 2020 (UTC)

I just visited www.mediawiki.org where I have a handful of contributions from a few years ago. Why does it show me as not logged in? Is it part of WP:SUL and it's just some glitch that I'm not logged in there?

I was looking at mw:WP:TNT which is a redirect to mw:Multilingual Templates and Modules and that leads me to another question: why does diff at Module:No globals show the funky w>DiBabelYurikBot without the normal "(talk | contribs)" links? That's also in the page history. Johnuniq (talk) 03:07, 3 September 2020 (UTC)

@Johnuniq: mediawiki.org is part of SUL, so you should be logged in there. When you first go to a new wiki, you often have to refresh the page before it fully takes effect, though. As for the weird username and missing talk/contribs links, it looks like that's an artifact of that particular revision being imported, rather than actually being made as an edit on this wiki. Jackmcbarn (talk) 04:45, 3 September 2020 (UTC)

Thanks, strange... Johnuniq (talk) 05:17, 3 September 2020 (UTC)

Johnuniq, browsers have started significantly restricting the presence of cookies on other domains. Unless you visit every top level domain in the wikimedia family at least once a day, there is no way any longer that browsers reliably support cross domain authentication like our SUL. You can thank all the ad trackers etc for ruining it for the ‘good’ people. —TheDJ (talk • contribs) 06:57, 3 September 2020 (UTC)

Isn't the internet wonderful, thanks. So if I needed to do something at mediawiki.org, I would have to log in using my normal SUL name and password, and I should expect to have to do that again if returning after a delay of a day or two. Johnuniq (talk) 07:59, 3 September 2020 (UTC)

@Johnuniq: this could be browser-specific, for example I just visited various WMF sites I rarely go to (e.g. ukquote) and was logged in just fine. Are you using "remember me" for your logon on here? — xaosflux ^Talk 19:11, 3 September 2020 (UTC)

• This happens to me too. Ugh, I cannot even count how many times I've accidentally edited on Wikidata while logged out. I've found the SUL issue usually happens more often when using the desktop view on a mobile device. Steel1943 (talk) 19:15, 3 September 2020 (UTC)

  @Steel1943: are you using "remember me" on your logon? When this happens, what do you have to do to get logged in (e.g. reload the page, actually enter your credentials, something else)? — xaosflux ^Talk 19:18, 3 September 2020 (UTC)

  • @Xaosflux: "are you using "remember me" on your logon?" Yep. "When this happens, what do you have to do to get logged in[?]" "Actually enter my credentials". Steel1943 (talk) 20:30, 3 September 2020 (UTC)

    • @Steel1943: do you mind sharing what browser you are using? Can you duplicate this problem with a different browser? — xaosflux ^Talk 21:59, 3 September 2020 (UTC)

    • @Xaosflux: Arg!!!! I'm using Safari. I've heard about various issues with Wikipedia on Safari, and I guess this takes the cake: I could not replicate the issue on Chrome. On Chrome, SUL worked just fine. Steel1943 (talk) 22:53, 3 September 2020 (UTC)

  If login cookies are misbehaving, try an explicit Special:UserLogout - this is performed server-side, but will invalidate all of your login cookies on all devices, no matter how old or how corrupt they may be. Then you can use Special:UserLogin to create a fresh, new, clean set of cookies. --Redrose64 🌹 (talk) 19:31, 3 September 2020 (UTC)

  • @Redrose64: Just did that, and then went to Wikidata ... which shows me as logged out. I'm just so used to it anymore that it doesn't phase me. Page refreshes don't work either; I have to manually log into each site ... which is weird because oppositely, after I log out of one Wikimedia site, I get logged out of all Wikimedia sites. Steel1943 (talk) 20:32, 3 September 2020 (UTC)

    Special:UserLogout is supposed to log you out of all WP:SUL sites, because it invalidates all of your login cookies. Until a couple of years ago, the login cookie was generated on whichever wiki that you used Special:UserLogin at; nowadays it's login.mediawiki.org that generates the login cookie. If you go to another site - say commons: - and find that you're not logged in, refreshing the same page multiple times is usually nonproductive; but it's often quicker (if not easier) to follow a few links on that site until you hit a page that shows you as logged in. Try the site's "random page" link a few times. --Redrose64 🌹 (talk) 21:57, 3 September 2020 (UTC)

    I figured the logout scenario was intentional. And I shouldn't have to hit "random page" a bazillion times to make my SUL carry over. In fact, I tried that, and after about 10 times, it didn't work. But it did work after time 15. Steel1943 (talk) 22:50, 3 September 2020 (UTC)

Looks like this is a known issue with Safari (phab:T226797). — xaosflux ^Talk 00:05, 4 September 2020 (UTC)

See also User talk:MusikAnimal/Archive 41#Using steward access?. * Pppery * _{it has begun...} 00:52, 4 September 2020 (UTC)

I am wondering how a vandalized Wikipedia article has ended up in my Wikivoyage userspace with no trace of it being moved there. Several of us at Wikivoyage have investigated and can't find out how this happened. It seems to have happened in August of this year. The only connection that I can see is that a few weeks ago I read the Wikipedia article on my phone, but I didn't edit it. Any thoughts? Ground Zero | t 20:22, 1 September 2020 (UTC)

Ground Zero, Take a look at your post: it's not quite grammatical and the link seems broken. ―Justin (koavf)❤T☮C☺M☯ 20:57, 1 September 2020 (UTC)

Koavf, the links work for me, and I don't see a grammatical error. What is it that you don't understand? Ground Zero | t 21:12, 1 September 2020 (UTC)

Ground Zero, An IP fixed the link and I misread you. ―Justin (koavf)❤T☮C☺M☯ 21:36, 1 September 2020 (UTC)

How bizarre. There you've got the whole history of our Milli Vanilli article up to a certain point in August 2010, almost exactly a decade ago. Whatever miracle caused this, it can't have occurred in 2010 as Wikivoyage didn't exist at the time. – Uanfala (talk) 21:26, 1 September 2020 (UTC)

I did a query on Quarry to find the page id and did another query to find pages with the ids either side of that.

use enwikivoyage_p;
select *
from page
where page_id >= 179513
and page_id <= 179521;

Which returned the following results:

page_id	page_namespace	page_title
179513	0	North_Vidzeme_Biosphere_Reserve
179514	0	New_York_(NY)
179515	1	New_York_(NY)
179516	1	North_Vidzeme_Biosphere_Reserve
179517	2	Ground_Zero/Milli_Vanilli
179521	3	Traveller1975

voy:North_Vidzeme_Biosphere_Reserve is in the import log as being imported on 13 July 2020 and voy:User talk:Traveller1975 was created on 14 July 2020, so whatever it was, it happened sometime between those two items. -- WOSlinker (talk) 22:58, 1 September 2020 (UTC)

As an importer here myself, I know that the import tool can be weird when trying to work with many revisions at a time ... it probably timed out and never logged properly. Ground Zero, is there some sort of gadget/tool (on Wikipedia/Wikivoyage's side)that facilitates easy imports to Wikivoyage that you might have enabled somewhere and perhaps misclicked on? I can't find any evidence of that but that's the only plausible explanation I can think of. Re timestamps: revision ID numbers can tell an interesting story too ... the first revid after your imported edits is 21:13, 13 July 2020 (UTC) and the last one from before your first imported edit is from 21:08 (UTC) on the same day. Graham87 04:09, 2 September 2020 (UTC)

Wasn't voy: started off as a kind of mirror/fork of WikiTravel? Maybe the route was Wikipedia → Wikitravel → Wikivoyage. --Redrose64 🌹 (talk) 18:32, 2 September 2020 (UTC)

@Ground Zero: The revision ID of the latest imported revision of voy:User:Ground_Zero/Milli_Vanilli is 4020727. Revision 4020728 is a talk page comment, from you, about a failed attempt to import a page into your userspace. So it looks like the import aborted mid-way through, at the vandalized revision, and didn't log properly, but it really was you. Suffusion of Yellow (talk) 22:03, 2 September 2020 (UTC)

still funny that it hit this particular article. ---Sluzzelin talk 22:13, 2 September 2020 (UTC)

@Uanfala, WOSlinker, Graham87, Redrose64, Suffusion of Yellow, and Sluzzelin: This does seem to have happened around the time that I was experimenting with the Import tool in order to deal with Wikipedia articles in the Category:Copy_to_Wikivoyage. I'm not a very technical person, and had forgotten that I had been using that, so it makes sense that I may have started the import by accident, then cancelled it part way through. Thank you for taking the time to investigate or at least think about this. Ground Zero | t 01:29, 4 September 2020 (UTC)

Anyone experiencing issues with edit previews not working correctly? I was making these changes, converting stuff like "Runner Up" to "runner-up". When I'd click Preview, the preview window showed that they were still capped and unhyphenated, even though the edit window showed that they were lower-case and hyphenated. the Show changes feature indicated that the change had been made. I also changed "Evicted By Housemates", to "Evicted by housemates", and after hitting preview, only one of the instances changed to lowercase. The others were still capped. So, just curious if anyone else is experiencing this. I'll blow out my cache and whatnot. Cyphoidbomb (talk) 16:05, 3 September 2020 (UTC)

1. I haven't had such an experience like that (lately/today/at all)

2. Are you sure you were looking at the right "Runner Up"s? I see 7 instances on that page, where you're changing only 5 of them

3. YIKES!! What devices do readers of this article use? One tables at 80%, the next is at 60%, and the broken <small> tagging for the Notes makes the entire Reflist teeny. Please, oh please take a look at WP:ACCESS, and rework the tables (and everything else) to not go below 85%. — JohnFromPinckney (talk) 19:48, 3 September 2020 (UTC)

@JohnFromPinckney: Hey, I always leave a possibility open that I'm an idiot and I'm missing something. I'm looking at this version of the article, (current as of this moment,) and in the Housemates Status section (miscapitalised), which is the section I edited, I still see "1st Runner-Up" and "Walked (5th Runner-Up)" and "Health Issue", even though I fixed those in my edit. I just purged that article's page cache and my browser cache, but still see the caps. I've got to be missing something here. It's also not something I've ever seen in page preview mode. Also, good luck making sense of the Bigg Boss templating across all the Indian language versions... Hindi, Tamil, Malayalam... Cyphoidbomb (talk) 00:22, 4 September 2020 (UTC)

OK, having looked closer at this, I think Template:Runner-up and Template:Quit are artificially forcing capitalisation when it's not warranted or needed. Cyphoidbomb (talk) 01:50, 4 September 2020 (UTC)

@Alucard 16: Hey there, since I see you have some knowledge of these templates, any thoughts on this? Since most of the stuff we add to tables seems to be more "Sentence case" formatted, I'm not exactly sure that "Runner-Up" is quite right from that perspective, although I'm not arguing with any Big Brother/Bigg Boss consensus(es) in mind. But if someone provides an explanation for a character leaving, like "Health issue" that probably doesn't need to be capped, right? Not trying to nitpick, but in a table like wot you see at Bigg_Boss_(Hindi_season_13)#Housemates_status, there's somewhat of a inconsistency there that I'm not sure how to encourage an entire community of casual editing series fans to adhere to. Thanks and regards, Cyphoidbomb (talk) 02:13, 4 September 2020 (UTC)

Hi I'm signed in right now but on my cell phone while not logged in I was looking at Wikipedia and looked at the edit page and noticed it said I was rangeblocked until Feb. 2021. I have only edited one thing ever on Wikipedia, it was when I saw a typo,the word because misspelled and so I excitedly fixed it. I searched a long time for minor typo that I could edit and become a part of Wikipedia. But I don't know if that would cause a rangeblock. I'm wondering what could've happened? — Preceding unsigned comment added by CircleRightEye (talk • contribs) 10:17, 4 September 2020 (UTC)

@CircleRightEye: See Template:Rangeblocked. --Malyacko (talk) 11:24, 4 September 2020 (UTC)

@CircleRightEye: Most cell phone IP addresses are blocked from editing Wikipedia. I personally think that it's overzealous, but I've lost that argument here before. --Ahecht (TALK
PAGE) 13:05, 4 September 2020 (UTC)

Do we by any chance have a template for use in the edit window, whereby an editor can quickly go to the bottom of a a section? Seems to me that these long drawn-out discussion topics could use such a tool. What a pain to scroll and scroll to get to the bottom to post a comment. — Maile (talk) 13:38, 4 September 2020 (UTC)

Ctrl+End? -- Michael Bednarek (talk) 14:02, 4 September 2020 (UTC)

Thank you! — Maile (talk) 14:31, 4 September 2020 (UTC)

This might be a stupid question but i need to make sure. On bnwiki we have a UTCLiveClock gadget (enwiki also has it) & a LocalLiveClock gadget (same code with little variant). Recently i updated their code and definition (by copying from enwiki). Here is the diff, notice that i used UTCLiveClock-pagestyles & UTCLiveClock.css for both gadgets. Is it fine? will it cause any problem? are css code going to be loaded twice? --আফতাবুজ্জামান (talk) 01:55, 4 September 2020 (UTC)

If the same CSS file is loaded twice, that's generally harmless. If something happened in between the two loads to modify the effects of the first load, those modifications might be reversed by the second load. --Redrose64 🌹 (talk) 08:03, 4 September 2020 (UTC)

@Redrose64:Thanks for reply. This two gadgets aren't default. Unless some enable both at the same time, i'm guessing there wont be any problem. Right? --আফতাবুজ্জামান (talk) 14:36, 4 September 2020 (UTC)

What's the best way to parse wikitext in javascript? I'm thinking something with the functionality of mwparserfromhell. What I'm doing now is just regex matching to find the templates I need, but that broke when somebody formatted a template in a slightly different (but still legal) way. This, of course, is unsurprising, since everybody knows that trying to abuse regex as a language parser is a lost cause. -- RoySmith (talk) 13:32, 3 September 2020 (UTC)

@RoySmith: See mw:Alternative parsers. I've used wtf_wikipedia before, and the API is pretty simple. Vahurzpu (talk) 16:21, 3 September 2020 (UTC)

Vahurzpu, Cool, thanks. I'll give wtf_wikipedia a shot, if only for the awesome name. -- RoySmith (talk) 17:09, 3 September 2020 (UTC)

@RoySmith: Do you actually need to do the parsing in JavaScript, or do you just need JavaScript to be able to get a parsed result? If the latter, consider using action=expandtemplates or action=parse in the MediaWiki API, or /transform/wikitext/to/html in the Parsoid API (this is how I designed WP:EPH, and I did it that way specifically because trying to parse myself led to the exact problem you're having now). Jackmcbarn (talk) 20:22, 3 September 2020 (UTC)

Jackmcbarn, I need to get the templates, and the template arguments. As far as I can see, action=parse will give me a list of templates, but just that a template exists, i.e.:

"templates": [
    {
        "ns": 10,
        "exists": "",
        "*": "Template:Sockpuppet"
    },

but not what the template arguments are. Am I just missing something? It seems obvious that there would be a way to get the template arguments, but I'm not seeing it. -- RoySmith (talk) 21:02, 3 September 2020 (UTC)

You can use prop=parsetree, and then deal with it in xml instead? —Cryptic 21:58, 3 September 2020 (UTC)

@RoySmith: If you want arguments, you almost certainly want Parsoid. That's exactly what EPH does; have a look at it. Jackmcbarn (talk) 01:31, 4 September 2020 (UTC)

Jackmcbarn, Yeah, the more I look at this, the more I'm convinced you're right, but man, what a strange way of doing things. The arguments in

{{sockmaster|blocked}}

and

{{sockmaster|1=blocked}}

parse totally differently ([7] vs [8]). -- RoySmith (talk) 01:53, 4 September 2020 (UTC)

@RoySmith: That's still MediaWiki's parser. Parsoid gives you much more sane parameters: {"1":{"wt":"blocked"}} for Jimchu23 and {"1":{"wt":"Viralvilla"},"2":{"wt":"proven <!-- blank/blocked/proven/confirmed -->"},"evidence":{"wt":"<!-- wiki link to alternate location of evidence if it's not on the master's SPI page -->"},"locked":{"wt":"no"},"notblocked":{"wt":"no"},"altmaster":{"wt":""},"altmaster-status":{"wt":"<!-- blank/blocked/proven/suspected -->"},"length":{"wt":""},"cat":{"wt":"<!-- Custom category name for the sockpuppet -->"}} for Ultrabone. Jackmcbarn (talk) 01:57, 4 September 2020 (UTC)

Jackmcbarn, What URL did you use for the above? I tried https://en.wikipedia.org/api/rest_v1/page/pagebundle/User:Ultrabone, which just gets me a not_found error. -- RoySmith (talk) 02:58, 4 September 2020 (UTC)

@RoySmith: I used https://en.wikipedia.org/api/rest_v1/page/html/User:Ultrabone. Jackmcbarn (talk) 03:02, 4 September 2020 (UTC)

Jackmcbarn, That gets the HTML. How did you get the JSON you showed above?

The documentation is baffling. this talks about routes with /v3 in them. this has a totally different set of routes. I'm assuming the later is machine-generated from the server's actual routing tables, so that's probably the correct one. Some of those routes (for example, the /html/ one you give above) work, but the /data-parsoid/ one doesn't. -- RoySmith (talk) 03:11, 4 September 2020 (UTC)

@RoySmith: That JSON was in the HTML, specifically in the data-mw attribute of the outer element. Jackmcbarn (talk) 03:59, 4 September 2020 (UTC)

Jackmcbarn, Wow. That's, um, a non-intuitive way to design this API. -- RoySmith (talk) 15:45, 4 September 2020 (UTC)

Hello,

I am wondering how to get rid of unwanted transclusions, for instance the page Relics of Sariputta and Moggallana has an transclusion in the first part of the Sanchi relics section, which makes no sense being there. I can't find anything in the code that would cause this so i am curious how to get rid of it. Wikiman5676 (talk) 06:46, 4 September 2020 (UTC)

@Wikiman5676: I'm not seeing any transclusion in that section. What specifically is transcluded? --Ahecht (TALK
PAGE) 13:15, 4 September 2020 (UTC)

@Ahecht: it's the subsection the says sanchi relics under the excavation of lost relics section. From "In 1851..." to the quote by cunningham that begins "Sariputra and Mahamoggallana...". If you try to select it via visual editor it will lump the texts together as a transclusion. Wikiman5676 (talk) 15:15, 4 September 2020 (UTC)

I don't use VE, but I can replicate this problem. Edit the section using this link, and it highlights the first paragraph of the "Sanchi relics" section along with the indented quote, using a gray background. There is a pop-up box overlaying the gray-highlighted area, with text that says: "Transclusion [new line] Generated from: Sfn, Sfn, Sfn, Sfn, Sfn, Sfn, Quote". The pop-up has an Edit button. When you click the Edit button, another pop-up window appears, allowing you to edit (some of?) the contents of the gray-highlighted area. It is bizarre. I don't see any errors on the page that would lead a parser to misinterpret this section. – Jonesey95 (talk) 15:53, 4 September 2020 (UTC)

@Jonesey95 and Wikiman5676: Inserting a line break before the {{quote}} seems to have fixed it (see Special:Diff/976720114). --Ahecht (TALK
PAGE) 16:05, 4 September 2020 (UTC)

Thanks! Wikiman5676 (talk) 16:59, 4 September 2020 (UTC)

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: [9] [10]. 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)

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)

Please whoever have a decision power here at Wikipedia don't let that design change happen. It is terrible, the limited width is very bad on large monitors. Making things very hard to read even with glasses. I've been searching for a couple of weeks now how I could remove it. I first though it was a bug and I landed on the mobile version. Then has it wasn't going away I though Wikipedia FR somehow got hacked. But no it seems it something on your part. At the moment I started to read Wikipedia in other languages to not suffer that design change. But if unfortunately it came to become a general change I don't think I would use Wikipedia as much as before as it would have become quite hard to read for me. - Sincerely a simple and concerned Wikipedia reader. — Preceding unsigned comment added by 87.231.14.108 (talk) 20:34, 30 August 2020 (UTC)

"the limited width is very bad on large monitors. Making things very hard to read even with glasses" That doesn't really make sense btw.. The size of the text is the same, so your ability to read with or without glasses, shouldn't depend on a constraint to width. The limited width should only affect those who want lots of very dense information. I advise anyone with difficulty reading to use the browsers zoom function btw.. It is awesome. ctrl + and ctrl - (or command + and command - if you are on macOS). —TheDJ (talk • contribs) 09:12, 31 August 2020 (UTC)

The reason it is bad is because of increased vertical scrolling, nothing to do with font size. — xaosflux ^Talk 18:58, 4 September 2020 (UTC)

Is there a magic word or some sort of function that returns the value of the line which it is placed? For example, if it were placed on the top line of an article, it would return the value "1". Steel1943 (talk) 16:49, 4 September 2020 (UTC)

@Steel1943: hmm, interesting. What would you be considering a "line" here though? (Anything before a "line break" is generated? - would a section header count?) — xaosflux ^Talk 17:15, 4 September 2020 (UTC)

@Xaosflux: Like the line number that shows up when looking at edit diffs or when editing modules. Steel1943 (talk) 17:17, 4 September 2020 (UTC)

To answer the question directly, no. It might be possible to do it, but it doesn't seem like something generally necessary that couldn't be done more directly using the same method. --Izno (talk) 17:32, 4 September 2020 (UTC)

• So, the reason I asked is I'm trying to write something that determines if it is on the top line of the page ... which is why I was hoping there would be a way to just grab the line number since that would obviously be "1" in this case. Steel1943 (talk) 17:47, 4 September 2020 (UTC)

Lua can do this by reading the unparsed wiki text and looking for the thing you placed there. So if you have a template, {{line marker}}, a lua module called by {{line marker}} can fetch text line-at-a-time and search each line for its parent template as a text string ({{line marker}}). cs1|2 uses something similar when it figures out how to format dates according to {{use xxx dates}} though it doesn't count lines. {{line marker}} then renders the line number returned from the lua module

—Trappist the monk (talk) 18:01, 4 September 2020 (UTC)

@Trappist the monk: That doesn't sound like it does what's being asked for. In particular, if you used {{line marker}} in two different places in a page, it wouldn't be able to tell which one it was being called from. Jackmcbarn (talk) 18:22, 4 September 2020 (UTC)

It was the simple example. If you want the third marker then write the template call with a key: {{line marker|3}} (key could be any plain text). When the module is invoked by that form of the template, it will look for a string that matches "{{line marker|3}}" (perhaps with allowance for whitespace ...). {{line marker}} isn't just an empty template.

—Trappist the monk (talk) 18:39, 4 September 2020 (UTC)

@Trappist the monk: Well okay, but now you have to use a unique key every time, and there's no way to generate one of those either. Jackmcbarn (talk) 18:50, 4 September 2020 (UTC)

Yeah, you do have to manually make sure that the keys are unique though I suppose the module could scan for duplicates as a modicum of error avoidance. Examples hard-coded to look for {{tlx|line marker}}:

{{#invoke:Sandbox/trappist the monk/what line|main}} → Found at line: 717 – as I write this in a section edit, this one reports line 8

{{#invoke:Sandbox/trappist the monk/what line|main|3}} → Found at line: 720 – this one reports line 11

Notepad++ agrees with the line numbers.

Presumably this #invoke could go inside another template and report the line number of that template (I haven't tried this so I don't know what hoops need jumping to make that work – I suspect that a mixture of positional and named parameters as keys would render this scheme unworkable because named parameters can be placed anywhere in the wikitext of a template).

—Trappist the monk (talk) 20:03, 4 September 2020 (UTC)

• A module could be derived from Module:Is infobox in lead. It scans the wikitext source to see if the named infobox is before the first heading. What sort of issue are you trying to test for? — GhostInTheMachine ^{talk to me} 18:10, 4 September 2020 (UTC)
  • I'm specifically trying to run a test to see if something is not on "Line 1", so I don't think any variation of that module would work since the module seems to check if it is placed before the first level 2 section header on a page, and I'm trying to get the test more precise than that. Steel1943 (talk) 18:41, 4 September 2020 (UTC)
    • Maybe the SD template might use a Lua module to see if the {{short description}} really is the first thing in the source. i.e. Test for something in front of it rather than thinking about line numbers. As an alternative, it might be "cheaper" to scan the sources held in a database dump to see if the short descriptions are at the top of their articles. — GhostInTheMachine ^{talk to me} 19:03, 4 September 2020 (UTC)
    • Strictly speaking, the {{short description}} does not need to be on line number 1 of the wikitext - it just needs to precede all other templates (in case one of those templates itself tries to set the SD). That seems a simple test to me and I do want an excuse to write some Lua. — GhostInTheMachine ^{talk to me} 19:17, 4 September 2020 (UTC)

      @GhostInTheMachine: Someone's been looking at my recent edits ... Steel1943 (talk) 19:47, 4 September 2020 (UTC)

@Steel1943: No, and one won't be added. The issue is that the Parsoid team wants to be able to cache pieces of parsed pages, so anything that detects where something is in the page, or what's before or after it, is out. And in fact, when people come up with clever ways to do that kind of thing anyway, the developers consider them bugs and remove them. Jackmcbarn (talk) 18:20, 4 September 2020 (UTC)

Jackmcbarn, this :D —TheDJ (talk • contribs) 18:24, 4 September 2020 (UTC)

• Oh, bullocks. Steel1943 (talk) 18:43, 4 September 2020 (UTC)

Special:ListUsers doesn't seem to support wildcards. I want to show a list of users with "foobar" in them (i.e., regex .*foobar.*). Can I just query the user table somewhere, or is there a special page or tool that supports wildcards? Thanks. —[AlanM1 (talk)]— 03:51, 5 September 2020 (UTC)

@AlanM1: You can use Quarry. Go to https://quarry.wmflabs.org/ and run select user_name from user where user_name like '%foobar%';. Warning: it will be slow (it took over a minute to return when I tried it). Jackmcbarn (talk) 03:55, 5 September 2020 (UTC)

@Jackmcbarn: Thanks! I did select user_name from user where user_name like '%chandandolui%'; and got two results: Iamchandandolui and Mr.chandandolui. I then did select user_name from user where UPPER(user_name) like '%CHANDANDOLUI%'; which ran for about a minute and returned no rows. I'm a little rusty but what am I missing? Shouldn't I get at least the same two rows? —[AlanM1 (talk)]— 04:18, 5 September 2020 (UTC)

Update: Asking at mw:Talk:Quarry. —[AlanM1 (talk)]— 07:53, 5 September 2020 (UTC)

(Or you could ask at WP:QUARRY here.) Most (all?) text is stored with case-sensitive collation, so LIKE is also case-sensitive. You can either use an explicit collation, like SELECT * FROM user WHERE user_name LIKE '%chandandolui%' COLLATE utf8_general_ci;, or use a case-insensitive regex search, like SELECT * FROM user WHERE user_name RLIKE '(?i)chandandolui';. Both show Chandandolui, Iamchandandolui, Mr.chandandolui, and Chandandolui1; the regex search is more flexible and about twice as fast.

Your attempt with UPPER() failed because user_name is a varbinary(255); see https://mariadb.com/kb/en/upper/ and DESCRIBE user. —Cryptic 10:02, 5 September 2020 (UTC)

@Cryptic: Thanks! The varbinary type did not occur to me. RLIKE is new to me, and very welcome. —[AlanM1 (talk)]— 11:20, 5 September 2020 (UTC)

I've looked all over I Hope You're Happy Now (Carly Pearce and Lee Brice song), and I can't figure out what's causing it to show up in Category: Pages using infobox song with unknown parameters. What unknown parameter has been inserted that I'm missing? Ten Pound Hammer • ^{(What did I screw up now?)} 04:16, 4 September 2020 (UTC)

@TenPoundHammer: It's format. You can see it by editing the page and previewing it. Jackmcbarn (talk) 04:22, 4 September 2020 (UTC)

In preview mode I see: "Warning: Page using Template:Infobox song with unknown parameter "format" (this message is shown only in preview)." At Template:Infobox song a search for "format" brings me to: "The format parameter has been removed as a result of the July–August 2020 talk page discussion. Any information entered in |format= will not be displayed." — JohnFromPinckney (talk) 04:27, 4 September 2020 (UTC)

Wow, that might be cause for a bot run. It filled the unknown parameters cat with nearly 50,000 titles. Raymie (t • c) 23:45, 4 September 2020 (UTC)

Yowsa. Maybe this is a chance for me to learn how (and where) to request bot operations. — JohnFromPinckney (talk) 01:07, 5 September 2020 (UTC)

@JohnFromPinckney: I'll send you to User talk:Primefac to have User:PrimeBOT do this. If it's implementing a discussion outcome, despite the very large article set, I doubt this would be seen as controversial. Raymie (t • c) 03:06, 5 September 2020 (UTC)

Interested editors may want to look at the template's talk page first. The discussion was attended by a small number of editors, and it is unclear to me (the person who eventually removed the parameter based on an edit request) whether the discussion was advertised. It would be unfortunate to have to reverse 50,000 bot edits if significant objections arise only after editors notice the parameter's removal. – Jonesey95 (talk) 13:40, 5 September 2020 (UTC)

The notice appears below the protection status. It's generally collapsed, barely visible, and I've only recently realised they're there at all–I usually just press X straight away, lots of words, and the first few about semi-protection are irrelevant, so who'd bother scroll down to read the rest? Can we get protection info either (ideally) (a) removed from that notice, or (b) placed below the page notice? For BLP articles especially, we should want the notice about BLP highlighted, not "this article has been configured with a mighty semi-protection setting by X for Y until Z on the time A [thank me!]". Or can we get it moved above, like the normal source editor? Can any of these be done locally, or do we need a Phab ticket for any of them? ProcrastinatingReader (talk) 11:24, 30 August 2020 (UTC)

@ProcrastinatingReader: can you provide an example page with this problem (an article would be best)? — xaosflux ^Talk 12:26, 30 August 2020 (UTC)

Xaosflux, a recent one I came across was Kenosha protests where there's constantly BLP violations, so making sure the notice is visible helps. It's not the most obvious since it only has one notice, but still an issue. On the larger Mac I'm using now I can see the notice in full, but on my 13" Mac I can barely even see the "Notice about sources" part until it cuts off, so how visible the issue is to you might depend on the device you're using. It's most visible, regardless of monitor, on articles like Donald Trump (due to long protection reason & multiple page notices). Where screen real estate is limited we should be prioritising the useful notices first, if you can kinda follow what I'm trying to get at? ProcrastinatingReader (talk) 12:43, 30 August 2020 (UTC)

@ProcrastinatingReader: so you'd want to move the protection message possibly to the bottom - if it is a protected page that you can edit --- however, I'm assuming this is still the most important notice if it is on a page you can't edit - since it tells you why you can't edit it; correct? — xaosflux ^Talk 13:46, 30 August 2020 (UTC)

Xaosflux, well, I don't think I can open up VisualEditor at all on a page I can't edit, so I don't think any exemption needs to be made for that case. Example: I found Kimberly Klacik, and indeed I can't open up VE at all on here. I can only see a "View source" button and the suggestion to submit an edit request (since you're (I)admin, I think you can only test this in incognito).

For pages I can edit, hence can open VE, what you say is mostly correct & is what I'm getting at. Really, I don't think the protection message should be shown at all on there, except maybe for full protection: the semi/ECP notices aren't helpful there, and anyway we have the coloured lock in the top right before one can click edit. But, if it really must be, then should be at the bottom of the notice list imo. If kept, the message should at least be cleaned up to look presentable. I think the eye naturally skims over that dumped log, especially in a view like VE, at least my eye does. ProcrastinatingReader (talk) 14:12, 30 August 2020 (UTC)

• I agree that the protection notices are meaningless here. Looking at Kenosha protests, as noted, you can't even get into the editor on a page you can't edit, so the only people who are ever going to see the semi-protected notice are people it doesn't apply to. And the stuff about the protection settings being moved are just noise; I can't think of any way having that information will help somebody edit the page. So, yeah, those two items shouldn't be there. -- RoySmith (talk) 14:20, 30 August 2020 (UTC)

  @RoySmith and ProcrastinatingReader: sure you can, try opening this link without being logged in (use a private browsing/incognito mode tab: link). (It is where you end up from viewing source with the visualeditor if you don't have edit access). — xaosflux ^Talk 14:28, 30 August 2020 (UTC)

  Xaosflux, sorry, I'm being a bit slow & blind I think, but where's the link to open VE? Whilst your direct link opens up, when I click "view source" I see this. I can't find a link to VE here? And even on your direct link I can't actually edit any words. ProcrastinatingReader (talk) 14:34, 30 August 2020 (UTC)

  At a closer look, the notices on the direct link look screwed. It repeats all the page notices twice (?), and it doesn't show the log entry but instead the "please make an edit request" notice. The direct link just looks bugged, tbh. ProcrastinatingReader (talk) 14:44, 30 August 2020 (UTC)

  Xaosflux, Well, OK, somebody could hand-craft a URL, but the most obvious way to get there is to click in the "Edit" link at the top of the article, but that turns into "Read" if you don't have permission to edit. If you wanted to cover this edge case, then the protection notices should only be shown to people who don't have write permission. -- RoySmith (talk) 14:41, 30 August 2020 (UTC)

• OK, lets break this down a bit :D Here is a rather clean page to use as an example: testwiki:VE-alert-testing1 (Direct link in to editing mode in debug mode: link). If I'm hearing you right, basically you'd like to move the order of precendence, in the visual editor page alerts, to place protection "warnings" such as (semiprotectedpagewarning) after the other edit notices. This is not managed locally, so yes would require a phab ticket and would be a global mediawiki change (or you could request that there is a per-project customization capability built). I don't think this is going to get general support though - the argument will need to be that a "page notice" is more important in general then a protection notice. Even here on enwiki, the proection notice is consider very important - for example it lets admins (who can edit through protection) know that they shouldn't be editing the page without a good reason. — xaosflux ^Talk 14:57, 30 August 2020 (UTC)

  Xaosflux, Re, it lets admins (who can edit through protection) know that they shouldn't be editing the page without a good reason, that's something I hadn't considered. Thanks for pointing it out. -- RoySmith (talk) 15:01, 30 August 2020 (UTC)

  Xaosflux, for example it lets admins (who can edit through protection) know that they shouldn't be editing the page without a good reason I agree for that niche case, i.e. pages full-protected due to dispute, and an admin might want to be aware of that before editing, & did hint at it above. Admins editing through full-protection is a very small % of edits, though, but certainly we could keep it shown for full-prot cases only. Even in those cases, there's still the golden lock in the top-right before clicking edit. With your test wiki example, for my eyes, the notice is dwarfed by the log message even when it isn't collapsed due to screen size. It just feels too routine, and hence doesn't demand attention. I think many editors are used to just clicking 'X' habitually. Some kind of per-project customisation capability would be nice. Even if the log message is to be kept, the ability to make it look... less convoluted... would be nice. ProcrastinatingReader (talk) 15:26, 30 August 2020 (UTC)

  @ProcrastinatingReader: hmmm - a possible option without doing too much change (still require a phab ticket) may be to let that logline (the entire ul element for it actually) be collpable and collapsed by default maybe. Do you think that would help? — xaosflux ^Talk 15:38, 30 August 2020 (UTC)

  Xaosflux, as in with like a [show] to the side? I think that's definitely a big improvement. As a side thought, given how well-designed and low-verbosity VE is, I do wonder how Design approved this in the first place. I do still think even the leftover sentence is too routine and verbose, though, and (since I doubt we'll be able to get the manpower to have them revisit at this issue twice) I'd like to find an easy-to-implement, low controversy, and customisable way to make this work fully off the bat. Ideally some way to either pop it into the config, or let local IAdmins customise it, would be neat. I'll take a flick at the code and ponder on the idea... Should seem doable since it's only the first .ve-ui-mwNoticesPopupTool-item (wholly containing the log entry) I'm trying to mess with, so the option of completely disabling per-project via config seems trivial, but then we'd need to work out something for full-protected-pages... ProcrastinatingReader (talk) 15:47, 30 August 2020 (UTC)

  Xaosflux, I bring good news. VE injects the editnotices in "includes/ApiVisualEditor.php", line 318. There's actually some good design here, because extended-confirmed is treat as "semi-protection" (see here), so it's easy to hide the semi and EC ones and still keep the full protections (and TE, and whatever else) for admins. So, the easy way with, I believe, no collateral is just to add a config param that doesn't add "semi-protected" editnotices. Few lines of code, might even make it through the Phab process sometime this year. The second idea is just to remove the first <div> using JavaScript locally, if it has a "semiprotectedpagewarning" div below it. Has to be JS (can't use CSS) because it's applied to the child object, and we'd have to remove the parent of that div. Both would do the trick. I'd prefer the latter because we can do it sooner, with the caveat that it requires JS, but so does VE so I don't think it's too big of an issue. Note, regarding the non-logged-in example you gave above, neither option will affect the niche case of crafting a URL, per line 277, users who can't edit the page (but see VE) are shown a separate notice, so this has no effect on them. Thoughts? ProcrastinatingReader (talk) 17:50, 30 August 2020 (UTC)

  @ProcrastinatingReader: if those have class wrappers, we could just display:none them locally right? — xaosflux ^Talk 19:14, 30 August 2020 (UTC)

  Xaosflux, kinda but, issue here is that non-first-child notices all have a border-top associated with them. If we just display:none it, it leaves the border-top from the page editnotice visible. For an idea, edit here and for the first child of .ve-ui-mwNoticesPopupTool-items set display: none, the line stays. Now if you remove the element completely, line goes. Pretty small detail, but... ProcrastinatingReader (talk) 19:28, 30 August 2020 (UTC)

  fwiw, the closest I've gotten with CSS is:

  #semiprotectedpagewarning, #semiprotectedpagewarning + ul {
    display: none;
  }
  

  And the JS solution being:

  mw.hook( 'wikipage.content' ).add( function () {
  	$('#semiprotectedpagewarning').closest('.ve-ui-mwNoticesPopupTool-item').remove();
  });
  

  ProcrastinatingReader (talk) 19:59, 30 August 2020 (UTC)

  @Xaosflux: following up, thoughts on the above implementations? ProcrastinatingReader (talk) 20:26, 4 September 2020 (UTC)

  @ProcrastinatingReader: preferably, this should be handled via a phab request, and not a js hack we have to run on every page load. — xaosflux ^Talk 21:55, 4 September 2020 (UTC)

  Xaosflux, is there some kind of file that adds the js on VE load only? Or is every page load the only option we have locally? ProcrastinatingReader (talk) 11:38, 5 September 2020 (UTC)

  Not that I'm aware of, and since it would be needed for ip users as well it would have to go in common.js - but server side (via a phab requests) perhaps those can be split, or tabbed, or at least reordered? — xaosflux ^Talk 22:20, 5 September 2020 (UTC)

I have had my signature set to display Papyrus font, which it did until today. I am guessing that Papyrus no longer displays for reasons other than Wikipedia settings (for lack of a better a term), but I am not technically adept, so I thought I would inquire here. I have "treat the above as wiki markup" checked. The markup code for my signature is:

<span style="font-family:Papyrus;font-size:14px;">[[User:Markworthen|Mark D Worthen PsyD]] [[User talk:Markworthen|(talk)]] [he/his/him]</span>

TIA - Mark D Worthen PsyD (talk) [he/his/him] 03:54, 6 September 2020 (UTC)

@Markworthen: That font makes it to the final HTML. Are you sure that your computer didn't lose the Papyrus font somehow? Can you see/use it on other websites or programs? Can you check what your signature here looks like from another computer? Jackmcbarn (talk) 04:02, 6 September 2020 (UTC)

I can see the signature above in the Papyrus font. It is working fine on my computer, in other words. – Jonesey95 (talk) 04:06, 6 September 2020 (UTC)

Good golly Miss Molly! You are absolutely correct. I quickly checked using Safari on my iPhone and, sure enough, my beautiful Papyrus signature appears in all its Egyptian elegance. ;^) Many thanks - Mark D Worthen PsyD (talk) [he/his/him] 04:08, 6 September 2020 (UTC)

So we have T132467 but it's 4 years old with no sign of progress. Looks like null edits to member pages fix this issue, though. Would it be allowable to just make up a bot that can make null-edits on all transclusions of a template, thus updating a category's members in hours rather than some arbitrary period of time when the job queue gets around to it? If so, would such a bot need a BRFA (since, well, the null edits wouldn't exactly show up anywhere?) ProcrastinatingReader (talk) 00:27, 6 September 2020 (UTC)

We had a null edit bot that seems to have disappeared. --Izno (talk) 02:19, 6 September 2020 (UTC)

Yes, Joe's Null Bot. Graham87 06:10, 6 September 2020 (UTC)

The best proposed approach I saw came up in the related T157670 and T159512. Legoktm was able to generate a report of "stale" pages and the last time they were edited. The proposal was to have a process or bot that null-edited pages based on that report, starting with the oldest pages, with the idea that no page would be stale longer than one month. – Jonesey95 (talk) 03:28, 6 September 2020 (UTC)

Looking at the article on Mustafa Kemal Atatürk, I notice that the abbreviation "c" to indicate "circa" for his year of birth appears at both of its two instances - lede and infobox - to display with a small dot preceding the c and a microscopic squiggle following it. I doubt this was intentional, but would have no idea how to fix it. If other users don't see this, maybe it's just my monitor? But all other characters display normally. This is Chrome on Windows 10. Milkunderwood (talk) 01:42, 2 September 2020 (UTC)

@Milkunderwood: Are you describing the effects of the <abbr> tag? If so, then it's supposed to be like that, to indicate that you can hover over it to see what it's an abbreviation of. If not, can you upload a screenshot of exactly what you see? Also, does it happen on other pages, like here "c." on this one? Jackmcbarn (talk) 01:51, 2 September 2020 (UTC)

In your reply example here I see exactly the same thing I first saw: a small dot, smaller than a period, level with the bottom of the letter "c", and a very tiny squiggle following the letter, again level at the bottom of "c". Milkunderwood (talk) 02:04, 2 September 2020 (UTC)

@Milkunderwood: Can you post a screenshot? Jackmcbarn (talk) 02:08, 2 September 2020 (UTC)

I can, but I only know how to screenshot fullscreen. If I hover, it does show me "circa". So those extraneous-looking marks indicate "hover here"? Milkunderwood (talk) 02:14, 2 September 2020 (UTC)

I'm not sure a full screenshot on this page is a good idea, and I don't particularly want to put my entire computer settings out in public. I'll take a break and see if I can figure out how to do a small shot of just what I'm seeing. Milkunderwood (talk) 02:18, 2 September 2020 (UTC)

I have my shot of what I see, but nothing will let me paste it here, either as png or pdf. Is there a special trick to that part? Milkunderwood (talk) 02:58, 2 September 2020 (UTC)

The "squiggle" is an optical illusion caused by the juxtaposition of two entirely different things - the period denoting an abbreviation appearing just above the gap between two of the dots from the dotted underline. Try using your browser's zoom-in feature to see what I mean. As for the screenshot, as noted in the box displayed whilst editing, if a screenshot would help you to describe the problem, please follow the directions at Wikipedia:Screenshots of Wikipedia. --Redrose64 🌹 (talk) 19:42, 2 September 2020 (UTC)

On my monitor, I have a line break in the lede between the c. and 1881 - which is confusing enough as it is. Better to just spell out the word "circa" and be done with it. Milkunderwood (talk) 03:20, 2 September 2020 (UTC)

• I also don't see the point of {{Circa}} template. On mobile and other contexts where there's no hover it's just a meaningless distraction and it's hard to see why we cannot use the full word. – Ammarpad (talk) 06:06, 2 September 2020 (UTC)

  MOS:CIRCA also suggests using just c. for circa. — GhostInTheMachine ^{talk to me} 07:13, 2 September 2020 (UTC)

@Milkunderwood: Is https://imgur.com/a/T7ubVt5 consistent with what you see? This is Chrome (version 84 on Windows 10) trying to be smart by interrupting the underline where it gets too close to letters. Because the underline is so short and spends most of its time almost touching the letter c, it is barely visible. This, that and the other (talk) 08:05, 2 September 2020 (UTC)

This sounds very much like Template talk:Abbr#Displaying strangely. --Redrose64 🌹 (talk) 19:08, 2 September 2020 (UTC)

Adding text-decoration-skip-ink: none; could fix this. Nardog (talk) 19:20, 2 September 2020 (UTC)

Only if the browser supports it. The text-decoration-skip-ink property has only been described in CSS Text Decoration Module Level 4 which was first published on 13 March 2018 and is still at the W3C Working Draft stage, hence is liable to be modified (or even completely removed) at any time. --Redrose64 🌹 (talk) 12:42, 3 September 2020 (UTC)

@Redrose64: It may not be appropriate as a site-wide style, but nowadays something like three quarters of web users use Blink-based browsers. Wouldn't it make sense to use it at least for this template as a tentative fix? Nardog (talk) 08:07, 6 September 2020 (UTC)

Many thanks for everyone's help and suggestions. Yes, https://imgur.com/a/T7ubVt5 is exactly what displays on my monitor. It's confusing by itself; but in the context of where it was placed in the lede at Mustafa Kemal Atatürk it was a real headscratcher. (But I still can't figure out how to post a screenshot here at Wikipedia. Different issue.) Milkunderwood (talk) 00:37, 3 September 2020 (UTC)

@Milkunderwood: As I noted in my post above, there are directions at Wikipedia:Screenshots of Wikipedia. --Redrose64 🌹 (talk) 12:44, 3 September 2020 (UTC)

Ah. I thought it might be a relatively straightforward and simple trick. But thanks. Milkunderwood (talk) 06:18, 4 September 2020 (UTC)

I used to get these but they went away. Now they are back. It's a pain because I have to then look at the history in a new tab to see if my edit has actually saved. This has happened twice today, both times my edit had saved. Doug Weller talk 15:56, 5 September 2020 (UTC)

I've had a couple of these in the past 24hrs. Literally only two (maybe three) out of 500+ edits, so I don't know what triggers it. Lugnuts ^{Fire Walk with Me} 07:10, 7 September 2020 (UTC)

A bunch of the lists linked by {{CanadaRadio}} use old sorting tricks with hidden spans (especially List of radio stations in Quebec) and have done so for more than a decade. I tried to convert these to use data-sort-value, but I couldn't figure out the regex to do it properly. Could someone assist? Raymie (t • c) 23:43, 4 September 2020 (UTC)

@Raymie: The frequency column sorts correctly for me, as long as you don't mind the AM stations being sorted higher than the FM ones (because the AM freqs are in kHz and all above 600, making them numerically higher than the FM freqs that are all below 108 MHz). That could be solved by adding sortkeys to the relatively few AM stations, preferably with a simple template that takes the frequency in kHz as a parameter and spits out the data-sort-value (parm/1000) and display value. Note there's one AM station that has both AM and FM freqs crammed into the field, which should probably just be split into two rows. I didn't look too carefully for other similar issues. —[AlanM1 (talk)]— 09:39, 7 September 2020 (UTC)

15:59, 7 September 2020 (UTC)

For your viewing pleasure:

• {{Party name with color}}
• {{Party name with colour}}

It goes without saying that one of these should be a redirect to the other, but these are actually different, apparently incompatible templates to make some sort of table row, both in use. I doubt it's a high priority, but I thought I'd just let technically-minded folks know in case someone feels like working on this. –Deacon Vorbis (carbon • videos) 22:34, 6 September 2020 (UTC)

Ideally the newer one should be merged to the older and functionality consolidated, but I see it's more developed than the older one. They also seem to be used in a slightly different way so probably it may not be easy merging, but I think it's worth doing. Templates should not differ based on trivial spelling difference like that. – Ammarpad (talk) 10:13, 8 September 2020 (UTC)

Any reason this can’t be sent to TfD? Editors there can figure out the technical feasibility of it. You’re not required to be able to merge yourself to nominate a discussion. ProcrastinatingReader (talk) 13:58, 8 September 2020 (UTC)

Oddities are happening today.

• Most notable to me personally, is that when I bring up any Wikipedia article, there's usually a one-line read-out at the top of the page that tells me who created it, when, how many revisions, etc. That still holds for the older articles. But today when I'm working the CSD candidates, if it's probably a new creation, it reads this "Unable to fetch revision data. 0 pageviews (30 days)"
• https://afdstats.toolforge.org/afdstats.py?name=Maile66&max=&startdate=&altname= has not been updating for me the last few hours. If I try to log in to https://wikitech.wikimedia.org/wiki/Portal:Toolforge, which I thought I was able to do, it tells me I'm giving the wrong user name and wrong password. Maybe I never could log in there - I don't remember. — Maile (talk) 22:46, 7 September 2020 (UTC)

The enwiki database replicas appear to be lagged by close to 21 hours. I've inquired on IRC, but predictably everyone is asleep. ST47 (talk) 05:23, 8 September 2020 (UTC)

I have asked on Phabricator. ST47 (talk) 05:40, 8 September 2020 (UTC)

The wikitech site is not a part of SUL. You need to create an account there to be able to log in. – SD0001 (talk) 06:46, 8 September 2020 (UTC)

• This is a consequence of some maintenance that is taking place on the databases. The DBAs expect the lag to be there for a few more days. This will affect any tools which use the enwiki database replicas. ST47 (talk) 17:06, 8 September 2020 (UTC)

Following up from this discussion, we'd like to redesign the file upload wizard so that it asks right off the bat whether you're uploading a free or non-free file, and sends you to Commons if you're uploading a free one. This would be much better than the current ordering, where the many people who are trying to upload a free file don't realize they should go to Commons until the third step, at which point they'll have to re-enter a bunch of information (and some may just give up, costing us an image we'd want).

There seems to be some JavaScript code behind the wizard, though, which I don't know how to edit. Does anyone more tech-savvy want to take a stab at this? Sorry if this isn't quite the right forum, but it's an important outstanding task. {{u|Sdkb}} ^talk 21:39, 8 September 2020 (UTC)

@Sdkb: The JS, which is at MediaWiki:FileUploadWizard.js, reveals the relevant boxes (hidden at the start with display: none; in the page's wikitext) and fills in the contents of boxes with inputs and such. If the intention is just to reorder things, I think you could just do that by editing the contents of Wikipedia:File Upload Wizard. --Yair rand (talk) 21:53, 8 September 2020 (UTC)

Yair rand, it's basically just a reordering, yes. It'll be slightly more complicated, though, because the form currently has the actual "upload" button in step three for people who ignore the advice to go to Commons (why do we even allow that?), and that'll have to be moved to what's currently step 2.

Overall, the file upload wizard probably needs a somewhat fundamental redesign, but I don't know where to go to get a group together to work on it (other than WP:WikiProject Usability, which is typically me talking to myself). Maybe we could borrow the design of the Commons wizard, which is much better? But tackling the big ordering problem will hopefully be much simpler than a full redesign, and it'll be a good start. {{u|Sdkb}} ^talk 22:04, 8 September 2020 (UTC)

[moved from proposal tab]

I’ve had bad user experiences (UX) while looking at Draft articles through the Visual Editor, which I use almost exclusively.

Instead of seeing the article itself, they’ll have massive templates that have to be scrolled through every time you want to see—let alone edit—the article.

In contrast, when I look at an article in main space that has a cleanup or AfD tag, it’s unobtrusive and minimized, and expands when you click on it. I think the various Draft tags should be likewise automatically minimized until they are clicked on. I think newer users especially would feel more comfortable continuing to improve the article if there wasn’t massive rejection tags atop them that have to be traversed every instance. Gleeanon409 (talk) 13:19, 18 August 2020 (UTC)

Gleeanon409, sounds reasonable to me. I'm not sure what the technical mechanisms at play are. {{u|Sdkb}} ^talk 19:06, 18 August 2020 (UTC)

Gleeanon409, could you please give me a couple of links to a "worst-case" draft, and a contrasting article with cleanup or AFD tags? I can file a bug report if the problem is in the VisualEditor instead of in the template design. Whatamidoing (WMF) (talk) 04:10, 20 August 2020 (UTC)

@Whatamidoing (WMF):,Dumb Show vs. Draft:Tor'i Brooks. Gleeanon409 (talk) 07:26, 20 August 2020 (UTC)

What needs to take place to make this happen? Gleeanon409 (talk) 12:46, 24 August 2020 (UTC)

@Gleeanon409, it looks like the problem is that the (very large) AFC box has several collapsed sections. When those are expanded, the whole thing is enormous. This can't be fixed in the visual editor, which treats all collapsisble content the same, and specifically uncollapses them (e.g., so you can make sure that you've added the correct navbox). But it might be possible to fix this in the template, using something like {{if preview}} to keep the content collapsed state. @Evad37, do you think that might work? Whatamidoing (WMF) (talk) 17:28, 24 August 2020 (UTC)

@Whatamidoing (WMF): Template:If preview doesn't work with visual editor - e.g. https://en.wikipedia.org/w/index.php?title=Template:If_preview/doc&veaction=edit shows the "when saved" values in the examples column, not the "when previewed" values. - Evad37 [talk] 01:16, 27 August 2020 (UTC)

Well, there goes that idea. Maybe we should take this to WP:VPT? Whatamidoing (WMF) (talk) 01:35, 2 September 2020 (UTC)

@Whatamidoing (WMF):, moved. Gleeanon409 (talk) 22:45, 8 September 2020 (UTC)

The guidance on embedding infoboxes (at Template:Infobox) says that, to have the title of an embedded infobox show up bold, it must be placed as a header. I want to use embedding on a set of infoboxes that have |autoheaders= enabled. Is there a way to specify that a specific header should always be displayed? Otherwise, the child will not display since it is assigned to a header field. Raymie (t • c) 23:47, 8 September 2020 (UTC)

What caused lists that have items that are listed horizontally to display incorrectly and have those items displayed vertically instead? A few minutes ago, the issue appeared on the Main Page and even in other articles. On the Main Page, bulleted lists had items that were displayed vertically. Even Template:COVID-19 pandemic data seems to have been affected, as all country names were shown in boldface, and the green box that was supposed to surround the documentation did not even display. LSGH (talk) (contributions) 07:30, 5 September 2020 (UTC)

Good question, I had the same problem. – Teratix ₵ 07:37, 5 September 2020 (UTC)

For about 15 minutes (~07:10 – 07:25 UTC), MediaWiki:Common.css failed to load. My Firefox console said

The resource from “https://en.wikipedia.org/w/load.php?lang=en&modules=site.styles&> was blocked due to MIME type (“text/javascript”) mismatch (X-Content-Type-Options: nosniff).

Nardog (talk) 07:38, 5 September 2020 (UTC)

I initially thought that the problem was with my browser, as it crashed and I needed to log in again. Other non-WMF sites were working perfectly fine. LSGH (talk) (contributions) 07:46, 5 September 2020 (UTC)

This is happening again right now. All https://en.wikipedia.org/w/load.php?lang=en&modules=site.styles&> returns is:

/* This file is the Web entry point for MediaWiki's ResourceLoader:
   <https://www.mediawiki.org/wiki/ResourceLoader>. In this request,
   no modules were requested. Max made me put this here. */

Nardog (talk) 14:04, 9 September 2020 (UTC)

...and it's gone. Nardog (talk) 14:06, 9 September 2020 (UTC)

Resolved

Could a grown-up please publish the sandbox version of the template. — GhostInTheMachine ^{talk to me} 09:35, 9 September 2020 (UTC)

I've got this one. – Jonesey95 (talk) 16:00, 9 September 2020 (UTC)

I use Firefox on Linux, with uBlock Origin. I use this rule to prevent accidental logged out editing, in the 2010 editor:

*##^#mw-anon-edit-warning ~ #editform .editOptions

This hides the "Publish" button and the edit summary field, and seems to stop Alt-Shift-S from working as well.

• Anything I'm forgetting? That is, any way to accidentally save a page that this won't cover?
• What works in your browser/OS/adblocker?
• Should we make a list, and link to it from ... somewhere ... privacy-conscious users are likely to read?

This would seem more proactive than suppressing IPs after the fact. Suffusion of Yellow (talk) 23:06, 7 September 2020 (UTC)

The following actions will save your edit:

• Alt+⇧ Shift+S at any time
• ↵ Enter when the focus is on any of: the Subject/headline box (when making a new section); the edit summary box (when editing an existing section); checkbox "This is a minor edit"; checkbox "Watch this page"; Publish changes
• Space when Publish changes has the focus

I don't know of other keyboard methods. --Redrose64 🌹 (talk) 23:18, 7 September 2020 (UTC)

If I go onto an edit page, and I've forgotten to log in, Wikipedia tells me I'm not logged in. I'm not sure I've understood what is the problem your solution addresses.Uporządnicki (talk) 00:07, 8 September 2020 (UTC)

Banner blindness. It's a common enough problem that it's mentioned specifically at WP:OSPOL. Suffusion of Yellow (talk) 00:47, 8 September 2020 (UTC)

Another option is to style the publish button to have distinct, non-default color. I use that myself, and the moment I see default blue color I know something is amiss. – Ammarpad (talk) 10:01, 8 September 2020 (UTC)

Or a simple solution is to change skin to anything but (spit) Vector, which will jarringly pop up when one gets logged out, since it's the default. Yngvadottir (talk) 19:34, 9 September 2020 (UTC)

Is anyone experiencing issues with the Wikipedia app? I have a Galaxy S10 and the articles are not loading. Only the images and the wiki-links show up. No text, no substance. -- Veggies (talk) 12:11, 9 September 2020 (UTC)

Apparently there is some instability on Parsoid, a component used for mobile app and the visual editor. Site Reliability Team is aware and working on it. Will update with a task or more info when I can.--JCrespo (WMF) (talk) 13:32, 9 September 2020 (UTC)

Anyone else finding Vis Ed is timing out? I'm having no trouble as long as I stick to source editing. —valereee (talk) 12:56, 9 September 2020 (UTC)

+1 Keeps on timing out. ~~ CAPTAIN MEDUSA^talk 13:16, 9 September 2020 (UTC)

screenshot ~~ CAPTAIN MEDUSA^talk 13:26, 9 September 2020 (UTC)

See above, apparently there is some instability on Parsoid, a component used for mobile app and the visual editor. Site Reliability Team is aware and working on it. Will update with a task or more info when I can.--JCrespo (WMF) (talk) 13:33, 9 September 2020 (UTC)

As far as I am told, visual editor and mobile app for the English Wikipedia should be back working normally, although some other languages and projects may still be affected. Please retry and report if it still doesn't work for you. --JCrespo (WMF) (talk) 13:38, 9 September 2020 (UTC)

The app still doesn't work for me. -- Veggies (talk) 16:52, 9 September 2020 (UTC)

Now it works. Mark as resolved for me. -- Veggies (talk) 21:30, 9 September 2020 (UTC)

I think I've figured out how to fix phab:T102286 and phab:T260500 while fiddling with my browser, but I want to test it further before submitting it for code review, which I've never done before. Is there a handy way to do this without, say, setting up a server and installing MW from scratch? (Or if someone with experience can do it on my behalf, that would also be great, the code is here.) Nardog (talk) 14:33, 9 September 2020 (UTC)

You can use https://patchdemo.wmflabs.org/ tool. It will require you submitting the change to code review first though, but I think it's still easier than setting up mw dev environment from scratch. – Ammarpad (talk) 07:09, 10 September 2020 (UTC)

I just noticed the new "Citations" button on the edit page. Not sure exactly what it does but when I click it I get an error popup: "Error: Citations request failed". RedWolf (talk) 16:57, 8 September 2020 (UTC)

@RedWolf: can you show a screen shot? Also what platform are you on (web, mobile web, mobile), what skin are you using, which editor are you using? — xaosflux ^Talk 18:22, 8 September 2020 (UTC)

@Xaosflux: error pop-up Web (FF 80), MonoBook, using the standard editor (not visual editor). RedWolf (talk) 18:57, 8 September 2020 (UTC)

RedWolf, do you have this gadget enabled ? Wikipedia:Citation_expander —TheDJ (talk • contribs) 20:32, 8 September 2020 (UTC)

@Xaosflux: Yes, citation expander gadget enabled. RedWolf (talk) 20:50, 8 September 2020 (UTC)

It's just being used a lot. I think it should be separated from Citation bot. Abductive (reasoning) 08:46, 10 September 2020 (UTC)

Seem to have ended up with a different image in the file to the one displaying on the page (but it is OK on my iPhone)Horatius At The Bridge (talk) 07:09, 10 September 2020 (UTC)

@Horatius At The Bridge: See Wikipedia:Bypass your cache. Nardog (talk) 08:36, 10 September 2020 (UTC)

Magic Many thanks Nardog Horatius At The Bridge (talk) 08:51, 10 September 2020 (UTC)

Several months have passed and the Medical cases chart template still suffers from a limitation of the mw-collapsible plugin. What is wanted is that toggles dynamically affect (based on their expanded, partial or collapsed states) their linked collapsible elements and sibling toggles, instead of the current "blind" toggling which creates the intersection of sets mess described in that talk page. I have checked all MediaWiki:*.js titles in MediaWiki and Wikipedia and found no JS which implements a similar functionality. Since such feature sounds so useful and basic/"core", I wondered if its absence was due to some kind of policy against JS which improves the visualization of content in specific templates. If there was nothing against it and safety guidelines were followed, would a .js page creation request from a non-admin possibly be accepted? Alexiscoutinho (talk) 00:13, 2 September 2020 (UTC)

@Alexiscoutinho: so basically the problem is that there is not a way for a page or template to "call a javascript" (at least not until phab:T8883 or phab:T63007 ever get done) - so the only way to have a local script run is to have it run on every page load (several ways to do that - but all have that affect). The best way to get a new table handler would be to place a enhancement request on phab. — xaosflux ^Talk 02:28, 2 September 2020 (UTC)

@Xaosflux: I agree, but in the meantime, as a workaround, the Load JS and CSS by URL snippet could be used. If the script gets good and robust enough, then it would make sense to merge it as an extension into the plugin itself. I just wanted to be sure that putting work on a JS that alters the event handlers, data parameter and so on of custom collapsible content wouldn't go to waste by an obscure policy... By the way, do you know where (in which source code) is makeCollapsible initially called to configure all mw-collapsible elements? I know Common.js calls it for a deprecated collection, so there should be at least another call buried in MediaWiki core. Also, are the hook handlers run in the exact order in which they are added/registered to the wikipage.content event? Alexiscoutinho (talk) 03:51, 2 September 2020 (UTC)

Alexiscoutinho, the mw-collapsible code is initiated by the mediawiki.page.ready core module. The code itself is in the jQuery.makeCollapsible core module. A postprocessing hook (which implements autocollapse and innercollpase is in MediaWiki:Common.js at the mwCollapsibleSetup function. "are hook handlers run in the exact order in which they are added/registered to the wikipage.content event?" Yes, but that registration order is asynchronous so there is no guaranteed order in the registration fase. —TheDJ (talk • contribs) 09:11, 2 September 2020 (UTC)

@TheDJ: Thank you! I didn't think that there was a github behind the API documentation. Alexiscoutinho (talk) 12:58, 2 September 2020 (UTC)

Alexiscoutinho, the GitHub is a mirror of our gerrit repos. But they are easier to browse/search at times. —TheDJ (talk • contribs) 13:22, 2 September 2020 (UTC)

TheDJ, is it possible to remove the handler that calls makeCollapsible in ready.js before it is first run? Not only is the handler outside my scope but it is an anonymous function... Removing it would help my testing since I would be able to process in my way and step-by-step the collapsible content without it already starting pre-processed by the default makeCollapsible. Alexiscoutinho (talk) 23:12, 2 September 2020 (UTC)

Alexiscoutinho, no this happens pretty early in page initialization, earlier than you can reach from a userscript. —TheDJ (talk • contribs) 07:47, 3 September 2020 (UTC)

TheDJ, is it bad to store information that is internally used by the plugin in jQuery's data object? I.e. the list of collapsibles and sibling toggles affected by a custom toggle. Should I only store information useful for an external user, like utility functions? Alexiscoutinho (talk) 22:52, 5 September 2020 (UTC)

Alexiscoutinho, no, that is not bad in itself. The collapsible module does it actually. However, in general you would avoid it, as it is faster to store and retrieve information in function scope of an instance of code that is being used somewhere. But the make collapsible plugin is a bit old, so it probably doesn't adhere fully to such criteria. An example of scoped storage would be the cache variable in the table initialiser of the tablesorter plugin. —TheDJ (talk • contribs) 07:48, 8 September 2020 (UTC)

@TheDJ: Also, should event handlers be somehow implemented to run in parallel as far as possible across Wikipedia or at least in the makeCollapsible plugin? Alexiscoutinho (talk) 14:41, 6 September 2020 (UTC)

No. experience has shown that this creates a huge processing peak, which is annoying for many users. Especially when dealing with HTML of content, simply process sequential from top to bottom. —TheDJ (talk • contribs) 07:48, 8 September 2020 (UTC)

TheDJ, I followed your advice and finished my changes to makeCollapsible. My code is here and it also contains an "unmaker" to bridge the behavior change. I also created a task (phab:T262622) following Xaosflux's suggestion. Alexiscoutinho (talk) 23:02, 10 September 2020 (UTC)

Can't the radio-button thing seen in infoboxes for places (MediaWiki:Gadget-switcher.js) be employed to achieve this? Nardog (talk) 07:32, 2 September 2020 (UTC)

I don't know which radio-button you are talking about. Could you show a template where it is used? However, it wouldn't make sense to add any radio-button to the Medical cases chart template. Furthermore, the modified toggle event handling would have to be implemented somewhere and MediaWiki:Gadget-switcher.js doesn't do that. Alexiscoutinho (talk) 12:58, 2 September 2020 (UTC)

@Alexiscoutinho: Just look up a place, e.g. Warsaw. Nardog (talk) 16:16, 2 September 2020 (UTC)

@Alexiscoutinho: Check this out (source/CSS):

Nardog (talk) 03:32, 3 September 2020 (UTC)

@Nardog: Cool, but it seems just too limited. In the current state, that demo does not cycle between on and off if just one button is pressed consecutively. The "Show all" button doesn't highlight all tabs. Would initial collapsed states work? And last but not least, how would you go around internally representing partial states for the buttons (which would look like dashed outlines)? If you can show that your method works for a table with 2 buttons and 4 rows, where the 1st button covers/toggles the first 3 rows and the 2nd button covers the last 3 rows, and the third row is initially collapsed, and the button states (based on how many of their "children" are being displayed) are always accurately shown by their outline, I would be amazed and could even use it! Alexiscoutinho (talk) 04:40, 3 September 2020 (UTC)

Any searches I run (for things that don't explicitly match an article title) give me the error: "An error has occurred while searching: Search is currently too busy. Please try again later." on at least 9/10 attempts. I just noticed this a few minutes ago. Is this really something that might happen and should be ignored, or does this possibly indicate a problem? –Deacon Vorbis (carbon • videos) 16:56, 11 September 2020 (UTC)

Same for me. Kaldari (talk) 17:16, 11 September 2020 (UTC)

I decided to look at the earliest versions of Empire State Building. Look at the number of bytes changed in the third version.— Vchimpanzee • talk • contributions • 20:11, 11 September 2020 (UTC)

There was some weird glitch back then. At one point every edit to September 11 attacks seems to have resulted in a loss of over 100,000 bytes.— Vchimpanzee • talk • contributions • 20:21, 11 September 2020 (UTC)

Both very likely a result of Graham87's imports from nost:, the same way the byte counts get confused when you do a history merge or split. —Cryptic 20:29, 11 September 2020 (UTC)

Yes, this is T114806, which was not fixed retroactively. Also see T38976. Graham87 08:33, 12 September 2020 (UTC)

I've recently written two scripts, User:Ritchie333/wirblps.py and User:Ritchie333/unlinkedblps.py, which populate User:Ritchie333/Unreferenced women BLPs and User:Ritchie333/Unreferenced and unlinked BLPs. These are used by Wikipedia:WikiProject Women in Red to track and fix various BLPs without sources.

In the past, Galobtter has integrated some of my scripts into his bot, but he's not available right now. I could set my own bot up, but it just seems like a lot of hassle for something that is going to run at most every hour, and write to a maximum of two pages, both in my userspace. Can anyone else help? Ritchie333 ^{(talk) (cont)} 10:35, 11 September 2020 (UTC)

A better way to establish the gender is to use the linked wikidata item rather than look for gendered categories which are unlikely to exist in many cases. Looking at the ORES articletopic classification is another way. You should put content=True parameter in calls to CategorizedPageGenerator which would speed up the script a great deal (and simultaneously makes it mw:API:Etiquette-compliant - fetching a number of pages together in a single API call is preferable). Also, use {{annotated link}} template rather than dumping a rawlist, so that the short descriptions are visible.

I can commit to this after a few days when I get time, if no one beats me to it. – SD0001 (talk) 14:00, 11 September 2020 (UTC)

@Ritchie333: Did you try WP:BON and/or WP:BOTREQ? --Redrose64 🌹 (talk) 15:50, 12 September 2020 (UTC)

Can anyone find a fix for the ridiculously tall square-root and brackets in this:

${\displaystyle u=F\left(\left.\operatorname {sn} \left({\frac {p}{n}}K(\kappa )\right|\kappa \right){\sqrt {\left.{\dfrac {1+x}{x+2\operatorname {sn} ^{2}\left(\left.{\dfrac {p}{n}}K(\kappa )\right|\kappa \right)-1}}\right|\kappa }}\right)}$

It appears that the height is being calculated as if the numerator and denominator inside the square root are the same height, which clearly they are not. More sensible results if the p/n element in the numerator (the tallest bit) isn't there,

${\displaystyle u=F\left(\left.\operatorname {sn} \left({\frac {p}{n}}K(\kappa )\right|\kappa \right){\sqrt {\left.{\dfrac {1+x}{x+2\operatorname {sn} ^{2}\left(\left.pK(\kappa )\right|\kappa \right)-1}}\right|\kappa }}\right)}$

Thanks SpinningSpark 13:40, 9 September 2020 (UTC)

Never mind, I worked it out myself, the final bar was supposed to be outside the sqrt

${\displaystyle u=F\left(\left.\operatorname {sn} \left(\left.{\frac {p}{n}}K(\kappa )\right|\kappa \right){\sqrt {\dfrac {1+x}{x+2\operatorname {sn} ^{2}\left(\left.{\dfrac {p}{n}}K(\kappa )\right|\kappa \right)-1}}}\right|\kappa \right)}$

but I'm still not sure why that was messing up the heights. SpinningSpark 14:17, 9 September 2020 (UTC)

I think this would be a job for \smash ...which is yet another bit of TeX that's not supported. Otherwise, it just seems to choke a little when the stretchable delimiter sizes get too large and it's desperately trying to keep trailing text centered with the fraction base line. (Note it looks fine if you take out the kappa). I've certainly seen this happen in other sorts of formulas, and you can try to rewrite the formula so it's not an issue (ec, already done apparently), but otherwise, there's not much we can do from this end. Maybe Debenben might know a little more? –Deacon Vorbis (carbon • videos) 14:23, 9 September 2020 (UTC)

Actually, in this case it was due to invalid formatting. The bracket was opened outside the square root, but closed inside it. It just was not obvious because the opening bracket was an "invisible" one. I'm surprised it rendered at all. SpinningSpark 17:34, 9 September 2020 (UTC)

I am not sure why the height calculation is that way but it is correct because in LaTeX it is the same. Things like \smash and \llap would be nice to have, those TeX commands work fine in MathJax. @Physikerwelt: --Debenben (talk) 16:39, 12 September 2020 (UTC)

Moved from Wikipedia:Village pump (miscellaneous) § Draft pages turning up in a Google search

Question: I recently speedy deleted several drafts per G3 as hoaxes. In doing a BEFORE search at Google I was surprised to find that the drafts turned up in a Google search. I thought drafts were not supposed to be indexed? -- MelanieN (talk) 20:55, 12 September 2020 (UTC)

For specific examples: two of the drafts that turned up in a Google search were Draft:Discovery (Christina Aguilera album) and Draft:Dayanithi. -- MelanieN (talk) 20:59, 12 September 2020 (UTC)

How old were the drafts? Adam9007 (talk) 21:02, 12 September 2020 (UTC)

May 2020 and October 2018. -- MelanieN (talk) 22:24, 12 September 2020 (UTC)

The latter was speedied in April 2019, and not recreated until 9 September 2020.

I don't suppose there's any chance what you saw was a google hit of a transclusion of one of these drafts on another page, rather than the draft itself? Or maybe a redirect from an indexed namespace to the draft? Not that I see any edits like those in the contribs or deleted contribs of any of the editors of those pages (except perhaps the speedy tagger, who I didn't check); I'm just kind of grasping at straws at this point. —Cryptic 22:30, 12 September 2020 (UTC)

This came up a few months ago. Google has been indexing the page titles but the page text shouldn't be displaying in results. Is it? --Izno (talk) 01:06, 13 September 2020 (UTC)

Moved from Template talk:Side box § Width seems slightly off

 – {{u|Sdkb}} ^talk 02:13, 14 September 2020 (UTC)

I noticed here that the Wikisource template (which ultimately relies on Template:Side box) is slightly wider than the normal thumb images. Would it be possible to adjust the width to bring them into alignment? {{u|Sdkb}} ^talk 19:33, 12 September 2020 (UTC)

The display size of thumb images is subject to preferences (and presumably site-wide settings). The size of side boxes, in this case 238px, seems to be determined by some classes, so it seems impractical and probably futile to harmonize them. -- Michael Bednarek (talk) 05:03, 13 September 2020 (UTC)

Michael Bednarek, it's true that users can change their preferred thumb image display size, but 99.9% of readers never do so, so it's of very little pertinence. I'm not fully familiar with classes; could you clarify what'd make it impractical to change them? {{u|Sdkb}} ^talk 01:36, 14 September 2020 (UTC)

Like you, I'm unfamiliar with the way classes in Wikipedia operate. Where are they defined? Who defined them? Is there a process to get community input in their creation or modification? That's why I called it impractical. Maybe WP:VPT is a better venue to raise this. -- Michael Bednarek (talk) 01:45, 14 September 2020 (UTC)

Sounds good; I'll move this there. {{u|Sdkb}} ^talk 02:11, 14 September 2020 (UTC)

The class that controls the size of the Wikisource box is .mbox-small. It's defined in the common CSS file (line 819), and has a default width of 238px (contrary to the default thumbnail width of 220px). Since the way thumbnails are displayed also change per skin, the template can be smaller than thumbnails in other skins (e.g. Timeless (test)). As far as I am aware of though, no magic word provides the user's preferred thumbnail width, which would be needed in order to set the size of {{Side box}} to the user's preferred size (which would be done by setting the template width to the preferred thumbnail size through the style attribute, like how thumbnails do now.) That unfortunately means we'll have to stick with the differences in width, unless we can somehow get the width of the thumbnails. This, of course, doesn't factor in some accessibility issues that doing this might have, which I can't comment on since I'm not well-versed in accessibility-focused web design. Chlod (say hi!) 02:51, 14 September 2020 (UTC)

16:18, 14 September 2020 (UTC)

Hey there! :)

Is someone free to help me a bit to combine two find and replace regular expressions into one? I need that for a bot I'm using in a wiki but I'm a bit new to regexes. To not over clutter this section, we can hold the conversation at a user talk page (either mine's or another's) so just tell me below and I'll write to you (or you write to me). Thank you in advance! :) - Klein Muçi (talk) 09:42, 13 September 2020 (UTC)

Klein Muçi: You're honestly better off just saying what you want to do here so that you get more eyes on it. No one worries about clutter; just put it up here.--Jorm (talk) 15:25, 13 September 2020 (UTC)

@Jorm: okay then, if you insist... :P

So I have a table like this in Notepad++:

Klein Muçi, for the future, it can be handy to make use of something like: https://regex101.com to build your regular expressions and to easily see what parts match what content for which reason. —TheDJ (talk • contribs) 07:08, 14 September 2020 (UTC)

I want to be able to go from:

aa: Afar

ab: Abkhaz

ae: Avesta

af: Afrika

ak: Akan

(many more entries)

to:

"\|\s*language\s*=\s*Afar\b" "|language=

"\|\s*language\s*=\s*Abkhaz\b" "|language=

"\|\s*language\s*=\s*Avesta\b" "|language=

"\|\s*language\s*=\s*Afrika\b" "|language=

"\|\s*language\s*=\s*Akan\b" "|language=

(many more entries)

in one step instead of two. I'm assuming that's possible. How do I do that? - Klein Muçi (talk) 16:15, 13 September 2020 (UTC)

I think I'm confused. You have a file with lines "xx: Yyyyyy"; and you want them into an escaped format? Probably better to show me one line that you have and then line you want it to look like. The way I'm understanding your example is trivial and shouldn't require two regexes to make it.--Jorm (talk) 16:23, 13 September 2020 (UTC)

This?

Find: [a-z]{2,3}:\s*([^\n\r]+)

Replace: "\\|\\s*language\\s*=\\s*$1\\b" "|language=

doubled \ in the replace required in my copy of notepad++ may not be required in awb or some other regex tool.

—Trappist the monk (talk) 16:26, 13 September 2020 (UTC)

The F&R regex Trappist gave above works perfectly. Can you explain to me the specific function of its components? - Klein Muçi (talk) 16:53, 13 September 2020 (UTC)

Klein Muçi, "any alpha character ([a-z]), 2 or 3 times ({2,3}), followed by a colon (:), and then 0 or more whitespace characters (\s*), and then gruop the word to the end of the line into a variable (take everything from that point on to the end of line". Putting things inside of parens creates a variable to be used next, and they are addressed like $1, $2. Jorm (talk) 17:13, 13 September 2020 (UTC)

TheDJ I tried that page before coming here but I just couldn't create the logic for the expression that I was looking for. I'd really like it if we had a page that creates regex-es for us according to our description but, alas, my wish won't come true anytime soon. Jorm why "2 or 3 times"? - Klein Muçi (talk) 10:12, 14 September 2020 (UTC)

{2,3} means 2 or 3 times. Jorm said as much. You may find this detailed cheatsheet on regex syntax useful. – SD0001 (talk) 19:11, 14 September 2020 (UTC)

Assuming the characters before the colon in your example are language codes, the commonly used ISO 639-1 and 639-2 language codes use two or three letters. If your data has different characteristics, then you can adjust the count accordingly. isaacl (talk) 23:55, 14 September 2020 (UTC)

If you are interested in the opposite—turning a regular expression into a text description of its components—I suggest looking at the regular expressions 101 site. (There are other ones out there.) isaacl (talk) 00:00, 15 September 2020 (UTC)

This is kind of expanding on the idea on a blacklist for RedWarn and other automated tools. But what we know is clear: you must use the Wikipedia API within Wikipedia policies or risk being blocked from editing.

Because it is easy to have a blacklist circumvented with modifications of a code or by using a different tool to achieve disruption, I suggest implementing something that blocks POST API calls only (maybe as part of m:Partial blocks). That way, the partially blocked editor can continue to edit Wikipedia with our web forms, etc., but cannot use any external tools or programs or gadgets to make edits, forcing them to go slow. Aasim 04:36, 15 September 2020 (UTC)

You'll be surprised to find out that VisualEditor uses the same API that all tools use. There is no private backend for on-site tools like VisualEditor. Unless we have each tool identify themselves in the API call, this is impractical. Even if we had each tool identify themselves and block depending on the identification, anyone can just circumvent that by using whatever VisualEditor uses in order to falsely identify yourself as a user of the VisualEditor. And if you only wanted to block a user from a specific tool, you could have just used that tool's own blacklist. Even if we were able to do API-level blocks (assuming that it's possible), anyone can just use a custom script to automate the process of editing an article. And of course, we can't even such achieve extreme levels of disruption unless the given user can bypass edit filters and at the same time evade blocks, since they'd most likely be blocked on sight for disruptive editing. Chlod (say hi!) 04:50, 15 September 2020 (UTC)

Awesome Aasim, just block people who don't abide by the rules. —TheDJ (talk • contribs) 08:34, 15 September 2020 (UTC)

How do I retrieve the number of pages in a category and all of its subcategories? Neither {{Category count}} nor {{PAGESINCATEGORY}} seem up to the task, since they each count subcategories as only one item within the category. {{u|Sdkb}} ^talk 05:03, 14 September 2020 (UTC)

PetScan may be able to help, as long as the count is not too high. This search shows the templates in Category:CS1 errors and its subcategories, three deep. You may be able to modify it to get what you want. – Jonesey95 (talk) 05:13, 14 September 2020 (UTC)

Jonesey95, I'm looking to retrieve the total number of lists on Wikipedia for the WP:Featured lists intro (analogous to the WP:FA intro), so a one-time PetScan result unfortunately won't help since it doesn't update. {{u|Sdkb}} ^talk 05:34, 14 September 2020 (UTC)

There's no way to get a dynamically updating figure (save for a bot updating the figure on the fly using the result from petscan). – SD0001 (talk) 08:26, 14 September 2020 (UTC)

SD0001, hmm, oh well. Do we even know how to get a one-time count of the number of lists on Wikipedia? The PetScan query I made starting from Category:Lists didn't work since there must be a "leak" somewhere in the tree. And WikiProject Lists claims far fewer featured lists than WP:FL, so there must be a bunch of untagged pages (which is a little concerning for featured content). {{u|Sdkb}} ^talk 19:39, 14 September 2020 (UTC)

The {{Category count}} template uses {{PAGESINCATEGORY}} to obtain its figures. {{PAGESINCATEGORY}} is not a template but a parser function, and cannot go more than one level deep. As far as plumbing a category's depth is concerned, you need some kind of limit in case of category loops. The tightest possible loop is one level, and there are normally just four categories that are immediate members of themselves - any more than four indicates an error somewhere. The four are:

• Category:Hidden categories (36,883)
• Category:Noindexed pages (2,770,519)
• Category:CatAutoTOC generates Large category TOC (0)
• Category:Template Large category TOC via CatAutoTOC on category with 2,001–5,000 pages (0)

The first two are intentional, the second two are because of the way that they're constructed. --Redrose64 🌹 (talk) 20:47, 14 September 2020 (UTC)

Actually it turns out there were 12 more such cats containing themselves !  Fixed – SD0001 (talk) 04:55, 15 September 2020 (UTC)

@SD0001: I should have mentioned that they're reported (roughly) weekly at Wikipedia:Database reports/Self-categorized categories. --Redrose64 🌹 (talk) 12:33, 15 September 2020 (UTC)

@Redrose64: Cool. BTW you may be interested in the discussion at Wikipedia:Village_pump_(idea_lab)#Killing_cats. – SD0001 (talk) 14:28, 15 September 2020 (UTC)

I'm sure the solution to this is simple, but it's outside of the info I have in my head. There's an empty footnote (currently number 5) in the Sariaya article. It is being caused by the line in the infobox reading: | elevation_footnotes = {{PH wikidata|elevation_footnotes}}. Wtmitchell (talk) (earlier Boracay Bill) 16:02, 15 September 2020 (UTC)

I suppose this line is the problem in {{PH_wikidata}}:

| elevation_footnotes = <ref>{{safesubst:#invoke:wd|reference|raw|P2044}}</ref>

When there is no reference it still passes the empty ref tags. It needs to put the reference in an if statement checking the reference. —  Jts1882 | talk  16:35, 15 September 2020 (UTC)

It seems as if you're saying that there is a problem either in {{infobox settlement}} or in specifying the content for elevation_footnotes as that infobox is used in the Sariaya article. I looked at the docs for that infobox and didn't see an answer; there's a commont on that parameter in the source for that infobox template which says, "for references: use <ref> tags", but I'm not sure what that is trying to tell me. Could you clarify this enough for me to figure out whether I need to follow this up on the article talk page or the talk page for the infobox template? Wtmitchell (talk) (earlier Boracay Bill) 22:30, 15 September 2020 (UTC)

(added) On further thought, it seems as if there is a problem with putting a {{wd}} invocation inside of a <Ref> because it might return an empty string -- which is sort-of what you said. However, from the viewpoint of the article editor, that is too far down in the weeds to be expected that it will be understood. If I'm right about that, I still don't see where I ought to follow this up. Perhaps there is a template somewhere which checks a string and, if it is empty, replaces it with an appropriate {{error}} (???). Wtmitchell (talk) (earlier Boracay Bill) 23:11, 15 September 2020 (UTC)

(added) Or maybe there needs to be a template named something like {{footnote|group=group|name=name|content}} which generates a <Ref> if content is not empty and does nothing if it is empty -- but that should be discussed someplace more appropriate than here (where?). Wtmitchell (talk) (earlier Boracay Bill) 23:41, 15 September 2020 (UTC)

{{PH wikidata}} should check for content in that Wikidata item before displaying <ref>...</ref> tags. I recommend opening a discussion at Template talk:PH wikidata. (Edited to add: I have started a discussion there.) – Jonesey95 (talk) 00:07, 16 September 2020 (UTC)

Sorry for not being clearer . What I meant, as Jonesey says, is that the Wikidata value needs checking before adding the reference tags. Something like:

| elevation_footnotes = {{#if:{{#invoke:wd|reference|raw|P2044}}
                        |<ref>{{safesubst:#invoke:wd|reference|raw|P2044}}</ref>
                        |}}

The spaces might need removing. —  Jts1882 | talk  07:39, 16 September 2020 (UTC)

 Done It fixes the problem at Sariaya and other places like Manilla, but I can't find an example with an elevation to check it is working when Wikidata has a value. —  Jts1882 | talk  08:15, 16 September 2020 (UTC)

I suppose I should walk through this. Robert le diable leads off with an image of Act III in its infobox. However, if viewed on the mobile site, the infobox - and image - disappears completely. What's going on, and if it's possible for the mobile site to remove elements, is it possible to provide an alternative (such as a thumbnailed image) for on the mobile site? Adam Cuerden ^(talk)_{Has about 7.5% of all FPs} 22:13, 16 September 2020 (UTC)

It's not an infobox. It's a box that uses {{Composer navbox}}, which in turn uses {{sidebar with collapsible lists}}, which, according to its documentation does not display in the mobile view of Wikipedia. I'm pretty sure that all normal sidebars and navboxes are hidden in the mobile view. Someone else will have to answer the "display alternative image on mobile" question. – Jonesey95 (talk) 22:28, 16 September 2020 (UTC)

That is because the infobox is actually a sidebar, which are known to be removed on mobile. I am somewhat skeptical that fact should change since it is predominantly about the links provided, so that means that the image should perhaps be moved out of the sidebar, as images for sidebars are intended to be decorative in most cases. --Izno (talk) 22:29, 16 September 2020 (UTC)

The trouble with that is the concept of "lead image" conflicts with the idea that an infobox should be the first thing on a page. It's pretty darn common for - as an example - a short species article to put its only picture in the infobox, e.g. Xenops. The images are not being used solely for decoration, and I don't think that's ever been true. Adam Cuerden ^(talk)_{Has about 7.5% of all FPs} 00:45, 17 September 2020 (UTC)

My point is that this case is not an infobox, it is a sidebar. If you want to image to show, you should take it out of the sidebar and make it a lead image. Most sidebars have decorative images. Most infoboxes do not. (Perhaps a discussion of interest.) --Izno (talk) 01:42, 17 September 2020 (UTC)

I'm trying to develop a dark mode color palette for the vector skin and am having trouble setting the color for visited interwiki and external links. Also, I'm having trouble changing the color palette for the text in the sidebar. (The WIP is available at User:LaundryPizza03/nightvector.css. The colors for interwiki and external links, visited and unvisited, should be the same as for internal links.) –LaundryPizza03 (dc̄) 08:28, 14 September 2020 (UTC)

Another question that was redirected from the idea lab: The dark mode has white text on a black background; the colors of links are also changed for legibility. I noticed that various templates with a colored background make the text illegible. I was wondering if a module could be implemented to adjust the template's colors to match the user's default text color, or if the text in such templates should default to black. Alternatively, is there a way to work around this issue? –LaundryPizza03 (dc̄) 05:35, 17 September 2020 (UTC)

Apologies if this is not the appropriate place to ask about Edit count. I've looked around and couldn't find a better place to do so. As far as I can see, Edit count has not been working for at least 24 hours. Is that so? Thanks. Misha Wolf (talk) 19:19, 8 September 2020 (UTC)

Misha Wolf, It's working for me. What happens when you try it? -- RoySmith (talk) 19:23, 8 September 2020 (UTC)

The field "Edits in the past 24 hours" shows "0", though I have made 5 edits in that period. Other stats are wrong too. For example, page https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Talk:ISO_4217 states that my "Latest edit" of Talk:ISO_4217 took place on/at 2020-09-04 20:28. In reality, I have made 7 edits to that page since that date/time. Thanks. Misha Wolf (talk) 19:32, 8 September 2020 (UTC)

As mentioned just above, this is because the toolforge database replicas are lagged due to ongoing maintenance. ST47 (talk) 19:39, 8 September 2020 (UTC)

Thanks! Misha Wolf (talk) 19:48, 8 September 2020 (UTC)

Basically, Wikipedia:Village pump (technical)/Archive 183#Toolserver replication lag for enwiki is now over 36 hours is happening again. --Redrose64 🌹 (talk) 22:10, 8 September 2020 (UTC)

Shame this is becoming so unreliable again. It used to run well until recently which was such an improvement to the way it ran (or did not run) a few years back. Have 2 day old edits at World number 1 ranked male tennis players which have not shown up yet, but also no indication there is a replication lag.--Wolbo (talk) 15:55, 9 September 2020 (UTC)

It's recovering, but is still not right. As with last time, there was one day when only one person managed to score an increase - congratulations Flyer22 Frozen (talk · contribs) for making two edits in the 24 hours ending 04:06, 11 September 2020. --Redrose64 🌹 (talk) 15:55, 12 September 2020 (UTC)

I did this twice, did I? Interesting...considering the many editors who spend significantly more time on Wikipedia than I do. Except for days like today (which find me on for longer), Wikipedia often gets only four hours out of me per day. But then again, I do intermittently use WP:Huggle, which inflates my edit count. And before that, I used WP:STiki (before it stopped working with this computer I use), which inflated my edit count a lot more. Flyer22 Frozen (talk) 01:56, 13 September 2020 (UTC)

Still a full day lag in the edit count.--Wolbo (talk) 21:30, 15 September 2020 (UTC)

I still notice the lag on just about any new page created. I have a script that normally gives me a read-out at the top of any page that tells me who created the page, how many editors, how many page views. etc. But if the page was created in the last day or two, it reads "Unable to fetch revision data. 0 pageviews (30 days)". — Maile (talk) 22:48, 15 September 2020 (UTC)

@Maile66: Did you check phab:T262239 - or even the replag itself - before posting here? --Redrose64 🌹 (talk) 18:08, 16 September 2020 (UTC)

... and your point is ... what? I was commenting on the couple of posts above mine. — Maile (talk) 01:19, 17 September 2020 (UTC)

My point is that not only is it a known problem, it is out of our hands and there is no point in making further posts here unless the situation is improving or even resolved. Every report, bot or script that obtains its data from Toolforge is affected. As I write this, the replag exceeds 69 hours with no prospect of immediate improvement; we at VPT can do nothing about it, the place to chase it up is the phab ticket. --Redrose64 🌹 (talk) 08:40, 17 September 2020 (UTC)

I've added "__NOINDEX__" to my metawiki page to prevent Google being spammed with user pages when my name is searched, yet these pages still appear on Google; how do I get the tag to work? Sidenote: even random talk pages of mine show up; shouldn't non-mainspace be noindexed anyway?  Nixinova   T   C   06:59, 15 September 2020 (UTC)

Nixinova, you have to wait until Google revisits the page and this can take a while. Also yes, you have to noindex every page you want not listed separately. —TheDJ (talk • contribs) 08:32, 15 September 2020 (UTC)

Pages that have had the tag for like a year still show up in Google, however. Is there any way to fix that?  Nixinova   T   C   08:49, 15 September 2020 (UTC)

Nixinova, call google :D —TheDJ (talk • contribs) 09:46, 15 September 2020 (UTC)

TheDJ, BTW, the way to "call google" is via their webmaster tools. -- RoySmith (talk) 15:05, 15 September 2020 (UTC)

The webmaster tools can be used if you control the website; I'm not sure you can request a reindexing for a page on a site you don't control, though. isaacl (talk) 20:17, 15 September 2020 (UTC)

Namespace indexing parameters differ by project, if you want to propose a change to a namespace indexing policy on metawiki you will need to start an RfC there. — xaosflux ^Talk 14:47, 15 September 2020 (UTC)

Maybe related: phab:T90475 – Majavah ^{talk · edits} 09:41, 17 September 2020 (UTC)

when im logged in to wikidata why can i only do edis in wikipedia android app Baratiiman (talk) 11:41, 17 September 2020 (UTC)

@Baratiiman: Your account in Wikidata is not (and never has been) blocked. What happens when you try to edit there while logged in? What happens when you try to edit while logged out? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 17 September 2020 (UTC)

Hello all! I noticed that section editing keeps track of the section with (let's call it) "section count" and no other information. So, when any section above the one you are editing gets removed (by an archiving bot, for example), instead of generating an edit conflict, the section you publish just replaces the section that has just received the same "section count" after the page updated (exhibit). Obviously I'll have to be careful about hitting publish around 05:40 UTC from now on, but it seems like something that ought to be fixed too (assuming my conclusions are correct). Would anyone please investigate and see if this is something for the phabricator? Or maybe warn about this somewhere prominently at WP:SECTIONEDIT? If it's not just me, or just the Teahouse, entire discussions may have been lost to talk page history in multiple other pages. TIA, Usedtobecool ☎️ 15:37, 17 September 2020 (UTC)

This can't really be fixed. The page will warn you if it happens to be a section which 'no longer exists' (in the sense that there are fewer sections than the section number in the URL string), which is about the best it can do. --Izno (talk) 16:27, 17 September 2020 (UTC)

I've probably asked this before (and gotten an answer) but can't find it in the archives. When I originally wrote Edward G. Faile, I used list-defined references. That was before I started using Visual Editor. VE can't deal with that style, so I need to convert it to a form VE groks. What's the best way to do this? -- RoySmith (talk) 17:30, 17 September 2020 (UTC)

Ah, I found it. Help talk:Footnotes/Archive 2#List-defined references vs. Visual Editor?. Once again, google search wins the day when wiki-search fails. -- RoySmith (talk) 18:05, 17 September 2020 (UTC)

The Citations button (edit page) is still giving me a "request failed" message. I first reported this error on Sept 8 and the final response was that it was because of load. However, I have yet to see this work regardless of time of day. Can the error message be changed so it's more accurate as to what the actual issue is? I remain unconvinced it is because of load. RedWolf (talk) 17:51, 16 September 2020 (UTC)

I've been testing it and load is definitely a factor. If one selects "thorough mode" when activating it on a large category or massive set of articles via #UCB_webform (I'm looking at you, @AManWithNoPlan:} User:Citation bot will slow down, and it will become difficult to activate Citation bot directly, by clicking the Citations button, or by clicking Expand citations on the sidebar. Abductive (reasoning) 05:35, 17 September 2020 (UTC)

Yeah, I have been testing it under load. I have made some substantial improvements and found a couple memory leaks. AManWithNoPlan (talk) 12:01, 17 September 2020 (UTC)

@AManWithNoPlan:}, is there a way to prioritize editors who are activating Citation bot from the article button/expand citations link? This is where all the frustration is happening. Abductive (reasoning) 20:03, 17 September 2020 (UTC)

I have made some changes to help with this. Long-term perhaps having two deployments might work better. AManWithNoPlan (talk) 20:05, 17 September 2020 (UTC)

Archives

1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25

We're considering merging WT:ITNR into WT:ITN but the former has been around a long time and has it's own archive. Any suggestions on how we could list the archives from WT:ITNR on WT:ITN without breaking the archive bot? --LaserLegs (talk) 19:32, 16 September 2020 (UTC)

LaserLegs, WT:ITN uses template {{archives}} to list its own archives. You could add another {{archives}} box, which would list old archives of WT:ITNR by using its parameter "root". E.g. {{archives|auto=short|search=yes|root=Wikipedia talk:In the news/Recurring items}}. This code generates the box on the right. —⁠andrybak (talk) 14:34, 17 September 2020 (UTC)

Thanks Andrybak. That worked well — Martin (MSGJ · talk) 20:16, 17 September 2020 (UTC)

refToolbar's "Cite" menu is appearing on the code editor toolbar when editing a Lua module, CSS, JavaScript or JSON. At first I suspected it was interfering with a script I'd installed, but it appears even when logged out (it seems to depend on namespace though, as it doesn't appear when editing a user CSS/JS).

I don't remember this being the case (right?) and I hope this will be fixed soon, since obviously there's no use in that menu when editing a module, CSS, etc. and clicking on it does nothing (unless you switch to the plain textbox). Nardog (talk) 08:07, 18 September 2020 (UTC)

I have a problem. Recently I edited the Silent Scope (video game) article and I noticed something funny: while I'm at the edit page sandbox, when I try to copy an original link under the archived link on the Wayback Machine, when I right-click, the picture freezes for a few seconds up to a minute before the right-click box appears. Also, when I try to cut/copy/paste a copied link onto the sandbox, the right-click has the picture freeze up for a few seconds up to a minute before the right-click box appears! The right-clicking in the Wikipedia sandbox seems to have some issues. Does anyone know why? (I'm using Google Chrome on Windows 8.1 BTW.) --Angeldeb82 (talk) 03:06, 18 September 2020 (UTC)

Some wabsites will fire up some JavaScript when you right-click, and that may soak up processor time before the expected behaviour is allowed to continue. There are various reasons for the javascript - some newspaper websites use it to modify the text that is to be copied to your clipboard, so that when you paste what you thought was going to be the article title, you get a whole bunch of other junk as well such as a the page URL, the author, the date and time, etc. --Redrose64 🌹 (talk) 09:27, 18 September 2020 (UTC)

Well, I think I know why the right-click issue freezes up for a few seconds on other sandboxes like Wikipedia and TV Tropes: it was because of the spell-check thing that's going on in Chrome. So I disabled spell-check, and now I'm able to copy-paste without the right-click issues freezing up. --Angeldeb82 (talk) 15:10, 18 September 2020 (UTC)

Crossposting based on feedback received to post on this group.

I was playing with the mobile app (on iOS) earlier, and I was able to see WP:ITN. However, clicking on the link just shows the top three news blurbs (each as a section). Does someone know why the mobile app does not carry the 'Ongoing events' nor the 'Recent Deaths' sections from the ITN panel? Is this question better asked in a different forum? Thanks. Ktin (talk) 20:53, 17 September 2020 (UTC)

@Ktin: You say Crossposting based on feedback received to post on this group. - where else was this posted? In accordance with WP:MULTI, I don't really want to answer here if answers have already been given elsewhere.

But that aside, do you see the Nominate an article link? If that is also absent, the most likely cause is that the mobile CSS is set not to display elements belonging to the itn-footer class. --Redrose64 🌹 (talk) 09:21, 18 September 2020 (UTC)

Redrose64, thanks for the note.

Here's the link to the crosspost Wikipedia_talk:In_the_news#WP:ITNRD_on_the_mobile_app?. I was referred by folks there to attempt posting here.

I was using the Wikipedia iOS app. There is no link to "nominate an article" on the iOS app. Instead we see the first blurb show up as "in the news". There is a link below that called "current events", and that takes me to a screen with the three blurbs from the WP:ITN panel, and that's about it.

Appreciate your inputs. Ktin (talk) 15:47, 18 September 2020 (UTC)

Hello, once again the file upload wizard is down. You add a pic, fill in all the boxes, press upload, it gets to 100%... and then nothing. No file. It has been doing this on and off repeatedly for the past few months. Very frustrating. WisDom-UK (talk) 18:17, 18 September 2020 (UTC)

How large is your file (bytes, not pixels)? --Redrose64 🌹 (talk) 20:46, 18 September 2020 (UTC)

Hi there, I am not totally sure, this is the right place to start this conversation, but I recently developed a Lua module on Turkish Wikipedia and translated into here. {{autocat}} works with Module:Autocat. Quickly I will explain what it does:

• First example: 2000 works

1. It has no parameter. So, it takes the page title, which is "2000 works", and divides into parts: the year and the suffix. In this case it is something like: "2000", "works".
2. And then It goes through Module:Autocat/data/arts and finds the "works" object, and uses that information to create a header bar, explanations, commons category links and portal links. And it checks if the category has a main article or see also articles.
3. It inserts the category the appropriate parent categories.
4. It has no parameters. Just placing the template to a category page.

The plus sides:

1. We would not need any of the templates listed in {{Creative works chronology category header templates}} or similar ones. It would be like a cleanup. It does not seem like a good cleanup but, we have hundreds of templates in Chronology category header templates. They all would be useless after this template.
2. We would not need to create {{WorksYear}} or {{WorksDecade}} templates seperately, they all use the same data listed on a Lua page, which is just a couple of lines.
3. Adding this template to the category pages can be done by the bots, as the same thing done on Turkish Wikipedia.

But the catch is that the data should be entered in Module:autocat/data pages. That is not a hard thing to do, if the sample data I put is examined. Just a couple of lines for each type.

So I am proposing to use this template on these chronology categories. ~ Z (m) 17:44, 18 September 2020 (UTC)

WP:MULTI strikes again, this template was mentioned at Wikipedia talk:WikiProject Categories#Template:Autocat. --Redrose64 🌹 (talk) 18:28, 18 September 2020 (UTC)

To be fair, these two discussions were started by different people, and it's quite possible Z didn't notice my discussion before starting this one. * Pppery * _{it has begun...} 20:56, 18 September 2020 (UTC)

This would disenable at least one well-used gadget and VisualEditor and make it difficult to remove unwanted cross-cutting categorization. As well as add to the expansion limit on a given page. This would also require a more descriptive name. --Izno (talk) 18:37, 18 September 2020 (UTC)

"the catch is that the data should be entered in Module:autocat/data pages" We already have Wikidata for that. Paging @Mike Peel and RexxS: as they have done a lot of similar work, not least on on Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 18 September 2020 (UTC)

(Originally asked in the help desk, but was referred here).

Is it possible to use a template from a sister project of Wikipedia, or from another language of Wikipedia? E.g. I need something like {{wikt:link|en|go|went}} to call Wikidictionary's template {{link}} with the aforementioned parameters, and in another language's wiki {{en:xpd|CURRENTDAY}} should call {{xpd|CURRENTDAY}}. Thanks, Veritas94 (talk) 22:23, 18 September 2020 (UTC)

No, you must import the template to the wiki of interest. --Izno (talk) 23:43, 18 September 2020 (UTC)

Does anybody know why this edit has the tag "Reverted"? It's not a revert. --Redrose64 🌹 (talk) 18:26, 18 September 2020 (UTC)

I am uncertain whether reverted refers to the edit in question reverting an earlier revision or if it refers to a future revision reverting the so-tagged edit. I am fairly certain it is the latter given this also is so-tagged. Tags can be assigned to arbitrary revisions, it's just that there are very few things that do so. --Izno (talk) 18:45, 18 September 2020 (UTC)

It means that the edit was later reverted (in this case, in the next edit). I don't recall seeing that tag until a day or two ago; maybe it's a new feature that could have been named a little better. [Edited to add: It looks like this new feature was in the works for a while and was released in August or September. See T164307 and related tasks. I sure wish the WMF developers would fix some of the pesky bugs I'm following before introducing shiny new features, but I'm just a volunteer (and a donor...).] – Jonesey95 (talk) 19:18, 18 September 2020 (UTC)

Yes, "this edit has been reverted" fits the bill - there certainly seem to be a lot of them at the moment, and yesterday was Thursday. --Redrose64 🌹 (talk) 20:17, 18 September 2020 (UTC)

As it happens these recent changes for reverted edit taggings are by volunteer/non-WMF/WMDE developers for Google Summer of Code. --Izno (talk) 21:05, 18 September 2020 (UTC)

I noticed it, too, and appreciate it. The single word seems clear to me, though shouldn't it be linked like some other tags? —[AlanM1 (talk)]— 06:07, 19 September 2020 (UTC)

It's a new feature, see mw:Manual:Reverts#Reverted_tag. Added by Ostrzyciel as part of GSoC 2020. – SD0001 (talk) 09:19, 19 September 2020 (UTC)

Hi all,

We wanted to get some opinion regarding the way that RedWarn currently loads its script content. There had been some controversy over a previous experimental distribution method, which was originally intended to make deploying RedWarn easier, which was removed due to privacy concerns, but over the past few months with RedWarn growing larger and larger, with hundreds of users, we want to expand by completely re-writing the RedWarn tool. This is helped experimentally by the fact that we now have access to Wikimedia Cloud Services, meaning we can implement technologies on WMF hosted servers. We know that this is substantially different to what other user script/gadgets do, but we believe using more modern web technologies can yield a significantly better user experience.

TLDR: Given that RedWarn now has access to servers controlled by the WMF, would it be problematic to move the code off-Wiki (but still on Wikimedia servers), given that all changes are tracked on RedWarn's GitLab, and considering checksums to verify the legitimacy of the script can be implemented? If so, would it be problematic to use a bot to update the RedWarn script (within its own userspace)?

Signed: Berrely (talk · contribs), Chlod (talk · contribs), Leijurv (talk · contribs), Ed6767 (talk · contribs) and Prompt0259 (talk · contribs) 20:06, 13 September 2020 (UTC)

Unless something has drastically changed - this is still just a personal user script that some other are importing - so it is really buyer beware. If there is plan to move this to a full gadget one day, it would be good to plan ahead now. As far as updates go, there is about 0 chance we would approve a wiki-"bot" as an interface administrator just for this task, and as a personal user script the ownership and accountability for the script belongs clearly to the user that is publishing it. If that user uses some sort of script on their end to update what is their own user subpage, we're not really going to do anythign to stop it. — xaosflux ^Talk 21:48, 13 September 2020 (UTC)

Xaosflux's usual hostility at user scripts aside, there's no problem with doing anything described here. However, as long as there is one "lead maintainer", I don't see why you guys want to use a separate bot account's userspace to host the script. The lead maintainer can host it in their space and update it from the master branch by running a "deploy" script. But it's understandable if you want to have fully automated CI/CD process.

The nowiki tags aren't working surely because User:Ed6767/redwarn.js contains multiple such tags. Nowiki tags can't be nested. The closing nowiki tag on line 2987 closes the one started on line 22. This can likely be worked around by substituting usages of "nowiki" in the source code itself with something like "no" + "wiki" (assuming webpack doesn't join the strings while minifying). – SD0001 (talk) 08:45, 14 September 2020 (UTC)

@SD0001: I'm actually rather welcoming of user-scripts in general, like I mentioned above the user can pretty much do whatever they want and anyone that doesn't want to use it can just move along. What I am rather unwelcoming to is having to get administrators to maintain personal user scripts that become at all popular and then are abandoned by their owners. — xaosflux ^Talk 03:10, 15 September 2020 (UTC)

I would have thought that making RedWarn a gadget would have been on the product roadmap. Is this something that the development team has considered and rejected? Best, Barkeep49 (talk) 19:31, 14 September 2020 (UTC)

@Barkeep49, it has been a consideration, especially now I've assembled at team to maintain it. If the community wants it to be a gadget, we won't object. If it was, however, as none of us are interface admins we'd prefer to host off-wiki on WMCS with all the correct security and privacy procedures in place so we can get updates out quicker and without massive edit requests, but hosting on-wiki is possible too. Ed talk! 19:39, 14 September 2020 (UTC)

Ed6767, that makes sense. I don't know all the ins and outs of making it a gadget but I understand that it offers considerable performance advantages over being a userscript. From what xaosflux wrote above it seems like making this change would complicate making this a gadget down the road. Is that correct xaos? Are there other reasons/advantages that the RedWarn team might want to move towards making it a gadget rather than continuing as a user script? Best, Barkeep49 (talk) 19:42, 14 September 2020 (UTC) Fixing ping of xaosflux. Barkeep49 (talk) 19:47, 14 September 2020 (UTC)

@Barkeep49, being a gadget would be preferable in terms of user friendliness as installing would be as easy as checking a box in preferences, so there'd be no need to dig into code files, which many may not prefer to do. Other than that, userscripts and gadgets are very similar in a technical nature, in terms of they both add code to Wikipedia that can be run in your browser. Now we've discussed internally, going forward, we'd prefer to make RedWarn a gadget, but that will require consensus. So, while we're on topic, would it be worthwhile to open an RfC regarding making RedWarn a gadget below? Ed talk! 20:04, 14 September 2020 (UTC)

I'm the wrong person to ask that question as all I know is just how much I don't know about the topic. Best,Barkeep49 (talk) 01:52, 15 September 2020 (UTC)

As far as turning a script in to a gadget goes, that is where most of the gadgets come from. Gadgets normally get extra scrutiny and all code changes on-wiki would need to be reviewed by interface administrators - which means there may certainly be reluctance to import instructions from off-wiki that would bypass the code-review and version-fixing components. — xaosflux ^Talk 03:13, 15 September 2020 (UTC)

This may be off-topic, but in terms of a blacklist for user scripts, I think something like this would do well as part of m:Partial blocks and blocking in general. There should be an option in block settings that blocks REST POST API calls only while allowing editing through the regular edit form. This would effectively disable gadgets like Twinkle and programs like Huggle while allowing the user to make constructive edits elsewhere. Aasim 04:09, 15 September 2020 (UTC)

@Awesome Aasim: I fail to find what exactly about what you said is related to RedWarn's deployment options. I suggest that you make a new section and provide the relevant context there. Chlod (say hi!) 04:20, 15 September 2020 (UTC)

I think you're trying to use the user script & gadget infrastructure in a non-idiomatic way. The existing process/expertise around scripts isn't geared to handle modern frontend practices. Years and years from now, any user script or gadget will someday be edited by a interface administrator in exclusively JavaScript form, so any nontrivial build process will complicate that. (I doubt the TS compiler outputs very nice JS, and minification will of course produce write-only code. Minification will also necessitate more extra sanitization steps to get the result past the MediaWiki parser.) As an example, all Popups did for a "build process" was concatenate a bunch of pure-JS files, and modifying it was painful enough.

I would instead recommend RedWarn be converted to a standalone tool running on Toolforge, just like Snuggle. On Toolforge, you can use any frontend technologies and not bother with any bot/deploy script stuff. From using RedWarn, it looks like the only big new thing that would need adding is a custom diff viewer, which isn't that bad since diffs already come from the API in HTML form. Users could unfortunately no longer use all their other user scripts that work on diff pages, but RedWarn could just link to the normal on-wiki diff page from the custom diff view. Yes, this would also bypass the gadget process, but I'm fine with that. This isn't really a gadget anyway, if you compare it with the rest of Preferences → Gadgets. Pinging Joeytje50, the WP:JWB developer, who probably knows all about user scripts that "take over" the browser window. Enterprisey (talk!) 09:20, 19 September 2020 (UTC)