- Transifex tools complain about missing Q_OBJECT (which makes
some sense -- you end up with a different context for calls
to tr(), of the base class).
Move some of the texts to the new TranslationFix, from ViewManager,
and use them. Keep them in ViewManager, too, so that the translations
with context ViewManager are not removed just now.
This is intended to apply translations to some common Qt UI components.
Example: a QMessageBox with standard buttons OK and Cancel; the text
for that is determined at startup using the system locale, and later
changes to the current locale or the current translation catalog,
do not affect OK and Cancel. It might be possible to load a catalog
with the right translation strings, except that there is no way to
know what the context or catalog **is** for the strings that are
used to label standard buttons: they can come from Qt base, or
the platform, or the theme. Merely loading the Qt Base translations
for the correct language does not help, because those translations
do not contain an "OK" string with the context used for standard
buttons.
Do the translation by hand; then we have all of the Calamares
languages covered, too, which is more than the Qt translations do.
Move the CMake code responsible for building the translations from
the src/calamares directory (yeah, yeah, the translations need to
link into the executable) into lang/ (which is where the source
and other infrastructure lives).
Prompted by Linlinger, I've reconsidered the names of languages
in the drop-down in the welcome page. We already have the
infrastructure for assigning specific names / locales to
"Calamares locale names" (which match Transifex names, not
necessarily Qt names). Use that to put exactly two Chinese-
language translations in the drop-down:
- Simplified Chinese (code zh_CN)
- Traditional Chinese (code zh_TW)
Drop zh (which is a peculiar locale name anyway) and zh_HK
(which is Traditional Chinese, but using the geographic
boundary is a bit weird; we're going to ignore the
minor orthographic differences with Traditional Chinese
written elsewhere for now).
Note that this makes the drop-down show "Chinese"
in the English column, twice; the difference is visible
only in the native-language representation.
SEE #1741
rewrite of keyboardq.qml, reduce stackview to 2, use a combobox for
keyboard models list
colors set to configurable
.xml files used for keyboard layouts, about a dozen added now
builds, runs, actions record as intended, GS filled correctly
With old Qt, Calamares could only run one check on a thread,
because the NAM would be switched to NotAccessible --
subsequent checks would fail because the NAM is already
hard-set to NotAccessible, so it could never be turned back
on by Calamares code.
Reset the accessible flag for the NAM while checking if
the internet is there.
- India (when in English) should use the English variant, not Hindi
- While here, fix up minor items in code:
- Typo in comment
- Asturian doesn't need a special case (which didn't match, anyway)
- Don't debug-log a country-name that might be entirely wrong
(the layout is English, variant "in" but "in" interpreted as
a country is Indonesia, and the actually-desired name is eng_in
which isn't a QLocale name at all -- just like the Hausa and Igbo
special cases)
The test was loading the config file (for testing) either from the
build directory or possibly the source directory; if the config
in the build-dir was edited (for other testing purposes) then
the test would fail. Load only the source-dir version of the file.
- improve logging
- fix failing tests -- the observed and expected behavior is
to fill in a fallback check-URL, not change to an empty list,
- **except** if there's no requirements key in the config
at all; this is a bit weird, but let's make the tests
document existing behavior so we can notice if it changes.
