Provide an equivalent public function to wxUILocale::UseLocaleName (Issue #23862)
Francesco Saltori
Description
Currently, wxWidgets documentation recommends to use wxUILocale instead of wxLocale to avoid compatibility issues on MacOS.
However, the former lacks an important feature that the latter has: the ability to choose a UI locale different from the system default one.
When using wxLocale, we can pass a custom language to wxLocale::Init. The only way to achieve the same thing with wxUILocale is to use the undocumented method wxUILocale::UseLocaleName, which I'd rather not to since it's meant to be used only internally.
That's why I propose to add a publicly exposed method to wxUILocale that takes a wxLanguage enum value and sets the UI locale accordingly (could wxUILocale::UseLanguage be a fitting name?).
To add a bit more context on why this would be helpful: the project I'm contributing to gives users the ability to pick the UI language they prefer from a list of available translations, and currently uses wxLocale to apply the language chosen by the user.
To improve MacOS compatibility, I'd like to make it use wxTranslations and wxUILocale instead, but I'd rather not rely on internal APIs 🙂
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Lauri Nurmi
How does this relate to the fact that macOS itself gives users the ability to pick the preferred UI language from a list of available translations, and wxUILocale presumably obeys this setting?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #23862 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I thought we explained this in the documentation, but apparently we don't do it clearly enough: what you'd like to do (and what I, and a few millions other developers, find perfectly reasonable) is simply impossible to do under macOS. The application language is determined on startup, must be one of the languages listed in its Info.plist and can not be changed during run-time.
One of the points of wxUILocale API is that it only allows to do things that work on all platforms and we simply can't make this work under macOS (until Apple changes their mind, but I'd not count on this happening any time soon), sorry.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
I wasn't aware of that macOS feature, however an application might still want to override the default locale option. For example, the application I mentioned above provides a language selector on its own, instead of having the user delve into the OS language settings just to change the app locale.
But more importantly, the wxUILocale API doesn't target macOS only. AFAIK Windows and Linux do not have a built-in per-app language selector.
Even if I wanted to provide an in-app language selector only on those OSes, I would have to resort to wxLocale on those systems while using wxUILocale on macOS, which looks quite counterintuitive to me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
Thanks for the information.
However I feel I'm missing something. If:
The application language is determined on startup, must be one of the languages listed in its Info.plist and can not be changed during run-time.
Then I guess that wxUILocale::UseDefault is simply a no-op on macOS?
And regarding other platforms, is there a way to just set the UI locale at runtime without applying translations, unlike wxLocale does?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Then I guess that
wxUILocale::UseDefaultis simply a no-op on macOS?
No, calling this function opts in into using the selected language. If you don't call it, everything remains in English/C locale.
And regarding other platforms, is there a way to just set the UI locale at runtime without applying translations, unlike wxLocale does?
wxUILocale only sets the locale and never does anything for the translations (which is indeed another important difference between it and wxLocale which conflated two related but different tasks), you always need to use wxTranslations explicitly with it, see the internat sample.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
Then I guess that
wxUILocale::UseDefaultis simply a no-op on macOS?No, calling this function opts in into using the selected language. If you don't call it, everything remains in English/C locale.
IMHO there is a bit of confusion here. wxUILocale::UseDefault sets internally a reference to the default UI locale based on the user's preferences as specified in the operating system. However, the C locale is not changed - at least not on Windows and macOS; on Unix systems it is different, because it is unavoidable to keep the C locale in sync with the default UI locale.
On Windows and macOS, where the C runtime locale is not modified by wxUILocale, the C runtime locale keeps its default value, which is "C" (corresponding to "en_US_POSIX"). This means that on those platforms for example the method wxString::FromDouble will use a decimal point as a separator even if the default UI locale is "German" or "French". This changes only, if the application explicitly changes the C runtime locale via setlocale.
And regarding other platforms, is there a way to just set the UI locale at runtime without applying translations, unlike wxLocale does?
wxUILocaleonly sets the locale and never does anything for the translations (which is indeed another important difference between it andwxLocalewhich conflated two related but different tasks), you always need to usewxTranslationsexplicitly with it, see the internat sample.
Correct. wxTranslations will use the default UI language, if a matching message catalog is available. However, the application is free to explicitly select a different language for the translation of the UI strings.
AFAICT all methods of the wxWidgets controls that format numbers and dates for the UI query the current wxUILocale to determine the required format specifications. This can be verified in the internat sample by using wxUILocale::UseLocaleName with a non-default locale id instead of wxUILocale::UseDefault - the floating point numbers and the single date control are then formatted according to the selected non-default locale.
A bit unfortunate is that the calendar control shows always German month and weekday names on my German Windows system, even if wxUILocale::UseDefault (or wxUILocale::UseLocaleName) is not called at all (as you can select in the internat sample on program start). IMHO this seems to be a bug.
I haven't tested on macOS yet, but I'm pretty sure that using wxUILocale::UseLocaleName should work there, too, because wxUILocale doesn't tamper with the C runtime locale. I will try to test it on macOS next week. If it works, then maybe wxUILocale::UseLocaleName could be made publicly available.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Then I guess that
wxUILocale::UseDefaultis simply a no-op on macOS?No, calling this function opts in into using the selected language. If you don't call it, everything remains in English/C locale.
IMHO there is a bit of confusion here.
wxUILocale::UseDefaultsets internally a reference to the default UI locale based on the user's preferences as specified in the operating system. However, the C locale is not changed - at least not on Windows and macOS; on Unix systems it is different, because it is unavoidable to keep the C locale in sync with the default UI locale.
Yes, indeed, under macOS we don't change the locale in "C" sense of the word. However from the user point of view, the most important effect is that if you don't call wxUILocale::UseDefault(), all the OS-provided UI elements remain in English instead of using the user's language.
A bit unfortunate is that the calendar control shows always German month and weekday names on my German Windows system, even if
wxUILocale::UseDefault(orwxUILocale::UseLocaleName) is not called at all (as you can select in the internat sample on program start). IMHO this seems to be a bug.
This is indeed strange.
I haven't tested on macOS yet, but I'm pretty sure that using
wxUILocale::UseLocaleNameshould work there, too, becausewxUILocaledoesn't tamper with the C runtime locale. I will try to test it on macOS next week. If it works, then maybewxUILocale::UseLocaleNamecould be made publicly available.
I don't think it can work. All native controls won't use a language different from default. E.g. all message boxes will still use "Ja" and "Nein" on your German system rather than "Oui" and "Non" even if you call UseLocaleName("french").
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
Yes, indeed, under macOS we don't change the locale in "C" sense of the word. However from the user point of view, the most important effect is that if you don't call
wxUILocale::UseDefault(), all the OS-provided UI elements remain in English instead of using the user's language.
As said I intend to do some more testing on macOS next week.
My current tests were on Windows where not calling wxUILocale::UseDefault() left the calendar control in German. I had expected to see English names in that case. I didn't check yet for other items (like "Yes", "No" and so on).
A bit unfortunate is that the calendar control shows always German month and weekday names on my German Windows system, even if
wxUILocale::UseDefault(orwxUILocale::UseLocaleName) is not called at all (as you can select in the internat sample on program start). IMHO this seems to be a bug.This is indeed strange.
Maybe it is a Windows 11 issue - I moved to Windows 11 with my development environment recently. I'll try to test it on Windows 10 again later on.
I haven't tested on macOS yet, but I'm pretty sure that using
wxUILocale::UseLocaleNameshould work there, too, becausewxUILocaledoesn't tamper with the C runtime locale. I will try to test it on macOS next week. If it works, then maybewxUILocale::UseLocaleNamecould be made publicly available.I don't think it can work. All native controls won't use a language different from default. E.g. all message boxes will still use "Ja" and "Nein" on your German system rather than "Oui" and "Non" even if you call
UseLocaleName("french").
Most likely you are right. At least on macOS. On Windows we call SetThreadPreferredUILanguages ... and I had expected that calling it with "fr-FR" on my German system would change the names in the calendar control to French. But that was not the case.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
I made a few tests with the internat sample on macOS Ventura. Results are a bit confusing. I used the latest wxWidgets master.
- Not calling
wxUILocale::UseDefaulthad the effect that the C locale was detected and almost all UI elements were in English, except for the "file save" dialog. Additionally the "Window" menu was a mix of English and German. - Calling
wxUILocale::UseDefaulthad the effect that the German locale on my system was detected. The calendar control showed German month and weekday names. However, the system strings like "yes", "no", "cancel" and so on (inwxMessageBox,wxGetTextFromUseretc) were still in English. This is surprising. Additionally the "Window" menu was a mix of English and German. - Calling
wxUILocale::UseLocaleName("fr-FR")had the effect that the French locale was detected. I had to explicitly load the French message catalog, otherwise the default German catalog is loaded. The calendar control shows month and weeekday names in French, the file dialog was in German, the system strings ("yes", "no", "cancel" etc) were in English. Additionally the "Window" menu was a mix of English, German, and French.
AFAIK the calendar control is not native on macOS. Therefore it is not a surprise that the month and weekday names are displayed in the selected language. That default strings like "yes" and "no" were always in English is a surprise, however. I had expected German strings on my German macOS. That the "save file" dialog was always in German, was also surprising.
I have to admit that my macOS runs in a virtual machine, not on mac hardware. I don't know whether this makes a difference or not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I made a few tests with the
internatsample on macOS Ventura.
Thanks for testing!
Results are a bit confusing.
Just to be sure, did you leave the code using wxTranslations and just removed/commented out the call to wxUILocale::UseDefault()? If so, this could explain some of the oddities.
1. Not calling `wxUILocale::UseDefault` had the effect that the C locale was detected and almost all UI elements were in English, except for the "file save" dialog. Additionally the "Window" menu was a mix of English and German.
The latter could be due to using wxTranslations. I can't explain how/why would the file dialog be in German by default however...
2. Calling `wxUILocale::UseDefault` had the effect that the German locale on my system was detected. The calendar control showed German month and weekday names. However, the system strings like "yes", "no", "cancel" and so on (in `wxMessageBox`, `wxGetTextFromUser`etc) were still in English. This is surprising.
Yes, especially because the message box is a native dialog while the text input one is a generic wx one. So it looks like wx translations are not used, finally -- but then I can't explain the above.
3. Calling `wxUILocale::UseLocaleName("fr-FR")` had the effect that the French locale was detected. I had to explicitly load the French message catalog, otherwise the default German catalog is loaded. The calendar control shows month and weeekday names in French, the file dialog was in German, the system strings ("yes", "no", "cancel" etc) were in English. Additionally the "Window" menu was a mix of English, German, and French.
AFAIK the calendar control is not native on macOS. Therefore it is not a surprise that the month and weekday names are displayed in the selected language.
Yes.
That default strings like "yes" and "no" were always in English is a surprise, however. I had expected German strings on my German macOS. That the "save file" dialog was always in German, was also surprising.
Yes, I really have no explanation for the discrepancy between the message and file dialogs...
I have to admit that my macOS runs in a virtual machine, not on mac hardware. I don't know whether this makes a difference or not.
I really don't see how could it manifest at this level, so I expect that the same happens on real Apple hardware too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
Just to be sure, did you leave the code using
wxTranslationsand just removed/commented out the call towxUILocale::UseDefault()? If so, this could explain some of the oddities.
No, I didn't commented out the call. Before calling wxUILocale::UseDefault() the sample application asks whether I want to use the program in the detected default language (German on my system). Answering this question with "No" skips calling wxUILocale::UseDefault() and loading message catalogs. That is, all should be in English and based on the C locale.
- Not calling
wxUILocale::UseDefaulthad the effect that the C locale was detected and almost all UI elements were in English, except for the "file save" dialog. Additionally the "Window" menu was a mix of English and German.The latter could be due to using
wxTranslations. I can't explain how/why would the file dialog be in German by default however...
As explained above the message catalog is not used at all in this scenario. That is, all text strings should be in English.
- Calling
wxUILocale::UseDefaulthad the effect that the German locale on my system was detected. The calendar control showed German month and weekday names. However, the system strings like "yes", "no", "cancel" and so on (inwxMessageBox,wxGetTextFromUseretc) were still in English. This is surprising.
Yes, especially because the message box is a native dialog while the text input one is a generic wx one. So it looks like wx translations are not used, finally -- but then I can't explain the above.
Arrggh, I just detected that the observed behaviour is at least partially my fault. I started with my test with a fresh copy of the wxWidgets repository. And I forgot that it is necessary to copy the wxWidgets standard message catalog into to the respective translation directory.
After copying wxstd.mo (German resp French version) to the respective translation directory, the situation improves considerably.
Now for the default language the strings "yes", "no" and so on in wxMessageBox, wxGetTextFromUser etc are in German as expected.
However, the system menu was still a mix of English, and German.
AFAICR Lauri had to make some modifications in the macOS specific code so that at least some system menu entries were translated correctly.
- Calling
wxUILocale::UseLocaleName("fr-FR")had the effect that the French locale was detected. I had to explicitly load the French message catalog, otherwise the default German catalog is loaded. The calendar control shows month and weeekday names in French, the file dialog was in German, the system strings ("yes", "no", "cancel" etc) were in English. Additionally the "Window" menu was a mix of English, German, and French.
After copying the French version of wxstd.mo into subdirectorey fr of the sample the strings "yes", "no" and so on in wxMessageBox, wxGetTextFromUser etc are now in French, too (as I had hoped).
However, the file dialog for saving a file is still in German (just as in scenario 1 without calling wxUILocale::UseDefault).
And the system menu was still a mix of English, German and French.
That default strings like "yes" and "no" were always in English is a surprise, however. I had expected German strings on my German macOS. That the "save file" dialog was always in German, was also surprising.
Yes, I really have no explanation for the discrepancy between the message and file dialogs...
Even after supplying the wxstd message catalog the file dialog is in German in all 3 scenarios.
It is strange that the button strings in the message box (of which you say it is native on macOS) are translated correctly, while the native file dialog is always in German.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Igor Korot
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/23862/1716593716%40github.com.
Ulrich Telle
I just checked the code for the message box. Actually, it is not native on macOS. The button strings get translated on configuring the message box.
That is, only the really native file dialog uses always the default locale, even if the default locale is not set by the application.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
In the meantime I inspected the macOS specific code for the file dialogs in file filedlg.mm. According to the Apple documentation about the class NSSavePanel it is in principle possible to configure the panel's appearance, for example, you can modify the following attributes (using matching translations as in the code for the message dialog):
- title - The title of the panel.
- prompt - The text to display in the default button.
- message - The message text displayed in the panel.
- nameFieldLabel - The label text displayed in front of the filename text field.
AFAICT currently only the message is set in the code (and will be displayed in the language selected for translations). I don't know whether the appearance of all UI elements can be changed in that way.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
I took some time to read the latest replies in more detail. As far as I understood, it appears that wxUILocale::UseLocaleName works fine on macOS too, with the exception of a few native OS dialogs/menu entries being displayed in the user-preferred language (which appears to happen even when not calling wxUILocale::UseDefault, as @utelle observed).
Is this enough to reconsider my proposal? At this point I don't see any compelling reason not to expose wxUILocale::UseLocaleName or an equivalent function publicly.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I'm not sure, but I think there are going to be more problems than this. And AFAIK Mac apps are just not supposed to use any language not declared in their Info.plist (so we can never make this work for any language) and this language still needs to be chosen at app startup.
What is the point of using UseLocaleName() if it only affects wx stuff? You could already just use wxTranslations to load whichever translations you want to use, if you only care about this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
What is the point of using UseLocaleName() if it only affects wx stuff?
It would be useful to make wxWidgets date/number formatting functions behave according to the user-selected language. Otherwise we would have localized strings but non-localized date/number formatting.
AFAIK Mac apps are just not supposed to use any language not declared in their Info.plist (so we can never make this work for any language) and this language still needs to be chosen at app startup
In our case, the list of languages that can be selected by the user is fixed so we could easily add them upfront to the Info.plist.
Apart from that, since wxWidgets doesn't touch the C locale on macOS and handles UI localization by itself, is adding languages to the Info.plist actually a strict requirement? I couldn't find any indication on that on Apple developer docs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
What is the point of using UseLocaleName() if it only affects wx stuff?
It would be useful to make wxWidgets date/number formatting functions behave according to the user-selected language. Otherwise we would have localized strings but non-localized date/number formatting.
But I suspect that any native controls, including NSDatePicker used by wxDateTimePickerCtrl would still use wrong formatting, so now it wouldn't be consistent inside the application itself, which doesn't really seem like a gain...
AFAIK Mac apps are just not supposed to use any language not declared in their Info.plist (so we can never make this work for any language) and this language still needs to be chosen at app startup
In our case, the list of languages that can be selected by the user is fixed so we could easily add them upfront to the Info.plist. Apart from that, since wxWidgets doesn't touch the C locale on macOS and handles UI localization by itself, is adding languages to the Info.plist actually a strict requirement? I couldn't find any indication on that on Apple developer docs.
Unfortunately I don't know for sure neither, but I think I saw it somewhere.
Anyhow, I'm not eager to add a function that won't (and can't be made to) work 100% correctly, but if people really, really want to have it and someone is ready to make the required changes, including updating the documentation to clearly explain the limitations, why not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
What is the point of using UseLocaleName() if it only affects wx stuff?
It would be useful to make wxWidgets date/number formatting functions behave according to the user-selected language. Otherwise we would have localized strings but non-localized date/number formatting.
AFAIK the calendar control under macOS already uses names and formatting based on the current locale (which is the system default locale, when wxUILocale::UseDefault() was called). It should work also correctly, if wxUILocale::UseLocaleName() was successfully called instead of wxUILocale::UseDefault().
But I suspect that any native controls, including
NSDatePickerused bywxDateTimePickerCtrlwould still use wrong formatting, so now it wouldn't be consistent inside the application itself, which doesn't really seem like a gain...
In principle, you are right, BUT NSDatePicker allows to set the locale which it should use. Most likely NSDatePicker uses the system default locale, if the locale attribute was not set explicitly.
That is, to support a non-default locale set by wxUILocale::UseLocaleName() it would be necessary to query the NSLocale from the current wxUILocale and set it in NSDatePicker.
At the moment the wxUILocaleImpl class has no method to retrieve a pointer to the internal native locale instance. Thus the main question is how to make the pointer available. If that is solved, setting the NSDatePicker locale is a one-liner.
In our case, the list of languages that can be selected by the user is fixed so we could easily add them upfront to the Info.plist. Apart from that, since wxWidgets doesn't touch the C locale on macOS and handles UI localization by itself, is adding languages to the Info.plist actually a strict requirement? I couldn't find any indication on that on Apple developer docs.
Unfortunately I don't know for sure neither, but I think I saw it somewhere.
I'm no macOS expert, therefore I don't know for sure either. However, it could be easily tested with minor modifications to the internat sample.
Anyhow, I'm not eager to add a function that won't (and can't be made to) work 100% correctly, but if people really, really want to have it and someone is ready to make the required changes, including updating the documentation to clearly explain the limitations, why not.
Well, under Windows and Linux using wxUILocale::UseLocaleName() works as expected - at least as long as the requested locale is actually supported by the operating system. So it would certainly be nice if this would work under macOS, too.
In principle, I would be ready to dedicate some time to this task. However, at least regarding how to access the internal locale instance of wxUILocale I would need a bit of advice how to accomplish that without introducing major changes to the wxUILocale API.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
AFAIK the calendar control under macOS already uses names and formatting based on the current locale (which is the system default locale, when
wxUILocale::UseDefault()was called). It should work also correctly, ifwxUILocale::UseLocaleName()was successfully called instead ofwxUILocale::UseDefault().
wxCalendarCtrl is generic, so it would indeed work, it's wxDatePickerCtrl which is problematic.
But I suspect that any native controls, including
NSDatePickerused bywxDateTimePickerCtrlwould still use wrong formatting, so now it wouldn't be consistent inside the application itself, which doesn't really seem like a gain...In principle, you are right, BUT
NSDatePickerallows to set the locale which it should use.
Thanks, I didn't know about this. So yes, it is possible to solve this problem with it.
We'd also have to do something similar for any other control that is possibly affected by the locale, if any, but if we can take care of (most of?) the standard dialogs and wxDatePickerCtrl it's already good...
At the moment the
wxUILocaleImplclass has no method to retrieve a pointer to the internal native locale instance. Thus the main question is how to make the pointer available. If that is solved, setting theNSDatePickerlocale is a one-liner.
This isn't really much of a problem, we can always add a private Mac-only function for retrieving it if we don't find anything better.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
wxCalendarCtrlis generic, so it would indeed work, it'swxDatePickerCtrlwhich is problematic.
Not really.
In principle, you are right, BUT
NSDatePickerallows to set the locale which it should use.Thanks, I didn't know about this. So yes, it is possible to solve this problem with it.
I didn't know it either until today. 😄
wxCalendarCtrl already works. Number formatting uses wxUILocale. wxDatePickerCtrl can be made operational. Are there any other native controls that are locale dependent?
We'd also have to do something similar for any other control that is possibly affected by the locale, if any, but if we can take care of (most of?) the standard dialogs and
wxDatePickerCtrlit's already good...
IMHO we should at least try to handle all locale dependent controls. I don't know (yet) whether it will be always possible.
At the moment the
wxUILocaleImplclass has no method to retrieve a pointer to the internal native locale instance. Thus the main question is how to make the pointer available. If that is solved, setting theNSDatePickerlocale is a one-liner.This isn't really much of a problem, we can always add a private Mac-only function for retrieving it if we don't find anything better.
Hm, wxUILocaleImpl* m_impl is a private member of wxUILocale, and NSLocale* const m_nsloc is a private member of wxUILocaleImplCF. One way to solve this could be to define a private Mac-only friend function being friend to wxUILocale, wxUILocaleImpl and wxUILocaleImplCF.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
Thank you guys for looking into this. Shouldn't this issue be reopened since the discussion is moving forward?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
The most elegant solution for Mac would probably be to remember the last used NSLocale, i.e. set some global variable in wxUILocaleImplCF::Use() (and reset it in wxUILocaleImplCF dtor).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Reopened #23862.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
The most elegant solution for Mac would probably be to remember the last used
NSLocale, i.e. set some global variable inwxUILocaleImplCF::Use()(and reset it inwxUILocaleImplCFdtor).
Good idea. This avoids to clutter the wxUILocale related classes with internal methods or functions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
@vadz: Some details about the implementation:
The most elegant solution for Mac would probably be to remember the last used
NSLocale, i.e. set some global variable inwxUILocaleImplCF::Use()
I agree with this. wxUILocaleImplCF::Use() is the only method where we know for sure that a NSLocale is selected and set as the current locale.
(and reset it in
wxUILocaleImplCFdtor).
Sorry, I think this approach is not the way to go. Since you can create as many wxUILocale instances as you want (without being able to call wxUILocaleImplCF::Use()), a wxUILocaleImplCF instance can't know whether it is the current locale in use or not. You could argue that we could check whether the NSLocale member of a wxUILocaleImplCF instance equals the global NSLocale, but in principle you could have several instances matching the default locale.
Since our new global NSLocale corresponds to the current wxUILocale (that is, wxUILocale::ms_current), IMHO resetting the global NSLocale pointer is not necessary, because it will be valid as long as ms_current exists and is valid. ms_current is a static member of wxUILocale. That is, it exists, until the application is terminated.
This brings us to the question whether ms_current is always valid. Actually, it is not. If the application doesn't call WXUILocale::UseDefault() (or wxUILocale::UseLocaleName()), ms_current is invalid. However, when wxUILocale::GetCurrent() is called and ms_current is still invalid, a standard C locale will be assigned to ms_current, thus making it valid.
The problem here is that wxUILocale::GetCurrent() doesn't call wxUILocaleImpl::Use() - as it should IMHO. Under MacOS not calling wxUILocaleImpl::Use() would lead to a discrepancy, because our new global NSLocale pointer would not be set in this case. If the global NSLocale pointer is null, we would use for example for the date picker the system default locale instead of the standard C locale - for example on my system de_DE vs en_US_Posix.
Conclusion:
- Set the global
NSLocalepointer within methodwxUILocaleImpl::Use() - Call
wxUILocaleImpl::Use()in methodwxUILocale::GetCurrent(), if a standard C locale is created - Check
wxUILocale::GetCurrent().IsSupported()before using the globalNSLocalepointer.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
I modified the wxWidgets code locally according to my conclusions. I tested it with the internat sample.
As you know my development system has a German default locale. Under macOS compiling the internat sample results in 2 files: internat and internat.app. The localization behaviour depends on how I start the sample.
- Starting
internatfrom the command line results in a default English locale used in standard system dialogs like the file open/save dialog. - Starting
internat.appby double-clicking it in the finder results in a default German locale used in standard system dialogs.
- Calling
wxUILocale::UseDefault()using start method 2, I get a UI completely in German. With start method 1 I get a mix of German and English. - Calling
wxUILocale::UseLocaleName("fr_FR")using start method 2, I get a UI in French, but the standard system dialogs are mostly in German. With start method 1 the standard system dialogs are mostly in English.
However, with the modified wxDatePickerCtrl implementation this control uses the selected language settings - German, French, or English (if the question on starting the application was answered with No).
IMHO introducing the internal modification of wxUILocale, wxUILocaleImpl, and wxDatePickerCtrl should be done independtly of whether we make method wxUILocale::UseLocaleName() an official API method or not. The reason is that the UI is more consistent if wxUILocale is not used at all and behaviour according to the C locale is expected.
Under macOS it is unfortunately impossible to modify the locale used for standard system dialogs from within the application.
To get consistent behaviour if the application is not localized/translated at all, it's the developer's task to configure the application in such a way that English is also used for standard system dialogs. I don't know how this has to be done, because I'm not a macOS expert, but if a user can configure the UI language, I guess a developer should be able to influence that, too.
In fact, after my latest experiments I'm less convinced that we should make wxUILocale::UseLocaleName() part of the public API.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Note that running non-bundled GUI applications is not supported under macOS. If you want to launch it from the command line you have to run ./internat.app/Contents/MacOS/internat and then the behaviour should be the same as when running it from Finder.
But yes, this (ugly) mix of languages in the UI is the reason I had decided not to provide this function originally.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
Note that running non-bundled GUI applications is not supported under macOS.
I made my test on macOS Ventura ... and I could start successfully the sample by running ./internat from the command line.
If you want to launch it from the command line you have to run
./internat.app/Contents/MacOS/internatand then the behaviour should be the same as when running it from Finder.
I have not yet tested this, but I'm quite sure that you are right.
But yes, this (ugly) mix of languages in the UI is the reason I had decided not to provide this function originally.
Actually, we have a similar situation under Windows. Using wxUILocale::UseDefault() works as expected and shows all controls and standard system dialogs in the user's default UI language. Using wxUILocale::UseLocaleName() formats numbers and dates according to the selected locale, but the calendar control and the date picker control use the default user UI language (German in my case). However, the file open/save dialog used the selected locale, although native controls are used.
If wxUILocale::UseDefault() is not called, number and date formatting is done based on English (US). However, calendar control and date picker control use German names and formats. AFAIK common controls (like calendar and date picker) will use the system default language, unless InitMUILanguage() is called (wxWidgets does not do that).
It seems that the Windows function SetThreadPreferredUILanguages() that is called in wxUILocaleImplName() has no effect for common controls like calendar or date picker control.
It seems that the situation under Windows is no better than under macOs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Igor Korot
Note that running non-bundled GUI applications is not supported under macOS.
I made my test on macOS Ventura ... and I could start successfully the sample by running
./internatfrom the command line.
If you want to launch it from the command line you have to run
./internat.app/Contents/MacOS/internatand then the behaviour should be the same as when running it from Finder.I have not yet tested this, but I'm quite sure that you are right.
But yes, this (ugly) mix of languages in the UI is the reason I had decided not to provide this function originally.
Actually, we have a similar situation under Windows. Using
wxUILocale::UseDefault()works as expected and shows all controls and standard system dialogs in the user's default UI language. UsingwxUILocale::UseLocaleName()formats numbers and dates according to the selected locale, but the calendar control and the date picker control use the default user UI language (German in my case). However, the file open/save dialog used the selected locale, although native controls are used.If
wxUILocale::UseDefault()is not called, number and date formatting is done based on English (US). However, calendar control and date picker control use German names and formats. AFAIK common controls (like calendar and date picker) will use the system default language, unlessInitMUILanguage()is called (wxWidgets does not do that).It seems that the Windows function
SetThreadPreferredUILanguages()that is called inwxUILocaleImplName()has no effect for common controls like calendar or date picker control.It seems that the situation under Windows is no better than under macOs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/23862/1756344766%40github.com.
utelle
Ulrich,On Tue, Oct 10, 2023 at 5:17 PM Ulrich Telle <git...@wxwidgets.org> wrote:Note that running non-bundled GUI applications is not supported under macOS.
I made my test on macOS Ventura ... and I could start successfully the sample by running ./internat from the command line.
Ulrich Telle
It seems that the situation under Windows is no better than under macOs.
Well, since the date picker and the calendar controls are part of the common controls (comctl32) they do not react to changes of the preferred UI language. They will always use the user's default locale as set in the system.
However, the date picker under Windows could be tweaked to use at least the correct date format, just as the date picker under macOS can be tweaked to use a user defined locale.
Regarding the calendar control there is absolutely no chance - it will always use the default user locale. That can be seen easily, if wxUILocale::UseDefault() is not called at all - the application language will then be English, but date picker and calendar will still use the default user locale (German in my case).
Even though, we can't solve all issues, I think it would be useful to adjust the wxWidgets code as described in one of my previous posts and maybe also the code of the date picker under Windows.
Regarding wxUILocale::UseLocaleName() I think this method can be useful for developers, because it allows to test the behaviour of an application under a different locale at least to a high degree without requiring to tweak the host operating system. However, in release versions of an application it should most likely not be called.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
I just made a PR with the changes to make the macOS date picker control locale-aware.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
However, in release versions of an application it should most likely not be called.
After reading your latest findings, I think that wxUILocale::UseLocaleName could also be useful to non-English applications that do not provide a multilingual UI.
For example, a German-only application could call wxUILocale::UseLocaleName("de-DE") to change the UI language to German even if the user's preferred language is not German. Some dialogs/UI elements will still use the default language, but at the very least date/number formatting will be consistent with the application language.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
After reading your latest findings, I think that
wxUILocale::UseLocaleNamecould also be useful to non-English applications that do not provide a multilingual UI.
Applications that do not provide support for a multilingual UI are usually meant to be distributed in regions where the actual language is spoken and where users typically have configured the UI language of their system to the very language. For such applications it is usually enough to use wxUILocale::UseDefault().
For example, a German-only application could call
wxUILocale::UseLocaleName("de-DE")to change the UI language to German even if the user's preferred language is not German.
I think that that is a not very common scenario.
Some dialogs/UI elements will still use the default language, but at the very least date/number formatting will be consistent with the application language.
That's the reason why @vadz is not in favor of adding wxUILocale::UseLocaleName() to the public API: except for the default locale we obviously can't guarantee an absolutely consistent behaviour - there will always be more or less discrepencies depending on the actual operating system.
For language-agnostic applications (not calling wxUILocale() at all) one usually expects a behaviour consistent with the standard C locale (i.e. en-US_POSIX). Therefore I still think that applying the changes I prepared in my PR for MacOS would be good. Work is in progress to do the same for Windows (@vadz Would you prefer a separate PR for the required changes in wxMSW or should I add them in the MacOS PR?).
All the above still doesn't answer the question whether wxUILocale::UseLocaleName() should be part of the public API or not. As said it would make sense for testing applications easily in a non-default locale setting. And in rare occasions it may be useful for end-users, too. Personally, I would add it (with clear documentation of the deficiencies), because it is doable anyway as long as wxLocale is part of the API. But I'm not a member of the wxWidgets core developer team - it's up to them to decide.
Another useful addition would be to add methods to the date and number formatters that take a specific wxUILocale instance as a parameter, so that it would be possible to format dates and numbers according to any supported locale, not only the default locale and the standard C locale.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
In the meantime I modified the code of the date and time picker controls to make them locale-aware under Windows, too, in my local development environment.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
I've seen that #23972 has been merged, so this can be closed. Thank you for considering this proposal!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Francesco Saltori
Closed #23862 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.