Translating Is Not Localising: Lessons from Shipping One Product in 27 Languages

Translation can make a product readable. Localisation has to make it usable.

That distinction becomes difficult to ignore when a product moves across 27 content languages. Words that look correct in a translation table can introduce an unintended legal term, violate the punctuation habits of a language, overflow a control or leave a field team with a report that reads smoothly but no longer preserves the evidence captured on site.

These are not merely editorial problems. They sit at the intersection of language, interface design, software testing, data architecture and construction practice. A voice-first construction documentation and defect management platform has to deal with all of them at once: workers speak, the software structures what they say, and the resulting material may become evidence, a defect, a daywork report, a task list or part of a handover.

Gewerkton offers a particularly revealing field report. Born in the German market, it has its deepest commercial integration there through GAEB, REB, XRechnung and DATEV. Yet it is being built for global markets, with 27 content languages and a choice of regional AI providers across the EU, the US and Asia, including mainland China.

The product is in beta now. A public beta is planned for fall 2026.

Vasco Translator Q1 | Voice Cloning | Phone Call Translation | Scarlet

• Voice Cloning Technology: Sound like yourself in 54 languages
• Real-Time Phone Call Translation: Translate calls in 53 languages instantly
• Lifetime Free Connectivity: Built-in SIM for free internet worldwide

View Latest Price

As an affiliate, we earn on qualifying purchases.

As an affiliate, we earn on qualifying purchases.

The KVKK incident: when translation creates meaning

One of the sharpest lessons came from the KVKK incident, in which a translator quietly invented legal terms. The danger was not a conspicuous mistranslation. It was language that looked plausible enough to survive an ordinary reading.

This is why localisation cannot be treated as a mechanical exchange of one phrase for another. A translator may receive a short source string without the wider product context. Faced with an apparent gap, the translator can fill it with wording that sounds appropriate. The result may be polished prose, yet it can assert something the source never said.

Legal and privacy language makes this especially visible because a small semantic addition can change the nature of a statement. But the underlying problem is broader. Construction software contains labels for evidence, reports, instructions, signatures, deadlines, plans, models and operational data. If localisation silently narrows, expands or formalises one of those concepts, users may encounter a different product in language B from the one described in language A.

The KVKK incident therefore points to a simple editorial discipline: translation must preserve claims, not improve them. A locally familiar expression is useful only when it carries the same meaning as the source. Fluency is not a licence to add assurances, obligations or legal categories.

This also explains why a language review cannot stop at spelling and grammar. The reviewer must ask a more demanding question: does the translated text say precisely what the product actually does? That question connects localisation directly to product truth.

A hyphen can be a product decision

Malay and Indonesian reduplication created a different kind of problem: hyphens. This may sound like a minor typographic concern, especially beside data residency or model coordination. In a multilingual interface, however, punctuation is part of the language system.

Reduplication is not decorative. Its written form affects whether a term looks natural and whether the product appears to understand the language it claims to support. A generic rule that removes, inserts or normalises hyphens may produce an interface that remains technically legible while feeling linguistically wrong.

The lesson is larger than the punctuation mark itself. Product teams often treat text as a sequence of characters that can be placed into interchangeable containers. Languages resist that model. They bring their own rules for word formation, spacing, repetition and visual rhythm. Those rules reach beyond the translation file and into tokenisation, search, line wrapping, validation and testing.

Localisation therefore belongs in engineering, not only in copy production. If the software manipulates a language after translation, every manipulation becomes a possible source of error. A correct entry in a language file can still emerge incorrectly in the finished interface.

Character budgets expose the interface

Character budgets are another place where translation reveals assumptions hidden in product design. A label that fits comfortably in the source language may break the interface after translation. The failure may appear as clipped text, an awkward line break or a control pushed out of alignment.

The usual temptation is to shorten the translation until it fits. Sometimes a shorter equivalent exists. Sometimes it does not. Compressing a phrase merely to satisfy a box can remove meaning, especially when the phrase distinguishes evidence from a note, or an instruction from a general comment.

That makes the available space a semantic constraint. Designers are not simply allocating pixels; they are deciding how much meaning an interface can display. A rigid character budget transfers the burden to translators, who may then be asked to solve a layout problem by weakening the language.

A multilingual product needs to be observed in its rendered state. Translation tables alone do not show whether navigation remains understandable, whether a button can still carry an accurate command or whether a field label competes with the value entered beneath it. The interface is where linguistic correctness and functional clarity finally meet.

This matters particularly on a construction site. The Gewerkton Field app turns dictation into evidence, defects, daywork reports, takt and portal workflows. In that setting, the language must work within the immediate task. A concise label is useful, but only if it still identifies the right action.

Why an LLM misses the last ten percent

“Just run it through an LLM” is attractive because it treats scale as the main obstacle. Once thousands of strings can be processed quickly, 27 languages can look like a throughput problem that has been solved.

The difficult part is the last ten percent. That is where fluent output meets product-specific meaning, local conventions, character limits and the facts the company is actually entitled to state. An LLM can produce language that reads naturally while introducing the same kind of semantic invention seen in the KVKK incident. It can also choose wording that is accurate in isolation but unsuitable inside a particular control.

The last ten percent is not necessarily the most visible portion of the text. It is the portion that demands context. Is the string a heading, a button, a status or a report field? Does it describe something already captured, or tell the user to capture it? Is the wording part of a privacy statement, an operational workflow or a marketing page? Can it wrap, or must it remain on one line?

No single pass answers all of those questions. Language generation and language verification are different jobs. The first creates a candidate. The second checks that candidate against the interface, the underlying function and the permitted meaning.

Gewerkton’s broader engineering model makes the scale of that verification notable. The platform is built by a solo founder directing a fleet of coding agents using Codex and Claude. In one night, the fleet shipped 21 software packages, verified with negative controls and mutation tests. That feat demonstrates how quickly agent-directed software work can move. The localisation lessons show the corresponding need for disciplined checks when speed reaches language.

Structured evidence beats prose notes

For documentation, the central issue is not whether a translated paragraph sounds elegant. It is whether the original event remains identifiable.

A prose note can blend observation, interpretation and follow-up into one block of text. Structured evidence separates the useful parts: what was captured, which defect or task it concerns, what deadline applies, what report it belongs to and how it connects to the project record. Translation can then help people work with the record without pretending that a rewritten paragraph is the event itself.

This distinction is essential for cross-border teams. Gewerkton is intended for projects where EU, US and APAC teams work together, each in their own language, while the evidence original stays unambiguous. The aim is not to make every participant write identical prose. It is to let different participants understand and act on the same structured material without obscuring the source.

Original audio is especially important in long infrastructure and tunnel projects, where durations are long, change orders are numerous and instructions can be backed by that audio. The translated or structured output supports access and coordination; the original remains connected to what was actually said.

This is the practical meaning of the line, “On site, what counts is what’s proven.” Documentation is strongest when it preserves the relationship between a statement and its supporting material. Better prose can improve readability, but readability alone does not establish that relationship.

One language layer, several construction settings

The demands change across project types, even when the language architecture is shared.

• On wind farms and renewable-energy projects, sites are distributed, crews rotate, field acceptance matters and capture must continue offline in dead zones.
• In data centres and industrial plants, many trades work in parallel under tight deadlines, and meeting decisions become trade-sorted task lists.
• In housing and building construction, defects carry a photo and deadline, daywork reports can be dictated, and signatures are collected on the device during handover.
• In infrastructure and tunnels, long project durations and many change orders make the connection between instructions and original audio particularly important.
• On cross-border projects, EU, US and APAC participants work in their own languages while the evidence original remains unambiguous.
• On projects in Asia, Chinese, Korean and Vietnamese crews need multilingual handling from capture to report, with data residency chosen for the project.

These settings show why localisation cannot be reduced to the public website. It follows information from capture through coordination and reporting. The user-facing words, the structured fields and the retained originals all contribute to whether the result remains understandable across teams.

Field, Studio and Cloud

Gewerkton is a branded house with three product lines, each occupying a distinct part of that information path.

Field is the voice-first construction site app, where dictation becomes evidence, defects, daywork reports, takt and portal activity. Gewerkton Studio is the browser workspace for plans and models. Where no model exists, the site team can create one in the browser. Gewerkton Cloud handles operations and model or data coordination between Field, Studio and third parties.

The separation is useful when thinking about language. Capture, spatial context and coordination are related, but they are not identical. A spoken observation on site, its location in a plan or model, and its movement between systems each impose different requirements. Localisation has to survive those transitions without turning a structured fact into free-floating prose.

Regional AI choice is part of language engineering

Language processing also raises an infrastructure question: where does it happen, and whose service handles it?

Gewerkton’s BYO-AI approach supports 13 AI providers. Users bring their own keys and can select providers by region across the EU, the US and Asia, including mainland China. The stated aim is to avoid vendor lock-in. Data residency is likewise a choice between an EU cloud and the user’s own infrastructure.

This does not make localisation automatic. It does recognise that a global language system cannot assume that every project will make the same provider or residency decision. Projects involving teams in mainland China, elsewhere in Asia, Europe or the United States may share documentation structures while selecting different infrastructure.

The marketing site follows another unusually strict architectural choice. It is available in 27 languages, uses zero trackers, has no cookie banner and is fully egress-free. Its media bank contains more than 51 self-produced clips and posters. Those facts place the multilingual content in a wider system rather than presenting translation as an isolated publishing exercise.

The real work begins after the first translation

Shipping one product in 27 content languages does not yield a neat rule that eliminates language errors. It produces a more useful conclusion: translation is an input to localisation, not its completion.

The KVKK incident shows the risk of plausible invention. Malay and Indonesian reduplication shows that punctuation can carry linguistic structure. Broken character budgets show that interface dimensions can distort meaning. The final ten percent of LLM-assisted work shows why fluency cannot substitute for contextual verification.

For construction documentation and defect management, the answer is not ever more polished prose. It is a system in which the evidence original remains clear, the important details are structured, and each language helps its users reach the same underlying record.

Gewerkton remains in beta, with the public beta planned for fall 2026. Its 27-language implementation is therefore best read as an active language-engineering field report: one in which translation, interface behaviour, evidence structure, AI-provider choice and data residency are parts of the same problem.