Translation guide for business buyers

Start with a decision-ready brief

The brief connects the text to a business purpose. A maintenance procedure, tender response and product landing page require different vocabulary and checking priorities. It should identify the document owner, subject field, intended readers and publication channel. The translation process provides the broader context for agreeing scope and handling questions.

A useful brief names the source language and each target language, including regional variants. It distinguishes an internal working document from material intended for publication or signature. A requested date should include the time zone and any intermediate approval point. File delivery, client review and publication are separate milestones; treating them as one deadline hides work that still needs an owner.

Commercial information belongs in the brief where it affects scope: purchase-order requirements, invoicing entity, authorised approver and the treatment of additional work. The technical owner should also identify material that must remain unchanged, such as model names, part numbers and contractual references. This prevents a translator from having to infer whether an unfamiliar expression is a brand or a mistranslation.

Prepare editable originals and a reference view

Editable source files usually make text extraction and reintegration more reliable. A PDF can be valuable as a visual reference, while the document or design file behind it supplies the editable text. Scans need a legibility check, and optical character recognition needs correction before a word count or translation starts. A decimal point lost in extraction can become a substantive error.

A file inventory should include names, versions, approximate volumes and dependencies. Text can sit in diagrams, screenshots, headers, footnotes, comments and linked spreadsheets. The owner should state which of these elements belongs in scope. An apparently short manual can contain many separate image labels that are invisible to the main document’s word counter.

Spreadsheet instructions should name the relevant sheets, columns and hidden content. Software exports need stable identifiers and protected placeholders. Slide presentations need a decision on speaker notes and embedded objects. File support should be confirmed with the provider before purchase; a familiar filename extension alone does not establish that every element can be processed safely.

Freeze the source and identify changes

A source freeze creates a known starting point. File names should distinguish approved source material from drafts, and a manifest should state which version is authoritative. Where the source remains in development, staged batches can be agreed, each with its own version and approval record. Sending successive attachments without a change log leaves both scope and responsibility unclear.

Later changes should be marked against the approved source, rather than hidden in a newly exported PDF. The project manager can then assess affected segments, cross-references and language versions. A changed warning may require revisions to several documents even if the amended sentence contains only a few words. Change size and review effort are different measures.

Supply terminology with context and ownership

A useful glossary records the source term, approved target term, definition, product context and any prohibited alternative. A list of isolated equivalents cannot show whether a word refers to a component, process or commercial role. Screenshots, diagrams and short usage examples help a linguist choose the right meaning and inflection.

Existing translations need an approval status. An obsolete manual can provide context without being suitable for reuse. The brief should rank conflicting references: current approved glossary, product documentation, style guide and historical translations. The translation glossary explains the distinction between terminology resources and translation memories.

One client terminology owner should resolve questions that affect several departments. Decisions should be recorded once and shared across language teams. If a preferred term changes during translation, the owner should identify whether earlier deliverables need updating. This keeps a terminology discussion from silently becoming an unpriced revision of an entire document family.

Explain readers, risk and publication context

Readers’ knowledge affects vocabulary and sentence structure. A technician may recognise an established abbreviation that would confuse a first-time user. The brief should distinguish specialist readers from customers, patients or employees. Product context also matters: a button labelled with one verb can require a different form in languages such as Russian, Polish or Bulgarian depending on whether it describes an action or a status.

Screenshots and navigation paths are particularly useful for software localisation. Context should identify variables, character limits and strings that appear together. Complete messages are generally easier to translate than fragments assembled at runtime. The developer remains responsible for explaining the assembly logic and testing the resulting interface.

Sensitive material needs an agreed handling method. Before transfer, the buyer should identify personal information, access restrictions and any limits on reuse or machine processing. Contractual arrangements and actual project instructions should agree. No particular hosting location, technical control or security certification should be inferred merely from a translation provider’s quality certificate.

Agree quality stages before production

ISO 17100 distinguishes translation and the translator’s own check from revision by another person. Optional review and proofreading have separate purposes. The ISO 17100 guide explains these stages. A request for “proofreading” is too vague if the buyer actually needs a bilingual check of technical meaning.

A client subject expert can validate product facts and preferred terminology, while a linguist checks whether a proposed amendment reads correctly in the target language. These roles complement each other. A technically preferred phrase may need grammatical adjustment; a fluent sentence may still describe the wrong component. An agreed query and approval route allows both perspectives to be recorded.

The review package should preserve segment identifiers or use tracked changes where appropriate. One consolidated feedback file is more usable than several overlapping email threads. Comments should distinguish errors, terminology decisions and stylistic preferences. A reason for a correction helps the language team apply it consistently without changing valid text elsewhere.

Close the project with controlled approval

Acceptance should identify the approved files and version. If the translation is moved into a layout or application after linguistic delivery, the final output still needs a check for missing text, corrupted characters and broken references. Responsibility for that check should be allocated explicitly. A successful editable-file delivery does not demonstrate that a later export is complete.

The buyer should also agree which terminology and bilingual resources will support future updates, subject to the contract. Retaining an approved reference set makes the next project easier to scope. For commercial comparisons, the translation quote guide explains why the count, quality stages and file work should be compared together.