Translating a document into Hebrew or Arabic is only half the work. The other half is making the translated text sit correctly on the page, in a form, on a website, or inside a court exhibit. Both languages are written from right to left, and that single fact cascades into dozens of typographic decisions that Latin-script workflows never have to consider. A translation that reads beautifully but renders with reversed parentheses, broken alignment, or a scrambled passport number is not a finished translation. It is a liability.
At Niv International Translations, founded in Rishon LeZion in 1999, we have prepared right-to-left (RTL) documents for the Ministry of Interior, Israeli courts, hospitals, and multinational companies for over two decades. The lessons below come from real files: birth certificates bound for apostille, bilingual contracts, medical records, and corporate filings. The goal of this article is to explain why RTL typography is genuinely hard and what separates a correctly produced document from one that gets rejected at the counter.
Why right-to-left text breaks Latin-built layouts
Most software, templates, and design systems were built with left-to-right (LTR) text as the default assumption. Margins, indentation, list bullets, table column order, and even the position of a logo are all anchored to the left edge. When you pour Hebrew or Arabic into such a layout, the visual logic inverts. Paragraphs should align to the right, bullet points should sit on the right, and the natural reading flow of a table moves from the rightmost column inward. If the layout is not genuinely mirrored, the reader's eye is forced to fight the page.
The deeper problem is the Unicode Bidirectional Algorithm, the rule set that decides how mixed-direction text is displayed. A Hebrew sentence that contains an English brand name, a Latin-script email address, or a sequence of digits is bidirectional by nature. The algorithm usually resolves this correctly, but punctuation at the boundaries, brackets, slashes, percentage signs, and quotation marks, frequently jumps to the wrong side or flips orientation. A phone number written as +972 inside a Hebrew line can display with the plus sign stranded on the wrong end, and the reader may not notice until the number is dialed.
The numbers and punctuation trap
Numbers are the single most common point of failure in RTL documents, and they matter most precisely where errors are least forgivable: identity numbers, case numbers, dates, monetary amounts, and dosages. Hebrew and Arabic both write numerals left to right even though the surrounding text runs right to left, so a string like an Israeli teudat zehut number or a court docket reference becomes a small island of LTR inside an RTL paragraph. Without explicit directional control, a nine-digit ID can split across a line break or reorder its segments.
Punctuation compounds the danger. The Hebrew gershayim and geresh, the Arabic comma and question mark which have their own mirrored Unicode characters, and ordinary parentheses all behave differently depending on the surrounding script. A closing parenthesis can render as an opening one, dates written with slashes can reverse day and month order visually, and decimal points can drift. In a medical record or a notarized affidavit, a visually transposed digit is not a cosmetic issue. It is a clinical or legal error, which is why human review by a native typesetter is non-negotiable for documents destined for the Ministry of Interior or the courts.
Fonts, ligatures, and the shape of the letters
Hebrew and Arabic make very different demands on type. Hebrew has no uppercase and no inherent letter joining, but it carries optional vowel points (nikud) and cantillation marks that must be positioned precisely above, below, or inside the consonant. Many fonts that look acceptable for plain text collapse the moment nikud is added, stacking marks on top of one another or clipping them at the line height. For documents that require pointing, such as certain religious, educational, or accessibility materials, font selection is a substantive decision rather than an aesthetic one.
Arabic is more demanding still. It is a cursive script in which almost every letter changes shape according to its position in the word (isolated, initial, medial, or final), and correct rendering depends on the font implementing those contextual forms plus the ligatures that join them. A font that lacks full Arabic shaping will produce disconnected, broken-looking words even when the underlying Unicode is perfectly correct. When a single document must present Hebrew, Arabic, and Latin together, as Israeli official paperwork often does, the typesetter needs a font family that handles all three scripts coherently, with matching weights and a comparable visual color, so that no language looks like an afterthought.
RTL on the web and in editable formats
Digital delivery adds its own layer of difficulty. On the web, correct RTL behavior depends on setting the document or element direction explicitly (the dir attribute and CSS logical properties) rather than hard-coding left and right values. Modern CSS offers margin-inline-start, padding-inline-end, and similar logical properties that automatically respect direction, but many sites still use physical left and right rules that silently misbehave once content is translated. Icons that imply direction, such as back arrows and progress indicators, should also be mirrored, while logos and certain symbols should not.
Editable formats carry a hidden risk. A Word or InDesign file produced in an LTR environment can look correct on the translator's screen yet shift when opened on a different operating system, a different software version, or after conversion to PDF. Copy and paste between applications frequently strips the invisible directional control characters that were holding a mixed-direction line together. This is why a professional RTL workflow treats the final exported artifact, usually a flattened, font-embedded PDF, as the deliverable of record, and verifies it on a clean machine rather than trusting the working file.
What a professional RTL workflow looks like
Producing reliable Hebrew and Arabic documents is a process, not a single step. It begins with a native linguist who writes idiomatic copy rather than a literal calque, continues through a typesetter who mirrors the layout and chooses fonts that survive nikud and Arabic shaping, and ends with a proofreader who checks every number, date, and proper noun against the source. For certified work, the chain extends further: the translation must match the format expected by the receiving authority, whether that is an Israeli court, a hospital intake desk, or a foreign consulate processing an apostille.
The practical takeaway is simple. RTL typography is where translation quality becomes visible or falls apart, and it cannot be automated away. Machine output and generic templates routinely pass the words while failing the layout, and in official Israeli contexts a layout failure can mean a rejected application and a wasted trip. When a Hebrew or Arabic document carries legal, medical, or governmental weight, insist on native-language production and a human review of the final rendered file. That is the difference between a translation that merely says the right thing and one that is accepted without question.