7 типовых провалов в l10n-процессе, которые ломают релиз сильнее, чем плохой перевод

7 типовых провалов в l10n-процессе, которые ломают релиз сильнее, чем плохой перевод

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

— Нет единого источника истины: строки правят в нескольких местах, а translation memory быстро засоряется дублями.
— Термины не закреплены в glossary: один и тот же продукт переводят по-разному в UI, help center и письмах.
— Нет правил для plural forms, placeholders и длины строки: интерфейс выглядит целым до первого языка с другой морфологией.
— Машинный перевод подключён без post-editing flow: экономия на старте превращается в ручную зачистку позже.

Ещё один частый провал — отсутствие ownership. Если product, engineering и l10n не договорились, кто принимает решения по спорным строкам, локализация начинает тормозить весь release train. В таких командах обычно страдают и QA, и скорость обновлений.

Хороший минимум: один source of truth, glossary для ключевой терминологии, автоматическая проверка плейсхолдеров и отдельный review-этап для рискованных языков. Тогда локализация перестаёт быть «последним шагом» и становится частью сборки.