CODEWITHSUNDEEP
asp.netsqlarchitecturetranslation
ElikBelikBom
ElikBelikBom

Reputation: 1

Website translation architecture and implementation

I'm conducting a project in which a website should have multi-language support. Now, this website is supposed to serve about 500K+ visitors a day, so it must be super-efficient.

I've created a table of parameters {[ID],[Name]} AND a linkage-table {[objectID],[parameterID],[languageID],[value]}. I think it's the best way to deploy multi-language support while having the privilege to translate different parameters for each language.

As far as I know, server's memory is much faster than a physical HDD. Therefore, I'm planning to store ASP.NET Application State objects for my translation architecture. (http://msdn.microsoft.com/en-us/library/ms178594.aspx)

How does my plan sound so far? any suggestions?

Upvotes: 0

Views: 590

Answers (3)

Tengiz
Tengiz

Reputation: 8409

So, localizing an application can be divided into two parts:

  • Localizing business logic entities.
  • Localizing everything else.

In the question I see words which are related to business entity localization. For that purpose I agree with the concept to have separation between entities and their localizations.

Part 1 - Localizing entities:

Personally I do this way in database:

table Entity {EntityID, Name} -this is the entity-related table.
table EntityByLang {EntityID, LanguageID, Name} -this is the localized version of the table for each supported language.

This way allows me to have default values for each localizable property like Name and its localization, if such is available in the localized table. What's left here up to you is - you need to implement the data-access-layer which takes the Name localized for the current user language, or the default value (if language or the translation is not available for the given language).

Part 2 - Localizing everything else:

Here, with no alternatives in terms of the performance, I would recommend using some kind of static resources. Personally I live with static resources available for standard asp.net applications.

From the architectural point of view, don't directly refer to localization code from your UI code, like this (which I don't like):

var translation = HttpContext.Current.GetGlobalResourceObject("hello");
//excuse me, if I don't exactly remember the GetGlobalResourceObject() method name...

Instead, I would recommend using this kind of approach:

var translation = AppContext.GetLocalizationService().Translate("hello");

Where: AppContext - some kind of facade/factory (in fact, implementation of abstract facade/factory). GetLocalizationService - initially returns some kind of ILocalizationService, when implemented it returns StaticResLocalizationService (which implements ILocalizationService). This way allowing switching from one kind of localization to another. And particularly StaticResLocalizationService works with asp.net static resources

Sorry for messy sample codes, but I hope you understand my approach.

I hope this helps!

Upvotes: 1

Robert
Robert

Reputation: 3302

I would suggest to create custom resource provider, you can read more here:

http://msdn.microsoft.com/en-us/library/aa905797.aspx

with this model you can leverage existing asp .net localization functionality

Upvotes: 0

Terry
Terry

Reputation: 5262

If you are planning on making an app that support multiple languages, your instant reflex should be let .net do the work for you. What i'm reading in your question is that you are setting up something to support that. You should know that localization is the way to go when you want to develop a multi-language environment.

Take a look at this msdn article, it should give you a general idea on the topic.

Upvotes: 1

Related Questions