https://bugs.kde.org/show_bug.cgi?id=340982
--- Comment #284 from Kevin Kofler <kevin.kof...@chello.at> --- The historical and technical reasons of why things are the way they are have been explained several times in this bug report, and I think that, even if it was apparently news to at least one commenter here, most people here already *know* all this. However, let me point out that: * When kdelibs was split into several independent Frameworks, KLocale could easily have become one of those Frameworks instead of getting dropped in favor of the less capable QLocale. That would have allowed KDE applications, or any Qt applications willing to accept one KDE Framework as a dependency, to retain the added flexibility of KLocale. * Even now, it is not too late to reintroduce a KLocale Framework, either resurrecting and porting the original KLocale code or rewriting it from scratch, and getting Plasma and those KDE Applications (be they Gear or Extragear ones) that display dates and/or times to use it. Third-party Qt applications will then likely follow if they care at all. * Considering that users are expecting features that KLocale provided and that neither QLocale (Qt/ICU locales) nor POSIX/glibc locales are able to provide, it should be obvious that deprecating KLocale was a mistake and that it needs to be resurrected *now*. This issue report has 133 users on the CC list, 19 duplicates, and 283 comments. This makes it clear that this is a priority for your users. * Consistency with GTK and other non-Qt applications is a worthwhile goal, but *not* if it means to be limited to the "lowest common denominator" (the intersection of 2 hardcoded lists of locales, one in glibc and one in ICU, which are both neither extensible nor configurable by the end user). -- You are receiving this mail because: You are watching all bug changes.
