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.

X is "auto-hyphenation can hyphenate here, and it's wrong"
V is "it should be hyphenated only here"
X is "auto-hyphenation can hyphenate here, and it's very wrong"
V is "auto-hyphenation can't hyphenate here, and it's wrong"

SuXperVcaXliVfraXgiVliXstiXcVexXpiVaXliVdoXciXoXus

Sure. And also, there are words where you want to hyphenate in places you decided, not the auto-hyphenation mechanism. So adding this manually will be very helpful.

In T85847#4587104, @Xaosflux wrote:

This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.

Sorry, I do not understand how can it help.

I'm not following why developers would be refusing to allow access to communities that have specifically reviewed and requested access for certain groups though? Do you have the phab numbers to review?

Of course, here you are: T188287, T187729. And also https://he.wikipedia.org/wiki/Special:AbuseFilter/90 and https://ru.wikipedia.org/wiki/Special:AbuseFilter/168.

In T85847#4586773, @MGChecker wrote:

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

If it will be done, is there a way to avoid contentmodel change from something to sanitized css, using abusefilter?

As you suggested, without the parameter. It is not urgent know, because you solved the problem with encoding, but maybe you can thing about it. And also about the warning I mentioned. Thank you.

Still, you can add one more option.

Honestly, I would prefer just get rid if this ?download=true and leave the url as https://quarry.wmflabs.org/run/290198/output/0/html, which works fine despite having the exact same binary contents.

Great idea.

Very well. Yes.

Very well.

Hi, @zhuyifei1999, and thank you. Could you please add an explanation somewhere in the output?

N3: About you asked: Last Quantum on Windows 7.

I understand your problem. Usually it's OK. But now the bug report goes to one particular person, that know all that. Here is your link: https://quarry.wmflabs.org/run/290198/output/0/html?download=true.

I do not see what to write here, but here you are:

1. Run 27365.
2. Check html output.

Thanks for calling me, but I'm the wrong person to ask this - I do not work with this wizard.
But I agree you should not spend your time on wikEd compatibility. The wikEd gadget has a lot of problems, and I see many complains that it destroys either interface or pages wikicode. Avoiding common work of these two tools is indeed a good idea.

Great, thanks.