It looks to me like the author is trying hard to justify localization because he wants it to be worthwhile, but looking at the numbers, I don't see the evidence. The reasons he gives seem like rally big stretches and factual cherry-picking.

It is nice to make your game available in many languages, but getting translations that aren't terrible is hard, and I have never seen a clear business case for it. So I think the proper attitude is "there is not an obvious business case, but we are doing it because we want to."

I mostly agree. The real measure of an investment, however, is the opportunity cost: What else could I have done with those resources? Might it have yielded higher returns?

But as the author alludes, the company is much better positioned for "the next one," so the investment actually has yet to pay off and there's plenty of upside left. From that perspective it was a huge win, since it appears that he came close to covering his costs, and now the company has a competitive advantage.

(I'm the author) Just for the record, although it's hard to exactly quantify the extra amount earned from the localization, even a conservative estimate covers our localization costs and a small profit. You're right in pointing out that opportunity cost is the real cost.

If this was the only game I was ever going to make, I probably would have spent my time better on things other than localizing it nearly a year into its lifespan.

I think the most important point is that we left plenty of money on the table by not having the localization available on day one. The localization was launched very late into the game, and almost all revenue comes from the major promotional periods.

It will be interesting to compare results with the sequel to see if we have notably larger market share right from the start in the languages we choose to localize in, I think that will provide a little more conclusive data than this admittedly murky analysis.

I think localization is so important and reaches beyond just translating a few strings (though really -- even that is something many developers miss). It's really about the small touches in the experience, for ecommerce, items that ship, taking tariffs and import/export rules into account. currency. for games, small hints like background and music and so on.

This effort is great and its awesome to an effort that speaks to a variety of audiences

I see there have been several fan translations. Do you think it would have been better/cheaper/easier to have in-game support for adding translation patches and working with the community, rather than hiring professionals?

There is in-game support for adding translations, sort of. You just drop files into a folder and there you go. (This is in fact how our Russian and Korean translations turned up, fans had started working on them on their own, and then started emailing their work to us).

The only thing that requires a lot of heavy lifting is if that language requires a previously unsupported font (like a new Asian language), or if the new language has problems fitting in the User Interface.

As I said in the article, I would not consider fan translations a replacement for professionals so much as a supplement, although I guess this depends on the needs of your app/game. In my case we had a big story-based RPG with 45,000+ words, which is not a trivial exercise and there's all sorts of opportunities for it to go off the rails in ways that kill the sparkle (inconsistent grammar, poor or erroneous characterization, horrible translations of jokes, etc). Fans can and do produce great work, but you can't assume that's what you'll receive.

For languages you're really interested in targeting (for us our top priority was German) you don't want to roll the dice on that. But for "like to have" languages it's not a bad idea.

Another simple benefit to localization is that it can make it easy to fix typos or reword things in your native language, too, if you use short keys in your code and have all real strings in a single place.

Even if you don't plan on localizing, it's a good habit to move all your strings to one place like this, as you can quickly see in one place if all of your strings have consistent tone, style, and word usage.

You're referring to the process of internationalization, which is usually treated as a separate process from localization.

Internationalization is making it possible to swap out language-specific assets at runtime (which is what Lars points to as the difficult part of this which can be carried over to other projects); localization is the process of actually making those language-specific assets. Internationalization is done by spending (usually in-house) programmer time; localization is about throwing money at (usually outsourced) translators.

I don't like using short keys. Another thing you need to come up with a name for. I much rather have the English phrase as the "key".

But what then when you fix a typo in your English text? Or slightly rephrase it without altering the meaning? This means the translation files have to be updated as well.

OTOH, systems where it is very easy to change only the English text without even thinking about the translations have their own pitfalls. Namely that people make "tweaks" and the translations go out of sync.

Or you have an en → en translation file. For some things this is necessary anyway (e.g. QTranslator's handling of plural forms).

+1. en → en translation file is common practice.

I appreciate the article and data, had a couple of thoughts from my own experience localizing:

* Punting on localization can make a lot of sense. It helps to do localization up front and plan for it, but that's when opportunity cost is at its greatest. It's also a marginal "multiplier" effect, and so it's not a make-or-break engineering item usually.

* I doubt localization to Russian is as good as Spanish, very often.

* Definitely agree that translations from actual users are leagues ahead of professional translator services, good thought to cultivate that.

* You can do it incrementally, and localize your app description prior to the app itself, which doesn't have the same engineering requirements.

"Definitely agree that translations from actual users are leagues ahead of professional translator services, good thought to cultivate that."

Not really. In recent month I was very active in translating software and web site from English to German and found a lot of weird and partially wrong translations.

Some of those are due to the context free way translation sometimes works. You get the original string and you have to translate it. For example "Sync", but is that a verb or a noun? In English it might not matter but in German it does.

Also sometimes you get people with a dialect in, which use different words and even a different word order which might only be used by a small minority but it is not consensus in the language.

I think the best approach would be to do both. Get professional translators and use direct feedback from users.

Despite my obvious pro-localization stance, I must say I agree a lot with this first point. Localization is NOT easy, and developers should be very wary about doing it in their first app.

The link to Playism is broken.

URLs in HTML are treated as relative by default, so doing <a href="playism-games.com"> creates a link to http://www.fortressofdoors.com/was-localizing-defenders-ques...

Cheers, fixing now.

I still think you should not focus on localization for the release of your first game. Try to get stuff out of the door and improve on it later. For subsequent games, maybe your organization might able to do a bit more before a release, but remember that trying to do more and more at once is just a recipe for disaster.

You used geography as a metric to correlate with languages.

I would think there are some number of people in the USA that appreciate having the option to play in their preferred language.

It'd be more interesting to find out how many people picked language X vs buying from country Y.

Indeed, for instance I bet there's a large Spanish market in the U.S.

Unfortunately, Steam doesn't really give me access to that sort of data (an oversight I hope they fix) -- they know what language people are running Steam in, there's no reason they couldn't pigeonhole the language of your player base and show you that data.

i guess my question was about choosing the language itself,

if it's chosen in-game, you could HTTP some basic analytics data to yourself.

A solid idea! Will probably do that next time.

I'm wondering how many of the Russian purchases were due to "cd key stores" or similar. Given that they're only paying half of what US customers are, the markup's high enough. Also, more and more of these stores send you the games as steam gifts.

(I'm the author) -- Good question! These were all actual sales, not steam key redemptions (which are tracked separately). So the answer is "zero."

Open question to readers: do gaming frameworks provide functionality like this? I know that Android SDK, and Appcelerator provide hooks for internalization (and by extension localization). Are there similar functions in game SDKs?

Some do. Unreal Engine 4 has localization support built in: https://www.unrealengine.com/blog/creating-a-localization-re...

And I suspect any game engine intended for text-heavy games would provide something. Ren'Py is one example.

But I'm fairly sure that Unity doesn't.

You might not have enough data yet but now I'm curious to see a study into the localization sensitivity for various languages.