Как подготовиться к локализации: 10 основных правил

Сначала делаем, а думаем потом — или наоборот? Alconost рассказывает, какие особенности локализации стоит учесть на этапе разработки игры.

Эту статью мы написали как ответ на повторяющиееся вопросы разработчиков: «Что с моей игрой не так? Почему перевода недостаточно? Как это исправить?»

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

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

Для начала разберемся с терминологией. Локализовать игру — значит адаптировать её к выбранной локали (языковому стандарту, стране или региону), переведя интерфейс на целевой язык и сделав поправки на культурные, религиозные и политические факторы.

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

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

Ещё один пример локализации — это перевод текста с числами. В некоторых языковых стандартах, таких как en-US (американский английский) числа иногда нужно записывать словами, а не цифрами. В других языках числам должны соответствовать определенные формы единственного и множественного числа существительных. Например, в русском намного больше вариантов, чем one и more than one, которыми прекрасно обходится английский язык. А в японском и китайском вообще нет форм для множественного числа. Ну, а если числа и тексты в игре зафиксированы в виде статических изображений, просто перевести текст будет недостаточно.

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

Чтобы предвидеть такие ошибки, мы в компании Alconost решили составить список правил. Если следовать им с самого начала разработки, то вы незаметно и без лишних усилий подготовите игру к локализации.

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

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

Возникает вопрос: как лучше выбирать перспективные языки до начала работы над игрой?

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

И ещё, мы рекомендуем уже с первого дня разрабатывать игру с прицелом, как минимум, на два языка.Эти два языка «по умолчанию» скорее всего — английский и русский. При таком раскладе у вас будет несколько преимуществ. Во-первых, игру можно переводить на другие языки уже с английского, согласованно и единообразно. Во-вторых, реализуя двуязычность в игре с первого дня, вы автоматически наткнетесь на подводные камни подготовки к локализации. И переход к 20-и языковым версиям не будет таким сложным.

Мы обычно советуем создавать элементы интерфейса «с небольшим запасом», чтобы их размер был как минимум на 30% больше, чем это нужно для исходного текста. Это особенно актуально для коротких строк, таких, как пункты меню.

Но у нас есть ещё одна идея, получше. Если вы начали с правила № 1 и уже составили список языков, разрабатывайте интерфейс под самый сложный (самый объёмный для локализации) языковой стандарт.

Для понимания, тексты на немецком будут в среднем на 30% длиннее английских, на русском и арабском — примерно на 10% длиннее. А вот иероглифы традиционного китайского письма занимают на 30% меньше места, чем английский текст.

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

Ещё один важный совет: старайтесь не составлять тексты из отдельных слов или фрагментов. Наглядным примером такой ошибки поделился на платформе StackExchange разработчик из Google:

String currency = Locale::getCurrencyString() + money.toString(); // дает «$123»

В этом примере мы получаем строку вида «$123», хотя в некоторых других языках знак валюты должен стоять после числа.

Поэтому лучше использовать форматирующие строки, которые могут быть локализованы. Например:

String format = Locale::get("currency format"); // возвращает «${0}» в английском

String currency = String::Format(format, money.toString());

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

К предыдущему правилу нужно добавить, что числовая информация должна тоже быть доступна для перевода — её нельзя оставлять в коде.

Будьте готовы менять формат чисел в интерфейсе: например, часы, отсчитывающие время в игре, скорее всего тоже придется локализовать. Здесь дело в том, что культура в западных странах, в основном, монохронная, то есть люди там представляют время в виде временной оси, а в азиатских странах — в виде круга.

И это не говоря уже о том, что форматы дат и единиц измерения различаются в разных языках.

Поэтому перед локализацией мы рекомендуем подготовиться и учесть эти нюансы.

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

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

Неправильно: "Mommy ate " + %num + " apples."
Правильно: "Mommy ate %num apples."

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

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

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

Если вы применяете «спѐциа́льнꙑе» символы, которые не вписываются в строковый класс, будут проблемы с кодировкой. И если после локализации у целевого продукта будет неправильная кодировка, на устранение символов вроде ��� уйдёт много времени и сил.

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

Мы рекомендуем вместо ASCII использовать Unicode: UTF-8 — самая распространенная и оптимальная кодировка.

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

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

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

Такой предварительный тест — не панацея, но он помогает. А ещё, тестировать новый интерфейс с «абракадаброй» вместо текста бывает очень даже весело.

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

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

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

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

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

Надеемся, вам помогли наши советы. Желаем удачи и побольше довольных игроков! Ну, а если понадобится помощь в локализации или совет, пишите нам в Alconost.