Why We Return an Error Instead of a Translation

On 2026-07-25 we ran a sample set of Universal Declaration of Human Rights documents through Lingivio, two dozen languages and more, most of them scans. All but one came back as translated files. The exception was a scanned Urdu document set in Nastaliq, which came back as a named error. This page is about why that is the outcome we want.

The file is analysed before you approve anything. Its pages have no text layer, so each one is routed to OCR. The recognizer runs, and on this script it returns noise below the confidence we require, so no page yields a readable line. A document routed entirely through OCR that produces no readable text, and has no digital text either, is by definition unreadable to us.

At that point the job fails with the error class pdf.no_text_layer. It is marked not retryable, because trying again would run the same recognizer over the same pixels. Every credit reserved for the job is released back to your balance in full; a failed job is never charged.

What you see in the app is the failed job with the message "This PDF has no text to translate." and a ledger line reading "Reserve released". What you do not see is a file to download, because there is nothing we could put in one that we would stand behind.

The engine has one rule for uncertain output, applied at two scales. At the scale of a sentence, every translated segment is checked before it is written back: unchanged numbers, currency and percent marks, codes, links and placeholders. A sentence that fails those checks is shipped in the original language inside the otherwise translated file, visibly, rather than as a guess. At the scale of a file, if nothing in it can be read or translated safely, the job fails and the credits come back.

A scan like this one is the second case. OCR noise fed to a language model does not produce an error; it produces fluent text that has nothing to do with the page. That is the worst outcome this product can have, because it looks finished. A file that looks translated but is not costs you more than a file that says it failed.

We measured that risk directly. In an evaluation dated 2026-08-04, a spike and not the production path, our OCR recovered 0.0 percent of the text on the Urdu document, which is exactly why it fails. One of the vision models we tried recovered a large share of it, and also produced text amounting to 23.2 percent of the page's length that aligned to nothing printed on it. Reading a page and inventing a page are different skills, and a system that cannot tell them apart should not be the one shipping your document.

Our scanned-page path uses open-source OCR: RapidOCR for Latin and several other scripts, and Tesseract for the rest. Tesseract's Arabic-script models are trained on Naskh typefaces, the upright style most Arabic and Persian printing uses. Nastaliq is the cursive, diagonal, calligraphic style that Urdu and Kashmiri printing favours, and those models cannot read it: on two independent documents the recognizer's mean confidence stayed around 0.27, flat across every render scale we tried. A Naskh scan of the same declaration in Persian passed the same confidence gate cleanly.

It is not a resolution problem, and it is not a bug we are sitting on. No Nastaliq-capable recognizer is available to us as a permissively licensed offline dependency, and until one is, the honest result is the error.

Clean scans in Latin, Cyrillic and Greek script are the well-trodden path. On the same 2026-07-25 sample set, scanned Hebrew, Bengali and Persian documents translated every segment the OCR extracted; scanned Hindi, Nepali, Gujarati, Thai and Tamil documents translated all but a few, with the rest left in the source language on the page rather than guessed at.

Those are observations about extracted segments, not a measure of accuracy. They come from a single dated run with a persistent cache, so a first cold pass can do worse; lines the OCR never extracted are not in the count; and the rendered page can still be untidy where a dense scan was fragmented. The caveats travel with the observations because the observations mean little without them.

Reading a script and writing one are separate questions. Whatever the source, PDF and image output can only be drawn in the scripts our bundled fonts render, which today means Latin, Cyrillic and Greek targets. Word, Excel, PowerPoint and the text formats hand Unicode to your own viewer and offer every target language we support. The language page lists both sets, generated from the same module the app validates against.

Two things, and neither is small. The first is a recognizer that reads this script. The evaluation above found vision models that read the Urdu page at high recall, but when the same models were asked for text positions on a Hindi test page, across every model and two runs not one recognized line overlapped its real position closely enough to use. Our overlay works by clearing a box and redrawing inside it, so a transcript with no trustworthy boxes is not a degraded feature, it is a tool that erases the wrong text.

The second is a way to pay for it. A vision-model call per page is a real cost on top of a page that already bills at the scanned rate, so if it ships it will be an explicit, priced option shown in the cost estimate before you approve the job, not a silent default. Until both exist, the error stays, and Urdu is deliberately absent from the language pairs we advertise.

A PDF with a real text layer whose fonts map to Unicode is read from that layer and never goes through OCR, so the typeface is irrelevant; the problem is specific to scans and photographs. Word, Excel and PowerPoint files likewise carry their own text. If all you have is a scan, the honest answer is that we cannot read it yet, and we would rather say so than charge you for noise.