When you hear the word "money", what is the first thing that comes to mind? Is it a green rectangle of paper with a former US president's face? Maybe it's a coin with Queen Elizabeth's face on one side? How about "breakfast" or "person"? The difference could be where you were born and how you were raised. Updating a game or program so that is adapts itself to the language and country it is executed in is called localization. Localization is important to expanding the possible user base for your game. I will cover how I updated my game engine to adapt to different languages and countries.

Supporting multiple languages means more than just having a word-for-word replacement. There are expressions like "money for old rope" that will lose meaning if you try to translate explicitly. Whether it is large blocks of text or just the label on a button, we will need the ability to replace text to ensure that the meaning isn't lost. This is where localization keys come in. Let's say we have a button that starts a race and we want it to display "Go" in English. Since that word will be something different in French then we should use something other than "Go" to begin with but it will be replaced with "Go" when displayed for English. We will use a localization key for what will represent "Go" in English. The key should be something that you can easily differentiate from common text. A good key for the text "Go" could be "[LS_195]" because you are very unlikely to naturally see that sequence of characters appear. You have to be careful if you open your text system to having replacements. If a user just so happens to create a profile with the name "[LS_195]" then you would not want their name to display as "Go". It is important to have the ability to skip translating text when appropriate.

Now that we have a key for the word "Go" we need to keep in mind that it is also a verb. When translating "Go", we wouldn't want the translator to confuse it with the Chinese game Go. The same goes for "Close" which could be used as "Close the door", "Close to work", or "two close friends". When translating text, it is important to provide context. There are translation services out there that you can hire but you need to do your best to help them choose the proper translation. I took two Latin classes and three French classes in high school and I found it amazing all the ways that a sentence can change depending on the tense and gender alone. My advice here is to provide any gender info about who is speaking or being spoken to, how it would be used in a sentence for short words or phrases, and character limits.

Character limits are important because a short sentence in one language could be much longer in another language. A character limit can help inform a translator that space is limited and to persuade them to use a shorter synonym where able. We now have localization keys that will give us the language-specific translations. These should be tracked within a spreadsheet or database. You wouldn't want to pay to translate the same text twice.

When we localize it would be impractical to try to localize for every permutation of every language and country. This means that in the absence of a perfect localization match then we must compromise with a fallback. Let's say the game supports British English and Canadian French but the user has set their device's language to English and their country to Japan. In this case it would be best to fallback to British English since the user will at least be able to read the text even if it is not perfectly what the user would expect. The selection hierarchy goes: Language-and-Country, Language, then Default. The language identifiers come from ISO 639-1 and the country identifiers come from ISO 3166-1. This means American English is represented by "en_US".

If we only translated text that passed through the text renderer then we would miss text that is embedded within images. Since the images are game-specific then it wouldn't make sense to use a localization key when selecting an image to display. For images, I use a different convention. Let's say we have translations for British English and Canadian French and different versions of our title image to match. Let's say the title image's default filename is "title.png". If the user has set their device's language to American English then the selection hierarchy will first look for "title.en_US.png". If it fails to find that file then it will look for "title.en.png" next. If it fails to find that file then it will use the default, which is "title.png". This same pattern can be applied to other file types including audio and fonts.

Fetch quests usually have a reward once completed. The great thing about fetch quests is that they can provide the player with a means of earning gold, experience, or resources. Another great aspect of fetch quests is that they can dynamically add content to a game's world with low effort. Each fetch quest text can be boiled down to:Go to ${PLACE_NAME_A}, get ${QUANTITY} ${QUANTITY_UNITS}, and return to ${PLACE_NAME_B}.The sentence has tokens that are easy to identify and substitute as needed. This pattern can be very handy but it still has some caveats. What if I asked you to get "1 cherry" versus "14 cherries"? The ${QUANTITY_UNITS} here would be "cherry" in the first case and "cherries" in the second. Non-English languages will have similar situations. You will need to translate the associated ${QUANTITY_UNITS} text as needed.