[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 danins...@gmail.com changed: What|Removed |Added CC||danins...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added CC||med.medin.2...@gmail.com --- Comment #263 from Nate Graham --- *** Bug 485373 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 hanyo...@protonmail.com changed: What|Removed |Added CC||dr.li...@gmail.com --- Comment #262 from hanyo...@protonmail.com --- *** Bug 485360 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #261 from Nate Graham --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #260 from RJVB --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #259 from Nate Graham --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #258 from RJVB --- (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? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #257 from brenb...@brenbarn.net --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #256 from Kevin Kofler --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #255 from Kevin Kofler --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #254 from Dotan Cohen --- (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? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #253 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #252 from Dotan Cohen --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added CC||pingger_kdesucks@iskariot.i ||nfo --- Comment #251 from Nate Graham --- *** Bug 479477 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 hanyo...@protonmail.com changed: What|Removed |Added CC||2023...@solarandthermal.com --- Comment #250 from hanyo...@protonmail.com --- *** Bug 476048 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #249 from crptdng...@gmx.net --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #248 from ric...@nakts.net --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #247 from Kevin Kofler --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #246 from doom...@gmail.com --- (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? :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Szokovacs Robert changed: What|Removed |Added CC|s...@szo.hu | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #245 from Luca --- (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! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #244 from Aaron Wolf --- (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). -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #243 from Luca --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #242 from Ken Fallon --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #241 from Enrico Tagliavini --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 soredake changed: What|Removed |Added CC|broaden_acid002@simplelogin | |.com| -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #240 from doom...@gmail.com --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #239 from Ken Fallon --- I think there is a fourth option. 4. Create a ugly hack where each user generates a custom locale for themselves -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #238 from ric...@nakts.net --- 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... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #237 from brenb...@brenbarn.net --- (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"? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #236 from David Gasaway --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #235 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #234 from arne anka --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 doom...@gmail.com changed: What|Removed |Added CC||doom...@gmail.com --- Comment #233 from doom...@gmail.com --- 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? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Christoph Feck changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=471085 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added Keywords||geezer-jobs --- Comment #232 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Flupp changed: What|Removed |Added CC||bugs.kde.org@derflupp.e4war ||d.com --- Comment #231 from Flupp --- 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ëcznikapò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:0101:02:01 2022-01-03 > 13:02:01 > de_BE.UTF-8 Mo Montag Jan Januar Mo 03 > Jan 2022 13:02:0101:02:01 2022-01-03 > 13:02:01 > de_LU.UTF-8 Mo Montag Jan Januar Mo 03 > Jan 2022 13:02:0101:02:01 2022-01-03 > 13:02:01 > en_CA.UTF-8 Mon Monday Jan January Mon 03 > Jan 2022 01:02:01 PMPM 01:02:01 PM 2022-01-03 > 01:02:01 PM > en_DK.UTF-8 Mon Monday Jan January > 2022-01-03T13:02:01 CET01: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 Pirmadienissaus.sausio 2022 > m. sausio 03 d. 13:02:01 01:02:01 2022-01-03 > 13:02:01 > nan_TW.UTF-8@latinp1 pài-it 1g 1goe̍h2022 > 1g 03 (p1) 13:02:01 CET ē-po͘ 01:02:01 ē-po͘ 2022-01-03 > 01:02:01 ē-po͘ > se_NO.UTF-8 vuosvuossárga ođđj ođđajagemánnuvuos, > ođđj 3. b. 2022 13:02:01 CET01: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 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #230 from Borden --- (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! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #229 from Maxim Egorushkin --- 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/ -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #228 from bugs5.kde@sjau.ch --- I can't believe that this was reported 8 years ago it's a regression. And nothing happens. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #227 from Kevin Kofler --- (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) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #226 from Kevin Kofler --- > 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #225 from Aaron Wolf --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #224 from Jérôme Borme --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #223 from EMR_Kde --- (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? >:^) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #222 from RJVB --- 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... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Paul changed: What|Removed |Added CC|pip@gmx.com | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Malte Eggers changed: What|Removed |Added CC|malt...@mailbox.org | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #221 from Kevin Kofler --- (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.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #220 from Kevin Kofler --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #219 from RJVB --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #218 from brenb...@brenbarn.net --- (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.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #217 from Szokovacs Robert --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #216 from John Brooks --- I don't have particularly high hopes for amending POSIX to fix this, to be honest. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #215 from Keith Zubot-Gephart --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 postix changed: What|Removed |Added CC||pos...@posteo.eu -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #214 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Lingfeng Fu <2871618...@qq.com> changed: What|Removed |Added CC||2871618...@qq.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #213 from Aaron Wolf --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #212 from Nate Graham --- 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 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #211 from John Brooks --- Is the status supposed to be "resolved upstream"? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Bug Janitor Service changed: What|Removed |Added Priority|HI |VHI -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added URL||https://bugreports.qt.io/br ||owse/QTBUG-58351 Status|CONFIRMED |RESOLVED Resolution|--- |UPSTREAM See Also||https://bugs.kde.org/show_b ||ug.cgi?id=394698 --- Comment #210 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #209 from John Brooks --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982
brenb...@brenbarn.net changed:
What|Removed |Added
CC||brenb...@brenbarn.net
--- Comment #208 from brenb...@brenbarn.net ---
(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 n...@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.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 John Brooks changed: What|Removed |Added CC||j...@fastquake.com --- Comment #207 from John Brooks --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Celeste changed: What|Removed |Added CC||coelacant...@outlook.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #206 from Elmo R --- (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 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #205 from Elmo R --- (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 :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 pg...@duralexnonlex.org changed: What|Removed |Added CC||pg...@duralexnonlex.org -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added Assignee|lu...@kde.org |plasma-b...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added CC||hanyo...@protonmail.com Component|kcm_formats |kcm_regionandlang -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Nate Graham changed: What|Removed |Added Severity|major |normal Priority|VHI |HI -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 nyanpasu64 changed: What|Removed |Added CC||nyanpas...@tuta.io -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #204 from Juha Tuomala --- (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 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Gerald Cox changed: What|Removed |Added CC||gb...@bzb.us -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Gerald Cox changed: What|Removed |Added CC|gb...@bzb.us| -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Andrey changed: What|Removed |Added CC|andrey.aleksandrovich@googl | |email.com | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #203 from RJVB --- 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! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #202 from Maxim Egorushkin --- (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? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #201 from Kevin Kofler --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #200 from Maxim Egorushkin --- 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") ... )` -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #199 from Enrico Tagliavini --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982
--- Comment #198 from cat22 ---
(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 n...@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
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982
--- Comment #197 from Nate Graham ---
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 n...@kde.org instead of
posting a comment.
Thanks.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #196 from Aaron Wolf --- 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 -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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #195 from sombrag...@sombragris.org --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #194 from tdy...@hotmail.com --- (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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 2wxsy5823...@opayq.com changed: What|Removed |Added CC|2wxsy5823...@opayq.com | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #193 from ric...@nakts.net --- 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.] -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #192 from sombrag...@sombragris.org --- 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. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #191 from Nate Graham --- 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! :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #190 from Nate Graham --- Yeah, if anyone wants to bring back KLocale and port everything to it, that would be a path forward. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #189 from Kevin Kofler --- 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 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #188 from Kevin Kofler --- 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.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #187 from RJVB --- (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] -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Alexander changed: What|Removed |Added CC||kos...@koshka.ddns.net --- Comment #186 from Alexander --- 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.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #185 from Smittie --- My apologies for the double post. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #184 from Smittie --- (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. -- You are receiving this mail because: You are watching all bug changes.
