Internationalization questions and bugs.
Details
Tue, Nov 5
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.
Mon, Nov 4
Wed, Oct 9
Sep 30 2024
May 16 2024
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.
Mar 28 2024
Feb 21 2024
Thanks for your work. I applied it to Gpgex.
Feb 14 2024
Will do. Thank you very much.
Feb 10 2024
Feb 9 2024
Feb 8 2024
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.
Feb 7 2024
Jan 24 2024
No regression, assuming things work.
Jan 5 2024
Nov 29 2023
Oct 27 2023
Thanks. I'll apply your patch.
Oct 20 2023
Well, this bug is fixed by using a decent libgpg-error or configure it correctly.
Oct 10 2023
I think ".UTF8" is always better than LC_TIME="" if the display string contains non-English Unicode chars.
Oct 6 2023
Feb 9 2023
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.
Feb 8 2023
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.
I have no idea about Homebrew - can you figure out the maintainer and point him to here?
Feb 7 2023
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.
Feb 6 2023
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
Jul 29 2022
It is unlikely that the tofu stuff will get into widespread use in the 2.2 version - if at all.
Jan 22 2022
Jan 20 2022
Jan 10 2022
That seems to (mostly) work partially fix PowerShell pipeline output at least:
Oct 1 2021
Sep 29 2021
Hello again Werner,
Ok, but the problem is that by default CMD command windows do not use any Unicode set of characters, and their default font is 'Raster characters' and the typical display of characters inside these windows, at least for Italian people because this was the default since MS-DOS age, is to only consider using MS-DOS ASCII codepage 850, not Unicode.
And this is also why before showing the error message I ran the command mode.
Anyway because of the 2 characters getting displayed instead of single expected 'è' (whose character code is 0x82) I can also tell you that by using Charmap.exe again (just in case you may not know it allows display of any Unicode or Raster font characters and their hexadecimal codes) and so switching its default font from System (Unicode) to 8514oem (raster, corresponding to 8514oem.fon) I've been able to determine which should be the 2 wrong displayed characters hexadecimal codes : 'Ã' (0xC3), and '¨' (0xA8) but here obviously both characters cannot be represented correctly because this site is using 'Segoe UI' font, which is Unicode too.
So the only main way to check that I identified the correct characters will be if you (or someone else you know) with another Windows client run Charmap.exe switch font to 8514oem (raster) and check that displayed characters corresponding to 0xC3 and 0xA8 are the same that got displayed in the error message bitmap I provided (a part from probably being able to find where in Italian messages localization rather then in source code those 2 characters have been used incorrectly).
P.S. Because in a past similar bug about Italian localization I saw a comment from you about this kind of option, please just let me know in case you think I might possibly be able to help you to review involved 'GPG' Italian error message(s) for this bug.
Sep 28 2021
That pretty much looks like the other errors you have with Unicode characters - which we can't replicate.