NLS является повторяющимся требованием, и часто, когда задают вопрос о функциональности NLS, спрашивающие люди не осознают сложности. NLS обычно делятся на (как минимум) 2 области:
В вашем случае, основанном на контенте веб-сайте, вы можете даже разбить второй пункт на - данные, сгенерированные поставщиком веб-сайта, и - данные, сгенерированные пользователем.
Для интерфейса пользователя NLS вы можете использовать механизм .resx, как упомянуто Mehrdad, но вы должны знать, что каждая работа по локализации всегда требует редактирования исходного кода (то есть файлов resx).
Когда мне пришлось разрабатывать многоязычное веб-приложение, я решил обработать требование NLS в своем коде и создал пару таблиц, специфичных для NLS, которые отражали пользовательский интерфейс (кстати, это была мотивация для написания graspx : извлечь все видимые тексты из источника aspx, такого как Label.Text и т. д.). Существует отдельное приложение для загрузки определения пользовательского интерфейса, и пусть переводчики делают свою работу. Основное приложение имеет функцию импорта переведенных текстов.
Модель данных выглядит следующим образом: Page - PageItems - PageItemTexts (со ссылкой на язык), поэтому все довольно просто.
Та же модель может быть применена к контенту: вместо Page и PageItems у вас просто есть ContentItems, которые содержат только PK и идентификатор, и таблицу, содержащую текст ContentItems, связанных с языком.
Кроме того, вы можете определить какую-то цепочку резервирования языка, чтобы текст, который еще не переведен, отображался на языке оригинала или на другом (тесно связанном) языке.
Отображаемый язык может быть выбран языком, предоставленным браузером (HTTP_ACCEPT_LANGUAGE), но он должен быть перезаписан пользователем (например, с помощью комбинированного списка). Выбранный язык должен храниться в переменной сеанса, в файле cookie или в базе данных (для зарегистрированных пользователей).