А теперь расскажу как человек, который давно и плотно интересуется локализацией, но в глаза Unity не видел.
Локализация ДОЛЖНА храниться в простенькой базе «ключ-значение», это может быть INI, CSV, XML или что-то ещё. А то часто бывают половинчатые решения, когда общие строки локализуются, а прописанные где-то в скриптах — через зад (StarCraft первый). Или одна и та же строка служит и ключом чего-то, и выводимой локализованной строкой (Atreides/Ordos/Harkonnen в Dune II).
Существуют два основных подхода к локализации.
1. Есть так называемый «основной» язык, прописанный ПРЯМО в EXE-файле, ПРЯМО в скриптах игры и так далее. Локализация имеет вид
«Open»,cmd → «Открыть»
«The door is locked.»,level1 → «Дверь закрыта.»
Как вы видите, ключ состоит из двух частей: строки-оригинала и уточнения. Если ключ совпадает, а уточнение — нет, берём строку без уточнения, а если и таковой нет — то что угодно. А если и ключ не совпадает — берём непереведённую.
Адепты этого подхода — Gettext и Qt.
2. Даже первый язык наравне с остальными.
Cmd.Open → «Открыть»
Level1.Locked → «Дверь закрыта.»
Вариант 2.1: первый язык (обычно английский) используется как резервный, если локализации не нашлось.
Сам я в пользу второго подхода, но он сложнее.
САМАЯ простая база ключ-значение, чаще всего использовавшаяся на Java ME, где с памятью швах,— это простой линейный массив.
[0] Открыть
[1] Дверь закрыта.
Всё преобразование из человекочитаемых идентификаторов S_CMD_OPEN в номера происходит на машине разработчика, генерацией файла
constexpr unsigned S_CMD_OPEN = 0;
Какой из методов брать?
1. Насколько много локализации?
2. Есть ли скрипты, GUI-формы и прочие ресурсы, способные содержать строки локализации?
3. Насколько много больших текстов?
4. Если программа параллельно разрабатывается и переводится: насколько тексты стабильны? Первый подход совершенно не выдерживает ситуации, когда исходные тексты меняются.
5. Возможны ли неофициальные локализации? Метод 2 без уточнения 2.1, если программа «живая», исключает их.
6. Что поддерживается вашим движком из коробки?
7. Локализация встроена изначально, или приходится переводить неготовую к этому прогу?
8. Насколько много интерфейса? У интерфейса есть противная фишка: нужно расщеплять строки, то есть давать одинаковым строкам разный ID (Open=«Открыть», «Открыто» и т.д.), и первый поход по умолчанию объединяет, второй по умолчанию расщепляет.
И ма-ахонький апдейт. Есть ещё такое понятие, как сегмент — кусок МЕНЬШЕ локализуемого текста. То есть сегменты есть только на уровне комплекта локализации, в экспортированных текстах они склеиваются в единый текст. Обычно предложение или абзац. Сегментация используется в переводе больших текстов, особенно в интерфейсах, с такими целями.
• Существуют тексты-«козы», которые могут найтись в памяти переводов. Например: «Серп и молот символизирует крестьян и рабочих. Осторожно, в вашем законодательстве эта символика может быть запрещена.»
• Из-за недостатков интерфейса проги перевода можно пропустить целое предложение. Да, бывает!
• В «живых» программах — можно помечать плохо переведённым кусок меньший, чем целый текст.
(Живой я называю программу, которая параллельно разрабатывается и переводится. Благо методика «аджайл» предполагает частые небольшие выпуски.)