Не могли бы вы быть конкретным, это для переводов на стороне сервера или на стороне клиента? Для переводов на стороне клиента у меня возникла проблема с OTB ResourceBundleExportServlet, подробно здесь .
слинг: базовое имя путь:
- Добавьте свойство sling: basename для mix: языковой узел. Скажите слинг: basename = "siteA"
- Передайте базовое имя во время поиска пакета. request.getResourceBundle ("siteA", локаль);
- Это вернет ключи только от определенного базового имени.
Экспортер пользовательских пакетов на стороне клиента:
- Хранить отдельные словари для SiteA и SiteB. Например: / apps / company / sitea / i18n, / apps / company / siteb / i18n.
- Если разделение словаря невозможно, сохраните номенклатуру в ярлыках для идентификации сайта. Например, все метки должны иметь префикс siteA / siteA. Например, siteA.click здесь, siteB.clickhere
- Создание собственного сервлета, похожего на ResourceBundleExportServlet. Сохраните путь как /libs/company/i18n/dict.
- Пользовательский сервлет будет проверять siteA или siteB на slingrequest и возвращать только соответствующие метки. Фильтрация меток на основе пути к словарю (шаг 1) или префикса (шаг 2)
Создать наложение для /libs/clientlibs/granite/utils/source/I18n.js. Измените urlPrefix на
var urlPrefix = "/libs/company/i18n/dict.";
Теперь поиск на стороне клиента i18n будет извлекать записи из пользовательского экспортера, а не из OTB-экспортера
Resolver на стороне сервера:
- Чтобы различать метки sitea или siteb, нам нужен шаг 1 или 2 сверху.
- Как только мы узнаем, как идентифицировать метки, специфичные для сайта, нам понадобится только вспомогательная утилита, которая проверяет сайт по запросу и разрешает из определенного словаря или префикса
Надеюсь, это поможет.