I was listening to Jon Skeet's talk at the last StackOverflow Dev Days and he piqued my curiousity regarding internationalization.

Suppose I have a waffle-making program, either complete, or still in progress, and I want to distribute it to other countries. What kinds of things do I need to worry about regarding internationalization? What are some un-obvious but easy pitfalls?

  • Sorry about the 3 edits but for some reason removing one tag replaced another with "java".
    – ChrisF
    Commented Jun 27, 2011 at 20:14
  • I personally thought the jon-skeet tag was funny.
    – rlb.usa
    Commented Jun 27, 2011 at 20:15
  • 1
    It may be funny, but it's not particularly useful
    – ChrisF
    Commented Jun 27, 2011 at 20:15

9 Answers 9


The most obvious thing that springs to mind is that your labels will most likely be a different length to the English version. This could play havoc with your layout.

You could either end up with acres of white space or labels crowded in and even overflowing the space available.

You need to make your layout flexible and flow regardless of the size of the contents. Having a layout that can cope with different screen resolutions will go a long way to solving this problem.

The other big issue is right to left language support. This will again require your layout to be flexible.

It's not just the menus and dialogs that need translating. It's all the support documentation, help files, tool tips and window title captions as well. There's usually a lot more text than you realise in an application and there will always be a few strings that were added directly rather than as resources.

  • With out a doubt, word length is the most difficult part of internationalization. German technical words have a tendency to be about 2.5x longer than their English counterpart.
    – Dave Nay
    Commented Jun 27, 2011 at 20:24
  • e.g. the English word "note" can be translated to "Aufzeichnungen" in German. A previous employer, we used different CSS layouts depending on the language that was being displayed. Check out CSS grids like YUI Grids or BlueprintCSS. Commented Jun 27, 2011 at 20:39
  • PLEASE do not forget to translate error messages also! Commented Jun 27, 2011 at 21:44
  • @Andy - that's implied in the "dialog" bit, but yes worth mentioning.
    – ChrisF
    Commented Jun 27, 2011 at 21:45

Timezones and date formatting! When dealing with applications where scheduling dates and times across timezones, make sure that you do things right.

Persist ALL date and time values as timestamps as they represent a single point in time. Further track timezones as you will need the timezone information to correctly display the timestamp in the correct format for the user.

I am working on an application right now where a user in Japan could schedule a date and time for a user running a client application in Idaho. Making sure that when the user sees 3:00PM that they know which 3:00PM that everybody is talking about.


Numbers. Most of the Europe, South America use comma (10,23) as a decimal separator while the rest (UK,US etc.) use period (10.23).

  • 4
    I know this is a link to Stack Overflow, but it's still good practice to summarise the content in your answer.
    – ChrisF
    Commented Jun 27, 2011 at 20:16

Remember that just because a person is in a particular country doesn't mean that she knows that language. The language and the location are two different issues.

  • 1
    Those geo-location language back-ends which are so popular these days are such a bad idea! You try being a Norwegian living in a French-speaking area of a predominantly German-speaking country (Geneva, Switzerland). The Accept-Language header is there for a reason!
    – l0b0
    Commented Jun 28, 2011 at 13:13

It's not always that easy... There are lots of things to consider, depending on the complexity of the software you are developing, and where you are going to ship it. In fact it might end up just about anywhere, so the important thing is which locales are you going to officially support.

  • Obviously, there's the language of the interfaces. All text you use should relatively easy to change for its equivalent in an other language. Like someone pointed already, the length of labels will vary. Something written in Chinese won't take the same width as something written in German, for example. Lets add that non only the basic interface is to translate, but all info bubbles, help files if any, error messages, maybe not log files, but it depends on the application I guess. If your application supports languages, your website might want to catch up too.
  • Character encoding. It's good to provide many languages, but how are you going to do that? If everything is programmed with a narrow/basic character encoding, you will have problems with some accents and most languages which are not using our characters. Think of Korean, or Arabic. I guess someone would have to use Unicode as much as possible.
  • Widget disposition / window orientation. If you choose to support Arabic, for example, you will need to think about a way to more or less flip your interfaces. They're reading from right to left, so it would be normal to have labels on the right side of the element they describe (textbox for entry, for example).
  • Number formatting. In some locales, there is a comma instead of a dot to separate the fractional part from the integer part in a number. That one is pretty obvious, but depending on the application domain, there might be lots of other things to consider. Are negative numbers between parentheses or with a '-' in front of them? Are thousands separated or not, with a space or with a comma? Is the separation of digits always by 3, or is only the first group by 3 and the rest by 2? Are you using Arabic numbers or Indian, or others?
  • Date formatting. It's almost as complicated. You might have to store the full names of days of the week, of months of the year, and all of them abridged too. What ordering are they using (day, month, year? month, day, year? year, month, day? etc. etc.).
  • Time formatting. 24 hours or 12? ':' or 'h'? ':' or '.' for the seconds? I don't know much about time formatting, but I guess there are plenty of unknown to me ways to display time.
  • Graphics! If you have icons... You will want to verify not only that the letters or words on them are still meaningful for all locales, but that the symbols you use are also meaningful and still correctly oriented. If an arrow pointed left in the English version, you have chances it should point right in the Arabic version (but not necessarily!). If you put up a stop sign as a red octagon on your icon, people in some locales won't have a clue what that is for, or worse, they will be convinced it should be doing some other things than what you intended and programmed.
  • If you have to deal with addresses in your system, they get awkward in some places too. Great headaches if you have to validate them.
  • Etc.

Happily, there are libraries in many languages to take care of a good part of the work. When you don't have a good library to do that, you will probably want to define parameters for all your locales and define them in detail using XML files or other types of configuration files (or in a database if you ship one with the software, or if you don't mind adding a small footprint one).


It depends a lot on the platform you are using. .NET supports Resource files which can be changed in and out depending on the customer's build.

Other issues which may or may not be supported in your platform include the ability reverse the order of labels and text boxes (some cultures prefer the labels to be on the right). These same cultures may want all text blocks to read from right to left.


Don't forget about values in lookup tables! Order status names, type descriptions, et al.

if you have descriptions and names in lookup tables, e.g. { OrderStatusId, OrderStatusName, OrderStatusDescription } these will also need to be translated.


Pick up a copy of ".NET Internationalization: The Developer's Guide to Building Global Windows and Web Applications" by Smith-Ferrier.

I recently was assigned the task of thoroughly thinking through the whole i18n issue with our suite of apps.

This book brought out issues I never would have thought of.


In addition to the above, consider date formats, spelling and screen orientation control. In reports where languages are read right to left, you need to worry about indentation direction. Weekend vary across countries. If you are displaying calendars you need to make sure that the weekends show correctly. If you are not using MS-Windows, check about features in client OS regarding handling collating sequences for sorting and how does the OS. Error messages must be translated to users when the mode is not English. In the code. For the database side, you need to select the correct character codes. This varies from database to database and may affect date comparisons.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.