Arabic support is not string replacement with a font swap at the end. A slide is a composition with a reading order built into it, and when the words run right to left while the slots still run left to right, the eye enters at the small print and leaves at the logo. The work is mirroring the layout — slot positions, alignment, list markers, the rail, arrows and process chevrons — while holding back everything that must not mirror: numerals, charts, Latin brand names, code. Replacing the strings is the easy half teams mistake for the whole job.
The usual process guarantees the failure. Export the copy, send it to a translator, paste the Arabic back into the same boxes. Every box now holds correct Arabic and the composition still says English: the headline sits top-left because that is where a left-to-right eye lands first, the progress bar fills towards the right edge, and the page number is pinned to the corner the reader now reaches last. Nothing is misspelled. All of it is backwards.
What actually has to mirror when a deck goes Arabic
Mirroring is a geometric reflection, not a style toggle. Slideable stores elements as absolute geometry in a 1280x720 space, so switching a deck to right-to-left moves nothing on its own — a title block stays stubbornly on the left until something reflects it. The reflection is one line: the new x is the slide width minus the old x plus the element width. Alignment flips with the position, because a column that keeps its old edge after the block has moved is worse than not moving it.
- Slot order, so a left image and right text column become a right image and left text column and the reader still meets the picture before the argument.
- Alignment: left becomes right, centre stays centre — and only where the direction genuinely changed, so text that was already Arabic is left alone.
- List markers, bullets and numbered indents, which belong on the inline start edge rather than a hard-coded left.
- Deck chrome. The page number takes a logical inline-start margin, so it lands at the far end of the footer in both directions without a second layout.
- Arrows and process chevrons. An arrow still pointing right in an Arabic deck points back towards the beginning.
- Quote marks and their hanging punctuation, which sit on the opening side of the quotation, and the opening side has just moved.
Two of these are decisions, not automation, which is why Slideable splits them into separate actions. Setting the deck direction re-flows the text and retags every box. Mirroring the geometry is a second button, because no code can tell whether the photograph on the left was a deliberate composition or an artefact of the template. Flip the split slides, the timelines, anything the eye traverses; leave the symmetrical ones alone.
What must never flip, even in a deck that reads right to left
The boundary is the actual craft, and nearly every visible RTL bug is something flipped that carried its own internal direction. Numbers are the loudest case. Arabic sentences run right to left, but a number inside one still reads left to right — the digits of 2026 sit in that order in an Arabic paragraph and in an English one, and mirroring them produces 6202. The Eastern Arabic forms behave identically: ٢٠٢٦ is read most-significant digit first.
- Numerals, Western (2026, 40%) or Eastern Arabic (٢٠٢٦, ٤٠٪). Which set to use is an audience decision — Western digits are ordinary in Gulf business decks, Eastern digits suit government work — but neither set reverses.
- Charts and their axes. A bar chart is a measurement with a convention attached, and mirroring it rewrites what the reader thinks the data says.
- Photographs and logos. Slideable moves images when it mirrors a slide but never scales them negatively: a mirrored photograph is a bug, and a mirrored wordmark is a trademark problem.
- Latin brand names, product names and technical terms, which stay in Latin script inside Arabic copy. Transliterating them makes a deck look translated rather than written.
- Code, file paths, URLs, phone numbers, and any timeline whose left-to-right order is part of its meaning rather than an accident of the language it was drawn in.
The timeline case is the one worth arguing about. A process diagram — discovery, then build, then launch — should mirror, because its direction is borrowed from the reading order and nothing else. A chart with a time axis should not, because its direction is borrowed from a convention the reader already knows. If you cannot say which one a graphic is, it was ambiguous in English too.
Why direction is a property of each run of text, not of the box
Setting a text box to right-to-left and moving on causes most of the remaining glitches. Direction resolves per run: a headline reading نمو ٤٠٪ في ٢٠٢٦ holds an Arabic run and a numeric run, and a sentence naming a Latin-script product holds a left-to-right island inside a right-to-left sentence. The bidirectional algorithm gets this right if you let it see the boundaries, and mangles it if you force one direction over the whole string.
So Slideable writes direction as the HTML dir attribute rather than a CSS property. CSS has no direction: auto, and auto is the value that makes a mixed deck work — the first strong character decides the base direction of the box, and every run inside resolves on its own. Chart widgets carry the same auto attribute per shell, so a numeric label and an Arabic caption in one widget each point the right way without being told to.
Base direction is a property of the paragraph. Direction is a property of the run. A tool that conflates the two gets every bilingual headline wrong, and only bilingual headlines wrong, which is why the bug survives review.
Alignment is a third thing again: a box can be right-aligned while its text runs left to right. Slideable flips alignment only where a box actually changed direction, so switching a deck twice never leaves it half-flipped.
Why Arabic breaks a layout that fitted perfectly in English
Arabic runs longer than English — commonly 20 to 30 per cent for the same meaning — so a headline that sat in two lines wraps to three, and a deck that was tight before translation overflows after it. Cut the Arabic rather than shrink it. Type auto-reduced to fit is the visible signature of a translated deck, and readers who cannot name the cause still register the slide as second-hand.
Measuring that overflow is harder than measuring Latin. Arabic cannot be measured glyph by glyph: the shaping engine substitutes initial, medial and final forms, and joined letters set markedly narrower than the isolated ones a naive table would sum. Slideable carries per-letter advances measured between joiners plus a correction for the forms a real word uses. Over 280 cases across eight families, line count is exact 95.4 per cent of the time and mean block-height error is 1.5 per cent. Latin is exact on every case. Every miss is Arabic.
Size and leading need rethinking rather than inheriting. Arabic has no capitals, and much of its distinguishing detail sits in dots and strokes above and below the baseline, so the same nominal point size reads smaller and the same leading reads tighter. An Arabic face wants a slightly larger optical size and noticeably more line height than the Latin face it replaced — and the deck must be re-fitted afterwards, because the same outline does not wrap in IBM Plex Sans Arabic where it wrapped in Inter. Twelve Arabic families ship with the editor, and the modern neutrals, the small-text workhorses and the classical Naskh faces are not interchangeable.
Why mirroring belongs to the layout system, not to each slide
Every argument above can be won once, by hand, on a single slide. None of them stays won. Hand-mirroring is a set of nudged rectangles, and the first person to add a slide or paste a chart from the English original breaks the pattern without noticing, because nothing in the file records that the arrangement was intentional. Which is the case for a layout being a named set of slots rather than a bag of free-floating boxes. When a slide is built by a layout that knows its slots — a headline, a supporting column, an image well, each with the character budget it was drawn for — mirroring becomes a property of the layout system rather than a repair applied to one slide. Every layout in the catalogue flips by the same rule, and the same flip on forty slides gives the same answer forty times.
It also survives an edit, which is the only test that matters. Set the language once at deck level and the direction, typeface, alignment defaults and fit follow from that setting rather than from someone remembering. Six weeks later a colleague adds a slide from the catalogue and it arrives right-to-left, end-aligned, in the Arabic face, re-fitted. A bilingual deck of mixed slides loses all of it: a deck has one reading direction, and a left-to-right slide inside a right-to-left one fights every alignment decision the layout makes. Build the English deck, duplicate it, translate the copy, check the fit.
Common questions
- What has to change when you translate a presentation into Arabic?
- The text direction, the layout geometry and the typography all change, not just the words. Slot positions mirror across the slide so the reading order matches the language, text alignment flips, list markers and page numbers move to the opposite edge, and arrows or process chevrons reverse. Numerals, charts, photographs and Latin-script brand names stay exactly as they are.
- Do numbers and charts get mirrored in a right-to-left slide?
- No. Numbers read left to right inside Arabic text — 2026 stays 2026, and the Eastern Arabic form ٢٠٢٦ is read most-significant digit first in the same way. Charts, their axes and any photograph keep their original orientation, because reversing them changes what the graphic claims rather than where it sits.
- Why does Arabic text overflow a slide layout that worked in English?
- Arabic typically runs 20 to 30 per cent longer than English for the same meaning, and Arabic faces need more line height than Latin ones at the same nominal size, so a headline that fitted in two lines wraps to three. Shorten the Arabic copy rather than shrinking the type, and re-fit the whole deck after the language switch, since a given outline does not wrap in an Arabic face where it wrapped in a Latin one.