On Plasma 4, I could go to System Settings > Locale (I think), and change specifics on my short date and time. It seems on Plasma 5, System Settings > Regional Settings > Numeric, Currency and Time Formats the settings for short date and time are set by Country. I would like to keep my country as-is, and change those detailed settings. Is that possible with Plasma 5? Reproducible: Always
I can confirm this. YYYY-MM-DD is defined as the international standard in ISO 8601 and ought to be easy to find. To set your locale to use ISO 8601, you have to set LC_TIME=en_DK. This does the trick for some applications, however, not for KDE (Plasma 5 and KDE applications). Neither can I find en_DK in Regional Settings under "Time". Please make KDE respect the system locale.
There are other settings missing too. It is a MUST to be able to change the ISO date, metric system, customize decimal separator for convenience. I'm Polish and I can't stand Polish translation so I use en_US, but I can't stand middle-endian date, so I set ISO date and 24H time. Then I want to use EUR as the currency. I miss KDE 4 settings. KDE5 has to have advanced settings.
I agree that this is needed. My use case is that I want ISO 8601 date (yyyy-mm-dd) with 24-hour time in the panel clock, which I'm able to do in Plasma 4.
On the current KDE (4) in F21 one can go to "System Settings --> Common Appearance --> Locale --> Country/Region" and separately set the format of "Numbers", "Money", "Calendar", "Date&Time" and other things such as page size. Now, with Plasma 5 there is a "Personalization --> Formats" section but I can't seem to find a way to set the Time Format to HH:MM:SS such that AM/PM isn't displayed and I get the time in the clock in 24hr format. I could set it to UK, but being originally from the US I'm used to MM/DD/YY not DD/MM/YY as the UK has it. So, my work around is to create .bashrc settings for LC_TIME. There are other settings which are configurable in KDE 4, but no longer the option in KDE 5. Loss of functionality is normally as step backwards.
Please note this is a missing feature and must be implemented ideally on Qt's side
This is a regression resulting from the switch from KDE's powerful locale and formatting classes to the inferior Qt-only ones, as part of the Frameworks initiative (that aimed at reducing interdependencies between KDE classes so that KDE can now ship a bazillion small "Frameworks" instead of a single coherent kdelibs framework). Sadly, loss of functionality was not considered a blocker for any of those K*→Q* ports.
Created attachment 91725 [details] 132 DPI KF5.8 locale's "Time" select list screenshot This shows that there's really no way to find out from within systemsettings even *if* a desired format is available. The unwieldly populous select list is not alpha-sorted, has no preview of any selection, and has no apparent offer of the ISO 8601 format that isn't tied to any particular locale.
Just loaded up Kubuntu 15.04 and ran into this. This in my mind is a pretty big frustrating regression from user convenience point of view. Nobody wants to see their clocks or currency or decimals in a format other than what they expect. Some countries even have multiple standards due to regional/language differences... Canada's got its own Wikipedia page on it! http://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada More importantly, your preset drop down solution is - as Felix stated - poor. Nobody should have to scroll through that list in 2015 to get a desired format, it is way too long. Love KDE and appreciate the work of the devs, but this needs to be fixed and if that means bringing back KDE's complex classes I say make it so. Personally I'll just restore my dd backup image of 14.04, but expect a lot of annoyed users who took a distribution upgrades within the month and didn't image. I think it is poor form personally, but I'm not involved in your decision making.
Reinstating KLocale is really not an option, it's tied in everywhere, would break API and ABI in multiple places and is just too much effort to do. Really, the solution is to put features one by one into QLocale, and that won't happen overnight. Giving advise is nice, but won't change anything in itself. Anybody's help is of course welcome here. Yours, too. That said, I think Jeremy that you may want to have another look into the Regional Settings | Formats settings page. For example, there are two entries for Canada (en_CA, fr_CA). This reflects these regional differences. Also, you can set the formats for currency and time (and others) separately. The dropdown also has keyboard completion. I agree that it's not super user-friendly, but maybe you haven't noticed that yet and it helps. This actually reflects the locale system that is used system-wide on Linux, so non-Qt/KDE apps are now able to pick up these settings as well.
How does one set en_DK in KDE now? I really need ISO date. I need a week to start on Monday. I need metric system and still use English. Looks like I am not the only one. On a side note - there is no preview for short date too,
Setting separate language and region should be possible, as well as displaying a short date preview. I'll have a look into it.
@Sebastian, sorry if I came off the wrong way, especially as giving programming advice. I'm not knowledgeable enough on the code base to be that presumptuous. I'm just trying to express what I see as a KDE user. Others will likely be saying the same things as they upgrade desktop/notebooks. I don't think users will expect the Locale system to undergo such a large regression in configuration. It isn't a feature most people check in the changelog/notes. I saw the separate drop downs and know about keyboard completion, and yes there is en_ca & fr_ca but that represents only two choices based on system locale for a field (say datetime or currency). If I don't like either of those choices, then as a user I have to iterate through the drop down hoping another country's preset is to my liking. That is tedious and unfriendly. By comparison, KDE4 offered this easily customized page https://userbase.kde.org/images.userbase/7/7a/Settings-locale.png . Each setting individually customized. I get as a programmer this regression arose because QT's Locale is inferior to KDE's. Users only care about what _IS_ though, not why it is. As for patching QLocale, that seems like the best solution but it is a bit late in the game to be doing that. It will take several releases I assume. KDE5 is shipping default now. I'm not trying to assign any blame or demand a fix or be hostile. I genuinely want KDE to be the best. I personally already reverted to my KDE4 Kubuntu 14.04 image over this regression & a few other quirks I spotted. Other less technical users though may be surprised/frustrated after dist upgrades, that's what I'm getting at. All they will see is KDE 5 Locale < KDE 4 Locale. Best wishes, Jeremy
Having this issue also. I'm from Northern California, USA, and I use 24-hour time format and YYYY-MM-DD. The fact that this can't be easily modified in Plasma 5.2 (nor 5.3 beta, which I am testing out now) really surprises me. Would greatly appreciate devs re-implementing this feature like it was on Plasma 4.XX, or even refining it with the same polish as the rests of the awesome Plasma 5 updates. (Running the newly-released Kubuntu 15.04 x64). Cheers!
Just curious, how do GNOME or other desktop users configure their locales? Since Plasma 5 now uses the system locale, instead of doing its own thing, aren't there any other (non-KDE4) Linux users, that need to customize the formats?
@Christoph Feck, As far as adjusting the time format, I know that GNOME (either in the time settings or the gnome-tweak-tool application) has a simple check box that allows you to switch from 12-hour to 24-hour time, regardless of the timezone you select.
That worries me as a KDE user and enthusiast - using "Others suck, so can we." arguments was not what made KDE great. Using ISO standard date and 24H should stand above all locales as we have to keep in mind what I in ISO stands for.
The idea was not to say "we can drop customization tools, because others do not have it either", but rather "can we use a cross-platform tool to create locale files" until Qt offers a way to return customized configurations to KDE applications.
@Jeremy/starcraft.man is exactly correct. And, "Qt does it like that so we just have to wait for them to fix it," is entirely the wrong answer.
Is there an upstream bug on the Qt bugzilla for this? If so, could someone please provide the link? (Perhaps it is QTBUG-14159 at https://bugreports.qt.io/browse/QTBUG-14159 but that's awfully vaguely worded.) If not, could someone more knowledgeable about the exact shortcomings of QLocale please open an issue there (and link to it from here), so that those of us who are affected can watch it and vote for it?
(In reply to Christoph Feck from comment #14) > Just curious, how do GNOME or other desktop users configure their locales? > Since Plasma 5 now uses the system locale, instead of doing its own thing, > aren't there any other (non-KDE4) Linux users, that need to customize the > formats? Little. XFCE is a mostly-GNOME interface. I have set LC_TIME=en_DK to get me ISO-8601 format and English names for date +%b (used in `ls -l`) at the same time. As for the task panel clock, its settings dialog suggests a handful of defaults based upon the *language in LC_MESSAGES* (stupid, eh). For example, setting it to de_DE yields the date plugin offering a Choice control {"1999-12-31", "1999 Dezember 31", "12/31/1999", "Dezember 31, 1999", "Dez 31, 1999", "Freitag, Dezember 31, 1999", "Fr, Dez 31, 1999", "31/12/1999", "31 Dezember 1999", "31 Dez 1999", "Freitag, 31 Dezember 1999", "Fr, 31 Dez 1999", "Custom…"}. Do note how it misses lacks offering the default date representation (as output by `date`) and date +%x, which would show the German dot ("31. Dez(ember) 1999"). Anyway, I don't care about the defaults so much because I chose Custom to input my own strftime string, because I like it to be very terse in the panel, but also with a week number. (So I have e.g. %V, %a %-d and %-H in it, which is anything but standard ;-)
Thinking about it, I am not entirely sure customization of locale formats should be implemented in Qt. QLocale simply respects the system's or user's locale settings. Why should customizations to formats only be respected by Qt applications? This would result in a similar inconsistency we had with KDE4, where only KDE applications respected them, but no other applications, or where users expected KDE applications to follow the standard locale variables, but KDE4 had its own idea. See bug 134993, bug 308674, bug 211531 and certainly many others. It was one of the reasons to drop the KLocale classes. To me, locale files should be user editable. Then someone could write a tool to edit those settings. I am not familiar with internals of system locale files provided by glibc, though. For example, I also hate how KCalc now displays numbers in "1.000.000" format, instead of "1 000 000" when enable digit grouping, but German locale simply defaults to a dot for thousands separators, and I really would love to get this addressed everywhere, not just in KCalc.
*** Bug 335949 has been marked as a duplicate of this bug. ***
*** Bug 346759 has been marked as a duplicate of this bug. ***
Well, there doesn't even seem to be a uniform setting. I did a fresh install of Kubuntu 15.04 and added the Kubuntu Team 5.3 Beta PPA. In the region settings I selected: Region: US/American English --> Because I don't want the system language to be German [checked ]Detailed Settings Numbers: Switzerland de_CH Time: Switzerland de_CH Currency: Switzerland de_CH Measruements Units: Switzerland de_CH Collation and Sorting: Switzerland de_CH The result is this: http://images.sjau.ch/img/1fb57908.png - System clock shows nicely time and date format as I want it: HH:ii dd.mm.YYYY - However in Dolphin date entries show: mm/dd/YY hh:ii am/pm - And in the terminal it's even more weird. There, the interface language is German. - Also Gimp presents the interface in German
Would it be possible to have a dialog that would allow creating a custom format like in the KDE4? Behind the curtain, a custom locale would be created for that custom format and used by the system. This is basically the workaround that is currently proposed. Also, there is no way to know which region has the format you are looking for (assuming one exists). The user has to try them all until they find one that is good enough. And this requires a reboot after each change. I don't expect any but the most determined to try that hard.
Unfortunately in current state of Plasma 5, locale is missing custom formats, for example I want to custom formats for date / time / numbers / currency and there seems to be no way to configure such things. Please bring back the options from KDE4... :-( this is such a huge step back -- for me, this is the only thing holding me back from updating to Plasma 5.
*** Bug 346906 has been marked as a duplicate of this bug. ***
Do I understand correctly, getting rid of KLocale also means that we go back where changing the locale means changing the environment variable, which means changing it goes to effect after logout/login? (without working session restore, to increase the fun) So we forfeit a working solution that mitigated the UNIX's worst feature for desktops. Are there plans to provide solution to this or it's not even considered a problem?
Is there a decent workaround to this (and related) issue(s)? I still haven't seen how to modify my locale appropriately. I'm digging through configuration files trying to figure out what to hit & how hard to hit it (right now, it'd end up being pretty hard, regardless how much force is needed).
I've just spent 5 hours trying to fix this, I want somewhere to voice my frustration. The whole 'region' concept is just $#%&^(* broken. It provides a decent first order approximation, but as a be-all end-all of format configuration is... I can't express how much this frustrates me. I need to vent, it's boiling over.
i just started to use KDE 5 on a Fedora 22. I just don't like it. It's not KDE3 to KDE4 again, but, those are important changes. I used KDE because I liked it's customization, despite the fact that it's fonts were really bad. Now, we still have bad fonts and less customization.
Is this being fixed/implemented. I like the YYYY-MM-DD format for short date (and sorting), and after upgrading to kf5 this feature is gone.
(In reply to bugs5.kde.org from comment #24) > - However in Dolphin date entries show: mm/dd/YY hh:ii am/pm That's because Dolphin is currently still a kdelib4 application. Ask your distributor to ship System Settings 4. Can't say anything about yout GTK problems. I have a similar setup (English GUI, German dates) and nothing is in German.
I just got bitten by the lack of customization options. I don't want to use German as a language anywhere on my desktop , so I didn't change the date/time to de_DE format. This entails non-ISO week numbering, which I wasn't aware of and I caused a hell of mess scheduling a data center downtime. In KDE4, I explicitly used ISO week numbering (may it even was the default?), but KF5 doesn't provide that setting.
I want to add that this has to go farther than the date format and I would like to see the full customisability of KLocale returned to KDE. This includes things like being able to set 12/24-hour clocks, change the first day of the week, number digit grouping, negative number formatting, etc. One of the things that put me off GNOME was how it used this locale-based system instead of letting users decide for themselves what format they wanted to use. My preferences are a mix of Canadian, British and ISO standards, so it's simply not possible to even figure out which country uses the particular standard that I want to use. Whilst I appreciate that KDE programmers are doing their best, most of us are not clever programmers like you. This UX regression loses a major KDE selling feature that we can't tackle ourselves. I just want to emphasise that I don't want to wait 10 years before this functionality returns!
(In reply to Borden Rhodes from comment #35) [...] I totally agree with your statements, I also use a mix of settings (English language, SI units, Monday as first weekday, ISO date format, HH:mm:ss time format, post-fix currency, prefix currency sign, dot as digit separator, comma as digit grouping symbol etc.) and unfortunately there is now way of customizing such basic things in the new KDE, so I'm forced to stick with KDE4 (and its sane locale settings), although I do like the overall look and feel of the new KDE.
I've been putting off upgrading my distribution for some time in order to avoid KDE 5 for this reason. Are there any plans to roll these changes back in the near future so I can at least set ISO 8601 date and 24H time? KDE has always been the DE that gives the user the ability to configure nearly everything as they see fit. To "simplify" and remove user choice is in my opinion very much down the wrong road for KDE. It's a bit frustrating to see the stated reason for this change in KDE5 (using the Qt-only formatting classes as part of the Frameworks initiative) - perhaps a better approach would be to wait and make the change in KDE only when the ability and flexibility in QT is fully there?
(In reply to Kevin Clevenger from comment #37) You can do this for the digital clock plasmoid in 5.4.
The use of generic regions instead of actual proper configurations places an assumption that everyone in every region has the exact same preferences. I use NL as a location, Irish for most defaults, ISO8601 for times, using 2 clocks (one in UTC and the other in CET). I need to set system to en_DE format for a known thunderbird bug. Switching the location to en_DK.utf8 (http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Change_the_Date_Format) and doing so on Fedora 20 converted the entire desktop to the Danish Language. I am switching back to Fedora 21 until this is fixed.
We should assign blame where blame is due. I think it's a good idea for KDE to hook into the underlying locale system, since there were localisation issues between KDE programs and non-KDE programs from KDE using its own localisation system. The problem is that the geniuses at IEEE and/or Linux Foundation decided to bundle the localisation settings by country. We could complain to them that this system is overly restrictive, prejudiced and outdated, but they won't, of course, care. My suggestion is for KDE to expose the customisation settings in locale(5) for us to specify our own settings that'll hook back into locale. That should allow us the KF4 customisation flexibility whilst using Linux and POSIX's developed systems.
Created attachment 94633 [details] Plasma 5 regional settings, different language and format with ISO date The following settings work for me on Arch Linux running Plasma 5.4 (english language with german formats and ISO date). System Settings -> Regional Settings -> Translations -> Preferred Languages = American English (top), Deutsch ... -> Formats -> Region = Deutschland - Deutsch (de_DE) Detailed Settings = No change, except for Time = Germany (nds_DE) locale.conf: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_MESSAGES=C Make sure all needed locales are generated, in my case en_US.UTF-8, de_DE.UTF-8 and nds_DE.UTF-8. Check your distribution wiki on how to generate locales. In the Detailed Settings ComboBox above the 'Default - (C)' entry most regional settings set the date/time format to ISO 8601, like ts_ZA or co_FR etc. Choose a setting matching your region and check in the 'Examples' section for the format. Also see the attached screenshot "Plasma 5 regional settings, different language and format with ISO date".
I think you're probably relying on a bug in the Low Saxon (nds) localization though, I strongly doubt people use a different date format in Low Saxon than in German.
> In the Detailed Settings ComboBox above the 'Default - (C)' entry most regional settings set the > date/time format to ISO 8601, like ts_ZA or co_FR etc. I do not know the reasoning behind this, but then there must be bugs in the settings for France (co_FR, oc_FR), Canada (iu_CA, moh_CA), Turkey (ku_TR), Belgium (wa_BE), Finland (sms_FI), Sweden (smj_SE, sma_SE) and many more as well, as most of the entries *above* the named entry 'Default - (C)' have an ISO 8601 date. You can also strongly doubt that all these dialects have a different date format than the main country.
*** Bug 352447 has been marked as a duplicate of this bug. ***
(In reply to Borden Rhodes from comment #40) > We should assign blame where blame is due. I think it's a good idea for KDE > to hook into the underlying locale system, since there were localisation > issues between KDE programs and non-KDE programs from KDE using its own > localisation system. The problem is that the geniuses at IEEE and/or Linux > Foundation decided to bundle the localisation settings by country. We could > complain to them that this system is overly restrictive, prejudiced and > outdated, but they won't, of course, care. > > My suggestion is for KDE to expose the customisation settings in locale(5) > for us to specify our own settings that'll hook back into locale. That > should allow us the KF4 customisation flexibility whilst using Linux and > POSIX's developed systems. But KDE should use that for the average user. For the power user, that needs to customize these settings, there should be an option. So the default/base should be locale, but there should be an "override" button that KDE uses (if only for KDE Apps). I figured out how to change Thunderbird's settings in F21 for YYYY-MM-DD 24-HR:leading-zero-Minute. Just give people the option - if that means going back to KLocale, so be it!
And how to I set the date to WOCHENTAGKURZ TT.MM.JJ or WOCHENTAGKURZ TT.MM. (needed especially for the panel clock)? I don't know what WOCHENTAGKURZ in English was - SHORTDAYOFWEEK? I want to get the format "Fr 25.09.15" or "Fr 25.09.", something short with day of the week - I guess there's no (inter)national ISO format for that?
This is ridiculous and perfect example of why Linux distros have 1.5% of the market. This is not an original problem. Mac OS X and Windows have the same issue and they both solved it long ago. The locale should provide the default settings. The user should be able to alter from those default settings to accommodate his specific needs. Making those alterations should be easy and intuitive, as it was in previous versions of KDE. That Qt made bad choices and KDE cannot do anything about it is completely ridiculous, lazy and amateurish.
I just installed Fedora 23ß with KDE5 (I had been using F21 with KDE4 until earlier this week) and, to my dismay, I find that I am unable to set the date in the official Canadian format (ISO8601), which is used in a number of variants. Luckily, of the many commonly used variants, a Default (C) choice gives me exactly what I want; however, not all KDE5 programs respect the setting, namely Korganizer! Why don't all KDE programs respect the date and time setting as configured in the KDE System Settings?
I agree this is a problem for personalization. The default locales for various countries I feel need to be updated. As you say, the Canadian official date is now ISO 8601. If KDE is using the system locale as a default date (which I feel is good) then it may be an option to write a program to edit the system locale instead of depending on QT or setting for the desktop. It may also be a benefit until there is a better way to add a description for each locale showing the various values of the particular locale or providing a web link to the various values. A set of ISO 8601 locales may be a good option. Anyone know where to submit requests for updates for default locales?
Digging deeper into how QLocale works, I now understand that my comment #21 is wrong. My initial impression was that QLocale uses the POSIX interfaces in glibc to get the locale data. But instead, it uses a built-in database derived from the Unicode CLDR database, which offers more information than POSIX can provide. Using "localedef" to compile a custom locale would not work for Qt applications. QLocale uses system calls on MacOS and Windows, but not on Unix :( POSIX really needs to be updated to CLDR standards, so that the CLDR data can be used as a base for "localedef". Then Qt wouldn't need to ship it's own database.
*** Bug 353219 has been marked as a duplicate of this bug. ***
(In reply to Christoph Feck from comment #50) > My initial impression was that QLocale uses the POSIX interfaces in glibc to > get the locale data. But instead, it uses a built-in database derived from > the Unicode CLDR database, which offers more information than POSIX can > provide. > > Using "localedef" to compile a custom locale would not work for Qt > applications. QLocale uses system calls on MacOS and Windows, but not on > Unix :( So what is the workaround for a user desperately needing to define how dates are shown in Qt apps? Recompile Qt with patched locale data?
Please, on the following 1-3 months, are there any chances to get the same level of configuration with the new Plasma 5 (and its QLocale based locale support) as we used to have with KDE4 (and its KLocale)? In its current state (and I guess for a long time to come) QLocale is way too limited regarding locale configuration (at least on Linux, according to #50). As a simple user, when I think about KDE, I think first about an excellent desktop (the best) with great usability and customization options... for me -- the simple user -- it's not about how the core libraries are designed, maintained etc. -- I don't see those things, no matter how great and important they are for development, I just see what you -- the developer -- let me see... so for us, your loving users :-) it's just very disappointing when such an important feature is lost when we're actually upgrading our great KDE.
Created attachment 95059 [details] Crude patch to the en_US locale with hardcoded values As it does not look like KDE/Qt are providing a true solution soon and I want to be able to upgrade to KDE5 without totally upsetting my users because of these locale problems, I made this crude patch to the en_US locale of Qt5. It changes en_US to 24h time, YYYY-MM-DD, metric units, a thousands separator of space and a decimal separator of comma. So you can stay with en_US to keep all your shell programs sane and still have nice output in all Qt5/KDE5 programs. If you want slightly different settings, the patch still might give you some guidance how to do it. I also want to point out the testlocales program which you'll find in util/local_database/testlocales within the qt5-qtbase source. Compile and run it, you can use it to search for locale parts you are interested in to combine them in a patch similar to mine.
Thanks Gerd, nice tip (#54). Now I made the switch to Plasma 5, using a custom PKGBUILD for qt5-base (with a patch inspired by yours). At least I know what I have to tweak from now on (hopefully this issue will be properly fixed in the next 50 years). :-) Many thanks again.
another thing that seems to be lost - ability to set locale to a region (to get the defaults for all the settings) and override interface language. pretty much all of the previously available overrides were very useful.
I too would like to use en_GB formats generally, but ISO date format (ISO 8601) as the date format and SPACE for the thousands separator following the general advice from BIPM and IUPAC described here: http://www.bipm.org/en/publications/si-brochure/section5-3-4.html http://old.iupac.org/reports/provisional/guidelines.html These require a thin space (or a space) as the thousands separator to avoid confusion in international use. The ISO data format and use of a space as the thousands separator are likely to be used in any locale.
It's now more than a year and (seemingly) nothing happened. I really don't get it. KDE once was the best. Of course, there were some bumpy episodes from time to time (e.g. when migrating from KDE 3.x to 4.x), but never before, I experienced such a miserable failure: *Without* *any* *need*, you removed a very important feature (!) and for over a year, you don't put any effort in re-adding it. What's wrong with you guys? Are you trying to convince people to migrate away from KDE?! I'm a software developer myself. And I certainly do not only think well before removing a feature, but I would immediately make re-adding/repairing it the highest priority, if this accidentally happened. Many users complained (this issue has 754 votes, currently), but still there seems to be no progress :-( So what's the state? Are you working on a solution? When is it expected to be ready?
I would like to add: Most people missing this feature are using ISO 8601, *THE* *INTERNATIONAL* *DATE/TIME* *STANDARD* *FORMAT*. So, besides making the format(s) [not only date/time, but numbers, too] fully configurable, a fast preliminary solution would be to provide THE INTERNATIONAL STANDARDS as one of the choices in the region combo. This, btw. should stay as a permanent solution, in addition to the manual configuration (which still should be added, later), because international standards should be valued and fostered by everyone - especially by free software.
it's probably not worth requesting the change - most developers are volunteers and i am very grateful to them for all things kde. there was also a reason for this feature to disappear - they now use qt more, which reduces kde-specific code (read, less maintenance). i'm not a programmer - but you mentioned that you are. maybe you can lend a hand at implementing this feature in qt ?
It seems like this bug could be split into two feature requests: 1) About 75% of the people here, including the OP, seem to be asking for ISO 8601 support*. This specifies, among other things, a date format of YYYY-MM-DD. 2) About 25% of the people here seem to be asking for freely-configurable date, time, and other locale items support. In my opinion, this bug should concentrate on adding ISO 8601 support, and another bug should be opened for freely-configurable locale support. * https://en.wikipedia.org/wiki/ISO_8601
I would agree to that, but don't forget the ISO-8601 time format.
Since this has been pointed out to be a KDE issue, I decided to look at the QT bug reports. I only found one that I think may be related. There is an open bug report for QT to extend the date formats to support Unicode but doesn't look like it has been worked on for a couple of years. https://bugreports.qt.io/browse/QTBUG-17107 I made a comment to add ISO-8601 as an option. If I get told that this isn't the correct bug, then I will create a new one, if I can figure out how as something blocks much of their scripted page from working properly.
(In reply to Robin Laing from comment #63) > Since this has been pointed out to be a KDE issue, I decided to look at the > QT bug reports. I only found one that I think may be related. > > There is an open bug report for QT to extend the date formats to support > Unicode but doesn't look like it has been worked on for a couple of years. > https://bugreports.qt.io/browse/QTBUG-17107 > > I made a comment to add ISO-8601 as an option. > > If I get told that this isn't the correct bug, then I will create a new one, > if I can figure out how as something blocks much of their scripted page from > working properly. There are (closed) bug reports related to this: https://bugreports.qt.io/browse/QTBUG-35692 and https://bugreports.qt.io/browse/QTBUG-49950 . I don't have high hopes for a Qt-side quick-fix...
(In reply to Sebastian Kügler from comment #9) > That said, I think Jeremy that you may want to have another look into the > Regional Settings | Formats settings page. For example, there are two > entries for Canada (en_CA, fr_CA). This reflects these regional differences. That's not only condescending, but wrong. In the first place, the "regional" differences mentioned go far beyond french and english, but more importantly, I've already found myself forced to set my date format to fr_CA which works fine for short dates, but forces me to read LONG dates in French. Thank god my bilingual capacities stretch that far.
It is always wrong to forcibly tie the format of dates, times or whatever else to the region of the world where one lives. Not only there are places were several formats are used by different people, there is also people like me who do not like the particular format used in the region where he lives. It just doesn't make sense, except perhaps to provide default settings. Unix got this amazingly wrong with the «locale» subsystem. It is sad seeing KDE ditching its previously working preferences (in KDE4) to adopt this obviously broken design.
Is this fixed yet? I am about to install a new system, and am debating whether to go with Plasma 5
ping?
(In reply to EMR_Kde from comment #67) > Is this fixed yet? I am about to install a new system, and am debating > whether to go with Plasma 5 Not fixed. Not scheduled to be fixed.
As I look now, this bug has 875 votes. That's just the number of people who have bothered to find this bug entry and vote on it. I wonder what proportion of users actually do that... Since this is not scheduled to be fixed, I'd like to politely ask why. Is this not considered a bug? Not an important enough bug? Are there just Insufficient resources to deal with it? Is it believed to be a reasonable compromise in features? How open are the devs to the possibility that the locale system might need another rewrite or reverting a significant amount in order to fix it? What's the reasoning here? This would be very important for an outside developer to know in evaluating their own level of motivation towards working on this.
(In reply to Chris from comment #70) > As I look now, this bug has 875 votes. That's just the number of people who > have bothered to find this bug entry and vote on it. I wonder what > proportion of users actually do that... > > Since this is not scheduled to be fixed, I'd like to politely ask why. Is > this not considered a bug? Not an important enough bug? Are there just > Insufficient resources to deal with it? Is it believed to be a reasonable > compromise in features? How open are the devs to the possibility that the > locale system might need another rewrite or reverting a significant amount > in order to fix it? > > What's the reasoning here? This would be very important for an outside > developer to know in evaluating their own level of motivation towards > working on this. The explanation as I understand it is that the root of the problem is in Qt and it is either not possible, too difficult, or not viable to fix/work around it above Qt in KDE. Until it gets fixed in Qt, it won't be fixed in Plasma. I am currently living on Kubuntu 14.04 LTS which does not have this issue. At this point, I will probably switch to another distro with a different DE.
I've already done that. I have even removed all KDE-based applications from my systems. They have too much of the "works for me, I don't know what your problem is" attitude. Options are great.
> What's the reasoning here? This would be very important for an outside developer to know in evaluating their own level of motivation towards working on this. We had issues with KDE applications having it's own idea of locales, instead of respecting what the environment (LC_LANG, LC_ALL, etc.) selected. See the comments avove. KF5 does no longer have a separate KLocale class. We now use Qt's QLocale because it respects those variables. Unfortunately, no one had the time to work on adding back the ability to configure locales. You could contact the qt-development mailing list or ask John Layt for the status and how you can help. > I have even removed all KDE-based applications from my systems. Interesting. Which other desktop offers to customize locales?
Maybe it would save allot of headaches if there was an easy way to change locale system wide. There are ways to play around but it would be nice if there was an ISO 8601 based locale instead of searching and using some country locale. For 24 clock, I use en_GB.UTF-8 for LC_TIME But I still don't have the correct short date. I found this as a work around and have to try it to see how it works. https://ccollins.wordpress.com/2009/01/06/how-to-change-date-formats-on-ubuntu/ This is more the official way of doing it. https://wiki.archlinux.org/index.php/Locale Maybe it would be better to design a program to change the system locale into a format that people want to use instead of waiting for a way to do it via QT.
(In reply to Robin Laing from comment #74) > For 24 clock, I use en_GB.UTF-8 for LC_TIME > > But I still don't have the correct short date. LC_TIME of en_DK (english danish) will give you 24Hr & ISO date in many programs
(In reply to Robin Laing from comment #74) > For 24 clock, I use en_GB.UTF-8 for LC_TIME > > But I still don't have the correct short date. LC_TIME of en_DK (english danish) will give you 24Hr & ISO date in many programs that respect that variable
(In reply to EkriirkE from comment #76) > LC_TIME of en_DK (english danish) will give you 24Hr & ISO date in many > programs that respect that variable en_DK has been discussed multiple times in this thread. The locale is not in the Unicode CLDR database and is therefore not available to QT applications.
(In reply to Christoph Feck from comment #73) > Which other desktop offers to customize locales? KDE3 (openSUSE all) KDE4 (Ubuntu 14.04 LTS, Mageia 5, openSUSE 13.2) TDE (Debian Lenny, Squeeze, Wheezy, Jessie, Stretch; Fedora 21, 22, 23; Ubuntu 10.04 and up; openSUSE 13.1, 13.2, 42.1; Q4OS default; RedHat; others).
(In reply to Felix Miata from comment #78) > (In reply to Christoph Feck from comment #73) > > Which other desktop offers to customize locales? > > KDE3 (openSUSE all) > KDE4 (Ubuntu 14.04 LTS, Mageia 5, openSUSE 13.2) > TDE (Debian Lenny, Squeeze, Wheezy, Jessie, Stretch; Fedora 21, 22, 23; > Ubuntu 10.04 and up; openSUSE 13.1, 13.2, 42.1; Q4OS default; RedHat; > others). Windows and Mac OSX. Everyone will bulk at their mention but as one who would like to see pre-installed Linux offered by Lenovo, ASUS and Dell, getting on par with the commercial offerings should be a goal.
I'm now using an alternate clock/calendar widget for the panel (http://kde-look.org/content/show.php/Event+Calendar?content=175591) which allows to set the date to a format I want. It can show the short day - "Fr 25.09." - and you can use any format for time and date you want, that's enough for me.
Created attachment 99000 [details] attachment-22055-0.html As I see it, the problem is the whole locale system which assumes that all your preferences are based on a single region. This problem is beyond KDE, and affects the entire UNIX ecosystem. On Sun, May 15, 2016 at 4:37 PM, Janet via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=340982 > > --- Comment #80 from Janet <bugzilla@kerridis.de> --- > I'm now using an alternate clock/calendar widget for the panel > (http://kde-look.org/content/show.php/Event+Calendar?content=175591) which > allows to set the date to a format I want. It can show the short day - "Fr > 25.09." - and you can use any format for time and date you want, that's > enough > for me. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
(In reply to Stefan from comment #81) > Created attachment 99000 [details] > attachment-22055-0.html > > As I see it, the problem is the whole locale system which assumes that all > your preferences are based on a single region. This problem is beyond KDE, > and affects the entire UNIX ecosystem. The problem with the 'UNIX ecosystem' is beyond the scope of KDE. Yes it would be nice if there were better ways to universally solve the problem at that level and this would fix this issue and make every single application conform, not just ones that use Qt's library for this. OS X uses POSIX locales just as Linux does. But just as KDE 4 kept things separate so does OS X. LC_ALL=C generally has no effect on an OS X application, but it does have an effect on grep/etc as would be expected. Although OS X was developed a very long time, I think Apple saw it as necessary to keep these systems separate. It is nice to have a universal standard for all, but the POSIX locale system is too inflexible for this as it is. It has no built-in customisation, only forced conformity. But even so, sometimes applications come with their own way to override locale, even ls. GNU ls has the --time-style argument, like so: --time-style="+%Y-%m-%d %H:%M:%S".
(In reply to Stefan from comment #81) > As I see it, the problem is the whole locale system which assumes that all > your preferences are based on a single region. This problem is beyond KDE, > and affects the entire UNIX ecosystem. The thing is that this was *working* before regressing to QLocale. Why not port KLocale over to KF5? Just because I am located in the USA doesn't mean that I want my settings as the "normal" user would have it. In Windows, OS/X I can change the format of my date and time. For logical and geeky reasons (mainly ease of sorting, and Linnaeus ease of use) YYYY-MM-DD HH24:MM:SS seems to make the most sense to me. From most general to the most specific. What really grinds my gears though, is that this was all working under KDE4... why change it?
I totally agree with what you are saying. Personally I hate 12 hour clock, the 24hr clock is the first thing I look for. Also, I am going to repeat after you: that yyyy-mm-dd or simply yy-mm-dd or simpler yymmdd makes perfect sense for sorting, this is why I use it everywhere. To me, this thing sounds like someone funding KDE5 development is forcing the issue against the rest of us.
(In reply to tdyzio from comment #84) > To me, this thing sounds like someone funding KDE5 development is forcing > the issue against the rest of us. As far as I can gather, it's rather the opposite. That is to say, without more funding---and for various other practical and well-intentioned reasons---it's generally better when possible to stick with upstream rather than complicating things with additional solutions atop of the upstream stack. Unfortunately in this case, QLocale is pretty dramatically inferior to KLocale for any of us (myself very much included) who can't stand the "correct" date and time formats for our locales and have years-bordering-on-decades of relying on the ability to customize this. The hope is that someone steps up with usable patches for QLocale, and that the Qt folks accept them. Unfortunately I, like most of the people balking at this regression, don't have anywhere near the programming skill to reasonably provide such code. But lacking that, we wait in perpetuity.
(In reply to Keith Zubot-Gephart from comment #85) > The hope is that someone steps up with usable patches for QLocale, and that > the Qt folks accept them. Unfortunately I, like most of the people balking > at this regression, don't have anywhere near the programming skill to > reasonably provide such code. But lacking that, we wait in perpetuity. I am definitely in the same boat. I know enough, but not as much needed to port KLocale to KF5. Further, it also relies on downstream KDE Apps to make use of the new KLocale5 (or whatever you're going to call it) instead of QLocale (after years of kapp owners being told to use QLocale). Interestingly enough, I also found this email from 2011 on removing KLocale. Had I known what was going to happen, I would have objected back then. http://kde-core-devel.kde.narkive.com/v0Q0HYO4/locale-in-kf5-qt5 It seems like item #4 never happened: "4) QLocale will add support for most if not all the KDE options to their parsers/formatters, as well as some options KDE does not currently support."
could some developer estimate the effort needed to implement eeeverything in qlocale (as per http://kde-core-devel.kde.narkive.com/v0Q0HYO4/locale-in-kf5-qt5) ? i could chip in a few euros, if there was some crowdfunding initiative... also, was this (or part of this) offered as a project for gsoc ? was the problem that there was nobody willing to mentor this project ?
*nudge* I'll chip in, and add some beer!
So I went to date/time format and went to select en_DK but it's missing from the drop down list in "Formats - KDE Control Module" I went through the list twice, perhaps I missed it for "Time".
(In reply to Gerd v. Egidy from comment #54) > If you want slightly different settings, the patch still might give you some > guidance how to do it. I also want to point out the testlocales program > which you'll find in util/local_database/testlocales within the qt5-qtbase > source. Compile and run it, you can use it to search for locale parts you > are interested in to combine them in a patch similar to mine. Thanks for that, Gerd. However, I have no idea how to start with creating a different kind of locale. The numerical codes in `qtbase-opensource-src-5.7.0/src/corelib/tools/qlocale_data_p.h` are incomprehensible to me; I guess testlocales will help explain them, but I'm not sure how to use this (see below). Could you please point me to a tutorial, or please provide more information? Thanks in advance. $ qmake testlocales.pro Info: creating stash file /tmp/qt5-base/src/qtbase-opensource-src-5.7.0/.qmake.stash $ make g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -g -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtCore -I.moc -isystem /usr/include/libdrm -I../../../mkspecs/linux-g++ -o .obj/localemodel.o localemodel.cpp localemodel.cpp: In member function ‘virtual QVariant LocaleModel::data(const QModelIndex&, int) const’: localemodel.cpp:286:60: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses] || role != Qt::DisplayRole && role != Qt::EditRole && role != Qt::ToolTipRole ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -g -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtCore -I.moc -isystem /usr/include/libdrm -I../../../mkspecs/linux-g++ -o .obj/localewidget.o localewidget.cpp localewidget.cpp:28:22: fatal error: QTableView: No such file or directory #include <QTableView> ^ compilation terminated. make: *** [Makefile:690: .obj/localewidget.o] Error 1
(In reply to sparhawk from comment #90) > Thanks for that, Gerd. However, I have no idea how to start with creating a > different kind of locale. The numerical codes in > `qtbase-opensource-src-5.7.0/src/corelib/tools/qlocale_data_p.h` are > incomprehensible to me; Sorry, there is no Howto or similar for this, as it is a "crude patch", just as the name says. I primarily looked at the source and compared the data that different locales used to find out the settings I wanted. With a bit of trial-and-error I got the result I wanted and that is what is in the patch. So just look at what locale uses the date format you want, what locale uses the currency format you want and so on. If two or more locales use the same format, then compare what fields are the same for them. This way you'll find out which field is what.
After playing around with patching qtcore and with Gentoo's locale settings, I'd like to share my current solution for achieving something like en_AT on a sinlge-user machine (kinda like a German regionalization). /etc/locale.gen (run locale-gen afterwards): de_AT.UTF-8 UTF-8 en_US.UTF-8 UTF-8 /etc/env.d/02locale LANG="en_US.utf8" LC_COLLATE="de_AT.utf8" LC_CTYPE="de_AT.utf8" LC_MEASUREMENT="de_AT.utf8" LC_MONETARY="de_AT.utf8" LC_NUMERIC="de_AT.utf8" LC_PAPER="de_AT.utf8" LC_TIME="de_AT.utf8" It's important to omit LC_ALL, which should lead to an empty definition in the output of "locale". I left the "Region" box in "Regional Settings"->"Formats" at "No change". This fixes basically all date/time/currency issues I've encountered. Of course this will display day & month strings in the regionalization language ("de" in my case). If you're not OK with such a system-wide change, I recommend to patch the locale_data_p.h file. For me however it was not as simple as mapping the "German/Latin/Austria" onto the "English/Latin/UnitedStates" numbers. Keeping the "lang" column at English "31" generated some strange effects like date strings containing "M06" instead of "June".
(In reply to Gerd v. Egidy from comment #91) Thanks for that information. Unfortunately, once I started to fiddle with locales, it exposed all kinds of horrible bugs in korganizer. (I won't bother filing them, because the devs have ignored all of my previous bugs.) I'll just move to another calendering application, and directly patch the clock widget instead. Thank anyway.
I think this bug is NOT really a technical issue, but a design problem. This is a option on the UI to let people choose time format, but...Why the date time format has to be bound with a country? What's the rationality for this design?
openSUSE 42 KDE Plasma version 5.5.5 ISO Date setting: Right click on the clock and select Digital Clock Settings Appearance Date format (at the end includes ISO Date option)
@Geoff Cutter, it's not just the clock, but other Plasma components that are affected, such as korganizer.
(In reply to sparhawk from comment #96) > @Geoff Cutter, it's not just the clock, but other Plasma components that are > affected, such as korganizer. Interesting, KDE doesnt even support en_DK locale ... user@host:~> locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME=en_DK.UTF-8 Yet, KDE defaults to en_US... so what is it? either you honor the locale, or allow us to change it like back with kde4
(In reply to EMR_Kde from comment #97) > > Interesting, KDE doesnt even support en_DK locale ... > > Yet, KDE defaults to en_US... so what is it? either you honor the locale, or > allow us to change it like back with kde4 Already covered earlier in Comment 77: https://bugs.kde.org/show_bug.cgi?id=340982#c77 (Please try and avoid adding to this report about things that have already been covered…)
Created attachment 100416 [details] attachment-28177-0.html That seems surprising to me, since although I find it weirdly difficult to find a direct list, the CLDR website links in turn to lists that include "English (Denmark)". On http://www.unicode.org/cldr/charts/29/ they even say "ICU does not contain all of the data in CLDR" when linking to the ICU which lists "English (Denmark)", which implies that CLDR is a superset of ICU. The comment you have linked to does not explain *why* en_DK is not included in the CLDR database. On Tue, Aug 2, 2016, 07:54 Erik Quaeghebeur via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=340982 > > --- Comment #98 from Erik Quaeghebeur <kdebugs@equaeghe.nospammail.net> > --- > (In reply to EMR_Kde from comment #97) > > > > Interesting, KDE doesnt even support en_DK locale ... > > > > Yet, KDE defaults to en_US... so what is it? either you honor the > locale, or > > allow us to change it like back with kde4 > > Already covered earlier in Comment 77: > https://bugs.kde.org/show_bug.cgi?id=340982#c77 > (Please try and avoid adding to this report about things that have already > been > covered…) > > -- > You are receiving this mail because: > You voted for the bug. > You are on the CC list for the bug.
(In reply to Keith Zubot-Gephart from comment #99) > That seems surprising to me, since although I find it weirdly difficult to > find a direct list, the CLDR website links in turn to lists that include > "English (Denmark)". On http://www.unicode.org/cldr/charts/29/ they even > say "ICU does not contain all of the data in CLDR" when linking to the ICU > which lists "English (Denmark)", which implies that CLDR is a superset of > ICU. The comment you have linked to does not explain *why* en_DK is not > included in the CLDR database. en_DK has been added to CLDR versions 28 and newer: http://unicode.org/cldr/trac/browser/tags/release-28/common/main Apparently, the updated versions of CLDR have not yet been incorporated into releases here. (At the time of this comment, the current release of CLDR is v29) Should a new bug be filed to request an update of the CLDR data?
(In reply to nerd65536+kde from comment #100) > > Should a new bug be filed to request an update of the CLDR data? CLDR data is embedded in QtCore, so a bug report here won't help. I haven't been able to find what CLDR version is embedded, but it seems Qt's plans for dealing with this issue (and others) can be found on their wiki: http://wiki.qt.io/Qt-5-QLocale
I recently upgraded to Xenial Xerus. I tried various locales in System Settings and found: *Latinoamérica - español latinoamericano (es_419) — this is not in the locales available in /etc/locale.gen . If I saw es_419 out of this context, I'd think it means "Spanish as spoken by Nigerian scammers". *Denmark - English (en_DK) — this is not in the list in System Settings, even after I ran locale-gen and made sure that en_DK is available. Running with an uninstalled locale causes some problems: Error messages are in Spanish, but accented characters are output like "no se encontr\xf3 la orden" instead of "no se encontró la orden" (command not found). I can type a degree sign in Kwrite if I run it with a real UTF-8 locale, but not with the nonexistent en_419.UTF-8. I am in the USA and use metric. I'd like to select English or Spanish, with the short form date being yyyy-mm-dd, 24-hour clock, A4 paper, decimal point, and the week starting on Sunday, regardless of the language. I have no trouble understanding decimal commas, but when I have a file of XYZ coordinates separated by commas, with decimal points, and no thousands separators, and throw it into a spreadsheet which, because of a Hispanic locale, is expecting a decimal comma, the result is a mess. I'd like to see KLocale reinstated, at least until QLocale is as flexible as KLocale.
After delaying my switch to Plasma5 until 5.7.5, I'm now discovering there still are this kind of problems. Among many regressions, this is not an acceptable one. Adding my vote.
I can imagine how KDE key figures are wondering how they could get more users into KDE community. With this kind of issues being open couple years, keep dreaming suckers.
(In reply to Juha Tuomala from comment #105) We agree it's a regression (I added my vote) but there's no need to become disrespectful. I hope the developers are going to ignore your comment so they don't get demotivated and keep contributing to this wonderful code base.
(In reply to Jérôme Borme from comment #106) > We agree it's a regression (I added my vote) but there's no need to become > disrespectful. The fact is that I'm disrespectful. Funny, that you mention 'regression'. Years back I wanted to start systematically collect regressions between releases. I was told that it's not wanted.
@Juha: Your behavior makes me stop reading here, and that's counter-productive to everyone involved. Also, your disrespectfulness has no business here, you're just destroying the base people work together on. Ask yourself this question: Do you really want to drive developers away from issues you and other people care about? Please strongly consider the Code of Conduct ( https://www.kde.org/code-of-conduct/ ) before posting again. If you don't, you simply do not have the right of speaking. "I just behave that way" is not an excuse.
(In reply to phma from comment #102) > I recently upgraded to Xenial Xerus. I tried various locales in System > Settings and found: > *Latinoamérica - español latinoamericano (es_419) — this is not in the > locales available in /etc/locale.gen . If I saw es_419 out of this context, > I'd think it means "Spanish as spoken by Nigerian scammers". > *Denmark - English (en_DK) — this is not in the list in System Settings, > even after I ran locale-gen and made sure that en_DK is available. > > Running with an uninstalled locale causes some problems: Error messages are > in Spanish, but accented characters are output like "no se encontr\xf3 la > orden" instead of "no se encontró la orden" (command not found). I can type > a degree sign in Kwrite if I run it with a real UTF-8 locale, but not with > the nonexistent en_419.UTF-8. > > I am in the USA and use metric. I'd like to select English or Spanish, with > the short form date being yyyy-mm-dd, 24-hour clock, A4 paper, decimal > point, and the week starting on Sunday, regardless of the language. I have > no trouble understanding decimal commas, but when I have a file of XYZ > coordinates separated by commas, with decimal points, and no thousands > separators, and throw it into a spreadsheet which, because of a Hispanic > locale, is expecting a decimal comma, the result is a mess. > > I'd like to see KLocale reinstated, at least until QLocale is as flexible as > KLocale. Yeah, I tried rolling my own locale because I knew that there would be some intransigence on this. And plus they said that it uses the system locale... lo and behold it works with the command line apps, but not with Qt/KDE. So I don't know... like I said, if they want to use the system locale, USE it, otherwise give us back KLocale. You know the phrase (modified for the younger audiences) "[poop] or get off the pot".
As has been explained before in this thread, the code does not really use the system locales, but a hardcoded list in QtCore. The system locales are only mapped to the hardcoded list. You have to patch and recompile QtCore if you want to add a custom locale.
(In reply to Kevin Kofler from comment #110) > As has been explained before in this thread, the code does not really use > the system locales, but a hardcoded list in QtCore. The system locales are > only mapped to the hardcoded list. You have to patch and recompile QtCore if > you want to add a custom locale. Then what's the point of this regression? Why not just go back to the way it was?
(In reply to phma from comment #102) > I'd like to see KLocale reinstated, at least until QLocale is as flexible as KLocale. My vote is to support this suggestion.
(In reply to Kevin Kofler from comment #110) > As has been explained before in this thread, the code does not really use > the system locales, but a hardcoded list in QtCore. The system locales are > only mapped to the hardcoded list. You have to patch and recompile QtCore if > you want to add a custom locale. Are there any better instructions about how to do such a patch than the "crude patch" already attached here?
It would be nice if the system recognized the locale to start with. One configuration. BUT, I do agree, on a multiuser system, there has to be recognition of personal choice. First fix should be to get all the valid local's into the hardcoded QTCore so they are recognized. Such as "Denmark - English (en_DK)" I would also add an ISO locale to the mix. Look at the ISO standard and create the best locale to recognize the standards as posted. I need ISO for work as that is part of our standards and being enforced more severely.
Same issue in Fedora 24 KDE spin.
@Robin Please don't muddy up this bugreport with unrelated requests. It's already too long, and adding a discussion here will make it longer to read, which reduces the time available to work on a fix. If you have a separate problem, please report a separate bugs as to avoid this report to become useless and harder to handle.
(In reply to Don Curtis from comment #112) > (In reply to phma from comment #102) > > I'd like to see KLocale reinstated, at least until QLocale is as flexible as KLocale. > > My vote is to support this suggestion. +++ KDE classes have served as inspiration for Qt improvements before, and working something out that works in/for KDE can have this effect again. Improvements to the locale functionality could also take the form of a framework (preferably Tier 1 I suppose). A glance at Qt's locale page linked above suggests they've embarked upon a thorough consideration of pros and cons of various approaches which is understandable but will not help speed up the arrival of a solution for Plasma 5 desktops. I'd think that it can only help (them and their thought processes) to have a modernised Qt5-based implementation of the KLocale solution from KDE4. FWIW: Qt5 and KF5 applications take locale settings from the host on Mac (e.g. dolphin5 uses the desired YYYYMMDD short date format for me); a KLocale class or framework shouldn't introduce regressions there, possibly even be a transparent wrapper.
Voting for customizability one way or another. My personal beef is with Finnish time format that has changed from sane hh:mm into insane hh.mm.
(In reply to hannu.alamaki from comment #118) > Voting for customizability one way or another. My personal beef is with > Finnish time format that has changed from sane hh:mm into insane hh.mm. Yes, I really don't understand the sources for these. It all seems a bit arbitrary. There's a similar bug where the first day of the week is hardcoded. Similarly, the selection is also arbitrary here: https://bugs.kde.org/show_bug.cgi?id=358106#c8
(In reply to hannu.alamaki from comment #118) > Voting for customizability one way or another. My personal beef is with > Finnish time format that has changed from sane hh:mm into insane hh.mm. I think it's some other issue (the changing the format to hh.mm) as it happens randomly with other locales (even en_US), too.
(In reply to RJVB from comment #117) > (In reply to Don Curtis from comment #112) > > FWIW: Qt5 and KF5 applications take locale settings from the host on Mac > (e.g. dolphin5 uses the desired YYYYMMDD short date format for me); a > KLocale class or framework shouldn't introduce regressions there, possibly > even be a transparent wrapper. > I have the feeling that in all the explanations as to "why this issue can not be resolved" something is being overlooked: 1. I have the impression that the KDE folks are attempting to produce a user GUI which will run in a 100% seamless fashion on any platform: MS Windows, Apple OS X, Apple iOS, Apple watch OS, Apple tvOS, Google Android, Google Chrome OS, Google Chromium OS, Oracle Solaris, IBM AIX, Blackberry 10, BSD, and, last but not least, Linux . . . 2. I have absolutely no idea of the "usage per platform" statistics of KDE but, I'm beginning to have the feeling that, the usage by the Linux community is currently a minority population, and therefore I am personally beginning to consider giving up on KDE as a valid Linux GUI.
Better get a grip on actual statistics before you make statements like that (and even then re-read it twice before posting). The only critique one can emit towards the "KDE folks" in general is that their attention seems to have shifted from basic low-level functionality like how date and time are shown to presumably more exciting stuff. Rest assured that also goes for similar low-level stuff on other platforms (e.g. the KWindowSystem plugin on Mac). Not really surprising after having kept up a crazy release cycle, but such is life. As to date/time format configuration and related locale issues: this is apparently largely a Qt issue which has to be addressed at that level.
(In reply to RJVB from comment #122) > The only critique one can emit towards the "KDE folks" in general is that > their attention seems to have shifted from basic low-level functionality > like how date and time are shown to presumably more exciting stuff. > So, it seems that the KDE folks are concentrating on "more exciting stuff", instead of continuing to support platform specific "stuff" such as "time", POSIX compliance, and, extended file attributes (another issue the Linux world currently has with the KDE Plasma 5 Dolphin implementation). If "more exciting stuff" has taken precedence over platform specific (POSIX, UNIX® and Linux) support, then my view remains: the current KDE Plasma 5 implementation will be moved to the bottom of my list of valid and viable User GUIs for the Linux platform.
KDE folks are aware this bug needs to be solved: « Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.» -- Sebastian Kügler https://vizzzion.org/blog/2016/10/plasmas-road-ahead/
(In reply to hannu.alamaki from comment #118) > Voting for customizability one way or another. My personal beef is with > Finnish time format that has changed from sane hh:mm into insane hh.mm. It's not "insane", but correct. And I hate it too. We just have gotten accustomated to colon because all alarm clocks whatever have been imported all our lives and *they* never gave a flying fsck about finnish standards. They used colon. If it needs fixing, someone has to start from where it has been defined, locally. SFS (http://www.sfs.fi) or something similar. And that's a long road. :-/
Well, there *is* a reason why I'm still using Kubuntu 14.04 with its "Plasma 4" desktop and run what's basically a home-brewn Neon5 parallel KF5 install. No "official" reaction on bug reports means that anyone who feels sufficiently concerned by an issue is not just welcome to propose a fix, but probably also quite free to apply it as long as it doesn't break anything obvious. But the quote of Sebastian's post above confirms what I wrote based on what I recalled reading: the date/time issue comes from QLocale. I know that the Qt folks are aware of it and from what I understand still debating how to address the issue. It does show that whatever solution KDE might bake downstream from QLocale will probably require patching all sources that now depend on QLocale. For better or for worse, designing a QLocale child class (KLocale?) that works exactly as it should might go against KDE's approach of how they extend Qt, but it *could* make an acceptable (basis for a) solution for Qt.
Could you please move the general thoughts, complaints and ideas on this to another medium? Anything that doesn't add technical data (and at this point, for this bugreports, that would be very specific traces, solutions, workaround or patches) just litters this bugreports with data that makes it harder to handle, and decreases the chance that someone picks it up and fixes underlying issues. Assumptions about project management, priorities, man-power, or simply unhappiness about the state of things do NOT belong into the issue tracker, putting it there makes things worse, not better. (Even if you feel better after venting.) Just imagine a developer having to sift through all the post, just to find the relevant bits of information buried here. It's not helpful at all. If this issue report becomes uneconomical due to signal to noise ratio, I'll close it and ask to reopen another report, with just the relevant information. Due to personal time constraints, I skip a post as soon as I get the impression that it's not contributing technical data to to the issue, unfortunately, I can't delete posts, but I surely would if that were possible. Thanks for the issue-tracker discipline, and please don't take this as a personal offense, it's just stating facts that not everybody may be aware of.
I was't sure if you were following this issue. How feasible would it be to derive QLocale to something like a KLocale class that provides the functionality missing from QLocale?
PS: probably not made any easier given that (as far as I can tell) QLocale works as one would expect on Mac (i.e. respecting system settings giving me my desired YYYYMMDD dates etc.) and presumably on MS Windows too.
I've explained that in comment#9 already.
(In reply to RJVB from comment #129) > PS: probably not made any easier given that (as far as I can tell) QLocale > works as one would expect on Mac (i.e. respecting system settings giving me > my desired YYYYMMDD dates etc.) and presumably on MS Windows too. Despite Apple OS X being a certified UNIX®, it seems that you're indicating that Qt and therefore also KDE are not supporting the POSIX ISO 15897 Locale definition used by Linux and other UNIX® implementations.
(In reply to Sebastian Kügler from comment #130) > I've explained that in comment#9 already. That comment explains that *using* KLocale would not be an option. I can understand that, to the extent that QLocale doesn't define the methods that would need overriding as virtual (which I haven't checked but presume isn't the case but it should be possible to make it the case in a potential solution). My question was about the possibility to derive QLocale into a class that provides the desired behaviour. This issue is clearly not important enough for the Qt guys to invest the required man-hours to fix it, so it might help getting things moving to present a working *complete* solution that's based on what exists currently. And for them too it might actually be an advantage if the solution extends QLocale. (In reply to Don Curtis from comment #131) > Despite Apple OS X being a certified UNIX®, it seems that you're indicating > that Qt and therefore also KDE are not supporting the POSIX ISO 15897 Locale > definition used by Linux and other UNIX® implementations. How am I indicating that? IIRC Apple's locale implementation is based on (and a wrapper of) ICU, and provides the same kind of configurability as Plasma 4 does. That's what I'm using to achieve my desired formats.
On Wednesday, February 8, 2017 8:40:06 AM EST you wrote: > 2. I have absolutely no idea of the "usage per platform" statistics of KDE > but, I'm beginning to have the feeling that, the usage by the Linux > community is currently a minority population, and therefore I am personally > beginning to consider giving up on KDE as a valid Linux GUI. Is usage by the Linux community a minority of Linux users or of KDE users? What about BSD? AFAIK locales work the same way on BSD as on Linux. Pierre
(In reply to phma from comment #133) > On Wednesday, February 8, 2017 8:40:06 AM EST you wrote: > Is usage by the Linux community a minority of Linux users or of KDE users? Either way, I'm beginning to suspect that, the number of Linux users who are choosing to use KDE as their user GUI are decreasing and, are therefore a minority in the KDE user community. > What about BSD? AFAIK locales work the same way on BSD as on Linux. > I have never, ever, used BSD. Only the KDE usage statistics could indicate if, a significant number of people using the BSD platform are using KDE as their user GUI.
Quite simply, we're not looking for a solution, the right solution has been proposed already. Someone needs to sit down and do the work, it's *that* simple. (I'm outta here, the amount of useless traffic this bugreport is generating just today is too much for me. I don't have time to work on it right now, anyway.)
(In reply to Sebastian Kügler from comment #135) > Quite simply, we're not looking for a solution, the right solution has been > proposed already. Someone needs to sit down and do the work, it's *that* > simple. There's a small difference between a proposed difference and one that only needs to be implemented from full draft, but above all it would have been useful to paste a pointer to that proposal here. Clearly not everyone is aware of its existence.
I found a workaround for this bug on the KDE Community Forum here: https://forum.kde.org/viewtopic.php?f=17&t=134970 The process creates a new digital clock widget placed in the users Home rather than altering the original Digital Clock widget in Root. It does involve a bit of file editing but I can confirm that it does work as I posted on that page here: https://forum.kde.org/viewtopic.php?f=17&t=134970#p376530 (also, note on my post there that I found an extra step was necessary to make it work, possibly because of a later version of Plasma 5).
FWIW after patching the widget for ages, more recently, my workaround has been to install awesome widgets [1], which lets you output any arbitrary command, e.g. date +'…' etc. [1] https://github.com/arcan1s/awesome-widgets
(In reply to Marco Schulze from comment #58) > It's now more than a year and (seemingly) nothing happened. I really don't > get it. KDE once was the best. Of course, there were some bumpy episodes > from time to time (e.g. when migrating from KDE 3.x to 4.x), but never > before, I experienced such a miserable failure: *Without* *any* *need*, you > removed a very important feature (!) and for over a year, you don't put any > effort in re-adding it. What's wrong with you guys? Are you trying to > convince people to migrate away from KDE?! > > I'm a software developer myself. And I certainly do not only think well > before removing a feature, but I would immediately make re-adding/repairing > it the highest priority, if this accidentally happened. Many users > complained (this issue has 754 votes, currently), but still there seems to > be no progress :-( > > So what's the state? Are you working on a solution? When is it expected to > be ready? ::ping:: And now we're in May of 2017, and still nothing. :-\
(In reply to sparhawk from comment #138) > FWIW after patching the widget for ages, more recently, my workaround has > been to install awesome widgets [1], which lets you output any arbitrary > command, e.g. date +'…' etc. > > > [1] https://github.com/arcan1s/awesome-widgets Fine, but: * Did you also include some openQA scripts to ensure that, your changes will get accepted by the Linux distributions which are beginning to really care about code quality? (Red Hat, SUSE, CentOS, openSUSE, Ubuntu, et al.)
(In reply to Don Curtis from comment #140) > Fine, but: > * Did you also include some openQA scripts to ensure that, your changes > will get accepted by the Linux distributions which are beginning to really > care about code quality? (Red Hat, SUSE, CentOS, openSUSE, Ubuntu, et al.) …no? I just patched the clock plasmoid locally. It was just a hack to hard-code the format.
Recently openSUSE TW upgraded to Qt 5.9, and now en_DK is available as a time format. But guess what, it gives "05/07/2017 14.52". Why?
(In reply to Christos Gourdoupis from comment #142) > Recently openSUSE TW upgraded to Qt 5.9, and now en_DK is available as a > time format. But guess what, it gives "05/07/2017 14.52". Why? Works for me on openSUSE Tumbleweed with libQt5 5.9.1. If it still doesn't work for you, an openSUSE-specific mailing list/form/issue tracker might be a better place to discuss it.
(In reply to Malte Eggers from comment #1) > To set your locale to use ISO 8601, you have to set LC_TIME=en_DK. For anyone doing this on a per-application basis (rather than putting it in $HOME/.profile), there is the problem that the language setting does not get saved with the KDE session. I have filed a separate issue for this with the session management product: Bug 382764.
Whilst googling in relation to Qt's locale support I came across this: Locale Support in Qt 5 https://wiki.qt.io/Locale_Support_in_Qt_5 ... which may be of some interest to people who've posted in this thread.
(In reply to Paul from comment #145) > Whilst googling in relation to Qt's locale support I came across this: > > Locale Support in Qt 5 https://wiki.qt.io/Locale_Support_in_Qt_5 > > ... which may be of some interest to people who've posted in this thread. The Qt document mentions "ICU" (Open Source -- Unicode License) -- which is a result of work done by Taligent, IBM and Sun (Java). The Qt 5 paper seems to be a little bit out-of-date: * openSUSE Leap has ICU 52 libraries. ** The Windows 10 Creators Update has integrated ICU into Windows -- "making the C APIs and data publicly accessible." (original Redmond text). <https://msdn.microsoft.com/en-us/library/windows/desktop/mt823414(v=vs.85).aspx>
*** Bug 384296 has been marked as a duplicate of this bug. ***
(In reply to Rod J from comment #137) > I found a workaround for this bug on the KDE Community Forum here: > https://forum.kde.org/viewtopic.php?f=17&t=134970 Thank you! Came here because I also use Dutch locale with English language. Then, Digital Clock decide to format mm/dd/yy short date, which is not only confusing but also wrong since my date locale says nl_NL?
not a solution at all, but an ugly workaround. on fedora 27 (plasma 5.10.5): add "LC_TIME=en_DK.UTF-8" to /etc/locale.conf in kde, set "System Settings" -> "Regional Settings" -> "Formats" -> "Time" to "Sweden - English (en_SE)" for some reason, the en_DK definition in qt/kde5 has the wrong date order, but en_SE (which i've never heard of and doesn't exist in the system locale database) has the correct one. this will give you: english long date iso short date (YYYY-MM-DD) 24-hour clock
(In reply to weed from comment #149) > not a solution at all, but an ugly workaround. > > on fedora 27 (plasma 5.10.5): > > add "LC_TIME=en_DK.UTF-8" to /etc/locale.conf > in kde, set "System Settings" -> "Regional Settings" -> "Formats" -> "Time" > to "Sweden - English (en_SE)" > > for some reason, the en_DK definition in qt/kde5 has the wrong date order, > but en_SE (which i've never heard of and doesn't exist in the system locale > database) has the correct one. > > this will give you: > > english long date > iso short date (YYYY-MM-DD) > 24-hour clock This is a kludge but WFM.
For me the way the date/time is displayed on the panel has always been my pet peeve with Plasma 5. This can now be changed to show the date/time in any way you want (how it always used to be) by installing the "Event Calendar" widget as a replacement for the standard calendar. The Event Calendar widget has all sorts of extra goodies too. Check it out! :-)
I found his hack that might be helpful, its not a solution by any means, but it is useful until a real solution comes out. The things is though, the part about font changes doesn't seem to apply (any ideas on that part?) https://www.ulduzsoft.com/2017/08/custom-date-configuration-in-kde-plasma-digital-clocks/ I was able to set my date in Leap 15 Tumbleweed to (for example) 09:00:03 Wed Sept 20,2018 I had to reboot to get it to come up right as the killall plasmashell; kstart5 plasmashell; didn't work even if i did an export $(dbus-launch) beforehand, but the date format was honored after rebooting. After seeing this work, I am wondering why kde cant do this or something along these lines.
I also discovered an add-on widget that allows you to set the date and time format to whatever you want including font size color and bold/nobold. Its called eventCalendar. I have tried it in both Leap 42.3 and Tumbleweed and it works great. My question is - if this widget can do it why can't KDE in general do it?
Because that widget does its own date/time formatting and does not use Qt or KDE Frameworks classes.
Git commit 235fa8107dabb757d88cd1876309c12cad990207 by Chris Holland. Committed on 14/01/2019 at 01:53. Pushed by cholland into branch 'master'. [Digital Clock] Add ability to set a custom date format string Adds a new customDateFormat config key which is used when the dateFormat "StringEnum" is set to custom. Shows a link to the Qt time formatting documentation next to the text field. Qt doc link and text field are hidden when not set to custom date format. Differential Revision: https://phabricator.kde.org/D18019 M +5 -1 applets/digital-clock/package/contents/config/main.xml M +8 -6 applets/digital-clock/package/contents/ui/DigitalClock.qml M +26 -0 applets/digital-clock/package/contents/ui/configAppearance.qml https://commits.kde.org/plasma-workspace/235fa8107dabb757d88cd1876309c12cad990207
I'd like to use yyyy-MM-dd format on en_US locale (not en_DK). So I rebuilt Qt5 on Debian 10 as a workaround: https://github.com/hikaen2/qtbase-opensource-src-5.11.3-dfsg1 It works, but I think it is bad solution. Are there any solutions?
Or at least something that accepts the same args as the "date" command: date "+%Y-%m-%d %H:%M:%S"
I like Elmo's idea. It makes a lot of sense. Support for the same format specifiers as the date command would support everyone. +1 votes for Elmo R :-)
Dolphin 20.04 does not allow iso date format whatever system language is (FR, DE, RU, etc.)
(In reply to Chris Holland from comment #155) > Git commit 235fa8107dabb757d88cd1876309c12cad990207 by Chris Holland. > Committed on 14/01/2019 at 01:53. > Pushed by cholland into branch 'master'. > > [Digital Clock] Add ability to set a custom date format string > > Adds a new customDateFormat config key which is used when the dateFormat > "StringEnum" is set to custom. > Shows a link to the Qt time formatting documentation next to the text field. > Qt doc link and text field are hidden when not set to custom date format. > > Differential Revision: https://phabricator.kde.org/D18019 > > M +5 -1 applets/digital-clock/package/contents/config/main.xml > M +8 -6 applets/digital-clock/package/contents/ui/DigitalClock.qml > M +26 -0 applets/digital-clock/package/contents/ui/configAppearance.qml > > https://commits.kde.org/plasma-workspace/ > 235fa8107dabb757d88cd1876309c12cad990207 This is perfect! It lets me set the date view in just the way that works for me, separate from any standards. Now, PLEASE can someone just add the same custom function for the **time** view? In my case, I want 12-hour time *without* showing the AM/PM part (particularly because I have a left-side panel and much less room for the numbers, so it's too small with the AM/PM shown.
Please note that this bug is about user-wide date format configuration, not just about the clock applet.
(In reply to Serhiy Zahoriya from comment #161) > Please note that this bug is about user-wide date format configuration, not > just about the clock applet. Thank you Serhiy, is there an existing ticket for this for the clock applet? If not, may I open one? I was searching and wasn't finding the right specific clock applet tickets.
> is there an existing ticket for this for the clock applet? If not, may I open one? I was searching and wasn't finding It may not exist if you didn't find it, yes. Please create it. I mean for changing time format option.
If you open a clock ticket can you please post the link here too?
(In reply to k3bBug from comment #164) > If you open a clock ticket can you please post the link here too? I found a relevant open ticket and updated it: https://bugs.kde.org/show_bug.cgi?id=393956 (incidentally, I was initially confused because I didn't realize I had to go to plasmashell and then find the Digital Clock as a product within that)
I've been annoyed by this issue as well, but I have found a workaround for the time being if you use English. It involves creating the pseudo-locale en_SE which uses the proper ISO 8601 format but still has months and weekdays in English. Do the following: sudo ln -s /usr/share/i18n/locales/en_DK /usr/share/i18n/locales/en_SE echo 'en_SE.UTF-8 UTF-8' | sudo tee -a /etc/locale.gen sudo locale-gen Then you may have to re-login before setting your time format in System Settings to "Sweden - English (en_SE)". This fixed it for me in Dolphin and other programs, however applications that use the long date format still don't use ISO 8601. Ideally we need something better than the archaic pre-defined UNIX locales, and this lack of flexibility looks bad compared to Windows and Mac desktops. However I don't really know whose role it is to fix that.
Also irked at this issue! Trying to set default language to en_au, and use 24hr time....
*** Bug 429345 has been marked as a duplicate of this bug. ***
I haven't commented on this issue before, because I am lucky? Things work for me well, but not without few attempts. I did the following: I made a complete system image backup using dd for quick recovery. I do that every time Debian has a new release. My KDE4 worked just fine, but things did not work few times when I attempted to upgrade my systems. Currently my KDE5 behaves well: I have long date YYYY-MM-DD and 24hr clock hh:mm:ss. By conducting careful upgrades I managed to defeat the 12hr (AM/PM idiocy) My locale reports: ANG=en_CA.UTF-8 LANGUAGE=en_CA.UTF-8 LC_CTYPE="en_CA.UTF-8" LC_NUMERIC="en_CA.UTF-8" LC_TIME="en_CA.UTF-8" LC_COLLATE="en_CA.UTF-8" LC_MONETARY="en_CA.UTF-8" LC_MESSAGES="en_CA.UTF-8" LC_PAPER="en_CA.UTF-8" LC_NAME="en_CA.UTF-8" LC_ADDRESS="en_CA.UTF-8" LC_TELEPHONE="en_CA.UTF-8" LC_MEASUREMENT="en_CA.UTF-8" LC_IDENTIFICATION="en_CA.UTF-8" LC_ALL=en_CA.UTF-8 I remember keeping out of Regional Settings, where under Formats I have Time: Canada (iu_CA) As I can see I never touched Time & Date because date is good but time is not (12hr). Yet, the time in the task bar is correct. Mind you, I decided to keep kdm at all cost, so maybe this is why things sort of work for me?
Git commit f0d03c7dd7ae8496714483b73cfab1b1708c6ad3 by Méven Car. Committed on 24/12/2020 at 00:11. Pushed by meven into branch 'master'. Details View: display dates as relative Short dates M +17 -4 src/kitemviews/kfileitemlistwidget.cpp M +4 -0 src/settings/dolphin_detailsmodesettings.kcfg M +28 -1 src/settings/viewmodes/viewsettingstab.cpp M +2 -0 src/settings/viewmodes/viewsettingstab.h https://invent.kde.org/system/dolphin/commit/f0d03c7dd7ae8496714483b73cfab1b1708c6ad3
*** Bug 396135 has been marked as a duplicate of this bug. ***
*** Bug 236311 has been marked as a duplicate of this bug. ***
*** Bug 370365 has been marked as a duplicate of this bug. ***
113 users 1503 votes has high First report date back nearly 6 years ago. A bunch of duplicated bug reports closed (time waste). No bug dependency reported. In my humble opinion, amongst the list of bugs, I believe this ought to be fixed, now and not in a couple of years.
*** Bug 395450 has been marked as a duplicate of this bug. ***
*** Bug 348071 has been marked as a duplicate of this bug. ***
*** Bug 430275 has been marked as a duplicate of this bug. ***
*** Bug 374410 has been marked as a duplicate of this bug. ***
*** Bug 348069 has been marked as a duplicate of this bug. ***
*** Bug 348068 has been marked as a duplicate of this bug. ***
After 7 years, apparently KDE has no intent to fix this bug. Why? I have no idea, maybe they just don't think its worth their time. Hey KDE, at least have the decency to change the bug's status to "CLOSED - WILL NOT FIX" with an explanation as to why.
To my knowledge, fixing this requires one of the following: 1. Change the Qt locale system to support the feature 2. Abandon the-in Qt locale system for this and implement a completely custom system, like the KLocale system we had in the KDE 4 days but moved away from in favor of QLocale Either one would be a huge amount of work. I wasn't around for the KDE 4 days, but if I had been, I probably would have been against abandoning KLocale (which could do this) for QLocale (which can't). That switch also introduced Bug 394698, which is the other major annoyance with this KCM. So in retrospect I personally think that switch may have been a mistake, but what's done is done. Hopefully we can learn from that mistake and do better in the future. Since fixing this is not a trivial task, it will probably take a while and require a senior developer.
(In reply to Nate Graham from comment #182) > To my knowledge, fixing this requires one of the following: > 1. Change the Qt locale system to support the feature > 2. Abandon the-in Qt locale system for this and implement a completely > custom system, like the KLocale system we had in the KDE 4 days but moved > away from in favor of QLocale > > Either one would be a huge amount of work. > > I wasn't around for the KDE 4 days, but if I had been, I probably would have > been against abandoning KLocale (which could do this) for QLocale (which > can't). That switch also introduced Bug 394698, which is the other major > annoyance with this KCM. > > So in retrospect I personally think that switch may have been a mistake, but > what's done is done. Hopefully we can learn from that mistake and do better > in the future. Since fixing this is not a trivial task, it will probably > take a while and require a senior developer. Then (as cat22 noted in comment #181) this should be the explanation in the *CLOSED - WILL NOT FIX* resolution. It's ridiculous that this bug sits open with no intent to fix it.
My apologies for the double post.
I began to use PC and to try to use Linux-KDE (Mandriva was the most convenient distro of that time) almost simultaneously. I was about 18 years old and it was early 2000. Now I am 40 years old and I can say that when I eventually die - there probably will be Windows on my laptop. (And Linux on my servers.)
(In reply to Nate Graham from comment #182) > To my knowledge, fixing this requires one of the following: > 1. Change the Qt locale system to support the feature > 2. Abandon the-in Qt locale system for this and implement a completely > custom system, like the KLocale system we had in the KDE 4 days but moved > away from in favor of QLocale > > Either one would be a huge amount of work. Isn't this exactly where OOC should make things straightforward if not easy? Just how much work would it be to clone (inherit) QLocale, merge/port the required functionality from KLocale (which I presume is or was in kdelibs4support at some point) and then (once properly debugged) do a search/replace on all the code in the frameworks, plasma and applications repositories to use the new class instead of QLocale? The amount of change could be huge, but maybe even that would be less than one might think if code using QLocale always imports qlocal.h . In that case, only that header has to be replaced with the new header, and the appropriate `using` expression. [OT] WHT happened to BKO? All of a sudden it looks as if designed for someone with a visuomotor handicap and a huge screen?! [/OT]
Would it really be that much work to resurrect the old KLocale class from kdelibs 3, forward-port it to Qt 5 or 6 and stuff it into a new Framework? Then it would just be a matter of porting applications from QLocale to that Framework. (For some, it might even just be a matter of finding the old porting commit and reverting it, plus adding one dependency to the new Framework.)
The old kdelibs 3 code can be found here: https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/3.5/kdecore/klocale.cpp https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/3.5/kdecore/klocale.h
Yeah, if anyone wants to bring back KLocale and port everything to it, that would be a path forward.
Or better yet, submit everything upstream to QLocale. That would be even better. IIRC that was what was supposed to happen during the Qt5 timeframe, but it never happened, so we wound up with a crippled QLocale and lost the nice user-friendly KLocale features. In any similar situation in the future, I would like to extract a guarantee that the code is submitted and accepted upstream FIRST before people port stuff away from it! :)
Nate, I really appreciate showing up and answering this issue, but really, this state of things is simply not acceptable. I am not a developer, I don't know how to handle pointers and structs and such, but this stuff should REALLY be fixed asap. I would urge you to get some KDE dev to fix this somewhat, be it as an ugly hack or by a harmonious refactoring. I do not care, really. What I care is that this is a bug reported over SEVEN YEARS ago, opened and biting over two Plasma full major version releases and two Qt versions, and is still there, still confusing for inexperienced users. Or, at least in the next (minor) release, under a document identified as "Known Issues", document the issue and any workaround if possible. That, at the very least.
A reminder to all the demanding commenters: this is an opensource community project. It is OK to be disappointed or sad - but the energy that is put in demands would be much better put elsewhere. One might be able to help with documentation, bug triaging or testing to give more time to developers - or put a bounty on a particular feature (like adding this functionality in QLocale). [Please feel free to hide this comment and others, not contributing technically.]
(In reply to richlv from comment #193) > A reminder to all the demanding commenters: this is an opensource community > project. > It is OK to be disappointed or sad - but the energy that is put in demands > would be much better put elsewhere. > One might be able to help with documentation, bug triaging or testing to > give more time to developers - or put a bounty on a particular feature (like > adding this functionality in QLocale). > > [Please feel free to hide this comment and others, not contributing > technically.] Rich, All I can say is Ouch! Your comment is nasty. While I am convinced that all the commenters are aware that this is open source software all of us believe that it does not matter if it is, the point is "It should be done right" and it isn't. The whole world except anybody that has to do with US (not the military) uses 24hr clock and not the AM/PM. Let me remind you and some other commenters that I am using hybrid system with kdm with its related libs, this way I managed to stay with 24hr clock. I refuse to dump kdm, because I like it. My clocks are 24hr clocks, but every time I messed with the kde system things got bad. I am going to end by saying that if all fails and I must I'll dump the kde. The only reason why I keep using it is because I got used to some packages, but thanks to the desktops Open Source provides I'll dump it in the blink of an eye when things get to difficult (LXDE seems like a good choice). Thanks for you efforts anyway.
(In reply to richlv from comment #193) > A reminder to all the demanding commenters: this is an opensource community > project. > It is OK to be disappointed or sad - but the energy that is put in demands > would be much better put elsewhere. > One might be able to help with documentation, bug triaging or testing to > give more time to developers - or put a bounty on a particular feature (like > adding this functionality in QLocale). > > [Please feel free to hide this comment and others, not contributing > technically.] It was a matter of time for a comment like this to appear. "Shut up and work instead of whining!" I try to do my best. Today it's reporting bugs in the best possible way; I simply do not have the time or money to do something else. But if you're interested, I was part of the Spanish KDE Localization team for 10 years, 2002 to 2012. My name is here: https://es.l10n.kde.org/colaboradores.php - Are you satisfied now? Do I have permission to report bugs now?? All in all, this does not invalidate the bug nor the unacceptability of its presence. It should be fixed, that's all.
If this were fixed, it would also likely make it easier to resolve https://bugs.kde.org/show_bug.cgi?id=393956 Hesitant to just add another +1, but this issue is *so* awkward. The simple capacity to override default formats with simple standard format codes ought to be trivial for anyone. I just want the logical ISO date format YYYY-MM-DD while keeping other U.S. norms, including 12-hour time (and no, 12-hour is not just some weird American thing, it's how all analog clocks work). I figured out that en_CA for Time works enough, but the extra dots in A.M. and P.M. are silly and take too much extra space. At least that workaround is possible, but this is not how it should be functioning. People lamenting a *regression* where things were fine and then a new design broke things is not the same as people demanding that free/libre/open software just magically have all the features they wish. And what bug-reporters want is mostly to have the bugs acknowledged completely. There's nothing about Open Source development that makes it any harder to simply say "yes, this is indeed a bad bug". Admitting that it's bad is not the same as a commitment to fix it promptly. There's no room for any comment that tries to be dismissive about the facts of the bug or downplay that it's bad.
The bug is acknowledged. It's marked as CONFIRMED with a VHI ("very high") priority and various technical people have shown up to offer thoughts on how to proceed with resolving it. At this point the best way to make that happen is to let them have that conversation without adding a bunch of comments saying things like, "+1, this is so bad!" and "OMG how did you let this happen?!" "and I've given up hope, KDE sux". Yes, we know it's bad, but clearly there is some desire to fix it among the developers. So let's let that happen. If you want to express your feelings about how bad this is and urge a quicker resolution, feel free to send them directly to me at nate@kde.org instead of posting a comment. Thanks.
(In reply to Nate Graham from comment #197) > The bug is acknowledged. It's marked as CONFIRMED with a VHI ("very high") > priority and various technical people have shown up to offer thoughts on how > to proceed with resolving it. At this point the best way to make that happen > is to let them have that conversation without adding a bunch of comments > saying things like, "+1, this is so bad!" and "OMG how did you let this > happen?!" "and I've given up hope, KDE sux". Yes, we know it's bad, but > clearly there is some desire to fix it among the developers. So let's let > that happen. > > If you want to express your feelings about how bad this is and urge a > quicker resolution, feel free to send them directly to me at nate@kde.org > instead of posting a comment. > > Thanks. and yet, nothing has been done in 7 years so apparently CONFIRMED with a VHI ("very high") priority don't mean what it says? My guess is no one is even looking at this or just dismissing it as "to involved or to hard" To me, i would think it shouldn't take more than writing a function that does the work and a few lines of code to decide whether to call it or not. It just can't be so difficult that someone couldn't fix it in an afternoon. Be honest and change the status to "WILL NOT FIX" and we can be done with this bickering
(In reply to cat22 from comment #198) > To me, i would think it shouldn't take more than writing a function that > does the work > and a few lines of code to decide whether to call it or not. It just can't > be so difficult that > someone couldn't fix it in an afternoon. > Be honest and change the status to "WILL NOT FIX" and we can be done with > this bickering Your expectations on how hard this would be is unrelated to how hard and how much work it actually is. Yes it sucks to have a bug for 7 years, but there might be more urgent and higher priority problems to solve first, take a look at the bug list. I would suggest you stick to the technical discussion. You and many other people have made clear about your frustration on this issue, there is no need to keep pushing.
I did my +1 to this bug in 2016, and this issue appeared to be trivial at the time for me, a fellow (naive) C++ developer, and a big fan of KDE Plasma. It is a bit hard for me to fathom that such a seemingly trivial issue, not even a bug but oversight in my eyes, couldn't be fixed easily. The comments here suggest that the issue stems from a design oversight, in that KDE Plasma is incapable of using user defined time/date formats independently of a system-wide locale. Could there be an option to create another system-wide locale which forks an existing locale, but overrides date-time format (and other formats, if desired), and could be used by KDE Plasma? May be a locale that overrides date-time formats with ISO ones? I wanted to take a look into this issue but couldn't find easy guides how to check out KDE Plasma source, build it, and run it without destroying my existing KDE Neon desktop environment. That was in 2016, may be things changed for better since then. This is a rather annoying and unexpectedly difficult bug for the most configurable DE, IMO, which is KDE Plasma. It didn't prevent me from doing my tasks though, I can still sort by date asc/desc in Dolphin and that works as expected. The dates and times don't look ISO-well-formed, but Dolphin does sort by the timestamp correctly, and that's usable enough. Elsewhere, I use: * In `bash`: `alias ll="ls -al --time-style=long-iso --block-size=\'1"` * In `emacs`: `(custom-set-variables ... (dired-listing-switches "-al --time-style=long-iso --block-size='1") ... )`
Well, the thing is, Qt does not actually use the system-wide locales, i.e., glibc/POSIX locales. What it does is map the glibc locale to a Unicode locale and then use that with ICU and/or with bundled copies of Unicode tables within Qt. So just inventing a glibc locale would not fix it, because it would not map to anything in Qt. And the tables in Qt are hardcoded and cannot be extended at runtime. IMHO, the whole QLocale system should be thrown away / ignored / blacklisted (just like, e.g., QHttp) and KDE code ported to a resurrected KLocale (based on the old kdelibs 3 code, not on QLocale) instead.
(In reply to Kevin Kofler from comment #201) > Well, the thing is, Qt does not actually use the system-wide locales, i.e., > glibc/POSIX locales. What it does is map the glibc locale to a Unicode > locale and then use that with ICU and/or with bundled copies of Unicode > tables within Qt. So just inventing a glibc locale would not fix it, because > it would not map to anything in Qt. And the tables in Qt are hardcoded and > cannot be extended at runtime. > > IMHO, the whole QLocale system should be thrown away / ignored / blacklisted > (just like, e.g., QHttp) and KDE code ported to a resurrected KLocale (based > on the old kdelibs 3 code, not on QLocale) instead. I am not sure if begging open-source developers ever worked, because someone has to pay the work, unless the developer wants to make a name with changes for themselves, which could be a quite tall order here. Would you like to spec the changes, as well as time and money required to materialize those changes? Or anyone else still listening to this conversation? With that we can try crowdfunding the change and see what happens?
Since blaming all of this on Qt is the default: you can actually hire them to implement or change something in Qt. Personally I think that the fact that KDE is built on Qt doesn't change the fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for most if not all of its classes that were/are merged into Qt or (will be) replaced by an appropriate Qt class. The present issue is annoying, but not to the same extent as the equally old QStandardPaths issue on MSWin and Mac, which could also have been avoided much more easily if the old KStandardSomething had been kept around to tweak!
(In reply to hannu.alamaki from comment #118) > Voting for customizability one way or another. My personal beef is with > Finnish time format that has changed from sane hh:mm into insane hh.mm. I find it strange too. Except found out some time ago, that it's now correct https://www.kielikello.fi/-/kellonaikojen-merkitseminen
(In reply to RJVB from comment #203) > Since blaming all of this on Qt is the default: you can actually hire them > to implement or change something in Qt. > > Personally I think that the fact that KDE is built on Qt doesn't change the > fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for > most if not all of its classes that were/are merged into Qt or (will be) > replaced by an appropriate Qt class. > The present issue is annoying, but not to the same extent as the equally old > QStandardPaths issue on MSWin and Mac, which could also have been avoided > much more easily if the old KStandardSomething had been kept around to tweak! Funny, one of the first things I did for QT was code a date/time picker and color chooser because it was lacking... in '98 :)
(In reply to Elmo R from comment #205) > (In reply to RJVB from comment #203) > > Since blaming all of this on Qt is the default: you can actually hire them > > to implement or change something in Qt. > > > > Personally I think that the fact that KDE is built on Qt doesn't change the > > fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for > > most if not all of its classes that were/are merged into Qt or (will be) > > replaced by an appropriate Qt class. > > The present issue is annoying, but not to the same extent as the equally old > > QStandardPaths issue on MSWin and Mac, which could also have been avoided > > much more easily if the old KStandardSomething had been kept around to tweak! > > Funny, one of the first things I did for QT was code a date/time picker and > color chooser because it was lacking... in '98 :) So, I cannot edit my comment, but I would like to add to that comment that a strftime type formatting would be immensely helpful. (e.g.: date command to strftime ╰─$ date +%Y%m%d-%H:%M:%S 20220805-12:43:55
The latest discussions about a QT-side change are here: https://bugreports.qt.io/browse/QTBUG-58351 I don't want to jump to conclusions before the discussion has progressed, but I think QLocale may not be the right tool for the job. It is effectively just a string formatting class, but I am not sure Qt will be willing to expand its scope to include formats that are not tied to "locales". They seem pretty married to the "localization" point of view where everything is regions and languages. Maybe Plasma and the KDE applications should start adding custom formats, or maybe we can revive KLocale. But this comes at the cost of losing consistency with pure Qt and other applications that do not use KDE frameworks.
(In reply to Nate Graham from comment #197) > The bug is acknowledged. It's marked as CONFIRMED with a VHI ("very high") > priority and various technical people have shown up to offer thoughts on how > to proceed with resolving it. At this point the best way to make that happen > is to let them have that conversation without adding a bunch of comments > saying things like, "+1, this is so bad!" and "OMG how did you let this > happen?!" "and I've given up hope, KDE sux". Yes, we know it's bad, but > clearly there is some desire to fix it among the developers. So let's let > that happen. > > If you want to express your feelings about how bad this is and urge a > quicker resolution, feel free to send them directly to me at nate@kde.org > instead of posting a comment. To take a different approach: does anyone have an estimate of the amount of money that would be needed to motivate someone with the necessary knowledge to fix this? If many people are affected by it they might be willing to pay for it.
(In reply to brenbarn from comment #208) > > To take a different approach: does anyone have an estimate of the amount of > money that would be needed to motivate someone with the necessary knowledge > to fix this? If many people are affected by it they might be willing to pay > for it. I don't think it's only a matter of motivation. It doesn't sound like a concrete path forward has been agreed upon yet.
Per the upstream discussion in https://bugreports.qt.io/browse/QTBUG-58351, this unfortunately isn't something we can feasibly fix in KDE alone. It doesn't even seem like something that can be done in Qt alone! Because the mapping of locales to both string formatting and also translated text is baked into the POSIX and libc implementation of locales, it really needs to be fixed there. If it's fixed at a level any higher than that, then the result would simply be applications not respecting your formatting preferences in a random-seeming manner. If it was done only in Qt, then all non-Qt apps would be non-respecting, and if we did it in KDE itself (as we did in Plasma 4 and earlier), then all non-KDE apps would be non-conforming, even those that use Qt. It would be a matter of winning the battle but losing the war. So someone needs to get the ball rolling at the POSIX and libc levels to propose a new spec, or backwards-compatible changes to the existing one.
Is the status supposed to be "resolved upstream"?
Yes, that means it's upstream's job to change/fix/implement/etc. See https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean
(In reply to John Brooks from comment #211) > Is the status supposed to be "resolved upstream"? Yeah, I agree. It's not resolved. People discussing the idea that the best resolution is upstream is not itself resolution nor does it seem that there's consensus on waiting for upstream resolution. It's obviously *possible* (though maybe a bad idea) to create a downstream override.
Again, please see https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean. In this context, "RESOLVED UPSTREAM" does not mean, "it's already fixed upstream." It means "It's upstream's job to fix." This is technical terminology; please don't read the word "RESOLVED" and interpret that to mean "it's already fixed for me personally." That's not what it means. If that's confusing to you, I understand, but re-read https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean and try to understand that this is a technical context where words sometimes mean something different from their plain English meaning. As I said, if we do our own thing to fix it for only KDE apps, or only for Qt apps, we make apps' presentation of formats inconsistent across the OS. This would work, but it's not a good solution, especially today given how people use apps form diverse sources. We can't just say, "we'll fix this for KDE or Qt apps and screw everyone else." That's not fair for the user. The user deserves a proper fix that doesn't make anything worse for their 3rd-party apps. That's why it needs to be fixed by overhauling how POSIX locales work.
With this bug remaining unresolved (in the colloquial sense ;)) for nearly a decade now however, doesn't that seem like a matter of letting the perfect be the enemy of the good? It certainly seems like if we're holding out for a change at that low of a level, we'll be holding out forever.
I don't have particularly high hopes for amending POSIX to fix this, to be honest.
(In reply to John Brooks from comment #216) > I don't have particularly high hopes for amending POSIX to fix this, to be > honest. That is why KDE pre-5 (and gnome) did what it did. And could do again.
(In reply to Nate Graham from comment #214) > As I said, if we do our own thing to fix it for only KDE apps, or only for > Qt apps, we make apps' presentation of formats inconsistent across the OS. > This would work, but it's not a good solution, especially today given how > people use apps form diverse sources. We can't just say, "we'll fix this for > KDE or Qt apps and screw everyone else." That's not fair for the user. The > user deserves a proper fix that doesn't make anything worse for their > 3rd-party apps. That's why it needs to be fixed by overhauling how POSIX > locales work. It sounds like what you're saying is, "if we fix it in KDE, it will be broken in non-KDE apps". But if we don't fix it in KDE, then it will be broken for all apps, including KDE and non-KDE apps. I would rather have it work the way I want at least some of the time than none of the time. To say it's "not fair to the user" to have it work some of the time and not all of the time seems a bit disingenuous. It's also not fair to the user to have it work none of the time. Also, an alternative I've been exploring is creating a custom locale. As I understand it, the problem with the Qt system is that they hard-code specific locale information into their own lib. On the Qt end, that could be changed by, well, having them not do that, and having it draw on a set of locale files in some standard location on the filesystem. Then what KDE could provide is a "locale editor" program that simply allows the user to input their preferences, and saves that in the form of a custom locale file. There's no reason for Qt or KDE or POSIX to know or care whether a "locale" file actually corresponds to any country or place; it's just a file that contains settings about how to display things. The fundamental issue, as I see it, is that for many people these are not "locale" settings. They are individual user preferences. People want to set their personal combination of date format, time format, first day of the week, etc., totally independent of any location in the physical world or the jurisdiction of any country. If POSIX defines that in terms of locales, that is indeed a problem, but the way to get around that is for KDE to give users the tools to fake out POSIX by making their own locale that provides a combination of settings that the user personally prefers. (I seem to have sort of gotten such a system working using some info I gathered from various places on the web where I found people complaining about this bug, although I'm not sure it's 100% working.)
And what happened to the "there are no [more] KDE apps" (certainly not as opposed to "mere" Qt apps) I got whacked with only a few years back, when the KF5 frameworks were nothing more and nothing less than a set of extensions from which any Qt application could make a pick? > People want to set their personal combination of date format, time format, first day of the week, etc., totally independent of any location in the physical world or the jurisdiction of any country. I plead guilty. A reintroduction of the old KLocale class would have my vote, altering POSIX and/or libc not. If that means changing how the current locale functions work such an overhaul will probably take years before it starts to trickle down to the most adventurous distros and from there into Qt, GTk, KDE etc. I see more promise in developing the updated functionality in a dedicated library.
One issue is that dropping a locale file into a folder for glibc will not be sufficient to fix it, because Qt does not actually use POSIX locales internally, but ICU locales, and has a hardcoded mapping from POSIX to ICU locales. So, for a custom glibc locale to work, Qt would need to be changed to use the POSIX APIs instead of ICU ones, and that would likely mean that POSIX, or at least glibc's implementation of it, would have to grow some additional locale APIs that Qt needs. (Last I checked, the maintainers of the Qt locale codes claimed that the POSIX/glibc locale APIs are not sufficient for their needs.) I still think that, as I had written in comment #6, KDE should just go back to using a KDE-specific locale and formatting implementation and bypassing the inferior Qt, POSIX, and ICU ones.
(The POSIX, ICU, and Qt implementations are all based on a closed set of locales determining all formatting preferences at country granularity. I do not see that ever changing, because it is a core design principle. And it is a very bad concept, because not everyone in a, possibly large, country agrees on the correct format to use. Even in a small country like Austria, dates can be (and in practice are) formatted as 1.1.2022, 01.01.2022, 1.1.22, etc., currency amounts can be formatted as 12,34€, 12,34 €, €12,34, etc., some people might even want to use 12€34 to match the spoken version, though I do not remember having it ever seen spelled like that. I would expect even more variance in large countries such as the USA.)
Doesn't Qt have to be configured to use ICU, or is that only on non-linux/unix platforms (Mac included)? ICU uses hardcoded locale definitions? FWIW, the specialty library approach I mentioned could of course provide suitably amended forks of the ICU and/or libc/POSIX locale functions, which would override those in ICU and/or libc. Doing this carefully enough it should be possible to avoid risk of ODR/ABI issues - I suppose. Heck, the new behaviour could even be conditional on something like an env. variable that "deviant" users like us would have to set. I agree that ICU nor POSIX are likely to change their implementations without a sufficient body of evidence that an alternative implementation is backwards compatible in ABI, API *and* behavioural terms. With enough evidence of demand for an optional different behaviour, however, they could not reject a merge request as introducing unjustified code complexification...
(In reply to RJVB from comment #222) > should be possible to avoid risk of ODR/ABI issues - I suppose. Heck, the > new behaviour could even be conditional on something like an env. variable > that "deviant" users like us would have to set. I agree that ICU nor POSIX LD_PRELOAD anyone? >:^)
One argument was that if an option is implemented in systemsettings (and not in ICU/Qt/POSIX), then the behaviour of the plasma desktop will be inconsistent with non-KDE applications are going to display differently than GTK/etc. when tuning the date option in systemsettings. This argument applies to plasma desktop, but KDE goes beyond that. I personally use KDE applications but my main system does not use plasma and I think this is a legitimate use case scenario for which the KDE developers should propose a solution. Now let's have a look at the KDE Applications. * Dolphin supports two date formats: absolute and relative. Changing the setting in dolphin does not impact the KDE File Selection dialogue and other KDE/Qt/GTK software * Spectacle allows to save files according to the GNU coreutils "date" syntax (by default: Screenshot_%Y%M%D_%H%m%S) * calligrasheets offers 37 formatting styles for date entries (2 of which are called "System" formats and I presume follow systemsettings) We can see that KDE application developers are open to add relevant date formatting options when they make sense for their software, even though this could be understood as an inconsistency KDE-wide. Therefore I think it would be very helpful to implement a free format option in *dolphin* as: 1) dolphin already has 2 options to choose from so it does not change the UI logic or reduce the elegance of KDE software, and 2) spectacle already does something similar. The file manager is a central place where users spend time reading file dates and times, I believe this would help solving a significant fraction of the problem, and alleviate the frustration while waiting for a solution that can be applied to KDE as a whole.
Indeed, the date format in the plasma clock widget is already completely customizable with a field to enter the format code. Everything about that existing is good. Even if system-wide qt-based custom formats were available, being able to independently set the format for the clock display makes sense. It should be the same for time, but it's an outstanding issue: https://bugs.kde.org/show_bug.cgi?id=393956 There is no reason not to support user ability to control formats at multiple levels (program-specific, plasma-overall, and system-wide). Date and time formats have a simple coding, and users should be able to set it. I urge that this *not* keep the resolved-upstream status even though I acknowledge what it means. KDE can *provide* a KDE-level control for the *display* of dates and times and so on without changing the underlying qt settings. It's not harmful to have both settings exist even later if qt ever fixes their approach to this.
> Indeed, the date format in the plasma clock widget is already completely customizable with a field to enter the format code. Only if you have it permanently displayed in the tray, which assumes a large enough tray to be readable. The tooltip uses a hardcoded date format that cannot be configured at all.
(e.g., the tooltip shows me today's date as "So. Sep. 25 2022" which is a completely broken format, we do not put the month before the day in Austria)
I can't believe that.... this was reported 8 years ago.... it's a regression. And nothing happens.
Thinking more about date format customisation, another option could be a file or a few in .config directory, e.g.: .config/date-format/default .config/date-format/file .config/date-format/clock .config/date-format/calendar Each file would contain a sole strftime format string, or gnu date format string, whatever works best. Which any applications can choose to honour, or ignore (to its users' dismay). Waiting on POSIX or C standard library can be an exercise in futility. Leading by example is contagious. Existing case study is https://editorconfig.org/
(In reply to brenbarn from comment #218) > It sounds like what you're saying is, "if we fix it in KDE, it will be > broken in non-KDE apps". But if we don't fix it in KDE, then it will be > broken for all apps, including KDE and non-KDE apps. I would rather have it > work the way I want at least some of the time than none of the time. To say > it's "not fair to the user" to have it work some of the time and not all of > the time seems a bit disingenuous. It's also not fair to the user to have > it work none of the time. +1 . We can either have a 60% that'll be good enough most users soon, or a 100% solution never, and it seems that some people are saying "Let's wait for the impossible to not happen." (In reply to Jeremy/starcraft.man from comment #8) > Nobody wants > to see their clocks or currency or decimals in a format other than what they > expect. Some countries even have multiple standards due to regional/language > differences... Canada's got its own Wikipedia page on it! > http://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada In addition to the fact that POSIX has invented and enforced standards that don't exist in countries, it's even worse for people like me who want to use their own standards. I set my dictionaries to UK because I use the King's English. I use UK date formats because they're cleaner than North American formats, but, unlike Europe, I start my week on a Sunday as the Abrahamic God intended. My functional and reporting currency is CAD $, not GBP. There is no POSIX standard that will ever accommodate me because of how I mix and match formats. Furthermore, over 20% of people living in Canada were not born in Canada, which means that they are probably used to using other formats that aren't "Canadian" (which, I said earlier, isn't even defined). To say nothing of any Canadian born before 1960 who grew up in school learning Imperial weights and measures instead of Metric. Point is, even if KDE somehow managed to 'fix' the POSIX standard, it still wouldn't work for most people!
Just adding another data point: (In reply to Nate Graham from comment #214) > […] > As I said, if we do our own thing to fix it for only KDE apps, or only for > Qt apps, we make apps' presentation of formats inconsistent across the OS. > […] In corner cases, it already *is* inconsistent. I was desperately trying to find a locale where Qt/KDE *and* the rest of my system use ISO date format and 24h time format. I failed. And I now understand why: (In reply to Kevin Kofler from comment #220) > […] Qt does not actually use POSIX locales > internally, but ICU locales, and has a hardcoded mapping from POSIX to ICU > locales. […] It seems that mapping is not (and probably cannot be) perfect. I worked around the problem as follows: It turned out that for Qt/KDE there is the en_SE locale, which provides the format I want, but that locale does not exist in the POSIX world. However, for POSIX the de_BE locale provides the format I want. So I ended up creating an en_SE POSIX locale by simply symlinking en_SE to de_BE and using en_SE system-wide (i.e., in the Qt/KDE world as well as in the POSIX world) for date and time. It is still not perfect because long date format is still inconsistent, but I can tolerate that. PS: In case this is relevant: I am using Arch Linux. PPS: If you search for an alternative POSIX locale providing ISO date format, here is a list: > localectl list-locales | while IFS='' read -r; do echo -n "$REPLY | "; LC_TIME="$REPLY" date -d '2022-01-03 13:02:01' '+%a | %A | %b | %B | %c | %p | %r | %x | %X'; done | grep '| ....-..-.. | ..:..' | column -ts'|' > > csb_PL.UTF-8 pòn pòniedzôłk stë stëcznika pòn 03 stë 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > de_AT.UTF-8 Mo Montag Jän Jänner Mo 03 Jän 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > de_BE.UTF-8 Mo Montag Jan Januar Mo 03 Jan 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > de_LU.UTF-8 Mo Montag Jan Januar Mo 03 Jan 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > en_CA.UTF-8 Mon Monday Jan January Mon 03 Jan 2022 01:02:01 PM PM 01:02:01 PM 2022-01-03 01:02:01 PM > en_DK.UTF-8 Mon Monday Jan January 2022-01-03T13:02:01 CET 01:02:01 2022-01-03 13:02:01 > eo.UTF-8 lun lundo Jan Januaro lun 03 Jan 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > fr_CA.UTF-8 lun lundi jan janvier lun 03 jan 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > hu_HU.UTF-8 h hétfő jan január 2022. jan. 3., hétfő, 13:02:01 CET 13:02:01 2022-01-03 13:02:01 > lt_LT.UTF-8 Pr Pirmadienis saus. sausio 2022 m. sausio 03 d. 13:02:01 01:02:01 2022-01-03 13:02:01 > nan_TW.UTF-8@latin p1 pài-it 1g 1goe̍h 2022 1g 03 (p1) 13:02:01 CET ē-po͘ 01:02:01 ē-po͘ 2022-01-03 01:02:01 ē-po͘ > se_NO.UTF-8 vuos vuossárga ođđj ođđajagemánnu vuos, ođđj 3. b. 2022 13:02:01 CET 01:02:01 2022-01-03 13:02:01 > si_LK.UTF-8 ස සඳුදා ජන ජනවාරි 2022-01-03 13:02:01 +0100 ප.ව. ප.ව. 01:02:01 2022-01-03 13:02:01 > sv_SE.UTF-8 mån måndag jan januari mån 3 jan 2022 13:02:01 01:02:01 2022-01-03 13:02:01 > wae_CH.UTF-8 Män Mäntag Jen Jenner Män 03. Jen 2022 13:02:01 CET 01:02:01 2022-01-03 13:02:01
Folks should feel welcome to work on an 80% good solution and see what happens. It's possible it will be considered good enough. But going all the way upstream does seem like the best approach to me. Sufficiently experienced and socially adroit people could definitely make it happen. I've seen it before.
I recently found this bug report after struggling to have suitable units and such in a brand new Plasma install. Going through this, and then going to upstream, has me shaking my head in disbelief. That this regression happened a *decade* ago, and both KDE and Qt are kicking the can back and forth at each other, is *embarrassing*. You had something that worked previously, why even bother tying this in to a project in a way that so thoroughly breaks user workflow?? Some people are suggesting we go upstream to get them to do something, which strikes me as *delusional*. They clearly said in as many words that this is not their circus and we aren't their clowns. Their suggested "solution" would be tantamount to just rebuilding UNIX from first principles, which is a complete non-starter. There are some people in this comment thread suggesting that to go back to KDE having their own locale stuff would break it in some non-KDE things. Which, I'm sorry, I've been using linux for 20 years now, since when has KDE *ever* cared about that?? Using KDE apps in a non-KDE environment has always been a pain in the ass and vice versa. Why are you starting to care *now* of all times? Is aggravating users that are neither the devs at their dev laptops nor a hypothetical grandma non-expert user a project goal of KDE? Either resurrect the old KDE locale methods, or issue a definitive statement that this bug WILL NOT BE FIXED, so I know to stop wasting my time with this project. How embarrassing is it that *Windows* has KDE beat with this?
(In reply to doomcup from comment #233) > Is aggravating users that are neither the devs at their dev laptops nor a hypothetical grandma non-expert user a project goal of KDE? Yes, that's pretty much the current school of thought. Subsided a bit after the "why do you think 4.0 is a stable release" fiasko, but now it is going strong again.
If this were clear-cut, it would have been done ages ago. Instead we have a trade-off to make: 1. Add the feature for only KDE apps, and then your non-KDE apps will display all their formats incorrectly, or at least inconsistently 2. Stick to the status quo of consistent systemwide formats, but without this desirable feature 3. Attempt to work upstream to change the whole world so that we can have all of the upsides with none of the downsides You're not wrong that #3 is unlikely, which effectively makes it a #2. I understand that you personally might prefer #1. However at the moment KDE's developers do in fact want to have KDE's apps play nicely with the world around them. This is far from something we ignore and is in fact a big deal to us. It's why we have a nice-looking GTK theme, a GTK settings synchronization service, a first-class implementation of the portal system for sandboxed apps. It's why we work upstream on wayland protocol work rather than just using private protocols and calling it a day and why we just implemented support in Plasma 6 for the FreeDesktop standard sound theme spec. You might personally prefer that we had different priorities, and that's fine. We can't make everyone happy. But we can explain our reasoning and hope that people can accept that sometimes there is no ideal solution and we have to pick from among a menu of imperfect options.
(In reply to Nate Graham from comment #235) > If this were clear-cut, it would have been done ages ago. Instead we have a > trade-off to make: > 1. Add the feature for only KDE apps, and then your non-KDE apps will > display all their formats incorrectly, or at least inconsistently > 2. Stick to the status quo of consistent systemwide formats, but without > this desirable feature > 3. Attempt to work upstream to change the whole world so that we can have > all of the upsides with none of the downsides If "upstream" here refers to POSIX locales, then #3 seems out of place. POSIX locales are not a system for recording or expressing individual user preference, are they? I do agree that the problem would ideally be fixed upstream with something system-wide, but that "something" may be a project that doesn't exist at present.
(In reply to Nate Graham from comment #235) > If this were clear-cut, it would have been done ages ago. Instead we have a > trade-off to make: > 1. Add the feature for only KDE apps, and then your non-KDE apps will > display all their formats incorrectly, or at least inconsistently > 2. Stick to the status quo of consistent systemwide formats, but without > this desirable feature > 3. Attempt to work upstream to change the whole world so that we can have > all of the upsides with none of the downsides > > You're not wrong that #3 is unlikely, which effectively makes it a #2. > > I understand that you personally might prefer #1. However at the moment > KDE's developers do in fact want to have KDE's apps play nicely with the > world around them. This is far from something we ignore and is in fact a big > deal to us. It's why we have a nice-looking GTK theme, a GTK settings > synchronization service, a first-class implementation of the portal system > for sandboxed apps. It's why we work upstream on wayland protocol work > rather than just using private protocols and calling it a day and why we > just implemented support in Plasma 6 for the FreeDesktop standard sound > theme spec. > > You might personally prefer that we had different priorities, and that's > fine. We can't make everyone happy. But we can explain our reasoning and > hope that people can accept that sometimes there is no ideal solution and we > have to pick from among a menu of imperfect options. I don't really understand this logic. You're saying for users who want things to look a certain way, it's better for them to have everything look bad than to have some look bad and some look good? KDE can never fix every problem, but what's the use in not fixing something just because doing so would make the unfixed non-KDE stuff look "inconsistent"?
I'd guess Nate is saying that the dev team has decided that consistency is their priority over this bit of usability for some users. While personally I want this format customisation so bad, I can understand the team having some priorities like that. Likely, if somebody came up with a patch implementing this, devs would accept it despite the inconsistency. Until that happens...
I think there is a fourth option. 4. Create a ugly hack where each user generates a custom locale for themselves
(In reply to Ken Fallon from comment #239) > I think there is a fourth option. > > 4. Create a ugly hack where each user generates a custom locale for > themselves Which is pretty much what we have. Managed to get something suitable thanks to en_SE and such, but terminal stuff complains about locale all the time now. There's another option, though: 5. Use a different DE that makes concessions to usability. After this experience on the laptop, for the desktop I switched back to XFCE. Do I have to configure a few things separately for XFCE's clock and Thunar and such? Yeah. But at least it lets me do so without borking my system's locale setup.
(In reply to Nate Graham from comment #235) > If this were clear-cut, it would have been done ages ago. Instead we have a > trade-off to make: > 1. Add the feature for only KDE apps, and then your non-KDE apps will > display all their formats incorrectly, or at least inconsistently > 2. Stick to the status quo of consistent systemwide formats, but without > this desirable feature > 3. Attempt to work upstream to change the whole world so that we can have > all of the upsides with none of the downsides > > You're not wrong that #3 is unlikely, which effectively makes it a #2. > > I understand that you personally might prefer #1. However at the moment > KDE's developers do in fact want to have KDE's apps play nicely with the > world around them. This is far from something we ignore and is in fact a big > deal to us. It's why we have a nice-looking GTK theme, a GTK settings > synchronization service, a first-class implementation of the portal system > for sandboxed apps. It's why we work upstream on wayland protocol work > rather than just using private protocols and calling it a day and why we > just implemented support in Plasma 6 for the FreeDesktop standard sound > theme spec. > > You might personally prefer that we had different priorities, and that's > fine. We can't make everyone happy. But we can explain our reasoning and > hope that people can accept that sometimes there is no ideal solution and we > have to pick from among a menu of imperfect options. And this is why Nate is one of the greatest example of a good member of a community. Always respectful and humble, no matter if he disagrees with you. Thank you for being a member if this community Sir! You are definitely making a difference. Sorry for the "mostly useless" comment, but I think it's important to also show some support for the community members, as a lot of times the negative one are under the spot light.
To be 100% clear, the work that the teams are doing and the amount of time and effort involved is appreciated. It is also reasonable to ask for a bug like this to be fixed. If you're not going to fix it then fine. The solution of "RESOLVED UPSTREAM" is not correct when the bug in question is marked at the QT side as "Unresolved". I would suggest INTENTIONAL, or NOT A BUG would better reflect the status. As a side note Thunderbird had a similar discussion which is now resolved. https://bugzilla.mozilla.org/show_bug.cgi?id=1509096 My suggestion of a #4 rolling your own was very serious. I would appreciate someone helping me with a beginners guide to creating a custom locale for the different distros.
To be honest I don't understand some of the logic in this discussion. Are we really asking that KDE changes system's locales, making up some customized/able version? Personally I don't think so. Several KDE apps provide a kind of TIME INFORMATION. I think we're asking to make this "time information" customizable. As I see it, this doesn't imply any POSIX changes. The system's locales offer several fine-grained variables, like month number or minutes. We're asking that KDE apps allow the users to combine these pieces of time information from the locale in ways that can be convenient for different apps. For instance, I might want the system-tray clock to show "month-day/hour" with particular separators. Or I might want – for whatever reason – Dolphin to display the time-information column about files only with "year-day". It's only natural that different apps, for their very nature, may require different choices and display of time information. And the user may want to customize this even more depending on professional use or whatever. So I don't understand when Nate (https://bugs.kde.org/show_bug.cgi?id=340982#c235) says "However at the moment KDE's developers do in fact want to have KDE's apps play nicely with the world around them." What does "play nicely" mean? I don't think we're asking that KDE apps internally store – or share with other apps – locales in any strange ways. We're asking for customizability of how locales info is combined and displayed. Thunderbird, for example, allows users to display time information in the "Date" column in a user-defined way (https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird). Or, as a different example on the same concept, Emacs let me customize how to display the file-name information, for example displaying "file-name/[last folder in folder tree]". This doesn't mean that Emacs is changing the internal file system. Why is there so much hang-up about "short-date" and "long-date"? Just let me customize which time data from the locales I want displayed on a Dolphin "Modified" column, for instance.
(In reply to Luca from comment #243) > We're asking that KDE apps allow > the users to combine these pieces of time information from the locale in > ways that can be convenient for different apps. Yes, thank you for that point so clearly. There is no reason that I should be unable to enter a custom *presentation* of date or time appropriate to my use of a particular app — independently from the default system locale settings. However, such *front-end* features (which are appropriate to KDE's ethos IMO) seem like they should be opened for specific front-end use cases. Such as https://bugs.kde.org/show_bug.cgi?id=393956 which is a request to get *time* customization in the clock widget (which already has date customization). That is an open ticket, not marked as resolved, and similar features could be requested (or submitted as patches) in other cases like Dolphin. This ticket here (340982) does seem to be pretty broad and system-level request to customize Locale overall (which I personally *also* think should be possible btw).
(In reply to Aaron Wolf from comment #244) > However, such *front-end* features (which are appropriate to KDE's ethos > IMO) seem like they should be opened for specific front-end use cases. > This ticket here (340982) does seem to be pretty broad and > system-level request to customize Locale overall (which I personally *also* > think should be possible btw). Thank you for clarifying this ticket's topic to me, I obviously misunderstood!
(In reply to Luca from comment #243) > To be honest I don't understand some of the logic in this discussion. > > Are we really asking that KDE changes system's locales, making up some > customized/able version? Personally I don't think so. > > Several KDE apps provide a kind of TIME INFORMATION. I think we're asking to > make this "time information" customizable. As I see it, this doesn't imply > any POSIX changes. The system's locales offer several fine-grained > variables, like month number or minutes. We're asking that KDE apps allow > the users to combine these pieces of time information from the locale in > ways that can be convenient for different apps. > > For instance, I might want the system-tray clock to show "month-day/hour" > with particular separators. Or I might want – for whatever reason – Dolphin > to display the time-information column about files only with "year-day". > > It's only natural that different apps, for their very nature, may require > different choices and display of time information. And the user may want to > customize this even more depending on professional use or whatever. > > So I don't understand when Nate > (https://bugs.kde.org/show_bug.cgi?id=340982#c235) says > > "However at the moment KDE's developers do in fact want to have KDE's apps > play nicely with the world around them." > > What does "play nicely" mean? I don't think we're asking that KDE apps > internally store – or share with other apps – locales in any strange ways. > We're asking for customizability of how locales info is combined and > displayed. > > Thunderbird, for example, allows users to display time information in the > "Date" column in a user-defined way > (https://support.mozilla.org/en-US/kb/customize-date-time-formats- > thunderbird). Or, as a different example on the same concept, Emacs let me > customize how to display the file-name information, for example displaying > "file-name/[last folder in folder tree]". This doesn't mean that Emacs is > changing the internal file system. > > Why is there so much hang-up about "short-date" and "long-date"? Just let me > customize which time data from the locales I want displayed on a Dolphin > "Modified" column, for instance. Thank you for putting this in a way I wish I had the patience and eloquence to do! Yeah I sincerely doubt anybody in this decade long thread actually wanted to change the underlying system locale, just display information from it differently in various places in a user defined way. (Which is, funny enough, how a lot of other DEs and programs handle things.) I know I've been something of a latecomer grouch here, but I too really do appreciate all the work and such that has gone into KDE over the years and all the volunteers contributing what they can. It's this appreciation and love for the whole free software thing that makes bugs like this long-standing one a little more irritating. You don't bother complaining about things you don't really care about, do you? :)
(In reply to Ken Fallon from comment #242) > My suggestion of a #4 rolling your own was very serious. I would appreciate > someone helping me with a beginners guide to creating a custom locale for > the different distros. The problem is that rolling your own locale is not actually going to work with Qt/KDE applications. See comment #220.
Regarding consistency, just remembered that the digital clock has "date format" dropdown already (https://bugs.kde.org/show_bug.cgi?id=340982#c155 ). Perhaps eventually the solution is / will be all apps offering their own date/time representation config options. Which might not even be that bad, as the desired format might change depending on the situation.
I am not sure if this has already been discussed previously, but this thread has become so long over time I have lost control ^^ Could it be possible to create a new locale file from scratch that is named eg. DV_dv" (DV = development) which is used just like any other locale file would be used, but it has a specialty: it is fully customizeable by user. That way in locale settings keywords can be re-arranged, edited, replaced etc. so that all stuff that relies on a valid locale file finds its bits. What amazes me is that in KDE we have editors to work on non-QT themes that originally came from other DEs but needed to be adjusted so they could be used in KDE as well. So why is there no user-editable locale file that does same for locale settings. It could be a copy of DE_de or anything, as a template, and user edits it so that there finally is a proper string for long/short date format, 24h time format etc. etc.
*** Bug 476048 has been marked as a duplicate of this bug. ***
*** Bug 479477 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #235) > If this were clear-cut, it would have been done ages ago. Instead we have a > trade-off to make: > 1. Add the feature for only KDE apps, and then your non-KDE apps will > display all their formats incorrectly, or at least inconsistently > 2. Stick to the status quo of consistent systemwide formats, but without > this desirable feature > 3. Attempt to work upstream to change the whole world so that we can have > all of the upsides with none of the downsides > > You're not wrong that #3 is unlikely, which effectively makes it a #2. > > I understand that you personally might prefer #1. However at the moment > KDE's developers do in fact want to have KDE's apps play nicely with the > world around them. This is far from something we ignore and is in fact a big > deal to us. It's why we have a nice-looking GTK theme, a GTK settings > synchronization service, a first-class implementation of the portal system > for sandboxed apps. It's why we work upstream on wayland protocol work > rather than just using private protocols and calling it a day and why we > just implemented support in Plasma 6 for the FreeDesktop standard sound > theme spec. > > You might personally prefer that we had different priorities, and that's > fine. We can't make everyone happy. But we can explain our reasoning and > hope that people can accept that sometimes there is no ideal solution and we > have to pick from among a menu of imperfect options. We are on the KDE bugtracker, discussing a KDE problem. The conversation is confined to the field of KDE. Every single user commenting here has stressed the importance of fixing issue 1 (Add the feature for only KDE apps). I understand the desire to handle issue 3 (Attempt to work upstream to change the whole world) but changing the world is not the goal of the KDE bugtracker nor related software that is developed in conjunction with discussions on the KDE bugtracker. Please, let issue 1 (Add the feature for only KDE apps) remain the goal of KDE and of this issue specifically, at least until parallel efforts enable fixing issue 3.
We can indeed implement option 1 and fix this issue for KDE apps. If your perspective is "I would rather have it work the way I want at least some of the time than none of the time", that's valid. The problem is that if we make this possible to satisfy those people, we're making the system more confusing for people who don't have that preference, or don't even know that that preference is a thing that can exist. Gradually we're trying to move away from what I call "broken promise" global options: options that are presented as global in scope but really aren't because they only affect some parts of the system. Experience shows that these options are a recurring source of bug reports from normal users as well as picky technical users who care a lot about consistency. When we can't fully get rid of kinds of options, we try to add textual explanations, but even those are imperfect. Experience also shows that even if we did something super in-your-face and added a giant banner in the Region & Language KCM that said: "ALERT! Changing this only affects KDE apps! It will not affect the way dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, LibreOffice, and Blender" ...then I can 100% guarantee you that we would *still* get bug reports from confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, and Blender don't respect their date display preferences. And we would have to explain the underlying reason over and over again. So for you folks who want it to at least work some of the time because some is better than none, I understand your perspective, but hopefully you can see how satisfying this preference would make the system less coherent to people without that preference.
(In reply to Nate Graham from comment #253) > We can indeed implement option 1 and fix this issue for KDE apps. > Thank you. I'm sure that the two hundred people here commenting, and untold frustrated others, appreciate this. > If your perspective is "I would rather have it work the way I want at least > some of the time than none of the time", that's valid. > Thank you. > The problem is that if we make this possible to satisfy those people, we're > making the system more confusing for people who don't have that preference, > or don't even know that that preference is a thing that can exist. > I understand your viewpoint, and I appreciate you conceding that viewpoint to the KDE users who have been begging for this horrible bug to be fixed for years. > Gradually we're trying to move away from what I call "broken promise" global > options: options that are presented as global in scope but really aren't > because they only affect some parts of the system. Experience shows that > these options are a recurring source of bug reports from normal users as > well as picky technical users who care a lot about consistency. > Then maybe just label the feature "KDE Date Format" as that is all that KDE can effect. Or even a stand-alone KDE Settings tool (not in System Settings) to make the change, so that no one will complain that it does not affect the entire System. In any case, that promise is broken already in System Settings in some other places, for instance Windows appearance options do not affect Java nor WXwidgets applications. > When we can't fully get rid of kinds of options, we try to add textual > explanations, but even those are imperfect. Experience also shows that even > if we did something super in-your-face and added a giant banner in the > Region & Language KCM that said: > > "ALERT! Changing this only affects KDE apps! It will not affect the way > dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, > LibreOffice, and Blender" > > ...then I can 100% guarantee you that we would *still* get bug reports from > confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, > and Blender don't respect their date display preferences. And we would have > to explain the underlying reason over and over again. > Then put the options in a KDE Settings submenu, or a standalone KDE settings application to compliment System Settings. But KDE users need this bug fixed. > So for you folks who want it to at least work some of the time because some > is better than none, I understand your perspective, but hopefully you can > see how satisfying this preference would make the system less coherent to > people without that preference. Yes, I see both perspectives. Now which is the lesser evil: KDE applications do not respect cultural date formats and there is absolutely no solution (so KDE apps display their dates wrong), or some people might be confused as to why they need to configure their non-KDE apps' date formats in addition to their KDE date format setting?
I am in general very much for consistency, but being consistently wrong is just not helpful. Even within a country, there can be distinct regional, local, ethnical, or personal preferences, so just having these settings be per country (or per language/country pair for those countries speaking more than one language) just cannot cover it. And many users prefer having their system in English (or some other foreign language), but still expect date formats etc. to follow the rules of their country (but not using its language for weekdays, month names, etc.), which is not covered by the locale system either. So the status quo is frequently not just not according to the user preferences, but genuinely wrong.
Also, there is no consistency anyway, since console and GTK applications use glibc locales, whereas Qt uses ICU locales and only tries to map the glibc locales to those internally. So you end up with en_DK working in everything except Qt applications and en_SE working only in Qt applications, making those popular workarounds for more international-friendly English locales useless. And for the same reason, a custom glibc locale will also not work in Qt applications.
(In reply to Nate Graham from comment #253) > Experience also shows that even > if we did something super in-your-face and added a giant banner in the > Region & Language KCM that said: > > "ALERT! Changing this only affects KDE apps! It will not affect the way > dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, > LibreOffice, and Blender" > > ...then I can 100% guarantee you that we would *still* get bug reports from > confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, > and Blender don't respect their date display preferences. And we would have > to explain the underlying reason over and over again. To put it bluntly, so what? Just create a FAQ about it and close those bug reports as invalid. The fact that people will ask why it doesn't work in all cases doesn't seem like a good reason to not fix it in some cases.
(In reply to brenbarn from comment #257) > (In reply to Nate Graham from comment #253) > > "ALERT! Changing this only affects KDE apps! It will not affect the way > > dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, > > LibreOffice, and Blender" > > > > ...then I can 100% guarantee you that we would *still* get bug reports from > > confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, > To put it bluntly, so what? Just create a FAQ about it and close those bug Remind me why it is again that KDE's systemsettings KCM can't set something that only affects KDE apps and give the user the option to configure the known corresponding setting for non-Qt/KDE applications? KDE4 had something of the sort for the GTk(2) colour profile. I can see how that would appear impossible if both glib and ICU locales are set from the same environmental variable but every Qt-based application running under `KDE_FULL_SESSION=true` will normally load the platform theme plugin. Would it be too late to change the value of the corresponding env. variable(s) from there and get the intended behaviour?
(In reply to RJVB from comment #258) > Remind me why it is again that KDE's systemsettings KCM can't set something > that only affects KDE apps and give the user the option to configure the > known corresponding setting for non-Qt/KDE applications? Is there such an option for GTK and/or other toolkits? If there is, then this could be a path forward, since we have a sync service that maps KDE settings to their applicable GTK equivalents already.
(In reply to Nate Graham from comment #259) > Is there such an option for GTK and/or other toolkits? How is that relevant if KDE already has a sync service that apparently does what I'm suggesting? I have no idea what parameter GTk (or Gnome) uses for this particular setting but I can guess that it's the same one KDE is currently setting without the expected effect in Qt-based applications. As far as I can oversee at this point, all that seems to be needed is to define an additional parameter that defines the behaviour for KDE/Qt applications; this would be the parameter controlled by the KCM. The KDE platform plugin would translate this to the actual parameter used in Qt's internals. That's assuming it gets the chance to do that early enough, of course, but I suppose there must also be a programmatic way to change these settings directly instead of via env. variables. The KCM can predefine certain mappings from Qt locale definitions to glib ones but since it's probably impossible to foresee every single combination users might require the KCM could provide an optional second locale configuration widget or screen for GTk/Gnome apps. The only drawback would be that this mechanism doesn't work when running KDE apps under a non-KDE desktop session. It could, if the user sets KDE_FULL_SESSION and KDE_SESSION_VERSION himself, but barring that the proposed mechanism shouldn't change anything for users who are in that situation.
(In reply to RJVB from comment #260) > (In reply to Nate Graham from comment #259) > > Is there such an option for GTK and/or other toolkits? > > How is that relevant if KDE already has a sync service that apparently does > what I'm suggesting? The sync service makes use of options and features in the target platform. So if GTK or GNOME apps lack an option to change the date format in the way we want, then there's nothing to sync our date format settings to.
*** Bug 485360 has been marked as a duplicate of this bug. ***
*** Bug 485373 has been marked as a duplicate of this bug. ***