Translating a deck into Arabic with the paragraphs actually right-to-left

TL;DR: When an Arabic translation looks broken in PowerPoint, the letters are almost never the problem. Arabic shaping and letter order are handled by the font, and they work. What breaks is paragraph direction: the paragraph is still marked left-to-right, so lines begin at the left margin and sentence-final punctuation lands on the wrong end of the line. The fix is a single attribute on each paragraph. SlideVerso writes it into every translated paragraph automatically when the target is a right-to-left language, and deliberately does not touch alignment, because overriding that breaks intentionally centred titles.

If you run Arabic enablement or training material, you have seen a deck come back from a translation tool where every word is correct and the whole thing still reads as amateur. This post explains exactly which layer failed, what the manual fix is, where mirroring fits, and how to check a translated deck in under two minutes.

Why does Arabic text render wrong after translating a PowerPoint?#

There are three separate layers, and only the third one usually fails.

Character shaping. Arabic letters change form depending on position in the word and join to their neighbours. This is the job of the font and the text engine, and modern PowerPoint does it correctly as long as the font in the run supports Arabic. If your Arabic comes out as disconnected letters, you have a font problem, not a direction problem, and the fix is to choose an Arabic-capable typeface.

Character order in memory. The Unicode bidirectional algorithm decides, at render time, the visual order of a run that mixes Arabic with Latin text or digits. This also generally works. It is why an English product name embedded in an Arabic sentence stays left-to-right inside a right-to-left line without anyone configuring anything.

Paragraph direction. This one is a stored property, not a computed one, and it is the layer that breaks. A paragraph carries a direction flag in the file. When it says left-to-right, the paragraph's base direction is left-to-right even if every character in it is Arabic. The visible symptoms are consistent: the block hugs the left margin instead of the right, first-line indents appear on the wrong side, bullet markers sit on the left of the text, and a full stop at the end of a sentence renders at the far left of the line, which is the single most recognisable tell.

A translation tool that writes Arabic strings into boxes that were built for English inherits the English paragraphs' direction flag unless it changes it. Most do not change it. That is the whole bug.

How do you fix right-to-left paragraphs in PowerPoint by hand?#

If you are repairing a deck you already have, the manual route works and is worth knowing.

1. Click into the text box and select all the text in it.
2. Press Ctrl+Shift+R. That toggles the paragraph to right-to-left. Ctrl+Shift+L goes back the other way.
3. Alternatively, open the Paragraph dialog from the Home tab and set the direction option there, which is useful when you want to see the current state rather than toggle blindly.
4. Repeat for every text box, every table cell and the notes pane on every slide.

Two refinements from people who do this often. Keep Arabic and English in separate text boxes where you can, because a box whose base direction has to serve both is a running argument with the bidirectional algorithm. And if the deck is built on a template you will reuse, set the direction in the Slide Master so new boxes inherit it rather than needing the same repair next quarter.

The arithmetic is why nobody enjoys this. A 60-slide training deck with a title, a subtitle, a bulleted body and a couple of table cells per slide is several hundred paragraphs. Step 4 is the afternoon.

What does SlideVerso do differently for Arabic?#

It writes the paragraph direction into the file as part of translating, so there is no step 4.

The engine keeps an explicit list of right-to-left primary language subtags, currently Arabic, Hebrew, Persian, Urdu, Pashto, Sindhi, Uyghur, Yiddish, Divehi and Central Kurdish. When the target language matches, every text frame it writes translated text into has each of its paragraphs marked right-to-left, by setting the paragraph-properties attribute that PowerPoint and Google Slides both honour. The same rule is applied on both output paths, so a file translated as .pptx and a deck translated natively behave the same way.

One decision inside that is worth stating, because it is the kind of thing that separates a deck that looks translated from one that looks made: alignment is deliberately left alone. It would be easy to right-align everything at the same time, and it would be wrong. Renderers already flip the default alignment when paragraph direction changes, so text that had no explicit alignment moves to the right on its own. Text that carried an explicit alignment, such as a title centred by the template designer, keeps it. Overriding alignment would un-centre every centred title in the deck in the name of fixing direction.

The rest of the pipeline is the same as any other target. The engine edits text runs inside the original .pptx structure rather than rebuilding slides, so images, charts, SmartArt and speaker notes survive as themselves, and the speaker notes are translated too. Every translated text frame gets shrink-to-fit set, which matters for Arabic because line counts change. A whole-deck coherence pass locks terminology before translation starts, which matters a great deal in enablement material where one English term must have one Arabic rendering across ninety slides. And a job that does not deliver a complete deck fails and is refunded automatically.

Do you also need to mirror the slide layout?#

Separate question, and the honest answer is that it depends on the deck.

Mirroring is real work and there are add-ins that automate parts of it, flipping slide element positions in bulk. It matters most on decks with a strong directional narrative: a left-to-right process diagram, a timeline with arrows, a before-and-after split. It matters least on a deck of titles, bullets and tables, which is most corporate enablement material. Text direction, by contrast, is never optional. A correctly mirrored deck with left-to-right Arabic paragraphs still looks wrong; a non-mirrored deck with correct paragraph direction reads fine.

How do you verify an Arabic deck in two minutes?#

1. Find a sentence that ends in a full stop and check the stop is at the left end of the line, which is the right end of the sentence. If it sits at the visual left of a right-aligned block, the paragraph is right-to-left and correct. If the whole block starts at the left margin, it is not.
2. Check a bulleted list. The bullet marker should be to the right of its text.
3. Check a table cell, not just a text box. Tables are the most common place for a tool to miss paragraphs.
4. Open the notes pane on a slide that has notes and confirm the same two things there.

To try this before paying, upload your .pptx at the app, pick Arabic as the target, and look at the free watermarked preview of one translated slide; choose a slide with a bulleted list and a full stop so the preview actually tells you something. The price shows before payment, by slide count: $19 up to 30 slides, $39 up to 80, $69 up to 150. Every supported target has its own page under the language pairs, and the layout guarantees are the same in Arabic as anywhere else.

Frequently asked questions#

How do I translate a presentation into Arabic with correct right-to-left text? Use a route that sets paragraph direction on the translated paragraphs. Characters shape correctly on their own; direction is a stored flag that has to be written. By hand it is Ctrl+Shift+R per paragraph.

Why does my Arabic PowerPoint look wrong even though the words are right? The paragraph is still marked left-to-right. Lines start at the left margin, bullets sit on the wrong side, and the sentence-final full stop appears at the left of the line.

Do I need to mirror the layout? Not for the text to read correctly. Mirroring is a design decision about visual flow and is worth it mainly on decks with directional diagrams or timelines.