Community Magazine 
In June I described a feedback loop that would learn a community's terminology from the corrections translators make. It is built now. Here is what it does, what happens when it translates content it has never seen, and how to try it on your own site.
My Google Summer of Code project officially finished on 24 August, and the Translator Feedback Loop is now an installable package: a component and five plugins.
The plugins are of four types:
- Translation plugins: what service is used for automatic translation (now only Claude).
- RAG plugins: what service is used for distillation of rules and normalisation of text (now only Claude).
- Task plugins: to automate the machine translations and the distillation process.
- Content plugin: to add some specific features to the source content.
A grid and a side-by-side editor
Anyone who has run a multilingual site knows the tedious part is keeping track of what has been translated and what has not. There is a screen for exactly that now, and it is my favourite part of the whole project. The Translation Queue is a grid: each row is a content item in the source language, each column is one of the site's target languages, and each cell shows the status of that item's translation into that language. That status moves from "No translation yet", through "Translating" and "Review", to "Approved" and "Published", and returns to "Pending" when the source changes. The grid is deliberately compact, so a site running a dozen target languages still reads at a glance.
Clicking a cell with "No translation yet" starts translating that item. What comes back is written as a real, unpublished Joomla item in the target language, tied to its source through Joomla's own associations. It is an ordinary article, category, tag or menu item, so everything Joomla already does keeps working on it.
Because it covers all four of those, it has to translate them in the right order. A category is translated before the article that sits in it, and the translated article is then pointed at the translated category and the translated tags rather than at the source's. That order is not a choice. It comes from the way Joomla's content items already depend on one another.
The status of the content item in that cell then moves to review, and clicking it again opens the Translation Feedback screen, a "side-by-side" editor: the original on the left, read only, and the editable translation on the right, field by field, including translatable custom fields. The translator fixes what is wrong and approves it. That is the whole job, and it is the same job a translator was doing before.
Admin access is not a requirement, because the component is served on the front end as well, so a Joomla Publisher can do all of this without ever seeing the backend. The translating itself can run unattended, on a schedule, working through a batch. What it produces are still drafts. The translator stays the one who corrects and approves them, and that is what produces the next set of rules.
Corrections come back as rules
This is where the work stops being thrown away.
On approval, the system pairs the corrected text against a snapshot of the machine draft exactly as it was produced. The difference between those two is what the translator changed, and nothing else.
A second scheduled task collects those pairs and works out what convention explains them. The comparison runs word by word, so a one-word fix inside a long paragraph is captured as that word rather than as the whole paragraph.
What comes back is a list of proposed (candidate) rules of three kinds:
- Terminology: translate this term this way.
- Style: how it should read, formal or informal.
- Preservation: leave this as is.
A machine translation is created unpublished, and a distilled rule arrives unpublished. That keeps both decisions with the translator: what reaches visitors, and what shapes the next translation. Either can be set to publish automatically instead, for a site where having something live matters more than having it checked first.
Every published rule for the target language is retrieved, and only the relevant ones are sent along with the text: the rules whose term actually appears in it, plus the style rules for that language. Matching survives inflection, because the rule's term and the words of the text are both normalised to a standard form first, a noun to its singular and a verb to its infinitive. So a rule written about "article" still applies where the text says "articles". Each word's standard form is worked out once and then remembered, since it never changes.
The approach is inspired by RLHF, reinforcement learning from human feedback, and built with RAG, retrieval augmented generation: the model is given a relevant selection of the rules along with the text it has to translate.
Starting from work already done
The primary goal for all this is Joomla's own user documentation, in as many languages as possible.
Herman saw early that we would not have to start from nothing there. Joomla's language packs already hold translations its communities approved years ago, and his idea was to distill those into rules, so a documentation site begins with the translators' work already instead of a cold start.
To do that I built a separate extension. It reads a language pack the site already has, translates those same strings again with no rules in play, and turns every difference between the two into feedback for the distiller. It ships on its own rather than in the package, not only because it is meant for documentation, but more generally: it is Joomla specific. It is not for domain-specific translations other than Joomla's own. What comes out arrives unpublished like any other proposal, so a language team is checking both the decisions it made years ago and how the distiller has read them.
Rules from one site can be used on another. The Rules view exports rules to a file and imports them back, which is how a community shares what it has agreed on, or moves it from a staging site to a live one. Rules the site already has are skipped, matched on the term they apply to rather than on their name. Imported rules arrive unpublished as well, unless you choose to publish them on import.
What it looks like when the loop closes
Take the German word for "article". Translated the everyday way it comes out as "Artikel". The German Joomla community settled on "Beitrag".
A translator corrects that once and approves it. The distiller sees the difference and proposes a terminology rule, and once that rule is published later German translations use "Beitrag". Style works the same way: corrections that turn a formal "Sie" into an informal "du" become a rule for informal address, which the system works out rather than being told. The French community keeps "template" in English, and a preservation rule holds it there.
An article the system has never seen then comes back using "Beitrag", and "du" throughout, including the verb endings. Neither choice was in the text it was given. Both came from corrections made earlier, on other articles.
I gave a live demo of this at the Joomla User Group London meetup on 18 August. The slides from that presentation are online, and the recording should appear on the group's YouTube channel.
Trying it, and what would help
The package installs like any other Joomla extension. It needs a multilingual site with more than one published content language, and version history enabled, which a standard Joomla installation already has. The repository has a user guide covering the setup and the workflow, and a guide to writing a translation plugin for another service.
The most useful thing anyone can do is install it, try it on real content in their own language, and tell me how it goes. Suggestions are just as welcome. The second most useful is a plugin for a translation service you already use: the translating and the rule-distilling are both plugins, so neither is tied to the one the package ships with.
That documentation work is where language teams come in. If your community would like to read Joomla's documentation in its own language, reach out to Herman or to me. We would love the help, and you would not be starting from nothing.
Twenty years of decisions about how Joomla should be read in each language already exist, in people's heads and in the corrections they make. This is a way of keeping them.
A glimpse of the room where this was designed and shaped. Many thanks to my mentors, Herman Peeren and Stefan Wendhausen.
Comments