Я построил платформу для публикаций на 90 языках — и первым делом ограничил её возможности

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

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

Оказалось, что это только половина проблемы.

Модель можно заменить. Промпт можно переписать. Неудачный перевод можно перегенерировать.

Гораздо труднее ответить на другой вопрос:

Следует ли продукту автоматически делать всё, что он технически умеет?

Моя платформа Nneon поддерживает 90 языков. В первоначальной версии автор мог практически одним действием превратить одну публикацию в десятки отдельных страниц.

За первый месяц восемь исходных материалов превратились примерно в 400 URL.

Google часть из них начал показывать. Часть неделями не сканировал. А я в итоге ограничил собственную платформу: теперь одной публикации не нужно автоматически становиться девяноста поисковыми страницами.

Встроенный перевод сегодня есть почти везде.

Браузер может перевести страницу. Социальная сеть может показать машинную версию поста. Мессенджер может перевести сообщение по нажатию.

Но обычно это выглядит так:

одна исходная страница → читатель нажал «Перевести» → интерфейс временно показал другой текст

Автор почти не управляет результатом. У перевода нет собственной истории редактирования, статистики и отдельного адреса. Поисковик тоже не получает полноценную страницу для новой языковой аудитории. Мне хотелось сделать наоборот:один оригинал → несколько самостоятельных публикаций

Например:

/ru/post/article /en/post/article /de/post/article /fr/post/article

Каждая версия существует отдельно. Автор может изменить французский текст, не затронув немецкий. Может закрыть один язык от индексации и оставить другой открытым. Может посмотреть, какая версия получает показы, а какая никому не нужна.

На этом и строится Nneon.

Платформа сейчас поддерживает 90 языков публикаций. Интерфейсные локали я генерирую связкой из скрипта и языковой модели: скрипт собирает и проверяет структуру, модель переводит значения. Вручную поддерживать примерно 900 JSON-файлов мне бы не захотелось даже из большой любви к собственному проекту.

Маркетингово число выглядит прекрасно.

Одна статья — до 90 языков.

Кажется, что автор получает почти мгновенный доступ ко всему миру. Несколько долларов — и материал существует на английском, испанском, немецком, французском, японском, индонезийском и ещё десятках языков.

Но у базы данных и Google другое представление о романтике международной публикации.

Каждый новый язык — это:

Я смотрел на 90 языков как на одну функцию.

На деле это были 90 новых обязательств.

Изначально я рассчитывал, что качество можно получить правильным пайплайном.

Логика выглядела разумно:

первая модель переводит → вторая проверяет → найденные ошибки исправляются → получается почти профессиональный текст

После первых тестов лучшим вариантом мне казался двойной прогон через GPT-4.1.

Проблема обнаружилась, когда я опубликовал статью о Тренте Резноре.

В русском оригинале была фраза:

"Я создавал платформу под его музыку."

Смысл очевиден для русскоязычного читателя: я слушал эту музыку во время работы.

Одна из версий (испанская) перевода передала мысль примерно так:

"Я создавал платформу для его музыки."

Слова были узнаваемыми. Грамматика не развалилась. Но связь между событиями полностью изменилась: фоновое сопровождение превратилось в назначение продукта.

Что особенно забавно, с отдельным предложением справлялся Google Translate. Многоступенчатый LLM-пайплайн — нет.

Дальнейшие тесты показали ещё более неприятную вещь: модель-проверяющий может исправить реальную ошибку, а затем переписать нормальный фрагмент и создать новую.

Дополнительный проход иногда:

Себестоимость одного языка в одном из вариантов выросла примерно с 20 центов до доллара. Стабильного профессионального качества это не дало.

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

Но автоматический процесс не может гарантировать одновременно:

Поэтому продуктовая схема стала другой:

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

Профессиональное качество должно появляться там, где уже проявился реальный интерес, а не там, где модель просто сумела сгенерировать текст.

Каждую найденную ошибку можно было бы превращать в новое правило:

Если встретилась такая конструкция, переводи её вот так.

Проблема в том, что универсальный промпт должен обслуживать разные жанры, темы и 90 языков. Если добавлять туда каждый частный случай, он постепенно превращается в энциклопедию прошлых неудач.

Поэтому я разделил контроль автора на два механизма.

Первый — защищённые фрагменты:

[[[Nneon]]] [[[OpenRouter]]] [[[GPT-5.6 Terra]]]

Содержимое тройных скобок не переводится. Система временно заменяет его техническим токеном, а после генерации возвращает исходное значение.

Второй — комментарий переводчику:

Фраза "создавал платформу под его музыку" означает, что я слушал эту музыку во время разработки. Платформа не создавалась для музыканта.

Первый инструмент говорит:

"Не меняй форму."

Второй:

"Правильно пойми намерение автора."

AI при этом вообще не обязателен. Двойной клик по языку создаёт бесплатную копию исходной публикации. Она не попадает в ленту и не открывается для индексации, пока автор не заполнит её правильным языком.

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

После запуска я хотел получить ответ на простой вопрос:

Будет ли Google вообще показывать автоматически переведённые страницы нового неизвестного домена?

Ответ оказался положительным.

Немецкая версия одной публикации начала получать поисковые показы. Статья о композиторе Мике Гордоне появилась в выдаче сразу в нескольких языковых вариантах, хотя находилась далеко от первых позиций и почти не получала переходов.

Потом я ввёл в Google собственный ник и увидел несколько десятков страниц, опубликованных через Nneon на разных языках.

Это не строгий научный эксперимент. Результаты зависят от региона, персонализации и истории запросов. Но как практическое подтверждение архитектуры этого было достаточно:

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

Но одновременно десятки других адресов оставались в Search Console со статусами:

"Обнаружена, не проиндексирована."

Или:

"URL неизвестен Google."

Страницы находились в sitemap и нормально открывались, но поисковик до них ещё не дошёл.

Я сначала говорил, что исчерпал краулинговый бюджет. Для сайта из нескольких сотен страниц это не совсем точное описание.

Правильнее сформулировать иначе:

Новый неизвестный домен создавал страницы быстрее, чем получал достаточный приоритет их обхода.

Для меня это было 400 полноценных объектов в базе.

Для Google — восемь исходных тем, быстро размноженных по множеству языков, на сайте без репутации, ссылок и постоянной аудитории.

После этого максимальное количество индексируемых языков одной публикации сократилось до десяти.

Возможно, стартовое значение в итоге будет ещё ниже — например, три языка с последующим расширением.

Но сама поддержка 90 языков никуда не исчезла.

Изменился смысл функции:

было: платформа поддерживает 90 языков → нужно сразу открыть 90 страниц стало: платформа поддерживает 90 языков → автор выбирает несколько осмысленных направлений → расширяет охват после появления данных

Технический максимум оказался плохим поведением по умолчанию.

Большинству статей не нужна одинаковая представленность на всех языках. Автору технического кейса могут быть полезны английский, немецкий и испанский. Локальной культурной публикации — совсем другой набор.

Языки нужно выбирать по аудитории, а не по числу кнопок, которые удалось разместить в интерфейсе.

Когда одна публикация существует в нескольких языковых вариантах, вручную искать каждый адрес в Search Console неудобно.

Поэтому основные данные Google я вывел непосредственно в статистику Nneon.

Автор видит:

На одном из первых замеров картина выглядела так:

Для зрелого контентного сайта эти цифры почти ничтожны.

Для неизвестного проекта возрастом около месяца важен сам факт: цепочка начала работать.

автоматический перевод → отдельная страница → обнаружение Google → поисковые показы → решение о ручной редактуре

Статистика должна отвечать не на вопрос «сколько страниц мы сгенерировали», а на вопрос:

Какой из переводов начал приносить пользу?

До продакшена я тестировал сайт как разработчик.

Создал запись. Нажал кнопку. Получил перевод. Значит, функция работает.

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

Если несколько часов писал оригинал, заплатил за десять языков и вручную улучшил две версии, уже нельзя одной кнопкой случайно уничтожить результат.

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

Например, русскоязычный пользователь может редактировать французский текст, продолжая видеть русский интерфейс. Для поисковика публикация при этом остаётся французской страницей:

/fr/post/article

Язык контента и язык интерфейса — два разных состояния. До собственного использования платформы это казалось мелкой деталью. После — стало обязательным поведением.

За первый месяц я получил подтверждение, что:

Но я пока не доказал главного:

Это уже нельзя проверить, продолжая публиковать только собственные статьи.

Лучше всего для эксперимента подходят материалы, основанные на личном опыте:

Общий текст «десять способов повысить продуктивность» нейросеть сегодня напишет без участия автора.

С личным опытом иначе. Модель может помочь его оформить или перевести, но не может сама прожить конкретные события, совершить ошибки и сделать выводы.

Именно такой материал имеет смысл переносить в другую языковую среду.

Писать новую статью специально для Nneon не нужно. Можно взять уже опубликованный материал, если права принадлежат вам.

Для первых тестов я готов предоставить ограниченный баланс на несколько переводов.

Международную аудиторию обещать пока не буду. Сначала её нужно получить и измерить.

От автора мне нужны:

Работающая платформа:

Nneon пока не приносит мне доход, поэтому параллельно я ищу работу:

До этого проекта я в основном называл себя фронтенд-разработчиком с UX/UI-бэкграундом.

Теперь точнее будет сказать, что мне интересна ответственность за пользовательский продукт целиком: от интерфейса и поведения функций до API, экономики, SEO, аналитики и запуска.

Пожалуй, главный урок разработки оказался простым:

Вызвать модель и создать ещё одну страницу несложно. Гораздо труднее вовремя решить, что очередную страницу создавать не нужно.