How to hack and modify a predefined date time format of KDE 5 that comes with Debian 9.2.1 Stretch?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite
1












I would like to hack and modify a predefined date time format of KDE 5 on Debian 9.2.1 Stretch.



A predefined format can be selected from the list of predefined formats at Kickoff Launcher > Computer > System Settings > Personalization > Regional Settings > Formats.



(For the screen shot of the Formats settings dialog, see https://superuser.com/q/1162283 on the SuperUser site.)



The effect of the format appears on the Formats settings dialog itself, and also appears on the Date field of the Details view of the Dolphin File Manager of the KDE desktop, and also the Properties of any file on Dolphin.



Unfortunately, none of the predefined formats suits me. The date time format of en_US ("United States - American English") is particularly terrible from my viewpoint. On the other hand, the short date time format of en_SE ("Sweden - English") is ISO 8601, and is close to what I want. Nevertheless, even en_SE does not completely satisfy me; especially its long format disappoints me.



This Formats settings dialog never lets you freely create custom formats. It only gives you a choice from predefined formats.



Thus, I would like to hack and modify a predefined format. Please let me know how.



The directory /usr/share/i18n/locales contains format files. The file names are identical to the format names such as en_US, en_GB, fr_FR and so on. However, the KDE that came with Debian 9.2.1 does not care about the format files in /usr/share/i18n/locales. Modification to these format files or even deletion of all of these files never affects the behavior of the KDE on Debian 9.2.1. This directory even lacks en_SE, and nevertheless en_SE appears in the Formats settings dialog.



I wonder if the predefined formats are hard-coded in KDE.



Note that Debian 9.0 Stretch was released on 2017-06-17. The versions of KDE components that came with Debian 9.2.1 follow:



plasmashell --version
# plasmashell 5.8.6

kf5-config --version
# Qt: 5.7.1
# KDE Frameworks: 5.28.0
# kf5-config: 1.0


TheEzekielProject claims in his post (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/guide-to-setting-custom-date-format-in-recent-versions-of-kde-4175595458-print/) that he managed to create a custom date time format by modifying a format file in the directory /usr/share/i18n/locales. The systems he tested are Kali Linux 2016.2 rolling with KDE Plasma 5.8.2 and KDE Frameworks 5.27.0, and Kubuntu 16.10 with KDE Plasma 5.7.5 and KDE Frameworks 5.26.0. His systems are older than mine.



I tried his method. In a format file, under LC_TIME, I changed d_t_fmt, d_fmt, t_fmt and t_fmt_ampm, and executed locale-gen, and so on. However, his method has turned out to have no effect on the KDE on Debian 9.2.1. Also a comment to his post complains that his method fails on Neon (plasma 5.10).



By the way, my question is not a duplicate of questions/1162283/use-iso-time-and-date-format-in-kde-5 on the SuperUser site. The question 1162283 asked for ISO date time format, and it has been fulfilled by the answer by
Marco Lussetti, that is, by simply selecting en_SE from the list of predefined formats. My question asks for a hack to go beyond predefined formats.







share|improve this question






















  • Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
    – Ipor Sircer
    Dec 14 '17 at 10:46










  • I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
    – i7pj3qnuz
    Jan 8 at 13:01










  • This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
    – Evi1M4chine
    Jan 27 at 13:35











  • Correction: Of course I meant find / -iname '*ksh_de*'.
    – Evi1M4chine
    Jan 27 at 14:06














up vote
3
down vote

favorite
1












I would like to hack and modify a predefined date time format of KDE 5 on Debian 9.2.1 Stretch.



A predefined format can be selected from the list of predefined formats at Kickoff Launcher > Computer > System Settings > Personalization > Regional Settings > Formats.



(For the screen shot of the Formats settings dialog, see https://superuser.com/q/1162283 on the SuperUser site.)



The effect of the format appears on the Formats settings dialog itself, and also appears on the Date field of the Details view of the Dolphin File Manager of the KDE desktop, and also the Properties of any file on Dolphin.



Unfortunately, none of the predefined formats suits me. The date time format of en_US ("United States - American English") is particularly terrible from my viewpoint. On the other hand, the short date time format of en_SE ("Sweden - English") is ISO 8601, and is close to what I want. Nevertheless, even en_SE does not completely satisfy me; especially its long format disappoints me.



This Formats settings dialog never lets you freely create custom formats. It only gives you a choice from predefined formats.



Thus, I would like to hack and modify a predefined format. Please let me know how.



The directory /usr/share/i18n/locales contains format files. The file names are identical to the format names such as en_US, en_GB, fr_FR and so on. However, the KDE that came with Debian 9.2.1 does not care about the format files in /usr/share/i18n/locales. Modification to these format files or even deletion of all of these files never affects the behavior of the KDE on Debian 9.2.1. This directory even lacks en_SE, and nevertheless en_SE appears in the Formats settings dialog.



I wonder if the predefined formats are hard-coded in KDE.



Note that Debian 9.0 Stretch was released on 2017-06-17. The versions of KDE components that came with Debian 9.2.1 follow:



plasmashell --version
# plasmashell 5.8.6

kf5-config --version
# Qt: 5.7.1
# KDE Frameworks: 5.28.0
# kf5-config: 1.0


TheEzekielProject claims in his post (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/guide-to-setting-custom-date-format-in-recent-versions-of-kde-4175595458-print/) that he managed to create a custom date time format by modifying a format file in the directory /usr/share/i18n/locales. The systems he tested are Kali Linux 2016.2 rolling with KDE Plasma 5.8.2 and KDE Frameworks 5.27.0, and Kubuntu 16.10 with KDE Plasma 5.7.5 and KDE Frameworks 5.26.0. His systems are older than mine.



I tried his method. In a format file, under LC_TIME, I changed d_t_fmt, d_fmt, t_fmt and t_fmt_ampm, and executed locale-gen, and so on. However, his method has turned out to have no effect on the KDE on Debian 9.2.1. Also a comment to his post complains that his method fails on Neon (plasma 5.10).



By the way, my question is not a duplicate of questions/1162283/use-iso-time-and-date-format-in-kde-5 on the SuperUser site. The question 1162283 asked for ISO date time format, and it has been fulfilled by the answer by
Marco Lussetti, that is, by simply selecting en_SE from the list of predefined formats. My question asks for a hack to go beyond predefined formats.







share|improve this question






















  • Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
    – Ipor Sircer
    Dec 14 '17 at 10:46










  • I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
    – i7pj3qnuz
    Jan 8 at 13:01










  • This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
    – Evi1M4chine
    Jan 27 at 13:35











  • Correction: Of course I meant find / -iname '*ksh_de*'.
    – Evi1M4chine
    Jan 27 at 14:06












up vote
3
down vote

favorite
1









up vote
3
down vote

favorite
1






1





I would like to hack and modify a predefined date time format of KDE 5 on Debian 9.2.1 Stretch.



A predefined format can be selected from the list of predefined formats at Kickoff Launcher > Computer > System Settings > Personalization > Regional Settings > Formats.



(For the screen shot of the Formats settings dialog, see https://superuser.com/q/1162283 on the SuperUser site.)



The effect of the format appears on the Formats settings dialog itself, and also appears on the Date field of the Details view of the Dolphin File Manager of the KDE desktop, and also the Properties of any file on Dolphin.



Unfortunately, none of the predefined formats suits me. The date time format of en_US ("United States - American English") is particularly terrible from my viewpoint. On the other hand, the short date time format of en_SE ("Sweden - English") is ISO 8601, and is close to what I want. Nevertheless, even en_SE does not completely satisfy me; especially its long format disappoints me.



This Formats settings dialog never lets you freely create custom formats. It only gives you a choice from predefined formats.



Thus, I would like to hack and modify a predefined format. Please let me know how.



The directory /usr/share/i18n/locales contains format files. The file names are identical to the format names such as en_US, en_GB, fr_FR and so on. However, the KDE that came with Debian 9.2.1 does not care about the format files in /usr/share/i18n/locales. Modification to these format files or even deletion of all of these files never affects the behavior of the KDE on Debian 9.2.1. This directory even lacks en_SE, and nevertheless en_SE appears in the Formats settings dialog.



I wonder if the predefined formats are hard-coded in KDE.



Note that Debian 9.0 Stretch was released on 2017-06-17. The versions of KDE components that came with Debian 9.2.1 follow:



plasmashell --version
# plasmashell 5.8.6

kf5-config --version
# Qt: 5.7.1
# KDE Frameworks: 5.28.0
# kf5-config: 1.0


TheEzekielProject claims in his post (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/guide-to-setting-custom-date-format-in-recent-versions-of-kde-4175595458-print/) that he managed to create a custom date time format by modifying a format file in the directory /usr/share/i18n/locales. The systems he tested are Kali Linux 2016.2 rolling with KDE Plasma 5.8.2 and KDE Frameworks 5.27.0, and Kubuntu 16.10 with KDE Plasma 5.7.5 and KDE Frameworks 5.26.0. His systems are older than mine.



I tried his method. In a format file, under LC_TIME, I changed d_t_fmt, d_fmt, t_fmt and t_fmt_ampm, and executed locale-gen, and so on. However, his method has turned out to have no effect on the KDE on Debian 9.2.1. Also a comment to his post complains that his method fails on Neon (plasma 5.10).



By the way, my question is not a duplicate of questions/1162283/use-iso-time-and-date-format-in-kde-5 on the SuperUser site. The question 1162283 asked for ISO date time format, and it has been fulfilled by the answer by
Marco Lussetti, that is, by simply selecting en_SE from the list of predefined formats. My question asks for a hack to go beyond predefined formats.







share|improve this question














I would like to hack and modify a predefined date time format of KDE 5 on Debian 9.2.1 Stretch.



A predefined format can be selected from the list of predefined formats at Kickoff Launcher > Computer > System Settings > Personalization > Regional Settings > Formats.



(For the screen shot of the Formats settings dialog, see https://superuser.com/q/1162283 on the SuperUser site.)



The effect of the format appears on the Formats settings dialog itself, and also appears on the Date field of the Details view of the Dolphin File Manager of the KDE desktop, and also the Properties of any file on Dolphin.



Unfortunately, none of the predefined formats suits me. The date time format of en_US ("United States - American English") is particularly terrible from my viewpoint. On the other hand, the short date time format of en_SE ("Sweden - English") is ISO 8601, and is close to what I want. Nevertheless, even en_SE does not completely satisfy me; especially its long format disappoints me.



This Formats settings dialog never lets you freely create custom formats. It only gives you a choice from predefined formats.



Thus, I would like to hack and modify a predefined format. Please let me know how.



The directory /usr/share/i18n/locales contains format files. The file names are identical to the format names such as en_US, en_GB, fr_FR and so on. However, the KDE that came with Debian 9.2.1 does not care about the format files in /usr/share/i18n/locales. Modification to these format files or even deletion of all of these files never affects the behavior of the KDE on Debian 9.2.1. This directory even lacks en_SE, and nevertheless en_SE appears in the Formats settings dialog.



I wonder if the predefined formats are hard-coded in KDE.



Note that Debian 9.0 Stretch was released on 2017-06-17. The versions of KDE components that came with Debian 9.2.1 follow:



plasmashell --version
# plasmashell 5.8.6

kf5-config --version
# Qt: 5.7.1
# KDE Frameworks: 5.28.0
# kf5-config: 1.0


TheEzekielProject claims in his post (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/guide-to-setting-custom-date-format-in-recent-versions-of-kde-4175595458-print/) that he managed to create a custom date time format by modifying a format file in the directory /usr/share/i18n/locales. The systems he tested are Kali Linux 2016.2 rolling with KDE Plasma 5.8.2 and KDE Frameworks 5.27.0, and Kubuntu 16.10 with KDE Plasma 5.7.5 and KDE Frameworks 5.26.0. His systems are older than mine.



I tried his method. In a format file, under LC_TIME, I changed d_t_fmt, d_fmt, t_fmt and t_fmt_ampm, and executed locale-gen, and so on. However, his method has turned out to have no effect on the KDE on Debian 9.2.1. Also a comment to his post complains that his method fails on Neon (plasma 5.10).



By the way, my question is not a duplicate of questions/1162283/use-iso-time-and-date-format-in-kde-5 on the SuperUser site. The question 1162283 asked for ISO date time format, and it has been fulfilled by the answer by
Marco Lussetti, that is, by simply selecting en_SE from the list of predefined formats. My question asks for a hack to go beyond predefined formats.









share|improve this question













share|improve this question




share|improve this question








edited Dec 14 '17 at 10:43









Jeff Schaller

31.9k848109




31.9k848109










asked Dec 14 '17 at 10:41









i7pj3qnuz

663




663











  • Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
    – Ipor Sircer
    Dec 14 '17 at 10:46










  • I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
    – i7pj3qnuz
    Jan 8 at 13:01










  • This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
    – Evi1M4chine
    Jan 27 at 13:35











  • Correction: Of course I meant find / -iname '*ksh_de*'.
    – Evi1M4chine
    Jan 27 at 14:06
















  • Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
    – Ipor Sircer
    Dec 14 '17 at 10:46










  • I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
    – i7pj3qnuz
    Jan 8 at 13:01










  • This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
    – Evi1M4chine
    Jan 27 at 13:35











  • Correction: Of course I meant find / -iname '*ksh_de*'.
    – Evi1M4chine
    Jan 27 at 14:06















Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
– Ipor Sircer
Dec 14 '17 at 10:46




Ask your question directly to KDE developers ( forum.kde.org ), they know much more about kde than us.
– Ipor Sircer
Dec 14 '17 at 10:46












I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
– i7pj3qnuz
Jan 8 at 13:01




I wish someone to ask KDE developers at the KDE forum (forum.kde.org), and post an answer back here. In general, hidden configuration options for KDE products that cannot be changed via the normal Settings dialog can be changed via the command "kwriteconfig5" or "kwriteconfig". Examples of such hidden configuration options are found on the following two web pages: "docs.kde.org/trunk5/en/pim/kmail2/…; and "reddit.com/r/kde/comments/55udc1/…;.
– i7pj3qnuz
Jan 8 at 13:01












This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
– Evi1M4chine
Jan 27 at 13:35





This is further solidified by the list of locales shown in the Plasma UI containing elements (e.g. ksh_DE) that are not present in /usr/share/i18n/locales. The find / -iname ksh_de does not even return any results. Bad KDE. BAD. Sit!
– Evi1M4chine
Jan 27 at 13:35













Correction: Of course I meant find / -iname '*ksh_de*'.
– Evi1M4chine
Jan 27 at 14:06




Correction: Of course I meant find / -iname '*ksh_de*'.
– Evi1M4chine
Jan 27 at 14:06










1 Answer
1






active

oldest

votes

















up vote
1
down vote













It took me half a day to (almost) fully investigate this, but I think I found how to do it, and you’re not gonna like it …



The Solution:



In a nutshell,



KDE just uses QT’s QLocale. Which itself uses hard-coded data inside qlocale_data_p.h, deep in QT’s core library code.



This data is apparently manually generated from the Unicode Consortium’s “Common Locale Data Repository”, using several Python scripts inside util/local_database/ of the QT source code package. Which itself is not even part of the source code, I am certain. Let alone, using any kind of configuration or data files on your computer.



So the only way to do this, is to …



  1. Download the CLDR files, either as a package, at http://unicode.org/Public/cldr/latest/core.zip (or cldr-common-*.zip, they both seem to contain the same), or at https://www.unicode.org/repos/cldr/trunk/, and extract the XML files under common/main/.

    Gentoo also has a package called app-i18n/unicode-cldr btw.

  2. Acquire the QT core source code, e.g. from your distribution’s repository, and unpack it.

  3. Use the scripts in util/local_database/ (like cldr2qlocalexml.py and qlocalexml2cpp.py), with your language of choice’s XML file, to re-generate the static qlocale_data_p.h.

  4. Then compile and install the package as normal.

And don’t forget to recompile all other packages that include qlocale_data_p.h.



Or, on Gentoo, make a lasting patch with:



ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b


NOW make the above changes in b, and not in a.



mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')


Final thoughts



To be perfectly frank, I didn’t check if those Python scripts actually worked by just passing an XML file. As, at that point, I just stopped bothering, and wanted to kill it with fire. :)



Patrick Bateman axe murderer



If anyone wants to actually do it in practice, please report, and I will update this answer. (Or do it yourself, if you can)




Here’s how I got there:



  • I opened KDE’s time formats setting dialog, via right-click on the task bar clock.

  • Then, with htop I found the most recently started processes, which included the obvious kcmshell5 formats.

  • Using htop’s list open files feature on it, I filtered for “format”, and found /usr/lib64/qt5/plugins/kcm_formats.so.

  • With the help of Gentoo’s equery belongs /usr/lib64/qt5/plugins/kcm_formats.so I could identify the package kde-plasma/plasma-desktop.

  • After unpacking its source file, I quickly found kcms/formats/kcmformats.cpp, whose addLocaleToCombo used the QLocale, and included <QLocale> too.

  • This QLocale could then be found with locate -i QLocale to reside at /usr/include/qt[5]/QtCore/qlocale.h. It included some generated enumerations of the languages, scripts, etc.

  • Another equery belongs /usr/include/qt[5]/QtCore/qlocale.h pointing me to dev-qt/qtcore/qtcore, and unpacking the source file later…

  • … I already had a gut feeling, that it was all generated with some tool. So I looked into util/ and found util/local_database/README stating “local_database is used to generate qlocale data from the Common Locale Data Repository (The database for localized names (like date formats, country names etc)).”.

  • Having never heard of that, I looked it up, and it’s apparently by the Unicode Consortium. The code of cldr2qlocalexml.py was not very useful though, as it is called with the path to a directory containing the CLDR locales. Its result is used for qlocalexml2cpp.py though, which generates the file src/corelib/tools/qlocale_data_p.h, which includes huge hard-coded tables of all the locale data. And that file already existed in the source. So… yep, it’s (partially?) hard-coded.
    facepalm

  • But the CLDR XML files were nowhere to be found. So I assume it just uses the previously prepared qlocale_data_p.h. Which is not very in the spirit of open source. But at least you can do it yourself, as described above.





share|improve this answer




















  • It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
    – theferrit32
    Apr 30 at 18:37










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f410844%2fhow-to-hack-and-modify-a-predefined-date-time-format-of-kde-5-that-comes-with-de%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













It took me half a day to (almost) fully investigate this, but I think I found how to do it, and you’re not gonna like it …



The Solution:



In a nutshell,



KDE just uses QT’s QLocale. Which itself uses hard-coded data inside qlocale_data_p.h, deep in QT’s core library code.



This data is apparently manually generated from the Unicode Consortium’s “Common Locale Data Repository”, using several Python scripts inside util/local_database/ of the QT source code package. Which itself is not even part of the source code, I am certain. Let alone, using any kind of configuration or data files on your computer.



So the only way to do this, is to …



  1. Download the CLDR files, either as a package, at http://unicode.org/Public/cldr/latest/core.zip (or cldr-common-*.zip, they both seem to contain the same), or at https://www.unicode.org/repos/cldr/trunk/, and extract the XML files under common/main/.

    Gentoo also has a package called app-i18n/unicode-cldr btw.

  2. Acquire the QT core source code, e.g. from your distribution’s repository, and unpack it.

  3. Use the scripts in util/local_database/ (like cldr2qlocalexml.py and qlocalexml2cpp.py), with your language of choice’s XML file, to re-generate the static qlocale_data_p.h.

  4. Then compile and install the package as normal.

And don’t forget to recompile all other packages that include qlocale_data_p.h.



Or, on Gentoo, make a lasting patch with:



ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b


NOW make the above changes in b, and not in a.



mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')


Final thoughts



To be perfectly frank, I didn’t check if those Python scripts actually worked by just passing an XML file. As, at that point, I just stopped bothering, and wanted to kill it with fire. :)



Patrick Bateman axe murderer



If anyone wants to actually do it in practice, please report, and I will update this answer. (Or do it yourself, if you can)




Here’s how I got there:



  • I opened KDE’s time formats setting dialog, via right-click on the task bar clock.

  • Then, with htop I found the most recently started processes, which included the obvious kcmshell5 formats.

  • Using htop’s list open files feature on it, I filtered for “format”, and found /usr/lib64/qt5/plugins/kcm_formats.so.

  • With the help of Gentoo’s equery belongs /usr/lib64/qt5/plugins/kcm_formats.so I could identify the package kde-plasma/plasma-desktop.

  • After unpacking its source file, I quickly found kcms/formats/kcmformats.cpp, whose addLocaleToCombo used the QLocale, and included <QLocale> too.

  • This QLocale could then be found with locate -i QLocale to reside at /usr/include/qt[5]/QtCore/qlocale.h. It included some generated enumerations of the languages, scripts, etc.

  • Another equery belongs /usr/include/qt[5]/QtCore/qlocale.h pointing me to dev-qt/qtcore/qtcore, and unpacking the source file later…

  • … I already had a gut feeling, that it was all generated with some tool. So I looked into util/ and found util/local_database/README stating “local_database is used to generate qlocale data from the Common Locale Data Repository (The database for localized names (like date formats, country names etc)).”.

  • Having never heard of that, I looked it up, and it’s apparently by the Unicode Consortium. The code of cldr2qlocalexml.py was not very useful though, as it is called with the path to a directory containing the CLDR locales. Its result is used for qlocalexml2cpp.py though, which generates the file src/corelib/tools/qlocale_data_p.h, which includes huge hard-coded tables of all the locale data. And that file already existed in the source. So… yep, it’s (partially?) hard-coded.
    facepalm

  • But the CLDR XML files were nowhere to be found. So I assume it just uses the previously prepared qlocale_data_p.h. Which is not very in the spirit of open source. But at least you can do it yourself, as described above.





share|improve this answer




















  • It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
    – theferrit32
    Apr 30 at 18:37














up vote
1
down vote













It took me half a day to (almost) fully investigate this, but I think I found how to do it, and you’re not gonna like it …



The Solution:



In a nutshell,



KDE just uses QT’s QLocale. Which itself uses hard-coded data inside qlocale_data_p.h, deep in QT’s core library code.



This data is apparently manually generated from the Unicode Consortium’s “Common Locale Data Repository”, using several Python scripts inside util/local_database/ of the QT source code package. Which itself is not even part of the source code, I am certain. Let alone, using any kind of configuration or data files on your computer.



So the only way to do this, is to …



  1. Download the CLDR files, either as a package, at http://unicode.org/Public/cldr/latest/core.zip (or cldr-common-*.zip, they both seem to contain the same), or at https://www.unicode.org/repos/cldr/trunk/, and extract the XML files under common/main/.

    Gentoo also has a package called app-i18n/unicode-cldr btw.

  2. Acquire the QT core source code, e.g. from your distribution’s repository, and unpack it.

  3. Use the scripts in util/local_database/ (like cldr2qlocalexml.py and qlocalexml2cpp.py), with your language of choice’s XML file, to re-generate the static qlocale_data_p.h.

  4. Then compile and install the package as normal.

And don’t forget to recompile all other packages that include qlocale_data_p.h.



Or, on Gentoo, make a lasting patch with:



ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b


NOW make the above changes in b, and not in a.



mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')


Final thoughts



To be perfectly frank, I didn’t check if those Python scripts actually worked by just passing an XML file. As, at that point, I just stopped bothering, and wanted to kill it with fire. :)



Patrick Bateman axe murderer



If anyone wants to actually do it in practice, please report, and I will update this answer. (Or do it yourself, if you can)




Here’s how I got there:



  • I opened KDE’s time formats setting dialog, via right-click on the task bar clock.

  • Then, with htop I found the most recently started processes, which included the obvious kcmshell5 formats.

  • Using htop’s list open files feature on it, I filtered for “format”, and found /usr/lib64/qt5/plugins/kcm_formats.so.

  • With the help of Gentoo’s equery belongs /usr/lib64/qt5/plugins/kcm_formats.so I could identify the package kde-plasma/plasma-desktop.

  • After unpacking its source file, I quickly found kcms/formats/kcmformats.cpp, whose addLocaleToCombo used the QLocale, and included <QLocale> too.

  • This QLocale could then be found with locate -i QLocale to reside at /usr/include/qt[5]/QtCore/qlocale.h. It included some generated enumerations of the languages, scripts, etc.

  • Another equery belongs /usr/include/qt[5]/QtCore/qlocale.h pointing me to dev-qt/qtcore/qtcore, and unpacking the source file later…

  • … I already had a gut feeling, that it was all generated with some tool. So I looked into util/ and found util/local_database/README stating “local_database is used to generate qlocale data from the Common Locale Data Repository (The database for localized names (like date formats, country names etc)).”.

  • Having never heard of that, I looked it up, and it’s apparently by the Unicode Consortium. The code of cldr2qlocalexml.py was not very useful though, as it is called with the path to a directory containing the CLDR locales. Its result is used for qlocalexml2cpp.py though, which generates the file src/corelib/tools/qlocale_data_p.h, which includes huge hard-coded tables of all the locale data. And that file already existed in the source. So… yep, it’s (partially?) hard-coded.
    facepalm

  • But the CLDR XML files were nowhere to be found. So I assume it just uses the previously prepared qlocale_data_p.h. Which is not very in the spirit of open source. But at least you can do it yourself, as described above.





share|improve this answer




















  • It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
    – theferrit32
    Apr 30 at 18:37












up vote
1
down vote










up vote
1
down vote









It took me half a day to (almost) fully investigate this, but I think I found how to do it, and you’re not gonna like it …



The Solution:



In a nutshell,



KDE just uses QT’s QLocale. Which itself uses hard-coded data inside qlocale_data_p.h, deep in QT’s core library code.



This data is apparently manually generated from the Unicode Consortium’s “Common Locale Data Repository”, using several Python scripts inside util/local_database/ of the QT source code package. Which itself is not even part of the source code, I am certain. Let alone, using any kind of configuration or data files on your computer.



So the only way to do this, is to …



  1. Download the CLDR files, either as a package, at http://unicode.org/Public/cldr/latest/core.zip (or cldr-common-*.zip, they both seem to contain the same), or at https://www.unicode.org/repos/cldr/trunk/, and extract the XML files under common/main/.

    Gentoo also has a package called app-i18n/unicode-cldr btw.

  2. Acquire the QT core source code, e.g. from your distribution’s repository, and unpack it.

  3. Use the scripts in util/local_database/ (like cldr2qlocalexml.py and qlocalexml2cpp.py), with your language of choice’s XML file, to re-generate the static qlocale_data_p.h.

  4. Then compile and install the package as normal.

And don’t forget to recompile all other packages that include qlocale_data_p.h.



Or, on Gentoo, make a lasting patch with:



ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b


NOW make the above changes in b, and not in a.



mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')


Final thoughts



To be perfectly frank, I didn’t check if those Python scripts actually worked by just passing an XML file. As, at that point, I just stopped bothering, and wanted to kill it with fire. :)



Patrick Bateman axe murderer



If anyone wants to actually do it in practice, please report, and I will update this answer. (Or do it yourself, if you can)




Here’s how I got there:



  • I opened KDE’s time formats setting dialog, via right-click on the task bar clock.

  • Then, with htop I found the most recently started processes, which included the obvious kcmshell5 formats.

  • Using htop’s list open files feature on it, I filtered for “format”, and found /usr/lib64/qt5/plugins/kcm_formats.so.

  • With the help of Gentoo’s equery belongs /usr/lib64/qt5/plugins/kcm_formats.so I could identify the package kde-plasma/plasma-desktop.

  • After unpacking its source file, I quickly found kcms/formats/kcmformats.cpp, whose addLocaleToCombo used the QLocale, and included <QLocale> too.

  • This QLocale could then be found with locate -i QLocale to reside at /usr/include/qt[5]/QtCore/qlocale.h. It included some generated enumerations of the languages, scripts, etc.

  • Another equery belongs /usr/include/qt[5]/QtCore/qlocale.h pointing me to dev-qt/qtcore/qtcore, and unpacking the source file later…

  • … I already had a gut feeling, that it was all generated with some tool. So I looked into util/ and found util/local_database/README stating “local_database is used to generate qlocale data from the Common Locale Data Repository (The database for localized names (like date formats, country names etc)).”.

  • Having never heard of that, I looked it up, and it’s apparently by the Unicode Consortium. The code of cldr2qlocalexml.py was not very useful though, as it is called with the path to a directory containing the CLDR locales. Its result is used for qlocalexml2cpp.py though, which generates the file src/corelib/tools/qlocale_data_p.h, which includes huge hard-coded tables of all the locale data. And that file already existed in the source. So… yep, it’s (partially?) hard-coded.
    facepalm

  • But the CLDR XML files were nowhere to be found. So I assume it just uses the previously prepared qlocale_data_p.h. Which is not very in the spirit of open source. But at least you can do it yourself, as described above.





share|improve this answer












It took me half a day to (almost) fully investigate this, but I think I found how to do it, and you’re not gonna like it …



The Solution:



In a nutshell,



KDE just uses QT’s QLocale. Which itself uses hard-coded data inside qlocale_data_p.h, deep in QT’s core library code.



This data is apparently manually generated from the Unicode Consortium’s “Common Locale Data Repository”, using several Python scripts inside util/local_database/ of the QT source code package. Which itself is not even part of the source code, I am certain. Let alone, using any kind of configuration or data files on your computer.



So the only way to do this, is to …



  1. Download the CLDR files, either as a package, at http://unicode.org/Public/cldr/latest/core.zip (or cldr-common-*.zip, they both seem to contain the same), or at https://www.unicode.org/repos/cldr/trunk/, and extract the XML files under common/main/.

    Gentoo also has a package called app-i18n/unicode-cldr btw.

  2. Acquire the QT core source code, e.g. from your distribution’s repository, and unpack it.

  3. Use the scripts in util/local_database/ (like cldr2qlocalexml.py and qlocalexml2cpp.py), with your language of choice’s XML file, to re-generate the static qlocale_data_p.h.

  4. Then compile and install the package as normal.

And don’t forget to recompile all other packages that include qlocale_data_p.h.



Or, on Gentoo, make a lasting patch with:



ebuild $(equery w dev-qt/qtcore:5) prepare
pushd /var/tmp/portage/dev-qt/qtcore-5*/work/ # assuming default Portage build directory
mv qtbase-opensource-src-5.9.3 a
cp -a a b


NOW make the above changes in b, and not in a.



mkdir -p /etc/portage/patches/dev-qt/$(basename $(dirname $(pwd))) # only for this version
#mkdir -p /etc/portage/patches/dev-qt/qtcore # for all versions
diff -ur a b > /etc/portage/patches/dev-qt/qtcore*/my-locale.patch
rm -rf a b
popd
ebuild $(equery w dev-qt/qtcore:5) clean
# Rebuild all packages that depend on it, just to be sure. May be optional.
emerge -1 dev-qt/qtcore:5 $(equery d dev-qt/qtcore:5 | sed 's/^/=/')


Final thoughts



To be perfectly frank, I didn’t check if those Python scripts actually worked by just passing an XML file. As, at that point, I just stopped bothering, and wanted to kill it with fire. :)



Patrick Bateman axe murderer



If anyone wants to actually do it in practice, please report, and I will update this answer. (Or do it yourself, if you can)




Here’s how I got there:



  • I opened KDE’s time formats setting dialog, via right-click on the task bar clock.

  • Then, with htop I found the most recently started processes, which included the obvious kcmshell5 formats.

  • Using htop’s list open files feature on it, I filtered for “format”, and found /usr/lib64/qt5/plugins/kcm_formats.so.

  • With the help of Gentoo’s equery belongs /usr/lib64/qt5/plugins/kcm_formats.so I could identify the package kde-plasma/plasma-desktop.

  • After unpacking its source file, I quickly found kcms/formats/kcmformats.cpp, whose addLocaleToCombo used the QLocale, and included <QLocale> too.

  • This QLocale could then be found with locate -i QLocale to reside at /usr/include/qt[5]/QtCore/qlocale.h. It included some generated enumerations of the languages, scripts, etc.

  • Another equery belongs /usr/include/qt[5]/QtCore/qlocale.h pointing me to dev-qt/qtcore/qtcore, and unpacking the source file later…

  • … I already had a gut feeling, that it was all generated with some tool. So I looked into util/ and found util/local_database/README stating “local_database is used to generate qlocale data from the Common Locale Data Repository (The database for localized names (like date formats, country names etc)).”.

  • Having never heard of that, I looked it up, and it’s apparently by the Unicode Consortium. The code of cldr2qlocalexml.py was not very useful though, as it is called with the path to a directory containing the CLDR locales. Its result is used for qlocalexml2cpp.py though, which generates the file src/corelib/tools/qlocale_data_p.h, which includes huge hard-coded tables of all the locale data. And that file already existed in the source. So… yep, it’s (partially?) hard-coded.
    facepalm

  • But the CLDR XML files were nowhere to be found. So I assume it just uses the previously prepared qlocale_data_p.h. Which is not very in the spirit of open source. But at least you can do it yourself, as described above.






share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 27 at 17:06









Evi1M4chine

27527




27527











  • It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
    – theferrit32
    Apr 30 at 18:37
















  • It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
    – theferrit32
    Apr 30 at 18:37















It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
– theferrit32
Apr 30 at 18:37




It is absurd that KDE and GNOME use hardcoded date format options, or don't at least include an ISO-8601 or RFC-3339 compliant hardcoded option. Both XFCE and Tint2 panels allow arbitrary strftime strings (like in date command). Honestly the simple fact that XFCE lets me display time in an arbitrary format is a huge advantage to me, because the GNOME time widget is awful to look at, and while KDE allows for more detail it doesn't comply with standards.
– theferrit32
Apr 30 at 18:37












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f410844%2fhow-to-hack-and-modify-a-predefined-date-time-format-of-kde-5-that-comes-with-de%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay