Make userconfirm prompt strings translatable

[Userfrom1995]

The confirmation prompt "Is this ok [Y/n]:" and response characters were hardcoded strings in the userconfirm.hpp template function, making them untranslatable.

Changes:

• Extract translatable strings to libdnf5-cli/utils/userconfirm.cpp
• Add helper functions: get_yes_no_prompt(), get_yes_response(), etc.
• Update libdnf5-cli.pot with new translatable strings

The userconfirm template now calls helper functions that return translated strings from the libdnf5-cli translation domain, allowing translators to localize the prompt and response characters.

Fixes: #1868

[Userfrom1995]

I’ve updated the POT and PO files. I’m not fully sure whether they were supposed to be updated. If not, just let me know and I’ll revert those changes.

[Userfrom1995]

CI failure doesn't seem related to my changes. Am I missing something?

[ppisar]

Correct implementation should use nl_langinfo() to retrieve the translated Yes/No expressions. This manual reimplementation is a step in wrong direction.

[evan-goode]

Agreed, after I learned about https://man7.org/linux/man-pages/man3/nl_langinfo.3.html and YESEXPR/NOEXPR. IMO we also don't need to add new public API functions. We can keep the logic contained in userconfirm.

[Userfrom1995]

Correct implementation should use nl_langinfo() to retrieve the translated Yes/No expressions. This manual reimplementation is a step in wrong direction.

Thanks for review. I was not aware of nl_langinfo().
I will update the implementation to use it.

[Userfrom1995]

Agreed, after I learned about https://man7.org/linux/man-pages/man3/nl_langinfo.3.html and YESEXPR/NOEXPR. IMO we also don't need to add new public API functions. We can keep the logic contained in userconfirm.

Thanks for review.
I will remove the new public API functions and userconfirm.cpp, and keep all the logic inside userconfirm.hpp.

[ppisar]

I believe the prompt was intentionally kept noninternationalized because if the correct way needs setting C++ locale, what DNF5 does not do now, you will run into flawed number formatting as tried and described in #1699. Resolving that will first require thorough review all all places where numbers are formatted.

[Userfrom1995]

I believe the prompt was intentionally kept noninternationalized because if the correct way needs setting C++ locale, what DNF5 does not do now, you will run into flawed number formatting as tried and described in #1699. Resolving that will first require thorough review all places where numbers are formatted.

I agree with the part that setting the C++ locale will break things, but this patch only uses the already set C locale, and I don't see any number or anything involved that may cause an issue in this patch, so I still can't understand how this patch will break things.

I have made the suggested changes using nl_langinfo() and removed the extra userconfirm.cpp file.

Sorry for being two months late with the update.

[evan-goode]

Thanks, this does seem to pick up the correct YESEXPR/NOEXPR. However, I still cannot see translations for the "Is this ok [Y/n]: " message, for example, if I add the following to dnf5/po/es.po libdnf5-cli/po/es.po:

msgid "Is this ok [Y/n]: "
msgstr "¿Está bien? [S/n]: "

msgid "Is this ok [y/N]: "
msgstr "¿Está bien? [s/N]: "

Am I just missing something, were you able to get it working?

Another concern is that the yesexpr/noexpr value and the translated message [Y/n] may be or may become out of sync. For example, we don't yet have a Swahili translation, so Swahili-speaking users would likely see the English fallback. Yet according to https://lh.2xlibre.net/values/yesexpr/, the sw_KE yesexpr is ^[+1nNyY]. So I believe with this patch, it would print

Is this ok [y/N]:

and then if the user types n, it would be considered "yes" 🙃

[Userfrom1995]

Thanks, this does seem to pick up the correct YESEXPR/NOEXPR. However, I still cannot see translations for the "Is this ok [Y/n]: " message, for example, if I add the following to dnf5/po/es.po libdnf5-cli/po/es.po:

msgid "Is this ok [Y/n]: "
msgstr "¿Está bien? [S/n]: "

msgid "Is this ok [y/N]: "
msgstr "¿Está bien? [s/N]: "

Am I just missing something, were you able to get it working?

Yes, I was able to get it to work on my local environment. The steps I took were:

I ran make libdnf5-cli-pot to update the template.
I updated the .po files using:
cd libdnf5-cli/po && for f in es.po cs.po de.po fr.po; do msgmerge --update "$f" libdnf5-cli.pot; done
I added the translations to the respective files.
I committed the changes.
I did an RPM build and installed the new binary, and then it worked.

Another concern is that the yesexpr/noexpr value and the translated message [Y/n] may be or may become out of sync. For example, we don't yet have a Swahili translation, so Swahili-speaking users would likely see the English fallback. Yet according to https://lh.2xlibre.net/values/yesexpr/, the sw_KE yesexpr is ^[+1nNyY]. So I believe with this patch, it would print

Is this ok [y/N]:

and then if the user types n, it would be considered "yes" 🙃

Yes, it was a major issue with my previous implementation and I have tried to solve it. Now, the yesexpr and noexpr from nl_langinfo are used only if a translation is available. If the prompt falls back to English, it strictly uses the "English regex".

Sorry for the delay with the reply.