Arabic and Hebrew email that keeps prices and links in order

Set the direction on each block of an Arabic or Hebrew email, and wrap every left-to-right run inside right-to-left text (prices, phone numbers, links) in its own isolating element, usually <bdi>. Email Digit does both when it renders an email: direction is decided block by block, and those runs are isolated so they keep their own order.

Why numbers and links get reordered

A screen decides the order of characters with the Unicode bidirectional algorithm. Letters carry a direction: Arabic and Hebrew letters are right-to-left, Latin letters left-to-right. Digits have only a weak direction, and so do the signs that travel with numbers, such as currency signs, plus and minus, slashes and full stops. Spaces and brackets have none at all. Characters without a strong direction of their own are placed according to what surrounds them.

That is fine for a word. It goes wrong for a run that is made of several parts joined by neutral characters. Inside an Arabic sentence, the spaces in +1 202 555 0143 can be resolved as right-to-left, and the groups of the phone number then display in reverse order. The same thing can happen to a price whose currency sign sits on the far side of the paragraph, or to a URL whose slashes and dots get pulled into the sentence around it. Every character is still there; the order is wrong, and the reader sees a different number from the one you typed.

It is easy to miss, because an email’s author usually checks it in an editor that shows it correctly, while the recipient’s mail client applies the rules strictly.

The fix, in plain HTML

Two pieces of markup handle almost every case:

1. A direction on the block. Put dir="rtl" on each Arabic or Hebrew paragraph, and dir="ltr" on English ones, rather than one direction for the whole email. A bilingual email with an English greeting and an Arabic body needs both.
2. An isolate around each left-to-right run. <bdi> tells the renderer to lay out its contents on their own, so nothing outside can reorder them.

<p dir="rtl" lang="ar">
  اتصل بنا على <bdi>+1 202 555 0143</bdi>
  والسعر <bdi>$18.50</bdi> فقط
</p>

Avoid invisible direction marks typed into the text as a fix. They work, but nobody can see them when editing, and the override characters among them are the same ones used to disguise links and file names. Markup is visible and safer.

What Email Digit does when it renders

The Message Builder has a text direction setting: Auto, LTR or RTL. Auto is the default, and it is the one that handles mixed email:

• Direction per block. Each block’s direction comes from its own text. A block that disagrees with the rest of the email gets its own direction and its alignment flips, so an English greeting above an Arabic body lays out correctly.
• Isolated runs. Inside right-to-left text, these are wrapped in <bdi> automatically: URLs, phone-like digit runs, prices with a leading $, £, € or ¥, and amounts followed by %, USD, EUR, GBP, SAR or AED. Only text is touched; a link’s address is left alone, so the link still works.
• Language and preview text. The email declares a language detected from its copy, and the hidden preview line that inboxes show next to the subject gets its own direction too, so an Arabic snippet does not appear with its punctuation on the wrong side.

English emails get none of this extra markup: isolation only happens inside right-to-left text.

Invisible characters are stripped

The same renderer removes direction-override and isolate control characters, the zero-width space and a few other invisible formatting characters from the text of paragraphs, quotes and table cells. They can make text display differently from what it says, which is how a disguised link or file name is built. Real Arabic and Hebrew do not need them, because direction comes from the markup above. Two invisible characters are kept on purpose, the zero-width joiner and non-joiner, because Persian, Arabic and several Indic scripts need them to spell words correctly.

Limits, and how to check your own email

• The patterns are specific. An amount written with a currency word in Arabic script, or with a currency code not listed above, is not isolated automatically. If it matters, put that sentence in an HTML block and wrap the amount in <span dir="ltr">, which that block keeps (it does not keep <bdi>).
• An explicit setting applies to everything. If you set the email to LTR or RTL instead of Auto, every block takes that direction. Use Auto for bilingual email.
• Mail clients differ. Markup removes the ambiguity, but a client can still render fonts and spacing its own way.

The quickest check is one test email. Write a paragraph in Arabic or Hebrew that contains a price, a phone number and a link, then use the Message Builder’s test send, which goes to your account email, and open it on your phone. If the three runs read correctly there, bidirectional text is surviving the trip.

Right-to-left handling is part of the renderer every email goes through, not a plan feature, so it is included from Lite at $7 a month. The pricing page lists what each plan sends.