views:

40

answers:

2

I'm currently designing a e-commerce solution. One of the primary requirements is for the store to support localized item details. The same store must be able to support multiple languages via the user's language selection and/or browser preference.

I have two tables:
Item (id, sku, price, ...)
ItemDetails (item_id, language, title, ...)

For each Item, there will be multiple rows corresponding to the item, where the (item_id,language) pair will be unique.

I would like to model this as:
class Item
{
public string sku;
public double price;
public ItemDetails Details;
}

Based on the user's session, I would like the items returned to have the Details object corresponds to the user's selected language (from their session).

What are some approaches for representing this?

A: 

Think about how you retrive lists of objects

  • are they cached
  • are they filtered / sorted / paged
  • are they searched
  • are they accessed by other applications (reports, partners )

The answer determines how much of the translation logic can be in the application and how much can be in the database.

The application I work on right now has lists of objects that are accessed only in the application. Only 2 properties are translated and I dont have to sort by these properties. I load lists of objects and every object already has translations for all languages saved in a dictionary. The nice think is that my cache only has one entry per key.

Thinks get more difficult if you need to search, filter and sort by translated properties. I would try to have the logic in the database then.

Malcolm Frexner
A: 

I'm working on a similar globalization, where there is much dynamic content stored in the database. The approach I'm taking to allow for multilingual dynamic data is like this:

create table Item
(
   ItemID
   ,Sku
   ,Price
   ,Title -- invariant, fallback culture
)


create table Item_Culture
(
   ItemID
   ,CultureCode -- ex: en-US, en-CA, fr-CA, en-UK, fr-FR, en, fr
   ,Title
)

select i.ItemID, i.Sku, i.Price, coalesce(ic.Title, i.Title) as Title
from Item i
left outer join Item_Culture ic
   on ic.ItemID = i.ItemID
   and ic.CultureCode = @CultureCode

Where @CultureCode is a parameter passed in from your application, and a Culture table contains a list of your different languages/cultures for reference or to specify fallback language dependencies.

You can expand this for multiple fallback languages if need be. It's a bit of a hit on the database compared to a single language implementation, but will accommodate the dynamic nature of your data, and that's just a cost of a multilingual dynamic site. Caching will be your friend if you have data that doesn't change too rapidly to help reduce the added database load.

ulty4life