For my master’s practicum at DCU I worked with Alpha CRC on machine translation for low-resource languages — improving translation accuracy and linguistic adaptability for pairs where the data most systems assume simply isn’t there.
This post is about the shape of that problem, which I think is more interesting than it first sounds.
Table of contents
Open Table of contents
The assumption everything else rests on
Modern machine translation is very good, and the reason is unglamorous: for a handful of language pairs there are enormous quantities of professionally translated text. Parliamentary proceedings, EU legislation, film subtitles, product documentation. English–French, English–German, English–Spanish — decades of human translators producing aligned sentence pairs, largely as a side effect of doing something else.
Almost every technique in the field quietly depends on that abundance. When you have millions of aligned pairs, a lot of hard problems become tractable by volume.
Now take a language with a few thousand aligned sentences, or a few hundred. Every method built on abundance degrades, and some of them degrade in ways that are hard to detect — the model produces fluent, confident output that is simply wrong. Fluency and accuracy come apart, and fluency is the one that survives.
There are roughly seven thousand living languages. Production MT systems support a small fraction of them well. That gap isn’t mostly a modelling problem; it’s a data problem wearing a modelling problem’s clothes.
The playbook
There is a standard set of moves. None of them are clever on their own — the difficulty is in how you combine and tune them for a specific pair.
Transfer from a parent. Start from a multilingual model that already learned something general about language structure from high-resource data, rather than training from scratch. You’re borrowing representations and hoping enough of them carry over.
Fine-tune on what you actually have. However small the genuine parallel corpus is, it’s the only direct signal about the pair you care about. Handle it carefully.
Back-translate. Monolingual text in the target language is usually far easier to find than translated pairs — news, books, scraped web text, transcribed speech. Run it backwards through a model to produce synthetic source sentences, and treat the result as extra training data. You are manufacturing the data you lack, knowingly accepting that some proportion of it is wrong, and betting that the volume is worth the noise.
That bet is the interesting part. How much synthetic data helps before it starts poisoning the model is not a settled question, and the answer moves depending on the pair, the domain, and how good your backward model was to begin with.
Why “low-resource” hides a lot
The term flattens together situations that aren’t much alike:
- Languages with millions of speakers but little digitised text.
- Languages with a written tradition but no parallel text.
- Languages that are primarily spoken, where your corpus is transcription and carries all of transcription’s problems.
- Languages with rich morphology, where a fixed vocabulary of subword tokens fits far worse than it does for English.
These need different responses, and a technique that rescues one can do nothing for another. “Low-resource” describes a symptom, not a cause.
Evaluation is its own problem
The standard automatic metrics compare a system output against reference translations. When references are scarce, or produced by a single translator, or subtly non-native, the metric inherits every one of those limitations — and you have no easy way to tell whether a score moved because the model improved or because the reference happened to match.
Coming from a testing background, this is the part I find hardest to let go of. You are optimising against a measurement you know to be unreliable, for a language you very likely don’t speak, and the honest position is that the metric is a weak proxy and native-speaker judgement is the real evaluation. That’s expensive and slow, which is precisely why people lean on the proxy.
This is where your specific work goes, and it’s the part I can’t write for you: which language pair(s) you worked on, which base model you started from, what the corpus actually looked like, what you tried, what the numbers did, and what surprised you. That’s the part nobody else can publish.
What stayed with me
The engineering instinct is to reach for a better model. In this problem the model is rarely the binding constraint — the data is, and so is your ability to tell whether anything improved. Most of the real work is in corpus construction, in being careful about what you’re measuring, and in accepting that some of the training data you’re feeding the thing is wrong and you can’t tell which parts.