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

В этой статье я расскажу о сложностях локализации в Unreal Engine, опираясь на свой опыт работы над Wizard of Legend 2. Мы разберём сбор и управление текстом, а также проблемы с форматированием, гендерно‑зависимым языком и обработкой шрифтов. Также я расскажу о ключевых аспектах, которые могут вызвать задержки, и о том, как их минимизировать.

Сбор текста

Процесс сбора текста в Unreal довольно прост:

1. Открываете панель локализации (Localization Dashboard).

2. Нажимаете кнопку «Gather Text».

3. Готово!

Однако в реальности вам придётся столкнуться с двумя главными проблемами, которые могут отнять много времени.

1. Ненужные тексты

Unreal собирает много ненужного текста. В нашем случае около 80% собранных строк не относились к контенту игры, а предназначались для локализации самого движка. И это происходило несмотря на установленные фильтры.

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

2. Неправильные типы данных

Другая распространённая ошибка — использование неподходящих типов данных.

В Unreal локализуемый текст должен быть типа FText. Однако разработчики иногда используют FString, а ещё хуже — изначально используют FText, но потом изменяют его через FString. Это легко, потому что между этими типами простая конвертация.

Решение:
Лучше сразу обучить команду основным принципам локализации в Unreal и назначить ответственного за процесс локализации. Регулярно запускайте команду «Gather Text» и проверяйте фильтры, чтобы избежать потери важных строк.

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

Проблемы с FText и FString

Если вы посмотрели упомянутые выше туториалы, то знаете, что конвертация FString в FText (и наоборот) — это плохая идея. Однако это так просто сделать, что я напомню об этом ещё раз!

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

Обратите внимание на Blueprint:

• Unreal автоматически конвертирует FString в FText и обратно, если вы меняете тип переменной в редакторе.

• Это можно легко упустить из виду, но нужно исправлять сразу, как только обнаружите.

Иногда преобразование FString в FText оправдано (например, для отладочного текста), но в большинстве случаев это сигнал тревоги.

Языки — это хаос!

Мы добавили выбор пола персонажа на позднем этапе разработки. Выглядело как простая задача с геймплейной точки зрения:

1. Создать женскую модель персонажа.

2. Добавить интерфейс для выбора пола волшебника.

3. Всё готово, да?

Нет!

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

Как это можно было решить заранее?

• Unreal имеет встроенный синтаксис для поддержки полов: {var}|gender(masculine, feminine, neuter).

• Можно передавать ETextGender в FormatText, и это работает отлично.

• Но мы этим не воспользовались.

Мы разрабатывали игру на английском, где гендерные окончания почти не используются. Чтобы использовать встроенный механизм Unreal, нам нужно было бы заранее определить переменную {var} для пола персонажа во всех строках.

Внедрение этого механизма на позднем этапе — огромная работа!

Наше решение

Мы разработали свой механизм, позволяющий не изменять оригинальный английский текст. Он работает аналогично конструкции Unreal {masculine|feminine}.

Этот механизм гибкий:

• Если бы нам нужно было добавить поддержку трёх полов, мы могли бы использовать [header: masculine|feminine|neuter].

• Это позволило бы разделить род говорящего и цель высказывания.

Другие проблемы локализации

1. Единственное и множественное число
Используйте конструкцию {number}|plural(one=, few=, many=, other=).

2. Форматы чисел и символов

• В турецком языке знак процента (%) ставится перед числом (%5 вместо 5%).

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

Эти нюансы сложно заметить, поэтому заложите время на тестирование локализации.

Шрифты

Работа со шрифтами для разных языков может стать настоящей головной болью.

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

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

Более удачное решение — использование механизма обработчика шрифтов Unreal, который позволяет выбирать определённый шрифт в зависимости от текущего языка. Этот метод работает, но не идеально. Например, в меню настроек может потребоваться отобразить название языка и на текущем языке, и в его оригинальном написании, например, «Farsi (فارسی)». Если шрифт выбирается только на основе текущей локали, то либо во всех шрифтах нужно поддерживать персидские символы, либо вместо них будут отображаться вопросительные знаки.

Самое удачное решение, которое я нашёл, — использование диапазонов Unicode и привязка каждого шрифта к определённому диапазону символов. В нашем случае основной шрифт охватывал все европейские языки, но китайский и японский оказались сложнее. Диапазоны Unicode для иероглифов Канси пересекаются, а упрощённый китайский, традиционный китайский и японский используют один и тот же набор символов, поэтому использовать для каждого языка отдельный шрифт было невозможно. Мы пробовали разные шрифты, обещающие поддержку и китайского, и японского, но при тестировании обнаружились пропущенные символы. Некоторые шрифты технически работали корректно, но китайские пользователи жаловались, что они выглядят нечитабельно. В конце концов, переводчики помогли решить эту проблему и предоставили ссылку на стандартные китайские шрифты: https://github.com/wordshub/free‑font.

Процесс перевода

Работа с командой переводчиков — это сложная управленческая и программная задача.

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

Прежде всего, узнайте, какое ПО использует команда переводчиков. Убедитесь, что во всём процессе кодировка текста остается неизменной, иначе можно столкнуться с проблемами вроде отображения чисел вместо переносов строк или повреждения ранее переведённых текстов. Хороший принцип — самостоятельно управлять процессом конвертации. Например, если переводчики работают в Excel, лучше отдавать им Excel‑файлы, а не CSV (особенно учитывая, что Microsoft Excel не запрашивает кодировку при импорте CSV). В зависимости от вашего рабочего процесса может потребоваться написать конвертеры или даже создать собственный формат (например, для контроля версий или тегирования).

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

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

Можно начать с использования команд из панели локализации Unreal (Localization Dashboard). Эти команды легко запускать через Python‑скрипты без необходимости открывать движок. В конце документа я привёл простой пример.

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

Ещё один вариант — автоматический перевод с помощью ИИ, после чего внутренняя команда QA сможет протестировать игру и выявить непереведённые строки перед отправкой их на окончательный перевод.

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

Особенности локализации для игровых платформ

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

Например, нельзя просто использовать слово «Controller» для всех платформ. Этот термин звучит на каждой платформе по‑разному, поэтому в игре он должен соответствовать официальной терминологии.

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

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

Заключение

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

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

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

• 3 июля в 20:00 — Ваш первый уровень с квестом на Unreal Engine!
  Добавите свой первый объект для создания квеста, настроите взаимодействие с объектом-квестом, добавите реакции уровня на завершение квеста.

• 15 июля в 20:00 — ИИ для игр: как оживить противника в Unreal Engine
  Создадите NPC с поведением, настроите систему обнаружения и добавите реакцию ИИ на завершение вашего квеста.

Создать собственную игру за пять месяцев с нуля можно на онлайн-курсе "Unreal Engine Game Developer. Basic"