- Use namespace CalamaresUtils::Locale consistently for this service.
- Move locale-related non-GUI support code from the Welcome module
to libcalamares; these are generally useful. Both Label (naming a locale)
and LabelModel (managing a bunch of those Labels) have been moved.
- This small header file contained a few unrelated typedefs.
Move those typedefs to the classes they relate to. This
**does** mean that some consumers need to #include something
else instead.
- Use type names more consistently.
Editorial: why are **pages** responsible for creating the jobs?
- deprecate the old entries
- use a geoip sub-map for GeoIP configuration
- polish up documentation
- drop mention of blank and "legacy" styles for GeoIP config,
just update your URLs already.
- Use only utils/YamlUtils.h to pull in yaml-cpp and supporting code.
- When compiling with clang, turn off warnings that the system header
for yaml-cpp would generate.
- These methods are used for multi-page view-steps, which are rare.
For all the others, just drop the empty implementation and defer
to the base class.
- The language and BCP need to be in-sync
- Existing code was inconsistent in setting things, which is why
you could get through the locale page without setting a locale
(at all) or it would keep English in spite of picking Germand on
the welcome page.
- Patch tests to use that API.
- Allow split-setting of the language and formats
- Test new constructors
- Since fromLanguageAndLocation can handle empty localeGen
lists just fine, skip all the weird checks that return
invalid guessed locale configurations.
- Replace createDefault() with a constructor that takes a
locale name; use it with en_US.UTF-8 in those places where
createDefault was previously used.
This basically means we talk about localization in the respective
localized variant. e.g. "German (Germany)" ➡ "Deutsch (Deutschland)".
If geoip lookup failed or isn't configured for whatever reason it's a
stretch to expect the user to know english enough to find their own
language. Preferring the localized strings resolves this issue.
Additionally this happens to bypass #712 respectively
https://bugreports.qt.io/browse/QTBUG-34287
as the native names are properly spelled. So, as long as Qt has localized
names the names will also be properly spelled.
- In many cases, using QLatin1String is a de-optimization, when
applied to a C string literal. Kevin Kofler pointed out that
those should basically all be QStringLiteral, instead. (Compile
tests with -O3 show that in the optimized object file, the
code size difference is negligible).
- Drop the explicit constructor entirely in cases where we're calling
QProcess::execute(), for consistency.
- Do a little less messing around in the mapping of keyboard locales
to keyboard map names.
- Fudge the numbers in the North, to improve location
of the pins and lines of latitude.
- Inuvik, Yellowknife, Cambridge Bay, Resolute look ok
- Thule, Scoresbysund look ok; Danmarkshavn a pixel or so too far North
- Reykjavik is a bit too far North
- Longyearbyen is a bit too far North
Since these places are off by one or two pixels, this becomes
invisible when a large pin + text label is placed on it.
The scaling on the map was a little off; the degrees of latitude
are a little wider there than around the equator and Europe.
- Johannesburg is in the right spot
- Hobart is no longer a suburb of Melbourne
- Punta Arenas is in Chile
Replace pin and text label with just a dot (to pinpoint where
locations are) and draw latitude lines on the globe when
DEbUG_TIMEZONE is set at compile time. Since there's probably
still timezone-related bugs (in particular in the images that
map points on the globe to timezones), leave this in the codebase.
- Since these tests use network resources, they are not enabled by default.
Set the environment variable TEST_HTTP_GET to actually do them.
- Do one request for each provider and check that they are all consistent.
(This works for me, yielding Europe/Amsterdam for all).
- Some providers don't provide a single flat JSON object
(e.g. "{time_zone: foo}") but a nested structure
(e.g. "{location: {time_zone: foo}}"), so allow dots
in the selector to do multi-level selection.
- Some providers return weirdly escaped data; strip out useless
escaping before splitting (there are no characters in correct
time zone names that need escaping)
- Add some tests for TZ splitting
- In GeoIP handler constructors that take a string (to configure the
selector to use), interpret the empty string (which generally isn't
a meaningful selector) as meaning "use the default".
- Drop the no-argument constructors in favor of a default-argument
which is empty.
- GeoIP gets a string selector; the interpretation is up to derived classes.
- GeoIPXML and GeoIPJSON use the selector to select an element by tag
or an attribute, respectively.
- The handler for JSON data should be called that, not named
specially after the original provider it was implemented for.
- Make filename and classname consistent, GeoIPJSON.
- Unchanged config files will continue to use the weird addition
of /json, and interpret JSON data.
- Allow to specify full URL with data format through one of
geoipStyle: json
geoipStyle: xml
- XML support is optional
- Make the BCP47 value explicitly lower-case.
- Add some constness and encapsulation.
- Fix up documentation in the packages module explaining the
format of the ${LOCALE} replacement (now forced to lower-case,
but it is also only the language part, not e.g. en-UK).
FIXES#922
