note that it does not change the locale language (yet), nor does is affect
it. it changes the translation language(s) - two different things!
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
also adjust KLocalizedString test case, "Job" is no longer translated
string in the source code thus not in the french translation
on a side note there are KLocale tests all around - KLocalizedString, KIO
tests, etc. so perhaphs only quircks should be tested by the KLocale
specifiec tests
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
while the threads are running the kdelibs4 catalog may or may not get
removed resulting in a race and different results in the functions (if
the catalog is not there there will be no translation but the test
functions expect it to be translated when french translations are
installed)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
people really messed up the precisions, look at what kcalc does with the
constants:
kde-extraapps/kcalc/kcalcdisplay.cpp
zero precision is essentially rounding the constants! also setlocale() no
longer has effect on Katie and thus Katana so updated the method to
override locale in KLocalizedString test while at it (tests pass after one
adjustment for the french locale case)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
to be rewritten. date, time, days, etc. translation and conversion work
like a charm tho (when translated and supported by the locale classes
ofcourse):
https://ibb.co/hcW0dL3
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
much like the old (and now gone) KLocale::prettyFormatDuration() except
with miliseconds precision instead of days
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using QLocale in KLocale and separating the date, time and numbers
conversion from translation KLocale actually gets extended locale
support from QLocale (which uses CLDR data v43 currently). translation
remains unaffected. for comparison here is the result of two function
calls the result of which should explain the whole change:
KLocale::allLanguagesList().size() = 669
KLocale::installedLanguages().size() = 68
the first number is locales Katie supports, the second being the
number of languages Katana is translated into
KSwitchLanguageDialog needs a rewrite but that is on the TODO
also copyrighting KCatalog to me because I rewrote it, for reference:
881b47b8ea
KCalendarSystem gets the middle finger - batteries not included for date
and time. extra calendar systems can, but are unlikely to be, supported
in the future
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
additional calendar systems can be supported via ICU in the future but
for now that will be more than enough considering other things such as
QDateTime and QCalendarWidget, the gregorian and julian calendars being
common, etc.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
what that does - the general application color scheme applies to the native
widget and any Plasma::Theme overrides are applied on top of that making it
slightly less native looking and more plasma-themed.
also that allows to not just hide the calendar month button but disable it,
the colors for disabled widget as slightly lighter than the usual color
scheme so its not a big difference visually with that change
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
interestingly QLocale is not used for many things but that is about to
change, Katie uses it a lot internally (e.g. for QDateTime formatting
and such) so instead of bolting a calendar system on top of KLocale
perhaps a QLocale wrapped around in KLocale will fit the general idea
of using QLocale in widgets when necessary (as does QCalendarWidget).
that however means no way to specify a calendar system (in general,
other than changing the widgets locale itself) but the QDateTime and
related classes are tied to gregorian calendar already - the system
time itself carries no information about the calendar and any
conversions from one calendar to another are basically made up stuff
(there is the time zone thing ofcourse but that is not a calendar)
another interesting thing to note is that KLocale was written such that
it is read-write - changing the date formats for example is possible
because there are public KLocale methods for that.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
this was not done in the previous implementation but it is now, it will
allow to detect tzdata changes and fallback to UTC in the plasma time
data engine during system upgrades for example. that ofcourse is only
theoretical and preperation for worst-case-scenario type of situation but
good to have anyway
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>