Test the rest

It’s finally about time to say something about my new job. As I already mentioned it is a project based job, and slow but steady we are about to reach the end of our project.

The company in which I am working does so-called linguistic video game testing as briefly mentioned in week eight. Times in which we get video games only in its origin language are fortunately over since the nineties. Games are being translated and adapted to their respective markets. This process is called localisation.

Just translating every manual and game texts won’t suffice here. Every culture comes up with small but mighty distinctions which can lead to big misunderstandings or even provocations if adapted inadequately.

Some examples:

Cultural or history-bound distinctions

A move in a snowboarding game is called Super 9/11. Needless to say that the name will be changed for the U. S. market.

Measures

Whereas in Germany, Austria or Switzerland the metric system prevails in the U.S.A. or U.K. gallons, degrees Fahrenheit, feet and miles are used. The adaptation does not mean a problem when translating it in texts. But for speedometer and thermometer – scales which need to be calculated in real time – complete new algorithms have to be programmed.

Poems and puns …

… are certainly one of the biggest challenges of a localisation translator. On one hand one would like to preserve the rhyme or the wit but on the other hand, logic should not fall by the wayside. A problem which is also linked to the film industry. Here an example from the film ‘the downfall‘:

Drunk German soldiers in bombed down Berlin:

Hey Berlin ist die Stadt der Warenhäuser. Hier war ‘n haus und da war ‘n Haus.

Hey Berlin is the City of ware houses. Here were houses and there were houses.

Poems or lyrics from Disney films are often mentioned as paragons for localisation work.

The localisation happens almost simultaneously with the creation of the base frame of a game. So relatively early in the development phase. After all the script has already been written so that the localisation agencies can begin with the translation work. And this is how the programmers don’t just work with a single version of the game from the very beginning but in all versions in which the game will be released.

This is where the localisation testers come into the play. Our task is to check every dialogue, every menu, the whole content which was translated and adapted on semantic, grammar, formatting, terminology mistakes, misspellings, or culturally conditioned mistakes.

Theoretically now every game tester would have to complete the game including all menus and sub menus. So that the publisher does not have to pay too many hourly rates to us testers we are being given cheats by the developer with which we can win or – should the test require it – lose at the touch of a button. Also we receive cheats with which we can select all the levels directly.

By and by it should be getting more clear how linguistic game testing works. But how does it look in detail?

Games are being tested on so called debug consoles which are only available for the studios and can only be purchased by the manufacturer directly. With this systems it is possible to run games which are still in their development stages. The single version of a game in development is called a build. As soon as the first build is on the table the team arranges who is going to test which game mode respectively and which menu including sub menus. This way every language forms a team which single members sit in front of on their respective platforms (PC, console, handheld). Because no full priced game is being developed for a single system any more these days except for exclusive titles.

What kind of bugs are there? To answer the question briefly: many! Too many to be mentioned altogether in this text. But the most essential shall be mentioned: crashes, freezer and blocker.

Crash

As the name indicates the system simply crashes at a certain point of the game.

Freezer

The same here with the name. The system simply freezes at a certain point of the game.

Blocker

One is caught in a certain situation or menu in the game, might be able to go some steps forward or back, but can’t escape the situation as something was simply not considered during the programming. The program runs consistently stable but the player is given no other choice but to turn off the system.

All bugs of this category have a high priority and must be fixed before the release. Even if those bugs don’t have a lot to do with language they will also be reported by linguistic testers as they hinder the tester to proceed with the testing. However the linguistic testers priority is to check all the game texts.

The following bugs are the most important ones:

Incorrect string,

translation or

incorrect formatting.

Are the translations placed correctly in the game? Are there any misspelt words? Were some texts forgotten or are there some place holders or even the texts in original language at some spots?

Formatting mistakes are being given a lower priority. An example would be that a text is being displayed correctly in a text box however shown squeezed as it is simply too long.

Also it has to be checked if at certain spots the right symbol or letter graphics are being showed. Testers ‘biggest pleasure’ regarding this is the Nintendo Wii at the moment. Because all menus have to be checked three times. Why? The Wii has three different joy-pad interfaces. The old Gamecube joypads, the Wii-mote together with the Nunchuck or the classic controller. So every menu has to be checked that the associated button graphics are being displayed correctly depending on which input device is being used. And of course graphics do also have to be checked regarding their system affiliation. Nintendo wouldn’t be flattered at all if the menu in one Wii game were to say: ‘Press the X-button to proceed or the O-button to cancel’. Also a certain text might be very readable on a high resolution Play Station 3 or Xbox 360 version. The PAL or NTSC resolution of the Wii might only show a blurry line. This is where the so called cross-check goes into play. After extensive testing the bugs are checked at the end of the day if they can be transferred to other plattforms or language versions. Most of the time blockers can be reported for all versions as it is inevitably a mistake which happened when programming a situation, which is to say that it will be the same in all versions. It becomes more complex with freezers or crashes. Does the system freeze because the code is insufficiently adapted to its system or because of the fact that a mistake was made when programming the base frame? Was a line only translated incorrectly in the German version or did someone make a mistake when compiling the script and all versions show the wrong string at a certain spot?

Why does one test a language’s menus during the development stage at all? Wouldn’t it be more simple to finalise the game first and to check everything at the end? One might think so, however, there are situations which can be explained in one language with only one word but might devour three lines in another. It won’t happen that a wider text box is programmed for only one language version. Either the text box will be enlarged for all language versions or one will try to shorten the text in that version in which the text is too long. So errors do occur which require code changes. Hardly possible with a finished game. Also it happens that some menus change after the localisation or menus or areas are added subsequently. Most of the times these translations are done by the linguistic testers and not by the localisation agencies any more.

How does it go on with the reported bugs now? Most developers use an encrypted online database to monitor the development progress of their products. Its advantage is that the progress can be checked from anywhere in the world. This is how the developers may sit in Canada for instance whereas the testing studio might be located in Japan. The development team now has the bug report and starts with the corrections. As soon as the bug is being wiped or the programmers think they have cured the error the ball is being passed back to the testing team. Because even if the bug is described in detail it is not always plain to see if a bug was really fixed. So when the testers then received the list of the fixed bugs they are checked if they are completely eliminated. If there isn’t any recognised change or the tester declares the alteration is insufficient the bug remains in the database or is enhanced with a more detailed description. This procedure is continued until the last bug is being fixed.

What atmosphere prevails in such a company? At first glance, somewhat deterrent might be the fact that you don’t have access to any area without an RFID chip key card. Also every tester has her or his own locker as any kind of data carrier has to stay outside the office. That is valid for mobile phones as well as for mp3-players. Cameras are an absolute no go. And communication with the outside world? The office place of the video game tester is one of the rare ones which copes without a phone. Emails can only be sent by the administrator authorised mail addresses. And who was hoping to gain further recreation during breaks by checking out XXX-web pages will be grievously disappointed. Even here only admin authorised pages can be viewed. Damn it! … In other words it is quite difficult to smuggle the testing game onto the internet or outside the office.

And what kind of working atmosphere prevails? Tester are young folks, rarely over 30. Who would like to keep up her or his second language(s) an passant rejoices to receive a free conversation course with this job. The Italian girls are wondering in their language about Berlusconi’s latest achievements, the guy behind me almost walked Spanish on me, and to my left someone is cursing in French. In other words we are weird folks. But we like it to be weird.

What qualifications does one need for such a job? Of course good native language skills. Because you will have to pass a ten page (!) long test at the job interview at the least. All bugs are being reported in English. Thus you should have good English skills as well. The job interview will be in English. As in every office job, good office software skills are required. And last but not least you should know how to hold a joy-pad correctly of course. The introduction to the database is quickly learned. Graphic or video editing programme knowledge is a plus but can also be conveyed within the first working week.

What salary/wage can one expect for such a job in Japan? It can vary depending on the region of course. It shouldn’t be below 1.300 yen per hour. In general wages fall around 1.500 yen per hour. Testing happens full time in a 40 hour working week, with a high volume of work even on Saturdays and Sundays!

Who now feels like getting such a job and would like to link it with a work and travel/working holiday stay in Japan should check out following links:

http://www.uniconpro.co.jp/de/recruit.html

http://www.enzyme.org/index.php?id=75&L=1

Special thanks to: Hubertus Neidhart from Webspace Provider Network for excellent web page hosting services; Lilith Pendzich, Germany; Brandon Lamb, U.S.A.;