AI Won't Refactor Your Web Component
AI coding tools extend local patterns fast. They do not reliably supply the design judgment needed to reduce complexi...
Stop Outsourcing Your Product Language
6 min read
Translation is product work
01.09.2026, By Stephan Schwab
Software translation is usually treated as clerical work: export strings, send them away, import the result. That works until one innocent verb approves an invoice, changes a contract, or tells a customer something final happened. AI makes the first draft cheaper, not the consequences. Product language needs the same context, review, and ownership as the code behind it. The question is not who can translate a file. It is who can judge the words inside the working product.
The traditional translation workflow was built for brochures, manuals, and legal documents. It works tolerably there because the document is the thing.
Business software is different. Its words live inside permissions, approvals, invoices, validation errors, and buttons people click when money or customer data is involved. A phrase is part of an action.
Yet the old pattern survives:
- developers export string files
- a vendor translates them out of context
- someone imports them later
- the product team discovers the words do not fit the screen or the market
- nobody knows which change introduced the confusion
That is not a failure of translation as a profession. It is a failure of product ownership.
Multilingual business software gets harder when language becomes frontend architecture. The calmer model is to keep language where the product already has ownership: in the repository, in review, in tests, and in the delivery flow.
The translator should see the product
If a translator cannot see the workflow, they are guessing. Expensively, politely, and often incorrectly.
The development team owns the product. The translator owns a file. The business owns the consequences.
Wonderful arrangement. Everyone gets a separate responsibility and nobody owns the sentence the user actually reads.
The problem is not that translators work outside the company. The process removes them from the context where meaning lives. Submit may be harmless on one screen and wrong on another. Approve, accept, confirm, release, and send look interchangeable until one triggers an invoice, changes a contract state, or makes a customer believe something is legally final.
That context rarely survives an export. It survives much better in a pull request.
A multilingual reviewer can see the changed keys, surrounding templates, product discussion, and a screenshot or preview of the working screen. AI can prepare the first pass. Human review protects the product meaning.
The job shifts from “translate these files” to “decide whether this product change speaks correctly in this market.” That is a much better job.
Keep the runtime boring
The best i18n architecture is usually the one where the user receives the correct document in the correct language.
The backend-first web component approach keeps the translation model deliberately unexciting. The server resolves the locale from Accept-Language or a saved preference, then renders the page in that language.
Web components provide reusable UI behavior where it is useful, but they do not become a second translation runtime unless the product truly needs that. A component can receive translated labels as attributes, slots, or rendered child content. It does not need to know how German plural rules work just to display a status panel.
Backend:
- resolve locale from request headers or user preference
- load messages
- render templates
- format dates, numbers, and money consistently
Web component:
- enhance a date picker, table, modal, or status control with browser behavior
- dispatch events
- preserve accessibility
- use the already-rendered labels it receives
The result is not primitive. It is controlled.
One pattern, any backend
Keep message catalogs beside the product and pass translated text into the HTML. The framework is incidental.
A Flask-style route can negotiate the locale, load the messages, and render HTML without putting the language in the resource URL:
SUPPORTED_LOCALES = ["en", "de", "es"]
def resolve_locale():
return request.accept_languages.best_match(SUPPORTED_LOCALES) or "en"
@app.get("/invoices/<invoice_id>")
def invoice_detail(invoice_id):
locale = resolve_locale()
messages = load_messages(locale)
invoice = invoice_service.get(invoice_id)
return render_template(
"invoice_detail.html",
t=messages,
invoice=invoice,
locale=locale,
)
The template passes translated labels into the component:
<invoice-actions
approve-label=""
send-label=""
status="">
</invoice-actions>
The catalogs stay boring:
{
"invoice.approve": "Approve invoice",
"invoice.send": "Send invoice",
"invoice.paid": "Paid"
}
German and Spanish variants sit beside the source. The team can diff them, AI can draft missing keys, and a multilingual reviewer can correct the wording next to the template that uses it.
Spring Boot follows the same model with message bundles:
messages.properties
messages_de.properties
messages_es.properties
Thymeleaf then passes localized messages to the component:
<h1 th:text="#{invoice.title}">Invoice</h1>
<invoice-actions
th:attr="approve-label=#{invoice.approve},
send-label=#{invoice.send},
status=${invoice.status}">
</invoice-actions>
Python, Java, or something else: the ownership model stays the same. The server renders the selected language, the component receives language-specific text, and the message files live in Git. Nobody emails a spreadsheet into the void.
AI drafts; humans decide
AI is useful for first drafts and consistency checks. It is not the final authority on market language.
AI makes translation review cheaper. It does not make judgment optional. Shipping machine output because the demo looked fluent is how you get polite nonsense with excellent punctuation.
Use AI for the parts it is good at:
- draft missing translations from existing source strings
- keep terminology consistent across files
- identify keys missing in one language
- propose shorter alternatives when labels do not fit
- compare wording against nearby product context
- prepare a diff humans can review
Then put multilingual humans where they add judgment:
- Does this sound natural?
- Does this match the product’s tone?
- Does the word imply the wrong legal or commercial action?
- Is the form too formal, too casual, too English, or too literal?
- Would a customer in this market trust this wording?
AI drafts.
Humans judge.
The repository remembers.
The pull request is the translation tool
Most companies already have the collaboration system they need. They just keep using it only for code.
A translation pull request can show the new keys, the AI-generated drafts, the templates where those strings appear, screenshots or preview links, reviewer comments, and test output proving that every language has the required keys.
That is much closer to product reality than sending extracted files to a vendor who never sees the user journey. It also gives the CTO something the old process rarely provides: traceability.
Who changed this label? Why did we choose this wording? Was it reviewed by someone who speaks the language? Can we revert it cleanly?
Repository-based translation work answers those questions. File handoffs leave a project manager searching email.
The workflow is small
The practical workflow is small enough to start without buying another platform:
- Developers add or change message keys as part of the product change.
- Codex drafts missing translations in the same branch.
- Automated checks fail if a locale is missing a required key.
- A multilingual reviewer checks the wording in the pull request.
- The team reviews the screen, not only the file.
- The product ships with language reviewed as part of the change.
This is not anti-translator. It is anti-isolation.
External translators can still participate, but inside the product workflow rather than at the end of a file handoff. Internal multilingual staff can help where domain nuance matters. Customer-facing people can flag wording that will confuse support. The CTO can see that translation is no longer a late-stage mystery.
Stop putting language in a side room
The product changes in one room. The language changes in another. The customer experiences the result as one thing.
That mismatch is the entire problem.
Render language-specific pages on the server. Keep components reusable without making them own translation state. Let AI prepare first drafts. Let multilingual humans review the words where the product is already changing.
That is not a transformation program. It is a better work habit. For a CTO, that matters more than another localization platform with a dashboard nobody opens after launch.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Three Ways to Understand a Country
Stefan drives Sophie to the Pacific for two days. The beach is big enough to make her feel appropriately small. Back at the finca the rain keeps th...
The Resignations
Nathan Cole resigns on a Monday morning with two sentences and no argument left in his body. By Tuesday his desk is empty and the company's institu...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Stop Outsourcing Your Product Language (01.09.2026)
- Software Has Always Moved Up the Stack (29.08.2026)
- SPAs Made i18n Harder Than It Had to Be (26.08.2026)
- AI Regression Is a Software Problem (22.08.2026)
- Your Website Must Be Open for Business (20.08.2026)