Software translation looks deceptively simple from a distance. Put the interface strings in a table, send them through a translation system, import the results and move on. That approach can produce words in another language. It cannot guarantee that those words fit the interface, preserve the intended meaning or support the way evidence must travel through a real project.
Wissen & Sprache · Localisation as engineering
Translating is not localising
Lessons from shipping construction software across languages, interfaces and connected project records.
Every label must preserve its function while fitting mobile screens, browser workspaces and reports.
Terminology, short labels, regional distinctions and edge cases remain after automation completes most of the volume.
Regional choice spans the EU, US and Asia, including mainland China—but changing providers does not replace product-level review.
Field captures site evidence, Studio works with plans and models, and Cloud coordinates operational and model data.
Small details, operational consequences
A translator invented legal terminology in the KVKK case. Reduplication hyphens required different handling in Malay and Indonesian. Accurate text could still exceed character budgets. Each failure looked minor; each could change how a record was understood or used.
The decisive test is not whether a sentence sounds polished. It is whether the documented event remains clear from capture to report.
Gewerkton offers a useful field report on the difference. The voice-first construction documentation and defect management platform supports 27 content languages and is being developed for global markets. It was born in the German market, where its commercial integration is deepest through GAEB, REB, XRechnung and DATEV, but its intended operating range extends across Europe, the United States and the Asia-Pacific region.
The language work has exposed problems that ordinary translation briefs rarely anticipate: a translator quietly inventing legal terminology, reduplication hyphens behaving differently in Malay and Indonesian, translated text exceeding interface character budgets, and large language models completing most of a job while still failing at the final ten per cent. These are not merely linguistic curiosities. In construction documentation, a small change in wording can alter how a record is understood, sorted or used.
The wider lesson is that localisation is a form of engineering. It concerns language, but also interface constraints, regional expectations, data handling and the structure of the underlying record. For a system built around site evidence, the decisive question is not whether a sentence sounds polished. It is whether the documented event remains clear from capture to report.
Overview of Translation Tools – Benefits of Translation Memory Management Software for an International Company
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Translation changes words; localisation protects meaning
A translated interface may be grammatically correct and still be operationally wrong. Construction vocabulary is particularly exposed because apparently familiar words can carry specialised meanings. A term may refer to a contractual category, a commercial process, a site instruction or a particular kind of record. Replacing it with the nearest dictionary equivalent can create a sentence that reads smoothly while pointing to the wrong concept.
The KVKK incident illustrates the danger. A translator quietly invented legal terms rather than preserving the required meaning. The problem was not conspicuous nonsense. It was language that could pass as authoritative. That makes it more hazardous than an obvious mistranslation, because fluent wording invites trust.
This is one reason localisation cannot be judged by fluency alone. A reviewer must ask where a term came from, what function it serves and whether the translated version introduces a claim that the source never made. Legal-looking language deserves special caution: a translator should not fill a conceptual gap by creating terminology that merely sounds plausible.
Language models do not remove that risk. They can generate convincing prose at speed, but confidence and correctness are different properties. “Just run it through an LLM” works until the remaining errors are concentrated in the places where precision matters most. The last ten per cent includes terminology, short labels, regional distinctions and awkward edge cases. It is smaller in volume, but often larger in consequence.
Malay and Indonesian show why small marks matter
Localisation failures are not confined to grand questions of law or technical vocabulary. A hyphen can expose them. Reduplication in Malay and Indonesian brings its own conventions, and treating the two languages as interchangeable can produce incorrect or unnatural results. The words may appear close enough to tempt reuse, yet their written handling still requires language-specific attention.
This is the sort of issue that disappears inside a translation percentage. A dashboard might report that every source string has a target-language value. It cannot reveal whether punctuation is performing the right linguistic function. Completeness at the database level is not the same as correctness for the reader.
The example also challenges the assumption that related languages can share a single localisation treatment. Similarity can help with comprehension, but it can also conceal distinctions. When forms look familiar, reviewers are less likely to stop and question them. Localisation therefore needs explicit checks for the details that automated pipelines tend to regard as incidental: hyphens, repeated forms, abbreviations and the relationship between a label and the action it triggers.
For curious readers outside software engineering, this is the heart of the discipline. Language is not a decorative layer placed on top of a finished product. It is part of the product’s behaviour. A button, heading or report field guides a person toward an action. If its wording is subtly wrong, the interface itself behaves differently.
Character budgets are part of language engineering
English and German already demonstrate that equivalent ideas do not occupy equivalent space. Across 27 content languages, the variation becomes a design constraint. A concise source label may expand after translation, wrap onto a second line, collide with another control or overwhelm a narrow mobile view. The translation can be accurate and the interface can still fail.
Character budgets are therefore not an afterthought. They belong in the localisation process from the beginning. Short interface strings need enough context for a translator to understand their purpose, but the resulting wording must also fit the place where it will appear. A label for an action is not interchangeable with a heading, a status or a sentence in a report, even when the source text uses the same word.
This matters especially for site software. Gewerkton Field is the voice-first construction site app, covering dictation to evidence, defects, daywork reports, takt and a portal. Its language must work where records are captured, including distributed renewable-energy sites, rotating crews and offline work in dead zones. A translated phrase that only works comfortably on a large screen is not fully localised for that setting.
The same constraint appears differently in a browser workspace. Gewerkton Studio is used for plans and models; where no model exists, the site team can create one in the browser. Here, language sits alongside spatial material. Long labels compete with plans, model views and the practical need to keep information visible.
Gewerkton Cloud coordinates operations and model data between Field, Studio and third parties. That movement between contexts makes consistency essential. A concept should not acquire a new meaning merely because it has travelled from the site app to a browser workspace or an external party.
Why the final ten per cent resists automation
Gewerkton supports bring-your-own AI across 13 providers. Users can bring their own keys and select providers by region, including the EU, the US and Asia, with mainland China included. That range avoids dependence on a single AI vendor and reflects the realities of multinational projects. It does not imply that one automated pass can settle every language question.
Different AI systems may be useful within the same broad workflow, but output still has to meet a stable product standard. A fluent translation can be too long. A compact translation can be too vague. A technically plausible phrase can be unsupported. A familiar form can be wrong for a neighbouring language. None of these failures is solved simply by changing providers.
The difficult remainder also includes consistency over time. Construction documentation accumulates. Instructions, defects, photos, deadlines, dictated reports and meeting decisions do not exist as isolated paragraphs. They become a connected project record. If terminology shifts between screens or reports, the reader must determine whether two labels describe the same thing. That uncertainty is precisely what structured documentation should reduce.
The practical role of AI is therefore bounded. It can accelerate production across many languages, but the localisation system must still detect where automation is least trustworthy. The final review is not ceremonial polishing. It is the stage at which linguistic output is tested against interface space, product function, regional use and the meaning of the underlying evidence.
Structured evidence beats prose notes
A prose note is flexible, but that flexibility can hide ambiguity. It may mix an observation, an instruction, a deadline and a responsible trade in one paragraph. The author remembers the context at the moment of dictation. Another person reading it later may not.
Structured evidence separates those elements. In housing and building construction, a defect can be documented with a photo and deadline. Daywork reports can be dictated, and a signature can be captured on the device at handover. In data centres and industrial plants, where many trades operate in parallel under tight deadlines, meeting decisions can become trade-sorted task lists. Structure turns language into fields that can be followed through a process.
This is the documentation angle behind the marketing line, “On site, what counts is what’s proven.” The line is less about producing more text than about preserving a usable chain of evidence. A polished paragraph is not automatically stronger than a shorter record with the relevant photo, deadline, original audio or signature attached to the right event.
Infrastructure and tunnel projects make the distinction especially visible. These projects can run for long periods and involve many change orders. Instructions backed by original audio retain a direct connection to what was captured. Translation can make the content accessible to more participants, while the evidence original remains available rather than being replaced by a newly written summary.
That principle is equally important for cross-border teams. EU, US and Asia-Pacific participants can work on the same project in their own languages while the original evidence remains unambiguous. Chinese, Korean and Vietnamese crews can move from multilingual capture to report, with data residency selected for the project. The system offers an EU cloud or deployment on the user’s own infrastructure.
Localisation extends beyond the interface
A global product cannot treat language, AI-provider region and data residency as unrelated settings. They meet in the same workflow. A crew may capture information in one language, another party may receive a report in another, and the project may require a particular infrastructure choice. Localisation must account for that combination without altering the original evidence.
The Gewerkton platform brings those concerns together across Field, Studio and Cloud. The underlying idea is not that every market should receive identical words. It is that each participant should be able to understand the record while the record itself remains anchored.
The public-facing site provides another, narrower example of engineering choices shaping language delivery. It is available in 27 languages, uses zero trackers, requires no cookie banner and has a fully egress-free architecture. Its media bank contains more than 51 self-produced clips and posters. Those facts do not solve terminology or interface-fit problems, but they show that multilingual publishing involves more than generating translated paragraphs.
The development method is also unusual. 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 scale that agent-assisted development can reach. It also sharpens the localisation lesson: rapid production makes verification more important, not less.
A beta product and an unfinished language problem
Gewerkton is in beta now, with a public beta planned for fall 2026. That status should be stated plainly because localisation across 27 content languages is not evidence of a finished product. It is evidence of the scope being tested.
The most valuable lesson from that work is methodological. Translation output should not be accepted merely because it is complete, fluent or generated by a capable model. It has to survive several different tests. Does the terminology preserve the source meaning? Does punctuation follow the conventions of the specific language? Does the text fit the interface? Does a translated record remain connected to its evidence original? Can the same concept travel consistently between capture, model, report and third party?
These tests explain why the last ten per cent remains stubborn. It is where language stops being bulk content and becomes product behaviour. Errors there are often small enough to evade a quick review and important enough to misdirect a reader.
For construction documentation and defect management, the answer is not to rely on longer prose. It is to create structured records whose components remain identifiable across languages: the event, the evidence, the responsible trade, the deadline and, where applicable, the original audio or signature. Translation can then serve understanding without silently rewriting what happened.
Shipping 27 content languages is therefore not a victory measured by the number 27 alone. The meaningful achievement is making those languages work inside real constraints while resisting invented certainty. Localisation succeeds when readers can act in their own language and still refer to the same documented reality.
