Add support for overriding GetPreferredUILanguages() return value by
setting the WXLANGUAGE environment variable to a colon-separated list
of desired languages (same as GNU's LANGUAGE variable).
Primarily used for unit tests, but may be more generally useful.
Implement wxUILocale::GetMonthName() and wxUILocale::GetWeekDayName() in
wxMSW, wxGTK, and wxOSX.
Also extend the existing wxDateTime methods to support a 3rd month and
weekday name representation (Name_Shortest) and a usage context
(Context_Formatting and Context_Standalone).
These changes make wxDateTime methods for getting the localized date and
month names use the current UI locale, as set by wxUILocale, instead of
the current C locale set by the standard C library function, which is a
change in behaviour but a desired one and notably fixes the display of
the months in generic calendar control in wxOSX where the current C
locale is not changed when the UI locale is set.
Replaces #23551.
Closes#23191.
Adjust the code to check for Windows sort order only after the last
underscore (instead of the first one).
This avoids misinterpreting locale tags like "zh_Hans_CN".
For wxOSX return "C" from GetName() for "en_US_POSIX" which is now
used as the standard "C" locale.
Also handle special locales "C" and "POSIX" properly in
wxLocaleIdent::FromTag().
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.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
The script part of a locale tag was incorrectly parsed due to a wrong index in the calls to `wxString::Mid`. This resulted in shortened script tags that couldn't be interpreted anymore.
Restore the old behaviour of wxLocale, which is supposed to use the
default locale and not the preferred language, which may not be the same
(see #22281).
Also apply the following fixes and improvements to wxUILocale:
- Add new GetSystemLocale() method.
- Change the MSW implementation to use the default locale instead of the
preferred UI language for Windows versions below Windows 10.
- Change the Unix implementation to respect LANGUAGE environment
variable and use it for determining the preferred UI languages.
- Use wxUILocale in wxTranslations to determine the preferred UI
languages.
- Use wxUILocale during initialization of internat sample.
Closes#22281.
Closes#22318.
Recognize strings returned by setlocale() when using MSVC under MSW too,
if only because it was possible to construct wxLocale using them in the
previous versions and so doing this avoids breaking the existing code.
Also don't assert in FromTag(), even if the input is incorrect, as it is
potentially user-defined (e.g. can come from environment variables under
Unix).
Closes#22247, #22252.
Many improvements and fixes to wxUILocale:
- Add wxUILocale method for retrieving wxLocaleIdent identifier,
localized names, layout direction.
- Add wxLocaleIdent attributes, getter, and setter for
platform-dependent tags under Windows: extension, sort order.
- Modify method wxLocaleIdent::FromTag to support not only BCP 47-like
tags, but also platform-dependent syntax.
- Modify method wxLocaleIdent::GetTag to allow specifying the tag type.
- Update internat sample to better show using wxUILocale.
- Update German and French message catalogs for internat sample (German
fully translated, French msgIds only).
- Introduced wxUILocaleImplStdC under Windows, because locale "en-US" is
not equivalent to the C locale.
- Adjust wxLocale class to restore previous wxUILocale in the
destructor.
- Implement wxLocale::GetInfo method through wxUILocale methods.
- Removed LCID dependency in wxLocale.
- Move the implementation of some static wxUILocale methods from
intl.cpp to uilocale.cpp.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Closes#2615.
There doesn't seem to be any reason to disallow copying these objects
and because they only have const methods, we can use reference counting
for them without bothering with copy-on-write, so it's simple to
implement.
This static function parses a subset of the language tags described in
BCP 47 (see https://www.rfc-editor.org/rfc/bcp/bcp47.txt).
Use the tag, as specified by this function, rather than the locale
identifiers components under MSW, where this should allow us to use even
locales that can't be described using just language-script-region.
No real changes, just don't make all wxLocaleIdent setters inline, this
is not necessary as none of these methods are performance-critical.
This commit is best viewed with --color-moved git option.
This is required for wxLocale compatibility, as using wxLANGUAGE_ENGLISH
is supposed to be the same as using "C" locale (even if it isn't,
really) at wxLocale level.
This function can now be implemented relatively straightforwardly
(although it does require an extra check under Mac), so add it, as it
can be generally useful and we're also going to need it for our own
tests in the upcoming commit.
This finally seems better than always creating some kind of impl object,
even if the locale isn't supported at all and makes all ports behave
consistently, as previously CreateForLocale() only returned NULL in
wxOSX implementation if the locale was unrecognized, but now all ports
do this (at least when locale_t and related functions are available
under Unix).
Also stop returning bool from Use(), as this resulted in initializing
wxLocale with any non-default language to fail under Mac: just ignore
the error here, as we always did it until now, because there is nothing
we can do about it anyhow.
This required changing CompareStrings() to be a method of wxUILocale
object, rather than just as a static function, as we must only allocate
the locale_t object once, and not during each to this function, as this
could make it unusably slow when using it as a comparison function when
sorting a large list of strings.
This is also more efficient under Mac, where we can similarly allocate
NSLocale only once and even marginally more efficient under MSW, where
we don't have to construct the locale string during each call. And,
under all platforms, it also simplifies code by separating this function
implementation from the initialization of wxUILocaleImpl.
Also document that case-insensitive comparison is not available under
Unix and adjust the tests accordingly.
Creating such objects (without using them for the UI) is supported under
all platforms, so allow doing it.
Note that this is only supported under Unix systems when locale_t and
related functionality is available, but this should be the case just
about everywhere by now.
Add a test (or, rather, replace an existing test which was disabled by
default) checking that we can now get locale information about any
locale, not necessarily the currently used one.
Add Use() virtual function which can be used if the newly created
wxUILocaleImpl object should be used as the default UI locale.
Currently Use() is always called after creating a new wxUILocaleImpl, so
adding a separate function just seems to complicate matters needlessly,
but this won't be the case any more soon, when wxUILocaleImpl could be
created for using them for other purposes than making them the default.
No real changes yet.
This is tidier than using #ifdefs in the same common file and also
ensures that initializing wxLocale affects wxUILocale too, which will be
important for compatibility when the code elsewhere is modified to use
wxUILocale::GetInfo() instead of wxLocale::GetInfo() in the upcoming
commits.
This commit is best viewed with --color-moved git option.
