Качественная локализация сохраняет смысл и помогает человеку выполнить действие в своей языковой среде. Грамматически гладкий перевод может оказаться неверным: поменять условие, перепутать валюту или не поместиться на кнопке. ИИ полезен для предварительного поиска проблем, если проверять несколько измерений качества отдельно и передавать спорные места человеку, знающему язык и продукт.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb. Он описывает проверку уже подготовленного перевода, а не обещает заменить профессиональную редактуру в любой языковой паре.
Передайте модели контекст строки
Для каждой записи нужны оригинал, перевод, ключ, назначение, экран и ограничения. Одна и та же английская строка может иметь разные переводы в зависимости от того, обозначает ли она команду, статус или название объекта. Без контекста модель оценивает правдоподобность фразы, а не правильность интерфейса.
Добавьте глоссарий и правила обращения к пользователю. Отдельно укажите неизменяемые переменные, HTML-теги и служебные обозначения. Если строка содержит количество, приложите используемую схему множественных форм. Не просите помощника исправлять программный синтаксис по догадке: он должен отметить проблему и сохранить технические элементы.
Разделите проверку на несколько проходов
В первом проходе сравните смысл: отрицания, условия, субъект действия, обязательность и последствия. Во втором проверьте термины и единообразие. В третьем — числа, даты, единицы и обозначения валют. Затем оцените длину, переносы и понятность текста в реальном интерфейсе.
Такое разделение помогает не смешивать критическую ошибку с вкусовой правкой. Неверное «удалить навсегда» вместо «убрать из списка» требует немедленного исправления. Два допустимых варианта вежливой формулировки могут быть вопросом редакционного предпочтения. Для каждой находки указывайте категорию, серьёзность, объяснение и предлагаемое изменение.
Учебный пример проверки двадцати строк
Предположим, в наборе из 20 строк найдены 3 существенные проблемы: потеря отрицания, изменённая переменная и двусмысленная дата. Строка «Do not close this window» переведена как «Закройте окно» — это смысловая ошибка. Замена {count} на {количество} может нарушить подстановку, если приложение ожидает исходный ключ. Запись 04/05 без локали допускает разные толкования.
Оставшиеся 5 замечаний касаются длины и терминов. Их нельзя складывать с критическими ошибками в единый показатель «40% плохого перевода» без определения метода. Лучше показать распределение по категориям и проверить, какие строки действительно мешают действию. Условные числа здесь иллюстрируют отчёт, а не стандарт оценки качества.
Проверь локализацию по оригиналу, контексту и глоссарию.
Для проблемы укажи ключ, категорию, серьёзность,
объяснение, исправление и уровень уверенности.
Проверяй смысл, отрицания, условия, термины, числа и переменные.
Не меняй служебные ключи, плейсхолдеры и теги без основания.
Отдели обязательные исправления от стилистических предпочтений.
Если контекста недостаточно, сформулируй вопрос, а не догадку.
Языковая пара и локаль: [данные]. Строки: [таблица].Проверьте результат в продукте
Текстовая таблица не показывает обрезание, неверный порядок элементов и проблемы переноса. Откройте ключевые экраны с реальными данными и крайними значениями. Проверьте короткие и длинные имена, нулевое и большое количество, ошибки и пустые состояния. Для языков с другим направлением письма нужен отдельный осмотр расположения элементов.
Попросите носителя языка или квалифицированного редактора оценить важные пользовательские сценарии целиком. Вежливый тон отдельной строки может звучать неуместно в ситуации потери данных или отказа платежа. Контекст экрана и последствия действия важнее буквального сходства с оригиналом.
После исправлений повторно проверьте затронутые строки и технические элементы. Сохраняйте одобренные термины в глоссарии с примерами применения. Не переносите решение автоматически на все случаи одного слова: термин в бухгалтерском разделе может отличаться от обычного значения в справке.
Для сообщений с числами проверьте все формы, которые реально поддерживает продукт: один объект, несколько объектов, ноль и большое значение. Отдельно посмотрите строки с именами и другими переменными, которые могут быть длиннее примера переводчика. Ограничение длины лучше задавать через поведение интерфейса, а не только количество символов. Короткая строка тоже может переноситься неудачно из-за шрифта, ширины кнопки и масштаба отображения.
Чек-лист выпуска локализации
- Смысл и условия исходника сохранены.
- Переменные и служебные элементы не повреждены.
- Форматы чисел и дат соответствуют выбранной локали.
- Текст проверен на реальных экранах.
- Критичные сценарии просмотрел компетентный человек.
Частые вопросы
Можно ли проверять перевод без оригинала?
Можно оценить естественность языка, но нельзя надёжно проверить точность передачи смысла. Для полноценной проверки нужен исходный текст и контекст.
Нужно ли исправлять все замечания модели?
Нет. Часть замечаний может быть ошибочной или вкусовой. Принимайте изменения по глоссарию, контексту и согласованным критериям качества.
Различие локализации и интернационализации объясняет материал W3C Internationalization. Он помогает отделить языковую редактуру от подготовки самого продукта к разным локалям.