A translation budget should pay for a reliable multilingual outcome, not merely for a number of words. Professional translation budgeting begins with scope, language coverage, content risk, workflow, reuse, update frequency, technical handling and review. The per-word rate can still matter, but it is only one component of a system that must move content from an approved source to a usable, maintainable target-language experience.
Searches for translation budget, localization cost, translation pricing, translation cost per word, localization budget, translation memory savings, machine translation post-editing cost, translation review cost and how much does translation cost often lead directly to rates. Rates are useful, but they are not enough. A cheap first translation that requires repeated repair, inconsistent terminology, emergency rework or expensive source synchronization can cost more over its lifetime than a carefully designed workflow.
This guide shows how to budget translation as a managed capability. It explains how to define scope, distinguish one-time from recurring costs, model review depth by risk, account for translation-memory leverage without double-counting savings, plan terminology and style work, budget engineering and desktop publishing, price source changes, reserve contingency, compare providers on total value, and measure whether multilingual content remains useful after publication.
This article belongs to eduKateSG’s Master Art of Translation architecture. It complements the existing pages on effort estimation, provider selection, translation memory, quality metrics and project management. Its job is narrower and more practical: turn the actual translation operating model into a defensible budget.
Quick Read: budget the workflow, not the word
A translation budget should answer six questions before it tries to calculate a total. What content is in scope? Which languages and locales are required? What is the consequence of error? Which quality workflow is appropriate? How much reusable linguistic material already exists? How often will the source change after launch?
Once those are known, the budget can include translation, revision, subject review, terminology work, project management, file engineering, localization testing, desktop publishing, in-country review, tools, vendor management and maintenance where relevant. Not every project needs every component, but every component that is required should be visible.
The strongest budgets also include choices. If funding is constrained, reduce or stage scope before silently reducing the controls needed for high-risk content. A smaller complete multilingual journey is often better than a large unreliable translation surface.
1. Define the budget objective
Before calculating cost, state what the budget must achieve. Are you launching a product in three languages, maintaining a global help centre, translating a one-time regulatory submission, localizing a course, supporting multilingual employees or building an ongoing translation programme?
Different objectives create different cost structures. A one-time document may be dominated by translation and review. A software product may require continuous updates, localization engineering and testing. A marketing programme may spend more on transcreation and in-market approval. A regulated programme may spend more on specialist review and auditability.
The objective tells you which costs are essential and which are optional. It also prevents a common mistake: comparing two translation quotes as if they describe the same service when one includes a much broader outcome.
2. Scope by content asset, not by an approximate word total
Word count is useful for estimating translation volume, but scope should begin with actual content assets. List the websites, documents, UI strings, videos, forms, help articles, policies, campaigns and other objects that must be localized.
This exposes work that word counts miss: extracting text from images, handling subtitles, rebuilding layout, testing interface expansion, checking links, validating placeholders and publishing target-language pages.
A multilingual content inventory can also remove unnecessary cost by identifying duplicates, stale pages and assets planned for retirement. The cheapest word is the word you correctly decide not to translate.
3. Distinguish source words from billable work
A source may contain ten thousand words, but the translation effort is not necessarily ten thousand new words. Translation memory may contain high-quality matches. Repeated segments may require verification rather than full translation. Tables may contain non-translatable codes. Conversely, ten thousand source words can require significant research or layout work that is not represented in the count.
Budget models should show the relationship between source volume and work categories. New translation, fuzzy-match review, repeated content, exact-match verification and non-linguistic production can be priced or planned separately.
This makes savings transparent without pretending that repeated text always costs nothing. A match still needs context and may require review if the surrounding meaning changed.
4. Budget by language and locale
Languages differ in provider availability, specialist supply, script, layout, review capacity and technical requirements. A budget that multiplies one universal rate by every target language hides these differences.
Plan per locale where meaningful. French for Canada and French for France may share much but require different legal or market conventions. Chinese Simplified and Chinese Traditional may involve different target markets and approval paths. Right-to-left languages can create additional interface and layout work.
Locale-level budgeting also clarifies staged rollouts. You can fund the highest-priority languages first without pretending the entire global programme has been purchased.
5. Separate translation from revision
Translation and independent bilingual revision are distinct tasks. If the project requires a second qualified linguist to compare source and target, budget that explicitly.
Some suppliers bundle revision into a rate; others price it separately. Neither model is inherently better. What matters is understanding what the quoted service actually includes and whether it matches the risk of the content.
If a quote is much lower because it removes independent review, the budget comparison should show that workflow difference rather than presenting the price reduction as pure efficiency.
6. Add subject-matter review where consequence requires it
Some content needs validation beyond linguistic accuracy. Clinical, legal, engineering, financial, scientific or policy material may require a subject specialist to confirm that terminology and interpretation fit the domain.
Specialist review can be one of the scarcest and most expensive resources, so identify it early. Do not translate an enormous volume and only then discover that the available expert can review a fraction of it before launch.
Risk-based budgeting reserves expert attention for the content where it changes outcomes instead of applying specialist review indiscriminately to every sentence.
7. Budget terminology work before volume translation
Termbases and glossaries are often treated as overhead, but they can reduce downstream rework dramatically. New products, technical domains and organizations with branded language benefit from deciding high-impact terms before thousands of segments are translated.
Budget time for term extraction, definition, target-term research, approval and maintenance. The initial investment may be small relative to the cost of correcting a core term across many files and languages later.
Terminology work is particularly valuable when the same concepts appear across UI, documentation, marketing and support. One stable concept system creates reuse across the whole content estate.
8. Budget a style guide when consistency matters
Voice, spelling, punctuation, date formats, capitalization, names, acronyms and interface conventions produce repeated decisions. A target-language style guide turns those decisions into reusable instructions.
The guide does not need to be large. A concise guide for a new language can save review time because translators stop reopening the same preference questions. Larger brands and long-running programmes may justify more detailed guidance.
Budget the guide as an asset whose value continues across projects, not as a cost that belongs to one page.
9. Account for translation memory without assuming every match is safe
Translation memory can reduce effort by reusing previously translated segments. Budget models often apply different rates or effort assumptions to new words, fuzzy matches and high-confidence repetitions.
But reuse is only valuable when the stored translation is appropriate to the current context. Legacy translations may contain outdated terminology, poor quality or language intended for a different product. High match percentage is not the same as high semantic reliability.
Budget an initial memory audit when provenance is uncertain. Cleaning a weak memory can prevent low-quality reuse from spreading faster and cheaper.
10. Treat machine translation as a workflow choice, not a free line item
Machine translation can reduce production cost for some content, but the relevant budget question is the whole workflow. Does the output require light post-editing, full post-editing, bilingual revision, terminology enforcement, risk review or no human intervention under an explicitly approved low-risk policy?
Different content classes may justify different answers. High-volume low-risk internal material is not equivalent to public safety instructions or brand-defining marketing copy.
Budget the evaluation and review needed to make machine-assisted work fit for purpose. A nearly free draft that consumes expensive expert correction may not be the cheapest system.
11. Include translation management
Project management is real work. Someone must receive files, verify scope, schedule translators, answer questions, maintain versions, coordinate reviewers, track deadlines, resolve conflicts and deliver the right files.
Small projects may absorb this effort easily. Large multilingual programmes can require substantial coordination, especially when many languages, vendors, content systems and approvals interact.
Do not treat project management as waste simply because it produces no target words. Good coordination is what keeps the right words in the right files at the right time.
12. Include file engineering and preparation
Translation-friendly files reduce cost. Poorly prepared files create manual extraction, reformatting and risk. Scanned PDFs, complex presentations, design files, embedded images, software resource files and structured data may require technical preparation.
Budget this work explicitly when it is material. Better still, improve source authoring and export processes so future projects become easier. Repeated file-engineering cost can reveal a source-system problem worth fixing.
Technical preparation also protects non-translatable elements such as tags, variables, codes and placeholders.
13. Include desktop publishing and visual QA
Translated text expands and contracts. Scripts differ. Line breaks change. Tables, labels, forms and diagrams may no longer fit. Documents and marketing assets often require desktop publishing after translation.
Budget layout adaptation and final visual proof where the delivered artifact matters. A grammatically perfect translation clipped inside a table cell is not a finished product.
Visual QA can be lighter for plain web content and more intensive for designed PDFs, packaging, presentations and print.
14. Include localization engineering for software
Software localization includes work beyond language: externalizing strings, handling plural forms, supporting locale formats, testing text expansion, right-to-left layouts, font coverage, sorting, input and date or number conventions.
Some of this is product engineering rather than translation, but the localization budget or programme plan needs to account for it. Otherwise language teams receive strings that the product cannot display correctly.
Investing in internationalization can lower long-term localization cost by making future languages easier to add and maintain.
15. Budget localization testing
Target text should be seen in context. Testing can reveal truncation, wrong variables, untranslated strings, broken links, mirrored layouts, misplaced punctuation, encoding problems and meaning that changed because the translator lacked context.
Decide which content needs linguistic testing, functional testing or both. Software, e-commerce and complex web journeys usually need more than document-level review.
Testing is especially important after automated deployment. A correct translation can still fail in production because the wrong string, file or locale was released.
16. Budget in-country or market review carefully
Local reviewers can add valuable market knowledge, especially for marketing, legal, cultural and product terminology. But unstructured in-country review can also become an expensive preference loop.
Define the reviewer’s role, authority, turnaround and feedback rules. Provide the style guide and terminology so they evaluate against shared criteria rather than rewriting into personal taste.
Budget review rounds and change limits. If every stakeholder can edit indefinitely, no estimate will survive.
17. Include accessibility-related localization work
Multilingual content may need accessible alt text, captions, transcripts, reading order, clear link labels and compatibility with assistive technology. Some source accessibility features must be translated; others must be recreated or tested in the target locale.
Do not assume accessibility is automatically preserved when text changes. A translated image description can be missing, a subtitle may become too dense, or a localized interface label may no longer be clear when read by a screen reader.
Where accessibility is part of the product promise or requirement, include it in scope and testing rather than treating it as post-launch cleanup.
18. Budget source-content improvement separately
Translation often exposes unclear source writing. Fixing that source can improve every target language, but the work belongs to source content governance, not hidden translator effort.
Create a budget line or ownership path for source clarification, controlled authoring, terminology cleanup and rewriting when needed. Do not silently ask translators to repair defective content and then compare them only on word rate.
Better source content is a multiplier: one improvement can prevent the same ambiguity from being solved separately in ten languages.
19. Model source changes and retranslation
Projects change after kickoff. Budget a rule for revised source. Small deltas can be processed efficiently; large rewrites can invalidate previous translation and review.
Use version comparison and change logs so the budget reflects actual new work. When the source owner replaces a file without identifying changes, the translation team may need to compare versions manually.
For continuously updated products, shift from one-time project budgets to an ongoing maintenance model based on expected monthly or release-cycle change volume.
20. Separate launch cost from maintenance cost
A language launch has initial costs: translation, terminology, style setup, engineering, testing and perhaps market review. After launch, recurring costs appear: source updates, new content, support, term maintenance, regression testing and content retirement.
Budget both. A launch that cannot be maintained creates stale multilingual content and eventually costs more to repair. The ongoing run rate may be more important than the one-time launch figure.
This is especially true for websites and software where source content changes continuously.
21. Forecast update volume realistically
Ask how much source content changed in the last six or twelve months, not how much stakeholders hope will change next year. Release histories, CMS logs and previous translation jobs can provide useful evidence.
Separate predictable recurring updates from major launches. Build a base maintenance budget and a project reserve for exceptional work.
If the source estate is rapidly growing, include growth. A flat maintenance budget for a content library expanding thirty percent a year is structurally underfunded.
22. Include content retirement and cleanup
Multilingual programmes spend money not only adding content but removing it safely. When source pages retire, target-language copies, links, search entries, downloadable files and translation assets may need updates.
Retirement work is usually cheaper than translating unnecessary new content, but it still requires coordination. Budget periodic lifecycle cleanup so stale translations do not accumulate indefinitely.
This also protects users from outdated information that looks current merely because it remains online.
23. Budget provider onboarding and evaluation
Switching or adding providers has setup costs: tests, security review, contracts, tool access, style training, terminology handoff and pilot work. These costs can be worthwhile, but they should be visible.
Do not compare a new provider’s first month with an established provider’s mature workflow without accounting for onboarding. Conversely, do not let sunk onboarding cost trap the organisation with a provider that consistently fails.
Provider selection should be based on evidence of fit, not the lowest nominal unit price.
24. Include tools without assuming more software equals lower cost
Translation management systems, CAT tools, machine translation services, quality automation, connectors and analytics platforms can improve productivity. They also create licence, integration, training and administration costs.
Budget tools based on the problem they solve. A small team with simple files may not need a complex enterprise stack. A global continuous-localization programme may save enormous manual coordination through good integration.
Total cost should include the people needed to configure and maintain the tools, not only subscription fees.
25. Model security and privacy requirements
Confidential or sensitive content may require approved environments, restricted access, contractual controls, data residency, vendor vetting or additional technical measures. These can affect both price and provider choice.
Do not solve security requirements after selecting the cheapest workflow. Build them into scope so providers quote the service you are actually allowed to use.
For highly sensitive material, a more controlled workflow may be economically rational because the consequence of exposure dwarfs the translation rate.
26. Add a contingency reserve
Translation projects encounter unknowns: corrupted files, extra revisions, missing context, urgent changes, unavailable specialists, new target locales and source defects. A budget with no contingency assumes perfect information.
Set a reserve proportionate to uncertainty and project maturity. A repeat project with stable files and a trusted provider needs less contingency than a first-time launch into several unfamiliar locales.
Track how contingency is used. Recurring “unexpected” costs should eventually become planned budget lines.
27. Use scenarios instead of one fragile total
Create a base, constrained and expanded scenario. The base covers the planned scope and required controls. The constrained scenario shows what can be staged or deferred without breaking critical journeys. The expanded scenario shows what additional value becomes possible with more funding.
This is far more useful than one total that collapses when leadership changes the budget. It also helps protect quality by showing that lower funding should first change scope, not silently remove essential review.
Scenario budgeting makes translation planning a decision conversation rather than a single approval request.
28. Compare total cost of ownership, not quote totals
A provider with a lower rate may require more internal management, generate more rework, lack specialist capacity, deliver inconsistent terminology or provide weak technical support. Another provider may cost more per word but lower the total operational burden.
Compare translation quality, revision performance, turnaround reliability, tooling, reuse policy, project management, security, expertise, escalation and maintenance. Include internal time spent fixing or coordinating work.
Total cost of ownership is not an excuse to ignore price. It is a way to compare price against the complete service.
29. Avoid double-counting translation memory savings
Translation memory can reduce the amount of new translation, but teams sometimes count the same savings twice: once in the vendor discount and again in an internal productivity forecast.
Build the budget from the actual pricing model. If exact matches are charged at a reduced review rate, use that rate. If internal translators reuse memory without separate billing, model their expected throughput accordingly. Do not claim both as independent savings.
Also remember that low-quality legacy matches may create negative savings if they require extensive correction.
30. Budget for quality measurement without turning it into bureaucracy
Large programmes may need sampling, error analysis, reviewer calibration, user testing or quality metrics. These activities consume time but can reveal systemic problems before they become expensive.
Use measurement proportionate to scale and risk. A small one-time brochure does not need the same quality analytics system as a global product releasing every week.
The purpose of measurement is to improve decisions: provider fit, reviewer consistency, terminology, source quality and workflow design. If a metric is never used, reconsider its cost.
31. Connect budget to service levels
A budget becomes more credible when each service level has a cost logic. Standard work uses ordinary capacity. Controlled high-risk work includes stronger review. Expedited work may require premium staffing. Large launches require project coordination. Emergency coverage may require reserved availability.
This lets requesters see why two projects with the same word count can cost differently. They are buying different levels of assurance and responsiveness.
It also lets the organisation decide deliberately where premium service is worth paying for.
32. Connect budget to prioritization
If the total desired translation scope exceeds funding, use the priority model. Protect mandatory, high-consequence and journey-critical content first. Then fund the next tier based on user need and strategic value.
Do not spread the same budget thinly across every language and every page if that creates incomplete experiences everywhere. Concentrated coverage can produce more useful access.
A prioritized budget tells leadership exactly what becomes possible at each funding level.
33. Track cost per useful outcome, not only cost per word
Per-word cost is easy to calculate, but it does not tell you whether users can complete tasks, support demand fell, market launches succeeded or regulated content remained current.
Where practical, connect spending to outcomes such as completed multilingual journeys, maintained critical pages, reduction in stale translations, faster update propagation or improved support resolution.
This creates a more mature conversation about value. Translation remains a cost, but it is a cost attached to capability rather than isolated text production.
34. Watch for hidden internal costs
Internal stakeholders spend time preparing files, answering queries, reviewing translations, resolving terminology and approving releases. These costs may never appear on a vendor invoice.
Estimate them for large programmes. If a supposedly cheap provider consumes hundreds of hours of internal correction, the budget should make that visible.
Likewise, investment in better source content, terminology or automation may look expensive until internal rework is included.
35. Treat budget variance as evidence
When actual spending differs from plan, investigate why. Was the source unstable? Did word volume grow? Were more review rounds needed? Did provider productivity assumptions fail? Did technical work appear late?
Classify variance and feed it into the next estimate. Repeated variance in the same category means the budget model is wrong, not that the project was uniquely unlucky every time.
This is how translation budgeting improves from project to project.
A practical translation budget structure
- Source scope: content assets and source volume.
- Languages/locales: launch and maintenance coverage.
- Translation production: new content, reuse and machine-assisted workflows where approved.
- Revision: independent bilingual checking appropriate to risk.
- Subject review: specialist validation where required.
- Terminology and style: setup and maintenance of linguistic assets.
- Project management: coordination, queries, scheduling and version control.
- Engineering: file preparation, extraction, integration and internationalization.
- Desktop publishing: layout reconstruction and visual proof.
- Localization testing: linguistic and functional checks in context.
- Market review: structured in-country approval where justified.
- Tools: TMS, CAT, machine translation, QA and connector costs.
- Security/compliance: required controls and approved environments.
- Maintenance: recurring source updates and target synchronization.
- Retirement: safe withdrawal of obsolete multilingual content.
- Contingency: reserve for defined uncertainty.
Worked example: a new website language
A company wants to translate a large website into one new language. The first estimate simply multiplies the total site word count by a rate. The better budget begins with the content inventory and priority model.
The team identifies the complete acquisition, purchase, account and support journeys required for launch. Old campaigns and low-value archives are excluded. The source is cleaned, duplicate pages are removed from scope, and high-reuse terminology is approved before translation.
The budget then includes translation and revision, a small target-language style guide, localization of forms and UI, visual QA, testing of critical journeys and a recurring monthly allowance for new content. The initial scope is smaller than “the whole site” but the launched experience is more complete and maintainable.
This is a better budget because it buys a functioning multilingual service rather than a percentage of translated pages.
Worked example: a regulated document set
A regulated document set has relatively modest word volume but high consequence. The budget includes qualified specialist translators, independent review, terminology validation, controlled versioning and formal approval. The per-word production line is only part of the cost.
Attempts to reduce the budget by removing review would change the risk model, not merely the price. A more responsible cost reduction might remove non-essential background documents from the first phase or improve source consistency to reduce queries.
The budget follows consequence rather than treating all words as equal commodities.
Worked example: continuous software localization
A software team releases weekly. A one-time translation quote cannot describe the operating cost. The budget includes TMS integration, translation memory, terminology, recurring new-string volume, review, linguistic testing, release coordination and occasional engineering work for new locale features.
Over time, reuse improves efficiency, but product growth creates new content and new languages. The programme tracks cost by release and by active locale, while also monitoring stale strings and defect rates.
The result is an operating budget aligned to continuous delivery rather than a sequence of emergency purchase orders.
Common failure: buying the lowest per-word rate
Price matters, but a low rate can describe a narrower service, less experienced resource, weaker review, poorer project management or simply a more efficient provider. You cannot know which without comparing scope and evidence.
Ask what is included, who translates, who reviews, how terminology is handled, how quality issues are corrected, how source changes are priced and what technical support exists.
Then compare total value. The lowest rate can be the right choice, but it should win because the whole service fits, not because one number is smaller.
Common failure: treating review as optional polish
Review is not always required at the same depth, but where it is part of risk control it should not be the first budget line removed. Doing so can create downstream rework or unsafe output.
Use risk-based workflows so lower-risk content can legitimately use lighter controls. This protects budget efficiency without pretending every document deserves either maximum review or none.
Quality architecture is a better cost lever than across-the-board cutting.
Common failure: underfunding maintenance
Launch budgets attract attention because they are visible projects. Maintenance is quieter and often neglected. Months later the source changes and translated content begins to drift.
Reserve recurring funds based on observed update volume, not a token percentage chosen for convenience. Include terminology, review and publishing work needed to keep target content aligned.
A language that cannot be maintained should be scoped more carefully before launch.
Common failure: translating before source cleanup
Every ambiguity and duplication in the source can multiply across languages. Spending a small amount on source readiness can be more cost-effective than translating the problem repeatedly.
Use content inventories and source-preparation checks to identify obsolete content, broken references, duplicated pages and undefined terms. Resolve them before they become multilingual rework.
Source quality is one of the most powerful translation budget controls because it improves every language at once.
Common failure: budgeting every language identically
Different locales may have different demand, risk, review resources and technical work. A uniform allocation can overfund some areas and underfund others.
Use a shared quality principle but locale-specific operational planning. The required outcome can be equal even when the path and cost differ.
Where a language is strategically important but expensive, make the trade-off explicit instead of quietly reducing coverage or quality.
How to build the first budget in one working session
Start with the content inventory and select the in-scope assets. Add target locales. Mark high-risk content and required review. Estimate new versus reusable translation. Add terminology, style, project management, engineering and testing where relevant.
Then separate launch from maintenance. Add known source changes and a contingency reserve. Create a constrained scenario that removes lower-priority scope without reducing essential controls. Create an expanded scenario for additional languages or deeper coverage.
Finally, write down the assumptions. A budget without assumptions becomes impossible to explain when volume, languages or source readiness change.
Questions to ask a translation provider about price
- What exactly is included in the quoted rate or project fee?
- Is independent revision included, and by whom?
- How are translation-memory matches and repetitions priced or handled?
- How are machine-assisted workflows used, if at all?
- How are source changes and revised files charged?
- What project-management and technical work is included?
- How are minimum charges, rush fees or weekend work handled?
- What specialist review is available for high-risk content?
- Who owns the translation memory, terminology and final files?
- How are quality defects corrected and how quickly?
- What security or confidentiality controls affect price?
- What happens to pricing as volume, languages or reuse increase?
Frequently asked questions
How much does translation cost per word?
There is no universal rate because language pair, content complexity, provider model, review depth, reuse, urgency and specialist requirements differ. Per-word pricing is useful when the included service is clearly defined, but it should not be treated as the whole project cost.
Is translation memory supposed to make translation free?
No. It can reduce effort for repeated or similar content, but matches still require context and may need verification. The quality of the stored memory also matters.
Is machine translation always cheaper?
Not automatically. It can reduce production cost for suitable content, but post-editing, review, terminology, risk control and correction can change the total. Compare the complete workflow and outcome.
Should review be a separate budget line?
It can be bundled or separate. The important thing is knowing whether independent revision, subject review or market approval is included and whether the workflow matches the content risk.
How should we budget for urgent translation?
Use service levels. Urgent work may require premium capacity, overtime, more coordination or displacement of other work. Define who can authorize it and which quality controls remain required.
How much contingency should we keep?
The appropriate reserve depends on uncertainty. New providers, unstable sources, complex files, new languages and first-time launches need more contingency than repetitive mature workflows. Track actual variance and refine the model.
Should we translate the entire website to get economies of scale?
Not if much of the site is stale, low-value or irrelevant to the target market. Scope from user journeys and priorities first. Scale is useful after you know the content deserves translation.
How do we reduce translation cost without reducing quality?
Improve source quality, remove duplicate scope, prioritize complete journeys, use reliable translation memory, decide terminology early, automate file transfer, match review depth to risk and maintain good provider relationships. These reduce waste rather than simply removing controls.
What is the difference between launch cost and maintenance cost?
Launch cost establishes a new language or content set. Maintenance cost keeps it synchronized as the source changes. Both are necessary for long-lived multilingual content.
How should we compare two translation quotes?
Normalize the scope. Compare included review, specialist expertise, project management, translation-memory treatment, tooling, security, source-change rules, turnaround and quality correction. Then compare total cost for the same required outcome.
The larger lesson: a translation budget is a model of responsibility
Budgeting reveals what the organisation believes translation is. If the budget contains only words and rates, it assumes language transfer is an isolated production step. If the budget contains scope, risk, review, terminology, engineering, maintenance and lifecycle work, it recognizes multilingual content as a system that must remain trustworthy over time.
The purpose is not to make translation expensive. It is to make cost visible in the places where work genuinely occurs and then remove waste intelligently. Better source content, better prioritization, reusable linguistic assets and connected workflows can reduce total cost without pretending expertise and quality assurance are free.
A strong budget therefore tells a clear story: these users need these journeys in these languages; this content carries this level of consequence; this workflow is required to make it dependable; this is what launch costs; this is what maintenance costs; and this is what we can stage if resources change.
For effort and risk planning, see Estimate Translation Effort, Risk and Review Depth Before You Start. For reuse architecture, continue with The Translation Memory System. For supplier decisions, see Select Translators and Translation Providers with Evidence, Not Price Alone.