Аннотация:
Многие разработчики мечтают о всемирной популярности своих приложений, но почти никто не создает локализованных версий своих приложений, ошибочно полагая, что программа должна сначала завоевать популярность.
Особенно с LoadStringLang. Её реализация в Windows действительно очень далека от идеала.
Единственное, что с картинкой, показывающей заполненность групп по 16 строк. Надо было нолики подрисовать и в начале группы, чтобы не пугаться лишний раз, когда первый раз видишь это дело под отладчиком :)
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Для MFC версии есть проблема с диалоговым окном: DoModal не работает с CreateIndirect() :-( Работает только с InitModalIndirect(), но этот метод не локализует ресурс. Как быть?
Все дело в том, что NT-подобные системы поддерживают ф-ю SetThreadLocale, которая назначает язык текущему потоку. После ее вызова ф-ии типа LoadString, LoadMenu и т.д. вернут ресурс на языке, который является текущим для данного потока.
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
FindResource все сделает сам, в том числе возвратит ресурс с языком LANG_ENGLISH, SUBLANG_DEFAULT
или, если и его нет, просто вернет самый первый ресурс с запрошенным идентификатором.
Хотелось бы также узнать, откуда взялось столь категоричное заявлеие, что LoadString
принципиально не поддерживает работу с таблицами строк на нескольких языках.
AfxSetResourceHandle(<хендл только что подгруженной языковой DLLки>);
заменит весь текст написанный тут.
Какой вообще прикол забирать под себя LoadString и прочее...
Я не буду комментировать статью, но считаю, что можно сказать так: многие знания — многие печали.
Но мы делаем так (отметьте, что ни в одном из случаев не требуется изменения основной программы при добавлении языка):
Вариант 1.
Все проекты имеют общую ресурсную библиотеку (копать в сторону m_hInstResDLL). После чего все ресурсы переводятся. Проблема как всегда одна: ресурсы рассинхронизируются. Для нахождения несоотвествия между ресурсами я написал по-быстрому недопарсер ресурсов. За 10-15 секунд перелопачивает рассинхронизировавшиеся ресурсы и выдает список несовпадающик контролов в каждом диалоге, ну кое чего еще. Никому не дам :)
Вариант 2. Все используемы строки пишутся так: Xlate(_T("Lya-Lya")). В OnInitDialog() вызывается Xlate(this), который пробегает по всем окошкам и переводит их названия. В функцию Xlate встроена система собра статистики: поработав в этом режим с программой и пробежав по всем диалогам, вы получаете словарь, который остается только перевести. Это работает с приемлемой скоростью даже на 200 мгц стронгарме. Плюсы: никаких проблем с рассинхронизацией и поддержкой! Недостаток: качество перевода, так как иногда перевод зависит от контекста.
Только при разработке и не хватает этой всякой гадости.
Как ты будешь отлаживать диаложки, если ресурсы недоступны ? Нужно держать на каждый билд его копию — зачем это ? И столько писанины из-за чего ? На два языка это можно в маленькой аппликации. А если исходного кода больше 60МБ и ресурсов — не меньше тысячи формочек? И локализовать нужно на все возможные языки ? Тогда как ?
Материал из Википедии — свободной энциклопедии, -_*
Борьба с "неполными" ресурсами при локализациях...
После прочтения статьи имею один вопрос, который мне не дает
спокойно жить уже достаточно продолжительное время.
В описаном Вами случае поднимается проблема локализации и загрузки
различных ресурсов. В примерах кода пррисутствует код, который
загружает ресурс по-умолчанию (английский) если не нашлось локальной
копии на загружаемом языке.
Но как в этом случае отследить "неполные" ресурсы? Поясню, что я
имею в виду под термином "неполный". Это, в основном, оносится к
диалоговым ресурсам и ресурсам меню. К примеру, у Вас есть диалог
настроек, который содержить три CheckBox'а (Opt1, Opt2 и Opt3). Также
существует локальная копия этого ресурса, скажем, на русском языке
(Настр1, Настр2 и Настр3).
В один прекрасный момент Вы добавляете в английскую версию еще один
CheckBox и пишете код для работы с ним. Однако по некоторым причинам
Вы не добавляете этого самого CheckBox'а в русский диалог. При
обращении к отсутчтвующему элементу, программа даст сбой.
Как же этого избежать? Как проверить, что ресурс "неполный" и
загрузить всесто его локальной копии копию по умолчанию?
Если Вы, или кто-то из Ваших знакомых решал подобную проблему или
знаете метод решения, пожалуйста, не поленитесь, напишите ответ.
Замечание относится непосредственно к MFC. Итак, локализация в MFC делается еще проще: достаточно в редакторе ресурсов приложения выбрать ресурс, подлежащий локализации, кликнуть правой кнопкой мыши и выбрать пункт "Insert Copy". После этого Вас попросят указать язык, на котором будет эта копия. Далее остается только перевести скопированный ресурс — остальное MFC сделает сама.
При загрузке приложения MFC будет искать и загружать ресурсы в зависимости от текущей локали пользователя в следующей последовательности: сначала ищет ресурс с суб_языком = равном локали Windows. Если такового не находится, то она (MFC) пытается загрузить ресурс с языком = локали Windows... Затем английский, затем нейтральный... И если уж не нашлось никакого, то MFC берет ресурс с первым "попавшимся под руку" языком.
Смысл в том, что у программиста не болит голова о локализации... Знай себе, вовремя делай копии ресурсов...
Единственным недостатком предложенного мной метода является то, что MFC грузит ресурсы язык которых соответствует языку Windows, а не региональным настройкам панели управления. То есть, если Вы будете работать на английском Windows, то всегда будете наблюдать английский интерфейс, если локализация выполнена по описанному мной способу.
С другой стороны, это правильное решение: ведь если Вы работаете в ОС на каком-то языке, то это значит, что Вы можете, как минимум, читать на этом языке....
Самому переводить свою программу на разные языки? При добавлении нового языка выпускать новую версию? Ну не знаю... Если уж задаваться целью дать каждому возможность увидеть на экране слова на родном языке, путь IMHO изначально тупиковый. Не лучше ли дать пользователям возможность переводить интерфейс как им надо — текстовый файл с переводом всех строк, каталог с родными иконками, как это напрмер сделано в Miranda ICQ — http://miranda-icq.sourceforge.net/ ?
Только не FindResource, а FindResourceEx. И именно это функция используется в примерах к статье для поиска ресурса на нужном языке.
А в чём, по Вашему, заключается поддержка таблиц строк на нескольких языках с LoadString? Если мы не можем задать (при вызове фнкции) язык, для которого мы хотим загрузить строку, то о чём тут говорить? А если Вы хотите сказать, что LoadString способно безошибочно работать в рпиложении, в ресурсах которого есть несколько таблиц строк, то тут Вы правы.
У нас в свое время для этих целей писали специальную утилиту, которая проходила по всем ресурсам и искала отличия. Задачка не из легких. Но стоит один раз написать такую утилиту и проблема пропадает. Возможно в сети есть аналогичные утилиты.
__________________________________
Василий Черневич (aka Willi)
Интересный вопрос. Над ним надо как следует подумать.
А пока могу предложить сравнивать длину загружаемого ресурса и/или его хэш с копией по умолчанию.
А выявлять такие ошибки на стадии компиляции ресурсов было бы вообще чудесно!
Как это — не доступны? Ресурсы на всех языках, которые поддерживает программа, создаются одновременно.
Копия на каждый билд? Нет! Я предлагаю, ресурсы на всех языках класть в один бил. Тогда ресурс на нужном языке будет загружен автоматически.
А что касается больших приложений, то там для каждого языка действительно создают отдельную конфигурацию (в терминах VC++). Для поддержки такого метода разработки в VC++ есть поле Condition в свойствах ресурса, а это не что иное, как #if #else #endif в файлах ресурсов. Так что здесь тоже нет никаких проблем.
Локализация ресурсов в целом более удобна, хотя и более муторна, чем локализация отдельных строк по нескольким причинам. Во-первых, так рекомендует делать Microsoft, а во вторых небольшой пример.
Например, вы имеете кнопку с надписью "Keyword" — 7 букв. Перевод на русский язык будет выглядеть как "Ключевое слово" — 14 букв. Ровно в два раза больше. И как Вы думаете, влезет ли это словосочетание на кнопку, на которой до этого располагался английский вариант? Я думаю, что нет.
Подобных примеров можно привести массу и не только с русским языком. Практически на любом языке фпаза длиньше, чем аналогичная в английском варианте. Это справедливо и к языкам, отдельные слова на которых короче своих английских "собратьев". Зато там навалом предлогов и артиклей...
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
