Имеется проект, его ресурсник представляет из себя 2 секции - для русской и английской локализации.


Секция английских ресурсов является небольшим фрагментом секции русской (проверяю корректность работы).
В свойствах проекта resources->general->culture стоит Russian (0x419).
Что получается в собранном приложении: те элементы ресурсов, которые определены в английской секции, берутся оттуда. Остальные - из русской. В ОС локаль поставлена russian/russian. При изменении culture в свойствах проекта на English (United States) (0x409) (да и вообще на что угодно) - результат такой же.

Где я натупил, почему результат не соответствует очевидному ожидаемому?

А вот, из MSDN:

Ничего не написано, как FindResource учитывает язык. Скорее всего, никак. Т.е. находит первый попавшийся.
А MFC ищет все ресурсы именно с помощью FindResource.
Поэтому:
никто не делает в одном модуле разноязычных ресурсов (для поддержки локализации). Ибо сильно геморройно все делать ручками через FindResourceEx, в то время как в MFC реализован сквозной поиск по всем модулям. Но вот язык не учитывается. Видимо, по историческим причинам.
Поэтому ресурсы разделяют по разным модулям. И подгружают тот, который соответствует языку. Это один из возможных способов, есть и другие.
Тема неоднократно обсуждалась, поройся.

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

Многоязычные приложения

Earnest, вся досада в том, что не я разрабатывал приложение. Оно уже есть, хренова туча кода, где на каждом шагу используются диалоги и строчки из ресурсов через ATL обертку. И вот тут ВНЕЗАПНО оказалось очень нужно сделать поддержку в приложении английского языка. И это уже моя работа. При этом, естественно, архитектуру менять нельзя, и вообще лучшше код как можно меньше изменять.

Да, это проблема... локализацию хорошо бы закладывать в проект.
Тогда остается путь такой: 1) выделить все ресурсы в отдельную DLL 2) сделать копию и перевести 3) подгружать на старте в зависимости от языка и устанавливать как можуль ресурсов вызовом AfxSetResourceHandle. Тогда все ресурсы сначала будут искаться в этой DLL, а потом уже в остальных. При этом насчет картинок и прочих непереводимых ресурсов можно не парится и оставить где есть; только строки, диалоги, меню.

Добавлено через 3 минуты и 59 секунд
Вариация, чтобы меньше париться:
1) оставляем все как есть, но для локализованных ресурсов создаем отдельную DLL и КОПИРУЕМ туда диалоги, меню, строки
2) На старте либо загружаем нашу локализованную DLL и вызываем  AfxSetResourceHandle? либо нет - в зависимости от языка.

Earnest, проблема #2: в ресурсах лежат не только диалоги/строчки, но и много другой чертовщины, которая тоже используется часто. Так, прийдется все это тоже пихать в локализационную DLL.
Да, дизайн проекта - <очень плохой>.

А что еще, кроме диалогов\меню\строк нуждается в переводе? Впрочем, бывают локале-зависимые картинки, а также ресурсы собственных форматов. Все это соверщенно непринципиально, поскольку подход один. И выполняться может поэтапно (по одноц штуке диалога за раз), т.к. недостающий ресурс будет найден в родном модуле.
"Зато" почти ничего не надо программировать. В кавычках, т.к. работа несложная, но долгая и нудная, полное счастье для программиста   Может, сумеешь объяснить начальству (после пары первых проб), что с этой работой вполне справится чайник Вася, немного обученный? А то ведь помрешь с тоски...

ATL по части ресурсов веселая штука. Где-то ресурсы берутся из инстанса _AtlBaseModule.GetResourceInstance(), где-то юзается APIшный LoadResource( UINT ). Прекрасно.

у меня както была такая засада.. тока на VB6... открываю формочку в дизайнере - а там тока таймер и посередине ничего не значащий прогресс бар. Смотрю на работу этой же формы - гриды, куча кнопок и activex объектов на С++ писанных, дофига фильтров, куча текстовых данных с БД и системы оповещения осообщениях сыпется...и все "шевелится" в "почти реалтайме"... эта был кошмар.