2016-05-23 3 views
0

В настоящее время я работаю над выпуском корейской версии сайта в Kentico 8.2 и работаю с локальными и dev-версиями сайта.Kentico Культуры не работают после навигации

Я могу загрузить страницу на корейском языке и даже некоторые последующие страницы для загрузки на корейском языке во время навигации. Обычно третья или четвертая страница, к которой я перехожу, вернется к английскому. Я могу повторно добавить строку запроса: lang = ko-kr или добавить/ko-kr/в URL (в зависимости от того, какой параметр я пытаюсь в то время), чтобы загрузить эту страницу на корейском языке (проверяя ее) , Кажется, что не важно, на какой странице я начинаю или на какие страницы я перехожу.

Я пробовал сочетание перечисленных ниже параметров:

  • Принуждение домена Культура (только) в Настройки/URL-адресов и SEO
  • Используйте префикс языка для URL-адресов (с и без Разрешить URL-адреса без языка префиксы) в настройки/URL-адресов и SEO
  • Изменение культуры посетителей Автоматически (сайты/Общие)

с этими различными настройками, я попытался appendi ng? lang = ko-kr или используемый домен/ko-kr/rest-of-url, чтобы загрузить страницу на корейском языке (соответствующая настройка).

Я попробовал другие вещи, чтобы увидеть, если они мешая, такие как:

  • настройки языка в браузере изменен на корейский, чтобы увидеть, если это было что-то переопределение.
  • Запустите в режиме инкогнито и очистите кеш/файлы cookie, чтобы убедиться, что это возможные проблемы.
  • Перезагрузка сервера после изменения настроек.
  • Проверка пользовательских URL-адрес не конфликтует (не установлена)

Я искал через Kentico форумов, здесь на SO, и погуглить различные поисковые термины не повез. Согласно тому, что я нашел, эти несколько настроек - все, что необходимо. Проблем с этими проблемами мало, так как большинство результатов возвращают нормальную документацию о том, как реализовать несколько языков на сайте.

Я застрял на этом несколько дней и чувствую, что у меня что-то совершенно очевидно ... это не должно быть так сложно, не так ли?

ответ

0

Я был в состоянии решить эту проблему, установив (Настройки> ссылки и SEO под заголовком SEO - культуры):

Принуждение домена культуры (непроверенные) Использование языка префикс для URL (проверяемых) Разрешить URL-адреса без языка prefixes (unchecked)

Всякий раз, когда мы получали NodeAliasPath, URL-адрес не включал код культуры. Он сохранит текущий язык для нескольких загрузок страниц, но в конечном итоге вернется к языку по умолчанию (на английском языке). Добавление ниже функции вокруг использования NodeAliasPath устранило проблему.

public static string GetCultureURL(string url) 
{ 
    url = url.TrimStart('~'); 

    string output = url; 

    if (CMS.Localization.LocalizationContext.CurrentCulture.CultureCode.ToLower() != "en-us") 
    output = "/" + CMS.Localization.LocalizationContext.CurrentCulture.CultureCode + url; 

    return output.ToLower(); 
} 

Система CMS любит вставить тильды (~) для ссылок, выбранных с помощью селектора линии, поэтому мне пришлось урезать его из URL.Поскольку английский является языком по умолчанию (и было запрошено иметь английские URL-адреса равными), у меня был оператор if, который пропускал добавление/en-us в начало URL-адресов.

Также нет необходимости вводить строчный URL-адрес, поэтому функция может быть уменьшена до еще большего.

+0

Если вы примените метод, о котором я упоминаю в моем ответе ниже, вам это не понадобится, используя только NodeAliasPath, поскольку URL-адрес будет разрешен для соответствующего URL-адреса культуры в зависимости от настроек сайта и cookie посетителя. –

0

Мы недавно столкнулись с проблемой с одним из наших сайтов, и это может быть или не быть связано с вашей проблемой, но может стоить проверить.

Если ваш документ культуры по умолчанию имеет собственный путь, определенный таким же образом, как и путь псевдонимов узла по умолчанию, URL-адреса других культур не будут работать должным образом, если вы используете только URL-адреса nodealiaspath в своем интерфейсе.

Для работы с MultiLang URLs правильно использовать этот метод:

Вы /страница, на английской версии (культуры по умолчанию) использование пользовательского путь должны быть проверены, но путь texbox должен быть пустыми, или что-то другое, чем /страница.

На португальском языке (мой пример), использование пользовательского пути также проверяется, но путь текстового поле имеет переведенный вариант /Pagina (вы можете проверить/снимите флажок Использовать пользовательский путь флажок и он будет генерировать переведенный путь для тебя).

Таким образом, если вы перейдете на URL /страница впервые он должен идти к /EN/страница

Однако, если у вас уже есть печенье для португальской версии, если вы идете в /страницы будет перенаправлен на /pt/pagina.

Вы также должны быть в состоянии navigato к /Pagina и он будет перенаправлять /пт/Pagina

Это самый лучший способ, которым мы нашли использовать и объяснить клиентам, как делать и работать с MultiLang URLs.

+0

Спасибо за предложение. Учитывая количество страниц и языков, которые мы будем использовать, не рекомендуется настраивать пользовательский путь для каждой страницы. То, что мы переживали, состоит в том, что оно не перенаправлялось бы на правильный язык, даже если язык был установлен в файле cookie. Нам приходилось явно указывать, какой язык мы хотели бы каждый раз (отсюда и предыдущий код культуры, используемый в моем решении). – momn99