Create translations with terminology and style control

A fluent translation can be factually wrong. A translation that uses consistent terminology can reverse the meaning of a sentence. An accurate version can still become confusing inside the actual form because its label is clipped or its relationship to the action is unclear. Reliable translation therefore requires separate checks of meaning, terminology, style and the context in which the text will be used.

This guide develops a practical workflow for German source material and English target versions. Its examples are original teaching texts rather than extracts from a client assignment. A small executable terminology checker demonstrates both its usefulness and its boundary. It identifies missing agreed words. It does not assess complete translation quality. Sources were checked on 9 November 2026.

Define the translation assignment first

Before drafting, establish the audience, language variety and purpose of the text. English for a British professional audience may require different decisions from English used in an international interface whose readers mostly have another first language. These choices affect vocabulary, spelling and expectations about tone and information density. Simply requesting an English translation leaves them unresolved.

The purpose belongs explicitly in the brief. A button must identify an action. Technical instructions must preserve conditions and sequence. A service description must accurately communicate what is included. A personal comment can support a different rhythm from an error message. Consistency does not require every kind of text to sound identical. It requires decisions that make sense for the role each text performs.

Record what must remain unchanged, including product names, code identifiers, file formats and agreed specialist terms. Give particular attention to numerical values, negation and prerequisites. Identify who resolves uncertainties in the source and who approves the target version's subject matter. A translation tool should not replace a missing factual decision with a plausible addition. The clearer these responsibilities are, the easier it becomes to distinguish a language question from a question about the product itself.

Organise terminology around concepts

A terminology collection is more than a table with two columns of words. A source word can refer to different things. German Anfrage can mean an informal contact, a technical query or a formal request. Without a definition, consistent translation can be consistently wrong. Each entry therefore needs a concept description and an appropriate context.

For a particular assignment, enquiry may be agreed for an informal contact. A database operation would call for query instead. Record that decision with a short definition and an example sentence. An alternative is not necessarily wrong in every setting. It may simply be inappropriate for this concept or this assignment. This distinction prevents a glossary from becoming an unjustified list of universally forbidden words.

Record permitted inflections, capitalisation and abbreviations as well. A checker needs to know whether an exact form is required or several variants are equally acceptable. Editorial judgement precedes automation. A simple matching rule can execute a well-defined decision. It cannot reliably repair the subject matter of a poorly defined entry. Review the concept whenever two apparently equivalent translations imply different functions, responsibilities or commitments.

A small glossary for the teaching example

This glossary applies only to the controlled sentences below. In particular, it establishes no universal rule that Webseite must always become website. Depending on the object being described, page may be required in another context. The meaning selected here is explicit so that the automated check receives an unambiguous task.

The German source is: Die Webseite zeigt den Preis. Senden Sie eine Anfrage. The intended English version is: The website shows the price. Send an enquiry. This is deliberately a short, simple starting point. An actual assignment would add information about the audience, interface and service scope. The example is designed to expose the difference between finding vocabulary and understanding a sentence.

Execute a formal terminology check

The following code operates on individual words. It normalises Unicode characters to NFC and compares without distinguishing capitalisation. It extracts sequences of letters and numbers from the texts. If an agreed source word appears, the corresponding exact target form must appear in the target text. The returned result contains identifiers of missing target forms.

The rule is intentionally narrow. It recognises neither multiword terms nor inflection or relationships between meanings. The word websites does not satisfy the exact requirement website. Conversely, a word used in an unrelated factual context can satisfy the presence check. This is an inspectable teaching checker for the small glossary, not a general language-processing system or translation approval mechanism.

const glossary = [
  { id: 'website', source: 'Webseite', target: 'website' },
  { id: 'price', source: 'Preis', target: 'price' },
  { id: 'enquiry', source: 'Anfrage', target: 'enquiry' }
];
function words(text) {
  if (typeof text !== 'string') throw new TypeError('Text required');
  return new Set(text.normalize('NFC').toLowerCase().match(/[\p{L}\p{N}]+/gu) ?? []);
}
function missingTerms(source, target) {
  const sourceWords = words(source), targetWords = words(target);
  return glossary.filter(term => sourceWords.has(term.source.toLowerCase()) &&
    !targetWords.has(term.target)).map(term => term.id);
}
const source = 'Die Webseite zeigt den Preis. Senden Sie eine Anfrage.';
const variants = [
  'The website shows the price. Send an enquiry.',
  'The homepage shows the prize. Send a request.',
  'The website does not show the price. Never send an enquiry.'
];
console.log(variants.map(target => missingTerms(source, target)));

In the executed check, The homepage shows the prize. Send a request. lacks all three agreed target forms. The intended version passes the presence check. Capitalised forms and punctuation do not alter the result in this implementation. These observations concern the implemented word rule alone. They do not establish accuracy, completeness or stylistic suitability beyond that rule.

Why passing a vocabulary check is insufficient

The crucial counterexample is: The website does not show the price. Never send an enquiry. All three agreed words occur. The formal checker therefore reports no missing target form. Nevertheless, the sentence contradicts the German source. It denies that the price is visible and reverses the invitation to make contact.

This distinction must remain clear in the editorial workflow. No terminology warning means only that this word rule produced no finding. It does not mean that the translation is accurate, complete or appropriate in style. A green indicator labelled translation correct would misrepresent what this checker has established. The interface should name the check it actually performed rather than imply a broader approval.

The native explanation in this article reproduces the code's actual results. It compares the intended version, a version missing the target forms and the semantically wrong counterexample. The final version is particularly important because it stops visible automation being mistaken for a complete quality assessment. A tool can be useful while remaining unsuitable for the final judgement.

Compare meaning with the source

Read source and target together when checking meaning. First establish who acts, what happens and under which conditions the statement applies. Then review negation, quantities, time references and qualifications. A small change involving may, must or only can substantially alter the service scope even when the rest of the sentence sounds natural.

For instructions, check sequence. A preparatory step must not appear after an action that depends on it. For product descriptions, compare promised functions with the actual service. More elegant wording is not an improvement when it introduces another guarantee or a function that does not exist. A plausible addition can be harder to notice than an obviously awkward sentence.

Record ambiguous passages as factual questions. The best response to an unclear source is not always the smoothest possible target sentence. Sometimes the original must be clarified first. Preserve the decision so that comparable passages can reuse it later. Consistent specialist language then grows from resolved meaning rather than repeated phrasing. Where the answer changes the original claim, review both language versions rather than silently improving just one.

Describe style through observable decisions

A style brief needs rules that can be examined. Instead of modern and professional, it might specify direct verbs, concise instructions, no artificial urgency and no additional success promises. A technical guide may call for a factual voice, while a personal introduction can retain more individual expression. The aim is a suitable relationship with the reader, not the mechanical removal of personality.

Explain how politeness and address should work. The distinction between German Du and Sie cannot be reproduced through a single English substitution. In English, tone depends more heavily on sentence structure, vocabulary and the balance between explanation and instruction. A mechanical counterpart can miss the intended character even when every individual word is defensible.

Use a few approved comparison sentences. Show the desired decision and explain why it fits the situation. An example for a button does not need to determine the voice of an entire technical article. Examples should narrow the context. A large rulebook without clear priorities can be more contradictory than a concise, well-reasoned agreement. If two rules conflict, identify which purpose takes precedence rather than expecting a tool to invent a policy.

Plan translation and localisation together

The W3C distinguishes language transfer from the broader adaptation needed for a target context. In practice, this includes number, date and currency presentation. An accurately translated sentence can still contain a number that the intended audience reads differently. Treat the numerical value and its displayed form as separate concerns.

When formatting a price, software should work with an actual number and an explicitly chosen currency. JavaScript's Intl.NumberFormat supports language-sensitive number presentation. Formatting does not decide which currency applies and performs no currency conversion. Mechanically replacing punctuation in a German string creates risks that are more substantial than a stylistic inconsistency. Preserve the value as data and apply a defined display convention.

For dates, determine whether the content represents a calendar day or a particular instant. Translation must not quietly invent a time zone. Even a short contact detail needs context because address order and country naming can depend on the intended market. Treat these as separate review tasks rather than silently delegating them to a language model. A readable sentence is not evidence that its embedded data has been interpreted correctly.

Review the actual interface

Translations are read in their intended layout. Check headings, buttons, error messages and options in the actual surrounding interface. Text can become longer and wrap differently. An isolated sentence in a spreadsheet does not show whether its relationship to the adjacent input remains clear. A shorter translation is not automatically preferable if it removes the information needed to act.

Combined messages are especially sensitive. If software assembles several translated fragments into a sentence, word order and grammar may become inappropriate. Complete messages with clearly defined placeholders are often easier to translate. Every placeholder needs a description of the kind of content inserted. A person's name creates different requirements from a number or filename. Review real substitutions rather than assuming that the placeholder's short identifier represents the final width or grammar.

Language metadata also belongs in technical review. W3C guidance recommends declaring the default language on the html element and marking passages in other languages appropriately. These declarations do not replace accurate translation. They describe the language the content uses. An English page carrying a blanket German declaration should therefore not pass review solely because its visible sentences read well.

Give AI a bounded assignment

A useful working instruction contains the original, audience, language variety, text function, approved terminology and immutable content. Ask the model to identify uncertainties separately. It should not resolve unanswered factual questions by inventing claims. For a longer document, agreeing a short section first can establish the decisions before applying them to the remaining material.

Review the resulting draft independently of the tool that produced it. Do not replace comparison with a persuasive self-assessment. A list of supposedly followed rules does not demonstrate that the text follows them. Formal word checking can provide particular findings. Subject review still needs to examine meaning and the actual use case. Treat a proposed rewrite as another version to evaluate, not an automatic correction.

For confidential material, establish the permitted processing route beforehand. The availability of a tool does not imply permission to transfer arbitrary client documents. The teaching checker here needs no external text service. Using a particular translation service remains a separate organisational decision with a defined data scope. The terminology workflow should be designed so that its essential review decisions remain understandable independently of a particular provider.

Record approval through separate checks

• Is the source unambiguous and the translated scope complete?
• Are action, condition, negation and time reference preserved?
• Do specialist terms match the defined concept and glossary?
• Are language variety, address and tone consistent?
• Are product names, identifiers and placeholders preserved where agreed?
• Are numbers, currency and dates presented correctly for the context?
• Does the version work in the actual interface?
• Have automated findings been reviewed with their limits understood?
• Is the person responsible for the subject decision recorded?

Do not turn these checks into a supposedly objective combined grade. A wrong word can be minor or alter the entire service scope. One serious meaning error must not be offset by numerous passed formal checks. Decide according to the significance of the finding rather than the number of green indicators. The approval record should identify what was reviewed instead of presenting a decorative score whose calculation hides important failures.

Maintain translations when the source changes

An approved translation belongs to a particular source version. When the German service description changes, the affected target text needs another review. Updating a date is insufficient. Internally identify the changed passages and the terminology decisions they affect. This avoids retranslating an entire document unnecessarily while keeping substantive changes visible.

A glossary change can also affect several texts. Searching for the old form is a starting point, not a completed correction. Review each occurrence in context. A term may intentionally remain in a historical description or technical identifier. Blanket replacement can damage previously correct passages. Treat exceptions as explained decisions rather than errors to be removed automatically.

Preserve the reasoning: original question, approved wording, justification and text type. This makes later maintenance and handover easier. Quality comes from a stable relationship between subject meaning and understandable language. A tool supports the work when its particular findings remain distinguishable from the actual approval decision. The workflow is strongest when another qualified person can reconstruct why a wording was chosen without guessing what the previous editor intended.

Prepare an inspectable review package

Give the reviewer a clear source version, target version, brief and relevant glossary entries together. Interface text also needs the actual view. Separate factual questions from spelling or stylistic findings so that the appropriate person can decide them. Read the target independently as well as alongside the source: independent reading exposes unclear references, while comparison protects meaning. Neither perspective replaces the other. Record the version and views covered by approval so later changes reopen the affected scope rather than inheriting an unlimited quality label.

Sources and the example's scope

The W3C explains localisation and internationalisation as related activities involving language and other requirements of the target context. The terminology category in ITS 2.0 supports identifying terms and linking associated information. Our small checker does not implement that standard.

The guidance on declaring language in HTML and the MDN documentation for Intl.NumberFormat address the technical subtasks described here. The executed vocabulary tests assess neither style nor semantic accuracy. The deliberately wrong counterexample demonstrates why passing a terminology check is not translation approval.