Almost every second project that comes to us starts with the phrase: “The website needs to be in Ukrainian and English. And maybe Polish as well.” It sounds like a minor detail in the technical specification. In practice, multilingual support is one of those things that costs a business far more than it seems at the start.
And the issue is not the technology. Building a language switcher in Laravel takes a few hours. The issue is content that lives: new pages appear, product descriptions change, news gets published, delivery terms get updated. Every one of those changes needs a translation.
In this article, we explain how we built an AI-powered translation pipeline inside a Laravel project, which architectural decisions we made, which mistakes we ran into, and — most importantly — where the line is beyond which automation still needs human control.
The problem almost every multilingual website faces
The typical picture looks like this.
A content manager adds a new page in Ukrainian. The text goes to a translator or an agency. Two to five days later, the English version comes back and has to be pasted into the admin panel by hand, checked for broken layout, and published. If there are three languages — multiply by three.
As a result, the business gets:
- a constant mismatch between language versions — Ukrainian is already updated, English is still “old”;
- costs that grow in proportion to the amount of content and the number of languages;
- a bottleneck in the process — translation becomes the reason a new page goes live late;
- manual copy-paste work during which links, formatting, and SEO fields get lost;
- a fear of adding another language, because it means yet another full translation cycle of the entire website.
The most telling part is that most of this content is not unique marketing creativity. It is product descriptions, technical specifications, news, FAQs, system messages. In other words, exactly the type of text modern language models handle very well.
Why “just plug in a translator” doesn’t work
The first idea every developer has: call a machine translation API on save and close the ticket. We started there too. And fairly quickly understood why that is not enough.
Loss of context. The word “lock” in a real-estate section and in a hardware catalog are different words. Classic machine translation sees a sentence, not a page.
Terminology. Every business has its own terms: product names, pricing plans, services, internal concepts. They cannot be translated differently each time. “Personal account” should not become Account, Personal Office, or Dashboard depending on the algorithm’s mood.
Markup and placeholders. Real-world texts contain HTML, links, variables like {name} or :count, Markdown. Naive translation regularly breaks tags, reorders attributes, or translates the placeholder itself.
Tone of voice. A brand that speaks to customers informally and with light irony cannot suddenly sound like a legal contract in its English version.
SEO. Meta tags, alt texts, page slugs, hreflang — all of this is part of multilingual support too. If only the page body is translated, search engines see a half-translated site.
So the task is not to translate text. The task is to build a process in which translation is controlled, consistent, and never blocks publishing.
Molfar Tip: Before choosing a translation tool, describe which types of content you have and how they differ. A product card, a legal offer, and a blog post require different approaches — and different levels of control.
How we built it: solution architecture
Here is a brief look at how it works under the hood. We deliberately describe principles rather than code: they transfer to any stack, although our default one is Laravel.
1. A single source of truth
Every record has a source language. That is the version the content manager edits, and that is the reference. All other language versions are derived from it. This is fundamental: we never allow the system to end up in a state where the English and Ukrainian texts have independently “drifted apart” and nobody knows which one is current.
2. Translation is an asynchronous event, not a synchronous call
When content is saved, we do not translate it “right here, right now.” We record an event: “the source has changed.” A queue (Laravel Queue) picks it up, and separate translation jobs run in the background for each target language.
This gives several advantages at once:
- the editor does not wait 10–20 seconds for a model response on every save;
- an external API failure does not block publishing the original;
- jobs can be retried, rate-limited, and scaled independently of the main application.
3. The model receives context, not just text
This is the key difference from a “plain translator.” Before calling the AI, we assemble a context package:
- content type (product card, news item, service page, system message);
- the company glossary — terms that must always be translated the same way, or not translated at all;
- a description of the brand’s tone of voice;
- several human-approved translations of the same type as style examples;
- explicit rules: do not change the HTML structure, do not touch placeholders, keep headline length within reasonable limits.
It is the context that turns a general-purpose language model into “a translator who knows your company.”
4. Structured output instead of free text
We do not ask the model to “translate this HTML.” We split the content into fields — title, subtitle, body, meta description, alt texts — and ask for the result in a strictly defined structure (JSON). Each field is then validated: are the tags preserved, are the placeholders in place, is the meta tag within the length limit?
If validation fails, the job is retried with clarification. If it still fails after retries, the translation is flagged as “needs attention,” and the editor is notified.
5. Humans stay in the loop — but off the critical path
Every automatic translation is stored with a status. We use a simple model:
- auto — generated by AI, not yet reviewed;
- approved — reviewed and approved by a human;
- stale — the source changed after translation; the version needs updating;
- manual — the editor rewrote the text by hand; automation no longer touches it without explicit permission.
Which content types can be published with the auto status immediately and which only after approval is decided by the business, not the system. A product card with specifications can go live automatically. A public offer agreement cannot.
6. Fallback: the website never shows an empty space
If a translation is not ready yet, the visitor sees the source-language version or the site’s default language — not an empty block or a technical key. An obvious thing that is, surprisingly, often forgotten.
7. SEO as part of translation, not a separate task
The meta title, meta description, image alt texts, and slug are generated within the same job as the main text. For slugs, we additionally apply transliteration and a uniqueness check. Hreflang tags are built automatically based on which language versions actually exist and are published.
8. Cost, idempotency, and control
API translation costs money, so:
- we never re-translate what has not changed — a hash of the source is stored for every field;
- jobs are idempotent: re-running them creates no duplicates and does not overwrite manual edits;
- we track translation spend per content type so the business can see where the money goes.
Molfar Tip: Create a glossary before you start automating translation. It is the cheapest way to significantly raise output quality — and a useful document for the whole team, not just for the AI.
What it gave the business
The most visible effect — the bottleneck disappeared. A new page appears in all languages almost immediately after the original is published, not days later. The content manager works in one language; reviewing translations became a separate task, not required for launch, that can be done at a comfortable pace.
The second effect — predictable cost. Translation spend no longer depends on whether a translator is available this week, and it is measured in content volume rather than hours.
The third — and, in our view, the most strategically important — adding a new language became cheap. Previously, a new language meant a full translation cycle of the entire site, with the corresponding budget and timeline. Now it is a configuration change plus a background process that gradually fills in the new version.
A side benefit: the quality of the original texts improved. When the team knows the text will be translated automatically, they start writing more clearly and with better structure.
Where we deliberately do not trust automation
We do not believe AI translation is a universal answer. There are categories of content that, in our projects, go through mandatory human approval or are translated manually altogether:
- legal texts — contracts, offer agreements, privacy policies, return terms;
- brand slogans and key marketing messages — what matters here is not accuracy but impact;
- financial and medical information, where the cost of a mistake is too high;
- content with cultural context — jokes, idioms, local references.
For everything else — catalogs, news, FAQs, service descriptions, system messages — automatic translation with spot-check review works reliably.
Molfar Tip: Do not try to automate 100% of your content from day one. Start with the most voluminous and least risky type — product cards, for example — and expand coverage once you are confident in the quality.
Common implementation mistakes
A few things we either did ourselves or have seen in other projects:
- Synchronous translation on save. Looks simple, but makes the admin panel slow and unreliable.
- No statuses. If you do not distinguish “automatic” from “approved,” the editor does not know what needs checking.
- Translating an entire HTML block in one request. The model may reorder tags or “improve” the structure. Split into fields.
- Overwriting manual edits. The worst case: an editor spends an hour polishing a text, the source is updated, and automation wipes it all. Manual edits must be protected.
- Ignoring SEO fields. A translated page body with a Ukrainian meta description is not a multilingual website.
- No limits. Without rate limiting and cost tracking, one bulk catalog update can unexpectedly generate thousands of API requests.
Conclusion
Multilingual support is not a switcher in the site header. It is a process that accompanies every content change throughout the life of the project.
Modern language models make it possible, for the first time, to automate this process without losing quality — but only if the right architecture is built around the model: context, validation, statuses, and human involvement where it is genuinely needed.
And the right question for a business here is not: “Can we replace the translator with artificial intelligence?”
It is: “How much content are we not publishing in other languages simply because translation is expensive and slow?”
The answer to that question is what determines whether you need this kind of automation.
Molfar Insight
We do not believe every website needs an AI translation pipeline. If you have ten pages that change once a year, a professional translator will do it better and cheaper.
But if content lives and changes weekly, and there are two or more language versions, the cost of “manual” multilingual support grows quietly and constantly. In that case, investing in an automated process pays off not through savings on a single translation, but because the website finally starts speaking to all of your customers at the same time.
The right automation is not the one that removes people from the process entirely. It is the one that leaves them only the decisions that genuinely require a human.