Indeed.

Probably, but not sure.

Pinging @Kipod and @eranroz from the original task.

See, for example, here, 223-227 in this revision.

Appears it does work in File namespace, both for local and Commons, but still does not work for Special pages. At least for me, on any wiki site.

I see. Thanks for your help.

How can it work if linktarget does not have any data about non-existing templates? What will be the id in templatelinks and where will be the tempkate name stored?

In T299417#7814637, @Ladsgroup wrote:

I'm not 100% sure I understood your usecase but if a query to templatelinks used to look like this:

SELECT tl_from, tl_namespace, tl_title from templatelinks where tl_from = 5974403;

It will change to:

SELECT tl_from, lt_namespace, lt_title from templatelinks join linktarget on lt_target_id = lt_id where tl_from = 5974403;

It seems the new table has not been replicated to the cloud replicas (I'll check and fix it soon).

If this doesn't answer your question, can you elaborate more? possibly giving the query you run usually.

Could you ellaborate, please, how will the new scheme interpret the red templates transclusion, so that quarry could recognize them?

I wanted to create such a request, and found this one presearching. For me, there is completely different reason for this magic word. If we add editing templates (update, rewrite, fix, add links, ....) or some others ({{Current}}), they should look differently at the article top or in some section. The magic word allows to check, if the section number is 0, the template is relevant to the article, otherwise to specific section.

Thanks. I'll write here if I see it again.

No problem. Well, as I said, on two pages I can see the full TOC, without definitions button. No, I don't.

BTW: it's just a guess, but if I would be you, I would check synchronization. There was one page that I opened twice, once broken, and once not. Maybe something js not ready in time.

In T302461#7749380, @nray wrote:

@IKhitron I've visited https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F and I only see one table of contents in the article (and no TOC in the sidebar):

Can you please paste the full url of the page you are noticing this issue?

In T302461#7749204, @Jdrewniak wrote:

@IKhitron we're actively working on the table of contents and bugs like this may appear temporarily due to caching. Are you still seeing this issue?

In T302461#7734225, Aklapper wrote:

I opened the link and the link is a diff.

Indeed. It's everywhere, and this link is just an example. Here is another one, in reading mode:

The screenshot seems to come from https://he.wikipedia.org/w/index.php?title=ויקיפדיה:מזנון&oldid=33299679 instead?

No, it doesn't.

Fixing problems does not require reverting.

Of course. Not for fixing, for avoiding the current situation.

I see. And what about the Linter rules update?

Just saw this in the Tech News. The question is: does this affect the Google Search?

@Jack_who_built_the_house

Well, FYI. It works now, and the problem was misleading documentation of the new future. It's better to rewrite it, I think. To tell about file names, about try and catch, and more.

I think I already get an answer from these links. Although, I coudn't make all this work yet.

Don't understand what are you trying to say.

@Johan, what do you say, do we need to publish this?

So, what's the right page name, mydata.json or Gadget-mydata.json as usual?

Thank you. When there be the next release of WVUI?

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.