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

A product can be translated and still feel foreign. Every sentence may be intelligible, every menu may contain the right nouns, and every instruction may be grammatically sound. Yet the product can still fail at the moment somebody must use it quickly, under pressure, with evidence that needs to remain clear across languages.

That distinction matters for Gewerkton, a voice-first construction documentation and defect management platform for global markets. The product was born in the German market and has its deepest commercial integration there, including GAEB, REB, XRechnung and DATEV. But its content spans 27 languages, while projects may bring together teams from the EU, the US and APAC. Chinese, Korean and Vietnamese crews may capture and report work in their own languages. Regional AI-provider choice extends across Europe, the US and Asia, including mainland China.

This is not a story about replacing one set of words with another. It is a field report about the troublesome final stretch: invented legal language, meaningful punctuation, interfaces with finite space and fluent machine output that remains subtly wrong. Above all, it is about why structured evidence is more dependable than prose notes when information must travel between people, trades, systems and languages.

Gewerkton is in beta now, with a public beta planned for fall 2026. That status is important. The language system, like the software around it, is being tested before broad public use.

Interface Development Tools RS485 click 3.3V MIKROBUS VERSION

View Latest Price

As an affiliate, we earn on qualifying purchases.

As an affiliate, we earn on qualifying purchases.

Translation answers only the first question

Translation asks what a passage means in another language. Localisation asks whether that passage still works where it appears. The difference sounds academic until a translated string enters a button, a consent notice, a task list or a construction report.

A sentence can be accurate in isolation and unsuitable in context. A short source label may become a long target-language phrase. A familiar compound may require punctuation that looks unnecessary to an outsider. A legal expression may sound plausible while introducing terminology that was never present in the source. A general-purpose language model may produce polished copy without understanding the practical role of the field it is filling.

Construction documentation makes these failures unusually visible. A note is rarely valuable merely because it reads well. It may need to preserve what happened, where it happened, which trade it concerns, what evidence supports it, what deadline applies and who must act. If translation turns these elements into an elegant paragraph without preserving their identities, the result can be fluent and operationally weak.

The useful unit is therefore not simply the sentence. It is the relationship between language, interface and evidence.

MultiLanguage Smart Translation Headset, 3-in-1 Language Translation Device 144 Languages & Accents and 3 Translation Modes, HD Sound Quality & Long Battery Life, Ideal for (#1)

• Language Support: 144 languages and accents
• Audio Features: HD sound, 5.49-inch speaker
• Translation Modes: Single, double tap, speaker, free talk

View Latest Price

As an affiliate, we earn on qualifying purchases.

As an affiliate, we earn on qualifying purchases.

The KVKK incident: fluency can conceal invention

The KVKK incident exposed one of the most dangerous localisation errors: a translator quietly invented legal terms. Nothing about an invented term necessarily announces itself. It can look formal, fit the tone of the surrounding text and survive a quick visual review. The problem is precisely that it appears credible.

Legal and policy language is not a suitable place for creative completion. A translator must convey the supplied meaning, not fill perceived gaps or upgrade ordinary wording into something that merely sounds more authoritative. When a source does not contain a legal claim, the target language should not acquire one through stylistic enthusiasm.

The incident also illustrates why surface fluency is an unreliable quality signal. Reviewers naturally notice broken grammar, missing words and conspicuous formatting errors. They are less likely to question a polished phrase that resembles professional legal prose. The smoother the invention, the easier it is to overlook.

This is one reason “just run it through an LLM” fails at the last ten percent. A model can rapidly generate coherent translations across many languages. Coherence, however, does not establish fidelity. The remaining work consists of checking boundaries: whether a term was added, whether certainty was strengthened, whether a role changed, whether an instruction became a promise or whether a neutral description acquired legal weight.

Those are small changes in wording with large changes in meaning. They require comparison with the source, not admiration of the output.

Why a hyphen is sometimes product behaviour

Malay and Indonesian reduplication provided a different lesson. Hyphens in reduplicated forms are not ornamental marks to be normalised away. They belong to the language. A localisation process that treats punctuation as globally interchangeable risks changing forms that should remain intact.

This problem often begins with a reasonable but overbroad engineering instinct. Product teams want consistency, so they standardise spacing, quotation marks, capitalisation and punctuation. Consistency is useful until a universal rule crosses into language-specific structure. At that point, tidying becomes corruption.

The lesson is not merely to create a special exception for two languages. It is to recognise that text processing rules carry linguistic assumptions. A pipeline designed around one language may interpret a hyphen as optional styling, a compound as separable or a repeated element as accidental duplication. The same rule can produce clean results in one locale and incorrect ones in another.

Localisation therefore needs protected language features. Review must cover not only what the words mean, but what automated formatting does to them after translation. A correct translation can still be damaged during import, rendering or later editorial cleanup.

For a product operating across 27 content languages, the cost of assuming that one punctuation policy fits all languages compounds quickly. The apparently minor marks deserve the same attention as the words around them because they may be part of how those words work.

The AI-Centered Enterprise

View Latest Price

As an affiliate, we earn on qualifying purchases.

As an affiliate, we earn on qualifying purchases.

Character budgets are functional requirements

Interfaces have boundaries that prose documents do not. Buttons, navigation items, status labels and narrow mobile fields have limited room. A phrase that fits comfortably in the source language can wrap, truncate or push adjacent controls out of place after translation.

This is more than a cosmetic inconvenience. On a construction site, the interface must support quick capture rather than invite the user to decode clipped labels. People may be dictating evidence, recording a defect with a photo and deadline, preparing a daywork report or obtaining a signature on the device at handover. The wording must remain legible in the space where the action happens.

Character budgets are consequently part of localisation, not a late design complaint. A translator needs to know whether a string is a heading, a button, an explanation or a trade-sorted task label. Without that context, the safest linguistic rendering may be the wrong interface choice.

Shortening also needs control. Removing words until a label fits can erase distinctions between capture, evidence, reporting and assignment. Two different actions may collapse into the same vague verb. An abbreviation that seems obvious to the person editing the string may be unfamiliar to the person using it.

The interface should be reviewed as an interface. String tables reveal textual completeness; rendered screens reveal whether the translation survives contact with the product.

Structured evidence travels better than prose

The deeper documentation lesson is that structured evidence beats prose notes. Prose asks each reader to recover the structure for themselves. They must determine the location, trade, issue, deadline, source and next action from a block of language. Every translation adds another opportunity for those relationships to blur.

Structured evidence keeps the components distinct. The original audio can remain connected to an instruction. A defect can remain associated with its photo and deadline. A daywork report can retain its report identity rather than becoming an incidental paragraph. A meeting decision can become a trade-sorted task instead of disappearing into minutes.

This is the centre of the voice-first approach in Gewerkton Field: dictation becomes evidence, defects, daywork reports, takt information or portal material. Language still matters, but it is no longer carrying the full burden of organisation. The evidence has a place in a system.

That distinction becomes especially useful across borders. Teams in different regions can work in their own languages while the evidence original remains unambiguous. Translation helps people understand the record; it does not need to replace the record.

The principle applies across the stated deployment fields:

• Wind farms and renewables involve distributed sites, rotating crews, field acceptance and offline capture in dead zones.
• Data centres and industrial plants run many trades in parallel under tight deadlines, with meeting decisions becoming trade-sorted task lists.
• Housing and building construction combines defects with photos and deadlines, dictated daywork reports and signatures on the device at handover.
• Infrastructure and tunnel projects run for long periods, produce many change orders and can preserve instructions with their original audio.
• Cross-border teams may span the EU, the US and APAC while each participant works in their own language.
• Projects in Asia may include Chinese, Korean and Vietnamese crews, with multilingual handling from capture to report and data residency by choice.

In each setting, a prose note can describe what happened. Structured evidence can preserve how the description relates to the project.

Localisation extends beyond the field app

A multilingual product is not a collection of translated screens. Information moves between different working environments, and localisation must survive those transitions.

Gewerkton Studio is the browser workspace for plans and models. Where no model exists, the site team creates one in the browser. That matters because language is attached to spatial and project context rather than floating as an isolated note.

Gewerkton Cloud coordinates operations and model data between Field, Studio and third parties. The localisation challenge therefore includes handoffs: a captured item must remain intelligible as it moves from a site workflow into plans, models, operational coordination or an external system.

Data location is another part of the same global picture. The choice is an EU cloud or the user’s own infrastructure. The bring-your-own-AI model covers 13 AI providers, with user-supplied keys and selectable regions across the EU, the US and Asia, including mainland China. The aim is choice without vendor lock-in.

Those regional options do not solve localisation by themselves. They address where and through which provider AI work can happen. Terminology, punctuation, interface fit and evidence structure still require their own controls.

Why the last ten percent resists automation

Gewerkton is built by a solo founder directing a fleet of coding agents using Codex and Claude. In one night, that fleet shipped 21 software packages, verified with negative controls and mutation tests. The episode demonstrates the speed available when agent work is directed and tested.

Language work has a comparable need for verification, but its failures are often less binary. Software can be challenged with a negative control or a mutation designed to show whether a test detects a change. A translation may pass ordinary checks while subtly altering legal force, breaking a reduplicated form or exceeding the space available in a mobile control.

An LLM can handle a large portion of the workload, particularly the first production of multilingual text. The difficult remainder is not simply “better writing”. It is the accumulation of exceptions and contextual judgments:

• Did the translation preserve the supplied meaning without inventing terminology?
• Did language-specific punctuation survive processing?
• Does the string fit its actual interface location?
• Are distinct actions still distinct after shortening?
• Does the translated description remain attached to the original evidence?
• Can the content move between field capture, plans, models and coordination without losing its role?

This is the last ten percent because generic fluency has already been achieved. What remains is product knowledge, linguistic care and inspection at the points where language meets behaviour.

A multilingual publishing system must obey the same rules

The marketing site also operates in 27 languages. It uses no trackers, requires no cookie banner and has a fully egress-free architecture. Its media bank contains more than 51 self-produced clips and posters.

This public-facing material presents another character-budget problem. Headlines, navigation, captions and posters are constrained formats. The same terminology must remain coherent across explanatory pages and product descriptions without forcing every language into the shape of the source.

Consistency here should mean conceptual continuity, not identical sentence construction. Field, Studio and Cloud need stable roles. The relationship between capture, evidence, models, operations and third parties must remain understandable. But each language still needs room to express those relationships naturally.

A content system that merely stores translated paragraphs will struggle with this. Reusable, structured concepts are more resilient. They let editors review whether the same product role has drifted across pages, while rendered checks expose where technically complete text fails in its visual setting.

The evidence original is the anchor

Gewerkton’s marketing line is: “On site, what counts is what’s proven.” It also captures the central localisation lesson.

A translation is an interpretation intended to make information usable. It should not become an opportunity to invent a claim, discard a language feature or hide uncertainty beneath fluent prose. When the underlying record matters, the translated text should remain connected to evidence that has not been silently rewritten.

That is why the documentation angle is more consequential than the novelty of supporting 27 languages. The number describes reach. The structure determines whether that reach is dependable.

Shipping multilingual content is relatively easy to begin. Machines can generate drafts quickly, interfaces can display locale files and a site can announce a long language list. Localising a working product is slower and less glamorous. It means finding the legal term that should never have appeared, retaining the hyphen that an automated rule wanted to remove, rewriting the label that cannot fit and checking the final output in the workflow where somebody will rely on it.

The best defence is not more prose. It is a disciplined connection between source meaning, structured evidence, interface context and human review. Translation makes the words available. Localisation makes them usable. Documentation makes them accountable.