Why Reading Direction Alone Doesn't Predict AI Difficulty With a Script

Reading direction is the most visible difference between writing systems, so it gets treated as a proxy for how hard a language is for a model. It is not one. Direction is a rendering property that the model never observes, and the variable that actually predicts quality — corpus volume — is uncorrelated with it.

The claim

The position argued here is narrow and falsifiable: a script’s writing direction has no bearing on how well a language model handles the language written in it, and the appearance of a correlation comes from a confound — that several right-to-left languages happen also to be lower-resource. If direction were the causal variable, the right-to-left languages would cluster at one end of the quality distribution. They do not; they are spread across it, and so are the left-to-right ones.

Four counterexamples, two each way

Two right-to-left languages, at opposite ends:

• Hebrew is right-to-left and well supported. Modern Hebrew has around nine million speakers — a small population by world standards. But it is the working language of a country with high internet penetration, a substantial software industry, a large Wikipedia, a full national press online, and decades of digitised literature and legal material. Models handle it competently. The direction did not stop that.
• Yiddish is right-to-left and poorly supported. Same script as Hebrew, exactly the same direction, exactly the same bidi handling in every renderer. Far less digital text. Model output is markedly weaker. Two languages, one script, one direction, opposite outcomes — the direction is held constant and the quality is not, which is what makes this pair the strongest evidence available.

And two left-to-right languages, likewise at opposite ends:

• Khmer is left-to-right and poorly supported. Khmer has roughly seventeen million speakers, nearly twice Hebrew’s, and reads in the same direction as English. It has comparatively little digital text, no word spaces, a complex stacked-consonant orthography, and thin tokenizer coverage. Model quality is substantially below Hebrew’s. The direction did not help.
• German is left-to-right and very well supported — the trivial case, included because it completes the two-by-two. Direction is constant between German and Khmer; corpus volume is not; quality tracks corpus volume.

Four cells of a two-by-two table, and the outcome varies with the corpus axis in both rows and with the direction axis in neither column. That is about as clean as an argument from public evidence gets without running an experiment, and no experiment was run for this page.

Why direction cannot reach the model

The counterexamples show the correlation is absent. The mechanism explains why it was never plausible.

Unicode stores text in logical order: the first character read is the first character stored, regardless of which side of the page it is drawn on. The Hebrew word for “book” is stored with its first letter first, exactly as an English word is. Direction is applied at display time by the Unicode Bidirectional Algorithm, described in Unicode Standard Annex #9, which reorders runs for rendering and touches nothing about storage.

A model receives bytes. Those bytes are in logical order. It never sees a line of text laid out, never sees a page, and has no representation in which “right” and “left” exist. Asking whether right-to-left text is harder for a model is like asking whether text in a serif font is harder: the property is real, and it is a property of a rendering the model is not given.

The same reasoning covers vertical scripts, which is why vertical reading order is likewise a presentation concern with no modelling consequence.

What direction does cost, precisely

Not nothing — but the cost lands somewhere specific, and naming it is the useful part of this argument. Right-to-left costs appear wherever logical order meets visual order:

• Layout and UI. Mirroring, alignment, icon direction, and every hard-coded “left” in a stylesheet.
• Mixed-direction text. An English product name or a URL inside an Arabic sentence triggers the bidi algorithm, and this is where the notorious bugs live — mixed Arabic and English runs and URLs breaking RTL layout.
• Document generation. PDF writers, spreadsheet exporters and chart libraries that implement bidi incompletely or not at all.
• Extraction. Pulling text out of a rendered artefact requires recovering logical order from visual order, and getting it wrong yields reversed runs.

Every item on that list is your code or a library’s. None is the model. This is why an RTL product can feel broken while the model output is perfect, and why the fix is a rendering fix. Treating it as a model problem sends you looking for a better model, which will not help.

The predictor that does work

If you want a single rough estimate of how a model will handle a language before you test it, the useful proxies are all volume proxies: the size of the language’s Wikipedia in real articles, its presence in the corpora and benchmark lists discussed on languages missing from training corpora, and the tokens-per-word figure your tokenizer produces for real text in it. That last one is the sharpest single number available, because it measures how much of the language the tokenizer bothered to learn, which is a direct read on corpus share.

None of those is direction. The practical consequence of insisting on the distinction is that it sends your effort to the right place: your RTL budget goes to rendering, layout and extraction, and your low-resource budget goes to data, evaluation and model choice. Conflating them means an RTL language gets a model swap it did not need, while a low-resource language gets a stylesheet audit that cannot help it.