Interface localisation: adapting text fields for RTL languages
Adapting applications and sites for right-to-left (RTL) languages is an issue encountered by developers working on many products under development and being introduced onto new markets. There was a point when we at Bumble — the parent company operating Badoo and Bumble apps — also found ourselves in this situation, since our applications have so far been translated into about 50 languages and dialects. There are plenty of articles that cover this problem and explain types of characters, CSS-mirroring principles and importance of the “dir” attribute (see some links in the end), but they mostly relate to static content. And there are not many materials dedicated to RTL text input, despite there are tricks here worth sharing.
So, in this article, I will tell you about several minor but interesting issues we discovered when adapting HTML forms on the Badoo.com site for Hebrew and Arabic. To start with, I’ll compare several interfaces of applications that include an RTL audience and how they handle the task of inputting text. Then, I’ll explain how we decided to implement our version of RTL.
Example 1. One social media network
Authorisation form
On the login form on the main page, the “email” field behaves like left-to-right (LTR) by default. This makes a lot of sense as most email addresses only contain Latin script.
However, this is not universal. Current standards allow us to use virtually any characters in email addresses. As a result, an address written in Hebrew would end up like this:
- Aligned to the left;
- When we type the neutrally typed symbols, “@” and “.”, the whole construction move around, which is not very convenient.
The password field is RTL by default; the cursor is on the right.
However, what happens when we try to input a password in Latin script or with numerals? As the text is input, the cursor will be positioned to the left of the text being input. This is not critical, as we can’t see the password anyway (as long as there is no “show password” button); however, the behaviour of the field could be improved by showing the user the keyboard layout being used to input the password. The specifics of RTL interfaces are such that, despite most text being right-to-left, users very often need to switch keyboard layout in order to input email addresses, logins or passwords — which are usually written left-to-right. A little hint would be timely at this point.
Registration form
Now let’s look at a registration form, also on the main page.
Here we can see that all the fields are considered strictly RTL and are aligned to the right which is inconvenient when you are dealing with LTR text. It is particularly unpleasant when you input an email address because the symbols “@” and “.” cause bits of the address to move around while you are typing. What was less critical in the case of rare RTL addresses in the previous example becomes essential in the case of LTR ones.
Update. While this article was being written, the main page of the mentioned service underwent significant visual changes and lost some of the mentioned fields. But those that remained retained all the described mistakes.
Chat component
Compact version
Chat component is one of the key tools for this application. This is where everything should, ideally, be a user experience as friendly as possible. Let’s take a look at the compact version:
Sure enough. The field is RTL by default, but, as soon as we start to input LTR text, the direction changes so that text can be input easily and there’s no jumping around. Let’s make sure that everything is fine in the full version too.
Full version
Whoops! Despite the fact that the Latin script text in the RTL field behaves properly, it is aligned to the right. This is not critical, but the logic doesn’t make sense: this is conceptually the same component so why does it behave differently?
The four components under consideration were probably developed by different teams or at different times — when the requirements vis-à-vis international interfaces were different.
Can anything be improved here? Yes, it’s possible, and fairly straightforwardly — let’s see how, next. But first, let’s take a look at one more example.
Example 2. A pretty well-known email service
Authorisation form
Here developers have adopted the principle that everything must be right aligned, but they still treat input content as LTR. This leads to several drawbacks along the lines of those shown in previous examples.
For example, the field for inputting an email address expects the text to be input on the right.
However, when the LTR text is being entered it behaves as it is supposed to without any ‘jumping around’ (and this email service forbids the use of non-Latin symbols).
Jumping ahead of ourselves a bit here, we can say that on the web today what matters most to speakers of RTL languages is that content and direction of text behaves in the same way as it does in documents. As regards text alignment, there is no uniform view, and users have already become accustomed to both options: for some, left alignment is what they are more used to; others are used to right alignment, but, overall, it doesn’t matter that much. At Bumble, having consulted translators, we decided to retain the logical positioning of text and not to align it forcibly.
What is more interesting is how the field for inputting the password behaves. This is also forcibly right aligned and is also considered LTR, which, in our view, leads to loss of useful keyboard layout information, when inputting text in an RTL language.
But when you select “show password”, everything goes very wrong. This is because neutral characters make the password jump around, as happened with email addresses in the previous examples. So, in the example in the next screenshot, the exclamation mark should come first, and the cursor should be to the left.
Registration form
Unexpectedly, the registration form is far more user-friendly. But actually, this is logical; the information being input into the form is far more diverse. At the very least here you have a name and surname.
Here also, alignment is always to the right, but the text is not considered to be strictly LTR, and fields change direction depending on the characters input.
The only exception is the address field. Here alignment is to the left. This looks a bit strange.
Here, once again, the field for inputting a password is a cause for disappointment. Although this page has the option of dynamically changing the direction of the text in the fields, for some reason this has not been added to the field for inputting a password.
As you can see, even these simple components raise questions. That’s not to mention complicated controls like a calendar.
Badoo app’s experience
Based on the results of this little overview, here’s how we want all text fields to behave on our website:
- Placeholders need to be aligned depending to the direction of the interface language;
- The text being input needs automatically to occupy the left or right-hand side of the field, depending on its direction;
- The alignment of the cursor in an empty field should depend on the direction of the interface language;
- Text being input in fields for inputting a phone number or URL should always occupy the left-hand side of the field;
- Fields for inputting an email address should expect left-to-right text, but also be prepared for right-to-left text;
- Cursors in empty fields for inputting an email address, phone number, or URL should be left-aligned.
Now that we know what is needed, let’s try to achieve this.
For a start, let’s take a field for ordinary text, for example a name with no additional gimmickry.
<html lang=”he” dir=”rtl”>…<input type=”text”>…</html>
The cursor is positioned to the right, as it should be because the INPUT tag has inherited the text direction from HTML; and for a right-to-left interface, by default, we expect text input to be right-to-left.
But, what happens if we start to input LTR characters instead? This is a situation we are already familiar with: unusually, the cursor is positioned to the left of the text.
In the examples above, developers have taken a robust approach when resolving this problem: using JavaScript, they track the characters being input and change the dir attribute “on the fly”. This made sense until recently, but now all contemporary browsers understand the dir=”auto” attribute perfectly well and can deal with reversing the direction of text. Let’s add this.
<input type=”text” dir=”auto”>This is what we needed.
Let’s try and add a placeholder to the field.
The use of placeholders is actually a separate issue which you need to familiarise yourself with. Some developers are of the view that blindly using this attribute makes input fields less convenient to use. The decision is up to you, but for the purpose of these experiments we will assume that we do need placeholders.
<input type=”text” dir=”auto” placeholder=”שם פרטי”>Uh-oh! For some reason, it is left-aligned, including the placeholder.
Why? It’s all to do with the dir=”auto” attribute. If there is no content, the browser may consider the text direction to be left-to-right. Let’s try to position the placeholders to the right. Usually, this is text in the interface language, so automatic positioning is not something we really need.
input::placeholder { direction: rtl;}
It’s much better now but it’s just the position of the cursor which is concerning — it’s still on the left, as before. Let’s try to stylise an empty INPUT using the wonderful pseudo-class :placeholder-shown.
input:placeholder-shown { direction: rtl;}
Unfortunately, in the case of inputs lacking a placeholder, the property :placeholder-shown will not work. To rectify this, add an empty placeholder to all these fields:
<input type=”text” dir=”auto” placeholder=” ”>Now we have everything we need. The placeholder is on the right, the cursor is on the left (because we are generally expecting RTL text), and the text is on the right or the left, depending on the language we are typing in.
But this is not enough.
We remember that email addresses nowadays can contain any kind of characters. For this reason, the code for this INPUT will be similar to that of the previous one.
<input type=”email” dir=”auto” placeholder=”כתובת אימייל או מספר נייד”>( On Badoo app the main thing we expect is an email address, but we also allow for a phone number to be input, so that is what the placeholder says.)
Although there can be any characters, we primarily expect an email address to be input in Latin script (and, in our case, a phone number using numbers). So, the cursor in an empty field should be on the left. We make an exception in CSS.
input[type=”email”]:placeholder-shown { direction: ltr;}
We shouldn’t stop there though. We still have the tel, number and URL field types. These are always left-to-right, so for them, we write the following code:
<input type=”tel” dir=”ltr” placeholder=”מספר טלפון”>And we add exceptions for empty fields:
input[type=”tel”]:placeholder-shown,input[type=”number”]:placeholder-shown,input[type=”url”]:placeholder-shown { direction: ltr;}
Now things are as we planned.
Just a few words to anyone concerned about IE11. This browser does not understand the dir=”auto” attribute, so there is no way of automatically changing the direction of the text without using JavaScript.
However, we still give users the option to input email addresses and telephone numbers conveniently.
.ie11 input[type=”email”],.ie11 input[type=”tel”] { direction: ltr;}.ie11 input[type=”email”]:-ms-input-placeholder,.ie11 input[type=”tel”]:-ms-input-placeholder { direction: rtl;}
If you put together the whole CSS, add the prefixes and the SCSS preprocessor, then you get something like this (yes, yes, we know that you can have checkbox-type INPUT fields, for example, but we’ll ignore this point for now for the sake of simplicity):
[dir=”rtl”] input { &::-webkit-input-placeholder { direction: rtl; } &::-moz-placeholder { direction: rtl; } &:-ms-input-placeholder { direction: rtl; } &::placeholder { direction: rtl; } &:placeholder-shown[type=’email’], &:placeholder-shown[type=’tel’], &:placeholder-shown[type=’number’], &:placeholder-shown[type=’url’] { direction: ltr; }}.ie11 [dir=”rtl”] input { &[type=”email”], &[type=”tel”] { direction: ltr; &:-ms-input-placeholder { direction: rtl; } }}
For us, we divide styles into LTR and RTL, so we don’t have a cascade from [dir=”rtl”], and we write the properties for LTR, so they change direction to RTL. But, I think, the principle is clear.
For TEXTAREA the arrangement is the same, with one exception: in the case of TEXTAREA field types and position the cursor or the text to the left are of no consequence — the content always changes direction automatically on account of the dir=”auto” attribute.
One important point which should not be forgotten is that all requirements vis-à-vis fields also apply to LTR interfaces. If a name is input in Hebrew or Arabic it must be shown on the right side, and the cursor must be to the left. In the rare case of a user with an exotic right-to-left email address, they must see their email as they have input it, namely RTL.
Summary
By adding the correct attributes to input fields and several lines of CSS, at no great effort, we can either completely adapt forms for RTL languages, or at least make them significantly more logical and easier to use.
