Localizing Our Software

If you want to sell (or give away) your software in multiple countries, you need to think about Localization, which simply means ensuring that the application can be used in other places. At Microsoft, and in SQL Server in particular, we actually break this into two parts: Globalization and Localization. Globalization has to do with time formats, currency and numeric types and so on. Localization has to do with languages.


SQL Server’s components, from SQL Server Management Studio (SSMS) to Books Online (BOL) are localized into over a dozen languages around the world. One way of handling this requirement is to simply re-write everything in another language. This is how it is done in the documentation sets, since you can’t just translate one word into another language one for one. For the code, re-writing everything to have all the strings you see on the string would be far too slow and prone to error, so instead we don’t actually put any strings on the screen. We use a pointer on the screen that reads the string from a file, and then we translate those string files into all the languages we support. When we build a particular language we marry the files together to make a Japanese or French or Russian version of the product.


But even just abstracting the strings out to files isn’t enough. In the Kanji character set, the fonts are slightly taller than English. And German words are sometimes far longer than the English. So not only do we have to translate the strings, we have to consider the multiple languages when we design the screens, so that they are wide and tall enough to support the larger text strings, but without prohibiting the use of a smaller one. It makes for some interesting design challenges!


In future posts I’ll explain another challenge we face in developing software – Accessibility.

Comments (1)

  1. If you want to sell (or give away) your software in multiple countries, you need to think about Localization