Дмитрий

Это костыль невиданных размеров…

То есть такой подход 100% рабочий?

Сейчас нашли закономерность.
Когда пользюк делает релог, то все становится нормально. Редиректа нет.
В чем может быть дело?

Кстати, может быть потому и не получалось, что ключ в контексте задан не как cultureKey а как culture_key? cultureKey по всей видимости значение в системе.

Работает! В ходе экспериментов, выявил несколько ключевых моментов:
1. Если использовать сниппет, то фраза должна быть не кешируемой. То есть [[!%a_buy]] будет работать, а [[%a_buy]] — нет.
2. Если использовать плагин, то кеширование фраз не требуется. То есть [[%a_buy]] работает.
3. $modx->setOption('cultureKey',$lang); — обязательная строка.

Код плагина на событие «OnLoadWebDocument»:

$lang = $modx->getOption('culture_key');
$modx->setOption('cultureKey',$lang);
$modx->lexicon->load($lang.':darvo:front');

Вопросик по поводу:
$lang = $modx->getOption('culture_key');
$modx->setOption('cultureKey',$lang);

Стоит ли поменять название ключа culture_key в контексте на cultureKey? Вроде бы ничего не должно поломаться?)

Да, совсем забыл выложить скриншот. Самое интересное, что в словарях все ок.

Логично.
Но как не пытаюсь, не выводит английскую и все тут.
Для верности, даже поэкспериментировал напрямую:
Так, на русском:

//$lang = $modx->getOption('culture_key');
$modx->getService('lexicon','modLexicon');
return $modx->lexicon->load('ru:darvo:front');

Так, тоже на русском:

//$lang = $modx->getOption('culture_key');
$modx->getService('lexicon','modLexicon');
return $modx->lexicon->load('darvo:front');

А вот так, не обрабатывает значения, т.е. на выходе «a_packs»:

//$lang = $modx->getOption('culture_key');
$modx->getService('lexicon','modLexicon');
return $modx->lexicon->load('en:darvo:front');

Честно говоря не понимаю, как оно у вас работает? Вероятно, за 2 года, phx в formit успели поломать?

Короче, создал 2 маршрута, которые отличаются на одну букву /items/… и /item/…
И повесил ресурсы с каждого из контекстов на них обработчиками. Все работает.

У меня есть предположение, что контекст не переключается плагином bezumkun'a потому, что в первую очередь событие OnHandleResources отрабатывает VirtualPage, и только затем плагин мультиязычности.

Быть может нужно как-то отследить событие инициализации VP, что бы это событие можно было повесить на плагин мультиязычности?

$modx->switchContext('en');
$modx->setOption('cultureKey','en');

Не работает. Быть может потому, что сниппет выводит чанк только со значениями из базы?
Странно все это.

Ссылки внутри чанка сами собой с /en/, в то время как ссылки вне чанка без /en/.

По всей видимости дело не в настройках, а в переключении контекста.
Как и говорили выше.

Заменил [[*context_key]] на [[++culture_key]], и понял, что второе берется как надо.
Поэтому, создал свой ключ в каждом из контекстов, в котором прописано значение, которое нужно для корректной выборки из базы.

Маршрут остался первоначальным:

/item/{item_id:[0-9]+}/

Обработчик тоже почти не изменился:
[[!mysnippet?
&context=`[[++myname]]`
&item_id=`[[+vp.item_id]]`
]]
Правда пришлось отключить кеширование.

Про настройки pdoMenu спасибо, надо поковырять.

И все-же /{key}/item/{item_id:[0-9]+}/ не вариант, и даже /{key:[a-z]+}/item/{item_id:[0-9]+}/

Судя по всему, в контексте en, по ссылке sitename.ru/en/item/123123/ vp анализирует только то, что находится после sitename.ru/en/. Это становится ясно, включая/выключая маршрут /item/{item_id:[0-9]+}/.

Когда последний отключен, modx выдает 404, когда включен, обработчик срабатывает.

wiki-router — это синоним router, просто старое название.
Ищет предмет в базе по id.

Спасибо за код, я делал так:

switch($context){
 case 'en':
  $context = 'en';
  break;
 default:
  $context = 'web';
  break;
}

Что по сути только меняло переменную, чтобы можно было вытащить английское название.

Теперь, благодаря вам, так:

$key = $_REQUEST['fastrouter']['context_key'];
if ($modx->getCount('modContext', $key)) {
    $modx->switchContext($key);  
}
$context = $modx->context->key;

Однако, по прежнему, VP не понимает ссылку:
sitename.ru/en/item/4/
В контексте /en/ работает только так:
sitename.ru/en/en/item/4/

1. Боюсь, что поменяв в настройках контекста site_url либо base_url, появятся проблемы с мультиязычностью.
2. Появляется еще одна проблема, VP не знает что контекст изменился, поэтому в меню генерируются ссылки вида:
sitename.ru/index.html
вместо:
sitename.ru/en/index.html
Меню собирается при помощи pdoMenu

base_url для web = / — (странно, что ссылка sitename.ru/item/1267/ при этом работает)
base_url для en = /en/
Согласно инструкции.

И каша в голове. Похоже, единственное что работает, это костыль. :\

Работает, но весьма странно:
Допустим, ссылка:
sitename.ru/en/item/1267/
получаем ошибку 404 (у меня 503 т.к. не задал страницу в данном контексте)

Если добавим еще один /en/:
sitename.ru/en/en/item/1267/

То все работает.
Получается, что нужно что-то мудрить с base_url?

Если будут обрабатываться разные маршруты, разными обработчиками.

Похоже, что самый простой вариант, добавить маршрут:
/item/{item_id:[0-9]+}/en/

И привязать к обработчику:

[[!wiki-router?
 &context=`en`
 &item_id=`[[+vp.item_id]]`
]]

Так — работает.
Правда ссылка будет:
sitename.ru/en/item/1267/en/

Хотя будет прекрасно работать и с:
sitename.ru/item/1267/en/ Только это ни к чему.
Впрочем, костыль готов. :)

Спасибо что заметили, делал очень давно и оказалось что в чанке у меня был вызов сниппета:

[[!router?
  &context=`[[*context_key]]`
  &item_id=`[[+vp.item_id]]`
]]

:facepalm:

[[*context_key]] ведь возвращается такой, в каком контексте расположена страница? Получается, что VirtualPage как виртуальный не может находиться где-либо, и берется значение прописанное в скриптах VirtualPage по умолчанию?

item_id — id строки игрового предмета из общей базы. Из которой я беру столбцы name_web, name_en и так далее, в зависимости от ключа контекста, и вывожу данные о предмете.

спасибо!