https://bugs.kde.org/show_bug.cgi?id=340982
--- Comment #317 from Roke Julian Lockhart Beedell <[email protected]> --- Comment on attachment 95059 --> https://bugs.kde.org/attachment.cgi?id=95059 Crude patch to the en_US locale with hardcoded values (In reply to phil4000n from comment #314) Please try to solely comment that which is technically constructive. More philosophical debates should be transferred to KDE Discuss, and mere disparagement has no place here. I realise how long this thread has become, and, thus, that getting a grasp of it is difficult. However, we solely exasperate that problem, if we continue to utilise this bug tracker as a discussion forum. For those frustrated because they don't understand what the holdup is, to summarise what's occurred: - Plasma 5 removed the detailed date/time formatting controls that existed in Plasma 4. The new “Regional Settings” solely allows one to choose a locale (nation), and offered preset formats bound to that locale, rather than fine-grained control over the short date, time order, and separators, etcetera. Choosing a different locale that coincidentally equivalated the desired format frequently modified alternative formats — of which number and currency formats are examples — that the user didn’t want modified. Consequently, the original request was to return per-field customization (ISO 8601 timestamps, which include 24-hour time), or any user-defined string, rather than solely locale-specific presets. - This regression was because Plasma 5 was using Qt’s QLocale, rather than Plasma 4's older KLocale, and QLocale didn’t expose granular customization. KDE developers acknowledged this was an absent feature, but explained that reinstating KLocale (at the least, with its previous implementation) was not feasible. Similarly, remediating this, correctly, would require modifications to Qt’s locale system, or would require a custom system to replace it. However, the best explanation is (as expected, from Nate) in https://bugs.kde.org/show_bug.cgi?id=340982#c210. Based upon its content, I took this issue to the Austin Group chair, who chairs the Open Group's POSIX and UNIX development (before filing at their MantisBT instance). [^1] He explained that a discussion needs to occur on the Austin Group Mailing List, but should be discussed with GLibC at the same time, or first. When I've managed to get around to remediating https://gitlab.com/mailman/mailman/-/issues/1225#note_2577619340, I shall try, if nobody else does, or has. [^1]: https://unix.stackexchange.com/questions/796338/does-any-organisation-standardise-system-management-fundamentals#comment1530070_796338 -- You are receiving this mail because: You are watching all bug changes.
