MediaWiki:Movepage-moved is the text you see when you have just moved the page, but that already links to the former title with &redirect=no

Pinging @SomeRandomDeveloper as the dev who implemented T326056

If nothing else, it should be a high priority to add a noticable and easy way to purge the previews

Perhaps more importantly also it needs to be reliable.

This is still happening. See https://en.wikipedia.org/wiki/Talk:Killing_of_Austin_Metcalf#Racist_Language for a report of revision deleted content still being displayed in previews almost two hours (and possibly longer) after the vandalism was reverted (and which was on the page only for a single minute).

[email protected] would seem to be the appropriate name based on that proposed standard.

Do we still think this feature will be useful if it can only link the user to Special:Preferences and not Special:Preferences#mw-prefsection-watchlist?

From a UX perspective, I think if this is implemented there should be some indication of whether the change you are seeing is or isn't the most recent revision to the page. A symbol placed at the start of a line showing the most recent revision to the page is what strikes me as the likely simplest.

Not wanting to tempt fate, but this might now be solved. I've not been logged out for over a month now (22 November was the last time) and there haven't been any recent reports here since @Theklan on 1 December.

At about 21:30 UTC today (22 November) I'm simultaneously logged in on en.wp but logged out on Commons. When clicking log in on Commons I was taken to the login screen to enter my details including 2FA.
I had previously logged in to Montage to review images for Wiki Loves Monuments and followed a link to Commons from there, but I am also logged into Commons in other tabs of the same browser (I didn't think to check them before logging back in, sorry).

It has been established that it's browser independent, although not seeming to impact mobile browsers at all.
I use monobook skin, and spend most of my time on en.wp although I do frequently visit Commons, en Wiktionary and Meta. I also read WikiVoyage occasionally
I don't know how to easily share my preferences but here are my settings for gadgets, beta features and custom scripts on my four frequently used wikis:
en.wp:
Non-default gadgets:

• Navigation popups
• find-archived section
• Display pages on your watchlist that have changed since your last visit in bold
• Citation expander
• HotCat
• Add an [edit] link for the lead section of a page
• Add a "Purge" option to the top of the page, which purges the page's cache
• Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms, as well as wildcard prefix searches (e.g., "Splark*") (report issues)
• Enable tracking bugs on Phabricator using the {{tracked}} template

Beta features:

• Paragraph-based edit conflict
• Discussion tools

I was logged out again today (17 November), at some point between 11:39 and 22:10 UTC. I was away from my computer from around 12:00 until shortly before I discovered I was logged out. I did browse Wikipedia on my phone during that time, but I was logged in there as a different user (and have not been logged out) so I don't think that is relevant.

And another logout, at some point between 15:19 and 18:36 UTC today 7 November.

I've just been logged out again, it happened some time between 12:36 and 13:10 UTC today (4 November). Switching browsers was not a factor this time, I made an edit in Firefox then went and did some stuff in other Firefox tabs, then came back to a Wikipedia tab I'd left open, clicked edit and found I'd been logged out.

@doctaxon It seems to be happening every 2-3 days on average:
(all times UTC)

I've just been logged out again (circa 21:30 UTC 26 October). I was reading (and made a reply) in Chromium and then switched to Firefox and reloaded a page that was already open and found I'd been logged out.
My edit was a 21:27 UTC I think I (re)loaded a page after that but I might just have read ones I'd opened previously. I logged in again at approximately 21:32 UTC.
My username is still Thryduulf

I was logged out at some point between 0814 and c. 1945 UTC yesterday (23 October). Sorry I can't be more precise but I was out all day so the logout happened either while I was away or on one of my first page loads after returning. I most recently logged in previously at circa 1136 on 19 October after a previous unrequested logout. My username is Thryduulf.

In case it's helpful, I've accidentally discovered that actively logging out doesn't prevent this from happening. Yesterday (18 October) I misclicked and logged out at ~18:35, logging back in straight away. Today (19 October) I was logged out by this bug at some point between 09:42 and 11:36.

In T372702#10223446, @Reader_of_Information wrote:

Also, I wonder if this is happening to Chromium users only. Does anyone here have this problem on Firefox?

I don't know if this is useful information, but I was logged out twice in the circa 24 hours leading up to 20:15 8 October (I logged in shortly before that timestamp). I then remained logged in until some point between 22:43 on 10 October (I was logged in when I got a notification of and read a post made at that timestamp) and 00:05 on 11 October (when I reloaded a page I had had open). During this period I have edited only en.wp but I have also viewed Commons, Meta and en Wiktionary.
I have been logged in and have opened, closed and not closed pages in both Firefox and Chromium on the same desktop computer (running Xubuntu Linux). I've not logged in with this account on any other browsers of devices between the log out events. I think I read the 22:43 post on Firefox, but I was logged out when I reloaded the page in Chromium. In normal times I use the browsers fairly interchangeably and don't get logged out randomly.

I wonder if a/the way to do this is to have a human-defined machine-readable table of defined equivalences such that when VE is asked to convert from e.g. cite-web to cite-news it can look up which parameters are equivalent to each other. This would probably require there to be a standard master set of parameters that all citation templates can pick from and then map their own parameter names to. This might be a big job but it would be doable and would be a one-off.
Alternatively to a table, maybe the template data system could be expanded to have a WikiData-like "instance of" property for parameters?

In T367856#10043858, @Liz wrote:

I know, right now the replag is 61 hours.

What is the current status of this feature?
When implemented, will it allow multiple full blocks/multiple partial blocks from the same set of pages/actions but where one has talk page access disabled and one does not?
This is related to the ongoing discussion at [[en:Wikipedia talk:Blocking policy#Admin Tools and TPA Revocation]]

Saying "it may happen" is accurate whether it happens or not.
Saying "it will not happen" is only accurate if it does not happen.

@Kizule I don't know of any way to exclude phrases from search results, but I can certainly see use cases for it. I'm not sure it's quite the same thing as this feature request though, so maybe open a new ticket?

I was actively surprised that these two preferences were not adjacent when I went to turn on notifications for edits to my userpage.

Regarding T278357, intentionally signing with 3 and 5 tildes is rare (but not non-existent), but typoing 3 or 5 when intending 4 is relatively common. The intent of that ticket is to more gracefully deal with those instances by not adding a duplicate signature when it happens, changing the logic from "there is no signature here, I will add one" to "there is a partial signature here, I will add the missing part".

I agree. One suggestion that has been made before, which I like, is to include the redirect in the suggestion to make it clearer what's happening.

Hang on, this needs a lot more consideration before implementation as it will be actively undesirable, even harmful, in some circumstances. While no user is going to be confused about seeing "A Tale of Two Cities" when searching for "Tale of Two Cities", the same is not going to be true in every case - examples:

• Bush Twins → George W. Bush. Unless you know that this is a redirect to a section of the former president's article this is confusing and implies that George is a twin (he isn't).
• Diaoyu Islands → Senkaku Islands. Unless you know that one is an alternate name for the other this is going to be very confusing (and given the sensitivity of place names in disputed territories there could be other issues too)
• Cuba, Ohio → Cuba (disambiguation), Dark Angel (album) → Dark Angel. These will cause confusion as, as far as the reader is concerned, they have entered a precise search term - why is Wikipedia going to take them to an ambiguous title or a disambiguation page?

Readers will be wondering what have they done wrong and how can they get where they want to go? This is bad UX.
Other problems include:

• Making it much harder to visit the redirect page itself - e.g. to categorise it, nominate it for discussion, retarget it, overwrite it with an article, etc., especially if there is no "redirect from" note on the page.
• Obscuring the utility of redirects - if people do not travel via a redirect there is no record of it being used, making it much harder for editors to distinguish redirects that are useful from those that are not and removing a source of information used when considering the best target for a redirect. These will make it harder for readers to find the content they are looking for.

There is definitely a benefit to hiding some redirects in the search suggestions, but not all and likely not when the redirect matches the search string. Which redirects should be hidden and which should not is not something that can be done other than by humans. See T24251 for a proposed solution to this (note that this task will not resolve that problem in all cases, so the tickets should not be merged).

I think this is a duplicate of T24251

@DougWeller I can't help regarding video, but on en.wp there are instructions for screenshots at https://en.wikipedia.org/wiki/Wikipedia:Screenshots_of_Wikipedia (if you are sharing the image here (phabricator) you don't need to worry about the licensing template or uploading to Commons, just click the upload file button (up arrow on what I think is meant to be a cloud?) in the toolbar once you've saved your screenshot.

en.wp (at least) was agonisingly slow shortly before it all went down, and even after en.wp came back up I wasn't able to allow Oauth access to login here.

I agree with Ainali regarding opt-in/opt-out

My answers:

@ppelberg the status quo at least on en.wp if (some?) formatted text is pasted the user is given a choice about whether to paste plain text or wikitext. imo the choice (whether by model dialog or some other method) is very significantly superior to always doing one or the other.

The status quo is:

• Someone copies formatted text and pastes it into the source mode of a reply or new discussion
• A dialog asks whether they want to paste as plain text or convert it to Wikitext
• The user chooses whichever option they want.

I still don't understand what the problem with this is? As long as both options do what they say they will do, then it doesn't matter what people want or expect (and I expect that any expectation for plain text is just that there has never been any option until now).

I agree with Tacsipacsi - the current behaviour seems desirable to me. The issues I reported at https://en.wikipedia.org/wiki/Wikipedia_talk:Talk_pages_project#Pasting_templates were not that this option appears but that when the "use plain text" option is selected nothing is pasted.

Perhaps there could be some way in your global preferences to control which wikis you want to accept emails from?

In T278476#6996980, @ppelberg wrote:

@Thryduulf and/or @Whatamidoing-WMF: do y'all have a sense for how many often you've observed this happening and/or encountered pages where you think it might [i]?

---

i. Read: talk pages where infobox-like elements on the side of a talk page.

T277919 has now been marked as invalid, but the problem remains. It seems T25310: Global suppression does not work properly when the target has already been locally blocked seems to be the relevant task for that, but that's been open since 2010 and is marked as low priority, with two blocking tasks also marked as low priority. As the issue is still (imo) a blocker it might be worth considering whether it is possible/desirable to release a version of DiscussionTools that does not include username suggestions.

See also T277919 where the issue regarding username autocompletion was initially raised. With such tools very significantly raising the visibility of username lists, making sure they don't display ones that are potentially libellous (e.g. accusations of paedophilia) or contain non-public information (e.g. other editor's home addresses) is now a much higher priority.

I've just discovered the existence of T279400 Make the feedback link for New Discussion tool point to the project page about the New Discussion tool (not the Reply tool)
It would be desirable, but not essential, to fix this before rolling out further.

If using the reply tool to a reply to a comment and that comment is removed in the page edit:

• If the comment you were replying to was the last on the page, your unsaved comment disappears as is desired
• if the comment you were replying to was not the last on the page, your unsaved comment becomes an unsaved reply to the comment following the one that was removed.

I've just created T279424 Abandoned comments get resurrected (unsaved changes). This is a medium-low priority task which can be fixed before or after DiscussionTools becomes an opt-in feature.

If I've understood your question correctly, I would say that T277919 should be resolved before a version of discussion tools featuring pinging with username suggestions is offered as an opt-in or opt-out feature.
T276510 should definitely be fixed before DiscussionTools is offered as an opt-out feature, with a strong preference for fixing it before offering it opt-in.
T265750 is not a blocker for an opt-in feature but should be fixed before offering it as opt-out one.
The other tickets are not blockers for either milestone, but fixing those I've listed as medium priority or higher before making it opt out will improve the reception.

In T276614#6971461, @Pelagic wrote:

I'd regard T277919 as a blocker.

Restricted task? I don’t have permission to see it.

I'd regard T277919 as a blocker.

In T271773#6958013, @matmarex wrote:

This demo implements my proposal from T271773#6934879, with the "weird" order of Reply and Cancel buttons. I am open to changing it, but I'm currently convinced that it's a good idea, so to convince me otherwise, you'll need either better arguments or more people who disagree with me ;)

Perhaps a way forward would be a per-user option with a per-wiki default. That should work on all wikis that use only one script, or multiple scripts of the same type (e.g. Latin and Cyrillic would both have a whitespace requirement as default, Chinese traditional and simplified would both not have that). Truly multilingual wikis would just have to pick one (I guess whichever suits whatever the majority of comments are written in) and advertise the config option.

I generally agree with @matmarex 's proposal above, except that "cancel" should follow "post" in tabbing order and/or you should be able to navigate from one to the other using the arrow keys.

Regardless of what the user chooses, this should use the same as the preceding comment for all except the final character. e.g. in the sequence:
Comment1
:Comment2
::Comment3

It seems like the operation should be set by script rather than by letter/non-letter

I experienced it on the outreach wiki adding a comment to a non-empty page - https://outreach.wikimedia.org/wiki/Talk:GLAM/Newsletter/Newsroom but I was focused on leaving the comment rather than documenting exactly what I experienced (when I wasn't expecting to experience it).
I tried to reproduce it on a few other wikis (listed in my en.wp feedback comment) but didn't manage to, but I didn't get a welcome message on every one of the wikis and I don't know how to force seeing it.
I followed a link to the outreach wiki from somewhere but can't remember where that was. In my testing I went direct to each wiki (no idea if that is relevant)

Adding to the pile on. The purpose of interface admin permission is so that non-technical administrators do not accidentally make breaking changes to technical pages. Administrators can still view these pages.

In T36244#6453416, @Nemo_bis wrote:

In T36244#393271, @Thryduulf wrote:

To perhaps clarify slightly, what I believe is being asked for here is for the historical revisions of pages with transcluded content to display the transcluded content as it appeared at the time of the historical revision.

How does this differ from T2851: when viewing an old version of a page, use old version of templates?

Users who are subject to a partial block from editing will be being watched to see if they are circumventing the block by copy-paste moves (at least on large projects). If they do that, then their actions can and will be reverted by others and they will be subject to increased sanctions. As long as the documentation of the feature mentions that there are workarounds (ideally bearing in mind WP:BEANS) then I don't see this as blocker to implementation.

Why has this been closed as "resolved" (twice) when nothing has changed and the requested behaviour has not been implemented?
If no changes will be made then it should be "declined", surely? (for the reasons I noted in my last comment I think the change should be made, and would strongly encourage an explanation why the status quo is more desirable, but that's separate)

As someone who frequently deals with I agree with most commenters here that this change would be a good one.
Regarding the talk page issue raised, I don't think its relevant. I use "article" in the examples below but it also applies in other namespaces:

On the English Wikipedia there is a frequently expressed desire for redirects from misspellings (and similar) to be excluded from the search suggestions drop-down.
A magic word NOSEARCH (or similar) that:

• excluded such pages from the search drop down (except for exact matches?)
• (for redirects) placed their target higher in the drop down list and full search results page (to the top if an exact match)
• lowered non-exact matches in the full search hits but did not remove them entirely

would satisfy this desire and, as I understand it, also satisfy the original request will limiting (to almost nothing) the potential for abuse noted by @MZMcBride in comment 4.

In T46787#6078162, @Trizek-WMF wrote:

Has using a system similar to the raw watchlist editing mode been considered?

I think this idea would be good, and would work for me. I think if you're wanting to exclude very many pages that you'd be better off using an opt-in system (which is T66090) - although I I realise that would require that to be or to have an option for "only these" instead of/in addition to "plus these"

@Tgr thank you.
The initial idea emerged in a discussion prompted by a local file being shown instead of the file from Commons a bot expected. At least on the English Wikipedia, there is already a warning if you try to upload a local file with the same name as an existing Commons file and only Admins can do it (T2889 seems relevant).
This means the problem (en.wp calls it "shadowing" I don't know if that term is used elsewhere) is almost always caused by a new file being uploaded to Commons that has the same name as an existing local file. To my knowledge there is no current way for this to be exposed to the uploader at Commons (given that it would need to check every connected wiki I'm guessing adding this would not be practical, which is backed up by T16888#189718 unless things have changed since 2009), or exposed automatically to the local wiki (this might be T18280).
There is a bot on en.wp operated by @Green_Cardamom that identifies newly shadowed files but I don't know how it works. These files are then dealt with by humans.

As I understand it, this proposal is suggesting:

• Change the file: namespace such that it only displays files hosted at Wikimedia commons
• Creating a new LocalFile: namespace that functions identically to the existing File namespace, other than displaying only files hosted on the local wiki
• Moving all existing locally hosted files (and their talk pages) from the file: namespace to the LocalFile: namespace (this may be possible to do using bots?)

There should still be a way for a user blocked from creating pages to get from a redlink to search results for the redlinked title. Whether that is a link from a message saying something like "this page does not exist and you do not have permission to create it" or (maybe less preferably?) simply being taken to search results when clicking a red link or some other method I don't know.
The reason is that these search results can be good way to find the article one intended to link to when the error (e.g. misspelling) is not immediately obvious.

That could get unwieldy if lots of users are partially blocked from a given article/set of articles, something quite plausible in topic areas like Israel-Palestine or US Politics. I can also easily foresee it being regarded as a badge of shame (or for certain people a badge of honour) to have their username prominently listed like that.

Confirming that this bug still exists in Android app 2.7.50305-r-2019-11-26 appearing exactly as it did in the 2018 screenshot in the description (although it's now reference 22)

In this edit Parsoid (presumably) replaced   in a reference name with a plain space (line 258 change block) when I made an unrelated change to the page (the addition of a parenthesis at line 289 was the only change I made, everything else is VE/Parsoid). It left the non-breaking spaces in the reference title alone.

In T59437#5658604, @John_Broughton wrote:

https://ux.stackexchange.com/questions/81134/should-modal-dialogs-be-movable seems to show a (rough) consensus that when a proposed solution to a dialog is to make it moveable, the dialog itself is poorly designed. That implies looking for a different solution that addresses the underlying user problem.