How to handle right-to-left languages in document localization

Right to left document localization goes wrong in a predictable way. The translation itself is fine. The client opens the file and the first page looks shaken: bullet markers sit on the wrong side, a part number inside an Arabic sentence has its brackets facing outward, and the numbered clauses in a contract step their indentation the wrong direction. We see files like this most weeks. Almost none of them have a translation problem. They have a text-direction problem nobody caught, because the person doing the final check could not read the language and did not know which handful of things to look at.

Here is what breaks in DOCX, XLSX and PPTX when the target is Arabic, Hebrew, Persian or Urdu, and how to catch it without reading a word of the target text.

What right to left document localization actually means inside a file

The first mistake is treating right to left as a mirroring operation applied to everything on the page. It is not. Arabic and Hebrew are bidirectional scripts. The sentence runs right to left, but numerals, Latin brand names, email addresses, URLs and product codes embedded in that sentence still run left to right. You end up with a paragraph that has two directions in it, and the rules for how they interleave come from the Unicode Bidirectional Algorithm, published as Unicode Standard Annex #9 and implemented by every text renderer you will touch.

That algorithm does most of the work for you. It also produces most of the failures, because characters like parentheses, slashes, hyphens, commas and spaces are directionally neutral. They take their direction from whatever sits around them. A neutral character between an Arabic word and a Latin code has to pick a side, and it will not always pick the one you meant.

The second distinction worth getting right early: direction is a property of the paragraph, not of the alignment. Right-aligning a paragraph of Arabic in Word produces something that looks correct on screen and behaves wrongly the moment anyone edits it, or the moment mixed content appears. Alignment moves pixels. Paragraph direction tells the renderer where the line starts, where sentence-final punctuation belongs, which side list markers sit on, and which way indentation steps.

Arabic and Hebrew also differ from each other in ways that reach the deliverable. Hebrew uses Western digits in practically all business documents. Arabic may use Western digits or Eastern Arabic-Indic digits (٠١٢٣) depending on the country and the client's house style, and that is a decision to settle in the brief rather than discover at delivery. On a two-page letter it does not matter. On a 200-page catalogue with figures on every spread it matters a great deal.

Where DOCX files break when the target runs right to left

In a DOCX, direction is stored per paragraph and per run, and both can disagree with the style they inherit from. That is where most of the damage starts.

A case from our inbox: a 60-page employee handbook translated into Arabic by a competent translator who right-aligned every paragraph instead of setting paragraph direction. At handover it looked correct. The client's HR lead opened it in Word, added one sentence to a clause, and the full stop at the end of that paragraph moved to the wrong end of the line. She added a cross-reference, and the numbered list below it reversed its indentation. Nothing was wrong with the Arabic. The file simply carried no direction, so Word treated those as left-to-right paragraphs that happened to be pushed against the right margin.

The places that get missed, roughly in order of how often we see them:

Paragraph direction on body text, which is the one everyone remembers
Numbered and bulleted lists, where both the marker side and the indent direction follow paragraph direction
Tables, where column order is controlled by table direction and will not flip because you flipped the paragraphs inside the cells
Headers, footers and footnotes, which carry their own direction and are edited in a separate pane
Text boxes, captions and diagram labels, each with its own settings
The style definitions themselves, which keep reasserting the original direction every time someone applies a style

A document where the paragraphs are right but the styles are not will look clean at handover and degrade with every client edit. That is a worse outcome than an obviously broken file, because nobody connects it back to the translation vendor six weeks later. If the document is going to be maintained rather than archived, fixing direction at the style level is the part that pays for itself. It belongs in the same category as the other post-translation layout failures we wrote about in what to do when a document's layout breaks after translation.

Numbers, part codes and dates inside Arabic and Hebrew text

This is the failure that survives every review done by someone who cannot read the script, because it looks like a rendering quirk rather than an error.

Take an Arabic sentence containing the string Model (TX-400/2). The Latin letters have strong left-to-right direction and hold together. The parentheses, the hyphen and the slash do not. Depending on what sits immediately before and after the group, the closing parenthesis can render to the left of it and the opening one to the right, so the reader sees )TX-400/2(. The underlying characters are correct. The display is not, and it prints that way.

We hit this on a Hebrew price list exported from a client's ERP: around 900 SKU strings shaped like AB-1200/3, each dropped into a Hebrew description cell. About forty rendered with the trailing digit visually detached and sitting at the wrong edge of the string. The translator had delivered correct text. The client's procurement team, reading at speed, ordered against two codes they had misread.

The fixes are small and worth knowing:

Insert a left-to-right mark (U+200E) or right-to-left mark (U+200F) next to the neutral characters to pin them. In Word that lives under Insert, Symbol, Special Characters.
Where the string is a fixed identifier, wrap it so its boundaries are explicit instead of relying on whatever happens to precede it.
Settle the digit convention and the date format in the brief. 12/05/2026 is ambiguous in any direction, and its slashes are neutral on top of that.
Place currency symbols deliberately. A symbol that precedes the number in English often follows it in Arabic copy, and that is a locale decision rather than a bidi one.

How much this matters scales with how many codes, measurements and dates the document carries. A marketing brochure survives some sloppiness here. A parts manual does not.

Tables, slides and the question of what to mirror

Spreadsheets have a sheet-level setting that displays columns right to left, so column A appears at the right edge. It changes display only, not formulas or cell references, and it is the setting people forget because the translated text looks fine without it. An Arabic reader scanning a price table starts at the right. If the sheet is still left to right, they start at the last column, which on a quotation is usually the total. We have watched a quotation get misread that way twice.

Presentations are harder, because PPTX raises a question with no automatic answer: what should mirror, and what should stay where it is?

Text boxes follow their own direction setting and should be flipped. Shape positions do not flip automatically, and sometimes they should not. A process diagram with arrows running left to right implies a reading order that is now backwards for the audience, so the flow should be mirrored. A screenshot of an English software interface should not be, because the software still looks like that. A timeline with years running left to right is a real judgement call that depends on whether the audience reads the years or the shape first. Our default is to mirror it and label the direction clearly, though we would not argue with someone who chose the opposite.

That judgement is the part no tool makes for you, and it is why decks for Arabic and Hebrew need a layout pass by a person as well as a translation pass. The slide-level mechanics are covered separately in how to translate a presentation into Arabic or Hebrew without breaking the slides.

Text expansion worries people more than it should. Arabic running text is often slightly shorter than English by character count. What it needs is more vertical room per line, which is a different problem, and the next section is about that.

Fonts and line spacing, where a file looks fine until someone else opens it

Word stores a separate font setting for complex scripts. Setting the document font to Calibri 11 does nothing to the Arabic, which keeps whatever complex-script font the style carries. The result renders in two typefaces depending on the character range, usually noticed only when the client prints it.

Then there is fallback. If the chosen font has no Arabic glyph coverage, the renderer substitutes one that does, and the substitution depends on what is installed on that machine. A 40-page Arabic manual we reviewed last year looked correct on the translator's laptop and reached the client as a PDF with empty boxes through two chapters, because the font was never embedded and the client's print shop did not have it. The translation was fine. The delivery was unusable, and the deadline was that afternoon.

Line spacing is the other one. Arabic carries diacritics above and descenders below the baseline, and templates built for Latin text often set line spacing to an exact point value. Exact spacing clips glyphs instead of growing to fit them. The characters are all present, and the top of every third line is sliced off. Switching those paragraphs to a multiple or at-least value fixes it in one pass.

Justification behaves differently too. Arabic typesetting traditionally stretches the connecting strokes between letters rather than the spaces between words, and Word's justification does not imitate that convincingly in every font. For body text it is usually acceptable. For a short headline it can look wrong enough that a client writes to you about it.

None of these are translation errors, and none of them are caught by reading the target text. They are caught by opening the file on a second machine and exporting a PDF before delivery, which takes about four minutes.

Running QA when nobody on the team reads Arabic

Most agencies taking their first Arabic or Hebrew job have no reviewer in house, and the honest answer is that anything being published still needs a native-speaker read. But a lot of right-to-left damage is detectable without knowing the language, because it shows up in things you can count.

Checks that need no reading of the target:

Numbers in source and target match, in value and in count. Bidi damage to codes and figures usually changes the visible string, so a numeric comparison catches it.
No untranslated segments, and no segment count mismatch between source and target.
Terms that were meant to stay in Latin script are present and unaltered.
Every paragraph has a direction property set, not merely right alignment. If you want certainty, that is visible in the file's XML.
A complex-script font is set, and that font is embedded in any PDF you produce.
The delivered file opens correctly on a second machine.

There is also a copy-and-paste test anyone can run. Take a paragraph with a mixed Latin and Arabic string, paste it into a plain text editor, and confirm the characters are in logical order and the digits intact. You do not need to understand the words to see whether TX-400/2 survived.

If the translation step itself is what you want to standardise, SnapIntel takes a DOCX, XLSX or PPTX, runs domain analysis on it, and builds a glossary and translation prompt you review and approve before translation starts. That approval gate is a practical place to pin the product codes and brand names that must come through unchanged into Arabic or Hebrew. What comes back is the translated file in its original format, a neutral source/target XLSX you can move into any CAT tool, and a QA report covering the number and terminology checks above. It does not make the mirroring judgements from the previous section for you, and it does not replace a native reviewer on anything headed for publication.

What to do before the next right-to-left job ships

Settle three things in the brief before anyone translates: which digit convention the client wants, which date format, and which Latin strings stay untouched. Put the last of those in the glossary rather than in an email, because the glossary travels with the file and the email does not.

Then run this at delivery. On a 50-page document it takes about fifteen minutes.

Open the file with formatting marks on and confirm paragraph direction is set, not just alignment, including in headers, footers, footnotes and text boxes.
Check the styles as well as the paragraphs, if the client will be editing the document afterwards.
In tables, confirm the table direction flipped, rather than just the text in the cells. In spreadsheets, confirm the sheet's right-to-left display setting.
Search for Latin strings and look at each one in context. You are inspecting brackets, slashes and hyphens at the boundaries, which is a visual check anyone can do.
Set the complex-script font explicitly, export to PDF with fonts embedded, and open that PDF somewhere other than the machine it was made on.
Compare numbers between source and target with a QA tool rather than by eye.

The handbook that degraded after a single client edit and the price list with forty misread codes both passed a translation review. Neither passed a direction check, because nobody ran one. Add the direction check to the pre-delivery list you already have, and most of this stops happening.