The umlauts are ok again!

I have reverted the commit mentioned by Carl and another text codec related commit for the Qt 5 builds. This will hopefully fix the broken umlauts in the progress messages.

This might be caused by https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win-tools.git;a=commit;h=30b5736a97d884452c9ad8c713600326ee06a7c3

Thanks! please consider adding it to 2.2 and master as well. I suspect it's more outdated than it would be if it had been shipping in the upstream tarball.

Pretty outdated, but I add it nevertheless to 2.4
s/gnupg-2.4/po/nl.po: 1320 translated messages, 625 fuzzy translations, 268 untranslated messages.

Thanks for your work. I applied it to Gpgex.

Will do. Thank you very much.

Looks like
https://bugs.kde.org/buglist.cgi?component=it&product=i18n&resolution=---
is the bug tracker for Italian translations.

Setting the priority to low because that is the task for the KDE translation team. I am not sure how we can interact with the translation team, bug tracker wise. Do they have their own tracker?

Check https://community.kde.org/Get_Involved/translation for information how to contact the translators and/or become active in translation.

No regression, assuming things work.

Thanks. I'll apply your patch.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

Good catch. The translation of the option descriptions is done as part of the option parser (libgpg-error/src/argparse.c) and thus we need to have gettext support over there. Also for some other error messages.

Seems to work if NLS support is enabled. Updating in https://github.com/Homebrew/homebrew-core/pull/122706. Once merged, users will need to brew reinstall libgpg-error (Homebrew has decided to avoid forcing updates to all users outside of critical fixes).

Probably due to libgpg-error being built without NLS support on macOS as formula currently doesn't have gettext dependency. On Linux, libintl is provided by glibc so doesn't need any extra dependencies.

This is the formula: https://github.com/Homebrew/homebrew-core/blob/c26f1c8714c231ee6796915f033ba229c89af3d6/Formula/gnupg.rb

I have no idea about Homebrew - can you figure out the maintainer and point him to here?

This is the Homebrew build. Maybe something not included in the recipe?

No idea what happens. I can't replicate that on a Linux box using GNU gettext and neither in Windows using gnupg's own gettext implementation. It seems that strings without any line feed don't get translated.

Thanks. Looks pretty standard. I will have a closer look.

gpgconf -L:

sysconfdir:/usr/local/etc/gnupg
bindir:/usr/local/Cellar/gnupg/2.4.0/bin
libexecdir:/usr/local/Cellar/gnupg/2.4.0/libexec
libdir:/usr/local/Cellar/gnupg/2.4.0/lib/gnupg
datadir:/usr/local/Cellar/gnupg/2.4.0/share/gnupg
localedir:/usr/local/Cellar/gnupg/2.4.0/share/locale
socketdir:/Users/emirsari/.gnupg
dirmngr-socket:/Users/emirsari/.gnupg/S.dirmngr
keyboxd-socket:/Users/emirsari/.gnupg/S.keyboxd
agent-ssh-socket:/Users/emirsari/.gnupg/S.gpg-agent.ssh
agent-extra-socket:/Users/emirsari/.gnupg/S.gpg-agent.extra
agent-browser-socket:/Users/emirsari/.gnupg/S.gpg-agent.browser
agent-socket:/Users/emirsari/.gnupg/S.gpg-agent
homedir:/Users/emirsari/.gnupg

Can you please provide the output of

It is unlikely that the tofu stuff will get into widespread use in the 2.2 version - if at all.

That seems to (mostly) work partially fix PowerShell pipeline output at least:

Hello again Werner,