Some more screenshots, before double-click

@Whatamidoing-WMF, saw your message, please pay attention.

In T243076#7314599, @chaim wrote:

Ok, I'm just the messenger but I'll try to explain the community position.

The use of protection in the Hebrew Wikipedia is defined so that we use mainly a basic level of protection.

But there are still issues that the community believes need to be protected, rather than raising the level of protection, we prefer to lower the level of permissions for people at increased risk, and the community believes the risk goes down for users who have made 100 edits and 30 days have passed since signing up.

@IKhitron Can you check that I was not wrong?

In T287701#7299218, @Tacsipacsi wrote:

In T287701#7298637, @IKhitron wrote:

And one more thing […]

I could not reproduce this in Chromium 90.0.4430.212 on Debian 10.10 “buster” on Hebrew Wikipedia logged out, using the default new Vector skin. I used the following wiki text:

<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>

<div class="hebrewRefList">
<references group="hebrew" />
</div>

and saw this:

In T287701#7298652, @Quiddity wrote:

In T287701#7298615, @IKhitron wrote:

Very well. Could I, please, get one example where adding lang changes something in direction on any device? Thank you.

If I understand correctly, the lang attribute does not have any affect on the direction of text. It is not required for this. However it is a useful additional standard piece of markup to include for both semantic reasons and for accessibility reasons (e.g. for screenreaders it might make the "voice" module change to one more suitable for speaking that language). Details about this are explained at https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts.html

And one more thing. I tried to fix by your recommendations, and it generally works. But there is a problem, that I couldn't fix until now.
If we use li::marker in references that have direction, it looks differently on different kinds of browsers. For example,
<ref group=hebrew>sometext</ref>
on a page where there were a lot of references in this group looks like this in most of browsers:

.hebrewRefList li::marker {
    direction: rtl
}

does not help. Tried all the possible values of direction and unicode-bidi, nothing helps. How can I fix this?

In T287701#7298080, @Tacsipacsi wrote:

As I wrote, such edits don’t worsen the situation in terms of web accessibility; the text was and remained inaccessible to people using screen readers, Braille translators and the like. Your tests do their job, they fix the directionality of the text, they simply don’t fix another issue.

In T287701#7283720, @Tacsipacsi wrote:

The example does lack the lang attribute for WCAG 2.1 AA-level compliance. It’s not directly connected to this class change, though; changing <div class="mw-content-ltr"> to <div dir="ltr"> won’t worsen the situation.

Sorry for bothering, but can I get an answer, please? Otherwise, looks like the lang parameter is not needed at all in this task, and without it, the millions of edits that should be done because of this task will be much easier. Thank you.

In T287701#7247687, @Jdlrobson wrote:

In T287701#7247642, @IKhitron wrote:

By the way, what does lang parameter add here?

https://www.w3.org/International/questions/qa-lang-why is probably the best explanation.

It also looks like this bug has been present on the Hebrew mobile site undetected for the last 10 years.. :(
https://he.m.wikipedia.org/wiki/%D7%9E%D7%97%D7%A9%D7%91#%D7%9C%D7%A7%D7%A8%D7%99%D7%90%D7%94_%D7%A0%D7%95%D7%A1%D7%A4%D7%AA

In T279674#7272137, @Jdlrobson wrote:

@IKhitron are you familiar with the WVUI library and how we transition to it? The first screenshot is the search before WVUI has been loaded and the second shows WVUI after it is loared and I think this is important context to understanding this issue. Why do you think it is irrelevant? Is there another bug occurring here that we need to understand?

@Jdlrobson, pay attention, the second screenshot you've added is irrelevant.

Danny, why don't you use the Watchlist messages, instead of inventing your own?

I see.

By the way, what does lang parameter add here?

It's not in 2 weeks. It already started on the new vector, for example.

It's not just div. It can be span, code, and more.

Actually, exactly one (< 1000) usage in our wiki is in <ref> replacing template, and it has impact on all the articles.

In T287649#7247031, @Jdlrobson wrote:

Backport completed and confirmed. This should be working now.

Already worked on this, before spiking with you. It is for sure disaster. There are many thousands of broken articles. Every user knows how to do this, and they all will need to learn it again, while most of them do not know html and css.

It's a disaster. I'm talking about hewiki. The examples are all our sources. We use

==References==
* Some local article
* Some local article
<div class="mw-content-rtl">
* Some article from US
* Some article from Britain
</div>

We can change this to dir attribute, but as I already said, you should give us a year. Working on common.css.

Hi. Can I understand from this that mw-content-ltr and mw-content-rtl classes will not work any more in the new Vector? Our wiki has 26,582 uses of these classes, and they show noncence now. Why did you do this? Why did not you announced a year before, so we can fix all the uses? What other classes are broken? Thank you.

In T287649#7245262, @DannyS712 wrote:

I'm using Chrome version 92.0.4515.107 (can check version at chrome://settings/help) and the vector skin. As far as I can tell, nothing changed in the CSS since last week, so I'm not sure. Maybe there was a change to core or vector that caused it?

In T287649#7245238, @DannyS712 wrote:

I logged out and back in in case my css was cached, but it still works fine. Maybe its due to personal CSS you have installed? Can you please try it with safemode and see if its still an issue? (Add &safemode=1 to the end of the url)

In T287649#7245212, @DannyS712 wrote:

@IKhitron would you mind clarifying what changed? I assume the problem is with the text you highlighted - how is it supposed to be displayed? Don't those links translate to "diff" and "2 changes" ?

I don't know if it is totally fixed on all possible browsers. But I can tell I did not see this starting, say, four month ago.

Thanks. Well, we didn't. I know because it was mentioned on other wiki.

In T241196#7191195, @Reedy wrote:

Until we disable the old version, the old checkpage needs to stay around. After that, it can be deleted.

In most case, you can just add people to the new version, as they will be using the latest release...

Hello, @Reedy. Congrats, it's much better. And also:

1. Why isn't this in the Tech News, so wikis could know to add the new names to the right page?
2. I understand we can remove names of those who updated to the new version from the old page, eventually deleting it? Because permanent synchronisation doesn't sound like a good idea.

Thanks.

I see. Very well, forget about it. Thanks.

I assume that one uses settings much less than watchlist.

Very well. As I already said, it doesn't metter to me.

For example.

1. Open GlobalWatchlist.
2. Click Settings.
3. Wait a second to load.
4. Click Cancel.

Expected:
Return back.
Got:
Go to GlobalWatchlist.
That is, I'm not going back to where I was, I open the GW from scratch.

It will decrease additional code complexity and maintenance costs, in UI.

Not so important to me, but FYIO, it doesn't work properly.

And what about to allow to the user to set their own maximum, 10 or 20 or 50, in settings?

In T254055#7117368, @Volker_E wrote:

@IKhitron Would you mind sharing your dismissal of this idea here?

Great. Thanks a lot.

In T217137#7108568, @Zabe wrote:

Done, sorry that this took so long :)

Hello again. Both namespaces are empty now.

In T217137#7078673, @dcausse wrote:

@IKhitron could add more precisions to your ticket esp. which wikis you consider the education program namespace should disappear?
Note that reading the system configation the Education Program appears to be still in use on several wikis:
cswiki
elwiki
enwiki
eswiki
fawiki
hewiki
itwikiversity
lvwiki
ptwiki
svwiki
ukwiki

Hello. @EBernhardson, @debt. 30 month later, what's going on. A week ago ruwiki asked the same, ant it's already done.

Even so, it doesn't mean they should appear in the rest for years.

In T229735#7065727, Iniquity wrote:

The question is, is it impossible to make the setting and hide these namespaces in all the wiki of the foundation for now? And then turn them back on, if necessary. No one will even notice, but this will at least reduce the load on the search filters.

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.