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