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.
The year is now included in the copyright string used in the makefiles
and so they need to be regenerated every time the year changes (which
happens surprisingly frequently).
It would be better to define a single variable with the year number to
avoid having to do this in the future.
Using a const char* and a wxString in the two branches of the ternary
operator resulted in compile-time errors since the result type of the
conditional expression was ambiguous, so add explicit conversions to fix
it.
Closes https://github.com/wxWidgets/wxWidgets/pull/2634
See #19355.
For some reason, we used "vc_x64_lib" as the output directory for the
libraries, but "vc_mswu_x64" as the output directory for the samples.
Place the arch suffix, i.e. "_x64" part, always after the compiler
prefix (possibly including version), for consistency with both the
library output directories and with MSBuild project files, as
build/msw/wx_setup.props uses $(wxCompilerPrefix)$(wxArchSuffix)_...
as wxIntRootDir value.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
Remove this bundle key from the generic Info.plist files as it's not
really useful there because none of our samples except "internat" is
localized.
So just add a special Info.plist for this sample and add values
corresponding to all the languages for which we have translations to its
CFBundleLocalizations.
This is more convenient than having to open the "About" dialog to see
the details of the locale being used.
It also makes it unnecessary to store wxLocale reference in the frame
class, simplifying the sample code.
Getting this dialog all the time is annoying when testing, so add
another command line option to set the locale unconditionally.
This commit is best viewed ignoring whitespace-only changes.
It makes more sense to skip loading the translations too, if the user
decided not to use the current locale.
This commit is best viewed ignoring whitespace-only changes.
Creating the controls directly on wxFrame is not recommended and looks
ugly under MSW due to the wrong background being used, so add an
intermediate panel.
This provides a more convenient way of testing wxLANGUAGE_DEFAULT than
selecting it from the dialog shown on startup.
This commit is best viewed ignoring whitespace-only changes.
Simply remove the not existent any longer shared-ld-sh from clean
targets in all makefile.
This should have been done in e663d9af2b (Stop using shared-ld wrapper
script under Mac, 2021-07-06).
Actually test using the coreutils catalog, as this was broken for many
years due to using a wrong catalog name and not adding /usr/share/locale
as a search prefix, but went unnoticed.
So add a menu item to show translation of a string in this catalog to
make testing that this works simpler.
This is more clear than testing for Linux and will allow enabling this
code under other systems later (as there doesn't seem to be any real
reason not to do it under other Unix systems too).
No real changes.
There is no need to suppress wxLog messages from AddCatalog() because it
doesn't log any errors even if the catalog is not found, while tracing
messages (given only if WXTRACE is set) from it can be useful.
What used to be called "fileutils" is called "coreutils" since many
years now, so use it to demonstrate loading of the standard catalog.
Closes https://github.com/wxWidgets/wxWidgets/pull/2395
As shown by the fact that no other platform-specific translations were
ever added since the initial version of locale/msw/it.po added way back
in 4d931bcca0 (Translate '&Help' to '&' for italian Windows only,
2005-08-12), this is not especially useful, so just handle this
particular case specially in wxGetStockLabel() and remove support for
platform-specific translations.
This allows to simplify the makefiles and the catalog loading code as
there is no need to deal with the files in subdirectories any more.
Surprisingly, we had Georgian translations for the internat sample, but
not for wx itself.
Extract a couple of strings that were present in the sample catalog for
the string defined in wx into the main catalog for tidiness.
This allows to reuse "&File" translation already available in wxstd
catalog rather than translating it again in the sample catalogs for all
languages, so remove the now unnecessary translations from them.
All still supported versions of MinGW/Cygwin provide w32api.h file, so
there is no need to test for it.
This allows to simplify the code, but also remove the definition of
HAVE_W32API_H from bake- and makefiles and this, in turn, allows to get
rid of extra flags in MinGW format entirely, as we don't support gcc
2.95 for which they were originally needed neither.
Put linker flags determined by configure after -L$(LIBDIRNAME) option
pointing to the directory containing the libraries being built, to
ensure that we link with these libraries rather than any wx libraries
globally installed in the system, as could be the case since the changes
of ec091c9f2b (Don't override CFLAGS etc in configure-generated
makefile, 2020-02-02).
See #18729.
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under
user-control and putting configure-determined options in them broke
something as simple as running "make CXXFLAGS=-Wno-some-extra-warning"
because this overrode the CXXFLAGS set by configure and required for
build.
Improve this by using WX_*FLAGS in the generated makefile and leaving
the user-controlled FLAGS alone. This is still not ideal as running
"configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both
FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it
on make command line won't override it, as it should, but this should be
a much more rare and also much less severe problem, so we should be able
to live with it for now.
Normally this commit shouldn't result in any user-visible changes, i.e.
it shouldn't break any previously working scenarios and only make some
previously broken ones work.
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
