My Love–Hate Relationship with Games Localization

  • 26 March 2018
  • by Michał Tosza
My Love–Hate Relationship with Games Localization

I must confess, I have a love–hate relationship with games localization!


On the one hand, it is always a pleasure to leave CAD software manuals behind and switch my focus to games. After all, games are concrete, tangible products. When I translate games, I enjoy the fact that I usually know the word count of the project right from the start, and I have direct contact with the product owners – the developers coding it. The localization work is tough and demands a lot of creativity, but at the end of the day, I have a feeling of completeness, that which comes with a job well done.

On the other hand, localizing games means I often need to explain to the developers every detail within the translation process, justify my time and financial requirements, and ask them to prepare the source files carefully so that the translation goes smoothly. More than once, I need to beg them to make extra space for localized strings. This is the not-so-fun part.

By now, I have managed to secure almost all of these issues, but I still remember the horrors of sticking to restrictions in string length or having to cut and squeeze my nice sentences in order to fit the character limit. It was tough on many levels, and perhaps this is why I still recall the joy I felt when the developers of a translation software I had been using back then introduced a blessing – a small field displaying the number of characters in a segment. That was a game changer (sic!), since then I can always visualize how many characters I have in each string before I start to translate. But it was certainly even more joy when I discovered I could automate character counting in memoQ. That was a true revelation! 

Why was this such big change? Maybe adding a bit of context helps the same way it does with translation: This was the time when mobile games started to grow in popularity, and the first thing you need to prepare for when localizing mobile games are small screens. In games localization, a small screen equals a low and strict character number.

Another main chapter in my love–hate relationship with games localization are file formats. Whenever I localize CAD software, I am almost certain there won’t be major issues with files. I generally get neat xlz, xliff or ttx files, and the translation workflow is quite simple, at times, it requires nothing more than just dragging and dropping the file into a memoQ project. In contrast, dealing with formats in games localization tends to be trickier, especially when working with indie developers. They have all sorts of wild ideas in terms of file formats, and very often want to localize their games into many languages and use only one file. 

To illustrate what I am mean, let me show you some examples:

Horizontal layout with populated translation fields on many Excel tabs? Be my guest.



Information overflow? Here you are.



No meta-information? Sure.



Bear in mind these are just a few of the many I’ve seen over the years. So yes - such situations turn on the "hate" in my love–hate relationship with games localization.
 
Let's try to deal with such a "problematic file": Imagine a game developer delivers an XLS file containing a strict character limit. The developer also says that file contains separate columns for context and many languages within it. Thankfully, memoQ can help you solve all of these issues.


What do we need to do?

a) Find out how to set a character limit,
b) Import an XLS multilingual localization file,
c) Force memoQ to guard character limits and notify you whenever you exceed them.
 

Now you should follow these steps:

1. Open or create a project in memoQ.
2. In Translation -> Documents pane right click and chose Import with options.



3. Download the following file: ExcelGameLoc.XLSX. You can first have a look at the file to check the formatting. You will see there are several columns, some of which are not for you (in my case, all the columns for languages other than Polish).

4. In the Document import options dialogue click Change filter and configuration and then press OK. In our case, the default setting (Microsoft Excel 2017, 2010 and 2013 filter) is misleading. Why? It would import all contents of the file along with the String ID and names of the columns, and we do not want that. What is more, English strings would be replaced with Polish translations and the source text would be gone spoiling the formatting (please go ahead and check it yourself!). Therefore, we need to change this option.



5. In the Document import settings dialogue click Filter drop-down list and choose the Multilingual delimited text filter. Do not click OK yet. So far, you have only changed the filter, but you still need to configure it because memoQ does not know how to handle the different columns in your XLSX file. Remember this is a multilingual translation, which means there are multiple languages, and you need to place your translations in the correct column and do not break the formatting.
 

 
6. Click new Columns tab. In Define the meaning of columns area, tell memoQ what to do with each column.

7. In this file, column A is treated as context. So click this column and below you will notice that a drop-down menu for Meaning of selected column becomes available. Configure column A as follow: Meaning of the selected column -> Context. Context is a "universal" option, so no further configuration is needed. All the information in column A will be now treated as the general context within the whole translation.
 

 
Column C is Source text, which in this case is English. You do not have to configure source language as this is inherited from project settings.
 

 
Column D is your Target language (Polish in our case). Here you need to apply a special configuration. Why, you may ask, if the target language is also configured in the project settings? Because the filter name is Multilingual delimited text file and you can have many different translations within one file and you need to configure each column for each language (if needed). We do not need this, but nonetheless, memoQ must know what language this column is to be translated into. So pick: Meaning of the selected column -> Translation, For column -> C (as this is the column we chose as Source text), and Language -> Polish (this is what I choose, but you can pick your language).
 

Finally, Column B is the Character limit, so for Meaning of the selected column pick Length limit (characters) and for column -> D. memoQ now knows there is a character limit for each string, but it can also warn you whenever you exceed this limit thanks to the quality assurance (QA) options that we will add right after.
 

 
We are almost done with this dialogue. Only one more setting left – in the General area select First row contains column names. This will stop memoQ from importing column names from the XLSX file. This is rather a cosmetic option in our case (as we have a very simple XLSX file) and you would know which strings in the editor are column names. However, if you are importing a huge XLSX with several tabs and tens of different columns in each one, you might miss some column names and translate them. This can potentially ruin the XLSX file at developer's end.
 

Click OK, and import the file. Open the file in the editor and check if all 3 strings are imported. Your editor window should look like this:



At the bottom of the screen, you can already see that character limits work. But what happens when you exceed them? Try it out and type a translation that is longer than 35 characters.



It turns red. That is useful, but memoQ can do better. It can generate a QA warning (a flash icon, you most probably know), but you need to configure it.

In order to configure the QA settings, click Project home tab, Settings, and QA settings icon.



You cannot edit the default settings profile simply because you may create faulty or unusable settings. Having to create new profiles allows you to delete useless settings or revert to the default one when needed. This "philosophy" of handling options/settings with profiles can be a real lifesaver if you like to experiment a lot and gives you margin to work out different options. In any case, you can always safely return to the default settings which are not editable.

Now you need to create a new (editable) profile. So click Create/use new (at the bottom) profile, name it GameQA and click OK.



Make sure this profile is active (tick the mark to the left of the profile name) and click Edit. In the Edit QA settings dialogue, you will notice quite a few tabs, but we only need to focus on Length. We will return to QA setting and profiles a future post. Now click Length tab and select the option named Check length of the translation based on value stored in the row or in its comment.



Hit OK and return to the editor. Reconfirm your translated segment and you will notice that a flash icon appears.



This is perfect! Now you can safely start localizing your game and all the features and options we configured will help you deliver the best translation.
 
To sum it up: we achieved the results we set at the beginning of the project, and we can see how useful this knowledge is.

1. We have managed to configure an import process for a complex file format. Multicolumn XLS/XLSX files are frequently used by game developers, and now you know how to import them and what settings to choose (and why!).

2. The times when you had to count characters manually are over! You can now visualize the number of characters available/used when translating, and get two types warnings if you exceed this limit: The first warning is the red font in the target source field, and the second one is the flash icon that comes as a result of the QA setting.

3. Additionally, we had a brief look at QA profiles and settings and learnt how the profile "philosophy" works in memoQ.
 

PS: I did not forget about your homework from the previous article where we explained how word count works in memoQ (see article here). You had to count the number of words in this piece of text:
 
John has got a cat.
John's got a cat.
John's got 345 cats.
John has got 23 000 cats.
John has got 23.000 cats.
John has got #### cats.
John
 
The correct result is 30 words. Yes, #### is a word, and 23.000 is one word, but 23 000 is two words. The number of words in a segments = number of spaces + 1.
 

This is third article of the Michał Tosza's series on games localization. On the links below you can find his previous posts: