С 1 марта 2026 года вступил в силу Федеральный закон №168-ФЗ, где сформулированы поправки к закону о защите прав потребителей, которые обязывают использовать русский язык в публичной информации для потребителей товаров и услуг. Нашу платформу ОНЛАНТА ИИ ХАБ пришлось срочно русифицировать. Делимся опытом в блоге ЛАНИТ, как мы подошли к задаче, как учли юридические риски, что делать с англицизмами и как это влияет на пользовательский опыт и метрики.
Что изменилось: юридический контекст
Базовая норма — новая статья 10.1 в законе о защите прав потребителей. Она регулирует публичную информацию: все, что производитель, исполнитель или продавец размещают для публичного ознакомления через любые носители. Вывески, надписи, таблички, конструкции — все это теперь должно быть на русском языке. Реклама в эту категорию не попадает. Ее регулирует отдельный закон (№38-ФЗ «О рекламе»), где требование о русском языке и так давно действует.
Главный вопрос, распространяется ли это требование на информацию, размещенную в Интернете. Изначально закон не отвечал на него конкретно, но Роспотребнадзор разъяснил, что в этой трактовке сайты, расположенные в сети Интернет, приравниваются к публичной информации. Поэтому необходимость русификации стала очевидной.
Как русификация из редакторской задачи превратилась в рефакторинг
Когда стало ясно, что онлайн-интерфейсы попадают под регулирование, мы поняли, что публичная часть платформы должна быть юридически нейтральной. Это оказалось масштабной задачей — пришлось делать полноценный аудит продукта.
Шаг 1. Тотальная инвентаризация текстов
Мы выгрузили все, что можно (основные элементы интерфейса платформы, системные сообщения, ошибки, онбординг, тарифные страницы) из систем управления контентом, почтовых шаблонов, пуш-уведомлений. Отдельно прошлись по жестко зашитым строкам. Именно там прятались самые живучие англицизмы.
Собрали реестр из сотен текстовых единиц. Каждую промаркировали: англицизм или заимствование.
Шаг 2. Терминологический ад
Самая сложная часть — не техническая, а терминологическая. Как перевести слово dashboard, чтобы пользователи поняли, юрист был доволен, а продукт не потерял узнаваемость?
Мы выработали три правила.
-
Есть устойчивый русский аналог — берем его (например, settings — «Настройки»).
-
Термин профессиональный, но эквивалент понятен — выбираем нейтральный перевод (dashboard → «Панель управления»).
-
Для спорных случаев собрали рабочую группу из продакта, маркетолога, юриста.
Все принятые решения по терминологии мы зафиксировали для коллег.
До этого у нас была локализация (мы уже использовали термины на русском), но не было строгого терминологического контура. Русификация заставила его выстроить: создали единый словарь, запретили вольные вариации переводов в разных модулях, синхронизировали продуктовые тексты с маркетингом, обновили гайды для дизайнера и редактора. Если в одном месте «Рабочее пространство», то в другом не может внезапно появиться Workspace.
Шаг 3. Архитектурные изменения, которых мы не планировали
Дальше началось то, что мы изначально недооценили.
Первое — вычистили все захардкоженные строки. Раньше часть сообщений об ошибках формировалась на бэкенде на английском, отдельные модули использовали собственные словари, какой-то текст был просто зашит во фронтенде.
Ввели жесткое правило: ни одной строки в коде вне языковых файлов. В некоторых случаях для локализации используется i18n, но мы решили не отдавать русификацию на полную автоматизацию, так как это могло привести к рискам неправильных переводов. Синхронизировали фронтенд и бэкенд по кодам ошибок — теперь сервер возвращает только код, а текст подтягивается из UI-слоя.
Второе — столкнулись с проблемой длины русских слов. После замены коротких англицизмов, которые использовались в качестве наименований наших ИИ-агентов, сломались ширина кнопок, поведение табов, переносы в мобильной версии, адаптивные сетки. Пришлось пересобирать часть компонентов, добавлять динамическое вычисление ширины, перерабатывать layout там, где текст был завязан на фиксированные контейнеры.
Третье — привели в порядок системные уведомления и почтовые шаблоны. Интерфейс — не единственная публичная часть. Под требования попали транзакционные письма, пуши и системные алерты. Централизовали шаблоны, перепроверили, нет ли там английских слов, синхронизировали стиль с интерфейсом. Это неожиданно улучшило консистентность коммуникации.
Параллельно шла юридическая валидация. Документально зафиксировали, что считаем публичной информацией внутри продукта, какие разделы относим к UI, какие элементы подпадают под исключения.
В итоге мы получили документированную позицию, которая позволила понять, как избавиться от англицизмов без рисков.
Если оглянуться назад, русификация стала точкой взросления архитектуры. Мы перестали относиться к тексту как к второстепенному слою и встроили контроль языка в сам процесс разработки. Это заняло больше времени, чем мы планировали, но в долгосрочной перспективе упростило сопровождение продукта.
Юридическая часть (сложнее технической)
Пока шла техническая работа, параллельно выстраивался юридический контур проекта. Готовых решений здесь оказалось меньше, чем в архитектуре — закон только вступил в силу, практика правоприменения не сложилась, а отвечать за результат нужно уже сейчас.
Проблема языкового барьера
Юристы оперировали формулировками закона, разработчики — конкретными UI-элементами. Необходимо было перевести правовые нормы на язык продуктовых решений.
Мы собрали рабочую группу из юриста, продуктового менеджера и технического лида. Договорились о простом принципе: юрист не говорит «это должно соответствовать закону», он говорит «вот эти элементы интерфейса попадают под регулирование, потому что…» А мы уже решали, как именно их приводить в соответствие.
Вместе прошлись по реестру текстовых единиц, собранному на этапе инвентаризации. Для каждой позиции фиксировали, является ли она публичной информацией, адресованной неопределенному кругу лиц, попадает ли под исключения, требуется ли перевод или допустимо оригинальное написание.
Определяли глубину изменений для каждой категории. Одно дело — кнопка входа, другое — техническое сообщение об ошибке, которое видит только админ. Юридическая формулировка про «неопределенный круг лиц» помогла провести границу.
Исключения, которые не исключения
Закон предусматривает возможность использования иностранных слов, если они общеупотребительны и не имеют аналогов в русском. Но кто определяет, что общеупотребительно, а что нет? Мы не стали рисковать и опираться на эту формулировку. Если слово можно перевести без потери смысла — переводили.
Документирование решений
Самый важный итог юридической части — фиксация документированной позиции по каждому спорному моменту. В нашем протоколе зафиксировано, какие слова нужно убрать, а какие можно оставить.
Что стало с брендом и рекламной кампанией
Когда мы разобрались с интерфейсами, перед нами встал следующий вопрос: а что делать с внешними коммуникациями? Сайт, посадочные страницы, баннеры, рекламные макеты — все это тоже подпадает под действие закона. Здесь юридические требования пересеклись с маркетингом и узнаваемостью бренда, и простое решение «перевести все на русский» перестало работать.
Наш продукт назывался ONLANTA AI HUB. Формально «искусственный интеллект» по-русски — это ИИ. Но мы хотели сохранить название продукта с минимальными изменениями. В итоге родился компромисс: в коммуникациях и рекламных кампаниях мы используем наименование ОНЛАНТА ИИ ХАБ, но в логотипе было принято решение использовать АИ ХАБ. Это позволило сохранить знакомый визуал и при этом следовать новому закону.
Это решение запустило цепную реакцию в маркетинге. Пришлось пересобрать все внешние коммуникации: переверстать баннеры и посадочные страницы с учетом того, что кириллица почти всегда шире латиницы, переписать тексты для контекстной рекламы, обновить креативы в соцсетях. Самым сложным было объяснить, почему мы не можем оставить AI как есть, — пока коллеги не увидели формулировки закона и не поняли, что альтернативой был бы полный перевод со всеми вытекающими.
Выводы. Что важно учесть
Проект русификации оказался сложнее, чем мы предполагали, и дал несколько важных уроков, которые стоит учитывать, если вы только готовитесь к такому же переходу.
1. Начинайте с аудита. Не верьте, что у вас все локализовано. Английские строки найдутся там, где не ждали: в бэкенд-сообщениях, старых модулях, маркетинговых попапах, письмах, документации.
2. Вырабатывайте правила до начала перевода. Терминологические споры лучше решить один раз сначала, чем переводить одно и то же слово по-разному в каждом модуле. Глоссарий и простые правила экономят месяцы согласований.
3. Закладывайте рефакторинг в бюджет. Русификация почти гарантированно потребует архитектурных изменений: вычистить захардкоженные строки, добавить линтеры, переверстать компоненты под длинные русские слова. Лучше заложить это сразу.
4. Документируйте юридические решения. По каждому спорному случаю (товарный знак, отсутствие аналога, исключение) фиксируйте обоснование. Если придет проверка, вы должны показать не только результат, но и логику, по которой его приняли.
5. Встраивайте контроль в процессы. Разовой чистки недостаточно. Линтер на запрещенные слова, проверка терминологии в code review, чек-листы для продуктовых команд — единственный способ не получить обратно английские строки через полгода.
Мы собрали все силы, провели эту работу и привели продукт в соответствие с требованиями. Системный подход к русификации дал и неожиданный плюс: мы получили более зрелую архитектуру, навели порядок в терминологии и сделали продукт целостнее. А дальше нам остается лишь внимательно следить за новостями и разъяснениями от регуляторов.
Автор: Onlanta
