Wikimedia Bugzilla is closed!

Added Blocks Bug 745 for easier structure and less bugspam.

Created attachment 8463 [details]
Bidi fixing effort

This patch supplies some fixes and shows how this can be used to fix many more BiDi bugs.

By wrapping text in <span class="unicode-embed"></span> a new embedding level is created, which allows for different text direction inside without breaking surrounding text.

This can be done in MediaWiki by using the Sanitizer::safeBiDi() function.

This patch already fixes bug 28030, bug 12415, bug 12406, bug 28411, and bug 28349.

a { unicode-bidi: embed } could already fix some things.

No, unfortunately this also breaks a lot, for example pieces of LTR text with links on a RTL wiki. I don't have an example right now but you can try it out for yourself (e.g. set a test-wiki with English texts to language "ar")

Please give examples, nobody has complained in twn yet :)

Niklas, it's quite possible that nobody complained, because RTL at twn was so broken that i switched to English ;)

(And it's really not TWN's fault, but a general problem in MediaWiki.)

I switched to Hebrew now. Where is it used in twn?

Created attachment 8464 [details]
Problem with applying this to all links

When applying this to all links (a { unicode-bidi: embed; }), you get problems when a piece of LTR text in an RTL wiki contains a link. See the screenshot.

(In reply to comment #6)
> Niklas, it's quite possible that nobody complained, because RTL at twn was so
> broken that i switched to English ;)
> 
> (And it's really not TWN's fault, but a general problem in MediaWiki.)

I know it's horrible :/

> I switched to Hebrew now. Where is it used in twn?

Everywhere :)

(In reply to comment #7)
> Created attachment 8464 [details]
> Problem with applying this to all links
> 
> When applying this to all links (a { unicode-bidi: embed; }), you get problems
> when a piece of LTR text in an RTL wiki contains a link. See the screenshot.

Well, you're not supposed to have LTR text in RTL wiki (unless tagged as such).

It's easy to tag LTR text in an RTL wiki when it's a part of an article. It's next to impossible to tag names of pages and users as having different directionality: HTML and CSS cannot be applied to specific names and LRM/RLM characters are filtered out, too.

For usernames filtering out LRM/RLM is probably a Good Thing, because they are supposed to be as simple as possible. But for page titles it is sometimes needed (Bug 28411). I tried solving it using unicode-bidi: embed and failed, but maybe i didn't try hard enough.

Well, that is the entire point of this bug: to fix occurrences of LTR text in an RTL wiki and vice versa. Setting unicode-bidi: embed; to all links doesn't make it better, it makes it worse. Or am I missing something?

The fix for that is very easy <div lang=en dir=ltr>..</div>. Like Amir said problem are different kind of listings which can contain mixed directionality items.

(In reply to comment #11)
> The fix for that is very easy <div lang=en dir=ltr>..</div>. Like Amir said
> problem are different kind of listings which can contain mixed directionality
> items.

Okay, so should we then include

a { unicode-bidi: embed; }

in shared.css? What do you think?

This would indeed mean that many things would be fixed automatically, although we would still need to manually wrap using safeBiDi() for bugs that have nothing to do with links, such as bug 12415. 

If you guys as i18n experts say its safe to apply unicode-bidi: embed; to all links by default, then we should do it. ;)

Another option would be to by default have Linker::link add class="unicode-embed" and add a parameter to remove this class.

I'm not 100% sure a{embed} it works without issues, otherwise I would have already applied it.

(In reply to comment #14)
> I'm not 100% sure a{embed} it works without issues, otherwise I would have
> already applied it.

I guess we can try it out on a RTL wiki by asking an admin to add the rule to the wiki CSS?

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*