Recommended way to handle RTL mixed with LTR languages


(Giorgos Kontopoulos) #1

The forum we are running is mainly in english but we have some pages recently that are RTL (arabic)
what is the recommended way to get a specific topic to have RTL direction

is this the only posibility ?

is this a plugin that can handle the tags [text-direction=rtl] [/text-direction]

any other way ?


(Simon Cossar) #2

We are going to be adding a site setting for supporting mixed text direction very soon. I’m working on it now.


(Giorgos Kontopoulos) #3

so the plugin is not really supported ?
should it be avoided ?
will it cause trouble if you solution comes out ?
any ETA on your solution ?


(Simon Cossar) #4

I haven’t looked at that plugin in a while. I wouldn’t recommend using it. For now, the best way to get RTL content to display correctly when a LTR locale is being used is to wrap the content in <div dir="rtl"></div> tags. Doing this won’t cause any trouble when support for mixed text direction is added. The ETA for that feature is early next week.


(Giorgos Kontopoulos) #5

Thanks for the answer
I tried both <p class="rtl"></p> and <p dir="rtl"></p> inside a post but I end up with <p></p> in both cases

So its strips out the attributes, how can I tell discourse to not strip those attributes ? is there a setting ?


(Simon Cossar) #6

Sorry, the dir attribute is only whitelisted for <div> tags.

<div dir="rtl">this is a test</div> will work:

There is no setting to add attributes to the Discourse whitelist. It can be done through a plugin. That’s what the plugin that you linked to is doing.


(Giorgos Kontopoulos) #7

Great thanks that worked


(pari) #8

Great job! I’ve been looking for this feature. Is it automatic? like suggested here?

Or is it a button to change the direction of text?


(Joffrey Jaffeux) #9

Any reason we don’t enforce dir="auto" ?


(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