Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

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

wrong sort by coordinates in class "wikitable sortable" table

This is how the table should like after the first click on the "Coordinates" column: coordinates must increase from the Northern Pole to the Southern. (The second click on each column displays the reverse order; if you tried to click anything here, return to the default view via refreshing screen with F5).

Meteorological hardware on Mars

Landing order	Mission	Coordinates	From	To	sols	Device	Zone
6	Phoenix	68.2188°N 125.7492°W / 68.2188; -125.7492	25.05.2008	28.10.2008	152	MET	subarctic
1	Viking-2	47.64°N 225.71°W / 47.64; -225.71	04.09.1976	12.04.1980	1281	(NASA)	moderate
10	Zhurong	25.1°N 109.9°E / 25.1; 109.9	22.05.2021		1143	MCS	moderate
2	Viking-1	22.27°N 312.05°E / 22.27; 312.05	20.07.1976	11.11.1982	2243	(NASA)	moderate
3	Pathfinder	19°7′48″N 33°13′12″W	04.07.1997	27.09.1997	83	ASI/MET	subtropical
9	Perseverance	18.4447°N 77.4508°E / 18.4447; 77.4508	18.02.2021		1240	MEDA	subtropical
8	InSight	4.5024°N 135.6234°E / 4.5024; 135.6234	26.11.2018		2026	TWINS	equatorial
5	Opportunity	1.9462°S 354.4734°E / -1.9462; 354.4734	25.01.2004	10.06.2018	5110	solar panel	equatorial
7	Curiosity	4.5895°S 137.4417°E / -4.5895; 137.4417	06.08.2012		4268	REMS	equatorial
4	Spirit	14.5684°S 175.472636°E / -14.5684; 175.472636	04.01.2004	01.05.2009	1892	solar panel	subtropical

However, now the sort engine of "wikitable sortable" treats the contents of cells with the {{coord|47.64|...}} template either as plain figures with a float decimal or as string constants. It brings the whole idea of sorting by coordinates to an absurd, because southern and nothern latitudes are mixed disregarding the value of the hemisphere parameter (N or S)

Foreseeing the questions like 'why latitude not longitude':
sorting by longitude (E or W) doesn't arise in the tables with geographic, climatic, astronomic etc. material. However the necessity to sort by latitude arises often when the readers to group the table contents. For these reasons I kindly ask the technicians to improve the "wikitable sortable" engine with a patch providing the accurate sorting by latitude (given the values are properly put into the "{{coord|...|...}}" template).

Programmatically this patch is short and easy:
- if the parser encounters the {{coord|...|...}} template in the cell =>
=> then it must search for additional hemisphere criteria (|N| or |S| enclosed in the straight brackets) =>
=> if the hemisphere is "S", the numeric key used for sorting does not change;
while if it equals "N", then the value must be converted to negative (multiply by –1).

Thank you in advance, Cherurbino (talk) 13:08, 16 October 2021 (UTC)

You may use data-sort-value="arbitrary value" to force a sort order if you are having issues, as in e.g. | data-sort-value="68.2188" | 68.2188 N X E or | data-sort-value="-68.2188" | 68.2188 S X W. Izno (talk) 13:19, 16 October 2021 (UTC)

thank you, but this code shall not work until the values inside the {{coord|...}} shall be converted into the numeric array from -90 (Northern Pole) to +90 (Southern Pole). This array should not be explicitly visible for the readers; it should be kept within the virtual code space Cherurbino (talk) 13:26, 16 October 2021 (UTC)

Or, if the trick is in the | data-sort-value="-68.2188" | 68.2188 S X W clause, could you show it directly by editing my sample here (or in my sandbox)& Cherurbino (talk) 13:28, 16 October 2021 (UTC)

Try that. --Izno (talk) 13:34, 16 October 2021 (UTC)

Of course, you can be less precise if you have few enough values that you don't think any of them will sort wrongly. I would suggest you avoid trying to stuff the longitude into the data-sort-value in any way since several digits of precision of the latitude should be enough to separate all the values cleanly, but if you really want you could probably make it work out somehow. Izno (talk) 13:37, 16 October 2021 (UTC)

Keeping the manual opened)) I kept on trying with the header line in my sandbox. However the pipe (straight quote "|") in your argument "-68.2188" | 68.2188 S X W messed all my table. Now I see, your solution is in inserting this clause in each line of the table. Of course, it shall work - but only for one table, while there are hundreds of other tables with the "coords" templates. This is a palliative, while I seeked for the universal solution for everybody. Thank you, anyway, for your time and kind attention Cherurbino (talk) 14:00, 16 October 2021 (UTC)

A "universal" solution is probably not forthcoming. At least one dev I know has complained about the complexity of the code in this area. :^) Izno (talk) 14:54, 16 October 2021 (UTC)

Could it be a good idea to amend the WP:TABLESORT help page with the sample for the coordinates' values? Cherurbino (talk) 14:08, 16 October 2021 (UTC)

Instead of a bare pipe | try using the special five-character sequence {{!}}. --Redrose64 🌹 (talk) 14:54, 16 October 2021 (UTC)

The table sorter is client-side JavaScript. That means it cannot see the wikisource or the template-expanded wikitext. It can only see the HTML sent to your browser. In your example, {{coord|68.2188|N|125.7492|W|globe:Mars}} becomes:

<style data-mw-deduplicate="TemplateStyles:r994658806">.mw-parser-output .geo-default,.mw-parser-output .geo-dms,.mw-parser-output .geo-dec{display:inline}.mw-parser-output .geo-nondefault,.mw-parser-output .geo-multi-punct{display:none}.mw-parser-output .longitude,.mw-parser-output .latitude{white-space:nowrap}</style><span class="plainlinks nourlexpansion"><a class="external text" href="//geohack.toolforge.org/geohack.php?pagename=Wikipedia:Village_pump_(technical)&params=68.2188_N_125.7492_W_globe:Mars"><span class="geo-nondefault"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">68°13′08″N</span> <span class="longitude">125°44′57″W</span></span></span><span class="geo-multi-punct"> / </span><span class="geo-default"><span class="geo-dec" title="Maps, aerial photos, and other data for this location">68.2188°N 125.7492°W</span><span style="display:none"> / <span class="geo">68.2188; -125.7492</span></span></span></a></span>

That's the output of a specific template at a specific wiki. The table sorter is used by many wikis in many languages. I don't think it would be good use of developer time to try to make this work when it's only relevant for sortable columns of coordinates on both hemispheres. However, outputting a sortkey could be an optional feature of {{coord}}. Then there could also be a choice between North-South and West-East sorting. It can be suggested on the talk page. PrimeHunter (talk) 21:47, 16 October 2021 (UTC)

Distinguishing between the hemispheres is the language-indepenent issue. Pure mathematics common to the whole world. Now sorting by coordinates returns wrong output: north is mixed with south. Solution of this problem is purely mathematical: if table sorter comes across the 'coord' template, then values for 'N' within it should be treated as negative. Cherurbino (talk) 18:45, 20 October 2021 (UTC)

Were it "purely mathematical", you would not have multiple editors tell you that what you are asking for is not going to happen as you wish. I have provided an alternative as has PrimeHunter; I suggest that you look into one or the other. Izno (talk) 18:51, 20 October 2021 (UTC)

Were this problem unsolvable, we would not see the examples, that it is already solved in some of the wiki engines. Let's take the Template:Mars map and the services putting the 'dots' on this map. This template dosn't mix N and S; it means that somebody has already written the code assigning negative values for 'N' in order to pass this argument to the proc, that calculates X and Y offsets necessary to set these 'dots'. Cherurbino (talk) 19:01, 20 October 2021 (UTC)

I didn't say this problem was unsolvable, I said you weren't going to get what you want. Please do not put words in my mouth. Izno (talk) 19:05, 20 October 2021 (UTC)

Sorry, I also didn't mean personally you constatating the unsolvability. It was a mere rhetorics when the fact 'nobody solves' is spread within the undistinguished community; nothing pesonal. Meanwhile, another example of solutions already found are infoboxes like {{Infobox crater data. User wraps the coordinates into the 'coord' template, and passes then to some underlying procedure which converts N and S values into the numeric offsets to place red 'dots' over the canvas of MOLA map. Cherurbino (talk) 19:18, 20 October 2021 (UTC)

Re: you would not have multiple editors tell you that what you are asking for is not going to happen as you wish - the arguments of PrimeHunter were not based on the subject. He told me about 'multiple wikies' while distinguising N and S is not a matter of national localization, and the long snippet he quoted does not contain the code relevant to sorting procedure. Which occurs later, maybe at geohack.toolforge.org — Cherurbino (talk) 19:26, 20 October 2021 (UTC)

Dear Izno, I feel we shall not find the answer here, so I propose to close the discussion topic. Thank you for your attention, as well as for the palliative you proposed. Best regards, Cherurbino (talk) 19:32, 20 October 2021 (UTC)

@Cherurbino: As regards whether north or south is negative, there's a simple test. Omit the hemispheres from {{coord}}, and use negative values instead - see where you end up. For example, {{coord|-22.911|-43.205|type:city|display=inline}} → 22.911°S 43.205°W / -22.911; -43.205. So there you are, negative is south and we won't change that. --Redrose64 🌹 (talk) 20:52, 20 October 2021 (UTC)

Dear Redrose64! Thanks for your sample I found the way to override the problem which didn't allow me to use the numeric +/- syntax before:

source	code	result	comments
Cherurbino	{{coord|68.2188|N|125.7492|W|globe:Mars}}	68.2188°N 125.7492°W / 68.2188; -125.7492	present state
Redrose64	{{coord|-22.911|-43.205|type:city|display=inline}}	22.911°S 43.205°W / -22.911; -43.205	sample
Cherurbino	{{coord|68.2188|-125.7492|type:city|display=inline}}	68.2188°N 125.7492°W / 68.2188; -125.7492	test OK
Cherurbino	{{coord|68.2188|-125.7492|globe:Mars|display=inline}}	68.2188°N 125.7492°W / 68.2188; -125.7492	test fails due to the

The parser does not allow to use purely numeric coordinates' values for globe:Mars parameter! OK, I shall declare Mars as a kind of 'city'))). Thank you very-very much for this lifehack... and I gotta feeling that our respected colleagues Izno and PrimeHunter shall breathe a sigh of relief after such a boring interlocutor like me shall leave the thread completely satisfied that his problem was solved. Thank you, everybody! Cherurbino (talk) Cherurbino (talk) 11:51, 21 October 2021 (UTC)

You apparently didn't understand what I wrote. Let me repeat in bold: The table sorter is client-side JavaScript. That means it cannot see the wikisource or the template-expanded wikitext. It can only see the HTML sent to your browser. "client-side" means it runs in your own browser on your own computer. It doesn't run on a Wikimedia server where the wikitext is stored. You wrote "if table sorter comes across the 'coord' template". It doesn't. It never comes across any template. It only comes across HTML. I quoted the exact HTML it comes across in your example at the English Wikipedia. In other wikis there will be different HTML, and sometimes local terms instead of N and S. Coordinates can also be formatted in several ways. It would be difficult to make the table sorter work reasonably reliably on coordinates across languages and formats. I can think of many more useful table sorter features the developers could use time on. Here are ten:

1. Descend: Option to sort a column in descending order on the first click (often best for numbers).
2. Surname: Sort by surname, e.g. sort "first names surname" by "surname, first names" when no sortkey is given.
3. Ignore: Specify words/strings to ignore in sorting, e.g "more than", "less than", "circa" in number sorting.
4. Regex: Specify a regular expression replacement to apply to each cell to make the sortkey.
5. Empty: Option to sort empty cells at the end in both ascending and descending (empty often means missing data, usually no reason to sort it at top in ascending).
6. Hide: Hide selected rows in sorting (instead of just sortbottom).
7. Colspan: Option to give a colspan cell different sort keys for different columns.
8. Transpose: Make sortable rows instead of or in addition to sortable columns.
9. Restore: Restore the original display, including rowspans and sort-bottom rows in their original position.
10. Initial: Specify a column to initially sort by before clicking anything.

Some of these can be accomplished in specific tables with sort keys but so can your coordinates. PrimeHunter (talk) 21:31, 20 October 2021 (UTC)

Dear PrimeHunter! As you see above, the problem has found its solution. I apologize for dragging you into the discussion of the specific programming side of the problem. It was not useless for those who have read it, includind myself. Now I know more than before coming here, and everybody has got an example of finding non-trivial solution for the non-trivial problem. As for you personally: you demonstrated the high level of professionalism in your field, and Wikipedia must be proud of such volunteers like you. Thank you, everybody! Cherurbino (talk) Cherurbino (talk) 11:51, 21 October 2021 (UTC)

Web Archive search

Is it possible to search archived versions of websites saved in Web Archive by content like in any web search? Eurohunter (talk) 18:28, 3 November 2021 (UTC)

@Eurohunter:

arquivo.pt has that feature, but it cover less pages than the archive.org. Still better than nothing. MarMi wiki (talk) 14:22, 6 November 2021 (UTC)

@MarMi wiki: Very interesting. It has more results than I expected unfortunatelly search tool is not optimised too well. Anyway I think Arquivo.pt should be listed somewhere as useful archive. Eurohunter (talk) 15:13, 6 November 2021 (UTC)

intake-analytics.wikimedia.org

Today (and yesterday) every time I save or preview an article I get the message "Microsoft Edge not responding - waiting for intake-analytics,wikimedia.org. The resulting delay ranges from a few seconds to two or more minutes, making even a simple edit a time-wasting process. What is going on, and when will it be fixed? This problem does not occur in Safari on iPad. Downsize43 (talk) 01:18, 4 November 2021 (UTC)

That domain is for metrics measuring. It shouldn't take that long to respond and I haven't heard more complaints about it yet. If it keeps up however, please do open a ticket in Phabricator. They might ask you for some more details about where you are located and the ISP, because likely this is an internet routing issue and somewhat specific to the path between your ISP and wikimedia. —TheDJ (talk • contribs) 09:46, 4 November 2021 (UTC)

@TheDJ: I was having this problem just last month (c.f. Wikipedia:Village pump (technical)/Archive_192#slow_pages_saves_waiting_for_intake-analytics.wikimedia.org) - ended up just blocking this domain locally. — xaosflux ^Talk 17:03, 4 November 2021 (UTC)

@Xaosflux: Just how do I do that? Downsize43 (talk) 11:19, 5 November 2021 (UTC)

@Downsize43: I used a software firewall, there are many ways you could do this - but none of them are Wikipedia-specific. — xaosflux ^Talk 11:36, 5 November 2021 (UTC)

My signature

Hello! So I'm here to write about an issue (That's mostly minor) with my signature. If you look at my signature, you'll notice a gap between my talk link and my discord username, and the timestamp. Anyone know what part of the code causes this to happen and how I can fix it? ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:19, 4 November 2021 (UTC)

It happens because position:relative doesn't change the space reserved for the text. {{Sup sub}} uses another approach but templates are disallowed in signatures and Special:ExpandTemplates shows it uses a lot of code. PrimeHunter (talk) 02:08, 5 November 2021 (UTC)

You could try to use "margin-right:-22q" on the subscript style: Blaze The Wolf^Talk_{Blaze Wolf#6545} but I don't know if that would be exceed the character limit. --rchard2scout (talk) 12:06, 5 November 2021 (UTC)

Unfortunately it does. But thanks for trying. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 13:05, 5 November 2021 (UTC)

@Blaze The Wolf: try [[User:Blaze The Wolf|<b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze The Wolf</b>]][[User talk:Blaze The Wolf|<sup>Talk</sup>]]<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545</sub>. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:32, 5 November 2021 (UTC)

Long tables causing a gray background to the right of the screen

A long table in a Wikipedia article is causing a gray background to the right of the screen.

I have encountered this problem in several articles.
Examples:
Tesla_Model_S#Sales_by_country
RGB_color_space#RGB_color_space_specifications
Asteroid#Size_distribution
Motion_picture_content_rating_system#Comparison_table
List of AMD accelerated processing units#Features overview
Fiddler on the Roof#Casts
List of country calling codes#Tree list
And I came here after having discussions at Talk:Tesla_Model_S#Page_Display, Talk:RGB_color_space#Page_Display, and Talk:Asteroid#Page_Display.

I am using the iPad mobile website.

I am using Safari.

— Preceding unsigned comment added by Neel.arunabh (talk • contribs) 21:24, 4 November 2021 (UTC)

The grey background is the "natural" background colour for all Wikipedia pages. The white that you see in the main text area is specific to that area, it is superimposed on top of the grey and hides it. There's a trend at the moment to artificially constrain the width of displayed text, tables are not subject to that restriction so may protrude into the blank area on the right. Personally I would design web pages to use all of the available width, because if people really want the text to be narrower, they can resize the window by dragging the left or right edge. --Redrose64 🌹 (talk) 00:07, 5 November 2021 (UTC)

See Wbm1058's suggestion at Talk:Tesla Model S#Page Display, "The large number of footnotes included in some cells of the table is causing some columns of the table to be much wider than necessary. If all the citations were pulled from inside the individual cells and placed immediately below the table, the table would not require as much screen real estate.". We do not want last few columns of the table to cross the edge of the main text area. Neel.arunabh (talk) 01:14, 5 November 2021 (UTC)

What would you do instead? Cut it off level with the main text? No thanks. Space is there to be used, not set aside as fallow. --Redrose64 🌹 (talk) 09:46, 5 November 2021 (UTC)

I am really against the current structure of the tables. Imagine what it would be if the same thing happened in a Word document. Neel.arunabh (talk) 15:23, 5 November 2021 (UTC)

A skin level solution is basically required to fix this, as well as fixing our templates that use tables rather than e.g. divs (already on my long list of things to fix). For normal tables, only the first really fixes it; e.g. both Timeless and Minerva take care of the issue by overflow-x: scroll or some variant, while Vector probably does not have that code. phab:T131650 exists as one element of the issue, as does phab:T66577 (though the latter is written from the mobile perspective, the issue is relevant to New Vector's fixed content width). Maybe Jdlrobson knows the more recent task I'm pretty sure Alex was looking at a few months ago and which I can't find right now. Izno (talk) 15:33, 5 November 2021 (UTC)

Neel.arunabh, have you tried choosing "Use Legacy Vector" under Preferences → Appearance? It looks like your choice of skin (Vector 2.0, I'm guessing) means that you are depriving yourself of screen width for the text. Please try it; you might like it. – Jonesey95 (talk) 03:54, 11 November 2021 (UTC)

"Use Legacy Vector" is already on in my preferences. Neel.arunabh (talk) 04:38, 11 November 2021 (UTC)

Big ugly message I can't dismiss

When I go to my watchlist there's a big ugly message about my interface language telling me nothing I haven't known for years, but with no apparent way to dismiss it. It appeared today. Is there some way of getting rid of this waste of screen? Thanks, DuncanHill (talk) 12:50, 5 November 2021 (UTC)

@DuncanHill: the best way to get rid of it would be to change your interface language to a supported language. In Wikipedia:Village_pump_(proposals)/Archive_184#Discourage_en-xx_UI_variants - there was widespread support to actively "discourage" editors from using patently broken interface languages. I just added an id to it, watchlist-summary-enxx-warning which you could hide in your common.css file. — xaosflux ^Talk 12:57, 5 November 2021 (UTC)

One of the most obnoxious features of the message is the claim "With this setting you will not be able to see many local messages, such as announcements made here" - if that were true I wouldn't be able to see it. Now it's one thing not to bother to make Wikipedia work properly for people with the en-gb setting, but to go out of your way to make things worse by putting big ugly notices in the way is quite another. I see the notice is also intruding on this page. I wouldn't go so far as to call it vandalism, I'm sure whoever thought this up had good intentions, but we all know whither that road leads. How do I hide it - on watchlist and wherever else it has been intruded? DuncanHill (talk) 13:00, 5 November 2021 (UTC)

You can hide this with:

#watchlist-summary-enxx-warning {display:none;}

In your Special:MyPage/common.css

— xaosflux ^Talk 13:06, 5 November 2021 (UTC)

Thanks, that seems to work. DuncanHill (talk) 13:11, 5 November 2021 (UTC)

• I'm the one who added it, based on the discussion I linked to above that I think supports that we actually "discourage" editors from using such settings. (I'm certainly involved there - and open to reversal by anyone else that want's to "close" that discussion with a different finding). — xaosflux ^Talk 13:10, 5 November 2021 (UTC)

  I wouldn't call that warning/notice an "announcement" really - and the message you are seeing there is not part of any workflow that will actually show what is more traditionally displayed as community "announcements". — xaosflux ^Talk 13:11, 5 November 2021 (UTC)

• I did pull it from the edit notice on VPT for now, that part may need some more work. — xaosflux ^Talk 13:12, 5 November 2021 (UTC)

There needs to be a button to dismiss it, at the very least. That wouldn't make me happy but it might make me less pissed off. You just can't go thrusting messages down people's throats all the time just because you don't approve of their use of the options you give them. DuncanHill (talk) 13:28, 5 November 2021 (UTC)

The one here on the VPT edit notice is gone, since it was messy anyway. As far as the watchlist header, the prior discussion appears to be quite supportive of actively discouraging people from picking that setting - we certainly disagree there but I'm open to more feedback from others below. — xaosflux ^Talk 13:52, 5 November 2021 (UTC)

@DuncanHill: You create problems for yourself by choosing en-gb. That's what happened at Wikipedia:Village pump (technical)/Archive 166#Unexpected behaviour of search/go where I asked you to please always mention it when you report issues with interface messages, and at Wikipedia:Village pump (miscellaneous)/Archive 67#Tags in Welsh where you didn't mention it. As one of the few users who both have en-gb and report interface issues, will you please either always mention it or change to en. At Wikipedia:Village pump (proposals)/Archive 184#Discourage en-xx UI variants I wrote:

"I once examined the full en-gb file and it only made around ten minor spelling and punctuation differences like color/colour, not different words like petrol/gasoline. For that you lose a lot of messages customized for the English Wikipedia, e.g. with links to our policies, processes and help pages. For example, compare the edit page for a fully protected page in en and en-gb (admins must log out to see it). en-gb users sometimes cause confusion when discussing the interface with others, and some help pages don't match what they see."

MediaWiki offers around 450 interface languages. All unregistered users and the large majority of registered users have en. We don't spend time customizing the interface for hundreds of languages here at the English Wikipedia. MediaWiki doesn't offer an option to automatically show a customized en message if there is no customized en-gb message. PrimeHunter (talk) 15:05, 5 November 2021 (UTC)

I finally specifically opened phab:T295164 about this problem - it could POSSIBLY be merged somewhere else - feel free to provide input there for now! — xaosflux ^Talk 15:21, 5 November 2021 (UTC)

@PrimeHunter: Starting off with "You create problems for yourself by choosing en-gb" really makes me not want to bother with you anymore. But I will say hundreds of languages which aren't English are pretty much irrelevant here, the problem is with a language which is. If I knew where to go and what to do to translate messages for en-gb I would lend a hand, but that does not seem to be wanted by anyone. DuncanHill (talk) 15:47, 5 November 2021 (UTC)

@DuncanHill: en-gb translations are done at translatewiki.net, you can help out there. Portal:En shows there was only 58 en-gb translations in the last 30 days, which is less than is necessary for a good user experience. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:21, 5 November 2021 (UTC)

ME TOO -Roxy the sceptical dog. wooF 16:43, 5 November 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: Thanks for the link. I think I've found the right place there - it's not entirely clear where things for en-wiki are. DuncanHill (talk) 17:40, 5 November 2021 (UTC)

From a technical note, I don't think that translatewiki is a solution to the problem: it is great for ensuring that default messages are accessible in all languages - it is not good for translating a single project's localized messages. — xaosflux ^Talk 17:55, 5 November 2021 (UTC)

@DuncanHill: you may find this useful for starting out in translatewiki. As Xaosflux said above, translatewiki is good for translating global default messages. Enwiki is unique in that we have a larger number of localised messages compared to other language projects. Translating them to en-gb is up to one of the admins of enwiki. For example MediaWiki:Gadget-HotCat/de is the German translation of enwiki's localised MediaWiki:Gadget-HotCat, which overrides the global MediaWiki:Gadget-HotCat. Like this a separate interface message can be locally set up at MediaWiki:Gadget-HotCat/en-gb and so on for other messages. Nobody seems to be interested in doing this, so you will have to depend on translatewiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:11, 5 November 2021 (UTC)

Why don't we just run a bit to create /en-gb and /en-ca customizations identical to the English defaults for all of the currently-customzied MediaWiki messages? That would be easier than all of this arguing. * Pppery * _{it has begun...} 16:47, 5 November 2021 (UTC)

@Pppery: well we did just discuss this at VPR (see link above) and the overwhelming feedback was to discourage these - not try to keep them going. — xaosflux ^Talk 16:50, 5 November 2021 (UTC)

Why is this issue being re-litigated here? This is a perennial Village Pump issue (link to dozens of threads where en-gb is mentioned as an issue). The VPP thread was pretty much unanimous for discouraging the choice of en-gb in this context. It is now being discouraged. A CSS workaround has been provided for people who resist the discouragement. Any time this comes up again, we can respond with a boilerplate message explaining that the use of that preference is discouraged because en-gb interface messages are not maintained, instructions for setting it to a user-friendly option, a link to a relevant phab task that would make the whole thing moot if fixed, and CSS instructions for making the discouraging message go away (caveat customizer, of course). – Jonesey95 (talk) 18:09, 5 November 2021 (UTC)

Why on Earth are we telling users to stop using the setting for their own language? If en-gb is provided as an option, it should be properly supported. If it is not supported, remove it from the list of options. If it is supported, stop discouraging people from using it. The watchlist notice is inappropriate. Did you actually speak to any en-gb users before slapping them with a warning message that makes no sense to them? A custom CSS workaround is not suitable because a) it's an obscure kludge and b) the vast majority of users won't known to use it. Modest Genius ^talk 13:12, 9 November 2021 (UTC)

@Modest Genius: There's a difference between saying that some feature should be "properly supported" and actually persuading people to perform that support. The people who maintain the various interface languages are volunteers, just like we editors are volunteers. If nobody is interested, it will at best stagnate, at worst deteriorate - as has been shown. As noted above, there was an RfC earlier this year. --Redrose64 🌹 (talk) 14:45, 9 November 2021 (UTC)

@Redrose64: I'm not asking you to support it. I'm saying there's no point in giving users the option if it just triggers an error message saying it isn't supported, particularly one that is confusing, self-contradictory, and cannot be dismissed. Either allow users to select en-gb without hassling them about it, or remove the option entirely. Telling them off for doing something we presented as a valid option is nonsensical. Modest Genius ^talk 19:38, 11 November 2021 (UTC)

So, when is the big ugly message going to vanish? -Roxy the dog. wooF 14:48, 9 November 2021 (UTC)

Might I ask why you are against selecting "en - English" as your language? --Redrose64 🌹 (talk) 15:03, 9 November 2021 (UTC)

Sure, and this for me is obviously the important point. It isn't clear which variety of english "en - English" is. I suspect it is probably american, in which case I want no truck with it as it is spelled rong. I hope that makes sense. -Roxy the dog. wooF 15:14, 9 November 2021 (UTC)

It's not American (if it were, it would be described as "American English" in the selection list), nor is it Australian, Indian or South African. It's an internationalised form that should be understandable to anybody for whom some variety of English is used in day to day communication.

Of greater problem to me as an editor is in talk page discussions where somebody describes a matter as "moot", the meaning of which in American is directly opposite to its meaning in British. It's the same problem when a motion is "tabled". Neither of those conflicts can be resoved by an interface language setting. --Redrose64 🌹 (talk) 15:31, 9 November 2021 (UTC)

User:Redrose64 thanks for responding, fyi I have changed from GB to En. If you want to stop the old farts like me from complaining, the best option is to remove GB altogether. Thanks again. -Roxy the dog. wooF 14:19, 11 November 2021 (UTC)

Non-functional reference parameters within a template

At {{Rotten Tomatoes prose}}, I can't get parameters like |access-date= to work. I'm guessing this may have something to do with the bug about stuff not working within tags, but the normal workaround of using {{#tag|ref|content=the ref}} doesn't work either.:L Any idea what's happening/how to fix it? {{u|Sdkb}} ^talk 19:48, 5 November 2021 (UTC)

You have skipped a few steps. Here's some tough love:

1. Revert the recent non-working edits to the live template, which is transcluded on 131 pages, in case you broke anything.
2. Create a sandbox version of the template.
3. Create and populate a testcases page.
4. Use Special:ExpandTemplates to figure out what the rendered version of the template's wikitext looks like.
5. Modify the sandbox and testcases page until you fix the problem or have a better idea of where the problem resides.
6. If necessary, repeat the previous two steps until you fix the problem or get stuck.
7. If you fix the problem, copy the sandbox code to the live template.
8. Post a note on the template's talk page asking for help.

I'm happy to help if you get stuck, but please be more careful when editing templates. – Jonesey95 (talk) 23:01, 5 November 2021 (UTC)

@Jonesey95, I'll go create the sandbox. Regarding carefulness/the possibility of breaking anything, I wouldn't have proceeded if there had been a possibility of that. The reference parameters only appear when |ref=yes is set, and that's only done on one page, which I previewed before saving to ensure that nothing was broken. The access date not appearing on that one page until this issue is resolved isn't a crisis. I also sense that you have a feeling that I just came immediately to the pump before trying to resolve the issue myself. That's again not true—I spent a good 15 minutes tinkering with |ref=/similar to see if I could get it to work; just since I did it in preview rather than in a sandbox doesn't mean it didn't happen. {{u|Sdkb}} ^talk 23:08, 5 November 2021 (UTC)

@Sdkb: I've tried again with #tag: and it seems to work now. Certes (talk) 23:38, 5 November 2021 (UTC)

@Certes, looks good; much thanks! {{u|Sdkb}} ^talk 23:44, 5 November 2021 (UTC)

VE not loading and editing menu buttons no longer visible on source editor

Hi techhies, I have two computers running Win 10 and the problem is only apparent on one of them (using Chrome), so not a bug at Wikipedia's end. Visual editor hangs up after loading 70% and never recovers. When editing in source mode, I have lost all the editing interface buttons (font size, italics, etc). Having already restarted a few times and ensured Java is updated, what is my next step for troubleshooting this? Loopy30 (talk) 19:57, 5 November 2021 (UTC)

@Loopy30: these don't require java - so it's not that. Try opening an "incognito" window in Chrome, don't even logon, and see if you can start editing that way (don't click publish). — xaosflux ^Talk 20:34, 5 November 2021 (UTC)

@Xaosflux: Yep, works fine in "incognito" mode, what would be the setting that is stopping me normally? Loopy30 (talk) 01:23, 6 November 2021 (UTC)

@Loopy30: I've turned off your userscripts (just revert my edit at User:Loopy30/common.js to turn them back on). Other things that could be related to your account, see if you have any beta features enabled and turn off. Then in your browser, clear your cache and cookies from wikipedia (you will have to log on again afterwords). — xaosflux ^Talk 01:29, 6 November 2021 (UTC)

Viewing the latest diffs

Tracked in Phabricator
Task T295225

When viewing old diffs, there are convenient "← Previous edit" and "Next edit →" links for navigation between the edits. When viewing the latest diff, only a "← Previous edit" link is shown for obvious reasons. However, if the page is edited again while you're viewing that diff, it'd be nice if a "Next edit →" link appeared so that that a) you'd know that another edit had been made without needing to view the watchlist/history again, and b) that newer diff could be viewed in one click. Is there a preference somewhere to achieve this? Sod25 (talk) 21:28, 5 November 2021 (UTC)

@Sod25 No, but you could ask at WP:SCRIPTREQ ― Qwerfjkltalk 21:35, 5 November 2021 (UTC)

This would require performance-degrading JavaScript for general use, but yes, a user script could maybe do something like this. Izno (talk) 01:10, 6 November 2021 (UTC)

What's the important feature here: having a "Next edit" link, or making it appear only when that next edit occurs? The former would be easy and efficient, as it only needs the current revision id (...&diff=next&oldid=current revision). If there is no next edit, it shows a "no changes" diff between the current version and itself. The costly bit, both for the browser and the (API?) server, would be polling for a new revision appearing. That might happen many times if the user leaves the tab open whilst doing something else. Certes (talk) 13:59, 6 November 2021 (UTC)

The polling could be done only if the tab is active. – SD0001 (talk) 14:51, 6 November 2021 (UTC)

Thanks for the replies everyone, I won't ask for a script to be custom written for me as this is a want not a need. An important part of the idea was the "Next edit →" link appearing so that you'd notice that another edit had been made, similar to how "↻ View new changes since..." appears in the watchlist for the same reason. The watchlist only seems to poll for new changes when you're viewing that tab, so that would probably be the way to go about it. Sod25 (talk) 22:51, 6 November 2021 (UTC)

Missing TOC?

Tracked in Phabricator
Task T295187

I just noticed that the table of contents was missing from Jacob Wohl, which has the requisite four headings that should autogenerate one. I've added __FORCETOC__ for now, but does anyone know what might've caused it? GorillaWarfare (she/her • talk) 21:50, 5 November 2021 (UTC)

Multiple users are experiencing this, it has been reported by three people at WP:HD, I'll direct them here. Beeblebrox (talk) 21:55, 5 November 2021 (UTC)

Huh, weird, I am experiencing this, but not consistently. I don't see a TOC at Jonestown or Alaska but do see one at Dune (2021 film) and History of Alaska. Weird. Beeblebrox (talk) 22:02, 5 November 2021 (UTC)

I see TOCs at all of those articles. I am using the legacy Vector skin. Check to see what skin the editors experiencing the problem are using. – Jonesey95 (talk) 23:06, 5 November 2021 (UTC)

Regular vector over here. GorillaWarfare (she/her • talk) 23:19, 5 November 2021 (UTC)

Oddly, the first time I looked at the Jonestown article there was no TOC. I made a change to fix the infobox, then I could see the TOC. Now, I see the TOC in all of the articles. I too use Real Vector — GhostInTheMachine ^{talk to me} 23:28, 5 November 2021 (UTC)

I am also using the legacy Vector skin, and I am also now seeing TOC on all four articles I mentioned above...so.... I dunno... Beeblebrox (talk) 01:16, 6 November 2021 (UTC)

In attempting to fix a different issue related to the ToC on language converter wikis (primarily Chinese), the revert ended up being worse and was un-reverted once the issue was realized. It should be fixed now, I added a link to the relevant Phab task. Legoktm (talk) 01:22, 6 November 2021 (UTC)

Wonderful, thank you for clearing this up! I've removed __FORCETOC__ from Jacob Wohl and the TOC is showing up as expected without it. GorillaWarfare (she/her • talk) 01:24, 6 November 2021 (UTC)

@Legoktm Awesome. It's back to normal for me too. -Oluwatalisman (talk) 02:22, 6 November 2021 (UTC)

"Contents" window having trouble

For some reason, the "Contents" index section on Wikipedia, which contains the heading section indexing, doesn't show up on a few pages for me (including for my talk page). I'm not sure why. Am I the only one? This has previously been discussed here.

EDIT: I just noticed a few people had already mentioned this issue above. WikiLinuz (talk) 23:20, 5 November 2021 (UTC)

The automatic generation of a contents list on talk-pages sees to kick in once a fourth section is added. Remove the fourth section and the contents list disappears. It's evidently part of the programming (whether or not it ought to be is another matter). See another example at Talk:Nero. Haploidavey (talk) 06:47, 6 November 2021 (UTC)

@Haploidavey: The TOC is automatically suppressed when there are fewer than four headings or subheadings (excluding the page title), by design. This is long-standing behaviour, and is mentioned at H:TOC. --Redrose64 🌹 (talk) 14:03, 6 November 2021 (UTC)

@Redrose64: Thanks for that, and for the notification. Very thoughtful of you! I'm sure the Notoc business is something I used to know. Or at least bits of it. But since I hit 70, I find these little biscuits of knowledge just fall into the cocoa of age, and are lost in a sludge of milky bedtime drinks. Haploidavey (talk) 14:20, 6 November 2021 (UTC)

@Haploidavey What???? -Oluwatalisman (talk) 18:56, 6 November 2021 (UTC)

@Talisman-white: Haploidavey has confused a long-standing feature (non-display of TOCs that would have three entries or fewer) with a recent bug (non-display of longer TOCs). --Redrose64 🌹 (talk) 21:47, 6 November 2021 (UTC)

Reply tool: "reply" button looks wrong on some pages

Hello! I've enabled discussion tools, and they've been working fine for a while. Today, though, the reply link started to act weirdly. On some pages (but not all), the "reply" button looks wrong (like ^reply instead of [ reply ]). For example, this page looks fine, but my talk page has the superscript-like style. I've tried safemode (and clearing my common.js) to no avail. Does anybody know what's going on? Thanks. Tol (talk | contribs) @ 22:09, 5 November 2021 (UTC)

I cannot reproduce on your talk page. Please point to a specific thread and/or comment you are seeing the issue on. If this is an issue, it sounds like it is an issue with someone's signature having an unclosed <sub> element and not an actual problem with the system that generates reply links to me. Izno (talk) 01:13, 6 November 2021 (UTC)

Well, it's gone now. Weird. It was formatted differently with every comment on my talk (and on Wikipedia:Bot requests). I still have no idea what happened. Tol (talk | contribs) @ 03:33, 6 November 2021 (UTC)

I saw it too. Dug around a little and couldn't figure out what was up. All's well that ends well... Enterprisey (talk!) 04:25, 6 November 2021 (UTC)

I can't be sure but it might've been connected to the missing TOC issue (discussion above). I saw the wonky reply links on discussion pages when I was wondering where the TOC had gone. I made null edits on a few pages to get the TOC to appear and the reply links were probably OK too after that. (It was late at night so I'm not 100 % sure of what I saw.) kyykaarme (talk) 08:28, 6 November 2021 (UTC)

How to fix issue with two different references by same author, one is a book reference and one a website reference.

Book reference using SFNREF, website is not, but it's creating a targeting error. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:19, 6 November 2021 (UTC)

If they are the same year then see Template:Sfn#More_than_one_work_in_a_year. A simpler fix is not to use the error-prone and reader-unfriendly sfn/harv system. DuncanHill (talk) 16:27, 6 November 2021 (UTC)

Thanks, that worked. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:30, 6 November 2021 (UTC)

Using |ref=none on the cite web template should also work if it isn't going to be called by sfn/harv.Nigel Ish (talk) 16:39, 6 November 2021 (UTC)

Thank you, I knew I'd seen that before but I couldn't remember what the correct option was. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:48, 6 November 2021 (UTC)

Hunk of text hidden in VPP/138

This search says that Wikipedia:Village pump (policy)/Archive 138 includes the phrase User:SMcCandlish is claiming the untrue once again, but it's not on the page. Digging into the wikitext source, it is in the wikitext, added in Special:Diff/814672137. Actually, a big chunk of the wikitext is missing from the rendered page, but I've been unable to isolate exactly where the missing chunk starts and ends. The W3C validator comes up with a bunch of nit-picky stuff, but nothing that looks like is should drop a big hunk of text. Can anybody see what's going on? -- RoySmith (talk) 18:51, 6 November 2021 (UTC)

The wikitext not too far north of that line has {{collapse top|title=Collapsing a dispute which has been mooted.}}. --Izno (talk) 19:04, 6 November 2021 (UTC)

Ah, thanks! -- RoySmith (talk) 19:08, 6 November 2021 (UTC)

Alternative text for images

Did something change recently with alternative text for images? Using Firefox on a PC, I could see the alternative text displayed when I hovered over an image. But now it's not displaying. What's up with that? — Mudwater ^(Talk) 02:31, 7 November 2021 (UTC)

Edited to add: Wait a minute. On the main page, I'm still seeing the alternative text. But I don't see it in album cover images in articles about albums. So, is something broken with the {{Infobox album}} template? — Mudwater ^(Talk) 02:34, 7 November 2021 (UTC)

Module:InfoboxImage was changed about 30 hours ago. – Jonesey95 (talk) 05:07, 7 November 2021 (UTC)

@Jonesey95: Yep, that was it. Thanks! Further reading: Wikipedia talk:WikiProject Albums#Alternative text for album cover in infobox — Mudwater ^(Talk) 15:59, 7 November 2021 (UTC)

align=center|

align=center| or style="text-align: center;" ? If align=center| why without quotation marks if {| class="wikitable" has always quatation marks? <br /> or <br >? Eurohunter (talk) 10:05, 7 November 2021 (UTC)

style="text-align: center;" is preferable. align="center" is obsolete.[1] Quotes are optional if the value to the right of the equals sign doesn't contain spaces or special characters (class=wikitable would work as well). I personally prefer <br />, but both are equally correct. Rummskartoffel 14:58, 7 November 2021 (UTC)

Automatic counting in table

I know there is template for automatic counting in table but I don't remember its name and maybe there is other way t achieve it? Eurohunter (talk) 15:03, 7 November 2021 (UTC)

Are you looking for {{row numbers}} or {{Static row numbers}}? * Pppery * _{it has begun...} 15:36, 7 November 2021 (UTC)

@Pppery: What is the point of it if you have to count it manually? Eurohunter (talk) 15:55, 7 November 2021 (UTC)

Oh, sorry, I completely misunderstood what you were asking for. Ignore me. * Pppery * _{it has begun...} 15:56, 7 November 2021 (UTC)

@Pppery: Do you have idea how to make it to count automatically? Eurohunter (talk) 16:14, 7 November 2021 (UTC)

I remember there was probably two templates one for add all wanted numbers in the table into one template and second template with result. Eurohunter (talk) 16:59, 7 November 2021 (UTC)

How to subst #if:

Moved from Wikipedia:Help desk § How to subst #if:

 –  ― Qwerfjkltalk 17:47, 7 November 2021 (UTC)

I was trying to add an auto-categorising feature to a template, which works fine as

{{#if:{{#invoke:String|match|s={{subst::{{subst:FULLPAGENAME}}}}|[[Category:Wikipedia scripts]]|plain=true|nomatch=}}||The Category}}

However when I try to subst into her a blank string. How do I fix this, and is there a better way to do this? ― Qwerfjkltalk 21:37, 6 November 2021 (UTC)

One of the regulars here might be able to help you, but I would suggest that WP:VPT is a better place to ask such a question. Beeblebrox (talk) 00:45, 7 November 2021 (UTC)

I can reproduce that behaviour. With subst:, it produces the text between the two pipes before "The Category", which happens to be blank. I don't understand the reason for that. (The other two subst: within s= don't seem to make any difference.) Certes (talk) 19:05, 7 November 2021 (UTC)

Are you forgetting to subst the #invoke? * Pppery * _{it has begun...} 19:09, 7 November 2021 (UTC)

That fixes it for me (and makes the other two subst: within s= necessary too). Certes (talk) 19:17, 7 November 2021 (UTC)

Thanks @Pppery, I was sure I'd already tried that ― Qwerfjkltalk 20:08, 7 November 2021 (UTC)

Automatically renamed users

Tracked in Phabricator
Task T219279

Hello! See User:Ʝ and User:DZoo — two users who seem to have disappeared during a rename from lowercase to capital letters. Their user pages' history show them being created by users with the lowercase name, but clicking their user link or contribs link brings you to the nonexistent username with the capital first character. I'm not sure what went wrong here. Tol (talk | contribs) @ 03:36, 8 November 2021 (UTC)

@Tol: This is being discussed at phab:T219279 - it isn't really about "lowercase" but a unicode problem that is being worked on, it may have some bugs that should be brought up at that phab task. — xaosflux ^Talk 14:34, 8 November 2021 (UTC)

Thanks, @Xaosflux. Tol (talk | contribs) @ 14:47, 8 November 2021 (UTC)

The end of the Modern Skin

I used to use this skin, yet later I found out that it no longer exists, thus I had to use Timeless instead, making WikiEd unusable. Later I used the new Vector instead, making WikiEd usable again, which delights me. But I still wonder why Modern, a very elegant skin, is not longer existent and why WikiEd can not be used while using Timeless. May fellow Wikipedians tell me?--RekishiEJ (talk) 12:45, 8 November 2021 (UTC) added "use" 05:39, 9 November 2021 (UTC)

@RekishiEJ: It does still exist, but only for people who already have it selected - it's not available to those already using another skin (but see below). More info at Wikipedia:Village pump (technical)/Archive 191#modern skin on Commons and WT:Skin#'Modern' not selectable any longer. In short: the more skins that we have, the greater the maintenance burden - every new feature and bugfix needs to be tested against all existing skins to ensure compatibility. So when new skins get introduced - such as Timeless and Minerva - the older ones with the least use get retired.

But for the time being, there is an unofficial workaround:

1. Go to https://en.wikipedia.org/wiki/Special:Preferences?useskin=modern#mw-prefsection-rendering
2. Select "Modern"
3. Click Save

This won't work forever, at some point you'll be forcibly switched to Vector and there will be no way back. --Redrose64 🌹 (talk) 14:31, 8 November 2021 (UTC)

And as far as "WikiEd" goes, that is a personal user script - you can follow up at User talk:Cacycle/wikEd. — xaosflux ^Talk 14:35, 8 November 2021 (UTC)

Well, Wikipedia and other Wikimedia projects should no longer consider compatibility for older browsers (i.e. only the newest stable version of any non-discontinued browser should be considered), since doing so greatly reduced burden, some websites stop Internet Explorer support (some only support IE later than 8), and Modern can be revived.--RekishiEJ (talk) 15:16, 8 November 2021 (UTC)

And in fact, Wikipedia supports only IE9 and above presently (soon to change probably since little-to-no traffic is generated from either IE9 or 10). But that's still many, many versions of Internet browsers that need to have minimal support, because a world-top-15 website dedicated to the mission of knowledge does not have the luxury of eliminating support for arbitrary old browsers. --Izno (talk) 16:58, 8 November 2021 (UTC)

But this is irrelevant to whether Modern is directly support of course. Modern was not dropped because it did(n't) work in certain browsers but because it was totally unmaintained, little-used, and an ancient skin to boot. Izno (talk) 16:59, 8 November 2021 (UTC)

@Izno:I mean if Wikipedia drops support for all older browsers maintenance will become much simpler, thus keeping Modern does not make maintenance more burdensome than now.--RekishiEJ (talk) 05:39, 9 November 2021 (UTC)

The impending retirement of Cologne Blue and Modern is is nothing to do with browser support but the lack of willing maintainers - they're volunteers just like editors, under no compulsion. Skins are retired when few people are using them and nobody wants to maintain them, and their continued presence is a bigger burden than the disappointment of a few niche users. Having a choice of four or so skins is a luxury that other popular websites do not offer - Facebook, for example, periodically introduce a new skin (or "theme", I think they call it) and although they run two in parallel for a few weeks, they then drop the older one like a stone. --Redrose64 🌹 (talk) 15:21, 9 November 2021 (UTC)

And the Chinese edition still retains Modern, despite having Monobook, Vector, Timeless and Minerva.--RekishiEJ (talk) 15:26, 8 November 2021 (UTC)

@RekishiEJ: zhwiki no longer offers Modern to switch to (c.f. w:zh:Special:参数设置#mw-prefsection-rendering) - however just like here there is still a hack to put it in (for now) and if you already have it set it is still available (for now). — xaosflux ^Talk 15:37, 8 November 2021 (UTC)

Xaosflux WikEd is offered as a gadget. --Izno (talk) 16:58, 8 November 2021 (UTC)

Indeed, if WikEd does not work with Timeless, that means WikEd should be fixed/corrected. --Izno (talk) 16:58, 8 November 2021 (UTC)

@Izno: as WikEd is labeled as a gadget that is maintained by a single user - going to that user is still the primary place to ask for work to be done. I suppose if this is confirmed, we certainly can flag the skin dependencies in MediaWiki:Gadgets-definition in the meantime. — xaosflux ^Talk 17:26, 8 November 2021 (UTC)

Tech News: 2021-45

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

Recent changes

• Mobile IP editors are now able to receive warning notices indicating they have a talk page message on the mobile website (similar to the orange banners available on desktop). These notices will be displayed on every page outside of the main namespace and every time the user attempts to edit. The notice on desktop now has a slightly different colour. [2][3]

Changes later this week

• Wikidata will be read-only for a few minutes on 11 November. This will happen around 06:00 UTC. This is for database maintenance. [4]
• There is no new MediaWiki version this week.

Future changes

• In the future, unregistered editors will be given an identity that is not their IP address. This is for legal reasons. A new user right will let editors who need to know the IPs of unregistered accounts to fight vandalism, spam, and harassment, see the IP. You can read the suggestions for how that identity could work and discuss on the talk page.

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

20:34, 8 November 2021 (UTC)

{{THISSECTIONNAME}}

There doesn't seem to be a magic word or template that returns the name of the section in which it is placed (but maybe I haven't searched with the right query terms), and it would be useful in a number of situations. Is there some elegant or at least decent way to do this? If not, I'm planning a template which would include a unique token as a param (or maybe auto-generate it as a subst'ed hash of concat( {{Time}}, {{SUBPAGENAME}} ), read the article with {{find page text}}, and match it against a regex pattern matching the last section header name before the token. But that seems hacky and wasteful to me, and there ought to be a better way to do it. Is there? Somewhere I seem to remember reading about "section numbers", but I think that was just an addressability issue, and not a retrieval one.

My current use case is to provide decent query terms for the 'find' params in templates like {{Unreferenced}} and {{Expand section}} and others, where the first query term (|find= = "exact string" match) uses the article title, and the second query term (|find2= = unquoted search) would be the section name. This generally gives very good results when done manually, but optional params don't get used a lot, and the ability to automatically provide current section name as an unquoted query term in these templates would be a big improvement in the quality of search results provided by those templates. I suspect there would be a lot of applications for such a template, and it would be useful to have it be as efficient as possible. Thanks, Mathglot (talk) 22:13, 8 November 2021 (UTC)

Today this is not possible. There is a future where Parsoid is the one parser that might be able to do something like this keyword. Izno (talk) 22:15, 8 November 2021 (UTC)

Thanks, I thought not. In that case, as a fallback position of a template to replicate that functionality, can anyone find a better or more efficient solution than the one I have proposed? Mathglot (talk) 22:29, 8 November 2021 (UTC)

Section names are not fixed, they may be altered at any time (example). When editing, sections are referred to by number (for example, this section is no. 29 as I type this), but those may change at any time if, for example, old threads are archived or new sub-sections added to earlier sections. --Redrose64 🌹 (talk) 11:48, 9 November 2021 (UTC)

why cant one merge two accounts

i want to merge two accounts but could i it's just mysql query bi (talk) 09:13, 9 November 2021 (UTC)

@Baratiiman: Short answer: No. We have never done this. Longer answer: we do not have the means to do this, and part of the reason that it was never provided is because of the requirements of CC BY-SA attribution - the same reason why we never delete accounts. As an example of a declined request to merge accounts, see phab:T154290. --Redrose64 🌹 (talk) 11:43, 9 November 2021 (UTC)

A bug with "Syntax highlighting" capability

Tracked in Phabricator
Task T252342
Resolved

Hi, if we follow this scenario

1. Go to the "Talk page" of an article, for example go to the talk page of Resolution (logic) i.e., the page Talk:Resolution (logic)
2. Press "New section" from top menu bar
3. Activate "Syntax highlighting" capability from the top toolbar, i.e., press the icon to activate it
4. Enter a short subject

Now in this place of scenario, if we try to sign our message via four tildes by pressing hyperlink existing on the bottom of that page, i.e., the hyperlink existing in "Sign your posts on talk pages: ~~~~" the resulting four tildes is always inserted in the "Subject textbox". Even if we put the cursor in the "Message textbox", and then put the that hyperlink again to sign the message, still these four tildes is always inserted in the "Subject textbox" and not on its correct position that is on the "Message textbox". Please correct this bug. Thanks, Hooman Mallahzadeh (talk) 17:28, 9 November 2021 (UTC)

Note: This bug is known and being tracked at phab:T252342. Rummskartoffel 18:03, 9 November 2021 (UTC)

I bet just adding

			} ).on( 'focus', '.CodeMirror', function () {
				$currentFocused = $( '#wpTextbox1' );

after MediaWiki:Gadget-charinsert-core.js#L-249 will do. Nardog (talk) 19:47, 9 November 2021 (UTC)

The CharInsert extension has code which seems to take care of CodeMirror compatibility, similar to what you suggest. We could copy that. Though I'm not sure what is the relationship between the charinsert gadget and charinsert extension. – SD0001 (talk) 04:49, 10 November 2021 (UTC)

I'm not sure what the relationship is either, but it's documented. It seems wrong to duplicate the code that should already be in the extension, but anyway I've copied over the extension's code per your suggestion and that seemed to fix it. Thanks for doing the research! — MusikAnimal ^talk 21:52, 10 November 2021 (UTC)

How can I know how many page views species articles on English Wikipedia recieve per month?

Hi all

I'm working on a potential partnership with a large natural history organisation and I would like provide them with some metrics to give them an idea of the scale of readership of Wikipedia. If anyone is able to help me by giving me a metric of how many page views English Wikipedia articles on species receive per month I would really really appreciate it. I've tried using categories to get page views but I can't work out how to only get species articles, assume that there are a few infoboxes which could be used to identify species articles.

Many thanks

. John Cummings (talk) 21:23, 9 November 2021 (UTC)

All species pages should have a taxobox template. Searching for pages with template {{Speciesbox}} will pick up species pages using the automated taxobox system. If you also wanted subspecies and infraspecies you could also include template {{Subspeciesbox}} and template {{Infraspeciesbox}}. And pages using the older manual taxobox system could be found by searching for pages with template ({{Taxobox}} and parameter |species=. No idea about the page views side of things. —  Jts1882 | talk  09:24, 10 November 2021 (UTC)

Incompatibility between music scores w/ sound and the Listen template

Tracked in Phabricator
Task T295514

Graham Beards and I have observed that issues result when a single article uses both the score extensions with sound and the {{Listen}} template (e.g. FAC Symphony No. 4 (Mahler) and FA Piano Concerto No. 24 (Mozart), as well as articles with more traffic like Symphony No. 9 (Beethoven)). On my end, the presence of the two causes the score's sound files to "reload" annoyingly before being formatted in a similar style to the sound file in the Listen template. On Graham Beards' end (using the latest version of Chrome browser), the presence of the two causes the scores' sound files to be unplayable. Furthermore, we both found that this problem disappears when the Listen template is removed from the articles. Any help with fixing this problem would be greatly appreciated, and would undoubtedly improve the reader experience on many music articles. GeneralPoxter (talk • contribs) 23:17, 9 November 2021 (UTC)

This seems to stem not from anything specific about {{Listen}} but from how Score and AV media embedded using [[File:... interact in general. If the page only has scores, the browser's native HTML5 player is used, but any media embedded via [[File:... triggers the loading of MediaWiki's own player, which replaces the HTML5 player, hence the delay.

I assume Graham Beards has turned "New video player" on in Preferences. The new player apparently doesn't work with Score at all (phab:T245377). Nardog (talk) 03:04, 10 November 2021 (UTC)

I've filed a task: phab:T295514. Nardog (talk) 23:40, 10 November 2021 (UTC)

Thanks, good to hear. GeneralPoxter (talk • contribs) 00:23, 12 November 2021 (UTC)

Recent Changes filters randomly disappear and reappear

For some reason, the "User intent predictions" filters on Recent Changes will just randomly stop working when you have them applied, and when you reload the page, they are nowhere to be seen on the list of filters. Then, after a while, they reappear and magically start working again, and the cycle repeats itself. Why and how on earth is this happening?? GMX^(ping!) 01:42, 10 November 2021 (UTC)

Get page creator from API

Is there a straightforward way of getting the page creator of a page via the MW API? It's listed if I go to, for example, https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=info, but doesn't appear to be listed when doing &prop=info in the API. I could ask for the user that made the oldest revision via &prop=revisions&rvprop=user&rvlimit=1&rvdir=newer, but that would mean doing a second API call since I'm already asking for info on the most recent revision (and it comes with the other limitations of prop=revisions, such as only being able to query one page at a time). --Ahecht (TALK
PAGE) 23:12, 10 November 2021 (UTC)

The XTools gadget listed in Preferences can do it. I think its source code is at mw:XTools/ArticleInfo.js. – Jonesey95 (talk) 00:04, 11 November 2021 (UTC)

Interesting, although it looks like it's still going to have to be a separate API call, and a separate call for each page. --Ahecht (TALK
PAGE) 00:59, 11 November 2021 (UTC)

Using the MW API, I believe querying the user of the first edit is the only way. – SD0001 (talk) 11:21, 11 November 2021 (UTC)

@Ahecht: Are you checking all 6.5m and need to get through it quickly; or more interactive application of small numbers with high response speed? I can possibly help with the former, a regularly updated data dump. -- GreenC 22:58, 11 November 2021 (UTC)

Blue underlining in edit box

This just started happening. I don't think it's a software update on my end (Microsoft Edge, Windows 10). But certain words get underlined in blue when I edit.

Actually, it just happened with "edit" and I saw a message saying there should be a space after punctuation. Then I saw the word "ignore". I c;icked on that and it went away. Maybe it's not Wikipedia.

No, there it is again. It wants me to click again to ignore.— Vchimpanzee • talk • contributions • 23:53, 10 November 2021 (UTC)

@Vchimpanzee: that sounds like a spelling and grammar tool in your browser, likely Microsoft Editor. — xaosflux ^Talk 00:12, 11 November 2021 (UTC)

It doesn't say how to get rid of it.— Vchimpanzee • talk • contributions • 00:26, 11 November 2021 (UTC)

Most likely the fix is something like this: Go to your web browser's Add-Ons or Extensions menu, and click to disable the add-on that is causing this message to appear. – Jonesey95 (talk) 00:30, 11 November 2021 (UTC)

It doesn't seem to be listed, but Wikipedia is the only place where I'm seeing this.— Vchimpanzee • talk • contributions • 00:42, 11 November 2021 (UTC)

Try using another browser to verify? — xaosflux ^Talk 01:19, 11 November 2021 (UTC)

It doesn't happen if I'm not signed in. I'm reluctant to sign in on two different browsers at the same time.— Vchimpanzee • talk • contributions • 23:21, 11 November 2021 (UTC)

You can have more than one browser open and be logged in on all of them simultaneously - each browser will require a separate login action. They won't conflict with one another, until you log out using the log out link at top right - which will log you out of all, because you can't log out selectively other than by going to the cookie management feature of one of the browsers, and deleting the login cookies. --Redrose64 🌹 (talk) 23:32, 11 November 2021 (UTC)

Everything looks very different here but I'm not getting the blue line.— Vchimpanzee • talk • contributions • 00:16, 12 November 2021 (UTC)

Insert link feature not behaving like expected for external links converted to internal links. Is it the problem or am I?

Tracked in Phabricator
Task T295517

Hi -- not sure if this problem is me or the Insert Link feature. When editing, if I paste a complete URL into the Target Page/URL box of the Insert Link tool in the edit window, I get the usual "The URL you specified looks like it was intended as a link to another wiki page. Do you want to make it an internal link?" message. However, when I click Internal Link, nothing happens. In the past, it would reformat a full URL to be a proper internal link and change the radio button. I used it constantly. Now it does nothing.

This change came as the same time as some other look-and-feel changes to this tool (I now see preview images, tool has a more DHTML feel to it) so I am wondering if it got updated and this is a bug, or there is something about my configuration that has maybe changed. I haven't knowingly changed anything in my configuration. I am using a Mac (Big Sur) and it happens across all three browsers (Chrome, Safari, Firefox, latest non-beta versions of each). Vector skin. Here's two screenshots with examples. If I paste in a complete URL, when I click "internal link" in the second screenshot, nothing happens, it just returns me to the same window. Thanks for any help/advice.

Jessamyn (talk) 00:15, 11 November 2021 (UTC)

Yep, can reproduce, I bet this is the relevant line. Pinging Samwilson. Nardog (talk) 00:44, 11 November 2021 (UTC)

@Jessamyn and Nardog: Thanks for finding this bug and letting me know! Sorry about this. I've created T295517 and will try to get it fixed soon. —Sam Wilson 00:53, 11 November 2021 (UTC)

As I suspected, replacing the line with insertLinkTitleInputField.getField().setValue( match[ 1 ] ); seems to do the job. But I'm surprised the function 1) keeps underscores instead of turning them into spaces and 2) doesn't decode percent encodings. I bet users of wikis in other languages have found it useless. Nardog (talk) 05:14, 11 November 2021 (UTC)

@Jessamyn I just wanted to acknowledge and thank you for this exceptionally well-written and detailed bug report :) — MusikAnimal ^talk 02:52, 11 November 2021 (UTC)

Awww thank you! I've worked in tech support before, so I like to think I can make a decent report. The little info box above the posting box really helps a lot. Jessamyn (talk) 04:13, 11 November 2021 (UTC)

Random aside — This change came as the same time as some other look-and-feel changes Does anybody have a link for that change? Ta — GhostInTheMachine ^{talk to me} 12:44, 11 November 2021 (UTC)

@GhostInTheMachine This is part of the Warn when linking to disambiguation pages project from Community Tech, based on the #2 wish in the 2021 survey. The visual changes you speak of specifically were a result of phab:T289214. — MusikAnimal ^talk 15:26, 11 November 2021 (UTC)

Thanks. So the change to the editor linky thing would have gone live in 1.38.0-wmf.5 on 21 October 2021? — GhostInTheMachine ^{talk to me} 19:20, 11 November 2021 (UTC)

WebSite: web caching of wiki pages and other objects might be improved

NOTE: this is a technical issue that should be evaluated by software engineers and webmasters of wikipedia website(s).

First of all, I do not want to be disrespectful to anyone so, please, take these user observations for what they are (maybe all of them are already well known): simple thoughts of an occasional user.

Introduction
In Wikipedia:Village pump (miscellaneous)#Very_big_pages someone has arisen the problem of long delays (i.e. till 5..7 seconds) when visiting big wiki pages, specially the first time someone retrieves one of them after sometime (days or weeks?) nobody has visited it.

In practice the topic being discussed was about how to lower the size of big / long wiki pages because someone thought that most of the wait time was due to client browser struggling to retrieve and visually render such big pages (HTML code between 1MB and 1.6MB) and having a PC with CPUs not slow and enough RAM, he was worried about what could happen to smartphones and other mobile devices with much less HW resources.

Someone else replied that he did not notice such a long delays, at most 1..2 seconds, so I contributed to the discussion with my thoughts too and I found out that maybe something in wiki pages retrieval mechanism between web servers and browsers could be improved.

Here I do not want to discuss about the problem of long delays for the first time retrieval of big pages because it's a too technical thing that regards only wikipedia internal technical stuff; I have already written something about it in the above mentioned wiki section page.

Talking about the impact of slow response in user (web) interfaces, see also wiki article about responsiveness, I have noticed that web caching of wiki pages might be improved noticeably in order to decrease a lot of unnecessary web traffic load that probably burdens web applications and DB (database) too.

Caching assumptions
If a user is logged in, it looks like that wiki pages are never cached by browser (this is right, at least when editing a page), instead if user is logged out (not logged) pages are temporarily cached (this makes a noticeable difference) and so if they have already been retrieved (recently, within 1 minute) and they have not been modified then they are rendered in less than 0.2..0.3 seconds on a medium speed (high speed, single CPU) PC.

Right know cacheability of a wiki page depends also on:

• type of content encoding format (compressed or not);
• value of cookies;
• authorization;

because of "Vary" header, which is right.

Cookies contain also a session identifier that is dismissed when client browser is closed and so caching of wiki pages will always be session bound (it will last only till browser is kept open and only for users not logged in).

Current behavior / problems detected
Current caching of wiki pages by browsers is far from being perfect because of the following technical issues:

• wikipedia web servers look like to be of different kinds, some send HTTP responses with a "Last-Modified" (but without "ETag") header, others with an "ETag" (but without "Last-Modified") header for the same wiki pages and so, depending on web traffic / load, etc. a browser can get responses one time from a web server and the other time from another one with a different type of object / cache identifier and of course in this case the entire wiki page has to be resent to browser even if it has not been changed, increasing the duration of overall operations by 10-20 times;
• a few wikipedia web servers used for static images (i.e. upload.wikimedia.org /common/thumb/*) send neither "Last-Modified" nor "ETag" headers and so static images served by those web servers are always fully reloaded when a page using them is displayed (as those images are rarely used in wiki pages this is not a big deal but anyway it is very odd and I guess really not necessary);
• in some cases header "Date" is not updated by web servers, but I am not sure about this case, maybe it depends on behavior of some web cache;
• caching of wiki pages depends also on cookies and cookies sent by browser include a counter value (tick) that changes at least every minute, so after 1 .. 60 seconds having received a wiki page, its cookie changes and browser has to invalidate its cached copy; this means that if the same wiki page is requested again by browser after its cookie has changed then the entire wiki page has to be retrieved, instead of just asking the web server if it has changed or not; this may be an issue that increases a lot web traffic and load of web servers, web applications, DB, etc. behind them.

In web server responses, it looks like that "Cache-control" and "Expires" headers already have proper settings, so apart from the alternate / random usage of "Last-Modified" and "ETag" headers, HTTP cache settings are already in good shape.

Goal to improve website response times of wiki pages
The aim should be to force browsers to ask web servers if a wiki page has been changed or not every time it is going to be displayed by browser (so statistics about number of pages showed by users should not be affected by this improvement); of course just asking that is much faster than retrieving the whole page every time it is visited by a user, specially if wiki page is big (there are wiki pages that do not change for hours, days or even months).

Proposals to reach goal of good cacheability of wiki pages
These are a few proposals in order to improve cacheability of wiki pages.

Web / application server(s) side
1. Each wiki page should have a unique identifier for each one of its revisions made by editors:

• surely this identifier already exists but all wikipedia web servers should send it as an "ETag" value for each wiki page;
• I suspect that using only a Last-Modified value would suffice because it is hard to think that a wiki page can be changed more than one time per second without conflicts (this should be confirmed by someone that know how those things work).

2. Web servers should send both "Last-Modified" and "ETag" headers for each wiki page, as recommended by last RFCs about HTTP; if both are sent, then only "ETag" is used by modern browsers but at least they can show value of "Last-Modified" somewhere in the information window and besides this, should an old browser - not supporting "ETag" header - be used then it could work anyway by using "Last-Modified" header (which in 99.99% of cases would suffice).

Client browser side
3. Value of Cookies should not change every minute (at least for users not logged in). The problem is to find out whether that tick value is mandatory or not to handle user session; if it is, then it should be investigated if it is mandatory for all kind of users (including those not logged in) or not and how to preserve its value without storing it in Cookies.

• first idea would be to remove that value from Cookies and to store it in a new custom HTTP header, sent by client browser, dedicated to cookie values that change frequently and that do not affect the cacheability of a wiki page, i.e.:

xapp-cookie: *TickCount=3

in this case above HTTP header should travel in client browser request till its arrival to a web server, then its value should be readded to "Cookie" values by adding custom code in web server(s) (or even in some web app if all HTTP headers found in request would be passed to that app to handle the response) and then resulting Cookie values could be used as usual;

• second idea would be to not use that tick value in Cookies for some kind of users (the majority of visitors); if in near future, users who are not logged in won't be able to edit wiki pages, then also using a tick value for user's session might not be a requirement anymore and so it could be removed from Cookies sent by those user's browsers, thus avoiding current cache problem with Cookies changing every minute; instead for users who were logged in nothing would change because for those users caching of wiki pages is already disabled (slow but safe mode) and so their Cookie values could change even once per minute;
• other idea(s) to be specified.

Something about improving HTTP caching could be done also for scripts and stylesheets; they are not always cached by browsers as they should be and besides this fact, sometimes their retrieval is a bit slow; specially when you are logged in and wiki servers are under load, you can see that wiki page is first visually rendered with standard browser fonts and then, after 0.3 .. 0.6 seconds, with proper text fonts because download of some style sheet is completed after wiki page has started to be shown in browser.

Conclusions
Doing above 3 suggested modifications, could allow caching of wiki pages feasable for an entire user session (until browser is closed), thus decreasing a lot the size of HTTP responses for wiki pages and the load server side.

Thank you for your attention and I'm sorry if I bothered you with already known issues. Ade56facc 13:05, 11 November 2021 (UTC)

Ade56facc I took the liberty of creating a Phab ticket T295556 which is better suited for discussions of this nature. ~ 🦝 Shushugah (he/him • talk) 14:23, 11 November 2021 (UTC)

Thanks for the ticket (I did not know about that reporting system). Ade56facc 14:40, 11 November 2021 (UTC)

I'm pretty sure these are all known and all have various reasons for being the way they are. For instance you make an assumption that a revision renders the same, but they do not for logged in users (for various historic reasons which are hard to undo (a 10 year project now)). But you are right that the biggest reason a page takes VERY long to load indeed is the complexity of turning wikitext into HTML when there is no cached copy of that available. —TheDJ (talk • contribs) 15:25, 11 November 2021 (UTC)

@TheDJ thank you for your comment, anyway I did not make that kind of assumption because I already wrote that for users logged in wiki pages are never cached; I was referring to an identifier usable in "ETag" HTTP header (that can be unique only for its associated page name, i.e. it could also be a revision number of the wiki page); anyway I have found out that maybe it is really not possible that two users can update the same page in the same second (even if they edit different sections) so maybe also a "Last-Modified" page date-time would suffice for caching purposes; the important thing would be to have the same behavior for all web servers serving wiki pages. Ade56facc 21:30, 11 November 2021 (UTC)

Listing contents of a category

In the text below, how can I display a list of the contents of the category as text, rather than just linking to the category ? If I remove the first colon, it just adds the page to the category; what I want is to produce a list of the articles at FAR. Thanks in advance, dumber than I look.

• Articles listed at FAR are:

Category:Wikipedia featured article review candidates

SandyGeorgia (Talk) 22:44, 11 November 2021 (UTC)

@SandyGeorgia: Does the categorytree extension do what you want? try {{#categorytree:Wikipedia featured article review candidates|mode=pages}} 192.76.8.91 (talk) 00:16, 12 November 2021 (UTC)

Bingo ! Thank you so much, 192! Best regards, SandyGeorgia (Talk) 00:22, 12 November 2021 (UTC)

@SandyGeorgia: Minor point, but if you want you can add "hideprefix" onto the magic word to get rid of all the "talk:", like so: {{#categorytree:Wikipedia featured article review candidates|mode=pages|hideprefix}}. Doesn't really make any difference to the functionality, but it would look a bit better where you're using it. 192.76.8.91 (talk) 00:43, 12 November 2021 (UTC)

And to get it to just print out a list of titles use {{#categorytree:Wikipedia featured article review candidates|mode=pages|hideprefix|namespaces="1"|hideroot=on}} 192.76.8.91 (talk) 00:54, 12 November 2021 (UTC)

Amazing! Now how do I barnstar the heck out of an IP ?? See the last green box in this mockup in my sandbox, where you can see I now have exactly what I want. Thank you! SandyGeorgia (Talk) 01:33, 12 November 2021 (UTC)