Is it OK to have a bilingual friend translate your game?

You need your game in another language, you have no budget, and you know someone who speaks it fluently. A friend, a partner, a cousin, someone from your old job. The thought arrives immediately: could they just do it?

This is probably the most common first move in small-scale game development, and the reflex advice — that only professionals should translate — is both true and useless when there is no money. The more useful question is narrower: which parts of this job does a fluent non-translator actually do well, which parts do they do badly without either of you noticing, and how do you ask in a way that does not cost you a friendship.

What follows assumes your friend is genuinely fluent and genuinely willing. Even then, the failure modes are specific and predictable, and almost all of them come from treating fluency and translation as the same skill.

Fluent is not the same as translator

Being able to read and speak a language means you can understand what a sentence says. Translating means writing a new sentence in that language that produces the same effect on a reader who has no access to the original. Those are related, but they are not the same ability, and the gap shows up in three specific places.

The first is production versus comprehension. Plenty of people read a second language effortlessly and write it stiffly. Their translation will be accurate and mean the right thing, and it will read like a manual — which for a game is a real problem, because tone is most of what your text is doing. Ask yourself whether you have seen your friend write at length in that language, not just speak it.

The second is game text conventions. Game text has rules that are invisible until you have worked with it: a menu label is not a sentence, a line of dialogue has to fit a text box, a system message has a house style, and a fragment like Loading has to work in a context the translator cannot see. A fluent friend will often translate strings as if they were prose, producing grammatically perfect labels that are three times too long for the button.

The third is file discipline, and it is the one that actually breaks builds. Placeholders like {playerName} must survive untouched. Markup tags must stay balanced. Keys must not be edited. Rows must not be reordered, merged, or deleted. A professional knows these are load-bearing; a friend working in a spreadsheet has no reason to suspect that fixing the spacing around a variable will make the game crash.

What to give them, and what to keep away from them

The decision is not all-or-nothing. Sorting your text by how much it depends on writing craft, and how much a mistake costs, gets you most of the value with far less risk.

Good candidates for a fluent friend are text where meaning matters more than voice, and where you can verify the result yourself: item names, menu labels, settings screens, tutorial instructions, and system messages. These are short, checkable against character limits, and a slightly plain rendering does no harm.

Poor candidates are the places where your game's personality lives, and the places where a mistake is expensive: your store page, the opening hour of the game, character dialogue that carries a relationship or a joke, and anything legally or commercially load-bearing. It is not that a friend cannot do these — it is that neither of you can tell whether they did.

Also keep them away from your files. Do not hand over the project. Export the text, send a sheet with only the columns they need, and import it yourself. This protects the build from the file-discipline problem above and, just as importantly, it protects your friend from being blamed for a technical failure they had no way to understand.

• Send a sheet, not the project — key column locked or hidden, one row per string
• Include a context column and a maximum-length column, and say plainly that the limit is hard
• Say explicitly that anything inside braces or angle brackets must be copied exactly, and give one example
• Split it into chunks with individual deadlines rather than one large file
• Never ask them to edit files inside your engine

How to ask so the friendship survives

The damage in these arrangements almost never comes from the translation. It comes from an unbounded favor: no stated size, no deadline, no way to decline gracefully, and no acknowledgment that it was work.

So bound it. Tell them the actual volume in words or lines before asking, not after they have said yes. Give a deadline that you can absorb missing. Offer payment even if you cannot offer market rate, and if you truly cannot pay, say so explicitly rather than leaving it ambiguous — an unstated expectation of money is a much worse outcome than a stated absence of it. Offer credit in the game and on the store page under whatever name they want, including none.

Give them an exit that does not require an apology. Something as simple as saying that if it turns out to be more work than expected, they can hand back what they have done and you will take it from there, removes the pressure that makes people go quiet instead of saying they are stuck. Most stalled friend translations do not stall because the person lost interest; they stall because the job turned out to be bigger than the favor and there was no dignified way out.

A short written brief does more for this than any conversation, because it converts a vague favor into a defined task that can be finished.

What I am asking for
- 420 lines of UI and item text (about 2,300 words)
- Sheet attached: translate column C only, leave A and B alone
- Anything in { } must be copied exactly as it appears
- Column E is a hard character limit for that line

Timing and terms
- Ideally by the end of next month, no crisis if it slips
- I can pay [amount] - it is below professional rate and I know it
- Credited as [name] in game and on the store page, or anonymously
- If it turns out bigger than expected, send back what you have
  and I will take the rest from there. Genuinely fine.

The arrangement that actually works: draft plus paid review

The most effective use of a bilingual friend is usually not as the translator but as one half of a two-stage process. Your friend produces a full draft, and a paid professional reviews and edits it rather than translating from scratch.

This works because reviewing is meaningfully less work than translating, which puts it within reach of a budget that could not have covered a full commission. It also solves the verification problem: you now have someone qualified who has looked at every line, so the file goes from unverifiable to known-quality. And your friend's contribution is real — the draft carries the understanding of your game that an outside reviewer would have had to build from scratch.

It works in the other order too, and sometimes better: pay for a professional translation of the small, high-value surfaces such as the store page and the opening hour, and have your friend handle the bulk of the mechanical text. Either way, the principle is that the money goes where verification is impossible without it.

If you cannot afford a review either, the fallback is a second fluent reader — a different friend, a player from that region, a developer you swap favors with — playing the game rather than reading the sheet. Two independent fluent readers is not the same as one professional, but it is far better than one, and it catches the class of mistake where the translation is fine as a sentence and wrong for the situation.

When something goes wrong after release

Assume at some point a player will report a line that is awkward, wrong, or unintentionally funny. This is normal, it happens to professionally localized games too, and how you handle it determines whether the arrangement was a good idea.

The rule is that the game is yours and the responsibility is yours. Do not name your friend in a response, do not explain that the translation was done as a favor, and do not let a public thread turn into an evaluation of their language ability. You chose the process; you own the outcome. Thank the reporter, fix the line, ship it in the next patch.

Handle the fix without routing it back through your friend by default, either. Going back to them for every reported line converts a one-time favor into an open-ended obligation, which is exactly what damages the relationship. Batch the reports, and only ask if you actually need their judgment.

Longer term, treat the friend-translated version as a first version rather than a finished one. If the language turns out to matter — if the wishlists, sales, or reviews from that region justify it — that is the point to fund a proper pass. The draft is not wasted; it becomes the base a professional edits, and it bought you the information that told you the investment was worth making.