Request for comments on autocrypt translation strings

[Petr Pisar]

On Sat, Aug 03, 2019 at 02:21:26PM -0700, Kevin J. McCarthy wrote:
> Hello Mutt Translators,
> 
> After about a month of hard work, I've finally pushed an autocrypt 
> implementation into master (https://autocrypt.org/).  There's still a 
> lot of testing to do, but I also wanted to get feedback from you all 
> about the translation strings.
> 
> I'm attaching a mutt.pot file.  If any of you have the time, would you 
> mind taking a look at the new strings and L10N comments?  Note: I am 
> *not* asking for translations at this time, just your feedback on things 
> that could be improved, typos, etc.
> 
I did not study the Autocrypt specification, only their About and FAQ. Maybe
therefore some messages are difficult to understand for me:

#. L10N:
#. The first time mutt is started with $autocrypt set, it will
#. create $autocrypt_dir and then prompt to create an autocrypt
#. account with this message.
#.
#: autocrypt/autocrypt.c:121
msgid "Create an initial autocrypt account?"

This sounds like an account of some on-line service. If it is about creating
a record in the autocrypt directory, why not call it a record or an entry?
I don't like the word "account".

#. L10N:
#. Message displayed just before a GPG key is generated for a created
#. autocrypt account.
#.
#: autocrypt/autocrypt_gpgme.c:136
msgid "Generating autocrypt key..."

Does the new feature use a completly new and separate PGP key from a key the
users already has in his private GPG keyring? If it does not and it is still
the same key, then I'd rather use e.g. "Generating PGP key..." I don't like
distinguishing it as "autocrypt" if it is a standard PGP key operated through
gpgme library stored in standard user's key ring.

msgid "No (valid) autocrypt key found for %s."
msgid "Error creating autocrypt key: %s\n"
msgid "Generating autocrypt key..."

The same issue.

I did not study Mutt implementation, but I really don't like the concept
that MUA silently replaces recipient's keys based on what it gets in an unsigned
e-mail header. This completely undermines a web of trust. I understand that
it's good enough for oportunistic encryption, but if a user already has an
established trust or relies on trust-on-first-use, then the silent unverified
key change kills it. If it indeed operates like that, then that's a reason why
I won't use it. It downgrades my security.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-po/attachments/20190804/b21acd9a/attachment.asc>