Schema LawSign in with Google

OCR Foreign Language Documents: Scripts and Accents

By Schema LawPublished Updated

OCR can read foreign language documents when the software supports that language and its script, and many tools cover the widely used ones. Results differ by tool and by page, so test yours. Check names and accented letters, the order of dates and any passage that mixes languages, and remember that recognized text is not a translation.

Can OCR read a document in another language?

Often, yes. Printed text in a widely used language converts well in many OCR tools, provided the tool was built to handle that language. Support thins out for less common languages, for scripts other than the Latin alphabet, and for anything handwritten. The only reliable answer for your document is a test page.

It helps to sort the document into one of three groups, because each fails differently.

GroupExamplesWhat usually goes wrong
Latin alphabet with extra marksSpanish, French, German, Portuguese, Polish, VietnameseAccents dropped or wrong, which changes names and words
Other alphabetsRussian, Ukrainian, Greek, ArmenianLetters swapped for Latin lookalikes; whole lines read as nonsense if the script is not supported
Other writing systemsArabic, Hebrew, Chinese, Japanese, Korean, HindiDirection, word boundaries, and thousands of similar characters

Schema Law makes no stated claim about which languages or scripts it reads, so do not assume. The free plan takes one document a day of up to three pages. Upload a representative page, read the parsed result against the original, and decide from that. The home page answers a related question under common questions: nothing marks a passage as uncertain, so the comparison is yours to make.

Checks you can make without reading the language

Bad output in a language you do not read looks just like good output. A paralegal who has no Portuguese cannot tell a clean paragraph from a mangled one by glancing at it. These checks need no fluency:

  1. Count blocks. The same number of paragraphs, headings and table rows should appear in the text as on the page.
  2. Compare every number. Digits are the same in most European languages. Amounts, dates and reference numbers can be checked character by character.
  3. Compare proper names letter by letter. Treat each name as a string of shapes and match it to the image, marks included.
  4. Look for placeholder symbols. Empty squares, question marks in diamonds, or runs of "?" mean characters were lost.
  5. Scan for English words that do not belong. A Spanish page that suddenly contains "the" or "and" has been pulled toward English.

Then ask someone who reads the language to look at one page of output beside its image. Ten minutes of their time tells you more than any other step.

Why does the recognition language setting matter?

The recognition language setting matters because it tells the software which characters can appear and which words are likely. Read a Spanish page as English and the engine has no "ñ" to choose, so it picks "n". It may also bend unfamiliar words toward English ones.

Some tools hide this choice and detect the language themselves. Others expose it. The open-source Tesseract engine is a clear example of how the setting works. Its command-line documentation says that when no language is given, "English language is assumed by default". It lets you name several languages together for one page. It also warns that "the time taken for OCR as well as the output can be different based on the order of languages". So the same page yields different text depending on which language was listed first.

That is one engine, and yours may behave differently. The questions carry over to any tool:

  • Is there a language setting, and what is it set to? Check it on the scanner and in the PDF program before a foreign page goes through.
  • Is the language chosen per document, per page or per line? A tool that picks one language for a 60-page file will handle an English contract with a Spanish exhibit badly in one half.
  • What happens to a language it does not support? Some tools return nothing. Others return confident text in the wrong alphabet, which is worse.

If your tool has a setting, sort a mixed batch by language before you convert it, and set the language for each pile. If it has none, your test pages are the only way to learn how it decides.

Accents, diacritics and characters an English keyboard lacks

Accents and other diacritics are small marks, and small marks are what OCR loses first. A dropped accent can turn one word into another and one surname into a different surname. On any page in a Latin-alphabet language other than English, check the marks on names before anything else.

What goes missing, and what it becomes

On the pageCommon misreadingsWhy it matters
ñn"año" (year) becomes a different Spanish word; Muñoz becomes Munoz
á, é, í, ó, úa, e, i, o, u, or the letter plus an apostropheChanges verb tense in Spanish; changes names
ü, ö, äu, o, a, or "ii" for üMüller and Muller are different spellings
ßB, or "ss" if the tool normalizesStraße read as "StraBe" fails every search
çcCommon in French, Portuguese and Turkish names
łl or tPolish surnames change
ø, åo or 0, aNordic names and place names
ı and İ (dotless i, dotted capital I)i and ITwo distinct Turkish letters collapse into one
¿ and ¡Dropped, or read as "6", "i" or "l"Stray characters at the start of sentences
« » and „ “"<<", ">>", commas or double commasQuoted passages lose their boundaries
º and ªo, a, or a degree signOrdinals and abbreviations in Spanish and Portuguese

The reverse error happens too. A speck of toner above a vowel becomes an accent that was never there, and the dot of an "i" beside a smudge becomes "í".

Text can show the correct accented letter and still not be found. Unicode allows some accented letters to be stored in more than one way: as a single character, or as a base letter followed by a separate combining mark. The Unicode Consortium's report on normalization forms calls such sequences canonically equivalent and describes how software can bring them to one form. Not every search box does that. If a search for "Muñoz" misses a place where you can see the name, copy the name from the converted text and search for that copy. The section on text encoding and special characters in legal documents explains what to do when accented letters turn into pairs of odd symbols after a file is opened in another program.

Searching a file with foreign names

  • Search for each name with and without its marks: "Muñoz" and "Munoz".
  • Search for the likely misreadings from the table: "StraBe", "Miiller".
  • Search for a fragment that contains no special character, such as "Mu" plus the first name.
  • When you correct a name in a working copy, correct it to what the image shows and not to the spelling you expect.

Non-Latin scripts and right-to-left text

Non-Latin scripts raise problems that accents do not: different alphabets whose letters resemble Latin ones, writing systems with thousands of characters and no spaces between words, and text that runs from right to left. Whether a tool reads a given script at all is the first thing to establish.

Alphabets with Latin lookalikes

Cyrillic and Greek share shapes with the Latin alphabet. The Cyrillic letters А, В, Е, К, М, Н, О, Р, С, Т and Х look like Latin capitals, yet each is a separate character with its own code, and several stand for different sounds. Recognition may return a Russian surname spelled partly in Latin characters. It looks perfect on screen. A search typed in Cyrillic will not find it, and neither will a search typed in Latin letters. If a visible name cannot be found, mixed alphabets are the likely cause.

Chinese, Japanese and Korean

These scripts use very large character sets, and many characters differ by a single short stroke. Words are not separated by spaces, text may run in vertical columns read right to left, and Chinese exists in traditional and simplified forms. Dense characters also need more pixels than Latin letters do to stay distinct, so a scan that is adequate for English may be too coarse here. The post on OCR for a low resolution scan shows how to measure what a file really holds.

Arabic, Hebrew and other right-to-left scripts

The Unicode Consortium's description of the bidirectional algorithm explains the difficulty. Arabic and Hebrew are displayed from right to left, the standard stores text in a logical order in memory, and because digits inside such text run left to right, a line with a number in it is a mixture of both directions. Software has to store the characters in one order and display them in another.

For converted text, that produces three things to check:

  • Order after pasting. Text that displays correctly in one program may appear reversed, word by word or letter by letter, when pasted into another. Paste a line into a blank document and have a reader of the language confirm it.
  • Numbers inside sentences. Make sure a date or amount in a right-to-left line holds the same digits in the same order as the image, and note whether the page uses Western digits or Arabic-Indic ones.
  • Dots and joined letters. Arabic letters join and change shape with their position in a word, and several letters differ only in the number of dots above or below. Speckle on the scan can turn one letter into another.

Scripts shared by several languages

One script may serve many languages. Tesseract's command-line documentation, for instance, shows a script-level model for Devanagari that it says supports all languages in that script along with English. Other tools organize support differently. Ask a vendor about the script and the language both, since "supports Hindi" does not tell you about Marathi or Nepali.

Contracts and records that mix two languages on one page

Pages that mix two languages are harder than pages in either language alone, because software must decide where one stops and the other starts. Expect the stronger language to convert well and the other to suffer. Check that both versions were captured in full and that neither was woven into the other.

How the two languages are arranged

LayoutWhere you see itTypical fault
Two columns, one language eachBilingual contracts and powers of attorneyLines read straight across, interleaving the languages
Alternating paragraphsNotices, consent forms, corporate resolutionsOne language's paragraphs read with the other's rules, losing accents
Labels in two languagesCivil registry extracts, customs and bank forms"Nombre / Name" pairs break apart from their values
English text with foreign names and addressesCorrespondence, invoices, pleadingsNames stripped of their marks
Foreign text with a stamp or seal in another languageNotarized and legalized documentsThe stamp is skipped or scrambles the lines under it

Columns are the first thing to verify. The post on whether OCR can handle two-column documents explains how to tell if the columns were read one after the other. For a bilingual contract, split the converted text into two documents, one per language, and line them up by clause number. A clause present in one and absent from the other is either a real difference between the versions or a block the software skipped, and the image tells you which.

Many bilingual contracts say which language version governs. Find and read that clause on the image. What it means for your matter is a legal question outside the scope of a conversion guide.

A summons or a third-party complaint in the other language needs the same split. You check the names in the caption and any line about service of process or intervention, and you do not assume personal jurisdiction follows from a date you converted. Counsel reads the governing clause on the image.

Dates and figures written the local way

A date made only of digits depends on the country. The World Wide Web Consortium's note on date formats observes that month-day-year order is used in the United States, that most of Europe writes day-month-year, and that Japan puts the year first. OCR reproduces the digits. It cannot tell you which convention the author followed.

Take a fictional supply agreement between Brightwater Imports LLC and Distribuidora Solano S.A., set in two columns. The English column gives the delivery date as "03/04/2021". The Spanish column says "3 de abril de 2021". The Spanish text settles it: the third of April, not the fourth of March. Had someone built a chronology from the English column alone, the entry would be a month out.

Three rules follow:

  1. Record the date as written, then your reading of it, then why. For example: "03/04/2021 (3 April 2021; Spanish column spells out the month)".
  2. Look for a written-out month elsewhere. The other language column, the signature block, a notary's certificate or a stamp often has one.
  3. Never tidy dates in bulk. Reformatting a column of dates in a spreadsheet applies one convention to all of them.

Amounts differ as well. Many countries use a comma for the decimal point and a period or space between thousands, so "1.234,56" is a little over twelve hundred. The post on why OCR gets numbers wrong deals with decimal points and separators.

Is OCR output a translation of the foreign document?

No. OCR output is the same document in the same language, turned from a picture into characters. A Spanish birth record comes out as Spanish text. Translation is a separate job done by a translator, and where a translation will be filed, the court or agency sets its own requirements.

Those requirements vary by forum. As one example, immigration filings call for a full English translation with a translator's certification, and the post on immigration records covers foreign-language records and certified translations. Check the rules of the court or agency you are filing with.

What a translator needs from you

  • The page images, complete. Every page, both sides, with stamps, seals, margin notes and handwritten additions visible. A translator works from the document, and converted text is at most a convenience.
  • The best copy you can get. A translator cannot translate what cannot be read, any more than software can.
  • Stable page numbers. Number the pages so the translation can refer back to them.
  • Known English spellings. If a party's name already has an established English spelling in the case, say so.
  • A note of what you could not read. Mark the passages where the scan is poor, so the translator knows to raise them.

Machine translation of converted text

Running converted text through a translation tool stacks one machine reading on another. A misread letter makes a different foreign word, and the translation tool turns that word into fluent, wrong English with no trace of the original error. That can be acceptable for triage, such as deciding which of 200 documents to send to a translator first. Relying on it for what a document says is another matter. Pasting a client's document into a free translation website is also an upload to a third party, and the post on whether it is safe to upload client documents to an OCR tool sets out the questions to ask first.

Older foreign records

Records typed decades ago bring a further layer of trouble. A typewriter built for one language often lacked the marks of another, so accents were added by pen, built from two keystrokes, or left out. The post on OCR for typewritten documents covers what typed pages do to recognition.

When the work is done, keep three things together in the file: the scan of the original, the translator's signed translation, and a note of which pages each English page corresponds to. Converting both to searchable text lets you find a name in either language and get from one version to the other.

All posts in Difficult scans