Andries Bos wrote:
> I have a Dutch application that is localized to English by using
> Multilizer to produce dll's. It workts fine and at startup of the program
> I could set my language.
>
> However, within this application I'm using custom components: within this
> component I use the function
> FormatDateTime(...)
> to retrieve my weekday's as string
Why are you asking the operating system how to translate the names of the
days of the week? Isn't that what Multilizer is for?
> I've tried to force reading the application's setting bij using a local
> TFormatSettings,
>
> GetLocaleFormatSettings(LOCALE_system_DEFAULT, LFormatSettings);
> and use this lFormatsettings variable within the function:
> FormatDateTime('d mmmm yy', ADatum, LFormatsettings);
>
> but all of these will return only the day-strings using my current
> regional settings
Well, yeah. All you've done is fetched the system's locale, which is
exactly what you already had.
> Changing my regional settings from dutch to english will return the
> correct strings,
It returns the _correct_ settings, or it returns the _English_ settings?
If you wanted the days of the week in French, would you still get the
correct results when you set your locale to English?
> but I would like to switch between laguages within my
> application at runtime
Why? Who do you expect to use that feature? Does Multilizer support that
feature?
> and would like to be independent of the regional
> setting. Also I could not force customers to change their regional
> settings to get the 'correct' 'Monday, Tuesday...'-strings etc.
>
> If I change the abond getlocalformatsettings to
> GetLocaleFormatSettings(1033, LFormatSettings); it will produce the
> English version of the day-names.
Right. That's because 1033 is the locale ID for English.
> How could I detect that my current application is started with the English
> version?
The English version of what? You want to _ignore_ the OS language. You're
not writing multiple versions of your program, just one version that
supports many languages. And what does it matter what the language was
when you started? You said you want to be able to change your program's
language at run time.
> I could not use global variables because this component is
> developed independent of my main application.
How independent? Is it so independent that it doesn't know about
Multilizer? If that's the case, then your component simply can't know what
the program's current language is, and thus it's the application's job to
trick the component into using the language that the application wants. I
would hope that Multilizer solves the problem already. I don't know what
the point of the product would be, otherwise.
I'm familiar with DxGetText. It solves the problem by patching the
function that the RTL uses for loading resourcestrings. That way, any code
that uses resourcestrings is automatically translated, even when it was
written without knowledge of DxGetText.
> In other words: I would like to know the 'language' of my application and
> of my pc. (regionale settings) and use this within my
> getLocaleformatsettings function
As I understand it, you really _don't_ want the language of your PC. You
only want the current language of your application.
How do you tell Multilizer what language it should use? Does Multilizer
provide a way for the program to find out what language Multilizer is
using?
--
Rob
