Multiple "StringTable" on the same EXE. (MFC App translation...)

[John Smith]

I am finding that If I set my PC to French
Get LocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_ILANGUAGE, .. Returns
Australian
Get LocaleInfo(LOCALE_USER_DEFAULT, LOCALE_ILANGUAGE, .. Returns USA

GetUserDefaultLCID() returns French

*Without any USA bitmaps or strings*
Bitmap is showing as Australian
Getting a string from a LoadString returns French (Which is what I want)

But without changing any other settings, adding a US version of the string
returns the US string, abd the bitmap shows as US.

Can anyone help please.

John.

P.S. The threads show it is better to have multiple DLL's, but we are
trying to provide just a few languages and images in the one dll.

"tutu lamotte" <sebastie...@hotmail.com> wrote in message
news:mnwm9.5600$Kg4.8...@news20.bellglobal.com...
> Hi folks !
>
> CONTEXT :
> I though i knew how it worked ! Seems not cause it doesn't ! ...
> I made an English MFC Application with all strings in a specific "English
> US" string table.
> I inserted a copy of that string table (in the same *.RC) with
specification
> French Standard and i translated all strings to french.
>
> I though that by modifying (Project/Settings/Language) it would set the
> correct String Table after rebuilding! Well it doesn't.
> It seem like the application is always using the standard language of my
OS
> which is French. I can no longer activate the English version of the
> application.
>
> QUESTION:
> A) Does it meen that on an English PC the same EXE would run in english ?
> B) And would i be able to force the use of a given String Table by calling
> SetThreadLocale ? (And where should i call it ?)
>
>
> Thanks in advance !
>
>
>
>

[Michael (michka) Kaplan [MS]]

LOCALE_SYSTEM_DEFAULT is your system default locale, not your user locale.

This is entirely expected.

Try using LOCALE_USER_DEFAULT instead.

--
MichKa

This posting is provided "AS IS" with
no warranties, and confers no rights.

"John Smith" <Jo...@Smith.name> wrote in message
news:#h6IDpQcCHA.1356@tkmsftngp08...

[Michael (michka) Kaplan [MS]]

FWIW, I cannot repro an issue with the user default being French but
GetLocaleInfo returning anything but USA settings/info.

Tested on Win2000, WinXP, and Windows .NET Server.

MichKa

"Michael (michka) Kaplan [MS]" <mic...@online.microsoft.com> wrote in
message news:#OS72OUcCHA.2588@tkmsftngp12...

[Andrew Baker]

The main problem is that when a US bitmap or string is in the stringtable or
image, this gets displayed regardless of what language is selected.

Without having a US bitmap or string everything seems ok.

Test.
Set your system to be Australian
Create a new dialog.
Add a bitmap to this (language default) That is "AUS" in a bitmap

run the app and see the bitmap

Now add a language specific bitmap for US - "US" in a bitmap

This now shows all the time.

Thanks for you time looking at this Michka, it is appreciated.

Andrew

"Michael (michka) Kaplan [MS]" <mic...@online.microsoft.com> wrote in

message news:eCs16jUcCHA.1296@tkmsftngp12...

[Andrew Baker]

regarding my last post, Visual C++ V 6.0

"Michael (michka) Kaplan [MS]" <mic...@online.microsoft.com> wrote in

message news:eCs16jUcCHA.1296@tkmsftngp12...

[Michael (michka) Kaplan [MS]]

Ok, I am now very confused.

You made some claims about the behavior of the GetLocaleInfo API that I
cannot reproduce.

You have included a lot of newsgroups here, including an MFC newsgroup --
yet you asked about Win32 APIs?

There is no way to "set your system to be Australian." See
http://i18nwithvb.com/win2k.htm for an example list of all the different
settings in Windows 2000, and then if you can tell me exactly what you mean
by "setting your system" I will understand it better and maybe be able to
help.

Note that NONE of this changes the fact that putting all languages in the
main EXE, in a single binary, is not the best way to do things. Best
practices really includes separate resource DLLs per language. You might
want to consider that the extensive amount of time being invested in this
"one binary" approach could be better spent having a more flexible and more
extensible system that is (as a bonus) not affected by changes in the
resource loader between versions of Windows.

Food for thought, I hope. :-)