I took a time to think about this, and decided to take the @Aklapper's suggestion. While the extensions' settings number as I asked will be better to me, I'm sure that most of the users will prefer the time zone in wiki settings. So, I've created T278440 and I'm closing this one.

Absolutely.

@DannyS712, something's wrong. Looks like this merge brokes the structure when there are site sites without changes, they appear in a list without any collapsing or collapsable.

BTW, Danny, if you do think it's better to use the Meta local timezone, please decline this task, I'll create another one with accordand description.

I just do not expect from international site to work like it's local. And the global list for me is a part of my local wiki, as before, with irrelevant address, not a part of Meta. But again, it's just me.

Because Meta is not supposed to be a local wiki for my local timezone, but it's just me. If Danny prefers, using the Meta value could be the second best for most of users that do have their local time there. In this case I will definitely use my local zone on Meta for this purpose.

Is this a request to add custom timezone support for the Global Watchlist only?

This will be the result.

Special:Preferences#mw-prefsection-rendering already offers to set the "Time zone" in the "Time offset" area, why not respect that setting instead?

Because the list is on Meta, it can't respect or even recognize this value for the user's home wiki.

It is not a bug, so there are no "actual problems". Only a feature to help 99% of users that do not live in Greenwich timezone to use the product without the same calculations of what does this timestump actually mean at each line.

I already described the steps. The settings are to see everything. Grouped. No live updates. What preferences?

Well, in 14 from 20 wikis I have maximum 3 pages in each.

In T276195#6875755, @DannyS712 wrote:

In T276195#6875610, @IKhitron wrote:

Just a thought. If you have two refresh buttons it may help. One to show first five wikis in the list. Another to show all. It can save a lot of performance if one presses the second button much less often.

I have no real idea how to do that, and it'll be confusing with how those work, how they interact with each other, and the live updates mode. My grant to develop the extension is currently over, and while I'm planning to request more funding for continued development and support for now this isn't a priority.

Tell if you change your mind one day, I'll give full answers. Looks like it should took to implement all this for 30 minutes top.

In T276195#6875602, @1234qwer1234qwer4 wrote:

On my device, the global watchlist takes just above 3 seconds to reload. 50 might be a bit high, but why not.

I think concerns about the time it'll take to reload might be a bit exaggerated, since if I recall all of the sites are loaded in parallel, so its based on whichever site takes the longest to load and process (for me thats enwiki) and any other sites added that don't take as long shouldn't result in a longer overall load time.

Just a thought. If you have two refresh buttons it may help. One to show first five wikis in the list. Another to show all. It can save a lot of performance if one presses the second button much less often.

I used the script with 20 wikis. Now I use it for 5 and the script for the rest.

"Freezed view" is a way to freeze the top line of the screen when scrolling, you use it in the watchlist.

1. Open the global watchlist.
2. Wait until there will be at least 1.5 screens of edits.
3. Scroll down a screen.
4. You can see the top line with the buttons remains at the top of the screen, see lines X - X+... below, and also see the bullets of the lines X-2 and X-1 at side.

At least for me, it is. Between the first unseen edit on this page until the last one, both with the same name.

I expect not to see Y again, and all the edits of both pages see in X group, as in Special:Watchlist, this is why.
You can check over there how is it implemented.

In T275437#6850970, @IKhitron wrote:

In T275437#6850610, @Urbanecm_WMF wrote:

In T275437#6850596, @Pchelolo wrote:

This ticket is not a UBN. We've had issues with mass message before, and there's no indication of widespread jobs failures.

Feel free to deprioritize it. The graphs I linked earlier (and that are outdated, as you noted) scared me, so I preliminarily set the priority to UBN. If you think this is not UBN, no objections for decreasing the priority (or reseting to Needs Triage).

FYI: T218511 is on 3 hours (sic!) delay on Meta now.

In T275437#6850610, @Urbanecm_WMF wrote:

In T275437#6850596, @Pchelolo wrote:

This ticket is not a UBN. We've had issues with mass message before, and there's no indication of widespread jobs failures.

Feel free to deprioritize it. The graphs I linked earlier (and that are outdated, as you noted) scared me, so I preliminarily set the priority to UBN. If you think this is not UBN, no objections for decreasing the priority (or reseting to Needs Triage).

In T275303#6846975, @DannyS712 wrote:

@Iniquity so this should really be documented somewhere, but the order is based on the order edits are made in, and then if there are multiple edits to the same page their are displayed using the timestamp of the latest, but (I'm pretty sure) still sorted using the timestamp of the oldest. Maybe we can add an explicit sort function watchlistUtils...

As you wish. For me, it will look wierd if it "jumps" from side to side on the same page.

Just a thought. Can you put the collapse button on the line center, nevermind what is the uselang and what is the wiki? It should be much easier.

Well, @DannyS712, it's on 30.

It will work better if you allow to make uselang language permanent in preferences, as I already suggested.

But, on the other hand, how can you be sure that the user does not prefer the foreign language preferences. He set them to use these wikis, including reading the diffs and the history pages.

I see. You're right.

OK. So how is this different from the current state? It does show the wikidata labels on the Meta preferences language, or overrided by uselang, doesn't it?

On which wiki? If somebody turns on a computer, opens a browser, opens the GW page on Meta, you do not know what wiki does this user prefer to work on.

I mean, how do you know which language you should use to override? How do you now that I prefer Hebrew without me saying this explicitly, for example by using uselang?

How can you use the language of local wiki? You do not know what is this language and can't recognize this.

Yes, I have all rtl wikis on Hebrew, ruwiki on Russion, and the rest on English. So?

As I already said, for my sake uselang is quite enough. Don't know what do you want achidve with this.

Confirm that it works on testwiki.

If I understand properly, I should see the results on testwiki now?

In T260862#6824810, @DannyS712 wrote:

So, unfortunately, there are some errors with the train (T271344: 1.36.0-wmf.30 deployment blockers), specifically T274589: No atomic section is open (got LocalFile::lockingTransaction)
As a result, there is a chance that the train will be rolled back, switching metawiki from wmf.30 back to wmf.27. There are a number of changes to the GlobalWatchlist extension between .27 and .30 that, in my opinion, are necessary before deployment. Accordingly, per discussion in #wikimedia-operations, we won't be deploying the extension today.

However, we are still backporting the fixes for the issues identified to wmf.30, so that once the train blocker is resolved this can proceed as planned

Maybe I needed a deep refresh once more. It works fine now in all cases.
On LTR interface:

Are you sure? The jenkins-bot did not leave a comment this time to say it's already there, and nothing changed visually.

@DannyS712, I'm here, but where is the jenkins-bot?

In T274313#6823802, @DannyS712 wrote:

I didn't think about the interaction with CSSJanus flipping stuff, since that wasn't the case for the user script.

Well, can you try to change the code to

.ext-globalwatchlist-feed-site {
	/* @noflip */ text-align: left;
	/* @noflip */ direction: ltr;
}
/* Handling of rtl wikis */
div[ id^='ext-globalwatchlist-feed-site-he_' ],
div[ id^='ext-globalwatchlist-feed-site-ar_' ],
div[ id^='ext-globalwatchlist-feed-site-azb_' ],
div[ id^='ext-globalwatchlist-feed-site-ckb_' ],
div[ id^='ext-globalwatchlist-feed-site-dv_' ],
div[ id^='ext-globalwatchlist-feed-site-fa_' ],
div[ id^='ext-globalwatchlist-feed-site-glk_' ],
div[ id^='ext-globalwatchlist-feed-site-ks_' ],
div[ id^='ext-globalwatchlist-feed-site-lrc_' ],
div[ id^='ext-globalwatchlist-feed-site-mzn_' ],
div[ id^='ext-globalwatchlist-feed-site-nqo_' ],
div[ id^='ext-globalwatchlist-feed-site-pnb_' ],
div[ id^='ext-globalwatchlist-feed-site-ps_' ],
div[ id^='ext-globalwatchlist-feed-site-sd_' ],
div[ id^='ext-globalwatchlist-feed-site-ug_' ],
div[ id^='ext-globalwatchlist-feed-site-ur_' ],
div[ id^='ext-globalwatchlist-feed-site-yi_' ] {
	/* @noflip */ text-align: right;
	/* @noflip */ direction: rtl;
}

?

Found the problem, trying to solve.

In T274313#6821779, @Legoktm wrote:

Ack. So I think the CSS solution just isn't going to work, instead I think we should identify whether the remote wiki is LTR or RTL, and then wrap the contents in <div dir="ltr"> or <div dir="rtl"> accordingly.

Now that I typed it, I'm not sure looking at the directionality of the wiki is right, shouldn't we look at the directionality of the user's chosen interface language on that wiki? My interface language is "English", so I would expect my watchlist to be LTR, even on RTL wikis.

Thanks @DannyS712 and @Legoktm. It was definitely merged, and it's much better now, but not enough.
See how it looks on LTR wikis:

In T274313#6818940, @DannyS712 wrote:

See https://meta.wikimedia.beta.wmflabs.org/wiki/Special:SiteMatrix - there are hebrew and arabic testwiki, so it should be possible to test there

In T274313#6818502, @DannyS712 wrote:

I can't merge it, since its my patch, but once its merged it can be tested on the beta cluster to confirm whether it works, and if it is we backport to testwiki.

Too late. They are already here.

In T274313#6817494, @DannyS712 wrote:

In T274313#6817312, @IKhitron wrote:

Well, @DannyS712, I still have no normal F12 tools, but try to replace the line 62 selector with

.ext-globalwatchlist-feed-site

Done in patchset 3

Well, @DannyS712, I still have no normal F12 tools, but try to replace the line 62 selector with

.ext-globalwatchlist-feed-site

I do not know how to do this, never tryed.
The script works fine for both cases, up to now.
Unfortunately I can't check the selectors using F12 tools by myself, probably until Thursday evening.

Well, @DannyS712, I think the patch will fix the problem of rtl wikis on ltr language page.
But I do not believe it will fix the problem of ltr wikis on rtl language page.
Please open the watchlist with uselang=he. As you can see, all the wikis are aligned to right. It should not happen without the patch. Maybe there is a problem with css selectors on the line 62, thay must align all the text to the left without the patch.

I see. Well, I haven't +2, of course, so I'll just take a look to the code and wait.

You can lie. Wait 5 seconds with the message, it will drop the number or users with irrelevant message from 100% to 1%.

I don't. I know it works, it's my code. I just was affraid you can't proceed to the deployment without enough reviews.

In T260862#6816943, @DannyS712 wrote:

What exactly would you have it do? That message is shown if the javascript is not loaded. If the message was removed, and users who don't have Javascript enabled tried to visit the page, it would just be blank for them...

Show this message with delay, for example.

So, you don't need me for +1? If so, there is no need to call him.

@DannyS712, you've asked me to review the code, but I'm not a developer on that level. May I call to a real developer that understands a lot in RTL?

In T260862#6816915, @DannyS712 wrote:

In T260862#6816864, @IKhitron wrote:

Congratulations again, @DannyS712! Three little issues that should not disturb to the deployment tomorrow, but should be fixed soon.

1. There is a second delay between opening the link Special:GlobalWatchlist and the watchlist work start. In this time, we can see an error message that we have no Javascript on this browser. It should be removed or replaced.

The error message is only shown until the javascript is loaded, and there is no delay coded into the extension for that - as soon as your browser downloads and executes the start of the code, the message is replaced.

Still, it's a wrong behavior.

2. You can add more than five wiki fields on Special:GlobalWatchlistSettings. The settings list should be aware of the wiki variable for maximum number of wikis.

You can add more fields, but you can't save them if there is more than 5 - its allowed to add extra fields because there is no easy way to reorder them

Yes, I know you can't save, but it will be better if you can't add. About an easy way - I suggest to remove the "Add" buttons at all, and always show maximum number of fields, empty or not. On save you read all the fields and filter out the empty ones, in any order.

3. You've commented out the code I wrote for rtl wikis, because "CSSJanus should handle it", or something like this, but it doesn't. The GW appears wrong for rtl wikis on ltr language page and for ltr wikis on rtl language page.

Okay, I forgot to test that out - handling at T274313

Thanks.

N3: The bug for empty lists fixed, thanks a lot for this.

Congratulations again, @DannyS712! Three little issues that should not disturb to the deployment tomorrow, but should be fixed soon.

1. There is a second delay between opening the link Special:GlobalWatchlist and the watchlist work start. In this time, we can see an error message that we have no Javascript on this browser. It should be removed or replaced.
2. You can add more than five wiki fields on Special:GlobalWatchlistSettings. The settings list should be aware of the wiki variable for maximum number of wikis.
3. You've commented out the code I wrote for rtl wikis, because "CSSJanus should handle it", or something like this, but it doesn't. The GW appears wrong for rtl wikis on ltr language page and for ltr wikis on rtl language page.

N3: The bug for empty lists fixed, thanks a lot for this.

In T260862#6808738, @DannyS712 wrote:

since my comment above I actioned the TODO and merged it into ext-globalwatchlist

In T260862#6808666, @Aklapper wrote:

Ah, thanks for the explanation. So the group doesn't exist on twn, instead of "it's broken".
Indeed, https://translatewiki.net/wiki/Special:Translate/ext-globalwatchlist-script shows Message group: All > Recent additions.
Maybe https://translatewiki.net/wiki/Special:Translate/ext-globalwatchlist was meant which shows Message group: All > Global Watchlist instead.

In T260862#6808659, @Aklapper wrote:

The link is not broken and works here. If you think that something is broken then please always include why you think that something is broken - thanks.

In T260862#6798579, @DannyS712 wrote:

Yes, ext-globalwatchlist-script should also be translated (TODO they should be merged, its no longer useful to keep them separate) - I'm not sure what you mean by unlock it, you should be able to translate at https://translatewiki.net/wiki/Special:Translate/ext-globalwatchlist-script

@Johan, I suggest to remove the message entirely from 2021/06, because it's already Thursday evening, the issue is closed very soon, and add it, for now, in "Recent changes" of 2021/07. We can move it again, if there will no be deployment next week.

In T260862#6804671, @DannyS712 wrote:

Also, the message included "You can watch up to five wikis. You can watch more wikis in the future." - as far as I know there are no plans to increase the default limit or override it for WMF config, and any such change would probably need approval from the performance team first.

In T260862#6798579, @DannyS712 wrote:

Yes, ext-globalwatchlist-script should also be translated (TODO they should be merged, its no longer useful to keep them separate) - I'm not sure what you mean by unlock it, you should be able to translate at https://translatewiki.net/wiki/Special:Translate/ext-globalwatchlist-script

Thanks, done.

In T260862#6798570, Legoktm wrote:

While I understand the grant said Meta only, the extension should be deployed to testwiki first for testing purposes.

Hmm, okay. Once its enabled on meta, is it okay to then disable it on testwiki?

In T260862#6793519, @DannyS712 wrote:

https://translatewiki.net/wiki/Special:Translate/ext-globalwatchlist

In T260862#6793424, @DannyS712 wrote:

In T260862#6793411, @IKhitron wrote:

@DannyS712, do you need us to translate MediaWiki messages on translatewiki toward the deployment?

There is nothing blocking deployment in terms of translations, but any contributions would be welcome, as always.

@DannyS712, do you need us to translate MediaWiki messages on translatewiki toward the deployment?

Another possible solution: The line above was added for better orientation. Now, when we have section names, the line above the header is not needed any more.

No. What I'm saying that if you display a part of section from any reason, you should not give her a wrong name. Nkw one can understand the line is the part of the wrong section. You can show both names, it will solve the problem. Or you can find another visualization.

I do not say if the first name should or should not be here. I do say the second name should be here for sure, the last header before the quoted line, and it's not here at all.

Thanks. I do not think I am able to do it by myself.

In T268950#6756094, @matmarex wrote:

@IKhitron Can you link to a few examples? I just looked at about 20 diffs from my watchlist and didn't see such problems. (I filed T272314 and T272315 though…)

In T272607#6765925, @DannyS712 wrote:

@IKhitron no other special page has handling so that links to it are shown with a uselang parameter, and without the uselang parameter the global watchlist will be shown according to the language set it your preferences, not the page/content language of the wiki. I don't really understand why this is needed or useful