Мы перестроили то, как платформа для агентной инженерии публикует мультиязычный контент

Если честно, всё началось как водоворот. Я хотел, чтобы по нашему собственному сайту было приятнее ходить — проще навигация, проще найти нужное, — и это быстро превратилось в перестройку самого процессора, который сайт обновляет. А как только трогаешь то, как публикуется контент, сразу упираешься в две вещи одновременно: его надо оптимизировать под человека и его надо оптимизировать под поиск — и под Google, и теперь под ИИ. Сегодня без этого уже никуда. А дальше, как обычно, появился побочный эффект: из работы выпал маленький инструмент, и я решил его оставить — сделать частью стандартной архитектуры, — потому что думаю, что многим, особенно здесь, в Европе, понадобится ровно это: аккуратный способ создавать мультиязычный контент.

Это немного необычный выпуск, потому что он про нас самих. Fractera — это Agentic Engineering Infrastructure, платформа для агентной инженерии, где ИИ-агенты строят ваш софт. Но у платформы есть и публичное лицо: вот этот самый сайт, его новости, его документация. И та часть машины, что публикует и обновляет этот контент, тихо стала тем, что не масштабируется. Поэтому мы её перестроили. В традиционном смысле такой текст жил бы в инженерном блоге или в сухом списке изменений — внутренняя записка для других разработчиков. Мы намеренно публикуем это как Новость, потому что у Fractera новостная лента — живая, доступная для поиска ИИ память проекта: каждое обновление здесь в момент выхода попадает в граф-память LightRAG рабочего пространства.

Проблема: контент, который был лёгким на двух языках и невозможным на восьмидесяти

Наш старый способ хранить контент был таким, с какого почти все начинают: один растущий файл на тип контента и большой переключатель «английский или русский» поверх. Работает прекрасно — ровно до тех пор, пока не перестаёт. В нём были зашиты две поломки. Первая: все статьи, посты и документы одного вида склеены в один вечно растущий файл. Вторая: перевод был «всё или ничего» — чтобы добавить язык, надо перевести всё целиком, иначе страница откатывалась на английский полностью. Для двух языков нормально. Для десятков, к которым мы идём, — это стена.

А по коду страниц были рассыпаны маленькие языковые костыли — «если язык русский, покажи это, иначе то». Каждый сам по себе безобиден. Тысяча таких, на растущем сайте, который правят и люди, и ИИ-агенты, — это медленно расползающийся беспорядок, который никакими благими намерениями в чистоте не удержишь.

Решение: одна папка на документ, перевод по ключам

Новая форма скучна в самом хорошем смысле. Каждый кусок контента — это своя папка: маленький файл для того, что не переводится (дата, теги, картинки), один полный базовый файл на английском и — для каждого дополнительного языка — частичный оверрайд, где лежит только то, что реально отличается. Новый язык теперь — это просто новый файл, положенный в папку. Ничего старого не переписывается.

• Новый язык = новый файл. Кладёте `de.ts` рядом с `en.ts`; существующие файлы не трогаете.
• Перевод по ключам, а не «всё или ничего». Недостающее поле само подставится из английского — можно выкатить язык с одним переведённым заголовком и дополнять остальное со временем.
• Никаких языковых веток в коде страниц. Надписи живут в словаре перевода; «другой блок под язык» решается полем в данных, а не `if` в разметке.
• Дата отдаётся в правильной локали сама — и попутно это починило реальный баг, когда русская статья показывала дату английскими названиями месяцев.
• Линтер сторожит границу — чтобы старый костыль `язык === ru` не прокрался обратно по мере роста сайта и числа контрибьюторов (включая ИИ-агентов).

Главная победа — во втором пункте. Перевод «всё или ничего» — это и есть настоящий блокер на пути вширь. С фоллбэком по ключам 81-й язык можно выкатить с одним переведённым полем, и он отрендерится идеально — английский закроет все пробелы. Приоритетные языки получают полный, выверенный вручную перевод; длинный хвост просто существует, корректный, пока до него не дойдут руки.

Оптимизация и поиск — теперь одна работа: и для Google, и для ИИ

Вот к чему я всё время возвращаюсь: «сделать сайт приятнее» и «сделать сайт находимым» больше не разделить. Каждый язык теперь получает свой URL с правильными сигналами `hreflang` и свою поисковую поверхность — заголовок, описание, ключевые слова — написанную под своим углом, а не дословной калькой, чтобы поисковики видели разные страницы, а не дубль. И мы относимся к обнаружимости для ИИ как к каналу первого класса: каждое обновление отражается в наших машиночитаемых индексах (`llms.txt`, `llms-full.txt`), чтобы ИИ-краулеры и агенты его находили — так же, как другие наши обновления. Generative engine optimization — это не бонус-трек, а половина причины, по которой контент-слой устроен именно так.

Побочный эффект, который я оставил: навык мультиязычного контента — в стандарте

А теперь то, чему я по-настоящему рад. Из этого водоворота выпал переиспользуемый инструмент, и я решил сделать его частью стандартной архитектуры нашего стартера — а не разовой штукой для маркетингового сайта. Это навык агента, `create-multilingual-content-entry`: любой ИИ-агент в вашем проекте может им создать мультиязычный документ правильно — папку, полную базу, частичные оверрайды, строку в реестре и проверку, что языковые костыли не просочились. Он самодостаточен: работает, даже если в проекте один-единственный агент без оркестратора и без памяти — никакого общего мозга не требуется.

Я его оставил, потому что почти уверен: ровно это понадобится многим — особенно в Европе, где проект редко рождается на одном языке. Два языка, три, четыре; голый английский сайт часто даже не вариант. Поэтому, вместо того чтобы каждый заново выводил одну и ту же схему, навык вшивает её внутрь. Тот же инстинкт пронизывает и остальную платформу — конвейер AI Draft Settings, что растит навыки агента, и автономный цикл разработки, что превращает запрос в выкаченный код. Появляется способность — и мы делаем её прочной, самодостаточной частью архитектуры, а не трюком, который кто-то должен помнить.

Коротко, контент-цикл — это три простых хода:

1. Создать — одна папка на документ, с полной английской базой.
2. Перевести по ключам — добавить язык как частичный файл; всё остальное само откатывается на английский.
3. Опубликовать для обеих аудиторий — URL и SEO-поверхность под язык для Google и машиночитаемые индексы для ИИ.

А теперь это внутри самого стартера

За мной был должок. Мы сказали вам «измените настройку — и станете мультиязычными», но в стартере, который вы разворачиваете, ещё не было механизма, который делает это возможным. Поэтому мы его встроили. Та же маршрутизация, что крутит этот сайт, теперь поставляется со стартером — и вот как именно она себя ведёт.

По умолчанию ваш стартер выходит с двумя языками — английским и испанским. Именно поэтому вы видите кнопку языка на стартовой странице из коробки. Как только вы оставите в настройках переменных окружения один язык, кнопка сама становится недоступной, а весь сайт начинает отдаваться прямо от корня, без языкового префикса. Вы просто перечисляете нужные языки в одной переменной окружения и задаёте язык по умолчанию — больше ничего. (Одна честная оговорка: эти значения зашиваются при сборке, поэтому их смена требует пересборки.)

• Два языка и больше → кнопка-переключатель появляется, а контент живёт под `/en/…`, `/es/…` и так далее.
• Один язык → кнопка пропадает, страницы отдаются от голого корня без префикса.
• Служебные страницы всегда остаются в корне — ваши рабочие страницы (Архитектура, AI Core, Шаги разработки, …) никогда не получают языкового префикса; его получает только пользовательский контент.
• Навык уже в вашем проекте — `create-multilingual-content-entry` (и `install-language-switcher-dropdown`) поставляются со стартером. Их документацию можно прочитать прямо в AI Core.
• Удаляйте кнопку без страха — как только начнёте строить свой мультиязычный интерфейс, просто попросите агента вернуть выпадающий список языков. Шаблон у него уже сохранён, так что он вас поймёт.

Где разместить кнопку — решаете вы: естественные места — хедер или футер; ставьте туда, где она вписывается в дизайн. А если нужен одноязычный сайт — просто оставьте в переменной окружения один язык (его стандартный ISO-код, например `en`) и задайте его по умолчанию. Кнопка спрячется сама, а все страницы пойдут от голого корня, без префикса.

И немного личного. Ещё в 2016-м создание мультиязычных Web- и PWA-приложений стало для меня настоящим направлением бизнеса. Я нашёл нишу — меню для ресторанов, и из этого выросли два бизнеса, которые я провёл сюда через COVID. Мой проект тогда — maps.menu, и рынок мне открыла именно мультиязычная версия: моим ключевым преимуществом стало создание мультиязычных меню для ресторанов, парикмахерских и других туристических заведений острова Тенерифе. С тех пор я отношусь к мультиязычности с особым вниманием, потому что знаю, как это важно для малого бизнеса. Поэтому мне в радость решать для вас одну из самых сложных задач — интернационализацию и локализацию. Удачи в создании ваших приложений.