A localization RFP checklist: what to send before you compare quotes

You have a game, a release window, and a mandate to get quotes from several localization vendors. A few weeks later you have four proposals whose totals differ by a factor of two, and nothing in any of them tells you whether the cheap one is efficient or the expensive one is thorough.

That is almost always a problem with the request rather than with the vendors. A vendor can only quote what you told them. If you did not say whether a second linguist reviews the translation, some will price that in and some will not. If you did not say what format the text arrives in, each will assume something different about how much engineering effort they are absorbing. Comparability is something you build into the request; it is not something you discover in the responses.

This is a checklist for the procurement side of localization work: what goes in the packet every vendor receives, what to ask them, what to compare once the answers arrive, and what the responses already tell you about how each vendor will behave once the project starts.

Why competing quotes usually are not comparable

Two honest quotes can differ enormously because they are pricing different work. The most common divergences are scope (in-game text only, or store page and marketing too), process (translation alone, translation plus bilingual review, or both plus LQA in your build), the counting basis (source words, target words, or characters), who absorbs file handling, and what happens to text that arrives after launch.

There is also a structural pull toward under-quoting that has nothing to do with dishonesty. When a request leaves scope open, the bid built on the smallest defensible reading of it wins the comparison, and the missing work reappears later as change requests. The vendor who priced the fuller picture looks expensive and loses, which teaches everyone in the market to quote the narrow version next time.

The fix is not to demand lower prices. It is to remove the room for different assumptions, so that the number each vendor returns describes the same job.

The packet every vendor gets, unchanged

Assemble one packet and send it to everyone on the same day with the same response deadline. If you answer an extra question for one vendor, send that answer to all of them — otherwise you are comparing quotes written from different briefs again.

• Volume per language pair, with a note on how you counted it and what the count includes or excludes
• A content breakdown — UI, systems text, narrative, item and tutorial text, store page, marketing, legal — because the mix changes both the rate and who they staff
• A real sample of the actual file: a few hundred lines exported exactly as the vendor would receive them, keys and all, not a hand-tidied excerpt
• The file formats and the round trip: what you export, what you need back, and what tool sits in between if any
• Target languages and locales spelled out precisely, since regional variants are separate decisions and separate costs
• Constraints the text carries: character or pixel limits per field, placeholder syntax, rich-text tags, and terms that must not be translated
• Schedule: content lock, delivery milestones, launch date, and how much new text you expect per month after launch
• The services you want priced as separate lines: translation, bilingual review, LQA in build, engineering, graphics text, voice
• Reference material that exists today: glossary, style guide, previous translations, a playable build or a video walkthrough
• Confidentiality and platform obligations: NDA, handling of unreleased content, and whether subcontracting is permitted

Ask every vendor the same questions, in the same order

Free-form proposals are unreadable side by side, because each vendor organises their answer around what makes them look best. Send a numbered question list and ask for the answers in that order. It costs them almost nothing and turns your comparison into a table.

The point of most of these questions is not the answer itself but whether the vendor can answer precisely. A studio that has run this process before can describe it without hedging.

1. Basis
   - Do you quote per source word, target word, or character?
   - Which count applies to Japanese and Chinese source text?
   - Is there a minimum charge per language, per file, or per delivery?
2. Process
   - Who translates, and is review by a second linguist inside the quoted price?
   - Is machine translation or AI used at any step? If so, where, and how is it disclosed?
3. People
   - How many linguists per language, and can the same people continue on updates?
   - What titles have those linguists worked on in these languages?
4. Assets
   - Who owns the translation memory and glossary produced on this project?
   - In what format can we receive them, and at what point?
5. Updates
   - How are post-launch batches priced and scheduled?
   - What is the minimum turnaround for a small urgent batch?
6. Quality
   - How is a defect we report after delivery handled, and within what window?
   - Do you offer LQA inside our build, and with what staffing?

What to compare besides the total

Price is a real criterion and there is no need to be coy about it, but the number worth comparing is the cost of the first year, not the cost of launch. Several of the criteria below move that number more than the rate does.

• Game experience specifically — not just entertainment or media, but games with a comparable text type and volume
• Whether they asked questions before quoting, and whether the questions were about your constraints or about your budget
• LQA capability: can they check text inside a running build on your platforms, or only read files offline
• Translation memory and glossary ownership, the delivery format, and when you can get a copy
• Continuity of the same linguists across updates, which is the single biggest driver of tone consistency over a game's life
• Turnaround and minimum charges for small batches, which decide what your live-ops updates actually cost
• How clearly they describe any AI or machine translation in their process, and how post-edited output is priced
• Working language, time zone overlap, and who you escalate to when something is late

What the RFP stage already tells you about a vendor

The response is a work sample. How a vendor behaves while they want your business is the most optimistic version of how they will behave once they have it.

A vendor who asks about placeholder syntax, character limits, and what reference material exists before quoting is showing you their process. One who returns a number within an hour without a single question is quoting a template, and the assumptions inside that template are the ones you will argue about later. Vagueness about who actually does the work — whether it is staff, regular contractors, or whoever is free that week — is worth pressing on, politely and directly.

Be equally suspicious of a schedule that is too good. A turnaround that leaves no time for the translators to ask questions is a promise to guess, and guessed lines are the ones that come back as player complaints.

If the decision is large enough to matter, pay for a pilot. Give every shortlisted vendor the same short, genuinely representative slice of content, at the same rate, with the same brief, and have someone who reads the target language score the results without knowing which vendor produced which. The cost of a pilot is small next to the cost of discovering the answer through a full delivery.

Running the process so the decision holds up

Write down your criteria and their weights before the responses arrive. Deciding what matters after seeing the prices is how a process ends up rationalising the cheapest bid, and it also makes the decision impossible to defend internally later.

Leave a real decision window. A vendor selection that lands two days before content lock is not a selection; it is whoever could start immediately. Work backwards from the delivery date through review, LQA, and build integration, and set your RFP deadline from there.

Keep the packet and every answer. Your next RFP is a diff of this one, and the questions you had to answer ad hoc this time belong in the packet next time. If you already maintain a localization kit for production handoff, the RFP packet is a subset of it plus the commercial questions; if you do not, what you just assembled is the first draft of one.

Finally, tell the vendors who did not win, briefly and without a price breakdown of their competitors. The market is small, the person who lost this bid may be the one with capacity when you are in trouble next year, and a reputation for running a clean process is worth more than any single negotiation.