The Gold Standard of Translation Project Management Services | Controlled Workflows and Verified Delivery

Translation project management turns a multilingual request into a coherent, usable release. Its gold standard is not a low per-word fee or a dashboard showing 100% translated. It is the ability to connect authorised source content, skilled people, appropriate standards, review, integration, changes and verified public outcomes.

This guide follows Makers Lane, a fictional neighbourhood arts programme whose weekend workshop is moved from Saturday to Sunday. The English source changes, but other languages and confirmation channels do not. The case explains why translation, language QA and product publication need a single accountable management chain.

Specialist ecosystem routes include Translation Memory Management, Terminology Management, Translation Quality Evaluation and Media Localisation. This article owns the programme-level coordination across those specialists.

Four project questions before buying translation

• **Audience:** Which people must accomplish which task, through which languages and formats?
• **Source:** What is the current authorised content and how will changes be communicated?
• **Team:** Who translates, revises, checks facts, integrates and approves the target?
• **Release:** Which real user journeys prove that all promised versions are ready?

26-chapter delivery roadmap

Chapter index

1. A project is not delivered because the translator pressed Send

A fictional neighbourhood arts group, Makers Lane, prepares a multilingual programme for weekend workshops. The project includes online booking, a printed timetable, venue signs and short captioned introductions. Two weeks before opening, the organiser changes a ceramics session from Saturday to Sunday. The English page is corrected, while the Mandarin brochure and Malay confirmation email retain the old date. Every language vendor shows the relevant files as ‘delivered’.

The gold standard of translation project management is one coordinated, verifiable publication outcome across source materials, languages, media and responsible people. It is not the fastest circulation of separate files or a perfect-looking schedule. Managers need to define actual needs, resources, risks, change rights, quality handoffs and release acceptance. Makers Lane is fictional; its outdated timetable illustrates how a professionally translated sentence can still be part of an incorrectly managed project.

Back to chapter index · Next chapter

2. Clarify why the client needs translation before buying words

A project request should start with audience tasks and intended outcomes: understand an event, submit a form, follow instructions or use a service in another language. The list of documents matters, but it is not enough to define which language versions the public will actually encounter. Different user journeys can rely on the same source sentence across several formats.

For Makers Lane, a family might first see a social post, then choose a workshop on the website and receive a confirmation email. All three must agree. A project manager should map the path and the languages promised, not simply count the brochure’s paragraphs. If the client only needs a readable information summary, that may call for a different deliverable from a fully translated registration and fulfilment system.

Back to chapter index · Next chapter

3. Use the current translation-project guidance within its proper scope

ISO 11669:2024 is published guidance on translation projects, including needs analysis, specifications, risk and effective communication among parties. It replaced ISO/TS 11669:2012. It applies to many sectors, including government, nonprofit and commercial projects, but not to interpreting services.

The standard does not provide the procedures for judging the quality of translated output; that is a distinct function addressed by such material as ISO 5060:2024. A buyer should use ISO 11669 to create intelligible specifications and decision routes rather than attach its name to a generic purchase order. The project manager’s task is to connect the organisation’s real outcome to the work commissioned, without pretending one guidance document certifies every finished language version.

Back to chapter index · Next chapter

4. Write a scope that distinguishes content and channels

A contract might specify source files and target languages while leaving web pages, accessible PDFs, subtitles, graphics or emails undefined. The result can be a dispute in which a vendor delivers the text it quoted but the customer cannot use it. Scope needs to identify deliverables by format, language, version and function.

Makers Lane’s brief should list the booking website, printed timetable, visitor signage, booking confirmation and introductory video. For each, identify which languages will be available and who handles the final layout or integration. A page can be translated correctly but fail because a developer never published it. The client should understand which vendor owns each handoff and which exclusions could prevent a complete public service.

Back to chapter index · Next chapter

5. Verify source readiness before scheduling translators

Late source changes are sometimes unavoidable, but uncontrolled drafts waste time and create contradictions. Establish which original materials are approved, who can change them and how amendments are notified. A file’s modification date is not proof that its contents are the authorised source.

In the fictional event, the printed programme was sent for translation before organisers agreed on room capacities and final dates. The manager should identify unresolved facts and either delay the relevant segments or mark them as provisional. A clean source freeze can reduce rework, while an honest change protocol handles exceptional late decisions. Translation quality cannot rescue a source that contains several mutually inconsistent versions of the same event.

Back to chapter index · Next chapter

6. Build a language-and-asset inventory, not only a word count

Real projects contain continuous paragraphs, interface strings, image text, subtitles, email templates, spreadsheets and snippets reused across products. Some assets have words visible only after users interact with a page. A word-count-based quote can miss those materials entirely or include strings that must never be translated.

Create an inventory with asset identity, language requirements, format, responsible owner, effective version and known dependencies. For Makers Lane, a workshop title might appear in the public brochure, payment confirmation and staff sign-in sheet. Every appearance needs to be traceable. The manager should be able to answer whether a change to that title affects a different team or needs new artwork instead of guessing after the event has started.

Back to chapter index · Next chapter

7. Define competent roles and actual approval authority

Translation work may involve translators, revisers, technical specialists, terminology managers, desktop-publishing staff, accessibility reviewers and publication engineers. A project manager coordinates them, but should not claim linguistic competence in every language. The client also needs an authorised source owner who can resolve facts and conflicting instructions.

ISO 17100:2015, with its published amendment, addresses translation-service processes and qualified resources within its actual scope. It excludes raw machine translation plus post-editing and interpreting. Decide which services the project uses before assigning personnel. A source editor can approve programme details; a qualified target-language reviewer approves the appropriate expression; a technical tester confirms that the right file appears in the actual service.

Back to chapter index · Next chapter

8. Plan time for translation, review and integration separately

A delivery calendar that allocates every day to translating words may have no room for revisions, target-language approvals, typesetting, caption synchronisation or final website tests. Time estimates must reflect language pairs, difficult terminology, source quality, staff availability and the interfaces into which text will be placed.

For Makers Lane, the final translated brochure needs an accessible layout review and realistic printing lead time. The registration page requires web publishing and a test booking. Include contingencies for a corrected workshop date and for reviewer questions. A plan promising perfect multilingual publishing at the final minute may create pressure to bypass checks or quietly release only some languages.

Back to chapter index · Next chapter

9. Make risk and critical information explicit

Not all sentences are equal. Workshop names, booking dates, prices, eligibility, venue access instructions and cancellation conditions may require special review. A style difference in a promotional introduction often matters less than a date change that sends a visitor to the wrong venue. The brief should identify significant consequences and escalation owners.

ISO 11669:2024 includes risk assessment in project specification guidance. In the Makers Lane case, the weekend schedule and confirmation email deserve targeted checks in every language. The project manager should not treat high-consequence text as merely another segment in a translation memory. Risk decisions need to be visible to linguists and publishers, not kept in a private spreadsheet that does not reach the people doing the work.

Back to chapter index · Next chapter

10. Manage terminology as a shared controlled resource

Projects involving several translators may use different names for the same workshop, venue or administrative process. An approved glossary can reduce confusion, but it should identify concepts and contexts rather than force one identical word into unrelated sentences. It needs a qualified owner, source evidence and change procedure.

The Terminology Management Services guide explains concept-oriented decisions. Makers Lane’s ceramics course must have one clearly identifiable listing across the timetable and booking site, even where the target-language expression naturally varies by context. A project manager should ensure approved terms reach every vendor and that disputed changes are decided before public production, not after visitors complain.

Back to chapter index · Next chapter

11. Control translation memories and reuse without copying old facts

Reusing approved phrases can improve consistency and efficiency, but an exact match may reproduce last year’s event date, old eligibility rules or obsolete contact information. The project must distinguish valid reusable language from time-sensitive content requiring fresh verification.

Translation Memory Management Services focuses on these reusable segment records. For Makers Lane, a recurring welcome paragraph may be suitable for reuse, while the workshop timetable needs current approved information. Define rules for review of reused segments and avoid counting a high match rate as proof that the delivered event programme is up to date. Reuse is an aid, not approval.

Back to chapter index · Next chapter

12. Choose machine assistance only where justified

A project manager may combine human translation, machine-assisted workflows and specialised post-editing for different content classes. Selection should depend on source complexity, risk, privacy, language performance and desired output. Neither an automated tool nor a preferred vendor should dictate the method for every part of the assignment.

ISO 18587:2017 remains the published standard for full human post-editing of machine-translation output as of October 2026, with a replacement draft still in development. Do not misstate such a workflow as covered by ISO 17100 when it falls outside that standard’s scope. Budget for qualified review and practical corrections rather than purchasing a low-cost raw output file and calling it publication-ready.

Back to chapter index · Next chapter

13. Secure source data and set legitimate vendor access

Translation packages may contain unpublished programmes, customer accounts, school information or contact details. A vendor might need access to the wording without needing access to every real applicant’s personal data. A mature project limits data transfer, defines permitted processors and maintains appropriate contractual and technical safeguards.

Makers Lane can use test booking data instead of sending a live family database to all translation partners. Confidentiality should also cover early campaign plans and unreleased artwork. If external AI systems or subcontractors are proposed, confirm authorisation, retention and location of processing where relevant. A signed nondisclosure agreement alone is not evidence that every shared drive and online tool is properly controlled.

Back to chapter index · Next chapter

14. Use interoperable files without mistaking validation for accuracy

Translation tools can exchange localisable units, comments and structural tags. Well-defined formats reduce manual retyping but can introduce compatibility problems between vendors or software versions. A successful import does not prove the right sentence appears at the right moment in the product.

OASIS XLIFF Version 2.1 supports localisable content interchange, while ISO 30042:2019 defines TBX terminology exchange. Their functions differ. Specify required formats and conduct representative round-trip tests of context notes, placeholders, language tags and terms. The organiser should be able to retrieve usable assets even if one vendor changes tools halfway through the project.

Back to chapter index · Next chapter

15. Track each segment’s status and real dependencies

A dashboard can show translation complete while revision, domain approval, layout or deployment remain unresolved. Meaningful project states distinguish drafted, translated, revised, approved, integrated, tested and published. A segment should not inherit the status of an entire language merely because it passed one stage.

The ceramics timetable may be approved in Malay but awaiting a corrected date in Mandarin. The project manager should identify that exception and tell the release team which assets are safe to publish. Do not use an aggregate percentage to obscure an unapproved critical section. Workflow status should describe actual readiness, not the optimism of the person reporting progress.

Back to chapter index · Next chapter

16. Resolve questions through a visible decision trail

Translators may ask whether a programme name is a registered title, whether an unfamiliar acronym should be expanded or whether an ambiguity in the source is intentional. Repeated private replies to individual vendors create inconsistent instructions. Route questions to authorised owners and record the answer in a place all affected parties can use.

For Makers Lane, a translator might discover two different start times in the same brochure. The project manager should not invent the correct one from an outdated calendar. Ask the event owner, capture the authorised decision and map any affected translations. Decisions should include source version and date; otherwise a seemingly clear answer can become obsolete when a later organiser approves another change.

Back to chapter index · Next chapter

17. Evaluate output with a model suited to the content

Translation evaluation needs qualified reviewers and a method suited to the reader, domain and risk. An error score can help compare work, but it must not hide a wrong venue, fee or date. The project manager should arrange quality assessment without pretending to be the linguistic adjudicator for every language.

ISO 5060:2024 offers guidance on evaluating human, post-edited and unedited machine-translation output. It does not define an entire corrective-action system. The Translation Quality Evaluation Services guide examines rubrics and sampling. Project management must then make sure findings reach authorised revisers and the changed assets are retested before release.

Back to chapter index · Next chapter

18. Give layout and accessibility separate acceptance owners

Translated content may be correct yet unreadable when its length changes, the chosen font lacks characters, a table loses structure or a caption extends beyond the available scene. These are production integration issues and should have owners, budgets and deadlines alongside the language work.

Makers Lane’s printed timetable needs readable languages and clear day headings; the website must work with keyboards and screen readers where relevant; the short videos need their promised captions. A project manager should not accept a language package as publicly complete merely because the bilingual spreadsheet passed. The Accessible Document Production guide explains another specialist piece of this handoff.

Back to chapter index · Next chapter

19. Keep a controlled late-change process

Source changes can arrive after translation and design approval. A useful change request identifies the original and revised facts, affected assets and languages, the business consequence, the person authorised to decide, and a realistic new deadline. Unrecorded changes sent by instant message easily create contradictory public copies.

When Makers Lane moves ceramics from Saturday to Sunday, the project manager should trace every dependent page, sign, email and video description. Some assets may be re-exported quickly; printed stock or scheduled messages may need different remedies. The team should know what cannot be corrected in time and how the organiser will communicate the change. Transparency beats declaring all languages ready while some still announce the wrong day.

Back to chapter index · Next chapter

20. Distinguish delivery acceptance from publishing acceptance

A language agency may deliver the contracted files correctly while the client’s content management system deploys an older version. Conversely, a website engineer may publish files the language reviewer never approved. Project scope needs to identify the acceptance checkpoint and who must verify the live result.

For the fictional workshops, an end-to-end test should let a target-language user find a ceramics session, select the correct date, complete booking and receive an accurate confirmation. The test is not satisfied by a proofreader approving the PDF alone. A publisher may hold some responsibilities outside the translation vendor’s contract, but the manager must keep their handoffs explicit to avoid a gap nobody owns.

Back to chapter index · Next chapter

21. Protect quality when multiple vendors and time zones overlap

A large multilingual programme can involve different companies translating, reviewing, typesetting, recording voiceovers and publishing. They may work in different time zones and follow separate calendars. The project needs one source of truth and clear transfer requirements, not merely frequent status meetings.

Define file identities, responsible contacts, time references, approval deadlines and escalation procedures in terms every vendor can follow. A contractor should not have to infer which of three near-identical art files is current. Track risks introduced by holiday schedules, late content and incompatible tools. Coordination is valuable when it prevents a problem, not when it multiplies administrative messages without producing decisions.

Back to chapter index · Next chapter

22. Keep commercial scope and change fees understandable

Costs can depend on source volume, language, complexity, revision, formatting, technology, specialist review and short-notice work. Clients need to distinguish initial translation from legitimate new work following a changed source. Vendors need clear rules rather than absorbing unlimited work under an ambiguously fixed price.

State what counts as a correction to defective work versus a paid new request. For Makers Lane, a late organiser-approved schedule change is a different event from a translator’s original misreading of an unchanged date. Apply the agreed contract fairly and preserve a record of approvals. Transparent pricing encourages issues to be reported early rather than hidden because each party fears blame for the additional cost.

Back to chapter index · Next chapter

23. Plan post-release support and error escalation

Publication is not the end of responsibility when audiences can report errors or programme details change. A multilingual site needs a contact and a method to fix one language without losing track of every other version. Corrections should be prioritised according to effect on users and real-world decisions.

If a family reports the wrong date in an email, the project owner should investigate the approved source and affected language routes. Repair the actual public information and notify those affected where appropriate. A vendor’s assertion that a new file has been delivered is not proof that an already sent message or cached page is fixed. Good support separates what can be amended, what needs public clarification and what remains uncertain.

Back to chapter index · Next chapter

24. Archive useful assets with legitimate future ownership

After completion, clients may need translation memories, termbases, source-target files, artwork, acceptance records and licensing information to maintain the programme. The agreement should specify the exportable formats, confidentiality boundaries, project history and retention or deletion arrangements.

A source glossary from Makers Lane may be reusable at next year’s event, while old dates and pricing must not become unreviewed current content. Hand over records that allow future teams to distinguish reusable expressions from time-sensitive claims. The client should not have to return to one proprietary system solely to recover the authorised translations it paid for, subject to real intellectual-property and licence terms.

Back to chapter index · Next chapter

25. Evaluate the project by audience outcomes and reliable control

Translation project metrics can include turnaround time, cost variance, defects, unresolved changes, translation memory reuse and on-time delivery. Each describes only part of quality. A project marked complete in every language can still fail if the intended audience cannot book or understand a material condition.

Review meaningful tasks and errors across the real delivered channels. The strongest evidence for Makers Lane is that families using each promised language see correct dates, choose a workshop and receive matching confirmation. Ask what caused missteps and whether improved source control or reviews prevented recurrence. The purpose of evaluation is learning and dependable service, not only assigning credit for meeting a spreadsheet target.

Back to chapter index · Next chapter

26. The gold standard is one multilingual project that people can actually use

Return to Makers Lane. A single approved schedule now governs the website, printed guides, signs, emails and videos in each language. Specialists have verified meanings and readable outputs; an accountable release manager can show what was published and when. When a workshop changes, the team knows which assets to revise and how to communicate the difference.

Translation project management earns its gold standard by coordinating credible people, standards, source information, language resources and publication decisions around a real audience outcome. The measure is neither the lowest word price nor the largest number of completed files. It is a responsibly managed journey from an authorised source to people receiving the correct information in a language they can use.

Back to chapter index

Worked case: a changed workshop day across five products

The event, translation process and mistakes are fictional. This case shows what a realistic source-to-release change record must identify.

Translation-project acceptance and responsibility matrix

Define these owners before a live deadline so language and technical teams can resolve defects without disagreement about whose file is ‘complete’.

Translation project manager’s checklist

• Translate real audience needs into measurable channel and language specifications.
• Use ISO 11669:2024 for project guidance and standards within their stated scopes.
• Confirm authoritative sources, qualified team roles and risk-important content.
• Inventory all formats, including graphics, emails, captions and third-party journeys.
• Protect confidentiality and maintain client-owned resource boundaries.
• Track translated, revised, approved, integrated and published as distinct stages.
• Give late changes a controlled source-to-target impact and release pathway.
• Verify actual language user journeys rather than the existence of vendor files.
• Deliver exportable sources, resources, approvals and continuing correction ownership.

Frequently asked questions

These answers explain where project management begins and ends, how to commission responsibly and what can legitimately count as a finished multilingual release.

1. What does ISO 11669:2024 actually cover?

It provides general guidance for translation projects, including needs analysis, specifications, risk, workflows and communication among parties. It is intended especially for buyers but also relevant to providers and end users, and applies across sectors. It does not provide translation-output evaluation procedures and does not apply to interpreting. Use it to write a practical brief, not as a claim that an individual translated website is officially certified by ISO.

2. How does project management differ from the translator’s job?

The translator handles meaning and suitable target-language expression within the assignment. The project manager connects client needs, sources, translators, domain experts, reviewers, formats, budgets, schedules and acceptance decisions. These roles can overlap on a small project, but the responsibilities remain distinct. A well-translated brochure can still be deployed with the wrong date if no one owns publication version control.

3. Does a translation provider need ISO 17100 certification to deliver the project?

That depends on the buyer’s requirements and the actual contractual and legal context. ISO 17100:2015 has a defined scope and describes translation-service processes; it is not a mandatory universal licence. Raw machine-translation output plus post-editing is outside its scope. A client should verify claims of certification and ask which specific processes, people and deliverables are actually covered, rather than treat a general standard name as a guarantee of perfection.

4. How should a client handle source changes after translation begins?

Give the change a clear source revision, authorised owner, reason and affected content list. Trace every language and distribution channel that uses the changed fact. Revise and retest those assets, with realistic cost or schedule decisions under the contract. Do not expect translators to infer changes from informal chat messages. If an already published copy cannot be withdrawn, plan an appropriate clarification or other remedy for affected users.

5. What is the difference between XLIFF and TBX in a translation project?

XLIFF exchanges localisable content and relevant workflow information; TBX represents terminology resources. Translation memories store reusable source-target segments. They can work together, but one is not a substitute for all the others. A project should specify required versions and profiles, test round-trip transfer and check that important context survives. Software compatibility does not establish that the language or source facts are accurate.

6. Can a high translation-memory match percentage guarantee low risk?

No. A reused sentence may include last year’s event date, a withdrawn product or an obsolete condition. Reuse is useful when the source and target remain appropriate under the current brief. Set rules for checking dates, names, quantities and other dynamic fields, and link project versions to approved source material. A low word count remaining after matches is not proof that publication checks can be skipped.

7. Should every language be released on the same day?

Not necessarily. A synchronised launch may be valuable or contractually required, but only if the necessary material and technical checks are complete. Where one language has a critical unresolved error, managers should consider honest phased release or another authorised remedy rather than claim the edition is ready. Explain availability clearly to users and avoid advertising a service as multilingual when the promised language journey is not usable.

8. How should clients compare translation quotations?

Compare scope, source quality, language pairs, reviewer competence, terminology resources, formatting, confidentiality, publication support, change handling and acceptance criteria. A cheap per-word quote can omit technical or accessibility work that determines whether readers can actually use the result. Ask which assets are excluded and who owns the final deployment. Fair comparison requires comparable outputs and correction obligations, not just the smallest unit cost.

9. Who decides if a translation error is critical?

Use an agreed rubric that considers meaning and likely user consequence, with competent language and domain input. A wrong workshop date, application deadline or safety qualifier may be consequential, while a harmless style difference might not be. The project manager coordinates escalation but should not override qualified evaluators without evidence. Record the final decision, source, affected assets and required action.

10. Can the project be completed when a PDF is translated but the website is not?

Only if the agreed scope truly ended with that PDF and the client understands the remaining work. A business cannot claim an entire multilingual registration experience was delivered if the necessary website or confirmation messages remain untranslated. Distinguish vendor file delivery from release acceptance and ensure the appropriate product owner tests what users actually see. A complete service description should not conceal important exclusions.

11. How should privacy be managed with several language suppliers?

Share only necessary content through approved systems with suitable confidentiality, access and retention controls. Avoid exposing real client accounts or sensitive records when test data suffices. Determine whether subcontractors or external AI tools are authorised before transfer. A project manager should maintain a controlled vendor and data flow, not let convenience create a chain of unapproved copies across personal devices and cloud accounts.

12. What is the strongest evidence that the translation project succeeded?

The intended audience can complete the relevant task using the promised language and format, with the correct current content. The project should also have a documented source, approved target versions, appropriate subject and language review, functioning delivery, clear rights and a route for correcting future errors. Dates, fees and change history are useful metrics, but real customer comprehension and reliable acceptance are the decisive outcome.

Verified standards and eduKate specialist links

• ISO 11669:2024 — Translation Projects: General Guidance
• ISO 17100:2015 — Translation Service Processes and Resources
• ISO 18587:2017 — Full MT Post-Editing Requirements
• ISO 5060:2024 — Translation Output Evaluation
• OASIS XLIFF Version 2.1 — Localisable Content Exchange
• ISO 30042:2019 — Terminology Exchange (TBX)
• eduKate — Translation Memory Management
• eduKate — Terminology Management
• eduKate — Translation Quality Evaluation
• eduKate — Media Localisation
• Gold Standard Sectors & Services Directory

Standards note, October 2026: ISO 11669:2024 is guidance for translation projects and does not include translation-output evaluation procedures or apply to interpreting. ISO 17100 has a defined scope excluding raw machine translation plus post-editing; ISO 18587 and ISO 5060 address other distinct tasks. Commercial, privacy, language and accessibility duties depend on the actual territory, client and project. This is a management guide, not a certificate of translation or legal approval.