Bug 394698

Thanks for the report Aleksey, I believe has been fixed since your report.

Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.

No! NOT FIXED!!! Very inconvenient: can't specify format manually like it was in KDE 4 - only select from languages list.

Thank you for the update, please see attached screenshot of Formats section under Regional. Is this the section you are looking for?

Created attachment 133570 [details]
Screenshot

Of course this section, but like I said (https://bugs.kde.org/show_bug.cgi?id=394698#c0) in KDE 4 it looked differently and it was possible to specify custom format for each section, now it is not possible - need to select some language.

Thanks for confirming, have updated affected version, hopefully, a developer will be able to look at this soon.

Created attachment 134599 [details]
How it used to look in KDE 4 times

This UX is very irritating to me too.

I wasn't around for KDE4 times, but I found and have attached a screenshot of what this KCM used to look like. It seems like a hugely better UX than what we have today: you select the format you want, rather than the country code that implements that format, which requires that you know every detail of every country.

*** Bug 339583 has been marked as a duplicate of this bug. ***

I agree this UX is a joke. If I want to use 24h or a different/custom format for time, currency, etc. the only choice I have is to select a different country’s locale, and you have to go through the whole world before finding the one with the format you like.

*** Bug 432938 has been marked as a duplicate of this bug. ***

*** Bug 438280 has been marked as a duplicate of this bug. ***

*** Bug 437796 has been marked as a duplicate of this bug. ***

*** Bug 446761 has been marked as a duplicate of this bug. ***

See the upstream discussion in https://bugreports.qt.io/browse/QTBUG-58351.

We had an idea to allow the user to select values/strings in the Plasma config UI rather than locales, and then secretly set whatever locale is mapped to it, but this ran afoul of the fact that the locales include translated text not just string formatting. The POSIX locale system just isn't set up to allow this to happen. So 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.

Ideal (for some, at any rate) would be the ability to use strftime()/printf() formatting for datetime/numbers respectively (actually, not entirely sure that printf() would be correct for numbers; it would have to be something more like LiberOffice format codes) as Custom formats in addition to predefined ones.

Very messy indeed...

*** Bug 465453 has been marked as a duplicate of this bug. ***

Any reasonable chance that this is getting fixed for Plasma 6.0? The status of this report is now RESOLVED UPSTREAM but when on the latest KDE Neon unstable, this problem is still there.

(In reply to Nate Graham from comment #14)
> See the upstream discussion in https://bugreports.qt.io/browse/QTBUG-58351.
> 
> We had an idea to allow the user to select values/strings in the Plasma
> config UI rather than locales, and then secretly set whatever locale is
> mapped to it, but this ran afoul of the fact that the locales include
> translated text not just string formatting. The POSIX locale system just
> isn't set up to allow this to happen. So 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.

Would it be possible to create a set of custom locale files based on a system locale with the custom formats built in and "select" that one?