If I want to deploy my software internationally, what architectural considerations should I take into account?

Question

I'm planning on developing software for the international market.

What architecture decisions should I consider other than just converting the text from one language to other?

Answer 1

Legal ramifications. Microsoft is going through that with the EU right now.

It's also not enough just to 'convert' the text from one language to another. Different cultures have different specifications: In certain parts of Canada, french must be above the english translation for anything.

Answer 2

1. Research and understand your platform's support for localized software.
2. Work within your platform's tools to meet your required behavior.

We can't really get into specifics when we don't know if you're working on a Mac or an embedded system for a microwave.

Answer 3

Work with resource files for any text displayed in your application. That's going to make things a lot easier when doing translations for other countries.

Also make sure that your controls/layout are able to handle with different text lengths/widths, because a button text might be much longer in one language than it is in the original language for which you designed/created the app.

Answer 4

There's no information about the type of project you're working on here but...

1) Make your resources easily deliverable to the translator. This is very much dependent on the environment that you're working in of course but most have some clean way of doing this. Set this up early to avoid massive conversion projects down the line.

2) If your environment allows, it would be good to make it possible for the UI in which the translations will be contained to be configurable on a per-language basis (e.g. dialogs). That way the translator (or you) can tweak the chrome to fit the language. This avoids clipped text in some languages that are much lengthier than other languages. Or, worse, I've seen UIs implemented such that there's huge spaces between controls to account for those verbose languages (I'm looking at you, German). Lowest common denominator implementations should always be a red flag.

Answer 5

• Take into account nuances of language. For instance 'homely' means comfortable in some English speaking areas and ugly in others
• Also take into account culural differences - thumbs up is not a good thing everywhere

Answer 6

• Make sure your application passes The Turkey Test
• Make sure you have people that know not only the language of targeted countries', but their culture and maybe the slang so you don't name your app nor any of its components in a way that majorly offends someone
• Make sure people working on graphics know how to properly draw the country flags and know world geography, so you either don't offend them or e.g. drown any country.

Your software must be localizable in a way that it's easy for the translator not only to translate the text in the GUI but also tweak its appearance so the text actually fits there without problems.

If your software uses any online services, make sure it uses the target country's one, so a German user doesn't e.g. get offered an online photo printing service located in the US.

Answer 7

There are a huge number of issues, depending on how far you are interested in going.

1. Numbers - both in thousands and decimal separators. In fact, not all locales use a separator every three digits. And the rules for writing out numbers as text, say for writing checks, vary considerably.
2. Currency and Measurements - not all currency has two digits of decimals. The sign can be leading or trailing. The indicator for negatives can be a sign, parentheses, or leading or trailing text (like "dr" and "cr" are sometimes used in US English). Similar issues for measurements (English vs. Metric vs. local).
3. Language script - it's not always left-to-right, top-to-bottom. Unicode is a must. Also, text layout changes by language. The same text can be shorter or much longer when translated, which means forms must be flexible.
4. Literal strings vs. Translatable strings - some text is literal and won't be translated; it's helpful if you design for that up front and make sure translatable strings are handled consistently (via resources or whatever is available). You'll also want to template strings like "abc {1} xyz" or "abc %1 xyz" for insertion text instead of doing "abc" + n + "xyz", since the place that the inserted text goes will vary by sentence structure.
5. Date and time - Not every country uses the same calendar; some have different year counting systems. For some fun, dig through the java.util.Calendar or System.Globalization.Calendar classes sometime.
6. Icons and Colors - What looks like a grippy hand in one culture may be an offensive gesture in another. And colors have different meanings as well.

Internationalization (I18N) can be a big deal, but it's not overwhelming. Pick your scope, and then dive in. Once you get the first couple of locales done, it gets easier. :)

Hope this helps.

Answer 8

You have completely failed to provide any information on what sort of software, or what platform. On the other hand, you sound like you're going to write the software, so you aren't stuck with bad decision already.

What will matter most is the display, so keep the display functionality separated from the rest. Do not, repeat do not, hard-code any strings. They need to be kept in a separate function table, with as much context as you can easily provide. Do not hard-code display layouts, particularly as English is a very terse language for most purposes, and most alphabetic languages will generally require more space to say the same thing. Be wary of doing anything with case, since uppercase and lowercase do different things in different languages. Make sure you're using Unicode for all text the user might possibly see.

Bear in mind that exception strings should be kept uniform, if you're using them, and error messages to be logged may be best kept in English (or whatever your native language is), depending on whether you or the locals are going to be examining them.

Whatever system you're working with is likely to have some sort of locale facility. Use it for everything it handles. You don't want to be writing out, say, February 9 as 2/9/2009 in Britain, because they'll read it as September 2. People will understand writing a million out as 1,000,000.0, but for some people that's a clearly foreign construct, and they want it as 1.000.000,0.

Try to avoid embedding numbers into sentences. In English, one would say "1 page printed" and "2 pages printed", and likely "No pages printed". In other languages, things get real complicated. Something like "Pages printed: 2" is much easier to translate.

Make sure the users can use the metric system and Celcius temperatures. Either use metric throughout, or convert it in the display layer.

Get real translators for every place you're going to be localizing to. Google works great for initial mockups, but you probably want to sound more literate in the countries you sell to than, say, "All your base now belong to us". Make sure they have enough information to do the job; some words and phrases in English are ambiguous, and the meaning depends on context, and therefore they may be impossible to translate without context. Budget for some good translation software, if available for your platform. Translators aren't cheap, and spending a few thousand dollars to help them work faster will pay off fairly quickly.

If possible, get somebody local to beta test the localized version, and pay attention to what he or she complains about.

That's what I've learned by now, and I'm slowly getting our software usable in Japan.

Answer 9

There are two sides to internationalisation: culture and language.

Language is the most obvious, and the other comments here summarise that well.

Resource everything visible to the user, including error messages. Make sure you have enough space in your design for e.g. German-language prompts that are up to twice the size of English. Ensure that numbers and dates are displayed appropriately. Toolbars and display artifacts might need to be reversed for right-to-left cultures.

Subtler in many ways are the cultural differences. This needs to be considered right from the start, as some will affect the way that you design the software. For a start:

• What kind of work flow is expected? Some cultures (such as Spain, Italy) are much more collaborative than others (such as Sweden or Finland).

• Are the expected customers of the software going to use it? In some cultures (e.g. the Middle East) there's a strong bias towards managers not having access to computers at all. Rather, their staff read mail on their behalf.

• The local software ecosystem won't necessarily match Western norms. For example, local social networking sites may be more popular than Facebook and Twitter.

If you're expected to sell software in non-native markets then these factors will all need to be considered before coding even starts. There is a well established infrastructure of product marketing specialists that can help with local perspectives of this kind.

Even for in-house IT applications it can be worth engaging with local users to determine the specific needs for their software. Managers in branch offices outside a company's principal country can sometimes resist implementation of systems that don't match their cultural norms.