- User Since
- Nov 10 2016, 5:57 PM (342 w, 12 h)
- LDAP User
- MediaWiki User
- Certes [ Global Accounts ]
Mar 14 2023
Oct 28 2022
It works for me, but the publish button was greyed out until I clicked on the rosette(?) icon to the right of the title and added a badge for "sitelink to redirect".
Oct 27 2022
On enwp, and perhaps all wikis, Preferences→Search→Show thumbnails in Special:Search can now be unticked. I don't know whether this prevents transmission of images or simply hides them.
Oct 24 2022
One problem is that "vector" is already the key of another skin, the one currently used by most desktop readers and editors and which will continue in widespread use. Giving a different skin the user-facing name "Vector" is bound to lead to confusion.
Oct 8 2022
I don't find the images helpful either, and have added CSS to avoid displaying them, but I expect they still get downloaded, tying up Wikipedia's bandwidth and mine. The clinching argument may be that, because some of the images are non-free and lack fair-use rationales for their appearance in search results, showing them to me risks putting the WMF in breach of copyright law. (I am not a lawyer, this is not legal advice, laws vary by jurisdiction, etc., etc.)
Oct 2 2022
Please change the wording of the link. "Donate to Wikipedia" incorrectly implies that a significant portion of the money donated goes to Wikipedia.
Sep 14 2022
T314417 doesn't seem to solve this issue. For example, try editing Wikidata's [[Q15665435]] to link enwp's [[Orconectes bisectus]] redirect. "Publish" is greyed out, because the enwp page is a redirect. Please, all you have to do is follow consensus by not disabling the publish button.
Jun 27 2022
Jun 25 2022
Jun 17 2022
Please don't worry about disabling Enter. On the rare occasions I press it, it's accidental (attempting to insert a newline into wikitext) and I have to revisit the edit. I expect others have similar experiences, and we want to encourage previewing or at least viewing a diff.
Jun 12 2022
"Production" doesn't mean "for readers rather than editors". Readers come first, but editing tools help us to serve them well. One action by an editor may help thousands of readers.
Jun 4 2022
I came here to request this and am amazed that it's been open for seven years. It's not sophisticated; it's debatably a bug fix.
May 3 2022
Please don't remove the Stop feature. It sometimes works, and is better than nothing, both for users who (sometimes) get their query unlocked for fixing and for the servers which can cease wasting resources on pointless tasks. The feature really needs mending rather than removing.
May 2 2022
I may have a workaround:
- tick the "Don't allow site to prompt you again" box on the 500 box (text varies by browser and language), or ad-block that box and its modal background
- replace the query by a trivial one such as SELECT 123 /* keep old query here for reference */
- click Stop and quickly click Submit Query
The query will complete, show the answer 123 and display the "Submit Query" button ready for re-use.
That's not ideal or intuitive; a proper fix would be much better!
Apr 30 2022
Yes, my trivial query 61115 claims to have be running for nearly four months now, and the Stop button gives error 500. Can we at least do a one-off task to stop all queries which have been in running or queued state for more than, say, a week?
Apr 12 2022
Please fix. If you can really only handle one protocol by default, it should probably be https://
Apr 11 2022
Please consider showing the edit summary box by default, so no one has to discover a method to reveal it. This matches the UX when replying in the traditional way, and is a good use of space.
Mar 9 2022
I've reproduced this misbehaviour in a sandbox, which may be invalid as both edits were by the same editor. I've also seen it in the wild with different editors. It's intermittent, but here are two scenarios which may make it more likely.
1: User:A starts editing page X; user:B moves page X to a new title Y, leaving a redirect X→Y; user:A publishes the change. This overwrites redirect X with a copy-paste move of a modified copy of Y.
2: User:A starts editing page X; user:B makes a quick section edit to X#Foo; user:A publishes the whole-page change. User:B's section changes are lost.
Feb 18 2022
Bdijkstra: Have you tried installing riched20 in winetricks? That fixed it for me.
Jan 4 2022
I reproduced the problem on enwiki_p, including https://quarry.wmcloud.org/query/61115 which should complete in milliseconds but claims to have run for more than a day.
Jul 1 2021
Jul 9 2020
I've now installed winetricks riched20, and neither Naypta nor I have seen the problem since. Here's hoping this is now Resolved.
Jun 9 2020
Jun 5 2020
That may be a bug. <includeonly>...</includeonly> affects text between the opening and closing tags. <includeonly /> affects no text, and is not useful.
May 28 2020
The Monza page has now changed and no longer shows the problem. I can reproduce it on enwiki [[1984 Monaco Grand Prix]], where it adds a blank line 351 even with default settings and unticking everything (no find and replace, no general fixes etc., no regex). I have .NET 4.5 (dotnet45) installed (and just updated Winetricks from 20190912 to 20200412).
May 26 2020
May 22 2020
May 7 2020
VE appears to simplify piped links in a way incompatible with transclusion, specifically to replace [[Foo bar|Foo<noinclude> bar</noinclude>]] by [[Foo bar]], This is helpful and harmless on the page being edited, but makes a transcluding page behave as if noinclude had not been used.