-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dnf5 does not use localized package summaries and descriptions (or field labels etc.) #1687
Comments
There two separate issues in the "dnf info" output:
The first is a sole problem of DNF. The latter depends on whether the package has not yet been installed, or whether it is already installed. For the uninstalled case it depends on what is stored in the repository. Looking at Fedora repositories, I cannot find any translations in them. Hence, I worry DNF5 won't be able to display translations of summary and description. That confirms your DNF4 tests. I tried creating a local repository with a package having a summary in multiple languages, and the result was disappointing: The repository stored a text for the locale used when the repository was created, but stored the text as an English text. That means a tool Fedora uses for creating repositories cannot create repositories with translations. |
Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB". DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used. C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only set the C locale up to now.. This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0). I manully tested dnf5 and dnf5daemon-client and it works for me. Though, there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome. Related: rpm-software-management#1687
Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB". DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used. C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only has set the C locale up to now. This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0). I manully tested dnf5 and dnf5daemon-client and it works for me. Though, there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome. Related: rpm-software-management#1687
Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB". DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used. C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only has set the C locale up to now. This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0). I manually tested dnf5 and dnf5daemon-client and they work for me. Though, there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome. Related: rpm-software-management#1687
Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB". DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used. C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only has set the C locale up to now. This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0). I manually tested dnf5 and dnf5daemon-client and they work for me. Though there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome. Related: rpm-software-management#1687
Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB". DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used. C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only has set the C locale up to now. This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0). I manually tested dnf5 and dnf5daemon-client and they work for me. Though there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome. Related: rpm-software-management#1687
In Fedora 40 there is now dnf version 5.1.17. This version does not use locale. |
What I see when I try this in a Fedora 41 mock chroot with
…so Unicode output is working in my default locale. But now, if I set it explicitly:
Ouch, now all the non-ASCII symbols are escaped as in the original report for #1685! If I try |
That is a dnf5 problem. The PR (just new) #1698 marks these strings for translation. And then the translations for each language will need to be added. |
I tried it and got
So, I installed langpack with And now it is working:
Can you check if you have the same problem? |
Ok, I’m seeing the same thing. For |
The string Lines 959 to 965 in 117bc3e
|
As reported in #1685 (comment):
There are also differences in localization, which kind of worked in
rpm
, kind of worked differently indnf
4, and doesn’t work at all indnf5
. You can compare these in Fedora 40:LC_ALL=zh_CN.utf8 rpm -qi python3-fastapi
: uses localized summary and description text and build date; does not localize its own fixed strings (field labels)LC_ALL=zh_CN.utf8 dnf info python3-fastapi
: localizes all of its own strings (dates, field labels), but does not use the localized summary and description textLC_ALL=zh_CN.utf8 dnf5 info python3-fastapi
: ignores locale completely, hex-escapes•
in the default English description(Don’t try other locales for now; I just fixed an issue with the other localized descriptions in the
python-fastapi
spec file, and the updates for this are not yet in stable repositories.)Displaying localized text will require proper Unicode support, #1685, for most locales.
The text was updated successfully, but these errors were encountered: