Web Localization with Right-to-Left Languages in Mind
When modeling localization scenarios, we frequently work with languages that have a presence at the Institute: Spanish, French, German, Russian, Traditional and Simplified Chinese, Japanese, and Korean. This offers a variety of interesting challenges that we need to prepare for when facing a new project, but there is a caveat. When preparing for potential challenges during the localization process, text direction is something we don’t tangle with as often as we’d like. All our go-to languages are read from left to right (a.k.a. “LtR languages”).
That’s why, when choosing our final project for Max Troyer’s “Website Localization” class, my partner and I chose to study best practices for accounting for text direction in web design and to how that applies to WordPress+WMPL localization workflows.
Starting From the Ground Up
We chose to narrow our language focus to Arabic. Before going off and getting elbows deep in WordPress, we looked at what the existing best practices were, both in theory and as use cases. In lieu of weighing down the theoretical portion of this blog post, please enjoy the cliffs notes:
Essentially, RtL localization is bidirectional localization. While Arabic may read from right to left, words in LtR languages are still left in that direction.
Since language directionality affects the way our readers perceive time and navigate two-dimensional space, things like formatting and layouts must also shift to take that into consideration.
However, localizing a web layout cannot simply be solved by mirroring your website. Some things do flip, while others do not.
For example, the order in which hours, minutes and seconds are listed does change, but numbers and date directions do not.
Latin letters and any cases of LTR, unsurprisingly, remain the same.
Anything related to how a reader may perceive the start and beginning of an interface: progress indicators and tables, for example, do get flipped.
Playback icons, on the other hand, are such ubiquitous bits of UI that they also stay the way they are.
Icons should be localized with respect to cultural norms and the direction of the flow of time.
Also of import is making sure your fonts support Arabic justification. Instead of white space, Arabic formatting usually uses kashida justification, where the horizontal strokes of some characters are elongated.
It’s also worth paying attention to the best practices of large companies. We can check with Al Jazeera to confirm that the website layout does change as the reader experience direction changes.
Another interesting tidbit is the YouTube approach to UI. When Arabic is selected as a language, but the country remains something non-RTL-centric like the United States, the layout remains formatted to match the country’s norm. This allows a user to easily switch between English and their RtL language without seeing a new UI every time. If we then switch our region to an RtL-centric country, the layout does flip, with all of the details that entails.
How YouTube looks to Arabic users in the US.
How Youtube looks to Arabic users in Algeria.
If we were coding from the ground up, we could account for any necessary layout changes in a rtl.css file. If we’re working with WordPress and pre-existing themes, however, we’re left with a far more nuanced field of options.
Working up to WordPress
We wanted to test a hypothetical situation. Say a client comes to you with an existing WordPress website and wants to localize it into a number of languages, some of which go from right to left. Say they are happy to use WPML, so all that’s left is threat analysis. What potential pitfalls may we face? WordPress has robust language support and WMPL can also handle some things with adding an RtL language, but what other problems may occur?
The trick is the theme.
Clients coming to us with an already existing website are likely to already have a theme for their website. We wanted to see what we would need to warn our clients about, should they ever come to request our aid in internationalization, even if they are not choosing an RtL language just yet.
We first took a layout that seemed simple and didn’t proclaim to support RtL and localized it to Arabic. Unsurprisingly, WordPress and WPML handled the language functions beautifully. However, the layout remained unchanged, which made it incredibly unsuitable for consumption in RtL-centric countries.
Then we took a layout that did support RtL languages, and saw what changed, with minimal input from us. Even when not all of the material on the page was translated, the layout shifted beautifully, following best practices with no input from the project manager.
The original layout of a RtL supporting theme.
The layout right after rudimentary localization. Note that even featured images haven’t been reinstated for this page but the layout is still perfect with no input from the localizer.
This is heartening. But what does it mean for our client? If they come in with theme that doesn’t support RtL languages, but may at some point see themselves needing localization to an RtL language, they have a few choices:
They can either choose to forgo supporting an RtL layout entirely. This is, perhaps, the cheapest option. As we saw in earlier use cases, if the audience is located within the same country, perhaps a layout shift is unnecessary. But it all depends on how frequently users will interact with that website in that language in that region. There is a risk of a negative net impression of the localized site, as the new market may feel offended that the client did not take their needs into consideration.
They can ask their engineers to add RtL support for their existing theme. This may be a good option for companies that have a proprietary theme. If a company of this size is looking to internationalize, they may want to hit the ground running and add RtL support to the number of other changes that need to be implemented for localization to go smoothly before translation begins. It’s worth keeping this option in the back of our clients’ minds, even if they aren’t initially translating into an RtL language.
Last but not least, they may choose to change their theme to one with RtL support. This may require a bit of effort on the end of the client, after all, this means fixing the formatting of every page all over again. However, it may be the most cost-effective option for a smaller firm, with the benefit of switching them over to a more robust theme. Our experience showed that when localizing a theme that already has RtL support, the localization process goes smoothly and the end result is the most attractive.
All of this, of course, depends on the needs and budget of your client. But, as a localization professional, we ought to remember that forewarned is forearmed! RtL support is an important part, not just of a localization workflow, but of client’s internationalization at large.
