Опечатку в исходном тексте можно исправить только один раз — до того, как она размножится. Async-задача разветвляет один исходный payload на все целевые локали, и каждая локаль переводит тот текст, который получила. Поэтому орфографическая ошибка, пропущенное слово или сломанное предложение в источнике не остаются одной проблемой. Это становится одной и той же проблемой на немецком, на французском и в любой другой локали, которую затрагивает задача, — и потом каждую версию приходится исправлять отдельно.
AI-редактирование перед локализацией (preEdit) закрывает этот зазор в самом источнике. Это первый этап async-пайплайна локализации: прежде чем запустится основной шаг перевода, AI-агент проверяет исходный payload и исправляет опечатки, грамматические и орфографические ошибки. В перевод уходит уже очищенный исходный текст — то есть вы исправляете его один раз до разветвления, а не вылавливаете одну и ту же ошибку в десятке результатов.
Это этап async-пайплайна, поэтому он выполняется только для задач, созданных через Async Localization API. Синхронная конечная точка /localize запускает только основной шаг перевода и игнорирует настройки пайплайна.
Что делает этот этап#
preEdit работает с исходным текстом, а не с переводом. AI-агент читает ваш исходный payload и правит его, убирая поверхностные ошибки — опечатки, грамматические и орфографические ошибки, — а затем передаёт исправленный текст основному этапу локализации. Каждая целевая локаль переводит уже этот очищенный источник.
Область действия здесь намеренно узкая — и в этом весь смысл. Это проход по очистке текста, а не его переписывание: он устраняет тот поверхностный шум, который делает исходный текст неоднозначным для модели перевода, чтобы модель тратила внимание на перевод, а не на догадки о том, что имелось в виду в искажённой фразе. Чем чище источник, тем более согласованными получаются переводы между локалями — потому что каждая локаль стартует из одного и того же исправленного текста, а не потому, что каждая модель по-своему интерпретирует одну и ту же ошибку.
Если вам нужен идиоматичный, естественно звучащий результат — когда сам перевод переписывается так, будто его писал носитель языка, — для этого есть другой этап. См. Rephrase for natural copy. preEdit очищает вход; rephrase полирует выход.
Он не может ухудшить задачу#
Первый вопрос, который задаёт осторожный инженер об AI-этапе, редактирующем контент перед переводом, — совершенно правильный: что произойдёт, если этот этап ошибётся или вообще не сработает?
preEdit — некритичный этап. Если вызов предварительного редактирования завершится ошибкой или по тайм-ауту, исходный текст будет передан дальше без изменений, а задача продолжит выполнение на шаге перевода ровно так, как если бы этот этап был выключен. Сбой здесь лишает вас очистки для конкретной задачи — но не самой задачи. Перевод всё равно уйдёт в доставку.
Что, если предварительное редактирование завершится ошибкой или по тайм-ауту?
Задача не завершится с ошибкой. Некритичные этапы откатываются к своему входу: при сбое preEdit неотредактированный исходный текст переводится как есть, и задача доходит до завершения. Статус задачи становится completed_with_warnings, шаг preEdit фиксируется как failed, а причина попадает в массив warnings задачи — так что вы увидите, что это произошло, но без блокировки доставки. О том, как читать записи этих этапов, рассказано в разделе Observe pipeline runs.
Если говорить совсем прямо: включение preEdit не может привести к сбою задачи, которая иначе завершилась бы успешно. Худший сценарий — этап не поможет в конкретной задаче и тихо отойдёт в сторону.
Чем это не является#
Важно сказать это прямо — именно там, где больше всего хочется, чтобы этап умел больше: preEdit работает в режиме best-effort и представляет собой очистку текста от поверхностных ошибок, а не корректора, который понимает вашу предметную область, и не фактчекера, который проверяет ваши утверждения. Он исправляет опечатки, грамматику и орфографию. Он не проверяет, верна ли цена, актуально ли название продукта или действительно ли фраза выражает именно то, что вы хотели сказать. Если исходный текст фактически неверен, preEdit добросовестно исправит грамматику ошибочного предложения и так же аккуратно переведёт его на каждую локаль.
Если есть термины, которые должны оставаться в точности как написано независимо от любого AI-прохода, — названия продуктов, товарные знаки, идентификаторы кода, — закрепляйте их в источнике. Пометьте их как непереводимые в glossary вашего движка локализации или, для структурных полей в конкретном payload, исключите их с помощью lockedKeys. Это гарантии на уровне данных; preEdit — лишь best-effort-очистка вокруг них.
Когда это включать#
preEdit оправдывает дополнительный проход, когда в исходном тексте вероятен шум, и становится избыточным, когда источник уже чист.
- Включайте его, когда исходный контент создан пользователями, извлечён машинно, собран парсингом, получен через OCR или иным образом создан вне редакционного процесса — то есть там, где поверхностные ошибки обычны, а цена их размножения по локалям вполне реальна.
- Пропускайте его для подготовленного контента, который уже прошёл редактуру или проверку человеком. Если источник чист, этапу нечего исправлять, и вы просто будете платить за AI-проход, у которого нет работы. Каждый включённый этап — это ещё один шаг в задаче и ещё одна строка в её стоимости: это оправдано там, где качество источника под вопросом, и пустая трата там, где оно уже не вызывает сомнений.
В этом и состоит весь компромисс: потратить один проход в начале на те задачи, где качество источника неясно, чтобы исправить ошибку один раз до разветвления, — вместо того чтобы исправлять одну и ту же ошибку во всех локалях уже после доставки.
preEdit включается на вкладке Pipeline вашего движка локализации, где применяется ко всем async-задачам, направленным в этот движок, либо переопределяется для одной отправки через pipelineConfig в запросе создания задач. Оба уровня и то, как пропущенный этап наследует значение по умолчанию от движка, описаны в разделе Configure the pipeline.
