Basic Software i18n Check List

Part of something my team is currently working on involves defining a standard approach to assessing the world-readiness of a piece of software, be it a brand new product or a legacy product that has existed for a long time.

If your codebase is not correctly internationalized, you will face many problems if you ever want to localize your application for another market.

Most of these are general items that could apply to any product on any platform, be a it a website or a mobile application.

Here’s my first draft of my list. This may help you if you are planning of localizing your application to sell in other markets.

Strings

  • Have all strings been externalized?
  • Have all strings been approved by someone who is a native English speaker?
  • Is there overuse of any abbreviations or acronyms, e.g. ‘App Info’?
  • Is there anywhere that you are concatenating strings together?
  • Punctuation is text too! Are you using any hard-coded punctuation marks (.,!?) these need to be externalized?
  • Have you identified all trademarks, tokens and other ‘special’ elements in your text and communicated to localisation that these shouldn’t be translated?
  • For mobile applications, is your text short enough to fit the potential small screen size of mobile devices? Consider string length expands generally 20% – 30% after translation. Some phrases expand by a lot more than 30%. Abbreviations and acronyms are the worst offenders here.
  • Try to keep resources that shouldn’t be translated separate from those that should.
  • Don’t embed HTML mark up in string resources.

Source Files

  • Source files are a standard file format – no need to invent new resource file formats. A standard resource file format will exist for the platform for which you are developing.
  • Source files are UNICODE.
  • You need to be able to generate your localizable file set in one step, it’s ideally handled by the build process.

General UI

  • Can input fields accept accented characters?
  • Can input fields accept double byte characters?
  • Is there room for buttons to expand if necessary?
  • Are there any UI elements like check boxes or radio buttons that are placed across the screen? It is better to place these vertically.
  • Try to put labels for controls above the control, rather than beside it.

Web Applications

  • Is server set up to send UTF-8 character set?
  • Are all buttons resizable?
  • Are there any mouse-over buttons with text in them?
  • Are other elements on the screen able to expand in size?
  • Are links to help and other user documentation appropriately localized?
  • For HTML based UI, never use absolute positioning.
  • NEVER use HTML tables to achieve layout.
  • Try to avoid using fixed widths with HTML layouts.
  • Don’t use the ‘align’ property to align items left or right.
  • Externalize CSS to a separate file – never use inline CSS.

Images

  • Is there text in any image?
  • Are there any images that depict hand, body or facial gestures? e.g, the thumbs up gesture is offensive in some cultures.
  • Are there any icons or images that are very specific to one region? e.g. an American type mailbox indicating an email.

SQL

  • Use the nvarchar type to store all text.
  • Can all insert and update statements handle unexpected apostrophes? (O’Sullivan, d’accord for example)?
  • Can all insert and update statements handle accented and double byte characters?
  • For MySql, ensure it was installed with UTF-8 as the default character set.

Numbers & Dates

  • Do any parts of your application format numbers using a thousand separator or a decimal point? If so the formatting string must be read from the OS.
  • Do any parts of your application format currencies? If so the formatting string must be read from the OS.
  • Does changing the application locale change all numbers appropriately?
  • Are all time and date formats read from the OS based on locale?
  • Does changing the application locale change all dates appropriately?

Regular Expressions

  • Do any regular expressions use the construct [a-zA-Z]? These are not safe from an i18n point of view.
  • Never use a regular expression to find a price, as the currency will be different for different languages.

Collation/Sorting

  • Do any parts of your application sort alphabetically? If so then they need to be tested for i18n awareness.

C# – Using Bing’s Translation Web Service

Microsoft’s Bing Translator provides a translation web service which can be called via C#. In this post I’ll outline the steps to use this web service, and create a simple application to perform translations.

First, you’ll need to create a valid application ID for your application. This is required in order to be able to call the web service. Head over to Bing’s Developer Centre and sign in with your Windows Live ID. Follow the steps to create a new ID for your application, it’s a simple process and shouldn’t take you any more than 2 minutes.

Next, create a new project in Visual Studio, (I’ve created a simple Windows forms application to demonstrate this, but you could just as easily create a simple console application). You’ll need to add a service reference to your application either way. Do this by right-clicking on your solution and selecting ‘Add Service Reference’. Under ‘Address’, add this:

http://api.microsofttranslator.com/V1/SOAP.svc

Under ‘namespace’, be sure to enter a descriptive name for the service reference. Now, for the code to perform translations (You’ll need to add in the application ID you created earlier in order for this to work):

// Translating from English to German

string textToTranslate = "Hello, world";
string sourceLanguage = "en";
string targetLanguage = "de"
string translatedText = "";

try
{
BingTranslatorService.LanguageServiceClient client = new BingTranslatorService.LanguageServiceClient();
translatedText = client.Translate("Your App ID", textToTranslate, sourceLanguage, targetLanguage);
MessageBox.Show(translatedText);
}
catch (Exception ex)
{
MessageBox.Show("An error has occurred: " + ex.ToString(), "Error");
}

‘BingTranslatorService’ above is whatever you called the service reference added earlier. I’ve created this sample application to show how easy it is to create a simple translation application:

Simple Translation Application

Download the full source code, here. You’ll need to add in your application ID in order for this to work properly.

Localization of C# Applications – Short Introduction

If you plan on releasing your C# application in non-English speaking markets, you will obviously want the UI to display localized strings. When developing applications using .NET, it’s relatively simple to achieve this. In this post, I’ll outline the steps involved in localizing a simple C# application.

.NET applications store string resources in .resx files. These are XML format, with the main advantage being they are human readable and can be opened in any text editor, unlike resource DLL files for example. The only item not human readable in a .resx file, may be an embedded object, like a Bitmap file for example.

Start off by creating a simple Windows Forms application from Visual Studio, it will create an initial form for us to work on.  Select the form and on the ‘Properties’ dialog look for the ‘Localizable’ property and set it to ‘true’. You may also notice the ‘Language’ property, leave this set to ‘Default’ for the moment.

Next, add a button to the form and add some text to it, something simple, for example:

Simple Localizable Form

If you take a look under your form in ‘Solution Explorer’, you will notice a .resx file has been created. It will be named FormName.resx, open this up and search for the string on your button and you will see how it is stored. Now to add the equivalent German strings (or any other language you fancy!).

Recall the forms ‘Language’ property mentioned earlier, you will find it under ‘Properties’ when you’ve got the form selected. In the dropdown, change the value to ‘German’. You will not notice any visible changes, but you can now edit the strings on the form to represent the German equivalents. Do this for as many languages as you want to. Once you’ve done this, take a look under your form in ‘Solution Explorer’, you will notice that a new .resx file has been added automatically, FormName.de.resx. This will contain your German strings. You should note here that you can also change the layout of the form to include any required changes, in the event some strings are longer in certain languages, e.g. Greek.

Now when your application is run on a German operating system, the strings displayed will be automatically taken from FormName.de.resx, rather than FormName.resx.

A note about locale selection

The UI language used in Windows is a function of the CurrentUICulture setting. In order to see the German strings actually display, you would need to install a German language pack, and change your regional settings, or we could just set our locale programmatically in our application.

In order to test your German strings display correctly, first add the following imports:

using System.Globalization;
using System.Threading;

Then add the following code to your form initialization function, (before InitializeComponent()):

// Sets the UI culture to German (Germany).
Thread.CurrentThread.CurrentUICulture = new CultureInfo("de");

This will make our application believe it’s running on a German locale. Now run your application, you should see your German strings displayed:

German Strings Displayed

This post outlined the very basics of localizing .NET applications. In future posts, I plan on expanding this a bit to advanced topics such as avoiding common internationalization issues.