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>
when it comes to KFileMetaInfo its bottleneck is determening what plugin to
use for the given URL/path - determening MIME type, matching globs, etc.
and it still is quite fast to the point where the flags are simply
redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
in the original KDE implementation it was used along with Nepomuk,
but Nepomuk support was dropped yet some semantic URIs are still
used across the KDE applications (e.g. dolphin, gwenview) for
info other than size, date of modification, etc. thus keeping a
local static mini-hash for the kfileitem properties is not very
good as knfotranslator has its own hash mechanisms thus the
translator items got merged into the translator and is now fully
utilized hopefully dropping the memory usage a little bit of the
metadata provider.
