Game translation contract checklist: what to settle before signing

Most game translation work starts without much of a contract. A template someone had from a previous project, a purchase order, or an email thread that both sides treat as the agreement. That holds up until the first situation nobody planned for: you want to change vendors, a translator objects to an edit you made, an agency asks whether they may use a machine translation step, or you and a supplier disagree about whether something is a defect or a new request.

What follows is a checklist of points to settle, organized by the trouble they prevent. It is deliberately not legal advice and contains no clause wording. Contract law differs by country and by what kind of party you are contracting with, and the drafting that makes any of these points actually enforceable is exactly what a general article cannot provide. Use this to work out your own position first, then have a qualified lawyer draft or review the document — the conversation is much shorter when you already know what you want.

Who owns the delivered translation

This is the point most worth getting right, and the one most often assumed rather than written. A translation is a work in its own right. Owning the source game does not automatically make you the owner of a translation of it, and paying for the work does not always transfer everything by default — what happens by default depends on the jurisdiction and on how the agreement is written.

Two structures are common. One transfers rights in the translation to the studio. The other leaves rights with the translator and grants the studio a license. A license can be perfectly workable if it is broad enough, but broad enough has to be spelled out in terms of what you will actually do with the text.

• Modify the translation without consulting the translator — for length, for a redesign, for a rating requirement
• Reuse it in ports, sequels, remasters, demos, and marketing material
• Sublicense it to a publisher, platform partner, or regional distributor
• Keep using it after the relationship ends, including in future updates

The modification point causes more real friction than the ownership label does. A studio shortens a line to fit a button, and the translator objects to their name appearing on the result. That is why modification rights and credits belong in the same conversation rather than in separate clauses drafted at different times.

Some jurisdictions also treat certain author's rights as personal to the author and not transferable at all, with the practical workaround being an agreement about how those rights will or will not be exercised. Whether that applies to you, and how it should be handled, is a question for a lawyer in your jurisdiction, not something to copy from a template found online.

Translation memory, glossaries, and everything built along the way

The deliverable is not only the translated file. The work also produces assets: a translation memory of every confirmed source-and-target pair, a glossary or termbase of agreed terminology, a style guide, and a log of the questions asked and the answers given. Those assets are usually more durable than any single build.

If the contract says nothing, the common outcome is that these live inside the vendor's tools and stay there. The consequence appears only when you switch suppliers: the next vendor starts from zero, and you pay again to translate lines you already paid for, in slightly different words than the ones already in players' hands.

Settle three things: that these assets are deliverables and not internal working files, what format they arrive in — portable interchange formats for memory and terminology, or an agreed spreadsheet layout — and how often they are delivered. Cadence matters more than people expect. An agreement to hand everything over on termination guarantees the handover happens at the moment goodwill is lowest.

Confidentiality, and what it actually has to cover

A confidentiality agreement almost always exists, and it is almost always written for generic commercial information. Game projects need it to cover specific things that generic wording misses: unreleased content, story beats and endings, character deaths, release dates that have not been announced, and access to builds that are not public.

The clauses worth reading carefully are about who and how long rather than what. Who inside the vendor may see the material, whether subcontractors are covered by the same terms, how long the obligation lasts after delivery, what happens to files and builds afterwards, and whether builds may be installed on personal machines.

One item is routinely forgotten: pasting text into an external online tool is a disclosure. Whether that is acceptable, and to which tools, needs saying explicitly rather than being left to each person's judgment on a deadline.

Subcontracting and AI use: who is actually doing the work

Agencies subcontract. That is normal and not inherently a problem, but it changes who is holding your unreleased content and who is producing the text you will ship. The contract should say whether subcontracting is permitted, whether you are told when it happens, and that confidentiality and any AI terms flow down to whoever actually does the work.

AI use deserves its own explicit position because the range of practice is wide. Some studios prohibit machine and AI translation entirely for narrative text. Some allow it for specific categories with disclosure. Some allow it only through named tools under terms that keep the content out of training data. Any of those can be a defensible policy. What is not defensible is leaving it unstated and finding out later, because that is the case where nobody agreed to anything and both sides believe they were reasonable.

The reverse direction needs stating too. If you run a machine or AI first pass yourself and ask the supplier to post-edit it, say so in the agreement. It is a materially different job from translating from scratch, it usually carries a different rate, and a supplier who discovers it after starting has a fair complaint.

Acceptance, rework, and what counts as a defect

Most disputes in localization are not about ownership. They are about whether something is a mistake the supplier must fix at no charge or a change the studio is asking for. Without an agreed line, both sides argue from their own definition and the relationship absorbs the damage.

Define what an acceptance check consists of and how long you have to run it. A window that starts at delivery and runs for a stated number of business days is workable; a window that never closes is not, and no supplier can price it. Then name the categories that are the supplier's responsibility to correct:

• Mistranslation and meaning errors, and untranslated or partially translated segments
• Terminology that deviates from the glossary agreed at the start
• Damage to placeholders, variables, and markup carried in the source
• Violations of character or length limits that were specified in the brief
• Inconsistent handling of the same source string in the same context

Equally important is naming what is not a defect: the source text changed after delivery, the brief changed, tone preferences that were never written down, or context supplied only after the translator had already delivered. Those are new work, and treating them as free rework is how suppliers learn to price your future projects defensively.

Two more details prevent stalemates. Say who judges — a named reviewer on your side, or an independent third party for the languages nobody internal can read — because a quality dispute with no named arbiter simply escalates. And agree a turnaround for corrections, along with an end to the correction obligation, so that neither an open-ended liability nor an unanswerable request sits in the contract.

Credits, payment, and getting out

Credits are cheap to give and matter enormously to the people doing the work. Settle whether individual translators are named or only the company is, in what form and in which section, and whether the individuals may list the title in their portfolio — including when they may do so, since an unreleased title mentioned publicly is a confidentiality problem rather than a credit one.

Payment terms need the boring specifics: currency, payment timing measured from a defined event, whether the work is split into milestones with partial payment, and who bears cross-border transfer fees. Cross-border engagements also raise tax questions — withholding obligations and the paperwork that goes with them differ by country and by whether the supplier is a company or an individual. Treat that as a question for a tax professional and your own tax authority's published guidance, not something to settle by analogy with another project.

Finally, write down how the relationship ends. What happens to work in progress and partially delivered files, whether you receive the memory and glossary covering the completed portion, whether rights transfer for what has been paid for, and how much notice either side gives. An exit clause is easiest to write when neither party wants to leave, which is exactly why it should be drafted then.

Every item on this list is a business decision before it is a legal one. Deciding your position on each — what you need, what you can concede, what you would walk away over — is work only your studio can do. Take those answers to a qualified lawyer for the wording, and to a tax professional for anything involving cross-border payment, and treat this article as preparation for those conversations rather than a substitute for them.