Scanning Multilingual Documents: What to Ask About OCR

Before commissioning OCR for documents in several languages, identify the languages and scripts, the required output, and who can check the original text. A general statement that software is multilingual does not establish how it will handle your particular pages.

For a Sydney organisation preparing a scanning enquiry, the useful question is whether the proposed workflow can produce the result people need: finding an original-language name, copying a passage correctly, or supplying a separately reviewed translation. Describe those tasks before agreeing the scope.

Map the languages and writing on the page

List the languages you know are present, and mark anything uncertain. Include the script or writing system where known, especially if a language may appear in different scripts. Keep uncertainty visible so someone qualified can resolve it; an English folder label does not establish the language of every document inside.

Record where the mix occurs: separate documents, different pages of one file, or several languages on the same page. Include small but important passages such as stamps, marginal notes, names and addresses. Identify handwriting separately from printed text, and distinguish original writing from later annotations.

Choose examples that show these differences. If only an English cover sheet is examined, the resulting estimate says little about the pages behind it. At the enquiry stage, a description of the collection can establish what needs assessment. Agree the handling arrangements before sharing records or representative pages.

Check support for the proposed OCR workflow

Ask which system, model and version would be used, and which features support the languages in your collection. Microsoft's Document Intelligence language documentation distinguishes printed-text and handwriting support. It also explains that a language detectable by the system may not be supported for text extraction. Detecting a language is therefore not evidence that its words were correctly recognised.

Configuration also varies. The OCRmyPDF cookbook describes specifying languages and having the corresponding language packs installed. Its documented workflow assumes English unless another language is selected. By comparison, Google Cloud Vision's OCR guidance says omitting language hints usually gives the best results through automatic detection, and an incorrect hint can hinder recognition.

These are examples of different approaches. They are not a recommendation to use a particular product, and they do not describe how any supplier, including Pexatech, would configure OCR for your documents. Ask the supplier to explain the proposed configuration and demonstrate it on the relevant page types. A list of supported languages cannot replace that document-specific check, particularly where handwriting or mixed passages are involved.

Separate recognition from translation

Specify the deliverable in terms of what a person will receive and use. These three tasks can appear in the same workflow, but they answer different questions.

For example, Microsoft's Document Translation overview describes a batch PDF workflow that uses OCR to extract text and then translates it. That combined capability does not make translation an automatic part of every OCR job.

If translation is needed, specify whether it is a separate file or another agreed output, how it relates to the source document, and who checks its meaning. Keep the original-language result identifiable. Do not silently substitute a translated or transliterated name for the original spelling. If information must also become spreadsheet fields, use the searchable PDF and data extraction guide to define that additional output.

Test the words people actually need to find

Prepare a small set of search and copy tasks using words that matter to the collection. Examples might include a person's original name, a business name containing accents, a reference beside non-Latin text, or a phrase spanning a change of language. Have someone who can read the source establish the expected result.

Check the finished output in the application where it will be used. Search for the agreed words, copy selected passages, and inspect any exported text in its destination. A PDF that looks correct on screen should still be tested for these tasks. Compare the underlying text with the page image, including characters, word order and passages that might have been omitted.

Where an English search alias is required for an original-language name, define it as a separate field or approved naming convention. Record who supplies it and retain the connection to the original. This avoids treating an OCR error or an unapproved spelling change as a normalised record.

Agree how failed tasks will be reported and resolved. The broader document scanning quality checklist covers completeness and acceptance; add language-specific examples to that plan instead of relying only on a general accuracy statement.

Assign language review and accessibility separately

Name the review responsibility before accepting the work. Confirm who can read each relevant language, whether they will review every passage or an agreed sample, and how unreadable text will be recorded. A supplier's software language list does not establish the availability of a suitable human reviewer.

If translation is commissioned, distinguish checking the recognised source text from checking the translated meaning. Agree which unresolved items return to the document owner and who approves corrections. Avoid guessing at names or missing words merely to make the output look complete.

PDF language settings are another separate consideration. Adobe's PDF accessibility overview explains that specifying document language helps some screen readers select the appropriate language. This setting is distinct from identifying characters during OCR. Where accessible reading is required, include it in the PDF accessibility brief alongside the other necessary checks.

Put the language requirements in the enquiry

Consider a fictional Sydney importer with English and Thai supplier correspondence, including handwritten additions. Its brief could ask for searchable original-language PDFs, preserved document boundaries, and a list of passages needing review. If staff also need an English translation, that should be a separate requirement with its own reviewer. This example describes a buyer's needs; it does not represent a completed Pexatech project or confirmed language capability.

An initial enquiry can state:

• The known languages, scripts and uncertain passages.
• Whether the mix occurs between files, between pages or within pages.
• The presence of handwriting, stamps and annotations.
• The required search, copy, export and translation tasks.
• Who can review original text and any translation, or whether reviewers still need to be arranged.
• The handling requirements, target date and questions the proposal must resolve.

Use that brief when discussing document OCR requirements. Confirm capability, review arrangements, processing location, equipment, staffing and timing in the proposal before committing. The purpose of the enquiry is to establish a workable scope for the actual collection.