- Allow TranslatedString to get a context parameter; if it has
one, it will try to use the regular tr()-infrastructure
**as fallback** for the translations from the config file itself.
- This makes it possible to offer -- and translate -- some "standard"
phrases in the module, while allowing the config file the knob
to change strings. Using one of the standard strings gets translations
for "free", while introducing something entirely new means sourcing
translations for it as well.
- don't have a NOTIFY CONSTANT property
- the data is constant, so drop NOTIFY
- remove redundant signals
- remove setLabels() now it's only needed from one constructor
- Hide the one file from lupdate by giving it a weird suffix
- Call lupdate a second time for the timezone translations
- While here, adjust so that the options precede the directories
they are supposed to affect
I don't want to give the translation teams 444 new strings all
at once (about 90% of which don't need translation).
- search for a key and return a type-cast pointer to the result
- while here, simplify some other code
- the find() function could be done with std::find_if but doesn't
get any shorter or more elegant
- By using QList< CStringPair* > consistently, we can save
a bunch of model code at the cost of an occasional dynamic_cast;
it's fairly rare for there to be a need for the derived pointer.
- read the file and create the regions on-the-fly, then sort the
resulting list (instead of building a string list and then
building the regions afterwards)
- Massage the implementation a bit, don't insert a meaningless
copy of the key as the untranslated message.
- Add isEmpty() to check for presence of the untranslated message.
- Document API.
- Update tests.
- The tests should be run in C locale, otherwise the plain get()
function uses the current locale, which will fail (e.g. running
LANG=nl ./libcalamareslocaletest returns the Dutch strings for
plain get, which isn't what we expect).
- sr@latin is still special.
- While QObject::tr and gettext give us translations **most** of the
time via the translation mechanism, we sometimes have strings
embedded in configuration files that need to be shown to people
as well. Follow the .desktop style in handling this.
- A key's value **might** be translated; use `key[lang]` for the
translation into one of the languages that Calamares understands.
Code that expects a translated (human-readable) string in a configuration
file can use TranslatedString to collect all the translations of a
given key, so that it displays the right string from the configuration
when needed.
- Minimal tests just check that all the availableTranslations()
entries have a reasonable language setting.
- Checks that Esperanto is still broken as a locale in Qt.
- The static destructor issues a warning on exit:
QBasicTimer::start: QBasicTimer can only be used with threads
started with QThread
so instead, heap-allocate the model. This leaks memory, but
it's a singleton *and* we're exiting anyway.
- Declaring namespace A::B is a C++17 extension, and Calamares
is C++14. Split the namespace declarations.
- While here, fix extra const warning as well.
- Which translations are available is a global property
of Calamares itself, not of the plugins, so getting
the model of available translations should live there.
Move the relevant code (which is simple) from the
Welcome module.
- 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.
- Lookup country data based on enum or 2-letter code
- No data yet, so return only stubs
- The (generated) data tables are not listed as sources because
they are #include'd by the API implementation; they're full of
otherwise-unused static tables, so don't make sense to compile
separately.
- While here, tidy up the CMakeLists a bit to reduce the number
of superfluous variables.
- Continuing the notion that libcalamares should provide
(non-GUI) services for modules, add a locale service.
- This will, unfortunately, roughly duplicate Qt's QLocale
database, but in a form that is public and more readable.
