Mon, Jan 27
canceling this, will re-write
Fri, Jan 24
Community discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=937297103#RfC_about_addition_to_Special:Import supports the change.
Thu, Jan 23
Thanks for the cleanup!
Mon, Jan 20
Agree, this shouldn't require a community buy in as long as the default was still "all pages" - adding a "filter" option (perhaps a collapsed one like in user contributions) would be non-intrusive to readers and could certainly be developed in stages. This would only be an output display filter, not actually changing categorizations. Suggest "namespaces" be tackled first as that seems to have the widest utility.
Follow up on https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Partial_blocks#specialblock-partialblock-banner
This is appearing on enwiki, we have local discussions and support for this - and are still actually working on our policies for it, so would probably be better to direct our admins to our local discussion.
Thu, Jan 16
I think the bigger issue here is that this feature would allow anyone, even IP editors, to "extend" someone elses block to any page.
The where isn't super important - as long as it is well advertised and attended. So if you put it at VPR, advertise it at VPT, AN, WT:RFPI, T:CENT for example. This isn't a really big deal that would need site notices, or voter invitations though.
Wed, Jan 15
This request shouldn't be dependent on if T160233 is ever done.
Was there any community discussion on this? As a regular at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_page_importation , I'm not seeing any sort of demand for this.
If revision has a revdel'd summary, researches can not normally view it - however, if the entire page is then also deleted, researches can view the revdeled edit summary.
Couldn't this still be warranted? Example scenario:
- Delete a page
- Use Revdel for something like only some edit summaries
- Restore the page
Tue, Jan 14
Sun, Jan 12
Just like my comment in T194529, I think this may be better dealt with with an overall "actions" list for partial blocks. Currently we have a couple of actions that someone can be blocked against (createaccount, sendemail) - why not have more - which should solve other tickets as well? UPLOAD and MOVE seem like ideal early candidates. massmessage really is a limited offering, so I'm not too concerned with this "loophole" - but the concept could use the same enforcement mechanics perhaps?
Fri, Jan 10
So yes, on enwiki the enabled-by-default reftoolbar (v2) gadget does not have this problem so our average editor using source edit mode doesn't have the problem, but if they move to VE and get citoid their web references may get corrupted
@Whatamidoing-WMF yes I think, it is very confusing to know which is in play at any time, as there is no branding attached to any of the front ends of the tools!
Thu, Jan 9
@Mvolz in T210871 the problem isn't so much about "removing parameters" but it seems to be that the process is following third party redirects and then replacing the entire path (and coincidentally in the example it is resulting in adding parameters). In replacing the entire path, editorial control of references is being lost (and in the example also results in a references that is useless for readers and editors)
Wed, Jan 8
Notably the behavior is different (and much worse) on VE then source editor.
My connections should have been from North America.
Got in on enwiki, failed at ~75% on dewiki, eswiki with this same error.
Mon, Jan 6
CSS hack applied in enwiki ( https://en.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&type=revision&diff=934333365&oldid=928521497 ) once this is resolved that should be backed out.
Dec 28 2019
It's non-default, and only run if someone actually tries to run it, but would mean that the page is always consistently laid out (as far as displaying it). As far as should a query that someone is specifically asking to be run - be run why not? Do we really need a shortcut (that as noted isn't going to always be accurate) to bypass this? We don't put what-if-shortcuts on the rest of the controls there. (e.g. If a project removed the bot permission, or auto\patrol permission from all groups - we don't check for that and hide those links)
What I'm saying is that when viewing Special:NewPages, the control that uses the "MediaWiki:Rcshowhideliu" label should always be present, it shouldn't be added and removed based on the current set of permissions on a project. It isn't a bad thing that clicking "hide registered users" would produce no results. The permissions of * could have just changed 1 second ago. Additionally, regardless of if the control is displaying on the page or not, the control should actually function if called - resulting in no results if there do not currently happen to be any.
Dec 27 2019
@DannyS712 as far as the change goes, available permissions can change at anytime, so this filter shouldn't appear or not appear based on the current permission mapping. The expected result should simply be that there are no results if there are no results - this keeps the behavior consistent across all instances.
Dec 26 2019
Dec 24 2019
No rush, just wanted to get this on the board for review, thanks for the udpates!
So as soon as a page comes up that is not able to be handled, perhaps it should default to the "read as wiki" view?
Dec 23 2019
I just looked at my own enwiki talk page, is is saying there are NO discussions at all (https://en.m.wikipedia.org/wiki/User_talk:Xaosflux) is this the same problem being discussed here? In order to see anything a reader has to click on "Read as wiki page".
Dec 22 2019
Would any work on this also solve T119072?
Would be useful, especially for looking for new non-redirects - perhaps if this could allow for the not operator, such as "!mw-new-redirect"
Dec 18 2019
@suffusion_of_yellow regarding "range talk", lets assume for a moment that it did exist - how would you expect notification/clearing of such a notification to function?
Dec 17 2019
@suffusion_of_yellow I suggest refining or splitting it to multiple tasks as well. Is your core concern communicating with "mobile editors" or "logged out mobile editors"? The former appears to have at least some form for notice they have new talk, while the later appears to have none.
From test test in my prior comment and the other notes above, it appears that we are delivering newtalk notifications one way or another to:
I made a couple of edits as an IP, using desktop, and using mobile browser.
I used a logged in account to leave User_talk: messages for that IP user. I observed the effects on desktop and mobile site I did not use the mobile app
In response to Tech/News/2019/51 which said this feature "will come to most wikis on 6 January." I am following up with User talk:NKohli (WMF) as to the current plan for English Wikipedia, as it is not clear what is this "most wikis". Where is this list?
Dec 14 2019
Dec 10 2019
Dec 9 2019
So to move forward on this - is there actually a current way to define that one "user ... has more permission" than another? What would this even be based on? Being able to add a user to "group x" can be added to any group. If this is not done, is there a task for it (which would be blocking this one)?
Thanks @TheDJ so it sounds like at the least this is blocked pending other future development - but not necessarily reason to never do it.
Dec 8 2019
@Izno can you expand on why doing this server-side is a problem?
Agree - this is really a feature request more than a bug, but it has been wanted for a long time.