Проектирование

Локализация

Обновлено: 13 янв 2025 г.

Локализация приложения позволяет охватить глобальную аудиторию за счет не только перевода текста и голосового контента, но и обновления элементов дизайна, чтобы обеспечить их восприятие в задуманном виде. Этот процесс требует времени и ресурсов, но он настоятельно рекомендуется, так как открывает возможность для новых пользователей по всему миру найти и приобрести приложение.

Планирование и проектирование приложения для локализации

Чтобы сэкономить время и ресурсы при локализации, проектируйте и разрабатывайте приложение с учетом того, что оно будет переведено и распространено среди широкой аудитории. Ниже вы найдете рекомендации по этапу планирования и разработки перед альфа-версией.

Подготовка файла строк

Локализация подразумевает работу с двуязычными файлами, поэтому файл строк играет ключевую роль в успешности и эффективности процесса. Этот файл должен содержать все строки контента приложения, которые необходимо локализовать. Во время планирования и разработки для максимальной эффективности учитывайте следующее:

Назначьте одного ответственного за планирование и реализацию процесса локализации.

Используйте единый мастер-файл для всего контента приложения.

Выносите строки во внешние файлы, чтобы они были готовы для перевода. Не задавайте текст в коде.

Убедитесь, что файл строк совместим с инструментами локализации. Популярные форматы: XLS, PO, JSON, XML, CSV.

Присваивайте уникальные идентификаторы (ID/ключи) каждой строке, даже если один и тот же исходный текст используется в разных местах приложения. Это упростит процесс перевода одного слова на несколько языков и обеспечит гибкость, если потребуется различное оформление текста.

Обеспечьте статичность ID строк, чтобы они не менялись в процессе экспорта. Инструменты локализации помечают и проверяют новые ID, что может привести к выполнению ненужной работы и дополнительным затратам на перевод.

Избегайте упоминания конкретных платформ в строках. При необходимости создавайте варианты строк для каждой отдельной платформ, и не забывайте изменять и удалять этот контент по мере необходимости.

Добавляйте комментарии разработчиков, касающиеся локализации, чтобы лингвисты могли точно перевести каждый раздел. Обеспечьте контекст: укажите цель текста или строки, поясните части речи (глагол, существительное и т. д.), укажите, кто говорит в определенной сцене, выделяйте сложные фразы или каламбуры и т. д.

Ниже показан пример XLS-файла, подготовленного для локализации.

string_ID	English	Developer Notes
mainmenu_start_button	START	UI button to start the game
mainmenu_credits_button	CREDITS	Main menu to view credits for the game
scene_1_cutscene_char1_1	Hey, wake up!	Dialogue, Max Character Limit: 15
scene_2_objective_name_record	Record	VERB. Name of objective: Record the conversation using a voice recorder

Создание пользовательского интерфейса, готового к локализации

Разработка гибкого и легко масштабируемого пользовательского интерфейса значительно сэкономит время при локализации. В сравнении с английским языком предложения и слова во многих других языках могут быть визуально длиннее в 2–3 раза. Кроме того, некоторые языки требуют более высоких макетов, для отображения дополнительных диакритических знаков и сложных символов. Вот ключевые рекомендации по созданию пользовательского интерфейса, готового к локализации:

Включите адаптивные макеты для учета изменений, связанных с типами символов в различных языках. Сюда относится автоматическое изменение размеров текстовых полей, кнопок и текста.

Для решения проблем с переносом слов поддерживайте горизонтально прокручиваемые элементы, например бегущие строки.

Интегрируйте теги форматирования текста для разрыва строк и запрета переноса (например, <br>, <nbsp>) в файлы перевода. Это упростит процесс локализации для переноса строк, особенно в языках с минимальными интервалами между словами.

Для более эффективного планирования процесса локализации документируйте все визуальные элементы, содержащие текст, встроенный в макет.

Если в макете предусмотрено место только для ограниченного количества символов, обязательно укажите максимальное количество символов для этой секции в примечаниях от разработчика.

Перед началом процесса локализации проведите полную проверку строк. Удалите устаревшие строки, которые не нуждаются в переводе, исправьте ошибки в орфографии, грамматике и пунктуации, чтобы оптимизировать процесс локализации.

Избегайте использования флагов стран для обозначения языков, так как один язык может использоваться в нескольких регионах по всему миру.

Управление поддержкой языков в приложении

Приложение Quest поддерживает 25 языков⁠, но вы можете выбирать. Язык в приложении должен определяться на основании языка устройства пользователя, если совпадают локали. Определите объект локали в среде выполнения с использованием SDK платформы Meta Quest или стандартных методов Android, а затем используйте его для определения локализованной версии приложения, которая будет отправляться конкретному пользователю. Подробнее об определении локали пользователя см. в статье Определение локали пользователя.

Обратите внимание: настоятельно рекомендуется, чтобы в приложении был переключатель языка и пользователи могли выбрать нужный язык. Если поддержка языка устройства пользователя не планируется, приложение должно по умолчанию загружаться на английском языке. Другие требования см. в руководстве по проверке виртуальной реальности (VRC) для Quest.

При управлении файлами локализации стоит также рассмотреть возможность использования языковых пакетов. Это может сократить размер установки приложения.

Шрифты для поддержки разных языков

По умолчанию многие игровые движки и платформы некорректно отображают нелатинские символы, заменяя их квадратиками (так называемыми "тофу"). Чтобы обеспечить корректное отображение нелатинских языков, необходимо использовать поддерживающие их шрифты.

Текст на корейском языке, отображаемый с использованием шрифта Liberation Sans по умолчанию в Unity. Он представляется квадратными блоками, так как в этом шрифте отсутствуют корейские глифы.

Корректное отображение корейского текста возможно при использовании шрифта Noto Sans, который поддерживает корейские глифы.

Чтобы локализованный контент соответствовал установленному стилю приложения, выберите и используйте шрифты, которые гармонируют с оригинальным дизайном. Существуют как бесплатные, так и лицензируемые шрифты для коммерческого использования.

Unity: импортируйте файл шрифта в Unity, а затем создайте объект Text Mesh Pro. По умолчанию для режима Atlas Population Mode (Режим заполнения атласа) задано значение Dynamic (Динамический). Это позволяет не беспокоиться о большом размере текстур, так как текстуры для каждого глифа будут создаваться во время выполнения. Например, если использовать статические текстуры для азиатских языков с иероглифами и сложными вариациями, такими как китайский и японский, размер текстуры может превышать сотни мегабайт. Однако с динамической текстурой размер можно уменьшить до 10 КБ.

Если используется статическая текстура, для многобайтовых языков с тысячами символов невозможно добавить каждый возможный символ в изображение. Поэтому наиболее распространенная практика — сканирование текста для создания библиотеки символов, содержащихся в файле строк, и генерация изображения, содержащего только эти символы.

Unreal и другие сторонние движки: в большинстве игровых движков метод отображения текста полностью настраивается. Постарайтесь действовать гибко и предлагать поддержку нескольких шрифтов.

Для проверки нового шрифта разверните сборку с блоком случайного переведенного текста. Обратите внимание: многие шрифты несовместимы с азиатскими или кириллическими языками, поэтому обязательно тестируйте приложение на этих языках, если они распространены в целевых странах и регионах. Помните, что неподдерживаемые глифы (символы) не будут отображаться при развертывании тестовой сборки или могут отображаться в виде квадратов.

Процесс локализации

Чтобы обеспечить плавный и эффективный процесс локализации, следуйте этим рекомендациям и учитывайте важные моменты на каждом этапе локализации приложения.

Добавьте локализацию в процесс выпуска приложения и планируйте заранее. В зависимости от объема текста, сложности тестирования и исправления ошибок локализация может занять недели и месяцы. Если контент будет зафиксирован до начала работы, команда локализации сможет точно оценить сроки и затраты, а также обеспечить относительно простой и беспроблемный ход процесса. Это справедливо как для случаев, когда приложение сначала выходит на английском языке с последующим добавлением локализованных версий, так и для сценариев одновременного выпуска на нескольких языках (так называемое sim-ship).

Основные этапы процесса локализации:

Фиксация файла строк.

Перевод контента приложения и магазина.

Проверка и тестирование переведенного контента.

Исправление ошибок и проблем с локализацией.

Отправка на утверждение для размещения в магазине.

Контроль версий и управление изменениями

Хотя обновления приложения, исправления ошибок и другие изменения неизбежны, перед началом локализации важно зафиксировать контент (т. е. заблокировать строки) и избегать изменений в них до завершения локализации. Если во время локализации необходимы изменения в дизайне или сборке, используйте на контроль версий, так как управление коммуникацией и процессом сборки становится особенно сложным, если в процесс локализации добавляется множество обновлений.

Перевод контента приложения: важность фиксации строк

Чтобы начать процесс локализации, соберите все строки для перевода в одном файле строк. При передаче этого файла команде переводчиков (внутренней или внешней) убедитесь, что он будет зафиксирован до завершения первого этапа локализации. Если строки будут изменяться после начала локализации, потребуется отправить переводчикам обновленный файл строк и запросить внесение изменений, что приведет к дополнительной работе и затратам. Это также может создать путаницу на этапе тестирования, если не уведомить команду QA о внесенных изменениях или если она будет тестировать устаревшую сборку. В конечном итоге, настоятельно рекомендуется строго фиксировать строк.

Перевод и загрузка контента для Магазина Meta Horizon

Панель разработчика Meta Horizon поддерживает импорт и экспорт файлов в формате TSV, что упрощает массовую локализацию. Заполните метаданные магазина на английском языке и нажмите Bulk Localization (Массовая локализация). Вы получите список рекомендуемых действий по локализации контента магазина. Затем экспортируйте файл TSV, нажав "Скачать TSV" во всплывающем окне, и отправьте его команде переводчиков.

Bulk localization overlay within Developer Dashboard

Обязательные метаданные для Магазина Meta Horizon:

название приложения — не более 40 символов;

краткое описание приложения — не более 500 символов;

полное описание приложения — не более 1 000 символов;

ключевые слова для поиска: не более 50 —символов на ключевое слово, до 5 ключевых слов (необязательно, но рекомендуется); пробелы внутри ключевых слов не допускаются;

для поиска эффективных ключевых слов обратитесь к рекомендациям в статьях Выбор названий и объектов для приложений и Отправка приложения на проверку в магазин.

Локализация названий приложений и почему она рекомендуется

Локализация названия помогает сделать приложение более близким и понятным для пользователей из разных стран. В то время как люди в западных странах чаще владеют английским языком на достаточно высоком уровне, пользователи из восточных стран могут не воспринимать должным образом смысл определенных названий или даже испытывать трудности с их прочтением. Локализованное название приложения может привлечь более широкую аудиторию.

Стоит отметить, что большинство киностудий переводят или транслитерируют названия своих фильмов. Транслитерация означает преобразование букв одного алфавита в похожие по звучанию буквы другого алфавита. Например, слово חנוכה в иврите может быть транслитерировано в "ханука" на русском. Для приложений, изначально разработанных на английском, при локализации на восточные языки чаще используется транслитерированное название приложения, тогда как оригинальное английское название обычно рекомендуется для западных языков из-за более высокого уровня владения этим языком. Прежде чем принять решение о маркетинге нового интеллектуального продукта (IP) в регионах проконсультируйтесь с командой локализации. Для нелокализованных названий в азиатских языках добавьте транслитерированное название в качестве ключевого слова для поиска в App Manager, чтобы оно появлялось в результатах поиска.

Проверка и тестирование локализованного контента

Для обеспечения наиболее точного перевода команды переводчиков полагаются на английский исходный текст и примечания разработчиков, однако это имеет свои ограничения, поскольку лингвисты, как правило, не имеют возможности увидеть приложение в действии (дизайн интерфейса, контекст повествования и т. д.). Им может быть трудно понять связь между строками в файле, и в процессе могут возникать ошибки, такие как некорректное отображение перевода, отсутствие поддержки специальных символов или наложение переведенного текста на элементы интерфейса. Именно здесь необходим контроль качества, специально направленный на локализацию. Этот процесс, часто называемый LQA (Localization Quality Assurance), традиционно подразумевает участие профессиональных двуязычных тестировщиков для проверки локализованной сборки, что позволяет повысить качество и устранить специфические проблемы локализации с большей эффективностью.

Распространенные в пользовательском интерфейсе, обнаруживаемые при тестировании LQA:

Для подготовки к тестированию LQA необходимо предоставить команде файл с переведенными строками и все другие материалы, которые были переданы команде перевода. Разверните новую сборку с последними реализованными переводами и добавьте команду LQA в канал сборки. Убедитесь, что в плане тестирования LQA указаны наиболее эффективные пути проверки элементов приложения, связанных с локализацией. Например, проинструктируйте тестировщиков пропустить области, которые не затрагиваются локализацией, и проверить все области, где были внесены изменения, связанные с переводом. Также предоставьте инструмент отладки, чтобы они могли пропускать разделы приложения, не имеющие изменений в дизайне или переводимого текста.

Чтобы завершить этап LQA, разверните новую сборку с исправленными ошибками локализации и попросите команду LQA проверить внесенные изменения. Повторяйте этот процесс до тех пор, пока команда LQA не подтвердит общее качество новой локализованной сборки и отсутствие серьезных проблем. После этого приложение можно будет подготовить к отправке на утверждение в магазин.

Отправка локализованного приложения на утверждение в магазин

Для отправки локализованной сборки на рассмотрение в магазин выполните следующие действия:

Предоставьте все необходимые материалы магазина в соответствии с рекомендациями по проверке приложений.

Введите локализованные метаданные магазина: название и описания приложения, ключевые слова для поиска. Чтобы выполнить обновление быстро и удобно, импортируйте переведенный файл TSV, выбрав "Массовая локализация" на панели разработчика.

В разделе "Характеристики" в App Manager добавьте новые поддерживаемые языки в нижней части страницы.

Supported languages section of Developer Dashboard

Обновите и сохраните все другие данные и материалы, которые должны войти в новую локализованную версию.

Отправьте приложение, выбрав "Сохранить и продолжить".

Совет по запуску локализованного приложения: объедините обновление локализации приложения с крупным обновлением контента, чтобы повысить шансы на размещение приложения в подборке магазина.

Дальнейшие действия

Когда приложение будет одобрено и выпущено для широкой аудитории, следите за аналитикой на панели разработчика. Используйте эти данные для принятия решений о будущих обновлениях, которые могут улучшить отзывы пользователей и повысить общую популярность приложения.

Для каждого обновления контента повторяйте процесс локализации. Планируйте так, чтобы локализованный контент выходил в тот же день, что и версия приложения на английском языке, чтобы упростить процесс коммуникации и обмена сообщениями.

Подробнее о том, как оптимизировать приложение с помощью встроенной аналитики и улучшить его обнаружение, см. в статье Введение в аналитику приложений.