Also in: සිංහල · தமிழ்

How to Build a Multilingual Engine with Generative AI

One source. Three languages. Several models. And a human who signs.

Idasara Digital, September 2026. A practical architecture for publishing the same document correctly in Sinhala, Tamil and English with generative AI: a single authoritative source, a pool of language models routed by benchmark rather than reputation, a second model that checks the first, and a human who approves before anything is published. Written for Sri Lanka's three languages, built to work for any organisation that serves people in more than one.

In short: Generative AI has made translation cheap. It has not made it trustworthy. If you serve people in more than one language, the answer is not "paste it into ChatGPT," and it is not "wait for a perfect model." The answer is an engine: one authoritative source, a pool of models chosen by measured results for each language and domain, a second model that reviews the first, a terminology bank and translation memory that keep the words consistent, an audit log that records who and what did every step, and a human who reads and signs. Translate once, validate once, publish everywhere. Use multiple models. Validate meaning. Keep humans in control.

One source, three languages: an authoritative document becomes Sinhala, Tamil and English editions, then flows to web, mobile, PDF, forms and chatbots through draft, review, translate, validate, approve and publish

Let me start in a training hall.

Over the past year I have sat with more than ten thousand public officers across Sri Lanka, from Jaffna to Matara, talking about generative AI. In almost every room, sooner or later, someone raises a hand and asks the same thing. "Sir, when we ask ChatGPT something in Sinhala, we sometimes get nonsense. Ask in English, and the answer is superb. Why?"

It is a fair question, and it is not only a government question. A bank has the same problem with its customer letters. A hospital has it with its consent forms. A school has it with the note that goes home to parents. Any organisation that must say one thing, correctly, to people who read in different languages has this problem. Sri Lanka simply makes it impossible to ignore, because our Constitution names Sinhala and Tamil as official languages and English as the link language. Three languages is not a preference here. It is the law, and more importantly, it is fairness.

So the question I want to answer in this piece is a practical one. How do you build an engine that uses generative AI for multilingual work without trusting it blindly?

Well, let us take it one question at a time.

1. Why is "just translate it with AI" not an engine?

Because a single model, used once, with no check, fails in three quiet ways.

It drifts in meaning. A model does not translate; it predicts the most likely next words. Most of the time that lands on the right meaning. Some of the time it lands on a sentence that reads beautifully and means something slightly different. In a poem that is charming. In a land permit, a drug label, or a benefit eligibility rule, it is a harm.

It is inconsistent with terms. Ask the same model to translate "Divisional Secretariat" on Monday and on Thursday and you may get two different Sinhala renderings. Multiply that across a thousand documents and your citizens, or your customers, are reading a different vocabulary on every page.

It hallucinates, and it hallucinates fluently. In 2025 Deloitte Australia had to refund part of a report it wrote for the Australian government after researchers found a fabricated court quotation and references to academic papers that did not exist. Nobody set out to deceive. A capable model produced confident text, and nobody read it closely enough before it went out. That is exactly what happens in translation, except in a language the approver may not read.

And there is a fourth failure that is specific to languages like ours. These models were trained overwhelmingly on English. Tamil is comparatively well served, because tens of millions of speakers across the world have written a great deal of it online. Sinhala is spoken by around twenty million people, nearly all of them here, and we have put very little of it on the internet. Research on commercial language models has shown that speakers of many languages pay more per sentence, because their text breaks into more tokens, and receive poorer results for it. Recent benchmarks built by Sri Lankan researchers show the same pattern: models that reason well in English degrade noticeably when the same problem is posed natively in Sinhala or Tamil.

In simple terms: the model that is best overall is not necessarily the model that is best for your language, in your domain, on your kind of document. Which brings us to the engine.

2. What does the engine actually look like?

Start with the first diagram above. The whole idea fits in one line: translate once, validate once, publish everywhere.

There is one authoritative source. Not three documents that someone hopes are the same, but one document, in one language, that is the truth. Every other edition is derived from it, and when the source changes, the editions change with it.

From that source, the engine produces the Sinhala, Tamil and English editions. And from those editions, every channel is fed: the website, the mobile app, the PDF, the printed form, the chatbot. The chatbot does not translate on the fly and invent its own version. It reads the approved edition.

The pipeline has six steps, and each one is a gate rather than a formality.

  1. Draft. A human writes the source.
  2. Review. A human checks the source. You cannot translate your way out of a bad original.
  3. Translate. The models do the heavy lifting here. This is where the six days of monotonous work become one.
  4. Validate. Meaning, terminology and legal sense are checked, by a second model and by a person.
  5. Approve. A named human signs. The signature is the point of the whole engine.
  6. Publish. All three editions go out together, versioned, with the same meaning.

Three quality principles sit under the pipeline, and I would print them on the wall: same meaning, legal accuracy, citizen-friendly. Or, if you are not a government: same meaning, accurate to your domain, and written the way your customers actually speak.

3. Why use more than one model?

This is the part most teams skip, and it is the part that makes the engine trustworthy.

Multi-LLM translation and validation: classify, detect language and domain, route to the best model from a pool, translate, second-model review, human approval, approved publication; measured on semantic fidelity, terminology consistency, fluency, hallucination rate and legal meaning preservation

Look at the second diagram. Between "source document" and "approved publication" there are two things a single-model setup never has: a router that chooses the model, and a second model that reviews the first.

The router. Before translating anything, the engine classifies the document, detects its language and its domain, and then picks the model that has measured best for that combination. Not the model with the most impressive launch. The one that scored highest on your benchmark, for this language, in this domain, on this document type. In my own sessions I have watched Gemini handle Sinhala grammar more naturally than its American peers, because Google has been indexing Sinhala and Tamil web pages for over twenty years. I have watched DeepSeek surprise a room with fluent Sinhala, because it was trained deeply on Chinese and on broad non-English data. I have watched Claude produce the most careful legal drafting in English. None of those observations is a verdict. They are hypotheses, and the benchmark decides.

The pool. So the engine holds a pool: Gemini, DeepSeek, the GPT family, Claude, and whatever strong multilingual model arrives next year. The pool is a strength precisely because models keep changing. When a new model appears, you do not rebuild the engine. You benchmark it, and if it wins for Tamil legal notices, the router starts sending Tamil legal notices to it.

The second-model review. After the primary translation, a different model reads the source and the translation side by side and asks a narrow set of questions. Does this sentence mean what that sentence means? Has any term left the approved terminology bank? Has anything been added that is not in the source? Two different models rarely make the same mistake in the same place. That is why the review catches what one model alone would sail past.

This is, in fact, the same habit I use in my own engineering life and teach in every session. I sweep the facts with one tool, expand and sharpen the prompt with a second, draft with a third, and then read every line myself before I sign. The engine simply makes that discipline systematic and repeatable, so it does not depend on one careful person having a good day.

What we measure. A benchmark is only as honest as its metrics. The engine tracks five:

  • Semantic fidelity. Does the translation mean what the source means?
  • Terminology consistency. Are approved terms rendered the same way every time?
  • Fluency. Does it read like a native speaker wrote it, not like a machine transposed it?
  • Hallucination rate. How often does something appear that was never in the source?
  • Legal meaning preservation. For regulated text, does the obligation, the right, or the deadline survive intact?

Score every model on every language and domain pair against these five, on your own documents, with native-speaker graders. Then let the numbers route the work. Do not trust one model just because it is strong overall.

4. What keeps the engine safe and governed?

Now look at the third diagram, the gateway. This is the version an institution can actually run.

The translation gateway: ministries, departments, digital services, portals and mobile apps feed one gateway holding an approved terminology bank, translation memory, a multi-LLM router, a human review workflow, version control and audit logging, governed by data classification and a record of who drafted, which model was used, who reviewed, what changed and who approved

Every ministry, department, portal and app sends its documents through one gateway instead of each team quietly pasting text into whatever free tool is on their phone. That single door is what makes everything else possible. Inside it live six components.

  • An approved terminology bank. The official Sinhala, Tamil and English for every term your organisation uses, maintained by people, enforced on the models. This is what ends the Monday-versus-Thursday problem.
  • A translation memory. Sentences that have already been approved are reused, not re-translated. It saves money, and more importantly it stops an approved sentence from being re-invented slightly differently next month.
  • The multi-LLM router from the previous section.
  • A human review workflow. Named reviewers, per language, with the source and the translation side by side, and the second model's findings in front of them.
  • Version control. Every edition tied to a version of the source. When the source changes, the engine knows which editions are now stale.
  • Audit logging. For every published sentence: who drafted, which model was used, who reviewed, what changed, who approved. If a citizen or a court asks "why does the Tamil say this?", you can answer in a minute, not a month.

And around the gateway sits data classification, which decides what may go where.

  • Public material may be sent to approved public AI services.
  • Internal material stays inside an enterprise environment with no data retention.
  • Confidential or restricted material goes only to controlled or sovereign systems, or does not go to a model at all.

I want to be honest about why this matters. In every office I visit, officers are already sending files to free AI tools on personal phones. Not with bad intent. The workload is crushing and the tool helps. Banning it does not stop it; it just makes it invisible. The gateway is the sanctioned route. It says: here is the safe way, and here is what you may and may not put through it.

5. Where do the humans stay?

Everywhere that judgment lives.

The engine takes the monotonous part: the first draft of a translation, the consistency checking, the side-by-side comparison, the logging. That is the work that used to eat six days of a week. What it hands back is time for the part only a person can do.

A native reader still decides whether the Sinhala sounds like Sinhala. I learned this lesson in my own company only this month. We were preparing a series of free English books for O/L students, and the English cover line was "English without the fear." Three faithful Sinhala renderings were offered to me, all correct, all literal, all lifeless. What I wrote instead was බය නැතුව ඉංග්‍රීසි පේපර් එකට ලියමු, "let's write the English paper without fear." It uses the word students actually say for the exam paper, it uses the spoken form, and it invites the act instead of labelling a state. No model proposed it, because it is not a translation of the English. It does a different job in the reader's language. The engine cannot make that call. It can only make sure a person gets to.

An approver still signs. Chain-of-thought traces, second-model reviews and audit logs exist so that the person who signs can see what they are signing. They do not exist to remove the signature.

After all, the point of a trilingual document is not that three files exist. It is that a Tamil reader in Jaffna, a Sinhala reader in Matara and an English reader in Colombo receive the same meaning and the same rights. Same government. Same meaning. Equal access. A machine can help you get there faster. It cannot promise it for you.

6. How do you start, without a ministry-sized budget?

You do not need the whole gateway on day one. You need the habits.

  1. Pick fifty real documents that already exist in all your languages and were approved by humans. That is your benchmark set.
  2. Write the terminology bank first. Two hundred terms, three languages, one approved rendering each. This is cheap and it removes half the errors before any model runs.
  3. Run three models over the fifty documents. Have native readers score them on the five metrics. You will be surprised which model wins for which language. Write the results down.
  4. Add the second-model review to whatever you already publish. Even without a router, a second model checking the first will catch the worst drift.
  5. Log everything. Who, which model, who reviewed, what changed, who approved. A spreadsheet is fine at the start. The habit is what matters.
  6. Never publish without a named human approval in each language.

Do that for a quarter, and you will have an engine. Not because you bought one, but because you built the discipline, and the software merely followed.

Having said all that, let me end where I began, in that training hall.

The officer who asked why Sinhala gives nonsense was not asking a technical question. He was asking whether people like him, and citizens like his, get the same quality of help as everyone else. The honest answer today is: not automatically. The hopeful answer is: they can, if we stop treating translation as a button and start treating it as an engine, with measurement, with several models kept honest by each other, and with people who read and sign.

That is what we do at Idasara. Our Learn to Learn book on Idasara Academy went live in English, Sinhala and Tamil together, every chapter derived from one source and checked by a native reader before it was published. It is a small engine. It is the same engine. And if your organisation needs one of its own, in Sri Lanka or anywhere people read in more than one language, that is the work we are here to do.

Use multiple models. Validate meaning. Keep humans in control.

At a glance

  • What is a multilingual AI engine? A pipeline that turns one authoritative source document into approved editions in several languages using a pool of language models, a second-model review, a terminology bank, a translation memory, an audit log, and human approval.
  • Why more than one model? Because the best model overall is often not the best for a particular language and domain. Routing by benchmark, and having a second model review the first, catches errors a single model cannot see.
  • What is measured? Semantic fidelity, terminology consistency, fluency, hallucination rate and legal meaning preservation, scored by native readers on the organisation's own documents.
  • Who is it for? Governments, banks, hospitals, schools, publishers, and any organisation that must say the same thing correctly in more than one language.

Frequently asked questions

Can I just use ChatGPT or Gemini to translate official documents? Idasara's position is that a single model used once, with no check, is not safe for official, legal or regulated text. Use it as the first draft inside an engine with a second-model review and a named human approver, never as the final word.

Which AI model is best for Sinhala or Tamil translation? It depends on the domain and document type, and it changes as models change. Idasara recommends benchmarking several models on your own documents with native-speaker graders, and routing each language and domain to whichever scores best, rather than choosing by reputation.

What is a terminology bank and why does it matter? A terminology bank is the approved rendering of every important term in each language. Enforcing it on the models is the single cheapest way to stop the same term being translated differently across documents.

What should the audit log record? For every published edition: who drafted the source, which model translated it, who reviewed it, what changed between versions, and who approved it. This is what lets an organisation answer "why does the Tamil say this?" quickly and honestly.

Does the engine replace translators? No. It replaces the monotonous first draft and the consistency checking. Native readers and approvers remain the final gate, and their time is freed for the judgment work that models cannot do, such as choosing wording that sounds natural to the reader.

The evidence behind this piece

Diagrams: Samisa Abeysinghe, Idasara Digital, September 2026.