A translator quietly invents a legal term. A hyphen disappears from a Malay or Indonesian reduplication. A perfectly accurate phrase becomes too long for the interface designed to display it. None of these problems looks dramatic in isolation. Together, they reveal why shipping software in 27 content languages is not a matter of replacing one set of words with another.
Wissen & Sprache · Language engineering
Translating is not localizing.
What Gewerkton’s 27 content languages reveal about preserving construction evidence across legal terms, grammar, interfaces and AI providers.
Fluent text is only the beginning. Meaning, structure and usability must survive every screen and every later record.
The KVKK incident
A translator quietly invented legal terminology. The sentence sounded authoritative—but fluency concealed a change in meaning. A translator had become an unseen author.
The consequential hyphen
Malay and Indonesian reduplication shows why punctuation is data. Dropping or normalising a hyphen can make familiar-looking words wrong—and carry that distortion into reports and handover records.
Correct—and unusable
An accurate label can still wrap, collide or overwhelm a compact site screen. Localisation must answer two questions: “Is it right?” and “Is it right here?”
The resistant final 10%
LLMs generate candidates quickly. They do not establish suitability for a legal context, character budget or evidence trail. The hard remainder requires constraints, review and testing.
The record must keep its relationships
A polished paragraph cannot repair a broken evidence chain. For construction documentation, structured evidence beats prose notes.
It is language engineering: the work of preserving meaning, structure and usability while terminology moves between legal contexts, writing systems, regions and constrained interfaces. The final ten per cent is where the comfortable promise of automatic translation tends to break down. A large language model can produce fluent text quickly. Fluency, however, is not the same as localisation, and localisation is not the same as dependable project documentation.
That distinction becomes especially sharp on construction sites. Notes are not merely read; they may become evidence, defects, daywork reports, instructions, deadlines or handover records. The original observation must remain connected to the right trade, place, plan, photograph, audio and action. A polished paragraph cannot compensate for a broken relationship between those elements.
This is the language-engineering problem behind Gewerkton, a voice-first construction documentation and defect management platform for global markets. Born in the German market, it has its deepest German commercial integration through GAEB, REB, XRechnung and DATEV. At the same time, its content spans 27 languages, and its AI providers can be selected by region across the EU, the US and Asia, including mainland China.
The product is in beta now. A public beta is planned for fall 2026.
Spanish Legal Conversation (Quick Study Language)
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
The KVKK incident: when fluency conceals invention
The most dangerous localisation errors are not always conspicuous. A visibly broken sentence invites review. A smooth, authoritative sentence may pass unnoticed even when one of its terms has been invented. That is what makes the KVKK incident instructive: a translator quietly introduced legal terminology rather than preserving the intended term faithfully.
The lesson is not simply that translators make mistakes. The deeper problem is that fluent language can create false confidence. Legal and regulatory terminology is especially vulnerable because readers expect it to sound formal, and formality can disguise a change in meaning. A plausible expression may look more finished than a literal or carefully qualified one, even though the plausible expression is the less dependable choice.
An LLM faces the same temptation at greater speed. Asked to produce natural language, it tends towards completion. If a source term is ambiguous, unfamiliar or regionally specific, the model may resolve the uncertainty by generating wording that sounds coherent. That behaviour is helpful for drafting ordinary prose. It is hazardous when the term belongs to a compliance context or is attached to project evidence.
The remedy is not to reject automation. It is to stop treating fluent output as proof of correctness. Terms with legal, contractual or technical weight need controlled handling. Review must ask whether meaning was preserved, not merely whether the sentence reads well. The KVKK incident matters because it exposes a category error: a translator was allowed to act as an unseen author.
Nishiyuenyi Auto Tool Reader Engine Fault with Pp Construction Multilingual Function Suitable
- Package Includes: 1 auto tool for users and professionals
- Compact and Ergonomic: Small size with easy grip and 83cm rope
- Multilingual Support: Supports 13 languages for global use
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Malay and Indonesian expose punctuation as data
Localisation failures also occur below the level of vocabulary. Malay and Indonesian reduplication makes the hyphen consequential. When an automated process treats punctuation as decorative, normalises it indiscriminately or drops it during generation, the output can be wrong even though every remaining word appears familiar.
This is easy to overlook in a workflow built around strings. A phrase enters the system, a model produces another phrase, and a reviewer checks the broad meaning. Yet language is encoded not only in dictionary choices. Hyphens, spacing, repetition and word boundaries can carry grammatical information. The smaller the mark, the easier it is for a generic quality check to miss.
The Malay and Indonesian example therefore changes the definition of localisation quality. It is not enough to ask whether a reader can infer the intended message. Construction documentation is cumulative: a field observation may later appear in a report, a task list, a portal or a handover record. If small distortions are tolerated at capture, they can travel through every later representation.
A useful localisation system must consequently preserve more than prose. It must respect the formal features of each language and keep them stable as content moves through different screens and outputs. Punctuation cannot be treated as an expendable layer applied after meaning has been settled. Sometimes punctuation is part of the meaning.
Proofreading and Editing Precision (with CD-ROM)
- Condition: Used Book in Good Condition
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
A translation can be correct and still break the product
Character budgets reveal another divide between translation and localisation. Interfaces have physical limits. A label that fits neatly in one language may expand in another until it wraps, collides with a nearby control or overwhelms the hierarchy of a compact screen. The translation may be linguistically accurate and operationally unusable.
This problem is particularly important for a site app, where information must remain legible inside working interfaces rather than on an open page. Gewerkton Field is the voice-first construction site app: dictation becomes evidence, defects, daywork reports, takt information and portal content. Each destination imposes a different context on the language. A phrase that works as descriptive text may not work as a short action, status or navigation label.
Character limits are therefore not a cosmetic concern reserved for the end of a release. They belong in the translation brief. A localised term must be judged in place, at the width and hierarchy in which people will encounter it. The question is not just “Is this translation right?” but “Is it right here?”
That last word matters. Language does not enter software as an abstract document. It enters buttons, fields, menus, report sections and task structures. Testing only the exported strings ignores the product in which those strings must function. The interface is part of the linguistic context.
Independent Verification and Validation: A Life Cycle Engineering Process for Quality Software
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Why the last ten per cent resists “just use an LLM”
LLMs are attractive because they can cover large volumes of text and many languages quickly. They can help a small team move far beyond the throughput of a traditional, sequential workflow. Gewerkton itself 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.
That speed is real, but it does not eliminate the need for verification. Indeed, the use of negative controls and mutation tests illustrates the opposite: automation becomes more useful when its output is challenged systematically. Language deserves the same attitude.
The first large portion of localisation can look remarkably successful. Sentences are grammatical, terminology is mostly consistent and the overall message survives. The remaining portion contains the hard cases: the term that must not be improvised, the hyphen that carries grammar, the label that exceeds its character budget and the regional wording whose acceptability cannot be inferred from surface fluency alone.
This is why “just run it through an LLM” fails at the last ten per cent. The model can generate candidates, but generation does not establish that a candidate is suitable for a particular legal context, interface width or evidence trail. The final work involves constraints, review and testing. It is less spectacular than instant multilingual output, but it determines whether the output can actually be used.
Provider choice adds another layer. Gewerkton supports 13 AI providers through a bring-your-own-keys approach, with selectable regions in the EU, the US and Asia, including mainland China. This avoids vendor lock-in and allows regional choice, but it also makes a consistent language layer essential. Different providers must not turn the same underlying project record into incompatible meanings.
For documentation, structure matters more than elegant notes
The central editorial lesson is that structured evidence beats prose notes. A free-form note can sound clear while leaving critical relationships implicit. Who observed the issue? Which trade does it concern? Where does it belong? Is there a photograph, a deadline or original audio? What must happen next? A reader may reconstruct some of that context, but the document itself remains fragile.
Structured evidence gives each part a place. This does not mean prose is unimportant. It means prose should not carry the whole burden of the record. Language is strongest when it describes an observation while the surrounding system preserves its connections.
The three Gewerkton product lines divide that work without separating the evidence. Field handles voice-first capture on site. Gewerkton Studio provides the browser workspace for plans and models; where no model exists, the site team creates one in the browser. Gewerkton Cloud coordinates operations and model or data exchange between Field, Studio and third parties.
That arrangement matters for multilingual work because translation should not sever provenance. Cross-border teams in the EU, the US and APAC can work on the same project in their own languages while the evidence original remains unambiguous. The goal is not to pretend that every participant wrote the same sentence. It is to let them understand the same structured record without losing the original.
The marketing line captures the priority plainly: “On site, what counts is what’s proven.” Proof here does not come from making a note sound more formal. It comes from preserving what was captured and how it relates to the project.
Different projects stress the language layer differently
A 27-language system is not solving one generic multilingual problem. Deployment conditions change what must be preserved and where the weak points appear.
- Wind farms and renewable projects combine distributed sites, rotating crews, field acceptance and offline capture in dead zones. The record must survive conditions in which continuous connectivity cannot be assumed.
- Data centres and industrial plants have many trades working in parallel under tight deadlines. Meeting decisions need to become trade-sorted task lists, so language must remain attached to responsibility and action.
- Housing and building construction requires defects with photographs and deadlines, dictated daywork reports and signatures on the device at handover. A prose-only summary would blur the distinction between these record types.
- Infrastructure and tunnel projects run for long periods and involve many change orders. Instructions can be backed by original audio, retaining a direct connection to what was said.
- Cross-border projects may involve teams in the EU, the US and APAC working in their own languages while sharing one project. The translated views must not make the evidence original ambiguous.
- Projects in Asia may include Chinese, Korean and Vietnamese crews. Multilingual handling extends from capture to report, while data residency remains a choice.
These examples show why localisation cannot be reduced to a language menu. The same words participate in different operational structures: field acceptance, meeting decisions, photographs, deadlines, daywork, signatures, change orders and audio-backed instructions. Translation is one transformation among several, and it must not damage the record as that record moves.
Regional AI choice and data residency are separate questions
Language coverage often gets discussed as if it automatically settled where data is processed or stored. It does not. A Chinese, Korean or Vietnamese interface says nothing by itself about provider region or infrastructure location.
Gewerkton separates those choices. Its BYO-AI model covers 13 providers, with region selection across the EU, the US and Asia, including mainland China. Data can reside in an EU cloud or on the customer’s own infrastructure. That distinction is important for global teams because language, AI-provider region and data residency are related configuration questions, not synonyms.
The public-facing site follows a similarly explicit technical position: it is available in 27 languages, uses zero trackers, requires no cookie banner and runs on a fully egress-free architecture. Its media bank contains more than 51 self-produced clips and posters. The breadth of material increases the localisation surface, but it also makes consistency visible: terminology must hold across interfaces, explanations, clips and posters rather than within a single translated page.
What a serious language-engineering workflow learns
The practical lessons are compact, even if applying them is not.
- Protect terminology from invention. Fluency is not evidence that a legal or technical term has been preserved.
- Treat punctuation and orthography as meaningful data. The reduplication hyphens in Malay and Indonesian are not optional decoration.
- Test language inside the interface. Character budgets, wrapping and hierarchy can invalidate an otherwise correct translation.
- Keep the evidence original unambiguous. A translated view should improve access without replacing provenance.
- Structure records before polishing prose. Photographs, deadlines, trades, plans, signatures and original audio should not depend on a paragraph to remain connected.
- Use automation with verification. Fast generation expands reach, while controls and targeted review handle the difficult remainder.
The broader point reaches beyond construction. Any multilingual system that deals with consequential records must decide whether language is merely presentation or part of the information architecture. If it is treated as presentation, translation becomes a late-stage content task. If it is treated as architecture, terminology, provenance, interface constraints and regional processing choices enter the design from the beginning.
Shipping one product in 27 content languages makes that difference impossible to ignore. The headline achievement is not the number of translations. It is the attempt to keep evidence coherent as it crosses languages, interfaces, providers and project conditions. Translation can produce another sentence. Localisation makes that sentence usable. Language engineering ensures it still belongs to the right record.
