Все крупные компании, с которыми мы общаемся, упираются в одни и те же две проблемы.
Первая — налог на координацию ради согласованности.
Android-приложение делает одна команда. Веб-приложение — другая. Маркетинговый сайт, документация, внутренние инструменты — у всего этого разные владельцы, разные циклы релизов, свои проверяющие и свои пайплайны доставки.
Устаревшие инструменты умеют делиться памятью переводов и глоссариями между проектами. Есть рабочие пространства. Есть ресурсы на уровне организации. Но общее не значит обязательное. Термин в общем глоссарии — это подсказка переводчику, а не ограничение для модели. Согласованность между командами превращается в ручную дисциплину. Кто-то постоянно синхронизирует глоссарий. Кто-то снимает конфликты в терминах между командами. Кто-то догоняет команду, которая переводит call-to-action одним способом, пока другая уже выпускает его по-другому. Согласованности можно добиться. Но поддерживать её приходится непрерывно.
Внутри проекта каждой команды расхождения только нарастают. Память переводов сохраняет согласованность, пока сегменты не меняются. В кодовой базе, где рефакторинг идёт каждую неделю, сегменты тоже меняются каждую неделю. Наше исследование RAL показывает, насколько быстро расползается терминология, когда модель не получает извлечённый контекст.
Вторая проблема — цена ухода от инструментов, которые этот налог и создают. В крупной компании каждый фактор всё усложняет: глоссарии, накопленные разными командами; память переводов, собранная в TMX и проприетарных форматах вендоров в разных проектах; коннекторы, встроенные в CI каждой команды; списки переводчиков, согласованные через закупки; SSO, интегрированный с IdP.
Такая миграция выглядит как инженерная программа на несколько кварталов — и ни один менеджер по локализации не хочет быть её владельцем.
Для среды с несколькими командами подходят две архитектуры.
Первая заменяет память переводов на уровне проекта на движок локализации на уровне организации, который извлекает контекст во время инференса. Один глоссарий, одна тональность бренда — и приложение каждой команды использует один и тот же движок локализации.
Вторая заменяет сценарий, в котором миграцию выполняет клиент, на встроенного в команду инженера по локализации от Lingo.dev, который делает миграцию за наш счёт времени, а не за ваш.
Оба подхода уже давно работают для всех остальных частей вашей инфраструктуры — теперь мы хотим, чтобы локализация наконец их догнала.
Архитектура №1: движок локализации#
Движок локализации
Состояние-сохраняющий API перевода, который команды создают в Lingo.dev и настраивают на уровне организации. Каждый движок локализации хранит собственный глоссарий, тональность бренда, инструкции для конкретной локали и ранжированную цепочку моделей. В каждом запросе извлекаются подходящие термины из глоссария, добавляются в контекстное окно модели до генерации первого токена, а после завершения результат независимо оценивается. Первый перевод работает почти без контекста, тысячный — опирается на всё, что уже накоплено.
Движок локализации удерживает согласованность на уровне терминов, а не сегментов. Он привязан ко всей организации, а не к проекту одной конкретной команды. Один глоссарий, одна тональность бренда — и любой интерфейс каждой команды использует один и тот же движок локализации.
Запись в глоссарии для "Submit" срабатывает в любом испаноязычном интерфейсе — на кнопке, в теме письма, в tooltip. Неважно, веб-команда это или мобильная. Извлечение сопоставляет смысл, а не строки. Одна запись для "Deploy" срабатывает на "deploying", "deployment", "Deploy your app" — не нужна отдельная запись для каждой формы.
Тональность бренда привязывается к движку локализации для каждой локали. Каждый запрос её использует.
Инструкции — это отдельные, проверяемые правила в рамках конкретной локали. Соглашения по сокращениям, неразрывные пробелы, кавычки — каждое можно отлаживать отдельно.
Цепочка моделей направляет каждый запрос в основную модель с ранжированными резервными вариантами. Можно менять провайдеров, не трогая глоссарий.
AI-оценщик работает на независимой модели. Он оценивает каждый запрос отдельно по глоссарию и по каждой инструкции. Результат — прошёл или не прошёл, с объяснением причин и отслеживанием во временном ряду.
| Критерий | Инструменты на уровне проекта | Движок локализации на уровне организации |
|---|---|---|
| Область согласованности | На уровне проекта, на уровне команды | На уровне организации |
| Единица согласованности | Целый сегмент, привязанный к hash | Отдельный термин, сопоставляемый семантически |
| Сохраняется при переписывании исходного текста | Нет | Да |
| Между приложениями и командами | За счёт дисциплины; согласованность поддерживают люди | За счёт архитектуры; согласованность поддерживает движок локализации |
| Измерение качества | Проверки на основе правил (теги, числа) | Оценка LLM для каждого запроса |
| Гибкость моделей | Привязка к одному провайдеру | Ранжированная цепочка |
| Кто определяет результат | На усмотрение переводчика | Глоссарий имеет приоритет над моделью |
Расхождения становятся тем, что можно измерять, а не тем, с чем приходится мириться. Глоссарий срабатывает в каждом запросе. AI-оценщик проверяет соответствие в каждом запросе.
Этот механизм называется retrieval augmented localization (RAL). Во время инференса движок разбивает входной текст на n-граммы, строит для них эмбеддинги и выполняет поиск по косинусному сходству в векторном индексе глоссария. Найденные термины попадают в контекстное окно модели до генерации первого токена. По структуре это тот же RAG, только применённый к переводу.
В контролируемой оценке на нескольких провайдерах LLM и нескольких европейских языках RAL снизил число терминологических ошибок на 17–45%. Более 42 000 парных оценок качества. Holm-Bonferroni corrected p < 0.001 у каждого провайдера. Интегральные оценки качества вообще не смогли уловить этот разрыв.
Архитектура №2: встроенная в команду инженерия локализации#
Вторая проблема — миграция. У вас уже есть рабочий стек. Он создаёт этот налог, но он работает. Стоимость его замены — инженерное время, переработка интеграций, повторное подключение переводчиков, миграция исторических данных — раз за разом оказывается выше, чем стоимость самого налога.
Именно поэтому этот налог до сих пор платят. Мы видели, как одно и то же узкое место в миграции снова и снова тормозит переход серьёзных компаний, и решили взять миграцию на себя.
Когда Lingo.dev подключает крупную компанию, миграцией занимаются наши инженеры. Не как отдельной услугой поверх лицензии, а как стандартным путём онбординга.
Встроенный в команду инженер по локализации изучает ваш глоссарий, документы по тональности бренда, конфигурацию коннекторов и контракты с переводчиками. Он импортирует память переводов из TMX, а глоссарий — из любого устаревшего формата, в котором тот хранится. Ничего не приходится восстанавливать заново. Он собирает движок локализации в Lingo.dev с уже загруженной терминологией. Подключает его к вашему CI. Пропускает ваш пул переводчиков через асинхронный пайплайн, чтобы люди, которым вы доверяете, оставались в процессе.
Именно в сценарии с несколькими командами эта архитектура окупается сильнее всего. В старой схеме согласование терминологии между командами означает N синхронизированных миграций — каждая команда заново восстанавливает ключи и TM внутри своего проекта. Здесь движок локализации создаётся один раз. Дальше каждая команда подключает к нему своё приложение в удобном ей темпе. Согласованность между приложениями появляется уже на первой локали, которая начинает использовать движок, а не после того, как каждая команда завершит собственную миграцию.
Наши инженеры остаются с вами до вашего следующего вывода в продакшен — и ещё одного после него, — пока ваша внутренняя команда полностью не возьмёт систему на себя.
Именно так мы подключаем корпоративных клиентов.
Когда организация с несколькими командами выпускает изменения каждую неделю, перевод уже не может оставаться закупочным тикетом между заказчиком и поставщиком. Он должен идти рядом со следующим выводом в продакшен, а не после него. Именно так — через встроенную инженерию — Palantir, Scale AI, Ramp и другие инфраструктурные вендоры подключают корпоративных клиентов уже больше десяти лет.
Теперь мы хотим, чтобы локализация наконец их догнала.
Аудит
Инженер Lingo.dev изучает ваши исходные репозитории, существующую TM (включая экспорты TMX), глоссарий, коннекторы и контракты с переводчиками — во всех командах, которые отвечают за свои интерфейсы. Затем он готовит план миграции с порядком шагов и сроками. План остаётся у вас.
Движок, настроенный под ваш текущий уровень качества
Мы настраиваем движок локализации с вашим импортированным глоссарием, вашей тональностью бренда для каждой локали и вашим пайплайном переводчиков. До любого продакшен-трафика мы проводим сравнение side-by-side: результат текущего инструмента против результата движка, те же строки, та же неделя. Вы сами решаете, сохраняется ли нужный уровень качества.
Подключение к CI каждой команды
Без полного rip-and-replace. Движок локализации встраивается как один шаг в существующий пайплайн каждой команды. Процессы merge, процессы проверки, проверяющие — всё остаётся прежним. Движок просто заменяет старый шаг.
Переключение в вашем темпе
Сначала одна команда и одна пара локалей. Потом три. Потом остальные. Порядок выбираете вы. На каждом шаге мы проводим сравнение. Откат — это один коммит.
Передача вашей команде
Наш инженер передаёт систему вашей платформенной команде — с документацией, runbooks и on-call ротацией, которую мы покрываем, пока они не возьмут её на себя.
Подтверждения#
Исследование. Исследование RAL: более 42 000 парных оценок качества на нескольких провайдерах LLM и нескольких европейских языках. Holm-Bonferroni corrected p < 0.001 у каждого провайдера. Снижение числа терминологических ошибок составило 17–45%.
Конфигурация важнее выбора модели. Мы увидели, что у Mistral, Gemini, Claude, GPT — любая модель в связке с хорошим глоссарием, тональностью бренда и правильно настроенным контекстом стабильно даёт переводы эталонного качества, готовые к выпуску, за малую часть стоимости. Не потому, что мы улучшили модель. В каждом запросе движок локализации извлекает по сходству подходящие термины из глоссария, тональность бренда и инструкции локали и добавляет их в контекстное окно модели до генерации первого токена.
Масштаб в продакшене. На платформе переведено более 200M слов.
Клиенты, которых можно назвать. Mistral, Solana, SoSafe, Cal.com.
Область применения#
Lingo.dev помогает командам локализации самого разного масштаба — от компаний с одним продуктом и open-source-проектов до команд, работающих только с мобильными приложениями, и корпоративных платформ. Архитектура, описанная здесь, оптимизирована для крупных компаний, где несколько команд выпускают несколько приложений более чем для 20 локалей.
Что дальше#
Первый шаг — двухнедельный пилот. Одна команда, одна пара локалей.
С вами работает выделенный инженер по локализации — вместе с вашим владельцем локализации и техническим руководителем. Мы изучаем ваш рабочий процесс. Настраиваем систему измерения, чтобы вы могли видеть качество переводов на языки, которыми ваша команда не владеет: AI-оценщики на независимых моделях проверяют каждый перевод по вашему глоссарию и правилам. Оценка основана на MQM — стандартной системе оценки качества перевода.
Мы настраиваем движок локализации на основе вашего глоссария и документов по тональности бренда. Запускаем его на вашем исходном контенте параллельно с текущим инструментом. Вы видите разницу и принимаете решение.
Дальше мы планируем миграцию для остальных команд и локалей в вашем темпе, а не в нашем.
Свяжитесь с нашими экспертами по инженерии локализации уже сегодня.
