Большинство разработчиков игр вскоре после запуска на локальном рынке начинают задумываться о том, как привлечь больше геймеров из других стран. Таким образом, рано или поздно возникает потребность в локализации.
Именно поэтому мы решили составить список правил для разработчиков. Если следовать им с самого начала разработки, вы незаметно и без лишних усилий подготовите игру к локализации.
Итак, как выбирать перспективные языки до начала работы над игрой?
В первую очередь, помните о правиле № 0: английский язык должен быть, по возможности, исходным. И еще, мы рекомендуем уже с первого дня разрабатывать игру с расчетом как минимум на два языка.
Этими двумя языками «по умолчанию» скорее всего станут английский и ваш родной язык (если это, конечно, не английский). У такого подхода есть неоспоримое преимущество: во-первых, игру можно будет переводить на другие языки уже с английского, что обеспечит согласованность и единообразие. Во-вторых, реализуя двуязычность в игре с первого дня, вы автоматически наткнетесь на все подводные камни подготовки к локализации, и переход к 20 языковым версиям не будет представлять такой большой сложности.
В процессе дизайна элементов интерфейса обычно рекомендуется предусмотреть, чтобы их размер был как минимум на 30% больше, чем это необходимо для исходного текста. Это особенно актуально для коротких строк: пунктов меню, интерфейса и т. д.
Но если вы приняли во внимание правило № 1 и уже составили обширный список языков, разрабатывайте интерфейс с учетом самого сложного для локализации языкового стандарта.
Например, тексты на немецком будут в среднем на 30% длиннее английских, на русском и арабском — примерно на 10% длиннее. А вот иероглифы традиционного китайского письма обычно занимают на 30% меньше места, чем английский текст.
Для записи одной буквы латинского алфавита требуется один байт, а для кириллических и арабских символов — два, что также необходимо учитывать для организации хранения данных.
Строки, которые невозможно извлечь из кода, не могут быть локализованы. Все локализуемые строки должны редактироваться без правки кода. Еще один важный совет: старайтесь не составлять тексты из отдельных слов или фрагментов.
Вообще, все технические задачи, выполняемые для запуска процесса локализации, относятся к интернационализации (кратко — «i18n»).
К предыдущему правилу хотелось бы добавить, что числовая информация должна всегда быть доступна для перевода — ее нельзя оставлять в коде.
Кроме того, будьте готовы менять формат чисел в интерфейсе: например, часы, отсчитывающие время в игре, скорее всего тоже придется локализовать. Здесь дело в том, что культура в западных странах, в основном, монохронная, то есть люди там представляют время в виде временной оси, а в азиатских странах — обычно в виде круга.
И это не говоря уже о том, что форматы дат и единиц измерения различаются практически во всех языках.
В случае локализации и редактирования текста использование переменных иногда кажется хорошей альтернативой жесткому кодированию. Однако если не дать переводчикам возможность использовать переменные по своему усмотрению, это может обернуться против вас.
Проблема в том, что порядок слов и фраз в разных языках может существенно различаться. Поэтому мы советуем делать переменные частью фразы, чтобы их можно было вставить в нужном контексте. Вот небольшой пример того, как правильно, а как — нет:
Неправильно: "Mommy ate " + %num + " apples."
Правильно: "Mommy ate %num apples."
Полезно будет также давать краткое описание переменных: это позволит избежать путаницы и ошибочного соотнесения (или не соотнесения) переменной с предыдущим фрагментом текста.
Если в игре есть изображения, будьте готовы локализовать и их, особенно если в них много текста, — а это означает переделку графики с нуля.
Редактирование графических ресурсов часто не лишнее, чтобы обеспечить соответствие стандартам выбранного региона в отношении цветов и символики. Однако если изображения переделываются просто чтобы вставить переведенный текст, это пустая трата времени и сил.
Если вы применяете определенные «спѐциа́льнꙑе» символы, которые не вписываются в строковый класс, обязательно будут проблемы с кодировкой. И если после локализации у целевого языка будет неправильная кодировка, на устранение символов вроде ��� может уйти много времени и сил.
Это же касается и шрифтов. В частности, в некоторых интересных шрифтах для игр нет глифов для всех языков — в результате для определенных языковых версий придется подбирать другие шрифты. Не забывайте об этом, иначе вы рискуете получить кучу символов вроде □□□ вместо текста субтитров.
Мы рекомендуем, по возможности, вместо ASCII использовать Unicode: UTF-8 — самая распространенная и оптимальная кодировка.
Итак, все изложенные выше технические нюансы учтены. Пришло время тестовой локализации. В Интернете есть множество отличных инструментов для псевдолокализации, которые могут имитировать интерфейс на иностранных языках, включая изменение длины текста, проверку кодировки и жестко закодированных строк.
По сути, вы запускаете сценарий, имитирующий целевой язык и выдающий билд, который затем проверяется в рамках обычного процесса тестирования, как исходный нелокализованный билд.
Глоссарий — это набор внутриигровых терминов и понятий, которые должны переводиться единообразно. В основном это предметы, названия состояний, статусов, артефакты и имена персонажей.
Поддержание единообразия терминов на протяжении всей игры с помощью глоссария — это очень важно. Представьте, что какой-то предмет переведен как «зелье» в одном месте и как «эликсир» в другом — и у игроков внезапно появилась непредвиденная логическая головоломка.
Не менее важно и наличие у команды локализации всего необходимого контекста. По нашему опыту, обеспечить контекст помогает налаженное общение между переводчиками, менеджерами по локализации и разработчиками игр.
Надеемся, этот небольшой список рекомендаций поможет вам в разработке игр. Желаем успеха и побольше довольных игроков!