Actually this isn't really a special case when you want to migrate your existing ssh keys to gpg and import them. As stated in this guide https://opensource.com/article/19/4/gpg-subkeys-ssh-multiples, what you need to do currently is export the master key with its private keys, delete the imported ssh key from your keyring and then import your private keys again.

In T5214#140791, @werner wrote:

For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

update for gnupg po/zh_CN.po
D518: po: Update Simplified Chinese translation po/zh_CN.po
the update is so big, so please review when you are free, and do not be push
thanks for all help

I fixed the latter two points. For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

Reimplemented 8 block parallel in "vertical" orientation.

With little extra effort, stitched implementation turned out ok after all.

I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

Hope he/she could help with that.

We should see that we can implement an auto-key-locate feature also in gpgsm. This would allow us to fetch the key as needed from the AD or another LDAP server.

please move away %AppData%\gnupg
it usually expands to c:\users\yourusername\AppData\Roaming\gnupg

Screenshots of the issue are attached.

Use released version or post to gnupg-devel for help.

Please report about released versions. If you have problems building from Git, posting to gnupg-devel is the best way forward,.

When building from git make sure that you have all tools installed and use
./autogen.sh --force
before running configure. Do not use autoreconf etc.

In T5189#140669, @gniibe wrote:

Reviewed D517 and pushed it as rE621446d3c859: po: Update Traditional Chinese Translation..

gniibe received another patch from Debian.

For D515, I think that there is similar issue, and I received another patch from Debian.

Reviewed D517 and pushed it as rE621446d3c859: po: Update Traditional Chinese Translation..

I did editorial change for meta data.
Also, I fixed the translation of "out of core", even if it's unused (it's comment).

GnuPG requires some C99 features - thus a language level of C89 might not work. We use variadic macros and the func macro. For details see doc/HACKING.

OS:AIX , Compiler: XLC

In D517#4833, @bobwxc wrote:

In D517#4831, @chyen wrote:

Thanks a lot for the translations! However, some terms appear to be translated from Simplified Chinese. Here are some suggestions:
...

Got that, thank you :-)
Any other suggestion?

In D517#4831, @chyen wrote:

Thanks a lot for the translations! However, some terms appear to be translated from Simplified Chinese. Here are some suggestions:
...

Got that, thank you :-)
Any other suggestion?

Thanks a lot for the translations! However, some terms appear to be translated from Simplified Chinese. Here are some suggestions:

Pushed the change for libgpg-error zh_CN.po.

For PO file editing, what I use (for Japanese Translation) is:

• Emacs PO mode: https://www.emacswiki.org/emacs/PoMode

There are actually tools for PO file editing:
http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/tools/trans_editors.html

use poedit to rebuild it

I think that you don't use PO editor. I'm going to remove mark like ", fuzzy", which should be removed when entering good entry.

Thank you for your effort. I'll review.

The patch will be in 2.2.27. Thanks.

Simply add -v or --verbose to the gpg invocation too see infos about the pinentry. --debug-level is not helpful here.
And well, we don't have a way to test stuff on Vista anymore. You should also update to at least Windows 7.

patch of libgpg-error/po/zh_CN.po
D516: po: Update simplified Chinese translation po/zh_CN.po

Good catch. This is due to back porting a change from master. However the extra introduced conditional of

if (sig->version >=4)

will always evaluate to true. It is set a bit above and GnuPG does not handle public key packets with version 3 anymore. So this if can actually be removed. Thus no harm.

Please provide detailed information about the build peoblem. An arbitrary paste from a build does not make up a bug report. If you need support building GnuPG you may want to look for a commercial offer or to ask on a mailing list. From what I see I assume you have an incomplete installation of the supporting libraries.

In T5189#140595, @gniibe wrote:

Please note that many error messages are defined in: https://dev.gnupg.org/source/libgpg-error/browse/master/po/zh_CN.po
and https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po

Sorry, in case you already know that.

May I ask that how to get a new complete clean po file.
I'm not familiar with gettext.
The old one is confusing, and I think maybe I should completely clean the messy.
Really a big project.

Frankly, I more or less forgot about these help files. The German version for sure needs an update as weel.

In T5189#140595, @gniibe wrote:

Please note that many error messages are defined in: https://dev.gnupg.org/source/libgpg-error/browse/master/po/zh_CN.po
and https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po

Sorry, in case you already know that.

In T5189#140594, @gniibe wrote:

For D515, I will also apply it to master.

Before that, I'd like to confirm an editorial change of mine:

• Remove an extra space before new line (two places)

Please and thanks, I imitated the English edition format :-)

• Remove a comment for use case of the file
  • If needed, we could have support of another locale(s) with Chinese language: zh_HK, zh_SG, etc.
  • It is not us, but it's users who decide which locale is better for them
    • E.g., my friend in Düsseldorf uses ja_JP locale
  • So, it's technically better not to address restriction in a translation

for that, I think you best keep that.
Use a locale to distinguish Chinese users always cause problems.
There isn't a big difference between the written language. And small region always lack translations.
Singapore's users who use simplified Chinese always use zh_CN if there is no a specific zh_SG.
And the traditional Chinese users from HK SAR and MC SAR sometimes use the translation for Taiwan Province.
So when translate it, the tip remiand you must consider all the users from anywhere.

Please note that many error messages are defined in: https://dev.gnupg.org/source/libgpg-error/browse/master/po/zh_CN.po
and https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po