Page MenuHomePhabricator

BiDi: LTR and RTL mixed up (tracking)
Closed, InvalidPublic

Description

Author: jp.posma

Description:
Tracking bug for all problems where mixing LTR and RTL text causes weird renderings.


Version: unspecified
Severity: normal

Details

Reference
bz28708

Related Objects

StatusAssignedTask
InvalidAmire80
ResolvedAmire80
InvalidNone
ResolvedNone
ResolvedNone
OpenNone
Resolved TrevorParscal
Duplicate TrevorParscal
ResolvedNone
ResolvedSPQRobin
ResolvedNone
ResolvedNone
OpenNone
OpenNone
OpenNone
InvalidNone
Resolveddaniel
OpenNone
OpenNone
ResolvedNone
ResolvedNikerabbit
ResolvedNone
OpenNone
DeclinedNone
ResolvedNone
ResolvedNone
Resolvedmatthiasmullie
DeclinedNone
ResolvedNone
OpenNone
ResolvedNone
ResolvedNirzar
DuplicateNone
Resolvedsanthosh
Resolvedsanthosh
OpenNone
ResolvedFomafix
OpenNone
InvalidTheDJ

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:26 PM
bzimport set Reference to bz28708.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Apr 26 2011, 2:37 PM

Added Blocks Bug 745 for easier structure and less bugspam.

jp.posma wrote:

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.

Attached:

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

jp.posma wrote:

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?

jp.posma wrote:

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.

Attached:

(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).

Attached:

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.

jp.posma wrote:

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.

jp.posma wrote:

(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?

jp.posma wrote:

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.

jp.posma wrote:

(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*

Ebraminio moved this task from Backlog to Other on the RTL board.Aug 9 2015, 11:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2015, 11:53 AM
Amire80 closed this task as Invalid.Aug 30 2015, 7:40 AM
Amire80 claimed this task.

I am merging this into T2745, because they are not really that different, and Phabricator tags and columns are a better way of sorting bugs these days.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptAug 30 2015, 7:40 AM
Meno25 removed a subscriber: Meno25.Sep 20 2015, 3:26 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptSep 12 2016, 4:22 PM