Question

I’m trying to create a domain model that supports localization. I’ve looked at some SO questions that were asked before but I did not really like the solutions proposed. For example, in this question I think it’s an overkill to create an additional entity for each and every entity that should support localized data. I’d rather have the localized data for all of my entities be in one entity whose sole purpose is to hold the localized data.

My proposed solution is as follows:

1. Create a LocalizedEntity class from which all of the entities that should support localization would inherit.

2. Create a LocalizedData entity which will basically hold the actual localized values by culture.

UPDATE:

public class LocalizedEntity
{
    public String Code { get; set; }
}

public enum ResourceType
{
    CityName,
    CityDescription,
    StreetName,
    AreaName
    //others...
}

public class LocalizedData
{
    public Int32 Id { get; set; }
    public String Code { get; set; }
    public ResourceType Type { get; set; }
    public Int32 CultureId { get; set; }
    public String Value { get; set; }
}

public class City : LocalizedEntity
{
    public Int32 Id { get; set; }
    public virtual ICollection<Area> Areas { get; set; }
    //others
}

Accordingly, the business layer will fetch the localized entity, and then go and get its localized value from the LocalizedData entity by Code and ResourceType. And of course, in order to avoid many round-trips to the database, some caching could be appropriate.

Your thoughts?

Answer 1

What you’re modeling is EAV (entity-attribute-value) storage. Very soon your “resource type” enum will overflow into unmanageable state. To add injury to insult, that’s pretty uneffective in terms of database structure.

If you want localization that’s still maintainable in terms of db usage of code readability, you should localize entities, not properties, which means that each row in database should hold entity id, language id and data for that entity in that language.