В небольшой компании по производству видеоигр, Black Lantern Studios, я был ведущим разработчиком игры под названием Lionel Trains DS. Мы локализовали на английский, испанский, французский и немецкий языки. Мы знали все языки заранее, поэтому включение их во время компиляции было единственным вариантом. (Видите ли, они записаны на ПЗУ)
Я могу дать вам информацию о некоторых вещах, которые мы сделали. Наши строки были загружены в массив при запуске на основе выбора языка проигрывателя. Каждый отдельный язык вошел в отдельный файл со всеми строками в том же порядке. Строка 1 всегда была названием игры, строка 2 всегда первой опцией меню и так далее. Мы отключили массивы enum, так как индексирование integer очень быстро, а в играх скорость - это все. (Решение, связанное в одном из других ответов, использует string поисков, которых я бы старался избегать.) При отображении строк мы использовали функцию типа printf() для замены маркеров на значения. " Поезд 3 отправляется из города 1. "
Теперь о некоторых подводных камнях.
1) Между языками порядок фраз совершенно другой. « Поезд 3 отправляется из города 1. », переведенный на немецкий язык, и обратно получается « Из города 1, поезд 3 отправляется ». Если вы используете что-то вроде printf() и ваша строка « Поезд% d отправляется из города% d. », то в итоге немец скажет « Из города 3, поезд 1 отправляется.", что совершенно неправильно. Мы решили это, заставив перевод сохранить тот же порядок слов, но в итоге мы получили довольно разбитый немецкий. Если бы я сделал это снова, я бы написал функцию, которая принимает строку и массив значений, начинающийся с нуля, и помещает ее в нее. Тогда я бы использовал маркеры, такие как %0 и %1, в основном встраивая индекс массива в строку. Обновление: @Jonathan Leffler указал, что POSIX-совместимый printf() поддерживает использование маркеров типа %2$s, где часть 2$ указывает printf() заполнить этот маркер вторым дополнительным параметром. Это было бы очень удобно, если это достаточно быстро. Индивидуальное решение может быть еще быстрее, поэтому вам нужно убедиться и протестировать оба.
2) Языки сильно различаются по длине. То, что было 30 символов на английском языке, иногда доходило до 110 символов на немецком языке. Это означало, что это часто не подходило бы экранам, на которые мы его ставили. Вероятно, это меньше беспокоит игры для ПК / Mac, но если вы выполняете какую-либо работу, где текст должен помещаться в определенном поле, вам следует рассмотреть это. Чтобы решить эту проблему, мы удалили как можно больше прилагательных из нашего текста для других языков. Это сокращало предложение, но сохраняло смысл, хотя и теряло немного аромата. Позже я разработал приложение, которое мы могли бы использовать, которое содержало бы шрифт и размер поля и позволяло переводчикам вносить свои собственные изменения, чтобы текст помещался в поле. Не уверен, что они когда-либо реализовывали это. Вы можете также рассмотреть возможность прокрутки областей текста, если у вас есть эта проблема.
3) Что касается кроссплатформенности, мы написали довольно чистый C ++ для нашей системы локализации. Мы написали пользовательские двоичные файлы для загрузки и специальную программу для преобразования из CSV языкового текста в .h с enum и file to language map и .lang для каждого языка. Наиболее используемой платформой мы использовали шрифты и функцию printf(), но у вас будет что-то подходящее для любого места разработки, или вы можете написать свой собственный, если необходимо.