Skip to content
When Terminology Inconsistency Becomes a Real-World Problem
By Vedat Güven — Mechanical Engineer, Technical & Quality Advisor — Alafranga Language Solutions
Across a career spanning aerospace and defence, oil and gas, energy, automotive, and heavy industry, he has held active roles in supplier quality assurance, quality management, QA/QC, test and verification systems, non-destructive testing (NDT), HSE, and international audits.



Translation errors in technical documentation tend to be discussed in the abstract. Accuracy matters. Consistency is important. Terminology should be verified. These are correct statements, and they are also statements that are easy to agree with and easy to ignore — because the consequences they describe are distant, hypothetical, and someone else's problem.
 
This article is about what happens when the consequences arrive.

The cases below are drawn from real projects — situations I have encountered directly or that were brought to us because a previous translation had created a problem that needed to be resolved. Details have been anonymised. The underlying pattern in each case is the same: a terminology decision that seemed inconsequential at the point of translation produced a concrete, costly problem at the point of use.
 
What terminology inconsistency actually means
Before the cases, a clarification. Terminology inconsistency in technical translation is not the same as a translation error in the ordinary sense. It is not a word translated incorrectly. It is a word translated differently in different places — sometimes across documents, sometimes within a single document, sometimes across a product line that was translated in multiple batches over several years.
 
A machine has a component. In the original German documentation, that component has one name — consistently, across the installation manual, the operating instructions, the maintenance schedule, and the spare parts catalogue. In the Turkish translations of those documents, produced by different translators at different times without a shared glossary, the component has three names. Each name is a defensible translation. Each name refers to the same physical object. And a Turkish technician who reads the maintenance schedule, then turns to the spare parts catalogue, encounters a term that does not appear in the maintenance schedule and has to determine whether it refers to the same component or a different one.
 
This is terminology inconsistency. It is invisible to anyone reviewing the translations individually for accuracy. It is visible — and consequential — to the person using the documentation in the field.
 
Case one: the pressure relief valve that wasn't
A European manufacturer of industrial fluid handling equipment had a product line sold across several markets, including Turkey. The Turkish documentation had been produced over several years, with different translators handling different document types. The installation manual, the operating instructions, and the maintenance schedule had each been translated separately, with no shared glossary and no cross-reference between projects.
 
The component in question was a pressure relief valve — a safety-critical component whose function is to release pressure when it exceeds a defined threshold, preventing overpressure conditions in the system.
 
In the German source documentation, the component was consistently referred to by a single compound term. In the Turkish translations:
The installation manual used basınç tahliye vanası — pressure relief valve, a direct and accurate rendering.
 
The operating instructions used emniyet ventili — safety valve, a term that in Turkish technical usage refers to the same category of component but carries a slightly different technical emphasis and is associated with a different set of standards.

The maintenance schedule used tahliye valfi — relief valve, dropping the pressure qualifier and using the English loanword valf rather than the Turkish vana.

Three terms, one component. For an experienced Turkish engineer, the ambiguity was resolvable — context made clear what was being referred to. For a maintenance technician following a procedure step by step, the maintenance schedule's instruction to inspect and test the tahliye valfi at defined intervals did not obviously connect to the basınç tahliye vanası described in the installation manual. The technician followed the maintenance schedule. The component described in the installation manual — which carried the pressure relief function the safety procedure was designed to protect — was not the component the technician understood the schedule to refer to.
 
The overpressure event that followed was minor in consequence but not in cost. The investigation identified the documentation inconsistency. The manufacturer's liability position was complicated by the fact that the maintenance documentation did not unambiguously identify the safety-critical component.
 
We were brought in to audit the full Turkish documentation set and produce a unified glossary. The audit identified forty-seven instances of inconsistent terminology across the product line — components, procedures, and safety instructions referred to by different terms in different documents. None of the individual translations were wrong in the conventional sense. The inconsistency was the problem.
Such concordance issues also occur when various machine translation engines are used on the same text or due to some technical constrains when a long text is divided into sections and each section is given to machine translation engines at different times. In these instances, translation engines may prefer to use different equivalents.
Case two: the torque specification that changed units
A German machinery manufacturer supplied industrial equipment to a Turkish systems integrator. The equipment included assembly instructions specifying torque values for fastener tightening — standard content in machinery installation documentation, and content where the values matter precisely because under-torquing creates loose connections and over-torquing creates component failure.

The original German documentation expressed torque in Newton-metres, as is standard in European machinery documentation. The Turkish translation of the assembly instructions was produced by a general technical translator who was not a specialist in machinery documentation. The translator used the correct Turkish term for Newton-metre — Newton metre or N·m — but in several places rendered the unit as kgf·cm — kilogram-force centimetres — applying a unit conversion that was arithmetically correct  but was not present in the source document and was not flagged as a conversion.
 
The Turkish assembly team, working from the translated instructions, encountered torque specifications in two different units within the same document. Assuming the original document was internally consistent, they interpreted the kgf·cm values as authoritative for those specific fasteners and applied them accordingly. The conversion had introduced a systematic error — the kgf·cm values, while arithmetically equivalent to the original Newton-metre values, were expressed at a different order of magnitude that created ambiguity about how they should be applied with the torque tools available on site.
 
Several fasteners were incorrectly torqued. The error was identified during commissioning inspection, before the equipment entered service. The rectification required partial disassembly and re-torquing — a delay of several days on a project where the commissioning timeline was already constrained.
 
The translator had not intended to introduce an error. The unit conversion was, in isolation, correct. The problem was that the conversion was applied inconsistently, without flagging, and without understanding that introducing a second unit system into a document that the source used only one unit system was a substantive change to the document — not a translation decision.
Case three: the safety instruction in the wrong register
This case is different in character from the others. It is not about a specific terminology inconsistency but about a register problem — a mismatch between the level of formality and directness of a safety instruction in Turkish and what the instruction needed to communicate.

A European manufacturer of power tools had safety instructions translated into Turkish for distribution with a product line sold in Turkey. The safety instructions followed a standard format: signal word, hazard description, consequence statement, avoidance instruction.
 
The source language — English — used the imperative directly and unambiguously. Do not operate the tool without eye protection. Failure to do so may result in serious eye injury. The instruction is straightforward. It is designed to be blunt. Safety instructions in English-language technical documentation are written to be direct, unambiguous, and to communicate consequence clearly.
 
The Turkish translation used a register that was technically correct but tonally misaligned with the source. The translator, working to produce natural Turkish, rendered the avoidance instruction in a form that was grammatically softer than the imperative — a construction that in Turkish communicates a recommendation rather than a mandatory requirement. The consequence statement was similarly softened, using a formulation that in Turkish implies possibility rather than the more direct risk communication of the English source.
 
The translation read naturally. A Turkish reader would find nothing jarring about it. But it did not communicate the same degree of urgency and mandatory compliance that the English source was designed to communicate — and that the applicable safety standards required the instruction to communicate.
 
When the product was reviewed during a market surveillance exercise, the safety instruction register was flagged. The reviewer's assessment was that the Turkish instructions did not meet the communication requirements of the applicable standard for safety instructions — not because the content was wrong, but because the register did not convey the required level of obligation and consequence.
 
This is a subtler failure than a factual error. It is also, in some ways, harder to prevent — because the translator's instinct to produce natural-sounding Turkish worked against the requirement to reproduce the communicative force of the original. Knowing that safety instructions require a specific register in Turkish, and that the register is defined by the applicable standards, is not knowledge that a general technical translator necessarily has.
The common thread
Three cases. Three different failure modes. One underlying cause.
In each case, the translation was produced without sufficient context about how the document would be used — by whom, in what conditions, against what standards, with what other documents. The translator's job was defined as producing accurate Turkish text. It was not defined as producing documentation that would function correctly in the operational and regulatory environment in which it would be used.

This is the gap between translation as a language task and translation as a documentation task. Language accuracy is necessary. It is not sufficient. Technical documentation functions within a system — a system of standards, of procedures, of trained users, of regulatory requirements, of other documents in the same product set. A translation that does not account for that system can be linguistically correct and operationally wrong.
What prevents these failures
None of the cases above required exotic expertise to prevent. They required specific, applicable knowledge applied at the right point in the process.
 
A shared glossary, maintained across a product line and applied to every translation project within that line, prevents the component naming inconsistency of case one. It is not a complex instrument — it is a document that says: this component is called this, consistently, everywhere. Building it requires an initial investment of time. Maintaining it requires discipline in project management. Not having it is a decision to accept inconsistency as a structural feature of the documentation.
 
A translator who knows that introducing unit conversions not present in the source document requires explicit flagging and client approval prevents the unit inconsistency of case two. This is a process requirement, not a knowledge requirement. It requires a briefing, a checklist, and a review step that catches undocumented changes to the source content.
 
A translator with specific knowledge of German and Turkish maintenance vocabulary — who knows what Sichtprüfung communicates in a German maintenance context and what Turkish equivalent would communicate the same thing to a Turkish service technician — prevents the procedure ambiguity of case three. This is the knowledge requirement. It cannot be substituted by fluency alone.
 
A translator who knows the register requirements of Turkish safety instructions under the applicable standards — and who understands that natural-sounding Turkish is not the criterion for safety documentation, compliant-sounding Turkish is — prevents the register failure of case three. This too is a knowledge requirement, and it is one that requires familiarity with Turkish technical standards, not just with Turkish.
The cost calculation
The three cases above produced, collectively: a market surveillance incident and a liability investigation, a commissioning delay of several days on a constrained project timeline, a warranty dispute complicated by ambiguous maintenance records, and a market surveillance flag requiring documentation revision before the product could continue to be distributed.

None of these outcomes were catastrophic. All of them were more expensive than the cost of translation done correctly the first time.

This is the calculation that is difficult to make in advance — because the cost of incorrect documentation is contingent and deferred, and the cost of correct documentation is immediate and visible. A translation that costs more because it includes glossary management, standards terminology verification, and domain-specialist review looks like a higher line item than a translation that does not include these things. It is a higher line item. What it is not is a higher total cost.
 
We have been producing Turkish technical documentation for European manufacturers since 2002 — for clients including ExxonMobil, Rolls-Royce, Siemens Gamesa, Daikin, Zeiss, and Mitutoyo. In that time, we have audited documentation sets that contained all three of the failure modes described above, and others. The pattern is consistent: the failures are predictable, the prevention is known, and the choice between them is made — usually without full awareness — at the point of commissioning.

▮Further readings:
Why Translating from English into Turkish Is Harder Than Most Briefs Assume