Архитектура перевода сайта и его реализация

Question

Я веду проект, в котором веб-сайт должен иметь многоязычную поддержку. Теперь этот сайт должен обслуживать около 500 000 посетителей в день, поэтому он должен быть суперэффективным.

Я создал таблицу параметров {[ID], [Имя]} И таблицу связей {[objectID], [parameterID], [languageID], [value]}. Я думаю, что это лучший способ развернуть многоязычную поддержку, имея возможность переводить разные параметры для каждого языка.

Насколько я знаю, память сервера намного быстрее, чем физический жесткий диск. Поэтому я планирую хранить объекты ASP.NET Application State для моей архитектуры перевода. (http://msdn.microsoft.com/en-us/library/ms178594.aspx)

Как звучит мой план? какие-либо предложения?

Answer 1

Таким образом, локализацию приложения можно разделить на две части:

• Локализация объектов бизнес-логики.
• Локализация всего остального.

ВНа вопрос вижу слова, которые связаны с локализацией хозяйствующего субъекта.Для этого я согласен с концепцией разделения между сущностями и их локализацией.

Часть 1. Локализация сущностей :

Лично я делаю это в базе данных:

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.

Этот способ позволяет мне иметь значения по умолчанию для каждого локализуемого свойства, например Name, и его локализации, если таковые имеются в локализованной таблице.Здесь остается только одно - вам нужно реализовать слой доступа к данным, который принимает Name, локализованный для текущего языка пользователя, или значение по умолчанию (если язык или перевод недоступны для данного языка).

Часть 2. Локализация всего остального :

Здесь, без каких-либо альтернатив с точки зрения производительности, я бы рекомендовал использовать какие-то статические ресурсы.Лично я живу со статическими ресурсами, доступными для стандартных приложений asp.net.

С архитектурной точки зрения, не обращайтесь напрямую к коду локализации из вашего кода пользовательского интерфейса, как это (что мне не нравится):

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

Вместо этого я бы рекомендовал использовать такой подход:

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

Где: AppContext - какой-то фасад / фабрика (фактически реализация абстрактного фасада)/ завод).GetLocalizationService - изначально возвращает какой-то ILocalizationService, при реализации возвращает StaticResLocalizationService (который реализует ILocalizationService).Это позволяет переключаться с одного вида локализации на другой.И особенно StaticResLocalizationService работает со статическими ресурсами asp.net

Извините за грязные примеры кода, но я надеюсь, что вы понимаете мой подход.

Надеюсь, это поможет!

Answer 2

Если вы планируете создать приложение, поддерживающее несколько языков, ваш мгновенный рефлекс должен позволить .net сделать всю работу за вас.Что я читаю в вашем вопросе, так это то, что вы настраиваете что-то для поддержки этого.Вы должны знать, что локализация - это путь, когда вы хотите разработать многоязычную среду.

Взгляните на эту статью MSDN , она должна дать вам общее представление отема.

Answer 3

Я бы предложил создать собственный поставщик ресурсов, вы можете прочитать больше здесь:

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

с этой моделью вы можете использовать существующие функции локализации asp .net