Mastodon: desktop notifications do not handle mixed RTL + LTR text correctly

Created on 4 May 2017  路  5Comments  路  Source: tootsuite/mastodon

image


(the corresponding event in the web ui: image)


  • [x] I searched or browsed the repo鈥檚 other issues to ensure this is not a duplicate.
  • [x] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).
bug

Most helpful comment

I just tested the following solution in Firefox and Chromium, and it works fine on both. So I believe this solution is safe to be implemented.

Solution

In making the string that shows up in the notification text, enclose the username inside Unicode embeddings. For example, instead of

{displayname} follwed you

write

‪{displayname}‬ follwed you

If you do this, the notification text will always be LTR, because {displayname} will be embedded and cannot affect direction of the entire notification. The first magic character is LEFT-TO-RIGHT EMBEDDING (LRE, U+202A) and the second is POP DIRECTIONAL FORMATTING (PDF, U+202C) (source).

However, for RTL locales, the first magic character should be RIGHT-TO-LEFT EMBEDDING (RLE, U+202B) instead. So this can be decided in a function that gets the current locale as input and spits out either LRE or RLE. The second magic character (PDF) is the same for both cases.

Why embeddings and not isolates?

Unicode isolates are indeed better than embeddings since they prevent some extra problems. But none of the major browsers support isolates yet (test results). Therefore, W3 recommends to solve this problem using Unicode embeddings as a workaround. Fortunately, the edge cases where isolates work better than embeddings do not affect Mastodon (they mainly deal with mixing numbers inside bidirectional text).

Hope this helps. I am happy to provide more help or feedback or testing.

All 5 comments

This is probably a browser-side issue?

maybe? I think there's a way to isolate unicode RTL contexts that we could use here

I just tested the following solution in Firefox and Chromium, and it works fine on both. So I believe this solution is safe to be implemented.

Solution

In making the string that shows up in the notification text, enclose the username inside Unicode embeddings. For example, instead of

{displayname} follwed you

write

‪{displayname}‬ follwed you

If you do this, the notification text will always be LTR, because {displayname} will be embedded and cannot affect direction of the entire notification. The first magic character is LEFT-TO-RIGHT EMBEDDING (LRE, U+202A) and the second is POP DIRECTIONAL FORMATTING (PDF, U+202C) (source).

However, for RTL locales, the first magic character should be RIGHT-TO-LEFT EMBEDDING (RLE, U+202B) instead. So this can be decided in a function that gets the current locale as input and spits out either LRE or RLE. The second magic character (PDF) is the same for both cases.

Why embeddings and not isolates?

Unicode isolates are indeed better than embeddings since they prevent some extra problems. But none of the major browsers support isolates yet (test results). Therefore, W3 recommends to solve this problem using Unicode embeddings as a workaround. Fortunately, the edge cases where isolates work better than embeddings do not affect Mastodon (they mainly deal with mixing numbers inside bidirectional text).

Hope this helps. I am happy to provide more help or feedback or testing.

Using the solution I explained above, I could fix the reverse problem (LTR display name in an RTL instance):

[Mastodon 1.3.1, wrong]
notification-rtl-bug
[Mastodon 1.4.1, right]
notification-rtl-bug-fixed
This was done by adding invisible RLE and PDF characters (see above) in the app/javascript/mastodon/locales/fa.json.

I still think it's better if this is implemented in the code rather than in the localization file. But at least what I did shows that the unicode embedding solution works.

I have a similar but related issue

A user has Unicode Character 'RIGHT-TO-LEFT OVERRIDE' (U+202E) as a trailing character in their username, leading to some pretty amusing text rendering

RTL Text in english

I believe it'd be solved by @mabkenar's solution, but I'll document the interesting behaviour nonetheless

Was this page helpful?
0 / 5 - 0 ratings