TwitterFacebookLinkedinBufferemailShare this page... According to App Annie’s “The State of Mobile” report, in 2018 games accounted for 74% of consumer spend in app stores. Games are huge, which is why MultiLingual‘s latest issue, which just went live, focuses on the topic. In 2019, mobile gaming is going to reach 60% market share of consumer spend. One of the reasons that makes it possible is the global presence achieved with the help of localization. Here is a guide for understanding whether the mobile game is ready for localization. In other words, this is a draft for a game localization maturity model. Language analytics A game might be developed and published by different companies. But even in this case, and even though the promotion team might also have the final say, it is recommended that marketing and analytics teams — in collaboration with localizers — make a general decision on what languages the game needs to be present in. Ekaterina Zaitseva, lead localization manager of RJ Games says that “we don’t translate game descriptions a few days before release in the App Store now. Everything is planned in advance.” When selecting the target languages, consider the following: The experience of your main competitors, including the popularity of their games in the country of your interest Publicly available research, such as insights on the game’s localization ROI The number of potential users speaking the language and their paying capacity Planned cost of localization Availability of quality translation service providers A few years ago, issues caused by miscommunicated expectations and process details between the development, design and localization teams emerged here and there in many games. The community reported cases of unlocalized text embedded in graphics, violated character limits and non-resizable text which both resulted in truncations, grammatical issues with gender and so on. Even today, in 2019, you download a game that boasts supporting, let’s say, the Russian language, and still (sad but true) you may get machine translation instead of a proper translation. But, on the other hand, localization is being increasingly integrated into the development process. The growing trend is for all the teams involved in a game creation to communicate constantly on how and when to do things. And interest in improving the quality of the process and its outcome is growing steadily Collaboration with the development team So, a responsible localizer does research and tells the developer in advance what problems may arise from a linguistic point of view. The priority and relevance of the main internationalization issues are to be carefully set depending on the project, as Ekaterina Zaitseva from RJ Games states: “Resourcing” all of the strings (when user-visible strings are put into resource files) Avoiding hard-coding or embedding text in any graphic files as much as possible Testing of every font for every planned language Paying attention to special characters, such as umlauts. (If you cannot find a font that blends appealingly with the game design and at the same time supports umlauts, use diphthongs instead) Remembering that UTF-8 is the right encoding choice most of the time Deciding whether or not you plan on mirroring the interface to consider the difference between LTR and RTL languages Making strings scalable, allocating space for size change, as some languages take more space than the source Enabling wrapping for multiline texts Taking into account how English is unique. Word order, use of genders, plurals and possessives, and other rules vary drastically between languages Creating text strings with variables for grammatical changes as well as time, date, currency and number formatting Localizers need to remember that collaboration with development and design teams covers not only the text and interface itself. Game sound and art need to be thought through and made localizable in advance as well. Ideally, all images, symbols and logos need to be focus-tested with the target locales to minimize the risk of offending certain audiences. IGDA, the International Game Developers Association, advises gaining awareness of the top four cultural variables as they apply to your target markets: history, religion, ethnicity and geopolitical considerations. In the subsequent discussion with the developers, when the process is already set up, it just makes sense to go through a localization sanity checklist, which should be compiled based on publicly available sources (such as “Best Practices for Game Localization” by IGDA), and of course, personal experience. Documentation and processes preparation Usually at some point when the game is still cooking, you already know what the target audience is, or what languages and game setting are planned, though there is no actual text to translate yet. Now is the time to set up the following: The localization processes and workflows, including decisions on what CAT environment to use, or who reports to whom and in what cases. For instance, how the work of Support will be organized and automated, and will it be multilingual or in English only? Documentation such as templates, checklists and rules, style guide, onboarding guide, language vendor scorecard, or the “Project localization Bible.” You can also start compiling a glossary: even though there’s no full source text available, some of the key terms are already known. A reference system for context. If you can ask the development team to leave some notes for text strings, all the better. The precious information on game logic will help localization teams a lot, even if there’s going to be a full-scale linguistic testing. A draft of the testing plan. At the linguistic testing stage linguists verify in-game texts and overall game performance (such as the correct response of game elements to user inputs). A testing plan will help to get the most out of this stage. If it seems hard to draft it at the preparation stage, you can at least think of the environment to use. Will your testers report bugs and upload screenshots in a simple Google Sheet or use an online repository, such as Jira? Advanced companies create special onboarding kits for developers, something like “Globalization 101,” which can focus on internationalization and culturalization aspects, or, for instance, feature common mistakes found in some other games. The alternative is seamless continuous localization. Predefined and tuned processes are a benefit. But what if some of them could be bypassed for good? Open source solutions such as Serge, which stands for String Extraction and Resource Generation Engine, offer a trendy way to make manual localization management (exporting, converting files, sending them for translation, doing reverse conversion, committing changes to version control) unnecessary. The tool gathers new source, publishes it for translation, acquires translations and integrates them back into the product, pulling and pushing changes, and will also synchronize with an external CAT tool of your choice. Serge is being developed by Evernote, which has its products and marketing materials continously localized into 25 languages. This solution is mostly tailored to work with text translations, though. Its effect is not so noticeable in the localization of non-textual formats such as graphics or audio. So if you need to localize these things for a game, Serge will only grant you partial automation QA and testing setup Another extremely useful means of partial automation is QA checks. When a language vendor delivers the job, you can apply industry standard practices such as a third-party review of a sample translation and extensive QA metrics. But in a budget or time-constraint environment it makes sense to at least run a simple in-house check prior to importing localized content into the game build for future linguistic testing. Use QA tools: QA built-in CAT, Xbench or Verifika. QA or at least spotcheck methods should be thought about in advance, as they may and most certainly will be another expense item. Prior to actual QA, a handy approach for advanced teams is to build a pseudolocalization tool for the mobile application testing. Even MT helps get a view of the localized product. And this might lead to useful proactive design changes. In addition to linguistic testing, some games can afford to invite focus groups to actually play the game. Their gaming experience is recorded and analyzed to evaluate their playing habits, if and when (and why) they face any difficulties in the game. This type of testing, though, belongs at the final stage of the project. Budgets and legal matters To dive into the localization stage at full speed, one must come prepared. And this is almost impossible without having agreed on who would actually do the job. So test the waters with localization vendors in advance. Communication with vendors prior to the actual project’s start will help with calculating localization budgets (advice: add 15-20% for unforeseen expenses, especially if there is a voiceover planned on the project), and avoiding delays in production due to any possible legal issues. Early collaboration with your legal department on setting up vendor contracts will streamline your future mutual localization efforts. Each new language, though, generates additional costs associated with globalization, as you would likely need to invest in social media localization and tracking reviews in app stores. Feedback collection Speaking of reviews, you can actually start gathering feedback from gamers related not to your game but to similar ones. Search for competing games and pay attention to the comments and ratings in app stores. There’s always something to learn: if the errors themselves aren’t useful, the root causes for them will be. Another smart move is to make it easy for gamers to leave feedback in the game itself. But if you’re conducting a survey, for example, you should give an incentive, maybe by providing an in-game currency per reply. This is something to discuss with development and design teams, especially considering the multilingual background of the users, but any way to thank a user for informative feedback adds a nice touch. (Yearly) plan and user engagement Continuing on user engagement, the #1 thing to include in the game plan for the next year is culturalization. 2018 saw a trend of labeling culturalization as a fictitious step created for demonstrative localization activity purposes only, which some localizers get offended by. They’re putting their hearts into making the game content viable and meaningful. And to make content meaningful, it pays to ask questions. So open discussions inside and even outside of your team that relate to plot, characters and objects during the conceptual stage, which will help identify cultural patterns and possible issues. As The Game Localization Handbook says, culturalization is all the more effective the earlier it’s applied to game content. The same could be said about the planning itself. But it’s even more fun to make amendments to the plan in the localization process. So with all due circumspection, let the game begin! TwitterFacebookLinkedinBufferemailShare this page... According to App Annie’s “The State of Mobile” report, in 2018 games accounted for 74% of consumer spend in app stores. Games are huge, which is why MultiLingual‘s latest issue, which just went live, focuses on the topic. In 2019, mobile gaming is going to reach 60% market share of consumer spend. One of the reasons that makes it possible is the global presence achieved with the help of localization. Here is a guide for understanding whether the mobile game is ready for localization. In other words, this is a draft for a game localization maturity model. Language analytics A game might be developed and published by different companies. But even in this case, and even though the promotion team might also have the final say, it is recommended that marketing and analytics teams — in collaboration with localizers — make a general decision on what languages the game needs to be present in. Ekaterina Zaitseva, lead localization manager of RJ Games says that “we don’t translate game descriptions a few days before release in the App Store now. Everything is planned in advance.” When selecting the target languages, consider the following: The experience of your main competitors, including the popularity of their games in the country of your interest Publicly available research, such as insights on the game’s localization ROI The number of potential users speaking the language and their paying capacity Planned cost of localization Availability of quality translation service providers A few years ago, issues caused by miscommunicated expectations and process details between the development, design and localization teams emerged here and there in many games. The community reported cases of unlocalized text embedded in graphics, violated character limits and non-resizable text which both resulted in truncations, grammatical issues with gender and so on. Even today, in 2019, you download a game that boasts supporting, let’s say, the Russian language, and still (sad but true) you may get machine translation instead of a proper translation. But, on the other hand, localization is being increasingly integrated into the development process. The growing trend is for all the teams involved in a game creation to communicate constantly on how and when to do things. And interest in improving the quality of the process and its outcome is growing steadily Collaboration with the development team So, a responsible localizer does research and tells the developer in advance what problems may arise from a linguistic point of view. The priority and relevance of the main internationalization issues are to be carefully set depending on the project, as Ekaterina Zaitseva from RJ Games states: “Resourcing” all of the strings (when user-visible strings are put into resource files) Avoiding hard-coding or embedding text in any graphic files as much as possible Testing of every font for every planned language Paying attention to special characters, such as umlauts. (If you cannot find a font that blends appealingly with the game design and at the same time supports umlauts, use diphthongs instead) Remembering that UTF-8 is the right encoding choice most of the time Deciding whether or not you plan on mirroring the interface to consider the difference between LTR and RTL languages Making strings scalable, allocating space for size change, as some languages take more space than the source Enabling wrapping for multiline texts Taking into account how English is unique. Word order, use of genders, plurals and possessives, and other rules vary drastically between languages Creating text strings with variables for grammatical changes as well as time, date, currency and number formatting Localizers need to remember that collaboration with development and design teams covers not only the text and interface itself. Game sound and art need to be thought through and made localizable in advance as well. Ideally, all images, symbols and logos need to be focus-tested with the target locales to minimize the risk of offending certain audiences. IGDA, the International Game Developers Association, advises gaining awareness of the top four cultural variables as they apply to your target markets: history, religion, ethnicity and geopolitical considerations. In the subsequent discussion with the developers, when the process is already set up, it just makes sense to go through a localization sanity checklist, which should be compiled based on publicly available sources (such as “Best Practices for Game Localization” by IGDA), and of course, personal experience. Documentation and processes preparation Usually at some point when the game is still cooking, you already know what the target audience is, or what languages and game setting are planned, though there is no actual text to translate yet. Now is the time to set up the following: The localization processes and workflows, including decisions on what CAT environment to use, or who reports to whom and in what cases. For instance, how the work of Support will be organized and automated, and will it be multilingual or in English only? Documentation such as templates, checklists and rules, style guide, onboarding guide, language vendor scorecard, or the “Project localization Bible.” You can also start compiling a glossary: even though there’s no full source text available, some of the key terms are already known. A reference system for context. If you can ask the development team to leave some notes for text strings, all the better. The precious information on game logic will help localization teams a lot, even if there’s going to be a full-scale linguistic testing. A draft of the testing plan. At the linguistic testing stage linguists verify in-game texts and overall game performance (such as the correct response of game elements to user inputs). A testing plan will help to get the most out of this stage. If it seems hard to draft it at the preparation stage, you can at least think of the environment to use. Will your testers report bugs and upload screenshots in a simple Google Sheet or use an online repository, such as Jira? Advanced companies create special onboarding kits for developers, something like “Globalization 101,” which can focus on internationalization and culturalization aspects, or, for instance, feature common mistakes found in some other games. The alternative is seamless continuous localization. Predefined and tuned processes are a benefit. But what if some of them could be bypassed for good? Open source solutions such as Serge, which stands for String Extraction and Resource Generation Engine, offer a trendy way to make manual localization management (exporting, converting files, sending them for translation, doing reverse conversion, committing changes to version control) unnecessary. The tool gathers new source, publishes it for translation, acquires translations and integrates them back into the product, pulling and pushing changes, and will also synchronize with an external CAT tool of your choice. Serge is being developed by Evernote, which has its products and marketing materials continously localized into 25 languages. This solution is mostly tailored to work with text translations, though. Its effect is not so noticeable in the localization of non-textual formats such as graphics or audio. So if you need to localize these things for a game, Serge will only grant you partial automation QA and testing setup Another extremely useful means of partial automation is QA checks. When a language vendor delivers the job, you can apply industry standard practices such as a third-party review of a sample translation and extensive QA metrics. But in a budget or time-constraint environment it makes sense to at least run a simple in-house check prior to importing localized content into the game build for future linguistic testing. Use QA tools: QA built-in CAT, Xbench or Verifika. QA or at least spotcheck methods should be thought about in advance, as they may and most certainly will be another expense item. Prior to actual QA, a handy approach for advanced teams is to build a pseudolocalization tool for the mobile application testing. Even MT helps get a view of the localized product. And this might lead to useful proactive design changes. In addition to linguistic testing, some games can afford to invite focus groups to actually play the game. Their gaming experience is recorded and analyzed to evaluate their playing habits, if and when (and why) they face any difficulties in the game. This type of testing, though, belongs at the final stage of the project. Budgets and legal matters To dive into the localization stage at full speed, one must come prepared. And this is almost impossible without having agreed on who would actually do the job. So test the waters with localization vendors in advance. Communication with vendors prior to the actual project’s start will help with calculating localization budgets (advice: add 15-20% for unforeseen expenses, especially if there is a voiceover planned on the project), and avoiding delays in production due to any possible legal issues. Early collaboration with your legal department on setting up vendor contracts will streamline your future mutual localization efforts. Each new language, though, generates additional costs associated with globalization, as you would likely need to invest in social media localization and tracking reviews in app stores. Feedback collection Speaking of reviews, you can actually start gathering feedback from gamers related not to your game but to similar ones. Search for competing games and pay attention to the comments and ratings in app stores. There’s always something to learn: if the errors themselves aren’t useful, the root causes for them will be. Another smart move is to make it easy for gamers to leave feedback in the game itself. But if you’re conducting a survey, for example, you should give an incentive, maybe by providing an in-game currency per reply. This is something to discuss with development and design teams, especially considering the multilingual background of the users, but any way to thank a user for informative feedback adds a nice touch. (Yearly) plan and user engagement Continuing on user engagement, the #1 thing to include in the game plan for the next year is culturalization. 2018 saw a trend of labeling culturalization as a fictitious step created for demonstrative localization activity purposes only, which some localizers get offended by. They’re putting their hearts into making the game content viable and meaningful. And to make content meaningful, it pays to ask questions. So open discussions inside and even outside of your team that relate to plot, characters and objects during the conceptual stage, which will help identify cultural patterns and possible issues. As The Game Localization Handbook says, culturalization is all the more effective the earlier it’s applied to game content. The same could be said about the planning itself. But it’s even more fun to make amendments to the plan in the localization process. So with all due circumspection, let the game begin!