Hi everyone:
I was wondering, if I call CString::LoadString() method to load a string from resources how do I know which language did that method use?
Printable View
Hi everyone:
I was wondering, if I call CString::LoadString() method to load a string from resources how do I know which language did that method use?
Have you looked through the MFC sources to find out?
I don't understand the question.
Hi,
There's no obvious way to do it. You can specify the language you want to be used as the 3rd parameter. However, there's no way to check that MFC was actually able to find the string in that language in your resource DLL.
Alan
CString::LoadString does not have any "3rd parameter". It has one and only one:Quote:
Originally Posted by alanjhd08
If the module (exe or dll) contains resources in more than one language then the only way to obtain the ones for the specific language rather than the default one is using resource APIs with Ex suffix:Quote:
BOOL LoadString( UINT nID );
FindResourceEx -> LoadResource -> LockResource
See How To Use LoadResource to Load Strings from a String Table
Yes. What happens on the inside is that the resource string is id'ed with a call to this Win32 API:Quote:
Originally Posted by Arjay
But that doesn't help me much.Code:::FindResource( hInstance, MAKEINTRESOURCE( ((id>>4)+1) ), RT_STRING );
I agree, that seems to be the case.Quote:
Originally Posted by alanjhd08
That is exactly the reason why I needed to know which version of a string resource was loaded. The reason being, in my application strings were processed a bit differently depending on the language.Quote:
Originally Posted by alanjhd08
That is not true. Or at least in the last versions of MFC. There's also this method:Quote:
Originally Posted by VictorN
But I would prefer not to use it and let the language be determined automatically. My reasoning behind it is that this whole language question is quite a complex subject that I may not completely understand at this stage (especially with custom locales in Vista, etc.) thus I'd prefer to let a Windows API handle the language selection.Quote:
Originally Posted by msdn
But, fellas, I was able to find an easy workaround. By adding a simple language ID string into the resource (that is always in your predefined language, English, in my case) I can easily tell which language was actually loaded.
Code:IDS_STRING_COUNTRY_ID "en_us"
Well, I cannot say I understand the solution.
Quote:
Originally Posted by ahmd
I cannot it either... :sick:Quote:
Originally Posted by Igor Vartanov
OK, say you have three string resources for English, French and German. You add the following string into each:Quote:
Originally Posted by Igor Vartanov
//For US resource
IDS_STRING_COUNTRY_ID "en_us"
//For French resource
IDS_STRING_COUNTRY_ID "fr_french"
//German resource
IDS_STRING_COUNTRY_ID "ge_german"
And then when the resource is loaded you check that ID to get the language of the resource loaded.
Could you demo the corresponding fragment from .rc file?
:) Igor, you're killing me.... Take a look at the resource file snippet:Quote:
Originally Posted by Igor Vartanov
Code://///////////////////////////////////////////////////////////////////////////
//
// String Table
//
STRINGTABLE
BEGIN
IDS_STRING_COUNTRY_ID "en_us"
IDS_STRING_HELLO_WORLD "Hello World!"
IDS_STRING_GOODBYE_WORLD "Goodbye World!"
END
/////////////////////////////////////////////////////////////////////////////
// French (France) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_FRA)
#ifdef _WIN32
LANGUAGE LANG_FRENCH, SUBLANG_FRENCH
#pragma code_page(1252)
#endif //_WIN32
/////////////////////////////////////////////////////////////////////////////
//
// String Table
//
STRINGTABLE
BEGIN
IDS_STRING_COUNTRY_ID "fr_france"
IDS_STRING_HELLO_WORLD "Bonjour tout le monde!"
IDS_STRING_GOODBYE_WORLD "Adieu le monde!"
END
#endif // French (France) resources
/////////////////////////////////////////////////////////////////////////////
// German (Germany) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_DEU)
#ifdef _WIN32
LANGUAGE LANG_GERMAN, SUBLANG_GERMAN
#pragma code_page(1252)
#endif //_WIN32
/////////////////////////////////////////////////////////////////////////////
//
// String Table
//
STRINGTABLE
BEGIN
IDS_STRING_COUNTRY_ID "ge_german"
IDS_STRING_HELLO_WORLD "Hallo Welt!"
IDS_STRING_GOODBYE_WORLD "Goodbye Welt!"
END
#endif // German (Germany) resources
Thank you. :) You might be surprised, but I never did multilanguage support this way. It's always was a per-language resource dll.
The same applies to a resource DLL, doesn't it?
What is "the same" in this context? :confused:Quote:
Originally Posted by ahmd
My approach.Quote:
Originally Posted by VictorN
How do you normally load your resource DLL, is it something explicit or you let an API decide which DLL to pick?
Only the end user chooses which language version of the resource dll he/she will use. Period.
Oh, so you don't detect it at the app's start-up and present the language appropriate for a user locale? I've seen it done a million times...
No! Never!
I never trust "a user locale".
User select the UI language either from the options combobox or/and pass the preferable language id (usually the abbreviation like "ENU"," DEU", "ESP" ,...) as a command line option.
Just curious, why so?Quote:
Originally Posted by VictorN
Because some German users prefer using German UI for my applications also in English-US Windows
So let me get it right -- your software defaults to English, and then someone can change it manually to German, right?Quote:
Originally Posted by VictorN
If so, what if some of your German users don't speak a word in English and you load the UI in it?
Then they shouldn't have chosen "English" as the language to use on installation, or they shouldn't have downloaded (or ordered) the "English version" of the installer program.Quote:
Originally Posted by ahmd
Look how many authors accomplish this -- they have different installation versions for the various languages, and in the installation, the user has the option of choosing the installation language or another language as the default language for the app. After that, it is a user error if the language of the application doesn't show up in something they understand.
IMO, trying to be too smart in what language the user may be using is a losing game. What would you do if the person is running the program in Switzerland? There are 3 official languages there -- which one do you choose to give to the user? This is where you let the user decide, and that is usually done on installation and/or menu choice, INI or registry setting, etc.
Regards,
Paul McKenzie
The primary language choice has an Admin who installs that software.Quote:
Originally Posted by ahmd
But there is no problem to edit the app shortcuts later to change the language if someone would like to use another one...