Локализация клиент-серверного интернет сервиса
От: creatman Германия  
Дата: 07.02.08 14:43
Оценка:
Коллеги, помогите решить следующую проблему:

Имеется софт и интернет сервер. Работают они вместе. Тоесть получается в совокупности некоторый интернет сервис с прикладным софтом. Что-то вроде скайпа или аськи. Встала задача локализации. Всвязи с этим возникли такие вопросы:
1. Нужно или нет реализовывать возможность динамически выбирать язык GUI в клиентском приложении?

Я например даже представления пока не имею зачем это вобще может понадобиться и почему в одних программах это есть, в других нет. Какими правилами (если они есть) тут нужно пользоваться?

2. Как лучше реализовать локализацию серверной части?

Изначально будут анлглийская и русская версии сервиса (соответственно с сайтами). Клиентское приложения общается с серверами по SOAP протоколу. В программе предусматривается возможность отправки клиентам информационных (возможно и рекламных) сообщений с серверной стороны. Я знаю пока два похода
1) Все реализовать на одном сервере. Тогда клиентские приложения общаются с одним сервером. вся информация хранится на одном сервере. Сервер взависимости от языка программы выбирает язык для информационных и рекламных сообщений и т.д. Когда пользователь загружает сайт то скрипт взависимости от домена редиректит на нужную локализацию сайта.
2) — Изначально вести локализации русской и английской версий сервиса на разных серверах (один в россии другой в америке). Когда пользователь заходит на русский сервер то качает русскую версию программы, которая работает с русским сервером и наоборот. Информационные сообщения независимо подаются клиентам с разных серверов (американский и русский).

У каждого из подходов есть свои плюсы и свои минусы: например в первом случае все на одном сервере, его проще апдейтить (хотя это еще спорный момент). Клиентское приложение работает с общим сервером. Может есть еще плюсы? Минусы первого подхода в том, что необходимо придумывать механизм разделения пользователей на американских и русских, чтобы хотябы кидать им разные сообщения. Также минусами являются плюсы второго подхода, например оба (американский и русский) сервиса работают независимо. Поддерживать их можно тоже независимо. Если один падает, то второй работает и приносит деньги. Апдейты осуществляются тоже легко и иттеративно: сначало к примеру апдейтим русский сервис, смотрим как все прошло, дофиксываем баги и потом по накатанной апдейтим американский сервер. С языками тоже проблем нет. Поскольку сервера разные то и данные на них разные. Можно вести разработку сервисов в разных направлениях (хоть перпендикулярно) взависимости от особенностей аммериканской и русской аудиторий. Минусы в том что это как минимум уже два проекта. А если будет 4-ре локализации то 4-ре. Тоесть возрастает сложность управления все этим. Получается из одного проекта сделали 4-ре.

Еще говорят что если онлайн проект ориентирован на российскую аудиторию, то сервер должен рапологаться в россии. Это влияет на индексацию в поисковиках. Это правдо?


 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.