Most of the code in this function was Unix-specific and didn't make
sense for Mac, where we never have to apply the workarounds in it nor
deal with languages specified without the territory etc, so separate Mac
branch using CoreFouundation API from the rest of the Unix code to make
things more understandable.
No real changes.
Using setlocale() is not the right way to do it there, try checking if
the locale is supported by Core Foundation instead of whether it's
supported by the Unix layer which is neglected and not used under Mac.
This code, added back in 420de418ea (workaround for buggy setlocale()
under AIX (without this wxLocale didn't work at all), 2005-09-18), is
probably irrelevant anyhow because AIX 5.2 must not be used any more,
but also seems to have lost its purpose at some time during the
intervening years, as we don't use "retloc" as argument to setlocale()
anyhow, so it is doubly safe to simply remove it.
Make GetInfo() return information for numbers by default in the Unix
version too instead of asserting, as this is more consistent with the
MSW and Mac versions and also seems more useful.
wxTranslations needs the information that user's default language is
used; in particular, it may choose to use a cascade of user-preferred
languages to choose the best UI language.
This was accidentally broken by
18bf718f60 which changed the logic to
fill shortName from the builtin database. This consequently changed
wxTranslations to use only the single detected language and ignore
user's preference cascade.
Closes https://github.com/wxWidgets/wxWidgets/pull/2385
Previously wxLocale object was set as the global local as soon as it was
created, even when the default ctor was used, i.e. the locale wasn't
really changed at all. This was always wrong, but only started to result
in visible problems since the changes of c6d6ec9295 (Merge branch
'msw-fix-decimal-point' of https://github.com/vslavik/wxWidgets,
2021-04-18) as we now could use the existing but not yet active locale
when checking for the decimal separator mismatch, resulting in spurious
asserts.
Fix this by postponing the call to wxSetLocale() and the rest of what
was previously done in the ctor until Init() is called (which is done by
all non default ctors).
Closes https://github.com/wxWidgets/wxWidgets/pull/2350Closes#19154.
wxWidgets may be unaware of the locale being used and may be unable to
get correct information from its languages database. For example, en-AT
locale, supported by Windows 10 and using "," for decimal point, would
be interpreted as en-US by wx, and return "." here.
The other situation, when wx supports a locale that the OS doesn't,
shouldn't make a difference here because in that case, CRT wouldn't
support the locale either and CRT formatting functions wouldn't be set
to use it.
See also somewhat related 9fc78c8167.
Avoid the need for ugly WX_NO_LOCALE_SUPPORT macro at the cost of a
couple of extra #ifs, which seems to be a worthy trade-off.
This also allows making the code calling setlocale("") for the default
language platform-independent.
No real changes.
Even if we do know about the system language, it's still better to let
OS/CRT handle it, as we may not know enough about it. E.g. "system
language" may actually be a mix of the different languages and formats
and we don't handle this case at all, while OS/CRT do just fine.
We must use GetUserDefaultUILanguage() and not GetUserDefaultLCID().
Although still not ideal, this is much better when the UI language and
the locale differ: when everything is in some language, it's better to
use this language and wrong date/number format than use correct
date/number format but a wrong language.
See #11594.
If we can't find an exact match for the system locale in the database,
try to at least find the corresponding language.
This is almost certainly what the intention of the original code was, as
otherwise the entire loop was useless because it couldn't find anything
that wouldn't have been found in the loop just above.
This allows to correctly load German translations when using unsupported
locale such as "de_IT", for example.
See #19082.
Define the function calling setlocale("xx_YY") first and then just
setlocale("xx") if the former failed, instead of doing the same thing
manually in 3 different places.
Also avoid attempting the second setlocale() call completely if there is
no "_YY" part in the first place.
No real changes.
Call the info->CanonicalName "shortName", as it's done in many other
places in the code instead of using "locale" for it here, even though we
do use it as a name of locale.
No real changes.
There doesn't seem to be any reason to partially duplicate Unix-specific
code in a separate Mac branch when we can just use the same code. Parts
of it which are not necessary under Mac, such as trying ".UTF-8" locales
in wxSetlocaleTryUTF8(), can be separately disabled there (even though
they are harmless), but other parts are probably needed, e.g. setting
Norwegian locale failed under macOS before because we didn't translate
nb_NO that we use to no_NO actually supported under macOS.
There is no need to try setting "loc.UTF-8" and "loc.UTF8" when we had
just called wxSetlocaleTryUTF8() which tried these variants and also
their lower-case equivalents already.
* changing datatransfer from CFPasteboard to NSPasteboard API
* factoring and cleaning up
* Switching back naming
* missed file
* getting wxCFStringRef to be independent of system headers
* add unichar include
* using wxCFStringRef in header
* moving to private headers, change method name
* adapting to lesser content in cfstring.h
* Removing malloc/free usage
* use wxScopedArray throughout
* using wxMemoryBuffer instead of char[]
* fixing nonprecomp headers
* missing forward decl in non-precomp builds
Recent versions of Windows 10 (finally!) allow to set up UTF-8 as the
system encoding, so recognize when it is returned by GetACP() in
wxLocale::GetSystemEncoding() and GetSystemEncodingName().
This function could (and did) return completely wrong results because
the value of the pointer returned by setlocale() could be (and was)
changed by the subsequent call to setlocale() with different arguments.
Fix the problem by copying the returned value into wxString immediately,
without any intervening setlocale() calls.
Previously, all MSW-specific stuff like calling SetThreadLocale() and
SetThreadUILanguage() was only done when initializing wxLocale from a
wxLanguage value, but not when using a string name for it.
Fix this by implicitly calling Init(wxLanguage) from Init(wxString) if
we can find the language corresponding to the given name, and if the
other parameter is not incompatible with it.
Don't call wxSetlocale() in DoInit() any more, this was redundant when
it was called from Init(wxLanguage) overload.
Add new DoCommonPostInit() called from both Init() overloads after
setting the locale in whichever way they do it to avoid code
duplication.
As a side effect of this change, the error message given if the locale
can't be set is the same now independently of the ctor/Init() overload
used (previously it differed depending on whether a wxLanguage or the
name of the language as string was passed) and it's always logged using
wxLogWarning() and not it in one case and wxLogError() in the other one.
Simplify the code by just using "retloc != NULL" as success indicator
until the call to DoInit() instead of keeping a separate "bool ret"
variable in sync with "retloc".
Instead of calling wxLanguageInfo::GetLocaleName(), which called
setlocale() at least thrice (first to query the current locale, second
to try to change it and third to restore the original locale) and then
calling setlocale() again if it succeeded, use the new TrySetLocale()
method which calls setlocale() just once and doesn't require calling it
again in the caller.
This makes the code slightly more efficient but, more importantly,
shorter and more clear.
Try to make code less confusing by avoiding defining a variable in
platform-independent part of the code and then actually using it only in
platform-specific code.
Simplify the code by not checking for language == wxLANGUAGE_DEFAULT in
wxLocale::Init(): this can't happen because we use the system language
when passed wxLANGUAGE_DEFAULT as parameter and return false immediately
if we can't determine the system language.
Check if setlocale() really works with the name of the returned locale
and return empty string if it doesn't.
This fixes problem with setting locale when using old MSVC or MinGW CRT
under new (Vista+) MSW versions, as the CRT doesn't support the locale
names returned by LOCALE_SNAME and we need to fall back on
LOCALE_SENGLANGUAGE.
macOS returns "cccc" (stand-alone weekday name) as a part of the
preferred date+time format for Finnish, and possiblly others. This was
not handled at all by wxTranslateFromUnicodeFormat(), and the user
saw the raw "cccc".
Similarly, handle stand-alone month name ("LLLL").
Closes https://github.com/wxWidgets/wxWidgets/pull/518
