Большую часть контента можно выпускать сразу, как только движок возвращает результат. Но не всё. Регулируемые раскрытия информации, медицинские инструкции, заголовки, в которых особенно важна тональность бренда, — в таких случаях перевод должен сначала прочитать и утвердить человек, а не клиент после подачи жалобы.
Обычно встроить человека в автоматизированный поток — значит выбрать один из неудобных путей: держать запрос открытым, пока кто-то читает перевод, собирать собственную очередь проверки или вручную интегрировать API поставщика переводов. Этот этап решает всё внутри самой задачи. Когда humanEdit включён, асинхронная задача запускает движок, затем ставится на паузу до проверки человеком — вашей командой или внешним специалистом — и возобновляется с его правками, передавая этот результат на все последующие этапы.
Это третий этап пайплайна локализации, и, как любой этап, он применяется только к задачам, созданным через Async Localization API. Впервые работаете с пайплайном? Начните с обзора.
На этой странице
Как работает пауза#
После основного шага перевода задача передаёт AI-перевод человеку на проверку. Проверяющий читает его и либо утверждает без изменений, либо отправляет отредактированную версию. Только после этого задача продолжается. Результат человека — утверждённый или отредактированный — становится входом для всех следующих этапов и в конечном итоге outputData задачи.
Самое очевидное возражение против паузы в задаче на минуты, часы или даже сутки — стоимость: если запрос остаётся открытым, ресурсы расходуются, хотя ничего не происходит. Этот этап работает не так.
Ожидание работает по событию, а не через открытое соединение
Процесс возобновляется по событию — когда проверяющий отправляет результат в панели Lingo.dev (Внутренняя проверка) или когда приходит callback от поставщика перевода (Внешняя проверка). Здесь нет постоянного опроса в цикле и нет удержания открытого соединения, поэтому долгий тайм-аут не расходует вычислительные ресурсы в фоне. Задача может ждать человека 48 часов точно так же, как ждёт модель: она припаркована, а не крутится вхолостую.
Доступны два режима проверки, и они выбираются отдельно для каждого движка. Разница только в том, кто читает перевод: механика паузы, возобновления и передачи результата дальше в обоих случаях одинакова.
Внутренняя проверка#
Ваша команда проверяет переводы прямо в панели Lingo.dev. Незавершённые проверки попадают на страницу Human Reviewer вашей организации (/orgs/<org-id>/human-reviewer), а проверяющие получают уведомления, когда появляются новые элементы. Проверяющий берёт элемент в работу, затем либо утверждает перевод без изменений, либо отправляет отредактированную версию. После этого задача сразу возобновляется с его результатом.
Второй проверяющий не может взять элемент, если над ним уже работает кто-то другой. Назначение эксклюзивно: в каждый момент времени элемент закреплён только за одним проверяющим, поэтому два человека не смогут редактировать один и тот же перевод и незаметно перезаписать работу друг друга. Строка остаётся заблокированной за тем, кто взял её в работу, пока он не освободит её или не отправит результат.
Внутренняя проверка — режим по умолчанию для новых движков. Выбирайте его, если нужная языковая экспертиза уже есть внутри команды и вы хотите полностью контролировать итоговую формулировку без участия третьей стороны.
Права доступа#
Внутренняя проверка доступна не всем в организации — страница Human Reviewer защищена правами доступа, поэтому перевод на проверке видят только те, кому вы этот доступ выдали. Администратор организации назначает доступ через роли (Settings → Roles):
| Разрешение | Что даёт |
|---|---|
Проверять переводы (engine:review_translations) | Просматривать и обрабатывать очередь проверки: взять ожидающий перевод в работу, отредактировать его, утвердить без изменений или отправить отредактированную версию |
Управлять проверками (org:manage_reviews) | Историю проверок и статистику проверяющих по всем внутренним проверкам в организации |
Эти два разрешения разделены намеренно. Проверяющему нужно только Проверять переводы — этого одного права достаточно для всей работы: взять, отредактировать, утвердить, отправить. Управлять проверками — для тех, кто курирует процесс; оно даёт доступ к истории и статистике по всей организации, но само по себе не открывает очередь. Выдавайте оба права руководителю, который и проверяет, и следит за метриками; только первое — тому, кто просто работает с очередью.
Внешняя проверка#
Если у вас нет внутренних проверяющих для нужной локали, перевод отправляется квалифицированному профессиональному переводчику через внешнего поставщика. Задача ставится на паузу точно так же и возобновляется, когда поставщик возвращает отредактированный перевод. В вашем коде ничего не меняется — меняется только то, кто читает строку, а не поведение самой задачи.
У внешней проверки есть два уровня, и различаются они тем, насколько высокой точности требует контент:
| Уровень | Лучше всего подходит для |
|---|---|
| Standard | Точного перевода с естественным человеческим звучанием — маркетинговых текстов, строк интерфейса, справочного контента |
| Pro | Профессионального использования с ещё более высокой планкой точности — юридического, медицинского и регулируемого контента |
Здесь важно сказать прямо: Внешняя проверка — это реальный переводчик по ту сторону процесса, со всеми вытекающими сроками и стоимостью. Это не «более быстрая модель». Используйте её там, где важна именно человеческая экспертиза, — для регулируемых текстов и критически важного контента, — а для основной массы контента, которой это не требуется, опирайтесь на сценарий только с AI.
Тайм-аут#
Этап с человеком добавляет риск, которого нет у AI-этапов: человек может вообще не ответить. Проверяющий в отпуске, поставщик перегружен, про элемент забыли. Если не задать границы, задача будет ждать бесконечно.
Поэтому ожидание ограничено. Вы задаёте, как долго Процесс ждёт результат от человека — одна и та же настройка timeoutHours применяется к обоим режимам проверки. Если тайм-аут истекает без ответа, этап помечается как skipped, и задача продолжает работу с AI-переводом как итоговым результатом. Значение по умолчанию — 48 часов.
Скажем прямо о цене такого решения: при тайм-ауте вы выпускаете непроверенный AI-перевод. Для большинства типов контента это правильный запасной вариант — лучше опубликовать перевод, чем держать задачу открытой бесконечно, — но компромисс здесь реальный. Для контента, который человек должен утвердить при любых условиях, задайте щедрый тайм-аут и настройте оповещение о пропуске; для контента, где проверка желательна, но не обязательна, короткий тайм-аут не даст пайплайну остановиться.
Тайм-аут задаётся для этапа, а не для всей задачи
Тайм-аут определяет только то, как долго этот этап ждёт человека. Он не связан с тем, сколько времени занимают остальные части задачи. Поскольку ожидание работает по событию, длинный тайм-аут влияет только на задержку до итогового результата, если проверяющий медлит, — но никогда не на фоновые вычисления.
Как включить этап#
humanEdit настраивается так же, как любой этап пайплайна: через значение по умолчанию на уровне движка во вкладке Pipeline и, при необходимости, через переопределение для отдельного запроса. Полная двухуровневая модель описана в разделе Configure the pipeline; структура именно для этого этапа выглядит так:
{
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
}
}provider выбирает режим — internal для вашей команды, иначе используется внешний поставщик. tier (standard или pro) применяется к Внешней проверке и игнорируется для Внутренней. timeoutHours — это ограничение из раздела выше. Чтобы переопределить настройку для одной отправки, передайте этот блок внутри pipelineConfig в вызове create; если его опустить, задача унаследует настройку движка.
Когда этап срабатывает, он записывает себя в задачу в разделе stepId: "humanEdit" со статусом completed, failed или skipped — это та же запись шага, которую создаёт каждый этап. Как читать эти записи, описано в разделе Observe pipeline runs.
Правка человека может расходиться с правилами вашего движка
Человек-переводчик может выбрать формулировку, которая расходится с вашим glossary, тональность бренда или instructions — его задача хорошо переводить, а не заучивать вашу конфигурацию. Чтобы автоматически привести правки человека в соответствие с правилами движка, включите следующий этап — AI-оценка. Он запускается только после этапа с человеком, который действительно выдал результат.
