QLocale::name() concats strings while QLocale::language() returns the value
of internal private member thus there will be less memory allocations
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
kcalc is no more, the plasma applet (which i rewrote too) is there for such
things. for complex operations there is the plasma (krunner) plugin
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
that means to get the translations linking to solid library or calling
KGlobal::locale()->insertCatalog("solid_qt") is required
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
for that to work what KConfig expects (the language only) has to be first
in the list, otherwise KConfig returns entries that are actually not in the
set locale (go figure)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
as noted in de7070d2bb having multiple
languages and matching the correct one for each use case will have to be
tuned
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
default as in no explicit language has been passed as argument to KLocale
and the language comes either from config or the environemnt variables
with this change KCalendarWidget properly adapts to KLocale config change,
however other applications and widgets may not which is something that has
to be looked into. note that logout is (and was before the KLocale rewrite
even) recommended by the locale KCM for the change to fully take effect
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the test case for this is in a KSignalPlotter test, see:
kde-workspace/libs/ksysguard/tests/signalplottertest.cpp
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
beware that bad things will happen if the input strings are not in one of
the formats KLocale::formatDate() and KLocale::formatTime() output
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
e.g. "bg" for "bg_BG", the default locale is special case for that method
too because of expectations in other places (such as KConfig, KMimeType
tries to match all of the languages returned by KLocale::languageList()
which is how it should be done but that is for another commit)
that is essentially the last bit to bring it back to a compatible state
with the previous implementation, except now more locales are supported
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>
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>
the catalog name argument is unused, KCatalog should be public if
translation from specific catalog is required
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
these seems unnecessary because QString::fromLocal8Bit() is used
if the function is not overriden, though some sorta UTF-16 support
is suggested in the internal functions I have no trouble creating
files with UTF-16 characters in theirs names and working with
them. if there are any complaints on this it shall be reverted
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
