Three Assumptions, Three Billion People

The Latin alphabet assumes horizontal reading, left-to-right, with spaces between words.

Three assumptions. Three billion people for whom none of them hold.

The First Assumption: Direction

Arabic reads right-to-left. Hebrew reads right-to-left. Urdu reads right-to-left. Persian reads right-to-left. These are not minority scripts. Arabic alone is the writing system for over 370 million native speakers and the liturgical script for 1.8 billion Muslims. Hebrew serves 9 million native speakers. Urdu serves 230 million.

Right-to-left is not a special case. Left-to-right is not the default. Both are conventions — historical accidents of brush angle, reed position, and scribal ergonomics that solidified into norms over millennia. Neither is more natural than the other. One dominates the technology industry. This dominance is not earned. It is inherited.

Every AI interface built on the assumption of left-to-right reading — every chat window, every text input, every response pane — is built on the first assumption. The assumption is encoded at the CSS level, at the layout engine level, at the interaction pattern level. “direction: ltr” is a single line of code. It is also a cultural statement: this interface was built by people who read left-to-right, for people who read left-to-right.

The engineering cost of bidirectional support is not zero. But the engineering cost of excluding over 600 million native speakers of right-to-left scripts is higher — if you consider them at all. Most interfaces do not.

The Second Assumption: Continuity

Latin characters are discrete. Each letter occupies its own space. The shape of an “a” does not change based on the letter next to it. This discreteness is the architectural foundation of digital typography: fixed glyph tables, predictable kerning pairs, straightforward cursor positioning.

Arabic script does not work this way. Arabic characters are connected — each letter joins to its neighbours in a continuous flow, like cursive writing that never lifts the pen. The shape of a character changes based on its position in the word: initial, medial, final, or isolated. The letter “ba” (ب) has four distinct forms depending on where it appears in the word. This is not an exception. This is the rule. Every letter in the Arabic alphabet has multiple forms.

Devanagari — the script used for Hindi, Sanskrit, Marathi, Nepali, and dozens of other languages serving over 600 million people — has a different structural logic entirely. Characters hang from a horizontal headline called the shirorekha. The headline connects characters within a word, creating a visual continuity that is neither the discreteness of Latin nor the cursive connection of Arabic. It is a third model entirely.

The implication for AI interfaces: text rendering, cursor positioning, text selection, line breaking, and hyphenation all behave differently in each script system. An AI chatbot that renders Arabic text using Latin text-rendering logic produces text that is technically readable but visually wrong — letterforms that fail to connect properly, word boundaries that break at incorrect positions, cursor behaviour that confuses the user.

The user does not see “a rendering bug.” The user sees an interface that does not understand their language. Trust is lost not at the semantic level but at the typographic level — before a single word of the AI’s response has been read.

The Third Assumption: Separation

English separates words with spaces. German separates words with spaces (except when it creates compound words, which are then not separated — “Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz” is one word). Chinese does not use spaces between words. Japanese does not use spaces between words. Thai does not use spaces between words.

In Chinese, Japanese, and Korean (CJK) writing, each character occupies a fixed-width cell. The characters are evenly spaced not by word boundaries but by character boundaries. Word segmentation — knowing where one word ends and another begins — is a task performed by the reader, not by the typography. The text provides no explicit signal.

For AI systems that process CJK text, word segmentation is a non-trivial computational task. The same sequence of Chinese characters can be segmented into different words depending on context. The sentence “下雨天留客天留我不留” can be read as either an invitation to stay or a request to leave, depending on where the word boundaries are placed. The ambiguity is resolved by context, not by typography.

When an AI chatbot responds in Chinese, the response must be rendered in fixed-width character cells with proper CJK spacing. When the same interface also handles Latin text — in a multilingual deployment, for instance — the two spacing systems must coexist. CJK characters at full width. Latin characters at proportional width. Punctuation rules that differ between the two systems (Chinese uses full-width punctuation marks; Latin uses half-width). Line-breaking rules that prohibit certain characters from appearing at the start or end of a line (kinsoku shori in Japanese typography).

This is not a feature request. This is a prerequisite. An interface that fails to handle mixed CJK-Latin typography correctly is an interface that does not work for the majority of East Asian users who read both scripts daily.

The Scale of the Exclusion

The numbers are not ambiguous.

Arabic script: 420 million native speakers. Devanagari: 600+ million users across multiple languages. Chinese characters: 1.4 billion native readers. Japanese (mixed kanji, hiragana, katakana): 125 million native readers. Korean (Hangeul): 80 million native readers. Thai script: 38 million native readers.

Combined, these scripts serve more people than the Latin alphabet. And that count excludes Cyrillic (250 million), Bengali (230 million), Tamil (80 million), Telugu (83 million), and dozens of other scripts that each serve tens of millions of people.

The Latin alphabet is not the world’s writing system. It is one of the world’s writing systems — and it is the one that controls the assumptions of every major AI interface.

What “Multilingual” Actually Means

Every major AI model claims multilingual capability. The claim is true at the language level. GPT-4, Claude, Gemini — all process text in dozens of languages with varying degrees of competence. The language model understands Chinese, Arabic, Hindi, Japanese, Korean, Thai.

The interface does not.

The language model’s multilingual capability is rendered through an interface built on Latin assumptions: left-to-right layout, discrete character rendering, space-separated word display. The model can think in Arabic. The interface cannot display Arabic properly. The model can generate Chinese. The interface cannot render mixed CJK-Latin text correctly.

The gap between the model’s language capability and the interface’s typographic capability is the gap between “multilingual” and “multicultural.” The model speaks the language. The interface speaks Latin typography wearing a language costume.

This is Bluewaves’ argument, reduced to its simplest form: language is not culture. Translation is not adaptation. A model that generates fluent Arabic through an interface that renders Arabic incorrectly has achieved linguistic competence and typographic incompetence simultaneously.

The Engineering Requirements

What would it take to build an AI interface that respects the three billion? The requirements are specific, known, and well-documented in the Unicode Consortium’s specifications, the W3C’s Internationalization guidelines, and decades of typographic engineering research.

Bidirectional text support (Bidi). The Unicode Bidirectional Algorithm (UBA) defines how text with mixed directionality should be rendered. The algorithm handles the common case: an Arabic sentence containing an English product name, or a Hebrew paragraph with a URL. The UBA is a solved problem — implemented in every major browser engine and operating system. The requirement is not to invent bidirectional support. It is to use the existing standard correctly. Most AI interfaces do not.

Contextual shaping. Arabic, Syriac, Mongolian, and other connected scripts require contextual shaping — rendering different glyph variants based on a character’s position in the word. OpenType layout features (specifically, the “init,” “medi,” “fina,” and “isol” features) handle this at the font level. The requirement is to use fonts that include these features and rendering engines that apply them. The requirement is not exotic. It is standard typography. It is frequently ignored.

CJK spacing and line-breaking. The W3C’s “Requirements for Japanese Text Layout” (JLReq) and “Requirements for Chinese Text Layout” (CLReq) define the spacing, punctuation, and line-breaking rules for CJK text. These are not optional guidelines. They are the typographic conventions that CJK readers expect — the equivalent of left-aligned text in Latin typography. Violating them produces text that is readable but wrong, in the way that a book with ragged-left English text is readable but wrong.

Complex script rendering. Devanagari, Bengali, Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Khmer, Tibetan, and Myanmar scripts all require complex shaping — reordering of characters, combination of base characters with vowel marks, and positioning rules that depend on the specific combination of characters. HarfBuzz, the open-source text shaping engine, handles all of these. The requirement is integration, not invention.

Vertical text support. Traditional Chinese, Japanese, and Mongolian can be written vertically (top-to-bottom, right-to-left columns). While horizontal writing has become dominant for digital text in Chinese and Japanese, vertical text remains important for formal contexts, literary publishing, and certain UI elements. Mongolian is written vertically by default. An AI interface that claims CJK support but cannot render vertical text is making a cultural assumption disguised as a technical limitation.

The Accessibility Dimension

The three assumptions do not only affect cultural competence. They affect accessibility.

The World Health Organization estimates that 2.2 billion people globally have some form of visual impairment. Screen readers — the assistive technology that converts text to speech for visually impaired users — depend on correct text directionality, correct character encoding, and correct semantic structure. A screen reader processing Arabic text in a left-to-right context will read the characters in the wrong order. The user hears nonsense.

This is not a niche concern. Arabic-speaking internet users number approximately 237 million. The intersection of Arabic-speaking users and visually impaired users is measured in millions. An AI interface that renders Arabic text in a left-to-right context has excluded these users from the interaction — not through any deliberate decision, but through the inherited assumption that all text flows left-to-right.

The EU Web Accessibility Directive (Directive 2016/2102) requires that public-sector websites and applications meet WCAG 2.1 AA standards. The European Accessibility Act (Directive 2019/882), which applies to private-sector products and services from June 2025, extends similar requirements to commercial products. Both directives require correct handling of bidirectional text, correct semantic markup for screen readers, and correct language identification in the HTML lang attribute.

An AI tool that fails to handle Arabic, Hebrew, or other RTL scripts correctly is not merely culturally insensitive. It is potentially non-compliant with EU accessibility law.

The engineering cost of compliance is the same as the engineering cost of cultural competence: implement the Unicode Bidirectional Algorithm correctly, use semantic HTML with correct lang attributes, and test with screen readers in RTL mode. The cost is incurred once. The exclusion, if the cost is not incurred, is permanent.

The Testing Gap

Here is a practical observation from years of working on cross-cultural design: the assumption that text is Latin persists because the testing is Latin.

QA teams test AI interfaces with Latin text. English queries, English responses, English rendering. The tests pass. The product ships. The Arabic user, the Hindi user, the Chinese user, the Thai user discovers the rendering failures after deployment — in production, with real queries, with real consequences for trust.

The testing gap is not accidental. It is structural. QA teams are staffed by people who read the development language. Test cases are written in the development language. Automated tests check for features described in the development language’s requirements documents. Multilingual testing requires multilingual testers — people who can evaluate whether Arabic text looks correct, whether CJK spacing is proper, whether Devanagari headline connections render correctly. These testers exist. They are rarely hired. They are an afterthought, if they are considered at all.

The fix is architectural: include non-Latin scripts in the core test suite, not as an appendix. Every automated test that checks text rendering should run against Arabic, Chinese, Devanagari, and Thai text in addition to English. Every manual QA pass should include native-script evaluation by a native reader. Every accessibility audit should include RTL and complex-script scenarios.

This is not a premium testing regime. It is a baseline testing regime for a product that claims to serve a global user base. A product that tests only in Latin and claims global support is not a global product. It is a Latin product with a global marketing page.

The Design Failure

The failure is not that these requirements are unknown. They are extensively documented. The W3C’s Internationalization Activity has published comprehensive specifications for every major script system. The Unicode Consortium’s specifications are the canonical reference for text processing worldwide. HarfBuzz, ICU, and other open-source libraries implement the rendering logic.

The failure is that these requirements are treated as special cases rather than foundational requirements. The AI interface is designed for Latin text. Then Arabic support is “added.” Then CJK support is “added.” Each addition is a retrofit — a patch applied to an architecture that was designed for one script system and extended, imperfectly, to accommodate others.

The alternative is to design for the three billion from the beginning. To treat bidirectional layout, contextual shaping, complex script rendering, and CJK spacing as architectural requirements — not features to be added later, but foundations to be laid first.

This is more expensive upfront. It is less expensive in total. Every retrofit is more costly than the original design decision would have been. And every retrofit produces imperfections — rendering glitches, interaction bugs, accessibility failures — that erode trust with the users who were an afterthought.

The Principle

The Latin alphabet is not the default. It is a convention — one of many, adopted by a minority of the world’s readers, elevated to architectural dominance by the accident of which culture industrialised computing first.

Every AI interface built on Latin assumptions excludes more people than it includes. Not through malice. Through inheritance. The assumptions were never examined because they were never visible — to the people who share them.

The three assumptions — direction, continuity, separation — are not universal. They are provincial. And building global technology on provincial assumptions is not engineering. It is carelessness at scale.

Three assumptions. Three billion people. The assumptions are optional. The people are not.

The AI interface built for the three billion looks different from the AI interface built for the Latin alphabet. It begins with bidirectional layout as a default, not an afterthought. It treats contextual shaping as a foundational capability, not an advanced feature. It handles CJK spacing as a core rendering requirement, not a localisation add-on. It tests with Arabic, Devanagari, Chinese, and Thai text as part of the standard test suite, not as a special case.

This interface does not exist. The specifications for building it exist. The libraries for implementing it exist. The demand for it — three billion people — exists.

What does not exist is the decision to build it. That decision is not technical. It is attentional. It is the decision to notice the three assumptions and to treat them as the provincial conventions they are, rather than the universal truths they are not.

Three assumptions. Three billion people. The decision is one.