i18n: add localization support for yes/no prompts and answers

[marcotuliomatos]

This change adds localization support for all yes/no prompts presented by the Apdatifier Bash scripts (printQuestion() in the utils script), as well as for the corresponding answer options available to the user.

With this change, the appropriate answer options have already been added to all .po translation files. Their contents reflect the values of yesexpr and noexpr in the glibc LC_MESSAGES section for each locale. This not only ensures consistency with the way many applications handle locales through glibc, but also has the benefit of lowering the barrier to adding support for new languages in Apdatifier, since the regex used to handle yes/no variants across a wide range of languages is already available in glibc.

To pave the way for this change, the conditional processing of user answers had to be replaced with if/then/else statements, which, unlike the case statements previously in use, are able to handle regex matching. The use of regex became necessary due to certain language-specific cases, such as Ukrainian. This situation is well described in glibc LC_MESSAGES for uk_UA:

% WARNING: symbols "Y" and "Cyrillic_N" are placed at one key in Ukrainian keyboard
% layout although the meaning is semantically opposite ("Y" stands for "Yes"
% while "Cyrillic_N" stands for "No").
%
% This problem may be dealt with by requiring at least two letters to be
% entered in Ukrainian language.

And:

% WARNING: symbols "N" and "Cyrillic_T" are placed at one key in Ukrainian
% keyboard layout although the meaning is semantically opposite ("N" stands for
% "No" while "Cyrillic_T" stands for "Yes").
%
% We may require two Ukrainian letters as input to deal with this potential
% problem.

Dealing with та/так/НІ (and their respective uppercase/lowercase variants) using Bash globs, although possible, would be overly hacky and could increase the maintenance burden, whereas regex handles them cleanly with ^([+1Yy]|[Тт][Аа][Кк]?)$ and ^([-0Nn]|[Нн][Іі])$.

Overall, everything seems to work as intended with this approach. Tests were performed manually to verify correct prompt behavior in all languages currently supported by Apdatifier.

[exequtic]

The standard y/n form is widely used in CLI tools and is already the expected convention for many users. Even pacman keeps the standard y/n prompts, while yay past attempts to localize yes/no answers have caused input-handling issues.

I’d prefer not to add more translation-related logic. The text in the widget is constantly being added to and changed, while community support for translations is almost nonexistent. For that reason, translations will most likely no longer be included in the widget’s package and will remain optional, or may even be removed entirely, so I don’t want to expand this part any further.

[marcotuliomatos]

Hi, thanks for the feedback.

I understand the preference for keeping the standard y/n form for consistency. I just wanted to clarify one point: in my environment, both pacman and yay already present localized yes/no prompts, so localized prompt answers are not necessarily outside the usual CLI experience:

$ sudo pacman -Syu
:: Sincronizando a base de dados de pacotes...

[...]

:: Continuar a instalação? [S/n] <--------

yay -S protonup-qt

AUR Explicit (1): protonup-qt-2.15.0-1

[...]

:: Prosseguir com a instalação? [S/n] <--------

That said, I understand your concern about adding more translation-related logic, especially if translations are becoming harder to maintain. I still think localization adds real value for non-English-speaking users, as well as for those like myself who can use English but are not native speakers, so I hope it can remain part of the project in some form.

My main goal with this PR was to make the existing localization support more consistent and reliable where translations are already present, while keeping the implementation aligned with well-established locale rules present in glibc. But I understand that this may not fit the project direction you have in mind right now.

Thanks again for your time. I’ll keep the pt_BR translation updated as long as localization remains in the project, and I’ll be happy to contribute in other areas as well.