Мультиязычность проектов (Оценка: +7)

Печать / RSS-лента
Предисловие
Почему ООП? Думается, для реализации мультиязычности в web ООП подходит отлично. Я думаю все читатели понимают, что под мультиязычностью в данной статье я буду понимать именно локализацию тех или иных компонентов системы, сюда не будет входить информация о создании переводчиков и подобного, это отдельная тема.

Немного теоретических размышлений
Изучая одну открытую платформу, обратил внимание на отличный подход к локализации (переводу) данных и решил "поковыряться поглубже". Если говорить о локализации, стоит выделить три основных типа данных, которые следует локализовать:
1. Сущности - то есть объекты, с которыми мы работаем. Сюда можно отнести такие понятия как login - логин; password - пароль; rule - право доступа и т.д. Другими словами, речь идет о классах и их свойствах, которые фигурируют в системе;
2. Компоненты пользовательского интерфейса - когда работает программист, записи вида msg://helloMessage это приемлемо, но когда за работу берется дизайнер, подобного рода записи, часто необходимые для локализации, начинают сильно мешать. Посмотрите сами, какой из шаблонов страницы лучше:
<div>
<h1>msg://TitleMessage</h1>

<p>%Content%</p>
</div>

или

<div>
<h1 dLocal="text">Hello people!</h1>

<p dInit="contentLoad">Test content. More text...</p>
</div>
Мне нравиться второй вариант. По моему мнению, здесь содержание шаблона отделяется от его форматирования. В первом случае при запуске такой страницы в браузере, мы увидим ненужную для нас, программную информацию, что частенько раздражает дизайнеров, и я их понимаю, мне тоже не хотелось бы задумываться обо всех этих программных примочках, а просто писать дизайн и пример страниц.
3. Динамический, "тяжелый контент" - к примеру сообщения пользователей или новостные сообщения, локализация которых часто очень сложна или занимает много времени (данный тип мы рассматривать не будем).

Все указанные типы данных следует локализовывать отдельно, иначе мы получим тяжеловесные, неуклюжие системы, сопровождать которые будет очень сложно.

Как я это вижу
При написании модулей локализации в своей платформе, я задался вопросом - как это лучше сделать?
Выделил следующие обязательные условия, которым должна соответствовать система локализации:
1. При локализации сущностей, следует беспокоиться о размерах файлов локализации, дабы не перебирать огромные массивы данных с целью поиска нужной нам записи;
2. Не следует смешивать процесс локализации с процессом программирования сущностей. Программисту и так в голове нужно держать целую проектную модель, на кой ему еще и беспокоится о написании локализации? Нужно сделать так, чтобы отдельные люди могли заниматься локализацией, при этом они не обязаны знать программирование!
3. То же самое, что и п. 2, только относительно дизайнеров!
4. Следует обеспечить дизайнерам возможность писать примеры страниц с тестовым содержимым, чтобы заказчик мог оценить результат как он есть, вместо записей на экране вида %contentID%!
5. При работе с пользовательским интерфейсом, вопрос объемов данных для локализации стоит еще более остро чем в п. 1;
6. Сделать все это удобным для работы!

Как видите, условия довольно строгие, но справедливые!

Автор статьи: Артур (22.05.13 / 00:41)
Мультиязычность, Локализация
Рейтинг: +7
Просмотров: 992
Комментарии (1) »