I just ran into the following PR: https://github.com/discourse/discourse/pull/15032 I think it my render legit Hebrew or Arabic text unreadable. One of the solutions I ran into was disabling the unicode algorithms and just display some representation of non-printable characters (I think it was implemented in Pootle). So basically the idea is to turn: This‎‏ text Into: This text This way to user can choose if this is malicious or not by understanding what the actual characters are and possibly choose to enable the unicode algorithms to be able to read the text properly. Thanks.

Demo: #include int main() { /* Say hello; newline /*/ return 0 ; printf("Hello world.\n"); return 0; } #include int main() { /* Say hello; newline /*/ return 0 ; printf("Hello world.\n"); return 0; } Test: ‫"שלום חבר" - Hello Friend Without BIDI Test: “שלום חבר” - Hello Friend Markdown: Test: ‫"שלום חבר" - Hello Friend Without BIDI Test: "שלום חבר" - Hello Friend Not the best example in the world, but you should get the gist here, only impacts source code being posted on the forum. Bidi chars in source code is not something that is usually done.

Thank you for raising this, we did think of this concern. The fix you linked in the OP only applies to unicode bidirectional characters in pre and code blocks, either manually written as HTML or generated from ``` markdown fenced code blocks, so it should not be an issue with regular Hebrew or Arabic text in a composed post.

I’ll give another example where no RLM does break the sentence. שלום לכולם ובמיוחד ל־Sam, Martin בחר לעזוב אותנו. שלום לכולם ובמיוחד ל־Sam,‏ Martin בחר לעזוב אותנו. Do you see the difference? The only change there is RLM, I wanted to congratulate Sam and inform that Martin is leaving (No offense).

Yes, that example is certainly much better! As you can see it continues to work and is not impacted by the security fix :tada:

[image] yaron: I meant that inside a codeblock it won’t appear as expected Yeah but why would you include it in a code block?

Excerpt from gettext, Hebrew/Arabic native strings, there are such cases.

[image] yaron: Excerpt from gettext, I would the outlier case here has workarounds (screenshot, attachment uploads and so on), also it is pretty clear that the special char is in place. The risk of https://trojansource.codes/ is higher than the risk of mild disruption in extreme outlier cases.

But my suggestion breaks the sentence with some cue, so replacing the RLM and LRM with or will show the user that there were some additional characters and now the text is rendered without them yet informing that it might break the experience and that there’s an option to replace back manually if needed, removing the characters completely without some indicators gives no room for educated decisions. And it will also prevent trojan source code as you mentioned because the user will be able to see the malicious code with the indicators. I will try to get some screenshots from Pootle, I don’t remember seeing that raw strings option in the past couple of years, it was very useful when we started fixing the LibreOffice localization.

Not following, we do not strip we replace , see my example above

I understand, wouldn’t it be better to use their names instead of Unicode entity?

Bidirectional characters in LTR languages post security fix

Product Support

yaron (Yaron Shahrabani) November 24, 2021, 1:27pm 10

Hmmm it’s not a codeblock
I meant that inside a codeblock it won’t appear as expected (This is what the fix is all about, am I right?)

Topic		Replies	Views
Wrong -> arrow direction in RTL text contexts Feature rtl	12	730	May 26, 2025
Uncode Emoji incorrectly converted to text inside code blocks Bug markdown-it-review	1	1289	January 8, 2016
Markdown css styles not shown when RTL is enable Bug	9	2218	July 16, 2018
Right to left override messes up the text in reviews Bug review-queue	5	206	April 30, 2025
Links are Left-to-Right by default Bug	1	597	May 19, 2019

Bidirectional characters in LTR languages post security fix

Related topics