дорый день.
Кто знает или делал когда-нибудь приложение с возможностью выбора языка? (как в TotalComander) например? Что для этого нужно, кроме того, что в проекте поставить широкобайтовые символы? Вопрос то в том, как поменять надписи, меню  и.т.д. Да и вообще кто знает как в двух байтах располагаются языки, поясняю свой вопрос: например кииллица начинается с 25000, а украинская раскладка там же с 30000? или как?
Вообщем, всех кто располагает какой-либо информацией, прошу поделится, ПОЖАЛЙСТА   

Способ, который предлагает Мелкософт, такой: продублировать все зависящие от языка ресурсы. 
Можно все это держать вместе, можно для каждого языка делать отдельную DLL с ресурсами.
При этом, приложение вовсе не должно быть UNICODE (даже если ты собираешься переводить его на японский-китайский), поскольку ресурсы и так всегда хранятся в UNICODE.
В API существуют функции выбора ресурса для конкретного языка.
Если не ошибаюсь, даже MFC это как-то внутри себя поддерживает - нужно только установить LANGUAGEID для процесса. Ищи в MSDN слова MultiLanguage и Localization.

Но остается открытым вопрос: а что делать при обновлении приложения? Т.е. выпускаем версию 1.1, в которой из 100 (допустим) диалогов поменялось 50. И что? Остается только ручками все приводить в соответствие. 
В свое время эта проблема меня сильно озаботила, и мы в итоге пришли к другому решению. Вкратце, вся ресурсы в программе - английские. Локальные ресурсы хранятся отдельно, в виде словарей специального формата, и загружаются на старте. Все обращения к ресурсам в программе проходят через специальные фильтры, которые выполняет "перевод". Как показывает практика, таких фильтров требуется немного: загрузка строк, инициализация меню и окон. 
Недостаток такого подхода - нельзя локализовать любое готовое приложение, нужно встраивать специальные классы в ядро приложения. Среди плюсов - возможность написать специальную утилиту, которая помогает переводить ресурсы и следит за изменениями...   

если я правильно понял, то должны быть типа вот такой функции:

???

Добавлено @ 11:35 
и про утилиту не совсем понял 

Нет, так не удобно. У тебя же все приложение на одном языке в каждый момент времени?
Так что функции нужны типа:

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

Насчет утилиты. Я имела в виду, что словари надо как-то хранить, и удобнее это делать в двоичном формате. Значит, потребуется специальная программа для доступа к их содержимому (заполнять-то их как-то надо). А уж в эту программу можно добавить все, что нужно для счастья разработчика: и визивиг (чтобы видеть, например, влезают ли строки в диалог), и отслеживание изменений, и навигацию по непереведенным ресурсам, ...  

Earnest, 
мда, понять сложновато... Но поскольку ты говоришь  я делаю вывод, что и мой вариант имеет право на жизнь, но не удолен - с этим в свете цитаты тебя я полностью согласен. Идем дальше,  а дальше я понимаю, что необходимо иметь словарь - файл или несколько файлов - словарей. При выборе языка мы должны этот словарь куда-то загрузить, но куда лучше? Дело в том, что мне надо не только диалоги мультиязыковывать, но и иметь набор строковых сообщений тоже на разных языках.
Что касается примера, пока так и не понял, что делает CurrentDictonary, и откуда при возвращении ей лжи загружается LoadString(ID)?
Я уже заранее был и буду тебе очень благодарен, только вот что понял, то понял, что не понял, то не понял  . Если есть на это время - можно чуть чуть более ясно (хоть чуточку) 

CurrentDictionary - это объект класса, который хранит строки и, соответственно, ищет их.

Из ресурсов, конечно - то, что там есть - это же стандартная функция MFC-строки.

Значит, еще раз. Я исхожу из предположения, что программа именно локлизуется, т.е. имеет интерфейс на каком-то конкретном языке. Т.е. нет ситуации, когда тебе одновременно нужны строки и на русском, и на французском. 
(Если нужны, схему нужно доработать.)

Итак. Что нуждается в локализации? Строки, диалоги и меню. Все эти ресурсы изначально создаем на каком-то одном языке. ИМХО, удобнее использовать английский (хотя бы потому, что это будет нормально работать на любом Windows-компьютере). Но, конечно, могут быть и варианты.

Дальше, у нас есть некий класс-словарь, который как-то умеет найти то, что нам нужно. Данные в этот словарь мы загружаем на старте приложения (когда определяемся с языком).

Рассмотрим, например, локализацию диалога. Диалог загружается из ресурсов (с английскими словами). Но перед отображением его надо "перевести". Удобнее всего это сделать в OnInitDialog (после вызова базового метода) - просто для каждого дочернего окна запросить перевод и изменить текст. 

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


 

Присоединённый файл ( Кол-во скачиваний: 10 )
 translate.rar 10,25 Kb

Earnest, спасибо, мысль уже понятна, сейчас файл скачаю, посмотрю к вечеру, сейчас бежать надо. В любом случае, тему пока закрыть не смогу, смогу когда что-то реализую.
СПАСИБО!!! ну а когда будет за что (на случай если ты про себя сказала : "да не за что"), скажу большое спасибо   

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

Второй способ, о котором говорит Earnest (с классами-словарями), так же имеет свои недостатки (Earnest о них уже упомянула).

Я для своего проекта пошел другим путем (хотя и он мне не кажется идеальным). Ресурсы в проекте - на английском. Строки, требующие локализации, (для меню, диалогов и т.д.) хранятся в ini-файле. При необходимости (например, при открытии диалога) извлекаем строки и меняем английские строки на локализованные.
Недостатки способа: 
1. Вероятно, несколько большая трудоемкость (но не сложность) данного способа.
2. Нельзя заранее посмотреть, вписываются ли переведенные элементы в отведенные для них места.

Преимущества:
1. Простота.
2. Возможность локализации после компиляции приложения.
3. Обновленная версия не требует обязательного обновления файла локализованных строк (новые элементы будут просто выводиться на английском, что не критично, хотя и не слишком приятно).
4. Возможность локализации самим пользователем-носителем языка (что может сэкономить средства для программиста-одиночки или мелкой фирмы), т.к. файл локализованных строк является обычным текстовым файлом.

Добавлено @ 07:59 
Earnest, хотелось бы узнать, что ты думаешь об этом. 

Мы тоже сначала этим путем ходили: текстовый файл, содержащий словарь. Ini или что там еще - не принципиально. Как я понимаю, ты хочешь использовать готовый механизм чтения. Главное, что заполнять это дело можно руками в любом редакторе. Что, казалось бы, может быть проще?

Но по мере работы начинаешь понимать, что этого недостаточно. 

Насчет текстового недостатков способа - согласна - и еще добавлю:

3. Никакой возможности контроля. 
Синхронизация превращается в кошмар: что-то поменяли, что-то удалили, что-то добавили...
Т.е. можно что-то написать дополнительно, но тогда мы плавно переходим к нашему способу (и использовать двоичный формат резко становится удобнее).

4. Что использовать в качестве ключа переводной строки? 
Строка на английском? - но иногда одна и та же англ. строка должна переводится по-разному в разных контекстах.
Идентификатор? - не всегда достаточно (те же  IDC_STATIC в диалогах)? 
Можно, конечно, придумать хитрый комбинированный ключ, но тогда его ручное заполнение чревато ошибками.
Да и вообще, вписывать вручную что строки, что номера - обязательно ошибешься. 

Что касается преимуществ:
1. Простота. 
Скорее, быстрота.
Как говорится, первый раз, да. Но приложение для перевода пишется один раз и может поддерживать кучу разных проектов. А когда оно есть, использовать его очень просто.
Кроме того, поддержку перевода со строны локализуемого приложения все равно писать нужно. А это хоть и не половина, но значительная часть.

2. Возможность локализации после компиляции приложения.
В нашем способе именно так и делается. Т.е. теоретически локализацию можно возложить на третьх лиц (пользователей, которые страсть как хотят иметь приложение на ридной мове).

3. Обновленная версия не требует обязательного обновления файла локализованных строк (новые элементы будут просто выводиться на английском, что не критично, хотя и не слишком приятно).
Точно так же. Само приложение ведь не обновляется, только дополнительные файлы рядом лежат.

4. Возможность локализации самим пользователем-носителем языка (что может сэкономить средства для программиста-одиночки или мелкой фирмы), т.к. файл локализованных строк является обычным текстовым файлом.

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

Как возник наш подход. В досовские времена у нас было как ты предлагаешь. Ну там понятно - немного интерфейса сочинишь. Потом, когда стали писать под виндоус, я долго мучилась, как бы скрестить уже с ежом (см. вышеупомянутые недостатки). Пока один знакомый программист не сказал: и чего ты мучаешься, сделай файл бинарным и пиши туда что хочешь. Неужели трудно написать утилиту для его заполнения? Мы начали с простого: графический интерфейс, список исполняемых модулей, форма для перевода ресурсов. Потом добавили визивиг (как диалоги-меню выглядят с переводом). Потом использование символьных идентификаторов, потом навигацию, потом контроль версий, потом... уже не помню что. Так что теперь процесс перевода выглядит следующим образом: загружаем проектный файл, в котором перечислены модули, текущие словари и еще какая-то служебная инфа, используемая для синхронизации. Программа перевода анализирует изменения, удаляет лишнее, пытается совместить измененные ид-ры и выводит список того, что не смогла сама.

Добавлено @ 16:24 
Среди недостатков нашего способа я бы отметила требования к локализуемому приложению: оно должно уметь грузить и использовать файлы словарей, созданные программой перевода. Т.е. любое приложение не локализуешь. Хотя самой программе перевода по барабану, что переводить - лишь бы ресурсы читались.
Так что если думать дальше, можно создать переводчик, который будет вписывать перевод прямо в ресурсы (или создавать DLL с локализацией, как это MFC предлагает). Сопроводительную информацию хранить в каком-нибудь служебном файле, чтобы все же поддерживать обновление версий.
И продавать это за большие деньги.   

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


Да, была у меня такая головная боль.


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

AlexPro, так делай постепенно, а способ нормальный, ты ведь не единственное приложение возможно будешь делать в жизни.
По теме, сделал диалог с кнопкой. Ресурсы на англицком. В OnInitDialog этой кнопке сделал SetWindowText(русский) - всё ок! Следоватеьно необходимо каждый диалог в OnInitDialog(да и вообще везде) корректировать по размерам кнопок. Каждую кнопку ставить в определенное место, но координаты вычислять как процент от ширины и высоты, которые вычисляются по размерам надписей - чтобы все они влезали.  Ну и при загрузке использовать технологию драгоценной Earnest, в которой я пока правда не разобрался "до руды" - но вектор задан.  
А программу - утилиту всё таки делать придется, чисто для синхронизации словарейт и без неё никуда не деться. Вот пока не понял одного, сделаю я сейчас файл с надписями на русском, texts.ru и на украинском  texts.ukr - просто наборы строк, надо ведь как-то их ID синхронизировать и с ID приложения. То есть ID_STRING_NUMBER1 есть в приложении, надо сделать так, чтобы и в файлах это была та же надпись. Может сделать так: каждой строке присваивать номер в файле и ID - имя, то есть строка бвыдет такая 10 ID_STROKAPOKANOMER_DESAT "строка за номеро десять". А дальше генерировать файл table_defines.h, в котором объявлять #define ID_STROKAPOKANOMER_DESAT 10 и так далее? да сам файл вставлять в проект. При добавлении нового словаря - никаких проблем.
PS.: пока не разбирался с примером, а пишу просто что бы AlexPro,  не чувствовал себя одиноким, мыслями опять же делюсь, пусть и глупыми  
 

Мы так не стали делать: общий дизайн диалога должен быть фиксирован, иначе будет выглядеть безобразно.
Поэтому, хотя исходные ресурсы на английском, во время разработки диалога делается прикидка с рускими строками (влезет-не влезет). А потом это контролируется при переводе: утилита-то показывает, как будет выглядеть. Иногда, конечно, не влазит, и приходится возвращаться в приложение и корректировать там. Но не часто. Конечно, этого не смогут сделать сторонние переводчики (на какой-нибудь длинный язык). Но нас это не особо волнует, потому что реальных интерфейсов 2: англ и рус. 


Вот в том коде, который я тебе дала как раз и есть формирование ключей. Насколько я помню, словарь многоуровневый: переводы разных ресурсов хранятся отдельно, строковые ресурсы индексируются просто их ID-ми, а строки диалогов - ID-ом диалога + IDC контрола или просто строкой для анонимных статиков. 

Я тоже локализировал проект почти так же как и AlexPro.
Есть словарь вида

'Число' - уникально для всего проекта...
Ну и локализация проста в коде:


Ключ переводной строки - у меня это идентификатор IDS__DIALOG__... (уникальный для всего проекта).
Как видно из кода C++, IDC_STATIC'ов у меня несколько, но я им присвоил разные идентификаторы. Об этом надо позаботится один раз при создании диалога.
Даже если на диалоге добавятся/удалятся контролы, то в обработчике OnInitDialog последовательность вызовов SetWindowText можно и не редактировать. Я во всяком случае только дописывал новый код для новых контролов в новых версиях...

Чесно говоря, метод локализации Earnest кажется мне очень сложным... 

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

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

Сложен не способ, просто требуется некоторая подготовка. 
Вот сравни:
1)

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


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

Повторюсь: Способ SeregaLBN и AlexPro - это то, с чего мы начинали. Если речь идет об одном маленьком приложении, где этих диалоги на пальцах посчитать можно, то вполне. Только я бы все же код перевода вынесла в базовый класс. И добавила простейшую утилиту, которая: 
a) сканирует ресурсы exe и выделяет все нуждающиеся в переводе ид-ры
б) генерирует заготовку для нового словаря
в) читает старый словарь и переводит все, что может; что не может - оставляет

Все же согласитесь, рутинную работу должна делать машина.