Why translating a deck into Arabic is not enough
The usual process is to export the text, send it to a translator, and paste the results back into the same slides. What comes back is a deck that is technically in Arabic and visually still in English. The reading order now runs right to left across a composition built left to right, so the eye enters the slide where the layout put the footnote and exits where it put the logo. Progress arrows point backwards through time. Bulleted lists hang their markers on the wrong side. Nothing is misspelled and the whole thing reads as an afterthought, because it was one.
An Arabic reader notices this in the first second, in the same way an English reader would notice a deck whose headlines were all flush right against a left-hand photograph. It is not a translation problem. It is a layout problem that translation exposed.
What has to mirror, and what must never
The work is entirely in the boundary between these two lists, and getting it wrong in either direction produces something worse than doing nothing.
- Mirrors: the order of the slots across the slide, text alignment, list markers and indents, quotation marks, process chevrons and any arrow that means "next", the slide rail, and the direction a two-column layout is read in.
- Does not mirror: numerals and the digits inside them, chart axes and the bars and lines drawn against them, Latin brand names and product names, code, email addresses, URLs, phone numbers, and any timeline whose left-to-right order carries its meaning.
The chart case is the one people get wrong most often. A bar chart mirrored wholesale reads as a chart of a different dataset: the categories run backwards and the trend appears to reverse. Charts are drawings of numbers, and numbers are not directional. They stay put, and only the text around them moves.
How mixed Arabic and English text behaves on one slide
Almost every real Arabic business deck is bidirectional. A sentence in Arabic contains an English product name; a metric label in Arabic sits above a figure in Western numerals; a customer quote names a company that has never had an Arabic form. Direction is a property of each run of characters, not of the text box that holds them, so a box set to right-to-left still renders the Latin run inside it left-to-right and the surrounding Arabic right-to-left. That is correct behaviour rather than a bug, and a tool that forces one direction on the whole box is the reason English brand names sometimes appear reversed in badly-made Arabic decks.
The practical consequence for whoever writes the deck: do not try to fix bidirectional text by inserting spaces or reordering words by hand. It will look right in the editor and wrong the moment the text reflows at a different size.
Why Arabic type needs more room than the same size in Latin
Arabic script has a taller effective x-height, a deeper descender and diacritics that sit above the line, so the same nominal point size occupies more vertical space and needs more leading before lines start to collide. It also sets shorter than English for the same content more often than not, which means a headline slot sized to a character budget in English usually has room to spare in Arabic — and a slot that was tight in English can still overflow if the translation is a literal one. This is exactly what the editor’s per-slot character budget is for: it reports which slides overflow rather than leaving somebody to notice in the room.
Doing it once, at the layout level
The reason to handle direction in the layout system rather than per slide is that a per-slide fix does not survive editing. Somebody adds a slide next week from the same template and it comes out unmirrored; somebody swaps a layout and the alignment reverts. When mirroring is a property of the deck’s language setting and the layouts respond to it, a deck stays consistent no matter who edits it afterwards or which agent does the editing — the MCP server exposes the language setting as a tool, so an agent can build an Arabic deck correctly without being told the rules.
Common questions
- How do I make an Arabic presentation with right-to-left layout?
- In Slideable, set the deck language to Arabic and the layout mirrors as a whole: slot order, text alignment, list markers and the slide rail all reverse. Numerals, chart axes and Latin brand names deliberately stay as they are, because they are not directional.
- Does PowerPoint support right-to-left Arabic slides properly?
- PowerPoint can set text direction and alignment per text box, but it does not mirror a slide layout as a unit, so the composition itself stays left-to-right unless somebody rebuilds each slide by hand. That hand work is what usually does not survive the next edit, which is why Arabic decks tend to drift back to a Latin composition over time.
- What should not be mirrored in an Arabic slide?
- Numerals, charts and their axes, Latin brand and product names, code, URLs, email addresses, phone numbers, and any timeline whose left-to-right order carries meaning. Mirroring a bar chart makes it read as a different dataset, because the categories run backwards and the trend appears to reverse.
- Can I keep one deck in both English and Arabic?
- Yes — the language is a deck-level setting, so the same layouts, Brand Kit and washes carry across and only direction changes. That keeps a bilingual pair looking like one deck in two languages rather than two decks that happen to share a logo.