Open any theme listing and you will find “translation ready” and “RTL supported” in the feature list. Both are usually true. Both usually mean far less than a buyer assumes.
“Translation ready” typically means the interface strings are wrapped so they can be swapped. “RTL supported” typically means a stylesheet flips the layout horizontally. Together they solve perhaps a tenth of the problem — and the remaining nine tenths are why so many sites in Bangla, Arabic, Hindi, Thai, or Urdu look subtly broken even when everything technically works.
We build in this space, so this is the list we wish theme buyers had before they bought.
Part 1: Typography is where it falls apart first
Latin script is unusually simple: letters sit in a row, each one shaped the same regardless of neighbours, with modest vertical extent. Most theme typography is tuned to that, and the tuning does not transfer.
Complex script rendering
Bangla, Devanagari, and related scripts do not simply place glyphs side by side. Consonants combine into conjuncts, vowel signs attach above, below, before, or wrap around their consonant, and some marks reorder visually relative to how they are typed.
When this works, it is invisible. When it fails — a font without proper shaping tables, or a rendering path that bypasses them — you get vowel signs detached from their consonants and conjuncts broken into separate letters. To a reader it looks like nonsense, and worse, it often looks nearly right, so the site owner never notices while every native reader does immediately.
The lesson: you cannot evaluate a script you do not read. Have someone who reads it look at real text on real devices.
Line height is not a universal number
Most themes set a body line height tuned for Latin. Bangla, Devanagari, and Thai need considerably more vertical room, because marks extend above and below the main body of the text far more than Latin ascenders and descenders do. Arabic needs extra room for dots and diacritics.
Set a Latin-tuned line height on Bangla text and lines crowd into each other, with marks from one line nearly touching the next. It is legible but tiring, and it silently signals that nobody involved reads the language.
The same applies to font size. At an identical pixel size, Bangla and Arabic often read smaller and denser than Latin. A theme that offers one global font size setting, applied across every language, is going to be wrong for at least one of them.
The fallback chain problem
A theme declares a font stack — a chosen typeface, then a generic fallback. The chosen typeface almost certainly has no Bangla or Arabic coverage, so those characters fall through to whatever the operating system provides.
That means your carefully designed site renders in a different, unchosen font on every platform, and looks materially different on an Android phone than on an iPhone. Fix it by declaring explicit script-appropriate fonts in the stack rather than relying on the system.
Weights that do not exist
A design might use five Latin weights. Many high-quality non-Latin typefaces ship with two or three. When the design calls for a weight the font lacks, browsers synthesise it — producing artificially thickened letterforms that look crude, and which can distort the fine detail these scripts depend on.
Decide your typographic hierarchy around the weights that actually exist in every script you support.
Two styling habits to unlearn
Italics. Bangla and Arabic have no italic convention. Applying italic styling produces a mechanically slanted version of the text, which reads as broken rather than emphatic. Use weight, colour, or size for emphasis instead.
Letter spacing. Adding letter spacing to Arabic is not a stylistic choice — it is destructive. Arabic letters join into connected words, and forcing space between them breaks the connections apart. A theme that applies a global letter-spacing rule to headings will visually shatter every Arabic heading on the site.
Part 2: RTL is not a mirror
Flipping a layout horizontally is the easy part, and the part theme authors usually do. The remainder is judgment.
Use logical properties. Writing styles in terms of start and end rather than left and right means the layout adapts by direction rather than needing a separate mirrored stylesheet to maintain. This is the difference between RTL as a first-class mode and RTL as a patch.
Not everything mirrors. Directional icons — back arrows, next arrows, indentation controls — should flip. Logos should not. Clock faces should not. Icons whose meaning is not directional generally stay as they are, and media playback controls conventionally do not flip either. A blanket transform applied to every icon produces a set of small errors that collectively look careless.
Mixed-direction text is the hard problem. Real RTL content contains LTR fragments constantly: a price, a phone number, an email address, a URL, a brand name, a model number. Without correct bidirectional handling, these fragments end up in the wrong order or with punctuation displaced — a phone number where the country code appears at the wrong end, a price with the currency symbol adrift.
This is the single most common visible RTL bug in themes that claim RTL support, and it is one you can spot yourself: put a phone number, a price, and an English brand name into a paragraph of Arabic and see what happens.
Check the incidentals. Drop shadows, gradients, slide-in animations, progress bars, and carousel direction all have a directional component. Any one of them left unflipped reads as subtly wrong.
Part 3: Numbers, dates, and formats
This is where most themes have simply never considered the question.
Numeral systems. Bangla has its own digits, as do Arabic-script languages. Which set a site should display depends on audience and context — a Bangladeshi retail site and a Bangladeshi technical site may reasonably differ. The point is that it should be a decision the theme lets you make, not a Latin-digit assumption baked into the templates.
Digit grouping. The South Asian convention groups differently from the Western one — the same number is punctuated in a distinct pattern, and lakh and crore are the units people actually think in. A price formatter that only knows thousands-and-millions grouping will produce numbers that are technically correct and awkward to read for a very large audience.
Currency placement. Symbol before or after, spaced or not, varies by locale. Themes that hard-code the position get it wrong for half the world.
Dates and calendars. Format order differs, month names need translating, and some audiences use additional calendar systems alongside the Gregorian one. A theme with a hard-coded date format is a small, permanent irritation.
Names, addresses, phone numbers. Forced first-name/last-name fields fail for the many people who have a single name or a different naming structure. Address forms with a fixed field order and a required state field fail outside the countries they were designed for. Phone inputs that assume a fixed digit count reject valid numbers.
Part 4: Strings and content
Text expands and contracts. Translated text is frequently longer than the English original. Buttons sized precisely to “Add to cart” break when the translation needs half again as much room. Design for flexible width, and test with the longest translation you actually ship.
Hard-coded strings hide in templates. “Read more,” “Related posts,” “Your cart is empty,” 404 text, form validation messages, and screen-reader-only labels. The main content translates while these stay in English, producing a bilingual interface nobody chose. The 404 page and form error messages are the most commonly missed.
Plural rules are not universal. Several languages have more plural categories than English’s two, and Arabic has notably many. A template that builds plurals by appending a suffix, or by choosing between exactly two forms, will produce wrong output.
Search has to work in the script. Test it: does site search return results for a query typed in Bangla or Arabic? Does it handle variant spellings and optional diacritics? Search that only works properly in Latin is a common and quietly costly failure on multilingual sites.
Decide your URL policy deliberately. Non-Latin slugs versus transliterated ones is a real tradeoff involving readability, shareability, and how URLs appear when encoded. Either is defensible; having the theme decide silently is not.
Part 5: The performance dimension
This one compounds, and it is where the audience is most vulnerable.
Fonts covering Bangla, Arabic, or Devanagari are substantially larger than Latin fonts, because they contain far more glyphs and shaping data. A site serving two scripts can easily carry several times the font payload of a Latin-only site.
And the audiences most likely to need those fonts are, on average, on more constrained networks and more modest devices. So the heaviest font loads land on the least forgiving connections.
Practical responses: subset fonts to the characters you actually need, use unicode ranges so a browser downloads only the script it requires for the page, cut the number of weights to the minimum the design truly uses, self-host rather than chaining to third-party requests, and make sure your fallback behaviour does not produce a visible reflow when the real font arrives.
What to check before buying
Ten minutes, on the theme’s own demo:
- Switch the demo to an RTL language if one is offered. Look at the icons, not just the layout.
- Paste a paragraph of your target script into the demo and read it — or have someone who reads it do so.
- Put a phone number, a price, and an English brand name inside that paragraph and check the ordering.
- Look for a global letter-spacing rule on headings.
- Check whether headings are italicised anywhere.
- Ask what the font stack falls back to for your script.
- Ask whether number formatting, currency position, and date format are configurable.
- Search the demo in your script.
- Check the 404 page and a form error message for untranslated strings.
- Ask whether the CSS uses logical properties or a mirrored stylesheet.
A studio that has genuinely done this work will have specific answers. A studio that added a flipped stylesheet and called it RTL support will talk about the feature list.
Why this matters commercially
There are enormous audiences here — hundreds of millions of Bangla speakers, a vast Arabic-speaking market, some of the fastest-growing internet populations in the world — and the supply of themes built properly for them is thin.
Most of what exists is a Latin-first theme with a flipped stylesheet and a translation file bolted on. That gap is a genuine opportunity, whether you are choosing a theme for your own business or deciding what to build next.
Getting this right is not exotic work. It is mostly the ordinary discipline of not assuming that the way your own language behaves is the way language behaves.
At eThemeStudio, we build and test in these scripts rather than treating them as an export option — logical properties throughout, script-appropriate typography and line heights, configurable number and date formats, and subsetted fonts so the payload stays reasonable on real connections. If you are launching in Bangla, Arabic, or any script your current theme was not designed for, send us the URL and we will tell you what is breaking.
Comments (0)