Whether your application should display its content in RTL should be based on the content

Raymond Chen

A customer had the following puzzle:

We have a small bootstrapper application that consists of a dialog box and a few message boxes. The problem is that we want our application to work properly on Arabic and Hebrew systems, and we can’t come up with a good way to determine text direction of the underlying system. We found this article by Michael Kaplan that tells us how not to do it, which is great, but what’s the recommended way of actually doing it?

You already know whether you should be displaying your application’s UI in LTR or RTL: If this is the Arabic-localized or Hebrew-localized version of your application, then display it as RTL. If this is the English-localized or French-localized version, then display it as LTR.

There’s no point in trying to display your English-language strings in RTL just because the underlying operating system is Arabic. If your strings are in English, then display them in the way they should look to an English speaker. A dialog box like this helps nobody:

When your localization team translates the application into Arabic, they can insert two copies of U+200E (LEFT-TO-RIGHT MARK) at the start of the File­Description in the version resource. That is the signal to Windows that the application should have RTL as its default layout direction.

If you want your application to choose a language dynamically (say, to use English strings if running on an English system but Arabic strings if running on an Arabic system), then you can add a flag in your resources so that the localizers can indicate whether a particular language pack expects text to run left-to-right or right-to-left.

IDS_LANGUAGE_DIRECTION "LTR" // change to RTL if localized in Arabic, etc.

Your application could then check the direction and call Set­Process­Default­Layout based on the result.

Raymond Chen

Follow