By Hagen Weiss
Game developers can often overlook formatting and punctuation. While it may seem minor, even the tiniest errors can prove costly. Understand these top five formatting errors, to avoid spending additional time and money on rework.
1. Formatting Hard-Coding Text
Embedding text right into the source code is a big mistake. Translators will need to read through lines of code to extract out the text required for translation. This makes translation extremely time-consuming and cumbersome.
Instead, input your text into separate resource files. Things like your product name, titles, descriptions, error messages, etc. should have a unique identifier within its resource file. These resource files will then be sent to your translator for translation.
2. Ignoring Punctuation Styles Formatting
Not all punctuation styles are the same – even within the same writing script. For example, the French language includes a space right before a question mark or an exclamation mark:
“Stop !”
Most languages do not follow this formatting (including English). Let’s say you translated your game from English into French without considering the French punctuation styling. Your entire translation follows the English styling (i.e. no space before the question or exclamation mark).
This forces you in a difficult situation. Either you spend time and money to go back and fix up all the punctuation errors, or you let the error go, risking poor user experience in the French-speaking market.
Both options are less than ideal. However, you can avoid this altogether by being aware of the punctuation style of the language you are translating into.
3. Using Concatenated Formatting Strings
Sometimes game developers will concatenate strings together based on the English language. Concatenated strings (or linking strings together) make sense to developers because it’s a more efficient way to write the code. For example:
- Color-1 = green
- Object-1 = potion
Developers may be tempted to concatenate these two texts together (Color-1+Object-1), which gives you the string “green potion.”
However, this is generally not a good idea when localizing into another language. While “green potion” might make sense in the English language, it won’t work in a language that has the object come before the adjective (for instance, French).
Either use separate strings or, alternatively, there are simple coding solutions to solve this problem. Consult with a LocQA tester and proofreader professional to see how you can mitigate against concatenated strings.
4. Not using Unicode
The vast majority of web applications and browsers utilize UTF-8 encoding. Simply put, you should too. UTF-8 standardizes encoding across all software and platforms. This standardization helps avoid broken or character errors when localizing your game.
5. Not Including Detailed Localization Notes
Localizers typically do not have access to the source files. Often, they are only working off the localizable files. If no notes are given, it can be difficult for the localizers to understand the context.
Add detailed notes when the translation can be ambiguous. Explain the value of variables within strings. Make a note when certain strings are not supposed to be translated. The more clear your notes are, the easier it will be for the localizer.
iGlobe: LocQA Services for Your Game
Catching all these formatting errors can be both tricky and time-consuming. iGlobe has a team of localization experts who can help you identify these grammar and formatting issues. We offer localization QA services to ensure your translations are of the highest quality.
Contact us today to learn more!
E-mail：hello@iglobe.ca
Tel：+1 604 355 3023