It is a common challenge in many applications to support several language versions of the same product. Applications are becoming more globalized and spreading to new markets while customers are becoming pickier and want localized versions of the software they use. Or then the custom software you deliver will be used by a globalized company that has users in many countries and you must support all languages.

There are several nice tools to translate the application user interface and error messages and such things related to the UI but how do you add support for the strings stored in the database? So that the application would display "Hammer" when the user has chosen English as the language but "Martillo" when Spanish has been selected. And all this should be done with minimum hassle.

But as databases seldom have in-built multi-language support (multi-dimensional columns anyone?), application designers generally end up crafting the multi-language support by hand.

So this is is clearly something that requires a pattern. Luckily, Nolics.net has been designed pattern-extensible.

In Nolics.net 2005 v4.2 there are at least three viable patterns for this problem:

Add a separate table to handle different translations.

• Pros: No limitations in search capabilities
• Cons: Somewhat more difficult to implement than the patttern #3.
• Cons #2: Slightly slower than pattern # 3(But is this a problem in real world cases? We don't think so.)

Add a separate record for language. In queries we must specify whether to use language as filter or not.

• Pros: A common pattern that has usability beyond multi- a language support.
• Cons: Complex to implement as this will affect primary keys in table (language must be one part of key) or requires sub table for all fields that have variations over some field.

Note! This pattern is very interesting and we will most likely add it to Nolics.net in a future version.

Add all translations to single field

• Pros: Simple to implement
• Cons: To work properly with queries, we must enable full text indexing features. This can be circumvented by using full text indexing features described in WT14.

We have created a sample project demonstrating this pattern. With full text indexing implemented in WT14, this will solve most problems related to storing strings in multiple languages.

And as always with Nolics.net, implementing a new feature needs some work, but then aftewards, using one is very simple.

Below you'll see a table definition that is in the core of the example:

namespace Nolics.Samples.TranslatableString;
type translatableString = "Nolics.Samples.TranslatableString.LanguageStringAttribute";

dbclass NewsItem {
    primary key long ID[AutoGenID = true];
    translatableString Heading;
    modified date Modified;
}

query NewsItemQuery for NewsItem {
}

In this sample, heading field can contain multiple translations.

TranslatableString is a new pattern we have defined and which guides the way the object to relational transformation is done.