Now You're Speaking My Language

When writing about the dialogue system a few weeks ago, I mentioned that it was important to consider how translations would work at the beginning of the project.

If every string has been hardcoded in English and there is now a demand to support a different language, then all of those strings need to be found, extracted and replaced with an ID before the translation can even begin. Depending on the size of the project, this can take weeks or even months to do it properly.

So the best way to avoid that scenario is to setup the project as if it is going to be translated, even if it isn't.

MonoGame's ContentManager is capable of loading files in based off the locale that is currently set. So let's say there are 3 files:

• text.txt
• text.fr.txt
• text.en-US.txt

The first file - text.txt - is the default file. This is the default language of the game, which for this example is English. But if the locale is set with a language of French, denoted by a language code of 'fr', the second file - text.fr.txt - will be loaded instead because that file contains the language code after the file's name and before the file extension.

The French file will have began as a copy of the default file, but with each string replaced with the translation in French. But what if the player has a locale of German? Since there is no text file with 'de' (the language code for German), then it will load the default file instead, so German players will have to play in English.

What about the third file - text.en-US.txt? It's got a language code of 'en' which is English, but the default file is already in English, so why is this needed? The file also includes 'US', so it will perform additional checks on the locale. It will first check against the language code to check that it is English, and then it will check against the country code. If the language code is 'en' (English) and the country code is 'US' (United States), then it will load this file instead of the default one.

But why have a different file for the same language? It's to cover cases where words are slightly different - so the default file may refer to a 'colour', but the US file will refer to it as 'color' instead. It's not just for different spellings, but where words have different meanings. Americans would use a 'cell phone', but British people would call the same thing a 'mobile'. While they'd likely be able to have a conversation with each other, French Canadians could end up confused when speaking to someone from France if one of them says a sentence which takes on a completely different meaning in the variant of the language that they speak.

As well as loading in different text files, MonoGame can also load in all kinds of other assets by using the same naming conventions. Textures and sounds can change depending on the language set, but the key one for localisation is the SpriteFont. There aren't many fonts which cover every letter or symbol for every language, so it's likely there will be different fonts for those with Latin characters (Western Europe), Japanese, Polish and Arabic (and other languages).

Changing the text and spoken audio of a game is what everyone thinks about when localising a game, but there's more to it than that. MonoGame's ability to change textures can be key for countries that have censorship on certain things. Blood can be swapped out for green goo and religious symbols can be removed. Even on the text side, quite often things have to be resized to get it all to fit.

I'm not planning on having any art assets changed based on the locale, but Halloween Game is set up to load different strings if I force the locale to be something that isn't English. The only problem with that is that there are no different strings to load, since I need to translate everything first.

The cheapest option is to stick everything through Google Translate. Instead of doing this one line at a time, it's possible to create a Google Sheet with a formula that can translate every line at once. The problem with this that not all the translations are going to be accurate, and the game will end up making no sense. I might as well have made a Kingdom Hearts game.

The non-cheap, and arguably best, solution is to get a translation company to do it. From some research, it typically costs between $0.10-$0.20 per word, depending on which comapny does it and what language the word is being translated to. That doesn't sound so bad, and with Halloween Game's current word count - including all menu options, hints and dialogue - that's between £75 and £90, which also seems reasonable.

But the word count is likely going to double, if not triple, and that is just for one language, which means it multiplies depending on how many languages I want to support. That stacks up to enough that it wipes an entire month off the time I have being indie, if the game does not sell well.

So, what trades offs can I make? I'd only wanted to target French, German, Spanish and Italian anyway, since that removes the headache of having to deal with symbols in Eastern European or Asian languages, so unless there is high demand for unsupported languages down the line then they are getting ignored. There are still additional symbols in the languages I want to support, but they are already covered by the current font.

I could also only translate one language to begin with and see how it goes, but research indicates that the top non-English languages are Russian and Brazilian Portuguese. Russian has already been eliminated because it's got weird characters, and I had considered Brazilian Portuguese and Latin American Spanish previously but ignored them because I incorrectly didn't think they were as big a market as they are.

Then I fiddled around with some numbers. How many copies would I need to sell in order to cover the costs of translation across the 6 languages I had? The answer was not as many as I was expecting - with the current word count, around 130 copies (which also takes into account fees and taxes). So if simply being in their language is enough to convince just over 20 people to buy the game, the costs are already covered.

I talked myself into saying that a big spend like that is worth it, but whether I actually follow through on that is something we'll find out a few months from now.

This week was the deadline for getting the game playable from start to finish, and the post reflecting on whether I did that will be posted in a couple of weeks, since I'm planning on taking next week off, even though I know full well I will not be able to leave Halloween Game alone. There is still a post next week, and it's a bit self indulgent.