Motley says: "Developing international software is really, really hard. We need a brand new version."
Summary
Motley: Developing international software is really, really hard. We need brand new binaries to ship in other languages.
Maven: Follow these tips when developing for international markets: design for one worldwide binary, ensure the software is globalized, do not build strings at run-time, expand UI labels by 40%, and test with pseudolocalized builds.
______________________________
[Context: Motley is a little shocked that the marketing team has asked the development team to produce a non-English version of the software they just shipped]
Motley: Arrrrrrggggghhhh. I've had it! We spend all this time shipping the first version of our software in English, and now the marketing team wants us to ship a Japanese version to expand our reach. I don't know the first thing about shipping software in languages other than English. It's too hard to do if you don't speak the language. We are going to have to hire a vendor to fully create a new version.
Maven: Calm down, Mot. It's not so bad. If you designed the software correctly from the beginning, shipping in another language really is not that difficult.
Motley: Okay, don't keep me in suspense. How does one "design the software correctly from the beginning?" I have to admit that we were not thinking about shipping an international version, and instead focused on getting the thing done as soon as possible in our default language - English.
Maven: There are various keys to shipping software in multiple languages. The first is to have one worldwide binary.
Motley: How can we ship one binary? If we ship English and Japanese, that will mean two different binaries that we have to build and distribute. Use your head, Mave!
Maven: Actually, no. Ultimately you want one executable for your application that is used regardless of what language is displayed in the UI. The user can potentially set the locale via the Windows control panel to switch languages, which does not change the .EXE that gets launched when the application icon is double-clicked. What does change, however, is what strings are loaded by the executable.
Motley: Ah, of course. That's what I meant. And, hmmmmm…. Fortunately we did use resource files for the UI strings for the most part to make it easier on the user experience people to make sure we developers who don't talk good English get our mistakes fixed.
Maven: Nice play on the grammar, Mot. The other benefit of being able to pass the resource files to user experience people is also being able to pass them to localizers for translation to other languages like Japanese. To do this, however, you need every visible user string in those resource files. Did we do that?
Motley: Well, probably not every string. We'll have to do a scrub of the strings. Shouldn't be a problem though. So that's it?
Maven: Not necessarily. You have to follow a few other rules. Firstly, do not build strings at run-time.
Motley: What exactly does that mean? Let's take a simple example: if I ask the user for their name and I want the software to say "Hello", I have to do something like: "Hello" + name. No real way around that.
Maven: Yes, that type of functionality is often required. However, there are better ways to put strings together. For example, in C# you want to do something like:
string.Format("Hello, {0}", name);
But remember, the string above is actually taken from a resource file. That gives the localizers the opportunity to change the positioning of the token in the string to match the language being translated. Some languages may force different locations of the name in the string. If you build the string in code with the '+' operator, the ordering is compiled in and you have to rebuild (and generate another binary) to change order if another language is "<name>, <hello>" instead of "<hello>, <name>".
Motley: At least the solution is easy. What else do we need to do?
Maven: Another big rule is to expand your UI labels by approximately 30% to 40% in length. In some languages, like German, a typical phrase has many more words/characters than the equivalent English phrase. As a result, just because your UI looks great for English does not mean that text will not be clipped for other languages. Have to be careful there.
Motley: Rules, rules, and more rules. Can't we just abbreviate for the other languages? I am kidding of course.
Maven: Additionally, don't forget that you should not make any assumptions about sort order, date/time formats, currencies, and other international differences. For your software to be truly globalized, it must work with any culture - even when Windows is set to display right-to-left instead of the standard left-to-right.
Motley: One thing at a time. Let's just focus on making v1.1 localizable (translatable to other languages) and globalized (functions correctly in differing cultures). We will likely have to make small modifications to our designs to accommodate this. But here is another question: I don't speak Japanese, so when we have a Japanese version available, how am I supposed to debug it? I want to avoid constantly switching between a Japanese and English build.
Maven: Great question. For initial testing that finds the vast majority of problems, as well as easier debugging, we can create what is called a pseudolocalized build.
Motley: Pseudo-what??
Maven: Pseudolocalized. We take a build that is localizable, and automatically insert some more, well, troublesome characters. We could insert accented 'e' characters to replace the 'e', as well as other characters that are similar to their English counterparts, thus still making phrases readable. In addition, the lengths of the strings are expanded, and each string starts with a delimiter character like '[' and ends with ']'. If you see a string in the UI that does not start and end with those characters, then you have a clipping bug. Pseudo-localized builds really help nail down international problems early in the development cycle.
Here is what a pseudolocalized application could look like:
Motley: Very cool. A lot of it looks like gibberish, but is still English-readable. The UI contains a lot of the characters that can be troublesome given the wrong font choice for the UI. I can definitely see this technique saving lots of bugs prior to check-in, provided the developers can generate a pseudo-localized build on their own.
Maven: Exactly. Since pseudolocalized builds really only require processing of resource files, they are generally easy to generate. The are tools out there that can do it for you, or you can write your own text processor to do simple string expansion and replacement. It's a valuable tool.
Motley: Good tips for a change, Mave. I guess we have some work to do to really make our software internationalized, but I don't feel it will be a lot of work given the choices we have already made. I better get to work!
______________________________
Maven's Pointer: There are lots of other tips to creating good international software, from requirements to development to testing. As a developer, it is little extra work to make your application localizable and globalized. Do this work up front - trust me. I was on a software project that lasted 6 months while we moved strings around. Not exactly fun work. If we had followed the tips above, avoided text in graphics (hard and expensive to translate), and avoided hard-coded user-visible strings in the code, we would have been in great shape to ship in multiple languages. Do it right the first time, and take the very minor hit to the schedule that comes with it.
Maven's Resources:
-
- Developing International Software, 2nd Edition, by Dr. International, Microsoft Press, ISBN: 0735615837, November 2002.
- NET Internationalization: The Developer's Guide to Building Global Windows and Web Applications, by Guy Smith-Ferrier, Addison-Wesley Professional, ISBN: 0321341384, August 2006.
- Wikipedia entry on Pseudolocalization: https://en.wikipedia.org/wiki/Pseudolocalization