What Information Translation Vendors Need Before Starting a Project

A common scenario in translation projects goes like this: a client sends a folder of PDFs with a short note—“translate to Spanish and French by Friday”—and then questions the results a few days later, with no locale specified. No glossary. No audience context. Faced with gaps, the vendor makes reasonable assumptions. And in translation, reasonable assumptions often lead to results that are technically correct but practically unusable.

Most issues in translation projects—rework, delays, inconsistent terminology—originate in the briefing stage, not in the translation itself. This is where most projects quietly fail—what looks like a simple translation project is often defined too loosely to support real translation project planning. This guide outlines what vendors need before starting work—and why it matters.

Why pre-project information determines translation success

Every translation project involves assumptions. The key question is whether they are informed or improvised.

Without context, vendors default to the most common locale, neutral terminology, and standard professional tone. Sometimes this works. Often it does not—and the problem only becomes visible after delivery.

Detailed intake is not administrative overhead—it is the foundation of effective translation and localization project management. It allows vendors to assign the right specialists, configure tools correctly, estimate timelines accurately, and flag risks early. Clients who invest in structured briefings typically see fewer revision cycles and more predictable costs.

In practice, the quality of questions a vendor asks before starting work is one of the clearest indicators of their process maturity.

Essential project information vendors must receive

Source files and editable formats

File format directly affects cost and turnaround time. Editable files, such as DOCX, XLSX, INDD, XML, or HTML, allow efficient extraction and reintegration. Scanned PDFs or flattened content require manual preprocessing, which adds time and cost before translation even begins.

Vendors also need a clear definition of scope, including:

• What content should be translated?
• What remains unchanged?
• Are there images with embedded text?
• Is there repeated or boilerplate content suitable for reuse?

Without this, even word counts become unreliable. In practice, this is one of the first places where project management decisions in translation affect costs without anyone explicitly noticing.

Target languages and regional variants

“Spanish” is not a sufficient specification. Localization requires precise locale definitions such as es-MX or es-ES—something that should always be clarified at the translation RFP stage, not after work has already begun.

Regional differences affect vocabulary, tone, regulatory compliance, and cultural expectations. The same applies to French (fr-FR vs. fr-CA) or Portuguese (pt-PT vs. pt-BR).

Equally important is audience definition. Technical documentation for IT professionals differs significantly from consumer-facing content, even within the same language. Without this context, translators are forced to generalize—and the output reflects it.

Subject matter and industry context

Different content types require different expertise. A legal contract, a pharmaceutical document, and a game script cannot be handled interchangeably.

Vendors need:

• Industry domain
• Document purpose
• Target audience expertise
• Any regulatory or certification requirements (e.g., ISO standards, sworn translation)

Without this, resource allocation becomes guesswork, and the risk of technically incorrect output increases.

Linguistic assets that improve consistency

Glossaries and terminology

Terminology consistency is critical. If a product feature has an approved name, it must be used consistently across all languages.

A glossary does not need to be complex. A simple list of key terms with approved translations is enough to prevent inconsistencies that later require extensive corrections.

If no glossary exists, it is often worth building one before translation begins. While this adds a small upfront delay, it prevents significantly larger issues during review.

Skipping this step rarely saves time; it usually just shifts the effort into a more expensive correction phase later.

Translation memories (TM)

A Translation memory stores previously approved translations at the sentence level. It enables the reuse of existing content, improving consistency and reducing cost.

If a company has worked with translation vendors before, a TM likely exists. Sharing it with a new vendor can significantly reduce effort, especially for documentation or content that needs to be regularly updated.

Updated TMs should always be returned to the client after project completion, as they are long-term assets.

Style guides and brand voice

Tone does not transfer automatically between languages. A conversational tone in English may require adaptation in languages with more formal conventions.

A practical style guide should define:

• Tone and level of formality
• Handling of humor and idioms
• Treatment of brand and product names
• Formatting conventions (dates, units, currency)

Concise, translation-focused guidance is far more effective than generic brand documentation.

Project scope and operational requirements

Volume and scope

Accurate volume data is essential for planning, and this is where a simple SOW review checklist becomes critical for avoiding scope ambiguity. Approximate figures are not sufficient for serious localization work.

Key metrics include:

• Word count per file
• New vs. repeated content
• Internal repetition rates
• Word count per language
• File types and complexity

These factors determine cost, timeline, and resource allocation.

Deadlines and phasing

Most translation projects are not single-stage deliveries. They involve multiple phases, languages, and review cycles.

Vendors need visibility into:

• Phase-specific deadlines
• Language sequencing (parallel vs. staggered)
• Internal review timelines
• Lead time before project start

Incomplete timeline information often leads to bottlenecks and last-minute compromises. Without this visibility, even well-structured translation project workflow plans tend to break under time pressure.

Quality assurance expectations

Quality requirements vary by project. Internal documentation does not require the same level of review as regulated content.

Define the workflow upfront:

• Translation only
• Translation and editing
• Full TEP (Translation, Editing, Proofreading)
• In-context review
• Testing for software (linguistic and functional)

Misalignment here is one of the most common sources of friction between clients and vendors.

Technical and workflow considerations

File formats and system integration

Modern localization often involves structured content and integrated systems rather than standalone documents.

Vendors need to know:

• File formats (XLIFF, JSON, XML, etc.)
• Content source (CMS, localization platform, custom system)
• Workflow (manual vs. automated)
• Tool preferences (e.g., memoQ, Trados)

These decisions are not purely technical—they directly shape the project's feasibility.

Confidentiality and compliance

Translation projects frequently involve sensitive data. Requirements must be defined before work begins.

These may include:

• NDAs
• Data residency constraints
• Restrictions on machine translation
• Security or compliance standards

Applying such requirements after the project starts creates avoidable risks.

Multimedia, UX, and cultural adaptation

UI and technical constraints

Software localization introduces constraints absent in document translation.

Examples include:

• Character limits (important for languages that expand)
• Layout restrictions
• Pluralization rules (more complex in many languages)

Without clear guidance, translators may produce linguistically correct text that breaks the interface.

Providing context—screenshots, UI references, or usage descriptions—significantly improves accuracy.

Audio-visual content

Multimedia translation has strict technical requirements:

• Subtitles must meet character and timing limits
• Dubbing must align with the audio duration
• Voice-over requires pacing adjustments

Vendors need scripts, timing files (SRT/VTT), and clarity on whether on-screen text requires localization. Providing only video files adds unnecessary preprocessing.

Cultural adaptation

Some content requires more than direct translation. Marketing slogans, humor, and culturally sensitive references may need transcreation.

Potential issues include:

• Wordplay that does not translate
• Unintended meanings in target languages
• Cultural differences in imagery or symbolism

Flagging such content early allows for appropriate adaptation strategies. Addressing it mid-project is significantly more disruptive—and often far more expensive than the initial translation itself.

Final thoughts: the brief defines the outcome

A translation project workflow that runs smoothly from kickoff to delivery almost always starts the same way—not with exceptional execution, but with a well-defined translation RFP and a briefing that gives both sides what they actually need. Source files in editable format. Locale codes, not just language names. A glossary, or an agreement to build one. A scope definition that reflects what the project actually contains. A timeline that accounts for review cycles and does not treat "urgent" as a substitute for planning.

None of that requires a client to become a localization expert. It requires treating the vendor briefing with the same seriousness as the delivery deadline. The information shared before translation begins determines whether the result is usable—and whether the process of getting there was worth what it cost.

The vendors worth working with will ask for most of this anyway, in their own intake forms or kickoff calls. That is actually a useful filter. A vendor who starts work without asking is either very experienced with your specific content type or they are making guesses. It is worth knowing which one before you sign—because at that point, the difference is no longer theoretical but operational.