User Details
- User Since
- Jan 4 2015, 2:23 PM (480 w, 1 d)
- Availability
- Available
- LDAP User
- IKhitron
- MediaWiki User
- IKhitron [ Global Accounts ]
Fri, Mar 15
My attention was drawn to this bug after I saw this, when moving the help icon to its appropriate place:
I made a very stupid fix for now, from
Mon, Mar 11
In this case we definitely should consult to community first, because otherwise, from my experience, nobody will pay attention. A week discussion will put it on the radar.
Sun, Mar 10
"Opt-in" means that newcomers to enwiki, for example, do not get it by default, @MusikAnimal?
Sat, Mar 2
I request to cancel the change for hewiki, please. The community decided to ask this, in Village pump, with more than enough voices, at least 31 supported from 32 that participated. You can find the voting over here. Thank you.
Thu, Feb 29
Well, I tried a couple of times to explain you it has nothing to do with all this, with new pages for example, only with any edit in any article. I can see no way to explain more.
This is something else, of cource. For me, if some user can't be trasted to make their one edits in articles, they for sure can't be trusted to have an Interface admin flag, which was created just because the Foundation didn't think the admins (sic!) were trusted enough to have. You definitely can have different ipinion.
Wed, Feb 28
Don't know what are the relevant tags.
Seems obvious, but OK.
Sat, Feb 24
Tue, Feb 20
Really hope this is the case. The current text looks like "write us, we make statistic, and abandon the current task, if there are a lot".
One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.
Mon, Feb 19
Hi there. A couple of questions.
If patroller X has a patrolling script that adds tags to some existing edit, will it work?
If AbuseFilter triggered by autoconfirmed adds tags to theirs edit, will it work?
Sun, Feb 18
Wow, I created a task, a d didn't even remember the previous one that I created in 2017 wasn't fixed, thought it's a new bug.
Feb 15 2024
Feb 14 2024
Well, I've just tried four most significant scenarios, and it works fine.
Feb 12 2024
I've asked to retrieve my bot flag, which I temporarily gave away a while ago due to lack of time. I know pretty well what is going on now on Watchlist in different modes, because I wrote a huge gadget, Whatchlist Manager, years ago. So, I'm planning to create various use cases to check what is the state after the deployment. Starting from this one:
- Open some watched page at 23:59.
- Close it.
- Go away for an hour.
- During this period, another accounts edit this page: three non-bot edits, a bot edit, three more non bot edits.
- Return to the screen and open the Watchlist in group mode, showing new edits only.
I expect to see a new group with seven edits. As far as I understand from todays Tech News, I will see none. Those before because of the new change, since marking an edit as seen marks automatically all the previous ones. Those after because of the mentioned old bug in the new conditions. The best result will be if I see all the seven.
Jan 29 2024
Very well. Changing to "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights" will by OK for you? So that user must have at least one of these two.
Because as far as I understand, not being a regular on enwiki, just from reading that page, autoreview and autopatrol are synonims. If they are not, I can always change the task title to be "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights", to fit both cases.
What do you mean by "autopatrol"? (in enwiki, to be more clear)
You mean, each sysop's edit is patrolled by a human patroller? The page https://en.wikipedia.org/wiki/Special:ListGroupRights claims otherwise, see "Have one's own revisions automatically marked as "accepted"" in sysop chapter.
I'm not talking about autopatrol group, but about autopatrol rights. The user's edits should not be manually patrolled. Sysops have this included for there group too.
I suggest to restrict someone without autopatrol rights to get interface admin, because that means the local community does not trust them. Autoconfirmed is just automatic rights, not related to my suggestion.
I see now. You changed my words too, not just title. Itbrakes also the facts and my thoughts. I don't know why did you do this, but if you think the opposite of my suggestion, you can always create another task. I return my request back.
@JJMC89, I do not understand your edit. It has no sence now.
Jan 9 2024
I would suggest somethink like
Pages that use the JSON contentmodel will now use tabs instead of spaces for autoindentation. This will significantly reduce the page size.
The first sentence because otherwise it will look like "name":"John Doe" -> "name":"John\tDoe" conversion, or even asking the users to insert tabs manually. The second one explains the large impact more straightforward.
Jan 5 2024
Jan 4 2024
Dec 25 2023
Well, enough time later I can say that the problem disappeared a second after the consequent deployment. Unless somebody else continues experiencing it, I would suggest to close the task.
Dec 12 2023
You do remember it's an Android problem?
Dec 11 2023
Dec 9 2023
Even didn't see the misaligned part.
Dec 7 2023
Me too. But it was fine until days ago. It does not happen for non wiki sites. It does not happen with meta itself.
As you are not using any adblockers and 3rd party cookie blocking and considering that the timing changed since the issue first started for you, I wonder if the clock of your device is set properly. Maybe it is not set to sync automatically with timeservers ?
No blockers, the clock is fine, nothing changed on device, I make app updates on Saturday eves.
Another option is that the storage that the domain is allowed to use is completely filled up and that this accidentally also blocks updates to cookies from being saved ???
I have a lot of place on the disk, can there be other restrictions?
That would be strange, but as this is the Samsung browser, it's not unfathomable that it is doing some things that are outside the expectations....
I'm thinking if there is an easy way for you to empty local storage (we should really have a hidden page for this in mediawiki ... )
Maybe some js script I can run using global.js?
It's extremely worse now.
- Open some page on other wiki, it's logged out.
- Click on login, it's logged in.
- Go for five seconds to other heavy app on the device.
- Come back to the browser, the wiki page is still in front.
- It loads from the cache, the page is logged out again.
Dec 4 2023
Always.
Dec 3 2023
One more important thing I just found.
- Open Meta.
- Click open in a new tab a wiki A link from Meta.
- Click open in a new tab a wiki B link from Meta.
- Press F5 on the page from wiki B.
- Make sure both are logged out.
- Click log in on the page from wiki A.
- The page from wiki A is logged in.
- Go to the page from wiki B.
- It's still logged out.
- Press F5 instead of clicking log in.
- It becames logged in.
Dec 2 2023
Indeed, looks like the logging out happens after ten minutes of non-working on some wiki.
Dec 1 2023
I'll try to check if the problem happens after 10 minutes of leaving some wiki.
How long takes to login cookie to expire if "stay logged in" box was not checked?
The group1 train sync was at 9:13 UTC so that's more compatible with this being caused by a server-side change.
For your information, if you consider a browser-oriented problem. I did not make any update of Android or of the browser in the last few days.
Didn't work there in these days. I'll try now.
Nov 29 2023
Confirming beeing fixed, thanks a lot.
I just tried to open Talk:BBC ..., using index.php API. Surprisingly, I get "impossible name" error, while the same for Category talk sais that the page does not exist, as expected.
Please pay attention to T352257.
Nov 7 2023
For history purposes.
Confirming it started to work in last five minutes, and I get mediawiki.org results from timestamp after the problem started.
Oct 30 2023
Oct 16 2023
Great, thank you. I'll convert the file I work with, 350KB and hundreds of translations. If there will be any problems, I'll be back.
Oct 14 2023
Does this mean that the problem is solved, for non-deployers sake?
Sep 28 2023
Sep 27 2023
Wait, @matmarex. People react to this and say there are more problems here, in Firefox only. I've asked to come here and to describe them.
Well, looks fine to me.
Ah, very good. Well, ten minutes later, looks like it works. I'll tell here if I'll see problems with the gadget in the future. For now I suggest to remove the html code from the message, and if it will be fixed as expected, to close the task. What do you think?
Also, the text is slightly different, it can be decided in the same discussion.
Waiting for results a couple of minutes. But it is not the only difference from the original. The is also an – instead of :. Do you want me to suggest to the community to change it back, if the gadget will work, to fix this bug? I can fix this now ahead, and start a discussion. But I must change it again, if the comminity will decide against the colon.
I can try it now. It's my gadget, @matmarex. I'll be back.
It was done because the community wanted different version from that on translatewiki.
Sep 23 2023
Does this mean that contentmodel dispersion will also work from the next deployment?
Sep 21 2023
Aug 25 2023
Well, I really want to convert most of this to JSON. But it's too big because of the spaces, impossible to update frequently on tablets or mobils. So it will wait until this task is resolved.
Aug 23 2023
Can't you just freeze the map as it was three days ago, while the task is in progress?