Thu, Dec 12
Thu, Dec 5
I have updated the description as I have checked on multiple mobile devices and none have sections collapsed in any state (not even on pages that don't have Template:Editnotice).
Thu, Nov 28
And it looks like this task is turning towards hiding that button if wgMFCollapseSectionsByDefault is false by default, which is not why I filled this report.
Now go to a page which DOES NOT have Template:Editnotice at the top but do have sections. Example https://m.wikidata.org/wiki/User_talk:Pigsonthewing. Observe that the sections are collapsed.
@Ammarpad I can't reproduce this. For me it's always expanded on all pages.
Not all changes on Wikimedia projects have community consensus, especially for preferences that user can disable and even more so in Wikidata project.
Yeah that's what the issue is, it's not a normal feature which can be enabled/disabled, so IMO a consensus should be there.
Plus, even if there was no consensus, the fact that this was not challenged for five years, is enough to make it a consensus itself.
No I don't agree with you on this. IMO this is not challenged is because lack of use of mobile site by Wikidata users. And even if it not challenged it is really not user friendly, like if somebody go https://m.wikidata.org/wiki/Wikidata:Requests_for_deletions you can't even load that page properly with those sections expanded.
Yeah, this is what I think. A separate task for MobileFrontend: if the settings has been disabled sitewide, don't show this to end-user which gives false impression that a user can change it, when in fact no one could (like we have here).
Yeah, I originally tagged mobileFrontend but somebody removed saying mobileFrontend is doing what should be. So if you have better luck convincing them, feel free to go for another task.
Well I'm not seeing this wrong. If you care to go to settings in Mobile site there's a button ''Expand all sections''. And that button doesn't work as it says, so I wonder why it's not bug?
Wed, Nov 27
@Ammarpad Why it's not bug report?
Tue, Nov 26
No it happens on WD:AN and WD:RFD too.
Thu, Nov 21
Tue, Nov 19
https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress?username=Lamchuhan-bot already finished, in case you guys still need this.
Sun, Nov 17
Nov 8 2019
I again apologize for causing this much trouble.
Nov 7 2019
Nov 1 2019
Oct 13 2019
I don't think any local venue process request which got rejected from global queue because of user rename policy violations.
Aug 28 2019
What about the requests which are there because of blocks? i.e username policy violations blocks.
Aug 25 2019
Duplicate of T217099?
Aug 22 2019
Jul 26 2019
Ops! I misinterpreted that. I checked https://pl.wikipedia.org/wiki/Specjalna:E-mail/Stansfield (not a great method) which didn't turned up anything.
Jul 25 2019
Jul 10 2019
Jul 2 2019
Jul 1 2019
Thanks. I have performed this rename and has been completed successfully.
Jun 30 2019
@jcrespo: What's the status of deployment now? Can we do these big renames?
Jun 14 2019
Jun 9 2019
Yeah, no hurry..
May 28 2019
May 6 2019
Rename completed successfully.. Thanks!
@Marostegui Can we start?
Apr 30 2019
Thanks, I'll.. and have a Happy Holiday!
sure no problem...
we can do right now?
Apr 21 2019
Apr 11 2019
Cmt: Surprisingly this is no more happening.
Apr 1 2019
yeah successfully renamed. Thanks!
If you have time we can do right now.
Mar 30 2019
Mar 29 2019
Mar 28 2019
Does this also happen in a private browser window, without being logged in?
Yes it does, as you can see in those screenshots I'm not logged in. Same results on logged in too.
Mar 24 2019
Don't know how frequent this needs to happen for fix, but having flow on wikidata, mediawiki and zhwiki (those I faced many times) it would be helpful if this can be looked into. :)
Mistakenly checked that earlier gerrit link and thought it's no more happening, but it is not yet fixed. Checked some filter and they still triggering, although I haven't triggered on recent rename having account on 735 wikis. Sorry for unnecessary ping.
@Daimona Should we close this?
That patch has been merged and looks like filters are no more blocking page moves during rename.
edit: My bad I have clicked earlier gerrit link.
Mar 9 2019
Mar 4 2019
It's resolved, we can close it now.
Mar 2 2019
Feb 22 2019
Not that I know of, but maybe possible with rooted device.
Feb 19 2019
Feb 9 2019
Feb 6 2019
Feb 3 2019
Jan 16 2019
Until it's fixed I think we should stop renaming people. It's literally triggering everywhere and these (1, 2) are few latest triggers I could found and it's only for me, there are 70 other renamers who might be triggering somewhere.
Jan 15 2019
Rename successfully completed. Thanks.
Jan 10 2019
Jan 6 2019
@Daimona Just tested a rename and looks like hack you did isn't working.
@Lymantria In the log you mentioned, I tried to move it manually, so there's no summary.
Jan 5 2019
@Daimona : There are 7 of them triggering rn. If you want to fix, I have mentioned some of them in my message above. @Lymantria : This one on zhwiki is fixed (1). But there could be more, yesterday I found one on metawiki (2) triggering for a renamer whois isn't much active there, so it depends upon local edits of renamer.
Jan 2 2019
So we gonna go to each wiki and fix them or is there any one way to fix for all them?
Dec 22 2018
Until it's fixed, should we stop renaming people who have accounts on these wikis as it's happening with every rename there and we have alot of broken page moves.
Another issue in which the user is same but forgot the password of old account.
Dec 20 2018
Okay, no problem, but to me it's looks like that it's the same problem due to which those logs aren't being transferred.
It's mentioned in comment T85023#937090 and lock is also a global user right i guess.
This is known issue and there's a task already: T85023
Dec 16 2018
This is strange but it looks like all these filters (1, 2, 3, 4, 5, 6) started triggering after this rename (T209488), before that there are no such logs. And also these filters were not updated from long time.
Dec 14 2018
Successfully finished. Thanks!