@scfc, you can try reading [[w:he:MediaWiki:Gadget-WLM.js]].

Once again, after I fulfilled your recommendation.

It was not reproducible from the beginning, just suddenly happening a couple of times every day. But no problem, I'll do this.

In T218511#5215295, @Izno wrote:

You should probably provide new instructions to reproduce. I've not had this issue all day today.

Pay attention. The wrong data in watchlist problem is resolved, but the original issue of this task, "After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)", isn't.

24 hours after group 1 deployment. I do not see any problems.

In T218511#5186070, @aaron wrote:

In T218511#5185892, @IKhitron wrote:

Group 1 deployed, the problem continues.

Unread things marked as read?

Group 1 deployed, the problem continues.

Well, group 1 deployed. It's much better now, but there are some problems from the last week.

Well, there is a new bug now, see above. Maybe it comes from this one.

Unfortunately, a lot of people in two wikipedias (at least) are complaining, with js, including myself.

And now I can see a page with no bold edits at all, but with edits I never read.

Now I can see that the original issue continues. Listen, the problem is at all in this task, or it's something else?

And I saw a first case of completely read page, marked as unread.

A pity that @Reedy believes it's not crucial. It was annoying until today, and now, for a week at least, the Watchlist can't be used at all any more - you can't know what edits are read and what are not. A week without watching pages in all wikis. A rollback of one version will solve the problem. Thank you.

Digged a little. For each page, that has at least one unread edit, most edits marked as unread, as far as they are on watchlist page, at least. I can see an example page, with 35 from 54 unread today, 36 from 53 yesterday, 12 from 24 the day before yesterday. For example, the last edit 3 minutes ago marked as read, when I did not opened it yet.

The unread edits API works well.

@aaron.

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

In T218511#5106768, @TheDJ wrote:

@isaacl mentions: "I'm still having the opposite issue that I mentioned before: diffs being marked as read even though they weren't, but on occasion I also see the issue that everyone else is complaining about regarding diffs that have been read"

It is not what I was tacking about, but it seems as another problem.

Hello, @Lea_WMDE. I can see that the wikidiff2 (T203069) has been already deployed, so the original diff looks much better, and "Michgrig" fits the aim of the tool. Nevertheless, please check "Фил Вечеровский", with comma on the left diff side.

Brilliant idea! Thanks a lot. Could you, please, add a Special:Interwiki "ww" wikilink prefix ([[ww:3]] -> https://w.wiki/3)?

I can see it once or twise every day since then.

Thanks a lot. Filed T219781.

In T181001#5051977, @Aklapper wrote:

As described by Hashar, this can be achieved already: See task-status(status) on https://www.mediawiki.org/wiki/Phabricator/Help/Managing_mail

Closing as upstream has no plans to dump more metadata into the email body.

In T176095#5039561, @TheDJ wrote:

@IKhitron do you know if this is still a problem ?

Indeed, Aklapper. Thanks.

Aklapper, I'm sure that those two are the same problem.

You did not understand me. It was Chrome in that report, but because of updating lack, I do not think that browser is the problem.

I do not think it's Chrome. A couple of people said thay did not update the browser a lot of time. Do you still want me to ask?

There is one complain from March 10.

In T218310#5024527, @Aklapper wrote:

@IKhitron: Any links to discussions? Any info which browsers and browser versions people use?

A lot of complains in ruwiki, starting from yesterday.

I see. Thank you.

Well, @Lea_WMDE, it's Tuesday. And it's definitely looks different (compare to F27961541). But still wrong. Thank you.

Thanks a lot.

In T214712#4909479, @Johan wrote:

https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%99%D7%95%D7%97%D7%93:%D7%99%D7%95%D7%9E%D7%A0%D7%99%D7%9D&type=massmessage should be the right place.

Where is the log, @Johan? I can translate.

The category Category:{{#time:H:i:s}}.

1. Create new page (X) with a code

{{#time:H:i:s}}[[Category:{{#time:H:i:s}}]]

2. Wait as couple of minutes.
3. Open the console.
4. Run

new mw.Api().post({ action: 'purge', format: 'json', forcelinkupdate: 1, titles: '<The created page name X>' });

5. Expected and got: The page text will be updated to the API call time.
6. Expected and got: The page category at the bottom will be updated to the API call time.
7. Expected: the relevent category from the the previous paragraph will have the created page name X in it.
8. Got: it is empty.

Summary: the API call does not update categories any more.

Hi there. Is this a bug, so I should open a new phab ticket? Thank you.
https://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markadmins.json&diff=0&oldid=97533626
As you can see, DrBug is shown as moved, instead of Michgrig, two lines below.

@eranroz, would you like to review the patch?

I see, my fault. Thank you.

In T210496#4777675, @Agabi10 wrote:

It can't be added until the change is deployed. If added before it's considered normal text, not a magic word.

Not until this moment. I think you can make it stalled for now.

@Addshore?

Thank you. I also thought this can be the reason, but it's too confusing, indeed. New message is a good idea.

I believe you are right. Something missing. I'll try to reproduce. Or, possibly, it was already fixed unintentionally.

That was I saw in "computed" panel in Firefox.

Well, it works. I found the problem. Thank you for your help. The problem was that when I changed the name of message, and then choosed "another message" in the popup menu, it returned to "abusefilter-disallowed", probably as a browser bug, so I edited the wrong message. So, (A) can be closed as invalid. I still do not know why did I see the double message in (B), but I can't reproduce it any more. Maybe it was has something with (A), still I can't understand how is it possible. Or some system glich. Anyway, I'm closing the task as invalid now, and if (B) will return, I'll reopen it. Thanks again.

Actually, @Daimona, I gave you all that I have. If the problem is on my side, I do not see it.
I can't provide such a flag. Let's ask @eranroz.

What info do you need, @Daimona?

In T136104#4674572, @Charlie_WMDE wrote:

Can I ask you what concern you have with displaying the year at all times? If it interferes with an existing workflow or we have not thought of an edge case where it would cause problems, I'd love to hear about it!

I see. A pity. Thank you.

In T136104#4674250, @Charlie_WMDE wrote:

You could say: but when the people hover over a revision they'll see the year immediately

No, I can't, because of mobiles. But I can say: everyone sees the tool for the first time only once in their life. In all the rest uses they already know how does it work.

Just a question. Sorry if it was already asked. Why do we need at all the current year? What's wrong in "Apr 17 - Oct 17 - Apr - Oct"?

As far as I know, it's on many browsers. Quantum. And F5 is not an issue here, you can open another wiki page instead.

Thanks to @eranroz for calling me. Well, I think it can be very useful feature. But for me, soft redirect isn't the main issue, but tracking categories. There are thousands that we try to keep emptied, and removing them from the special page will be very helpful. About the list of excluded categories, excluded and empty categories, or excluded and non empty categories - I do not really care, because I can use query. But on large wikis it can't cope with this, so these lists can help too.

I see. @Amire80?

Non text - you mean wikilink?

I do not sure it is possible. I can tell that if I open now local prefs and change this, I'll see it back in a while. But I do not know how to reproduce the start situation, so it begin to happen.

In T204226#4591005, @Framawiki wrote:

Patch merged and deployed, but the problem is not totally solved as said in previous comment. We haven't any idea/can't do anything to resolve your exact problem.

Thank you.