Wrong -> arrow direction in RTL text contexts

This has nothing to do with bidi settings in Discourse.

When I type -> it gets converted into an arrow character , so A -> B renders as “A → B”. Pretty cool.

However, the arrow goes the wrong way in RTL text: א -> ב renders as: “א → ב” with the arrow going the wrong way. (If you’re reading this in the future after this bug has been fixed, this was rendered as “א → ב”)

Note that the input character sequence here is:

Character Name
א HEBREW LETTER ALEF
SPACE
- HYPHEN-MINUS
> GREATER-THAN SIGN
SPACE
ב HEBREW LETTER BET

which you can verify by copying the string א -> ב into this tool: https://unicodedecode.com/

This is because arrow characters don’t bidi-mirror in Unicode. Relevant document: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

In particular, arrow and arrow-like characters each often has a mirror character. One could argue that they should have had the Bidi_Mirrored=Yes property value, but they don’t, and cannot now get that.

There is unfortunately no bidi-flipping arrow character, meaning that if you want to make this substitution correctly, you have to determine the bidi direction of the surrounding text to correctly pick between ← and → arrows. No easy task.

1 Like

@falco I would argue that this is indeed a bug, not a feature request. The output is the exact opposite of user intentions and expectations.

Given that

It means we would have to build a new feature, as we are currently following the Unicode spec, which is why I recategorized it as a Feature request.

Moving on to actually addressing your issue, I think this could be easily done in a Theme component, using our existing api.decorateCooked API.

1 Like

Thanks. I’m in no hurry to get it fixed in any particular forum, I just think this should be fixed in Discourse.

I don’t want to get into a pointless argument about semantics, so I’ll leave it at that. I’ve said what I have, I think this should be considered a bug, but what you do with that is up to you now.

Thanks for your attention and quick response :slight_smile:

1 Like

Well… A man can only resist so much. I will say one last thing (I promise). As far as I’m aware, the Unicode spec does not encourage converting -> to (and this issue would be one reason why), so this existing Discourse feature is not following any Unicode spec. It makes a false assumption about text and introduces this bug in the process. That’s how I see it. (The feature is still neat though)

Now I’ve said what I have!

2 Likes