With the hyper-competitive nature of mobile gaming and web portals, there’s never been a better time to expand your potential audience internationally by localising your games.
To help make that process easier and to highlight potential pitfalls, here’s the internal checklist we’ve developed over the past few years while localising games such as Disney Fairies: Lost & Found.
Note that we’re using Localisation as a generic term to cover both the act of allowing a product to be localised – a process generally called Internationalisation – as well as the implementation of specific localised content.
Planning & Content
The more time you spend planning your localisation process and getting to understand your content, the simpler and more robust the implementation should be.
- Identify expected locales, if possible including those that aren’t necessary now but may be desirable in the future. The addition of subsequent locales can have significant impact on the implementation of your product; for example if alternate text directions will be required.
- Standardise your locale naming convention. It’s useful to pick a standard for referring to locales and use this consistently throughout your product. We recommend combining the two-letter language identifier as specified by the ISO-639 standard with the two-letter country identifier as specified by ISO-3166, e.g.:
- US English would be represented by en-US
- US Spanish would be represented by es-US.
- Create a context matrix, which should contain all text content that will be featured in your product. To make life easier, plan for this document to either be used directly by your product or define a transformation/export process to get the latest content into your build. A Google Spreadsheet is an ideal starting place for a content matrix.
- Provide context for translators. While creating a content matrix is a good start, you’ll also need to provide additional context for each string to ensure the translations make sense. This could be in the form of written notes explaining how the string will be represented in the product, or even screenshots showing the string in-situ.
- Consider types of data which may be affected by localisation. For example; dates, times, numbers, currencies and interpolated strings (e.g. “You have X points”, where X will be replaced dynamically) may all have unexpected formatting than your primary language.
UI & UX
Potentially the most complex part of the localisation process, especially when it involves an existing non-localised product.
- Accommodate variable amounts of text. It’s likely that the same content will vary in length between locales, so any text-bearing UI elements should be designed with this eventuality in mind. This could include allowing elements to dynamically resize, or for the introduction of scrollbars or similar methods for holding more content than visible in the physical space. Defining specific character limits may also help translators understand any UI limitations.
- Choice of fonts. If possible, you should ensure your chosen fonts support the character sets required by the locales you’re working with, or plan for allowing alternate fonts to be specified for locales.
- Prefer iconography over text, where possible. Reducing the amount of text in your UI can significantly simplify the localisation process.
- Avoid non-dynamic text. Each instance of static text – for example text that’s part of an image – will further complicate the localisation process.
While there will be differences in the implementation of localisation on different platforms, the following points should be generic enough to remain applicable wherever you’re working.
- Select languages at runtime. You should be supplying a single build of your product which supports multiple locales, allowing the selection of the desired locale at runtime. Potentially you could even support swapping locales during usage as opposed to only at startup, which would make testing your content much easier.
- Be aware of platform limitations. There may be fundamental limitations in your chosen technical stack which prevent you from supporting certain languages – for example Unity does not have native support for right-to-left reading languages like Arabic or Hebrew.
- Ensure consistency in your encoding. Most technical stacks now have native and default support for UTF-8 encoding of text content, but it’s worth ensuring you’re using this consistently at all stages of your pipeline where text is handled.
- Allow for rapid previewing of text amends. Designing your content pipeline to allow for live reloading allows content editors to preview the impact of their changes without waiting for new builds to be created. Such a system would likely only be enabled during development, with static content being used for production builds.We built such a system using the Google Apps Spreadsheets API, allowing us to dynamically refresh content in development builds from within the app itself.
Testing your localised product is likely to be the most time-intensive part of the entire process, and can involve multiple rounds of iteration.
- Ensure you have native speakers available for QA. At a minimum this could be the original translator, but having a fresh pair of eyes review the translation can help catch any regional variation or comprehension / grammatical errors.
- Context errors. It’s possible that even with helpful notes supplied alongside each piece of text to be translated that the context may be lost in translation. Evaluating the translated text in-situ in your product is essential to ensure it makes sense.
- Text formatting issues. Where your UI may not be handling the translated text as you expect. Examples of the kinds of issues you may encounter include:
- Clipping or overlapping text
- Incorrectly wrapped text
- Incorrect or missing punctuation
- Incorrect or missing characters
- Untranslated text