Using bLang and DocLister in AJAX Requests

AJAX endpoints often bypass part of the page lifecycle that multilingual plugins rely on. The donor case behind this article showed exactly that problem: a project using bLang called DocLister through $modx->runSnippet() inside an AJAX request, but the response always came back in the default language.

The core issue is not DocLister itself. The issue is context. If the current language is never restored before the snippet runs, the listing controller has no choice but to use the default site language.

Original DocLister call

echo $modx->runSnippet('DocLister', [
    'parents' => '19',
    'controller' => 'lang_content',
    'tvPrefix' => '',
    'tvList' => 'image,eventdate',
    'orderBy' => 'eventdate DESC',
    'id' => 'eventListNew',
]);

How to make AJAX output language-aware

• send the current language or locale in the AJAX request
• restore the same language context before calling runSnippet()
• use a normal front-end route when possible so the language plugin runs in its natural order
• avoid building a detached endpoint that skips the initialization used on full page requests

A practical request pattern

fetch('/ajax/events', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ lang: 'uk' })
});

On the server side, read the incoming language, initialize the same context that bLang expects, and only then call the listing snippet. If the language is resolved too late, the query may already be built for the default branch of the site.

Best practice

For multilingual projects, treat AJAX handlers as full page fragments, not isolated utilities. They still need the same language, routing, and site-state assumptions as the visible page they belong to. Once you preserve that context, DocLister output becomes predictable again.