The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 11 2021
Feb 10 2021
We have the --unwrap option which already does this. The problem here is that an addition compression layer is not removed. Therefore I will rename this report to add a feature strip things down to a signature or literal data packet..
Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.
The other patches don't make sense because of future plans for dirmngr.
Feb 4 2021
I have to leave this as open as this describes a clear issue users expirience in our software. I assign it to me to keep an eye on the issue. Werner and me discussed this issue at length verbally and there won't be a quick fix for the stable branch but we will address this some time in the future, but then not only for 8bit but for full unicode.
Feb 3 2021
I mentioned it several times: It is not sufficient to use some wmain as long as we don't rework the entire spawn machinery in gnupg. libassuan and gpgme. Reading Unicode from the command line would be easy the other things are the real work.
And in fact it was never possible to use 8bit filenames on the command line. The result was not stable and led to non-compatible messages due to the use of native character set instead of proper utf-8. It depended on just too much things.
gpgme-tool or gpgme-json might be useful workaround.
You can use --multifile for this. This reads the filenames from a descriptor or a file. One on the reasons to implement Unicode handling at most places was a request to allow using --multifile as a workaound for the command line limitation..
Jan 29 2021
Jan 28 2021
The last server of the HKPS pool dropped off for several hours yesterday, during which hkps.pool.sks-keyservers.net could not be resolved.
Jan 26 2021
Sorry, we won't apply such changes. A couple of years we did this and all we earned were a few extra bugs aqnd useless diffs. Further many of those changes are in files which will be updated from upstream time to time and your chnages would be lost.
OK, I only edited documents and notes, no code changes.
Thanks. However, we need to go over the list one by one to decide this. For example
"http://gnupg.org/.well-known/openpgpkey/hu/12345678" is actually expected to return a 404 and test code may very well use http:
Jan 25 2021
Jan 23 2021
Hi,
you can close this tickets, the Italian translation has already been uploaded successfully. Don't import anything to GnuPG. Thanks a lot!
Jan 22 2021
Jan 21 2021
Jan 20 2021
Jan 19 2021
Jan 18 2021
Jan 11 2021
We are hoping to have at least a beta release soon with gcrypt 1.9 that we can put in a Gpg4win-4 beta.
Jan 10 2021
I think the main work of listed translation update has been completed, and other minor problems will be corrected in the future patch.
Jan 8 2021
rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.
Jan 7 2021
I'm also getting this same error with GPG4Win 3.1.14.
Description and translation domain were swapped in 2.2.
D520 is accepted by me.
If you will have another fixes, please go ahead.
Or else, I'll commit the change to master of GnuPG.
Jan 5 2021
In T5189#140853, @gniibe wrote:Please check following translations:
"do not detach from the console" "do not use the internal CCID driver" "do not use a reader's pinpad"Those are explanation for the options to instruct gpg-agent or scdaemon, not do something.
It's not a text to users.
I think we can close this one, right?
rG6850f21d08b2: po: Fix Simplified Chinese Translation. is a fix for adjusting columns; The number means the number of columns.
rGf4a8be0950ea: po: Fix Simplified Chinese Translation. is a fix for:
- SETERROR is a command name of pinentry which should not be translated.
- The message is expected to be displayed in four lines.
Please check following translations:
"do not detach from the console" "do not use the internal CCID driver" "do not use a reader's pinpad"
Those are explanation for the options to instruct gpg-agent or scdaemon, not do something.
It's not a text to users.
Sorry, I didn't read your message above, and it's applied and pushed to master, due to exactly same reason (it's so big).
It's easier (at least for me), when it's in git repo.
Dec 30 2020
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
Dec 29 2020
Hope he/she could help with that.
Dec 28 2020
In T5189#140669, @gniibe wrote:Reviewed D517 and pushed it as rE621446d3c859: po: Update Traditional Chinese Translation..
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..
Dec 26 2020
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
Dec 25 2020
Dec 24 2020
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
Thank you for your effort. I'll review.
Dec 23 2020
patch of libgpg-error/po/zh_CN.po
D516: po: Update simplified Chinese translation po/zh_CN.po
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.poSorry, 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.poSorry, 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
For D515, I will also apply it to master.
Applied D514 to master, with an editorial change (removing extra space before newline).
Dec 21 2020
also update doc/help.zh_TW.txt by the way
D515: update gnupg doc/help.zh_TW.txt
Yes, that worked. Thanks for the tip and sorry for the noise ;-)
upload the v2 patch and create a revision
D514: update gnupg doc/help.zh_CN.txt
waiting for review
:-)
Please not that you can use this interface: https://dev.gnupg.org/differential/
I think that it is better when you update your patch. You can just refer a patch from this task by:
In T5189#140362, @gniibe wrote:Do you call gpg-agent as 'Gpg 代理'? IIUC, it is better keep it as is (gpg-agent), because it is the name of the program.
If translated, 'keygrip' should be different word to 'fingerprint', because 'fingerprint' is used as a technical term of OpenPGP.
Do you call gpg-agent as 'Gpg 代理'? IIUC, it is better keep it as is (gpg-agent), because it is the name of the program.
I think that ... For some reason, your private key file under .gnupg/private-keys-v1.d has wrong serial number.
Dec 20 2020
OS, Compiler, any configure options?
In a discussion we decided that we need a deadline for GnuPG 2.3.0 so that we finally release it.