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>
the output goes to the TTY and there is no rich text handler there, note
that the plain format for the "email" tag also contained entities (even
before the KuitSemantics reimplementation)
because the plain format for the "email" tag
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
not used in plain context, same as "p" in rich context. also now Katie will
detect the paragraphs as rich text
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
fun fact: there is CLDR data for ~1000 languages and only ~50 use different
number system (not "latn")
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
text with "<" in it is considered as rich text by Qt::mightBeRichText()
as special case. also entities are not markup and shall not be handled by
KuitSemantics (there is a class for that - KCharsets). entity is used
only in one place (kde-workspace/kate/part/view/kateviewhelpers.cpp) and it
does not even need special handling by KuitSemantics. so, instead of
slowing the whole markup parsing with redundant and unused feature I've
decided to not support it and even improve Katie's Qt::mightBeRichText()
function
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
is interesting how much simpler it can be by assuming that the tags are
strict and by using Qt::mightBeRichText() for the rich text detection.
while mostly compatible (entities are not converted, some tags were not
used and some even did not do anything) it is subject to optimization by
using QStringMatcher or other tricks (like using a separate tag for the
numbers precision)
overall - no regular expression matching, no XML parser is used and does
what the old implementation was doing but with less code. also passes
most tests (the exception is KLocalizedString test case that expect
entities to be replaced)
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>
otherwise KLocale::formatNumber() has to guess the precision that was
passed to KLocalizedString::subs() and make up a localized integer string
with a magic wand, the precision for precise number types (e.g. ulong,
qlonglong, etc.) remains -1
fixes KSignalPlotter test case failure
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>
