SharePoint 2010 имеет встроенный функционал, помогающий в реализации многоязычного сайта. В книгах не трудно найти информацию о легкости перевода пользовательского интерфейса, навигации и списков, в том числе столбцов списков. Достаточно установить language pack, указать возможные языки для сайта и пользователь будет иметь возможность выбрать язык отображения сайта. Пользовательский интерфейс сразу будет переведен на выбранный язык, списки, столбцы и пункты навигации достаточно один раз перевести вручную и введенные значения сохранятся только для текущего языка. Куда труднее обстоят дела с переводом контента. Создавать отдельный сайт для контента каждого языка – неизбежность. Поиски (1, 2) материалов по этой теме навели меня на variation feature. Статьи в блогах гласили, что этот инструмент копирует весь контент и структуру (списки и подсайты) с сайта источника на остальные сайты настраиваемой иерархии. Скопированный контент становится черновиком и ждет ручного перевода. Видимо так было для SharePoint 2007. Развернув этот инструмент, я обнаружил, что нет ни малейшего намека на копирование контента.
Продолжив исследования, я нашел статьи на technet, посвященные развертыванию многоязычного сайта и в частности variation feature: Plan for multilingual sites (SharePoint Server 2010), Variations overview, Plan variations.
Статья variation overview прямо говорит о том, что variation feature не копирует контент, за исключением библиотеки Pages инфраструктуры публикации, от которой я отказался в виду сложностей с версткой. Аналогично состоят дела и с копированием структуры сайтов – копируется только структура сайтов (то есть подсайты), а списки и библиотеки не затрагиваются. Итого в моем случае полезность variation feature – это автоматическое перенаправление на сайт, соответствующий текущему языку посетителя сайта. На первый взгляд это кажется упущением разработчиков, однако это дает бОльшую гибкость (списки на разных языковых версиях можно делать разными), при незначительно бОльших затратах на разработку.
Итак, нужно решить ряд проблемы связанные с синхронизацией структуры списков, самих списков и их контент.
Со структурой списков все очень просто. Всю проблему решают типы контента. Достаточно на корневом сайте создать тип контента и он будет виден на остальных сайтах иерархии вариаций. После чего развернуть список на основе этого типа контента и перевести названия столбцов на нужный язык.
Сами списки можно разворачивать на всех сайтах при помощи кода или вручную, что тоже не затратить большого количества времени, если использовать типы контента.
Синхронизация контента уже более интересная вещь. Самым логичным на мой взгляд является вариант с разработкой рабочего процесса, который будет выставлять всем переводчикам задачи о необходимости перевода контента. Это требует некоторого времени. Если переводить контент нужно всего одного-двух списков и расти собирается не скоро, то, на мой взгляд, достаточно поставить уведомления переводчику, этот путь и был мною выбран.
Да, Варианты оказались не всесильны. Перевод существующей структуры, которая огромна, вызывает много усилий.
ОтветитьУдалитьЯ думаю для переноса существующей структуры стоит задуматься над созданием кода, который создавал бы типы контента на основе существующих списков, привязывал бы списки к этим типам контента, а после на всех вариантах делать списки (опять же из кода) на основе этих (используемых в списках корня) типов контента. Т.е. алгоитм работы кода я вижу таким:
ОтветитьУдалить1. Цикл по спискам web'a создает типы контента на основе полей текущего списка.
2. Цикл по спискам того же web'а создает списки на варианте на основе типов контента текущего списка.
Шаги 1 и 2 лучше разделить, т.к. вполне вероятно, что нужно будет добавить ещё один вариант и тогда шаг 1 выполнять не нужно будет.