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

Note: This currently impacts modern Vector only which is either opt-in or default for wikis who are early adopter to support us finding bugs like this.

Over the next 2 weeks it will impact all skins so the sooner we get this out the better.

How would you like this described in Tech News?
I've drafted this, but I'm unsure if it is complete & accurate (given the limitations of space):

If your wiki uses <div class="mw-content-ltr"> or <div class="mw-content-rtl"> without the required dir attribute, then these will no longer work in 2 weeks. There is a short-term fix that can be added to your local wiki's Common.css page, which is explained at T287701. From now on, all usages should include the full attributes, for example: <div class="mw-content-ltr" dir="ltr" lang="en"> or <div class="mw-content-rtl" dir="rtl" lang="he">. You can find existing examples on your wiki that need to be updated, using the instructions at T287701.

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

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.

Perhaps instead say uses the class "mw-content-ltr" in wikitext e.g.. <div ... might be better, but I'd hope anyone who is familiar with templates would be able to understand this nuance.

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

The new Vector experience is opt-in and bugs are to be expected there. I've checked other wikis that are opt-in by default early adopters and Hebrew Wikipedia seems to be the only wiki that's majorly impacted by this change so I don't think we need to add confusion around the timeframe. The purpose of this message is to make communities aware of this potential issue and allow them to either act reactively or preactively.

By the way, what does lang parameter add here?

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

I see.

Question.. while I agree that the class is used incorrectly a lot... and that most of those incorrect usages should be replaced as described.. at the same time, that's not the proper replacement for a correct usage of these classes is it ?

As far as I understand mw-content-ltr is it to be "the direction that the main content is" (not any possible random child of the content). Specifically, the intent of the class back then, was to make sure that you force align elements the same way as the proper content direction, for instance a template generating a fake edit button and ignoring the direction of any subblocks.

So for proper usages, you should be removing .mw-content-ltr from the html and using templates styling target: .mw-body-content[dir=ltr] .myblock. But the mw-parser-text scoping prevents you from targeting that CSS rule I think.

Where does this happen you might ask? I have no direct examples, but I'd assume in things like Commons/Meta, where multiple levels of mixed content directionality is common, yet consistent placing within the main content is still required. You'd have say ltr interface language and main interface, rtl content (causing ltr editsection strings in rtl content), which can then again have a nested ltr section, including a fake edit link, which should follow the direction of the editsection strings....

I have no idea how common a mess like this is these days. It might be that all these situations were cleaned up in alternative ways over the years, but pretty sure that's what the class was for.

Do we need the class at all? The dir attribute correctly sets the text directionality (except for in Internet Explorer and legacy Edge), but MediaWiki styles such as correct margin side for lists currently depend on the class. I’d appreciate if we could get rid of it and make multilingual templates’ source code simpler.

In T287701#7248257, @TheDJ wrote:

[…] make sure that you force align elements the same way as the proper content direction, for instance a template generating a fake edit button and ignoring the direction of any subblocks.

Why should it? I don’t know what kind of edit button you mean, but usually the outer directionality (floating side, margin etc.) of an element should depend on the immediate context, e.g. if the box is floated to the right in a left-to-right context, it should be floated to the left within a right-to-left subblock on a (left-to-right) file page, or it will lead to even more things like this, where the content is right-to-left, but the box is floated to the same side as if the content was left-to-right.

So for proper usages, you should be removing .mw-content-ltr from the html and using templates styling target: .mw-body-content[dir=ltr] .myblock. But the mw-parser-text scoping prevents you from targeting that CSS rule I think.

If you still want to depend on the directionality of the page in TemplateStyles, you don’t have to do such tricks: just use .myblock, and CSSJanus will take care of flipping the styles on right-to-left pages. (This doesn’t apply to non-TemplateStyles CSS like sitewide styles, gadgets or user styles, but they aren’t scoped either.)

As a note, that recommended search is woefully under-finding content, consider whether you actually want this to go out in 2 weeks. A more appropriate search finds some 500k instances on a wiki that doesn't need to care about it for the most part (disturbingly many)...

In T287701#7253874, @Izno wrote:

As a note, that recommended search is woefully under-finding content, consider whether you actually want this to go out in 2 weeks. A more appropriate search finds some 500k instances on a wiki that doesn't need to care about it for the most part (disturbingly many)...

That search is still throwing up a lot of false positives.

<div class="mw-content-ltr" dir="ltr" lang="en"

is not impacted by this change.

If in doubt, I suggest adding this rule to MediaWiki:Common.css e.g as we did on Hebrew Wikipedia.

o we need the class at all? The dir attribute correctly sets the text directionality

This

In T287701#7248375, @Tacsipacsi wrote:

Do we need the class at all? The dir attribute correctly sets the text directionality (except for in Internet Explorer and legacy Edge), but MediaWiki styles such as correct margin side for lists currently depend on the class. I’d appreciate if we could get rid of it and make multilingual templates’ source code simpler.

This was my understanding of the class. As far as I can tell from the git history, this rule dates back to a time when Internet Explorer did not support attribute selectors e.g. [lang][dir] {} .

I'm willing to be proved wrong, but I'd be very surprised if there is a legitimate use case for it given dir and lang can be defined in wikitext and will override the parent direction/language.

Please add [[Special:LintErrors]] rules to detect pages that have this issue.

In T287701#7257680, @Dave_Braunschweig wrote:

Please add [[Special:LintErrors]] rules to detect pages that have this issue.

Seems like a good idea. Could you file a task under MediaWiki-extensions-Linter as I'm not too familiar with how that extension works or how to add a linting rule?

@Jdlrobson Done as https://phabricator.wikimedia.org/T288270 .

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one. If that is incorrect, please update the task again and educate me.

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

I was informed that this example does not luck lang parameter, only dir parameter. I checked this out in https://he.m.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:IKhitron/%D7%98%D7%99%D7%95%D7%98%D7%94&oldid=31982606
Were we wrong? If not, why need anyone the lang parameter for direction stuff at all?

In T287701#7280626, @Huji wrote:

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one.

If you specify the directionality of some text, it’s almost certainly not in the same language as its context. If it contains no natural language content, you should use zxx according to BCP 47 (page 57).

In T287701#7283024, @Tacsipacsi wrote:

In T287701#7280626, @Huji wrote:

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one.

If you specify the directionality of some text, it’s almost certainly not in the same language as its context. If it contains no natural language content, you should use zxx according to BCP 47 (page 57).

Thanks for educating me on this, @Tacsipacsi. I had not seen this used in action so my first reaction was to check to see if any of our source codes use it. Wikibase does but I have not seen it anywhere else.

Are you recommending that if a <code> tag needs a dir (which probably only happens on RTL wikis when they need an LTR section of code inline) that they should specify both dir="ltr" and lang="xzz"?

Actually even those <code> tags would ideally have lang="zxx" attribute that don’t necessarily need a dir attribute (because they are in LTR context). Even though <code> represents a fragment of computer code, I found nothing in the HTML standard that would mandate that <code> elements’ language is implicitly zxx.

Given that yous aid "ideally", I assume that "practically" we may chose not to add the "zxx" lang code to every <code> element for now. And that even when we specify the dir attribute, we would still elect not to specify the lang attribute. This is not ideal, but is much easier to maintain. In reviewing the HTML standard, I did not find anywhere that says the lang attribute must be specified for <code> elements.

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#7283556, @Huji wrote:

This is not ideal, but is much easier to maintain.

I don’t think it would be easier to maintain, it’s just easier to migrate to it using bots now. In the long term, I expect no maintenance costs but many benefits by the way of more support by translators, screen readers, Braille translators, or even browsers for non-disabled people, which can select more appropriate fonts.

In reviewing the HTML standard, I did not find anywhere that says the lang attribute must be specified for <code> elements.

It’s not in the HTML standard (at least I couldn’t find anything about it either), but it’s a AA-level criterion of WCAG 2.1, which is the bare minimum we want to achieve in terms of accessibility.

In T287701#7281046, @IKhitron wrote:

I was informed that this example does not luck lang parameter, only dir parameter. […] Were we wrong? If not, why need anyone the lang parameter for direction stuff at all?

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.

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.

So could you explain me, please, what did I wrong in the tests? Thank you.

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#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.

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

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#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

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

So, I was right. I know we need to use it, of course. But not as a part of this task description convertion. Thanks.

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#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:

I get a lot of complaints. Maybe you should try another Chrome. Because I can't see the problem on Samsung Internet, Chrome derived, either.

Ouch. Getting rid of uses of mw-content-ltr/mw-content-rtl classes (is it planned by this change besides CSS removal?) will impact Convenient-Discussions as it uses (actually, just started to use) these classes to find LTR discussions on RTL pages and vice versa (like this). These discussions are then styled accordingly:

The currently used rules look like this (link):

.sitedir-rtl .cd-commentLevel:not(ol) > li,
.sitedir-rtl .cd-commentLevel:not(ol) > dd,
.sitedir-ltr .mw-content-rtl .cd-commentLevel:not(ol) > li,
.sitedir-ltr .mw-content-rtl .cd-commentLevel:not(ol) > dd {
  padding-left: 0;
  padding-right: 1em;
  margin-left: 0;
  margin-right: 1em;
  border-left: 0;
  border-right: 1px solid #c8ccd1;
}

And there's many more of them.

The problem with using [dir="ltr"]/[dir="rtl"] in CSS selectors is that attributes are considered way worse than classes in terms of CSS performance.

Is there anything left to do in this ticket, or can this be resolved? Asking as this is under "Already announced/Archive" in User-notice only, with no other tags.