Summary: | The date/time format of the LC_TIME locale is not regarded | ||
---|---|---|---|
Product: | [Applications] krusader | Reporter: | Peter Thoemmes <peter.thoemmes> |
Component: | general | Assignee: | Krusader Bugs Distribution List <krusader-bugs-null> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | krusader-bugs-null, nikita+kde, peter.thoemmes, piny |
Priority: | NOR | ||
Version: | 2.7.1 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Peter Thoemmes
2018-11-12 09:50:46 UTC
Pls forgive me the typo. The summary should be... The date/time format of the LC_TIME locale is not regarded. Assuming that Krusader uses Qt to format date/time strings: The Qt library uses the CLDR data to map locale identifiers to format strings. As far as I know, the en_DK locale is not in the CLDR database. https://unix.stackexchange.com/questions/62316/why-is-there-no-euro-english-locale has more information, including: 'The name "en_DK" is sort of a joke...' Related: bug 340982 and (invalid) https://bugreports.qt.io/browse/QTBUG-35692 So do I get this right... In case I use the time locale "en_US.UTF-8" (to avoid en_DK.UTF-8), and then manually edit /usr/share/i18n/locales/en_US to make the date/time representation of "%x %X" becoming ISO, then Krusader still don't care for the system settings, but simply does its own ***HARDCODED*** thing, while all the rest of the system regards my system-wide LC_TIME settings??? STEPS TO REPRODUCE: # vi /usr/share/i18n/locales/en_US ... % Appropriate date representation (%x) %d_fmt "%m//%d//%Y" d_fmt "%Y-%m-%d" % % Appropriate time representation (%X) %t_fmt "%r" t_fmt "%H:%M:%S" ... # vi /etc/environment ... LC_TIME="en_US.UTF-8" ... # locale-gen # date +"%x %X" 2018-11-14 09:25:20 OBSERVED RESULT: Krusader does not regard LC_TIME EXPECTED RESULT: All applications should regard the LC_TIME settings Yes. The CLDR database has more information than provided by the POSIX interfaces, so Qt developers decided to implement QLocale using an internal copy of the CLDR data. It is possible to overwrite classes like QTableWidget and handle the format of the 'modified date' column according to kdeglobals, as it was before in Krusader (2.4.0 beta1)... $ vi ~/.kde/share/config/kdeglobals ... [Locale] DateFormatShort=%Y-%m-%d TimeFormat=%H:%M:%S This was very handy and platform-independent as well? Easy and handy sorting by the 'modified date' column is essential for file managers. Krusader is such a handy software - so those little, but very much helpful things would be a brilliant enhancement. The ~/.kde/share/config/kdeglobals was not platform-independent. It was supported by custom logic in KDE4 libs (KLocale class), AFAIR. https://community.kde.org/KDE_Core/KLocale#Qt5_.2F_KDE5 > Using KLocale (and thus KConfig) is a major barrier to Qt-only apps adopting our libraries so we should try remove the need for KLocale where-ever possible. Much can be achieved by pushing KLocale features into QLocale and ensuring QLocale fully supports all options common to all the platforms (some options are still not supported, or are only properly supported on some platforms). So we migrated to QLocale during KF5 migration. I agree that system setting should be respected in Qt (in case not explicitly overridden). Please open a bug in Qt bug tracker and reference it here. |