Details
-
Bug
-
Resolution: Duplicate
-
Not Evaluated
-
None
-
6.7, 6.8
-
None
Description
When the POSIX locale set on the system is not covered by the CLDR table, the setting is ignored. This can for example happen when the Qt version is too old for the system, or when an organization/user has created a custom locale, or when the locale just isn't in the CLDR at all.
On an up to date Arch Linux installation that seems to affect some 40 or so locales because they have no counter part in the QLocale (i.e. QLocale("$locale") returns C)
To reproduce e.g. on Ubuntu as root:
cd /usr/share/i18n/
echo 'sitter.UTF-8 UTF-8' >> SUPPORTED
cd locales
cp de_AT sitter
LC_ALL=sitter.UTF-8 date # shows de_AT format
this qml:
// SPDX-License-Identifier: BSD-2-Clause // SPDX-FileCopyrightText: 2024 Harald Sitter <sitter@kde.org> import QtQuick Item { Component.onCompleted: { let date = new Date() console.log(Qt.formatDateTime(date)) } }
Shows en_US date format because it fails to map sitter to a QLocale data set. Running it with LC_ALL=de_AT.UTF-8 correctly maps and yields localized results.
This appears to happen because qlocale_unix routes the POSIX locale variables through QLocale which ultimately will try to find it in the CLDR map and if not found default to C. The supposed solution would be to newlocale instead and then query {}{{nl_langinfo{}}}_l and friends in the query function.
In point of fact: as a side effect of routing everything through qlocale, even the localized results may be wrong from a platform point of view. On ubuntu 22.04 the d_fmt for de_AT is ISO 8601 YYYY-MM-DD but Qt prints the (alternative) DIN 5008:2020-03 format DD.MM.YY.
Long story short: Qt doesn't produce the same output as other applications on Linux because it doesn't properly integrate with the platform locale system.
Attachments
Issue Links
- duplicates
-
QTBUG-122633 QLocale doesn't align with C library functions to let us use them for system locale data
- Open