How to Translate a Presentation into Arabic or Hebrew Without Breaking the Slides

Translating a deck into Arabic or Hebrew fools people twice. The first surprise is that the text comes back correct and the slides still look wrong. The second is that repairing the slides takes longer than the translation did. When you translate PowerPoint into Arabic, RTL is a layout question before it is a language question, and PowerPoint answers only part of it for you.

We have rebuilt enough Arabic and Hebrew decks after the fact to know where the damage concentrates. It is almost never the sentences. It's the arrows pointing the wrong way, the numbered steps running backwards, the table columns in reverse reading order, the fonts that quietly swapped themselves, and the speaker notes that nobody thought to include in the scope.

What right-to-left actually changes inside a PPTX file

There are two separate layers here, and confusing them is the root of most RTL disasters.

The first layer is character ordering inside a run of text. Every modern renderer applies the Unicode Bidirectional Algorithm (UAX #9), which decides how a string containing both Arabic and Latin characters gets laid out for display. If a line mixes Arabic words with a product name and a version number, the algorithm sorts the direction changes on its own. You do not configure this, and you rarely need to think about it, except when it produces something odd around punctuation and numbers.

The second layer is paragraph and shape direction, and this one is yours. A paragraph has a direction property: set it to RTL and bullets move to the right edge, indentation flips, and the text aligns right by default. PowerPoint exposes this per paragraph, and when an RTL editing language is enabled it also offers a slide-direction setting that reverses placeholder order on the slide.

Neither layer moves your shapes. A logo anchored to the top-left corner stays in the top-left corner. A three-column layout keeps column one on the left. An arrow drawn pointing right keeps pointing right, which now means it points backwards against the reading flow.

That gap is the whole problem. The translation step changes the words. Direction properties change the text flow inside each box. Nothing changes the composition of the slide, so the deck ends up half-mirrored: right-aligned Arabic paragraphs sitting inside a left-to-right visual structure. Native readers notice this in under a second, the same way you would notice a reversed English slide.

Where an Arabic or Hebrew deck breaks first

Not every element needs mirroring, and the decisions are not evenly difficult. In our experience the damage clusters in six places.

Multi-column layouts read in the wrong order. A two-column comparison slide where column one is the current state and column two the future state now reads back to front.

Process diagrams and arrows carry direction as meaning. A five-box workflow with arrows pointing right is a sentence, and translating the labels without reversing the boxes leaves that sentence inverted.

Numbered steps and step badges break the same way when they are drawn as shapes rather than typed as a numbered list.

Tables reverse reading order. Column headers usually need to run right to left, which in PowerPoint means physically rebuilding the table rather than toggling a setting.

Charts hold text in places translation tools may not reach: axis labels, legends, data labels, and anything baked into a linked or pasted image.

Mixed content behaves strangely near boundaries. Product names, URLs, version numbers, and code fragments stay left to right inside an RTL paragraph, and the punctuation bordering them can land on the visually wrong side.

One concrete case: a 24-slide onboarding deck we saw go English to Arabic came back with every paragraph correctly translated and right-aligned. The body text was fine. The five-stage implementation diagram on slide 11 still ran left to right, the numbered icons underneath it counted up in the wrong direction, and the comparison table on slide 18 put the "before" column where an Arabic reader expects "after". Three slides, roughly two hours of rework, on a deck whose translation took less time than that.

How to prepare a PowerPoint deck before you translate it into Arabic or Hebrew

Preparation is where most of the rework gets avoided, and it takes about twenty minutes on a normal deck.

Decide the mirroring policy first, and write it down. Not every slide should flip. Title slides and photo-led slides usually need nothing. Diagrams that encode sequence almost always need reversing. Screenshots of an English product interface should stay exactly as they are, because a mirrored screenshot shows something that does not exist. Settling this before anyone opens the file stops the question from being answered five different ways on five different slides.

Find the text that is not really text. Open the outline view and compare it against the slides. Anything visible on a slide but missing from the outline lives in an image, a chart object, or a grouped shape, and needs separate handling. Text inside a PNG will not be translated by any tool that works on the file structure, and it is better to discover that now than during review.

Set the font before translation, not after. If your deck uses a Latin-only font, the renderer substitutes something else the moment Arabic or Hebrew characters arrive, and the substitution is not always the same on every machine. Choosing a font with proper coverage up front means the translated file looks the same for you and for the client.

Loosen the layout. Turn off shrink-text-on-overflow where you can, because it hides overflow problems by making the type unreadable instead. Leave roughly ten percent of empty space in every text box in the source deck.

Brief the translator or the prompt. List the terms that stay in Latin script, the numeral convention, and whether the target is a specific regional variant. Without this, you get a reasonable but inconsistent answer across the deck.

Fonts, numerals, and the details a native reader notices immediately

Arabic script is contextual: letters change shape depending on their position in a word, and they join. A font without proper Arabic support does not simply look plain, it renders disconnected letterforms that read as broken. Calibri, still the default in plenty of corporate templates, carries no Arabic glyphs, so PowerPoint falls back to whatever is available and your typography choices vanish. Faces shipped for the purpose, such as the Arabic and Hebrew fonts bundled with Office, are a safer starting point than anything chosen for how it looks in English.

Line height is the second font trap. Arabic sits on a taller effective line than Latin text at the same point size, and diacritics extend above and below. Any text box with fixed line spacing tuned for English will clip. Switch to multiple line spacing and give it room.

Numerals are a decision, not a default. Arabic is written with either Eastern Arabic-Indic digits (٠١٢٣٤) or Western digits (01234) depending on the region: the Gulf and Egypt commonly use the former, the Maghreb uses the latter. Hebrew uses Western digits. Pick one convention per target market, put it in the glossary, and apply it to every figure in the deck including chart data labels.

Punctuation has its own forms too. Arabic uses a reversed comma (،), a distinct semicolon (؛), and a mirrored question mark (؟), and using the Latin equivalents throughout is the sort of thing that makes a deck read as machine output.

A second case from our own review queue: an English to Hebrew pricing deck where the translation was clean but the figures were not. A price string had been left as a Latin run inside an RTL paragraph, and on several slides the currency symbol rendered on the side a Hebrew reader would not expect, while the thousands separator stayed in a format the client's finance team does not use. None of that is a translation error. All of it looked like one to the client.

Text length, autofit, and why Arabic slides overflow in odd places

Published expansion tables tend to say Arabic runs longer than English and Hebrew runs shorter. Treat these as rough planning numbers rather than rules, because the result depends heavily on register and on how much of your source is product names that do not change at all.

What matters more on slides is that length behaves differently here than in a document. A Word file reflows; a slide does not. A bullet that grows by fifteen percent has nowhere to go except a fourth line the designer never planned for, and once a text box is full, PowerPoint's autofit starts shrinking type. The slide still technically fits. It now has 12-point body text next to a 20-point heading, which is the most common sign of a deck that was translated without a layout pass.

Headline boxes are the tightest constraint, because they are usually sized to the exact width of the English phrase. Short Hebrew headlines create the opposite problem: a title box sized for a long English line leaves a wide empty gap on a right-aligned slide, which reads as an accident rather than a choice.

This works best when the source deck was built with some slack. If you control the English original and you know it will be localized, leaving whitespace and avoiding manually kerned single-line titles saves a full round of rework later. It does not apply when you inherit a finished client deck, in which case plan review time rather than hope for it.

The review pass: check the deck the way an Arabic reader would

Linguistic review and visual review are two jobs, and doing them in one pass means both get done badly.

For the language, a bilingual view works better than reading the translated deck alone. A source-and-target table lets a reviewer check terminology and consistency across the whole deck without hunting through slides, and it separates "this term is wrong" from "this box is the wrong shape".

For the layout, run the deck in presentation mode rather than edit mode, on a second screen if you have one. Watch for animations that reveal elements in the original left-to-right order, arrows that now contradict the reading direction, and any slide where your eye starts in the wrong corner. Then export to PDF and check it again, because PDF export is where missing font embedding shows up as boxes or substituted glyphs.

Speaker notes deserve their own check. They are frequently left out of scope, and then someone presents from them.

If the translation step itself is the part you want to hand off, a structured workflow helps more here than a one-click translator. SnapIntel takes a PPTX directly, prepares a glossary and translation prompt you can review and approve before anything runs, and returns a translated presentation along with a QA report and a neutral source/target XLSX export you can use for the bilingual review described above. It covers the text layer, including slide, table, grouped-shape, and notes content. The mirroring decisions on diagrams remain a human call, which is true of every tool we know of.

What to do on your next Arabic or Hebrew deck

Work in this order and the slides survive.

1. Audit the source deck for text living in images, charts, grouped shapes, and speaker notes, and decide how each will be handled.
2. Write a one-page brief covering the numeral convention, the regional variant, the do-not-translate list, and which slide types get mirrored.
3. Set an Arabic or Hebrew capable font across the template and switch fixed line spacing to multiple before translating anything.
4. Translate, then set paragraph direction to RTL on the translated text.
5. Mirror only the slides your brief says should mirror, rebuilding tables and reversing diagram sequences by hand.
6. Review language and layout as separate passes, finishing with a PDF export check.

The step people skip is the second one. A deck can be translated well and still be wrong for its reader, and the brief is what stops the client from being the one who discovers it. For the format mechanics underneath all of this, our guide on translating a PowerPoint without breaking the slide layout goes deeper on what survives a translation round trip.