LC_MESSAGES should only be used for getting the translations language,
so using GetLocaleFromEnvironment(), which uses its value if LC_ALL was
not set, in wxUILocaleImplUnix::InitLocaleNameAndCodeset() was wrong for
the cases when we did call it from there, i.e. when not using glibc and
so _NL_LOCALE_NAME is not defined.
Correct this by replacing GetLocaleFromEnvironment() querying all
environment variables at once with GetLocaleFromEnvVar() getting the
value from just the one environment variable specified by caller and
not calling it for LC_MESSAGES from InitLocaleNameAndCodeset().
See #23217.
Remove WXDLLEXPORT from the internal classes used only inside the
implementation.
Also remove forward declarations of classes not used in the header from
it.
Historically, we used to fall back on any locale using the same
language, if the exactly requested locale was unavailable. This doesn't
seem such a great idea, and results in unexpected behaviour, such as
returning true from wxUILocale::IsSupported() for locales such as
"en-FR" that are not really supported at all.
Remove this fallback and just return false if the locale with the
specified region is not supported.
Still choose any supported region if the region is omitted entirely,
however.
Using GTKGetPreferredSize() doesn't always seem to return the correct
values, resulting in making the control too big, so just hard code the
smaller margins there.
Additionally implement wxWebViewEdge::GetUserAgent() via SDK.
This functionality is available with the slightly newer
WebView2 SDK required by previous changes.
See #23225.
Fix wxUILocale::GetLocalizedName(wxLOCALE_FORM_ENGLISH) to actually
returns the names in English by using the en-US locale for obtaining
them.
Closes#23190.
Co-Authored-by: Lauri Nurmi <lanurmi@iki.fi>
Don't always "succeed" in wxUILocale::UseDefault() and, consequently, in
wxLocale::Init(wxLANGUAGE_DEFAULT), under Unix systems, even if the
locale couldn't actually be set, as it can happen if the environment
variables contain a locale which is not supported on the current system,
e.g. a "mixed" locale such as "en_FR", or even a completely invalid
string such as "bloordyblop", which still used to succeed.
For now only fix it for reasonably modern systems with locale_t support,
it could be done even for the ancient ones without it later too if
anybody still cares about them.
Closes#23218.
This function must be used for setting the default CRT locale only and
we can't request arbitrary locales support from it under Mac as it
doesn't support any kind of mixed locales, such as "en-FR".
We do support them in wxUILocale, and calling wxUILocale::UseDefault()
from wxLocale::Init(wxLANGUAGE_DEFAULT) actually worked, but then this
function failed because wxSetlocale(LC_ALL, "") did not work for such
locales.
Fix this simply by removing Mac-specific code from this function.
This makes wxLocale::Init(wxLANGUAGE_DEFAULT) work as well as it ever
can under Mac.
Use [NSLocale systemLocale] instead of trying to create a locale with
the name "C" which just fails and doesn't create any NSLocale at all.
If nothing else, this makes the behaviour of wxUILocale::GetCurrent()
consistent on all platforms as its GetLocaleId() now returns "C"
everywhere.
This function replaces the existing GetSystemLocale() as it can
represent the locales that don't have any corresponding wxLanguage
values and for which GetSystemLocale() has no choice but to return
wxLANGUAGE_UNKNOWN.
After the changes of the previous commit, GetSystemLocale() started
returning the language, found as due to the fallback logic implemented
in FindLanguageInfo(), for mixed locales, e.g. it would return English
for en_FR which is wrong as the actual locale is rather the French one,
using decimal comma and not period in this case.
Make it always return wxLANGUAGE_UNKNOWN for the mixed locales for now.
When looking for the language information, we must recognize the
language independently of the region it is followed by, so en_FR is
still English and fr_DE is still French, even if the full locale is
unknown, but this wasn't the case before.
Fix this by comparing the language part of wxLanguageInfo with just the
language of wxLocaleIdent we're trying to match, instead of comparing it
with its full BCP47 tag, which is never going to match.
Previously, if LANGUAGE was set, the other locale-related environment
variables (LC_ALL, LC_MESSAGES, LANG) were simply ignored, which seems
wrong as the user running the program after explicitly setting LC_ALL
expects it to use this locale and not en_US from the default value of
LANGUAGE on a typical Linux system using English.
So handle LANGUAGE as a source of supplementary information, but still
honour all the other environment variables. This goes against an
explicit GNU gettext manual recommendation, but this recommendation
seems to only make sense in the usual case, when the first element of
LANGUAGE is the same as LC_ALL/LANG value, but not when they differ.
See #23146.
At least under macOS it fails when the system locale is something like
en_DE, for example, as setlocale() doesn't support such locales.
Use wxUILocale::GetSystemLanguage() instead of wxLANGUAGE_DEFAULT.
Check if using Init(wxLANGUAGE_DEFAULT) is going to succeed by actually
calling wxSetLocale(LC_ALL, "") in this special case, as we can't if
it's going to work otherwise if we don't recognize the language.
The wxUILocale function really returns the default language unlike the
one in wxLocale which must kepe using the default locale for
compatibility, making its name confusing.
This can be useful to compare the results of calling
wxUILocale::GetSystemLanguage() and the function with the same name in
wxLocale (which actually corresponds to wxUILocale::GetSystemLocale()).
Explain that we need to call our (i.e. wxLocale) GetSystemLanguage()
here instead of letting wxUILocale::GetLanguageInfo() call its own (i.e.
wxUILocale) GetSystemLanguage() which does _not_ do the same thing.
No real changes, just try to explain this confusing code better.
As we don't call IncreaseSizeForText() in the ctor any longer, redo the
same check there too.
Also prefer using GetClientSize() to GetSize() for determining the
available size, the difference is not big, but the former is more
correct.
This is identical to 44e9218e03 (Don't always increase height in
DoGetSizeFromTextSize(), 2023-02-02) for wxGTK and ensures that we don't
make the returned height too big when a valid height is specified on
input.
