Recommended way to handle RTL mixed with LTR languages


(Simon Cossar) #10

It’s doesn’t get inherited, so it would need to be applied to every element in a cooked post. Also, Internet Explorer doesn’t support it. If we’re not concerned about supporting IE, there are places in the code that it would be useful (titles, category descriptions, etc.), but it’s easy enough to add a helper function that sets the direction of those elements based on their text content.

It automatically applies the correct direction to text in the preview window, cooked posts, titles etc. It sets the direction of text fields based on the text that is entered. It doesn’t automatically set the direction of the composer’s textarea. To make it easier to type, you can switch the direction of the textarea by clicking a button. Changing the textarea’s direction doesn’t affect its final output. It will be formatted correctly regardless of the direction the textarea is set to.

Facebook’s editor handles text direction very well. They can do this because their editor is using contenteditable. This lets them set the text direction on individual elements in the editor. It’s possible to get behaviour similar to this by adding the attribute dir="auto"to the composer’s textarea, but doing that has some strange side effects.


(Pari) #11

any update for this feature?


(Simon Cossar) #12

It is available in the master branch now. Enable it by selecting the support_mixed_text_direction setting. I’ll write a topic about it soon.

There are a few improvements that could be made to the way it’s setting the text direction for topics. The biggest problem I’m seeing with it is that usernames need to be treated as a special case.

To get category descriptions to display correctly on the categories page, you need to add this css to your theme. I’ll make a pull request to add that to the main code.

.category-description span {
    display: inline-block;
}

The button for toggling the editor’s direction is found here. Toggling the editor’s direction doesn’t affect the editor’s output, it just makes it easier to type.

There are still a few areas where mixed text could be displayed that are not having their text-direction set. If you come across any, please let us know.


(Pari) #13

Fantastic! I have updated discourse to latest and it is working like a charm.

My first comment would be if you can do something for this button to not toggle entire editor and just toggle current paragraph. That would be great.

I keep an eye on this new feature and let you know about problems.


(Sam Saffron) #14

I would love to support partial ltr/rtl to be visible in the composer but it will require a pretty big change to the composer cause we can no longer use a text area and would have to use a content editable div


(Pari) #15

So maybe removing that button is better. because at least for my community, it is confusing the ppl. they think that it is that button that decides the direction of text.

another question.

I realized that to change the direction of text, rtl and ltr contents should be separated by two enters. Can you also support correct direction with one enter?


(Pari) #16

Please ignore this suggestion. It is good when it comes to a full ltr/rtl post.


(Simon Cossar) #17

Thanks for the feedback! One of the main reasons for adding the button was to make it easier to add blocks of code on RTL sites.


(Pari) #18

Is this possible @Simon_Cossar ?

non tech people don’t understand the difference between one and two enters.


(Simon Cossar) #19

I think it is possible, but I’m not sure how efficient it will be. I’ll give it a try.

The easiest non-technical explanation for the difference between one and two enters is that two enters (a blank line) creates a new paragraph. The direction is being set at the paragraph level.


(Pari) #20

@Simon_Cossar, I found that there is a great performance drop in long topics containing mixed text direction. First I thought its because of rating plugin. However after further examination, I turned off this feature in our forum, and found that everything was back to normal.


Topic Ratings Plugin
(Sam Saffron) #21

We will get this sorted can you post a copy of a long post with that issue so we can have a look


(Pari) #22

Its not a long post.

its a topic with thousands of posts. here


(Mittineague) #23

I’m wondering if the bottleneck is Discourse generating the directional instructions or the browser interpreting them and rendering the display.

Have you compared the efficiency using different browsers?


(Simon Cossar) #24

The topic that you linked to seems to be loading correctly for me. I am using a fairly powerful computer, so that could be the difference. There is a small change that could be made to the code that I’m sure would improve performance, but we would loose support for Internet Explorer.

What browser and operating system are you using?

I am surprised that the number of posts in a topic is making a difference. I’ll look into that.


(Pari) #25

I’m on Ubuntu 16.04 and I tested with Mozilla and Chrome

I also tested with my cellphone now. However surprisingly, the topic opened normally. Now what could be the problem? :thinking:


(Jeff Atwood) #26

What version? You mean not Edge, so IE11 only? That could be an acceptable tradeoff for many audiences.


(Simon Cossar) #27

There’s no support for dir="auto" in IE11 or Edge.


(Jeff Atwood) #28

Wow that’s really weird:

https://www.w3.org/International/tests/repo/results/the-dir-attribute-auto


(Simon Cossar) #29

Yes, I was surprised, so I tested it with BrowserStack as well. There is another approach we could take with this to make it more efficient, but we need to be sure there’s a problem first.