Glossary-Consistent English to Urdu Translation for Public Notices and Health Leaflets

The problem: one term, three translations

Hospitals, government departments, banks and NGOs in Pakistan publish a lot in English that people need in Urdu: health leaflets, vaccination notices, admission rules, scheme eligibility, consent forms. Translators are expensive and slow, so machine translation is increasingly used, then lightly checked.

The output is fluent but inconsistent. A term like "blood pressure", "CNIC" or "eligibility" may be translated differently in each paragraph, borrowed in English in one place and translated in another, or simply wrong. In health and legal text, inconsistency confuses readers and wrong terms can mislead them. Organisations usually have, or could easily write, a short glossary of approved terms. Most tools do not enforce it.

There is also a real choice to make about borrowed English. Many Urdu readers know "blood pressure" or "CNIC" better than a formal Urdu equivalent. A glossary lets the organisation decide once, with its readers in mind, instead of leaving it to whichever way the machine happens to translate each sentence.

What already exists and the gap

• Google Cloud Translation supports glossaries, custom dictionaries for consistent translation of domain terms, as a paid API.
• Open translation models such as Meta's NLLB cover Urdu and many other South Asian languages.
• Language models translate well when prompted and can be given a glossary in the prompt, but nothing guarantees they follow it.

The gap is a tool and a fair comparison: which method actually keeps approved Urdu terms consistent across a whole document, at what cost to fluency, and with a review screen that shows a translator exactly where to look.

Inspiration

"Lexically Constrained Decoding for Sequence Generation Using Grid Beam Search" by Chris Hokamp and Qun Liu, published at ACL 2017, showed how to force a sequence model to include given words or phrases in its output by changing the search, without retraining the model. It is the classic method for terminology constraints in machine translation. Your project tests it, and later variants, against glossary prompting for English to Urdu.

What you build

• Translators and communications staff paste or upload a document, choose a glossary and get an Urdu draft with glossary terms enforced and problems highlighted.
• Terminology owners, such as a hospital's patient education team, maintain the glossary.
• Readers get documents where the same thing is always called the same thing.

The review screen is where the tool earns trust. Each sentence shows the English, the Urdu, the glossary terms found and whether each was used. A translator can accept, edit or flag a sentence, and the system records which method produced it.

The technically interesting part

• Urdu morphology. Urdu terms change form with gender, number and case, and postpositions attach nearby. A constraint that forces one exact string can produce broken grammar. Store inflected forms and decide how strict the check should be.
• Constraints versus fluency. Forcing terms can make sentences awkward. Measure both term accuracy and overall quality, and look at examples where they trade off.
• Prompted glossaries leak. Language models sometimes ignore a glossary entry, or apply it where it does not fit. Your term checker catches both.
• Right-to-left output. Exporting Urdu with mixed English terms, numbers and punctuation needs care with bidirectional text.

How to evaluate it

• Term accuracy: share of glossary terms in the source that appear correctly in the output, per method.
• Overall quality: automatic scores such as chrF against reference translations, plus human ratings from a qualified Urdu translator on a sample.
• Consistency: for terms that appear many times in one document, how many different translations each method used.
• Editing effort: time a translator needs to finalise a page from each method.

Suggested plan

• Weeks 1 to 3: read the paper, collect documents and a glossary with a partner organisation, get reference translations.
• Weeks 4 to 7: the three methods and the term checker.
• Weeks 8 to 10: review screen and export.
• Weeks 11 to 13: evaluation with the translator.
• Weeks 14 to 15: report and demo.

Path to a product

Health systems, government departments, NGOs and banks all publish in several languages and care about consistent terms. A translation workspace with glossary enforcement and review, sold to organisations, is realistic, and the same approach extends to Sindhi, Pashto and other languages. The project is strong preparation for NLP and AI engineering roles.

Scope warning

The tool drafts; a qualified human approves anything published, especially health information. Do not train a translation model from scratch. Use documents the partner owns or that are public, and do not put patient-specific text into any external API.

Learn what you need on Sefism

• AI engineering roadmap: using models through APIs and checking their output.
• LLM APIs cheat sheet: prompting, cost and structured output.
• Hugging Face Transformers Documentation: running the open translation model and custom decoding.
• CS224N: Natural Language Processing with Deep Learning: sequence models and decoding.
• AI Evals: Everything You Need to Know: combining automatic and human evaluation.

Get help with this idea

The risk is an evaluation with too few reference translations to mean anything. Tauseef can help you find a partner, plan the test set and keep the comparison fair. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session