Solo & indie devsこの記事を日本語で読む

Localizing your game with no budget: what free actually covers

Every article about translating a game eventually arrives at a number, and the number is larger than what you have. If your budget is zero, the useful question is not whether you can afford professional localization. It is which parts of the job free effort genuinely covers, which parts it covers badly, and which parts it will never cover no matter how much time you throw at it.

The honest version of the answer is that a surprising amount of the work is free — but almost none of the free part is translation. The free part is preparation, prioritization, and verification. Those three happen to be the parts that decide whether the translation you eventually get, paid or unpaid, is usable at all.

This article maps that out: what to do first when you have nothing but time, how far you can push yourself plus machine translation, what to offer people who are not being paid, and where the first money should go once you have any.

Free is not free — you are paying in time and risk

Before planning around a budget of zero, be clear about what you are actually spending. Every unpaid route costs you time you could have spent on the game, and it costs you risk: a translation nobody qualified has checked can reach players with mistakes you cannot see, and the cost of that shows up as reviews, support messages, and a patch you did not plan for.

That is not an argument against doing it. It is an argument for sequencing. Spend your free effort where a mistake is cheap and reversible, keep it away from places where a mistake is public and permanent, and be deliberate about which risks you are accepting rather than discovering them later.

It also means being realistic about how much time you have. A full script translated by yourself with machine assistance and checked line by line is not a weekend. If you cannot give it weeks, shrink the scope instead of lowering the care — a small amount of text done properly beats a whole game done carelessly, and it is much easier to expand later.

Do the structural work first — it is free and it never gets cheaper

The highest-value unpaid work has nothing to do with any language. It is getting your game into a state where adding a language is a data change rather than a code change, and it costs nothing but your own hours.

That means pulling every player-visible string out of your code and into files you can export. It means giving those strings stable keys instead of relying on the English text as the identifier. It means checking that your UI can survive text that is longer or shorter than what you wrote, that your fonts contain the characters your target languages need, and that your text rendering handles line breaking for those languages sensibly.

Skipping this step does not save you anything — it moves the cost somewhere worse. If your strings are still scattered through your source code when you finally get a translation, someone has to hand-place hundreds of lines into a codebase, which is slow, error-prone, and has to be repeated for every language and every update. Teams routinely discover that the engineering work of becoming translatable was larger than the translation itself.

There is a second reason to do it now: it makes every downstream option cheaper. A translator quoting on a clean exported file quotes lower and delivers faster than one who has to work around your project's structure, and a volunteer is far more likely to finish.

Start with the store page, not the game

If you have limited free effort and no money, the store page is where it goes furthest. It is a few hundred words, it is the only text most people will ever read, and it is the surface where being unreadable costs you the most: a player who cannot understand what your game is will not buy it in order to find out.

It is also the safest place to concentrate quality, precisely because it is short. Getting a few hundred words genuinely right — checked by someone who speaks the language, rewritten rather than transliterated — is achievable for free in a way that a full script is not. And because it is short, it is the one piece worth paying for first if any money ever appears.

Store pages have a second advantage: they generate data. Adding a language to your page and watching where interest comes from tells you which language deserves your next block of effort, which is a far better basis than guessing. Publishing a translated page before translating the game is not a compromise — it is a test.

How far you plus machine translation actually get

For most solo developers with no budget, the working combination is their own language ability plus machine or AI translation, applied unevenly across the text.

This works reasonably well for short, repetitive, low-ambiguity text: menus, settings, item names, system messages. The mistakes there tend to be about length and terminology rather than meaning, and both are things you can catch yourself with mechanical checks — comparing placeholders between source and target, flagging lines that came back identical to the source, flagging lines longer than the space they have to fit in.

It works much less well for anything where a character's voice, a joke, a social relationship, or a cultural reference is doing the work. Machine output in those places is confidently fluent and quietly wrong, and if you cannot read the target language you have no way to notice. If your game is narrative-heavy, this is the honest limit of the free route, and pretending otherwise is how games end up with reviews complaining that the translation is technically correct and completely lifeless.

The practical compromise many small games make is a split: machine-assisted translation for the mechanical text, and either professional work or a genuinely fluent reader for the parts where voice matters. Which brings up the other unpaid resource.

People who are not being paid — and what to offer them instead

Money is not the only thing you can offer, and several unpaid arrangements are legitimate if you set them up honestly rather than hoping goodwill covers everything.

Players who already like your game are the most common source. Some will offer to translate, and a fluent, motivated player can do excellent work on a game they know well. The risks are also real: people disappear halfway, quality varies with no way for you to judge it, and an informal arrangement over rights and credit can turn into a dispute later. Agree the scope, the deadline, the credit, and who owns the resulting text in writing before anyone starts, even if no money changes hands.

Other developers are underused. Reciprocal review — you check their text in your language, they check theirs in yours — costs neither side money and gives both a reader who understands games. Developer communities in your target regions are also where you find out whether your store page reads like a real product or like a machine translation, often for the price of asking politely.

Whatever the arrangement, make it easy to say yes to and easy to leave. Small, clearly bounded chunks of text with a stated deadline get finished. Handing someone your entire script with no structure and no end date usually produces nothing, and costs you a relationship.

  • Say exactly how much text is involved, in words or lines, before asking
  • Give a real deadline, and make it one you can absorb being missed
  • Offer credit in the game and on the store page, by the name they choose
  • Offer keys, and offer them to their friends — it costs you nothing and it is genuinely valued
  • Write down who owns the translated text and that you may edit it, so a later disagreement is not a surprise

What free never covers, and where the first money goes

Some things do not have a free version. You cannot verify a language you do not speak, and no amount of care substitutes for one person who genuinely reads the target language looking at your text in context. You cannot get accountability for free — an unpaid contributor owes you nothing, and when they stop, the work stops. And you cannot get consistency across a long project for free, because it depends on the same person staying with it.

So plan your spending in the order that buys the most certainty per unit of money. Store page first, because it is short, high-traffic, and cheap to have done properly. Then a review pass over your machine-assisted text by someone who reads the language — a review is substantially less work than a translation, and it converts an unverifiable file into a known-quality one. Then the first hour of the game, where reviews are formed. Full narrative translation comes after all of that, and by then you will have data telling you whether the language deserves it.

One more piece of free work is worth doing regardless: give players an obvious way to report a bad line, and act on the reports. A game whose translation improves visibly over a few patches is read as a game that cares. That is available to you at a budget of zero, and it is worth more than most of what money buys.

Related articles