Локализация на этапе дизайна. Объединяем усилия дизайнеров, UX-писателей и переводчиков
Разработка продукта — это всегда командная работа, но когда к привычному процессу добавляется локализация, как правило, именно этот этап бывает хуже интегрирован. При использовании классических подходов к локализации, которые я описала в этой статье, команда локализации приступает к работе в момент, когда локализационные файлы-исходники уже добавлены или обновлены в Git, и хотя эти подходы являются стандартными и доказали свою эффективность, у них есть недостатки, которые в некоторых случаях могут быть критичны.
В этой статье я расскажу, какие недостатки есть у локализации на этапе разработки, как их решает локализация на этапе дизайна, а также о том, с какими вызовами можно столкнуться, применяя этот подход. Статья будет интересна продакт и проджект менеджерам, UX-дизайнерам и писателям и, конечно, всем специалистам в области локализации ИТ-продуктов.
Недостатки локализации на этапе разработки
Итак, макеты новой фичи готовы, текст интерфейса на языке-исходнике вдумчиво подготовлен UX-писателем, а также разбит на ключи и загружен в рабочую ветку. Группа переводчиков и редакторов приступила к финальному этапу перед релизом — перевела строки в CAT системе (Computer-Aided Translation) и занялась лингвистическим тестированием интерфейса. И тут выясняется, что для одной локали один из элементов дизайна не имеет смысла из-за культурных особенностей, а для другой — искажен смысл фразы из-за непонимания контекста переводчиком. Теперь нужно вносить правки в перевод и, что еще дольше, переделывать элемент дизайна таким образом, чтобы он был понятен для пользователей из всех регионов. Чтобы не откладывать релиз, нужно заранее закладывать дополнительное время на корректирование таких ошибок. Но что если разработка ведется настолько активно, что дополнительного времени нет? Интеграция локализации в рабочий процесс на этапе дизайна интерфейса может решить эту проблему.
Что такое локализация на этапе дизайна
Как следует из названия, при этом подходе локализация начинается в момент разработки дизайна интерфейса. Это значит, что лингвисты работают в тесном сотрудничестве с дизайнерами и UX-писателями, а разработчики получают переведенные строки вместе с макетами. Таким образом, мультиязычный контент готов задолго до релиза. Пошаговый процесс отображен на схеме ниже.
Преимущества локализации на этапе дизайна
Сотрудничество дизайнеров, писателей и лингвистов, которое обеспечивает этот подход, приводит к улучшению качества локализации за счет того, что команда локализации берет исходник для перевода у дизайнеров и имеет больше контекста. Кроме того, потенциальные ошибки локализации дизайна и текстового содержания интерфейса будут предупреждены, и потому не придется много времени тратить на их исправление перед релизом или сразу после него.
Вызовы локализации на этапе дизайна
При использовании локализации на этапе дизайна меняется привычный круг заинтересованных сторон. Лингвисты работают в сотрудничестве с UX-писателями, но реже взаимодействуют с дизайнерами и часто не имеют навыков работы в Figma, Sketch или других популярных инструментах для дизайна макетов интерфейса. Применение этого подхода к локализации пройдет гладко в случае, если все команды открыты к переменам, готовы к изучению новых инструментов, а горизонтальные связи между ними сильны. В противном случае есть риск встретить сопротивление нововведениям со стороны команд.
Кроме того, поскольку дизайнерские инструменты становятся в центре работы всех вовлеченных команд, требуется уделить внимание подбору дополнительных инструментов для совместной работы и автоматизации экспорта и импорта текстовых ресурсов, чтобы иметь возможность работать с ними в CAT (Computer-Aided Translation) или TMS (Translation Management System), стандартных инструментах в индустрии локализации. Некоторые из CAT и TMS предлагают интеграции, необходимые для локализации на этапе дизайна, такие как плагины для автоматической выгрузки текста из Figma или Sketch и возможность автоматической отправки уведомлений в популярные корпоративные мессенджеры о готовности перевода. Если ваш инструмент не поддерживает подобные интеграции, можно воспользоваться дополнительными плагинами для Figma или Sketch, часть из которых бесплатна.
Стоит ли практиковать локализацию на этапе дизайна в работе над вашим продуктом
Локализация на этапе дизайна довольно противоречивый подход: с одной стороны она позволяет добиться более высокого качества и сократить временные затраты на локализацию, но она также сопряжена с некоторыми вызовами и ограничениями. Чтобы определить, подходит ли этот подход именно для вашего продукта, нужно соотнести вложения в свою команду и в дополнительные инструменты с потенциальной прибылью от положительных эффектов, а также учитывать зрелость локализации в вашей компании.
Если вы никогда не приступали к локализации или подобные задачи возникали в качестве проектов и обладаете конкретными данными, говорящими о том, что продукт популярен в целевом регионе, а локализация на местный язык повысит лояльность пользователей и расширит потенциальную аудиторию, то вы сможете в краткие сроки обеспечить качественную локализацию интерфейса, применив этот подход. В случае, если у вас уже сложился определенный процесс локализации, а перевод на новый язык выполняется для того, чтобы проверить востребованность продукта на новом рынке, то, возможно, локализация на этапе дизайна не лучший выбор.
Вне зависимости от того, как вы делаете локализацию интерфейса, и подходит ли вам локализация на этапе дизайна, вы можете улучшить свои рабочие процессы, обращая внимание на те недостатки, на устранение которых нацелена локализация на этапе дизайна: ошибки дизайна, связанные с культурными особенностями и ошибки перевода, возникающие из-за недопонимания контекста. Например, можно консультироваться с переводчиками на этапе проектирования дизайна, а также знакомить команды, имеющие отношение к локализации, с особенностями работы друг друга, чтобы добиться большей осознанности о процессе в целом.
