Can you write text from right to left? It doesn't matter, your website can do that on its own.

When creating end-to-end global solutions, we often encounter challenges with product localisation. We need to ensure that the date and time format is appropriate. Display a currency that is convenient for the user and, most importantly, display content in a specific language. Of course, there are many ready-made solutions to the above problems. But what if we are dealing with a right-to-left written language? Let's see what challenges lie ahead.

Reign over the Tower of Babel

The first challenge is to master content in other languages. We need to have a tool that allows us to develop content multidimensionally. Because, on the one hand, we have developers who create complex applications and websites. They are responsible for the keys and the content in the original language, because they know best how the content will be placed, and how to divide it up. On the other hand, we have translators who need to be able to access this content easily, with the option of adding a translation in their own language. There are a lot of great tools out there, and we at TalkToLoop have relied on lokalise.

As we can see from the screenshot, in this tool we have a convenient breakdown by language. We can see how many translations are missing, how many of them have been verified. From this platform, we can also easily export the data to our application, in the format we want.

With such tools, we can easily add content and translate it into any language. Also, integration into the application is not a problem. Let us consider what to do about the real challenge of displaying a language written from right to left.

When things take an unexpected direction

Right-to-Left (RTL) languages, such as Arabic, Persian (Farsi), Urdu, and Hebrew, present several unique challenges for website design and development. A variety of issues can arise when designing websites to be compatible with these languages, given their unique script direction and certain cultural nuances.

1. Layout Mirroring: The most significant challenge is the need for website layouts to be mirrored for RTL languages. In contrast to left-to-right (LTR) languages, which follow a left to right flow, RTL languages require a layout that begins from the right side of the screen. This involves not only the text but also elements like menus, buttons, forms, sliders, and even animations, which can be a complex task especially for websites that were initially designed for LTR languages.
2. Typography: Another major issue is the appropriate handling of typography. RTL scripts have unique typographical requirements, and some fonts designed for LTR languages do not support these. Also, the font size and line height may need adjustments to ensure the text is legible and aesthetically pleasing.
3. CSS and HTML Support: While CSS and HTML are designed to support both LTR and RTL layouts, some features and properties may not work as expected when switched to RTL. Developers must understand and test these complexities to ensure consistent experiences.
4. Bilingual or Multilingual Websites: If a website supports multiple languages, switching between LTR and RTL languages can present additional challenges. The website's design and coding must accommodate this shift seamlessly, which can be complicated to implement.
5. Text Alignment and Direction: Text alignment and direction must be handled carefully. Aligning text to the wrong side or mixing LTR and RTL text can lead to confusing or unreadable content.

6. Forms and Inputs: User input, like forms, can be particularly challenging. Text inputs must switch directionality based on the language, and validation errors or hints must follow suit.
7. Images and Icons: Images and icons should also be considered when switching from LTR to RTL. Icons that indicate direction or action (like back, forward, next, etc.) should be mirrored for RTL languages.
8. Cultural Sensitivity: Beyond the technical issues, cultural differences must be considered. For example, colors, symbols, or images acceptable in one culture may not be in another.

Despite these challenges, support for RTL languages is crucial in today's global digital environment. It requires careful planning, design, and testing but ultimately broadens a website's accessibility and inclusivity, reaching a wider audience.

Our recipe for holding the right direction

In the first instance, we created a service that is responsible for checking whether the user is using the RTL language. We can then use this service to toggle the dir attribute, which is responsible for arranging the HTML content in the appropriate direction.

Using the setRtl(true) method will set the dir attribute to the rtl value and add it to the <body> selector. We may get the impression that our page is ready. Nothing could be further from the truth. If we take a closer look, we will find that we are missing distance in many places. And in others they are there even though they shouldn't be. Example of an incorrectly displayed menu below.

As we can see, there is no break between the text and the chechbox. This is caused by the fact that we have set the margin-right for the checkbox. But after switching to RTL, we need this margin on the other side. This problem will affect any element that has margin or padding and other similar properties.

We run toward the sun

To remedy this, we can replace all these properties with mixins, which will change value depending on the dir value on the <body> element.

As we can see in the code, this first mixin, will make all the parameters we put inside work only if we display the language written from left to right on the page. The second, on the other hand, will allow us to write css rules that will only be applied if we are dealing with an RTL language. With these two mixins, we can go further and create another generic reusable mixin.

We have now created a mixin so that we can juggle the scss rules depending on the direction of the script. Our scss method takes the following arguments: the rule for ltr, the rule for rtl, the value. Sound complicated? The next two mixins will make it all obvious.

Remember our problem with the margin on the wrong side of the checkbox? Forget that problem forever. All you have to do is use these mixins throughout your app, instead of the margin-left and margin-right rules. The mixin will do the rest.

Isn't that simple and wonderful? The result of this mixin will be this css code.

If we used this on the menu checkbox we discussed. Everything would display correctly and perfectly as it should. Okay, that was the margin. Now we can add the same beautiful methods for the padding rule.

and the result of use

will be

Such mixins can and should be created for rules such as left, right, border-left, border-right etc. For all those values they should change dynamically. We know from experience that this will just be everywhere. And there will be no exception to this. For example, the shorthand padding rules.

Okay, with these few simple tricks we have embraced 99% of the right-to-left writing challenges. In summary, it is important to have a good system for managing translations so that it is easy to enter, review, revise and integrate into the app. RTL language support is a must. In the next step in our application, we need to create a service that decides when to switch our application to RTL mode and vice versa. Then use it to switch our body selector globally. Then replace all the css rules responsible for distances, borders etc. with mixins that out-of-the-box will change our application depending on the direction of the text.

‍

Hubert Wróblewski