In T370144#10268504, @Krinkle wrote:

If I share /wiki/Banana?lang=x&skin=y it will instruct the system to try to use X and Y. Whatever the result is, you'll get the same when I share it.

An error message seems too drastic to me unless it's just added at the top and the rest of the page still displays. But an error message sounds like more work, especially if there are translations. I would be satisfied with invalid useskin just being ignored. Without knowing the code, that sounds simple to me.

I'm not suggesting aliases. I'm suggesting that if you have MonoBook in preferences then any invalid value in useskin= should display in MonoBook. useskin=vector-legacy was just an example of an invalid value. It could also have been something random like useskin=hippopotamus.

This bug has BLP implications when there are captions identifying living people. Without gallery styles it looks like captions belong to the following image. Compare for example commons and enwiki. The latter looks like we claim Ariela Lowenstein is a bald man because the caption is far closer to that image.

In T285951#8169569, @Nardog wrote:

This doesn't even include quotes.
https://en.wikipedia.org/w/index.php?search=%22Society+of+the+Snow%22+prefix%3A%22User+talk%3AIdoghor+Melody%22

The backslash is included in the section link so it breaks since the id at the target has no backslash.
I tried some other special characters and a backslash in a heading has the same problem: A second backslash is added in the TOC.

An anchor is certain code in the html. There is no anchor saying "top" in Vector 2022. However, I didn't know the HTML specification https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment:top-of-the-document-2 says:
"10. If decodedFragment is an ASCII case-insensitive match for the string top, then return the top of the document."

https://en.wikipedia.org/wiki/Example?useskin=vector#top goes to NEAR the top of the page, between the tabs and heading since the html says <a id="top"></a> there.

The original post refers to an enwiki gadget "Add an [edit] link for the lead section of a page" at https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets.

Steps to reproduce for a simpler example without so many search results.

I made a simpler test page at https://en.wikipedia.org/wiki/User:PrimeHunter/VisualEditor_note_duplication

The first reported issue may be a duplicate of T352256.

https://uk.wikipedia.org/wiki/Special:Impact/Base is empty for me while
https://en.wikipedia.org/wiki/Special:Impact/Base works.
For myself, both
https://uk.wikipedia.org/wiki/Special:Impact/PrimeHunter (I have no edits at that wiki) and
https://en.wikipedia.org/wiki/Special:Impact/PrimeHunter work.

This bug is still present and was reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Watchlist_bug_with_wikidata (permanent link).

I don't know PHP and cannot make patches but I would certainly prefer a wikitext solution. Looking at https://en.wikipedia.org/w/index.php?title=Talk:Example&action=info&uselang=qqx, maybe we shouldn't worry about future conflicts if wikitext is allowed. The two fields with links have the link text in message names ending in -name: pageinfo-redirects-name and pageinfo-subpages-name. None of the other message names are like that. Indexing by robots is pageinfo-robot-policy. If customized wikitext is allowed and MediaWiki later wants to add its own link there, can it be expected to use a new message pageinfo-robot-policy-name for the link text, and ignore a customized pageinfo-robot-policy?

Thanks Jdlrobson. I don't know the implementation part but for editors I think it would be simpler and more flexible to allow wikitext.
https://en.wikipedia.org/wiki/Help:Page_information shows other examples of links but some of them are only on part of the text and wouldn't make proper sense on the whole text.

"Indexing by robots" is from MediaWiki:Pageinfo-robot-policy.
I tried to link https://en.wikipedia.org/wiki/Wikipedia:Controlling_search_engine_indexing with this in https://en.wikipedia.org/wiki/MediaWiki:Pageinfo-robot-policy:

In T329983#8630578, @matmarex wrote:

Curiously, double-clicking works if you click on the last (bottom-right-most) table cell.

The default MediaWiki:Visualeditor-tablecell-tooltip is "Double click to edit cell". At https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-tablecell-tooltip I have added "(in Firefox: single click and press Enter)". I suggest doing the same to the default if the bug is not fixed quickly.

I assume the report is about Vector 2022. Vector legacy displays MediaWiki:Tooltip-p-logo where the default English is "Visit the main page". I don't know whether it was intentionally dropped in Vector 2022 for some reason.

A null edit also changes the snippet to the editor's interface language at the time. If you experiment with w:test:NewPagesFeed language test then please return it to Danish to avoid confusion for others.

This is happening again to me and others at enwiki. Reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Thursday?

It's discussed at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Very_weird_page_views (permanent link). Desktop and mobile views are both huge while app views are tiny.

There has been some limit since 2008 in https://www.mediawiki.org/wiki/Manual:$wgMaxAnimatedGifArea

Also discussed at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problems_with_Tables_and_Infoboxes

This is also in T29275.

The interwiki prefix itself is not counted in the length limit but it causes a namespace to be counted.
I made some tests here: https://en.wikipedia.org/wiki/User:PrimeHunter/Page_name_size_in_interwiki_links

The bug was first mentioned at https://en.wikipedia.org/wiki//Wikipedia:Village_pump_(technical)#Image_caption_showing_up_as_link?
Tests indicate it happens when the file name has quotation marks. In the example, VisualEditor changed

It would be nice to restore everything about the original table when the order is restored. rowspans and the position of sortbottom rows are currently not restored as mentioned in https://en.wikipedia.org/w/index.php?title=Help:Sorting&diff=962664726.

Search of exactly 5 MB uploads sorted by creation date descending. The most recent error is from 23 May. There were many daily errors before that so it looks like the issue is fixed.

noc.wikimedia.org still links https://wikitech.wikimedia.org/view/Server_Admin_Log but it now redirects to https://wikitech.wikimedia.org/wiki/Server_Admin_Log again so I consider this resolved.

Example: If you are logged out and view https://en.wikipedia.org/wiki/Foobar then Page Previews works on "Smokey Stover" in the image caption in the article but not in MediaViewer at https://en.wikipedia.org/wiki/Foobar#/media/File:Smokeycover.jpg.

It works for me in Firefox, Edge and Chrome. I get the reported bug in IE11. When the date field changes to -0001-11-30 I get logs from before 2017-11-30, e.g at https://en.wikipedia.org/wiki/Special:Log?type=&user=PrimeHunter&page=&wpdate=0000-00-00&tagfilter=

I called it annoying and pointless before knowing the purpose was to enable redirect=no. Sorry about that.
I'm unsure what it means when it's both said the new version will be backwards compatible and it will be html. Will customized messages be able to use wikitext like previously? If yes then all sounds fine. If no then the previous customized functionality may be hard or impossible to restore. It used features like namespace-dependent behaviour and url encoding of the page name. MediaWiki messages should allow wikitext as much as possible. Wikisyntax can link with redirect=no by using a url instead of a wikilink, e.g.:
<span class="plainlinks">[{{fullurl:$1|redirect=no}} $1]</span>

Please revert the current implementation of this change. It breaks the message in all wikis which have customized it to use the page name to add other useful links on WhatLinksHere. See e.g.:

MusikAnimal's "We're also going to hide the Thanks link via CSS" refers to adding this to MediaWiki:Common.css in the English Wikipedia:
.mw-thanks-thank-link {display: none;}
Other wikis still have thanks links.

I thanked PrimeHunter for the 7 September edit, as shown in the first screenshot.
I reloaded the page and the newest 11 October edit by PrimeHunter2 was marked as thanked, as shown in the second screenshot.
PrimeHunter received no thanks. PrimeHunter2 received thanks for the 11 October edit. The thanks log also says PrimeHunter2 was thanked:
https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=thanks&user=PrimeHunter3

There are many reports of mentions not causing notifications at
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Not_receiving_pings.
I posted an example where the editing account got "Your mention of PrimeHunter was sent", but I didn't receive the notification.

Here are test cases for various magic words: https://en.wikipedia.org/wiki/User:PrimeHunter/Asterisk_escape_test

Special:Allpages still displays MediaWiki:Allpages-summary at the top so wikis can create the message to explain it like I did in https://en.wikipedia.org/wiki/MediaWiki:Allpages-summary and mentioned in https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Special:AllPages_disabled. I guess a temporary MediaWiki default for MediaWiki:Allpages-summary might not be displayed before the issue is fixed.

In T153275#2875073, @Betacommand wrote:

Short urls do not handle any URL params.

Which specific problems are created by the name change? That would help understand and evaluate this request.

Example templates which use {{REVISIONUSER}} to make code like "I'm [[User:PrimeHunter|PrimeHunter]]" when they are substituted, also in manual edits:
https://en.wikipedia.org/wiki/Template:Welcome_to_Wikipedia
https://en.wikipedia.org/wiki/Template:Huggle/warn-delete-1

The page image is chosen by https://www.mediawiki.org/wiki/Extension:PageImages#Image_choice (section just added by me with limited knowledge). There are some replies at https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Changing_a_page_image (will later be archived here).

I tested around 20 other main pages in Wikipedias and other Wikimedia projects. The only huge increase was ruwiki, but that is 1 million to 17 million daily, gradually from July 19 to 26. The whole increase is in desktop, 450000 to 16 million.

The target of the Help link is determined by MediaWiki:Search-helppage. I don't know where to change the default for Wikimedia wikis but changing it from https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Searching to https://www.mediawiki.org/wiki/Special:MyLanguage/Help:CirrusSearch would be good.
There is no global language preference so users are directed to the English version unless they have set another language at mediawiki.org, and I guess few have. Maybe unregistered users (and even registered?) at https://it.wikipedia.org/wiki/Special:Search should automatically get a link to https://www.mediawiki.org/wiki/Help:CirrusSearch/it, and so on for other languages and help links, but that may be beyond this task.

At https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=727504846#Fatal_exception_of_type_.22Exception.22
Tot Samyj Niekto says login attempts after a rename gives:
[V3Ov@gpAADwAABS9iCYAAAAO] 2016-06-29 11:24:42: Fatal exception of type "Exception"

On https://en.wikipedia.org/wiki/Template:X1 I previewed this:

I have made instructions for affected users to try to identify the problem wiki and logging in there: https://en.wikipedia.org/wiki/Help:Logging_in#Login_issues_and_problems
I also linked to it in https://meta.wikimedia.org/wiki/Help:Logging_in#Log_in_problems

My tests were at https://en.wikipedia.org/wiki/Special:ChangeEmail and https://meta.wikimedia.org/wiki/Special:ChangeEmail

Another one: https://meta.wikimedia.org/wiki/Special:CentralAuth/Isakoshekso

Another case was reported today in https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&diff=710975148

This is the same as T119736.

In T118823#1814909, @Mattflaschen wrote:

This should be filed separately. Please elaborate on exactly how it fails in the other browsers. Information from the JavaScript console would help, if you know how to access that.

The Wikipedia Adventure works for me in IE 9.0 on Windows Vista 32-bit.
It fails in Firefox, Chrome, Opera and Safari.
In IE I started at Mission 1 and reached Mission 4 step 12 before a browser crash which was probably unrelated to Wikipedia (the computer has issues).

I have made a temporary fix to the English Wikipedia:
https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=690352708&oldid=688903518
It adds this:
.infobox,
.last-modified-bar,
h2 {

clear: none !important;

}

I can reproduce with NoScript on https://de.wikipedia.org/w/index.php?title=Friedrich_II._(Preu%C3%9Fen)&action=edit
But disallowing certain url's with special characters is part of a NoScript feature against cross-site scripting and not a bug - unless false positives by an aggressive filter is considered a bug.

This was also reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#User_Contribution_Search

All three examples by Bulgarios are invalid. Those pages really were dead ends when https://en.wikipedia.org/wiki/Special:DeadendPages was cached 04:11, 23 June 2015.
I posted a series of real examples at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29#Dead-end_pages

Main Page snapshots are stored many times daily at
https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Main_Page
CSS hides the heading at https://en.wikipedia.org/wiki/Main_Page
but it's still in the html source.
The snapshots show the whitespace was added June 11.
1.26wmf9 was deployed to the English Wikipedia that day.