Jump to content
  • Advertisement
  • entries
    1212
  • comments
    1738
  • views
    1144724

Chinese games and localization hints

Sign in to follow this  
johnhattan

754 views

Been spending the last few days localizing, as Mochimedia (now owned by a Chinese company) offered free localization services for any customers who wanted to release their games in China.

I'm not sure exactly when my games will start popping up on Chinese sites. But until then, you can check 'em out.

BaffleBees
ChessCards
Ballistic Balloon Baboon Bounce
Brain Bones
ConFusebox
ConFusebox 2
Countdown Dice
Double Twelve
Head On Collision
Meltdown
Olive War
Poker Patience
Pop Pies
Pop Pies 2
Pop Pies 3
Shi Sen
Think Tank
Voracity
Worm Sojourn
Zombie Kitten Attack!


Now here's some tips on translating your games. This is my third or fourth time translating a whole pile of games into another language, and here are a few things I've learned.

1. Don't overengineer the process. Chances are, your text is going to be passed along to an entry-level writer, so don't make the process needlessly complicated.

At one company I worked at, they built a whole Java-based database of their text, with every string tagged with a language, and then a nightly process would convert the database into a series of source files that the game could read. They then gave their translators access to the database with the thinking it would make everything easy and automated. The job got done, but it wasn't easy for the translators.

When it came time for my project, I asked if I could just paste all of my in-game text into an Excel spreadsheet and email it to 'em, and they were THRILLED.

2. Plan to make a couple of passes at it. Inevitably, something won't sound quite right in practice, and you'll need to make another pass or two with the translator until everything looks right.

3. If you have something poetic or idiomatic or something else that just won't translate well, offer a more "literal" phrase that will translate better. For example, in my game "Brain Bones", the big button to roll the dice says "Roll The Bones". While the phrase "Roll The Bones" can be readily translated into another language, it's likely does not still mean "throw the dice" in that language. In such a case, provide alternate text that's free of nuance. . .like "throw the dice".

In the case of my game text spreadsheet, I had two columns of text. One contained the actual in-game text, and the next column contained alternative text if I felt the in-game text wouldn't translate well.

Ditto for alliterative text. While "Ballistic Balloon Baboon Bounce" can be translated literally, it will sound horribly stilted in another language. So I offered "Bouncing Balloon Game" in the alternative-text column. Between the actual and the alternative text, hopefully your translator will be able to come up with something reasonable.

4. It's monkey-work, so take it slowly and methodically. Translating is mostly just cut-n-paste, so take some time and be careful about it.

5. Test everything to make sure it all fits once you're done. This was a much bigger problem with German than anything else, as Germans will happily construct a single word out of several words to create a 30+ letter monstrosity that'll fall off the edges of your dialog boxes. Look over everything and make sure it all fits.

6. Make everything clear to your translator. Hopefully your translator is a native speaker of the target language. If so, that means that they're NOT a native speaker of your language and they might trip up on stuff that sounds fine to you (like "PRESS THE A KEY") but doesn't parse in their "not thinking in your language" brains. Make it clear to 'em that you're available and you're happy to provide more literal text if they need it.

7. Don't get married to your fonts. The "Baby Kruffy" font I used in Ballistic Balloon Baboon Bounce doesn't have Asian characters. Heck, it doesn't even have lowercase! In fact, you'll notice that all of the Chinese characters in my games are the same font, Microsoft YaHei. It's a boring font (it's Arial with a full Asian character set), but it is a "safe" font that's guaranteed to look right on all of the computers the games will use.

8. Account for time zones. My afternoon is China's middle of the night and vice-versa, so I wasn't in a hurry.
Sign in to follow this  


6 Comments


Recommended Comments

I've been through localization of a few games and it is never fun. German always messes things up :p Spreadsheets for the win, though. At the last company I worked for, a 3rd party Wii and DS developer, we used Excel spreadsheets that we just exported to CSV. A tool would process the CSV files appropriately for the game. As a designer entering text strings, I found it nice and simple :)

Share this comment


Link to comment
Yeah, the last place I worked did localisation the same way as zer0wolf mentions.

Simple yet effective system.

It tended to be broken down to the following columns;

[ID value] [english text] [descriptive version] [optional char limit] [other] [languages] [followed] [after]

Share this comment


Link to comment
I've done the localisation (Well, handled getting it in-game) for our past few games. We have an Excel spreadsheet with all in-game text, comments, character limits, etc in it, and a macro I wrote to export each language into a binary format the game parses.

That also gives you the ability to do things like highlight cells that exceed the character limit or to warn about / convert bad characters (Such as the '...' character MS Word uses, and newlines (Which you generally don't want)).

Share this comment


Link to comment
I actually enjoy localization, and one of the reasons for enjoying it is that I avoid Excel spreadsheets at all costs. I've done several games for Microsoft, with up to 19 languages in the one title including Traditional Chinese, Simplified Chinese, Japanese and Korean. We use XML or RESX for localized text, one file per language. Microsoft loc teams specifically state that they do not want Excel spreadsheets for localization purposes. The big advantage is that you can easily diff text-based files in source control to see what changed. Spreadsheets are usually binary files that do not diff well, if at all. Our games use the XML or RESX files directly, so there is no copy/paste involved at any stage in the process.

If you are copy/pasting text as part of the localization process, you're doing it wrong. That poses a large risk in copying something wrong (so easy to do from prior experience), and because the text is in a language that you usually cannot understand it is very difficult to see which strings you messed up.

It is useful to include a short description of the string in the file to put it into context for the translator. This can help them understand how the text is used which may change how they translate it.

It may be tempting to re-use the same strings for different purposes in your game, e.g. a screen title and for a button. Don't. Text that may be the same in your language for different purposes may be two or three different strings in other language, depending on the context of use.

Provide a fall-back path. If you are supporting French, support the neutral culture "fr". Some strings may be different in Canada, so provide the Canadian-specific strings in a "fr-CA" culture. Strings not in this specific culture should fall back to using the neutral "fr" culture.

Share this comment


Link to comment
Some other things I've found doing localization:

(1) Plan on changing some graphics. Each language takes a different amount of space, so buttons and menus and other text containing graphics will often be too small or too big in relation to the new text. Character limits might help with this too.

(2) Avoid baking text into graphics. Artists like to sneak that in to give the text a bit more "pop," but that quickly becomes a nightmare.

(3) Definitely, definitely plan on using string tables from the get-go. As Sly said, it's really easy to make copy-paste errors. Conversely, if you've been referencing into a string table the whole time, typically you can drop a translated string table into the right place and it will "just work."

(4) Bitmap fonts sound great until you have to translate to an Asian language. The game I'm currently working on has about 9+ bitmap fonts. I ran some analysis on the final localized text, and it uses roughly 1190+ unique characters counting Kanji - too many to squeeze into a single bitmap image that meets our size limit. It's a bit of a mess; if at all possible, avoid this.

(5) If you're constrained by what languages you can get a game into, it's worth doing research to discover what regions are actually looking at your game. I just translated a game to Spanish, and not a single person in a Spanish speaking country has purchased it.

(6) This one's a bit specific - it's actually valuable not to localize too much for your first version of an XBLIG game. The peer review system requires people speaking those languages review the game, and this doesn't always happen, leaving your game in limbo for a while.

Share this comment


Link to comment
At the global year of 2010 its mandatory to make sure texts are saved to a unicode file. Without doing it you may end up major problems if there is western, east-europe, far east languages at hand.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!