We have a lot of (enigmail) strings that are currently in content/ so we can change them freely to iterate.

These strings should be moved to a localizable place, but first they should be converted to using Fluent so that we don't have to go through a tedious migration process for them.

I'm talking about (at least) these:
https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/strings

https://firefox-source-docs.mozilla.org/l10n/fluent/tutorial.html

Part 1.

Part 2.

I'll land these so we don't bitrot.

There is a functional change in msgReadStatus, for the upper signature status. The short summary header is done. Now the longer explanation text is shown as bold.

Check-in needed for 1638822-fix-openpgp-one-recipient-status-status.patch and 1638822-fix-read-sig-explanation-v2.patch.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/28d70f3af773
fix for upper signature status. r=khushil
https://hg.mozilla.org/comm-central/rev/ec0e99a2f1e4
fix read sig explanation. r=khushil

Kai - please set up your .hg username/email. (I noticed to late, it's wrong here.)

Sorry, I had forgot to rebuild!

Some minor adjustments for strings, while we can.

Typo:
.label = Display Untrusted Ueys

This is missing the word "it"
.label = Yes, but I have not verified that is the correct key.
It should be
.label = Yes, but I have not verified that it is the correct key.

But I'm not sure I like your change.
You removed the suffixes (rejected), (undecided), (unverified) and (verified) from the acceptance selection.

I had added those labels as a one-word summary, to enable a recognition effect in other places.
In the one receipient dialog you kept those labels.

To clarify my comment. I'd prefer to keep the trailing "(...)" elements in the following strings:

openpgp-acceptance-rejected-label =
-    .label = No, never use this key. (rejected)
 openpgp-acceptance-undecided-label =
-    .label = Not yet, maybe later. (undecided)
 openpgp-acceptance-unverified-label =
-    .label = Yes, but I don't know if it is the correct key. (unverified)
 openpgp-acceptance-verified-label =
-    .label = Yes, I've verified in person this key has the correct fingerprint. (verified)

(In reply to Kai Engert (:KaiE:) from comment #31)

But I'm not sure I like your change.
You removed the suffixes (rejected), (undecided), (unverified) and (verified) from the acceptance selection.

Yes, it's super ugly.

I had added those labels as a one-word summary, to enable a recognition effect in other places.
In the one receipient dialog you kept those labels.

Correct. Since it's a column I'm not sure we can do better. I'm not too thrilled about that UI either but have no easy suggestions.

This is a patch I had to move to a localizable location. Maybe you want to incorporate it?

Or let's hold that, for now.
Let's keep the strings non-localizable for now until they stabilize.

Kai, can you also look at these patches and if you find any problems, can you describe steps to reproduce them?

If you use a single bug for longer, can you please mark patches, which are already done, using some indicator? You could edit the description of the patch and add [checked in] at the end. That would make it easier for me to know which patches are still left undone, and to which patches you're referring to in your request.

Ideally, if you work on changes in these area, you should try the related UI of all affected code yourself, and not depend on me to discover failures. Could you setup OpenPGP for yourself in a test profile and experiment with it?

(In reply to Kai Engert (:KaiE:) from comment #45)

Ideally, if you work on changes in these area, you should try the related UI of all affected code yourself, and not depend on me to discover failures. Could you setup OpenPGP for yourself in a test profile and experiment with it?

Yes, I am doing this. But here we are working with 200 odd strings and all these strings are inserted through Javascript and JSM files. And it's pretty much covering all the functionalities. So it's likely that I can miss a few things and we don't want to break things right now.

Thanks for the feedback, I'm glad you're testing, too.
Can you please say which of the many patches I should apply for testing?

(In reply to Kai Engert (:KaiE:) from comment #47)

Thanks for the feedback, I'm glad you're testing, too.
Can you please say which of the many patches I should apply for testing?

Patch for which I have asked Magnus's review. I have tried it to slipt into multiple patches. There are currently 4 patches. 2 more patches are coming. Name: Bug-1638822_openpgp-fluent-enigmail-properties-part-1-to-part-6.patch

I am going to test them once again tomorrow as now I have converted all the strings. You can look at them after I do the final testing.

tools / openpgp key manager / file / import public
fails with
JavaScript error: resource://gre/modules/Localization.jsm, line 347: Error: Can't use sync formatWithFallback when state is async.
JavaScript error: chrome://openpgp/content/ui/commonWorkflows.js, line 58: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "Can't use sync formatWithFallback when state is async." {file: "resource://gre/modules/Localization.jsm" line: 347}]'[JavaScript Error: "Can't use sync formatWithFallback when state is async." {file: "resource://gre/modules/Localization.jsm" line: 347}]' when calling method: [mozILocalization::formatValueSync]

additional problem:

to reproduce, ensure you have a personal openpgp key configured already.
to check that you have, use tools / openpgp key manager and confirm you have a line that is bold. If you double click it, it should say "type personal key".
If you don't have one yet, use menu generate to create a new one for you

now that you have this prepared, use the following to reproduce the failure:

go to "edit / account settings / end-to-end encryption"
in the "openpgp" section, click button "set personal key".
a dialog will open.

Expected behavior:
the list shows your personal keys

Actual behavior with your patches applied:
the list is empty

I'll stop testing for now. Please let me know once you have these failures fixed, then I can do more testing.

Note that the test results from comment 51 and 52 were done using a comm-beta 78 branch build.

I tried a m-c 79 build, but that doesn't even start up. I get:
JavaScript error: chrome://openpgp/content/modules/trust.jsm, line 15: TypeError: Localization is not a constructor

which prevents loading of the main messenger window.

Needed a rebase. I have checked almost every functionality now. Let's merge these 3 patches first so that it's easy to find the problem. I have checked this on the Trunk.

Checkin needed for Bug-1638822_openpgp-fluent-enigmail-properties-part-1, part-2 and part-3.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/637bcc4f8125
Bug 1638822 - convert openpgp strings to Fluent - keyDetailsDlg.js and enigmail.ftl. r=mkmelin
https://hg.mozilla.org/comm-central/rev/1cab4ddc29b6
Bug 1638822 - convert openpgp strings to Fluent - jsm files. r=mkmelin
https://hg.mozilla.org/comm-central/rev/7db4a57f1718
convert openpgp strings to Fluent - jsm files continue. r=mkmelin

Thanks. I've tested the patches from today on comm-beta, together with the other recent work (partially not yet uplifted to beta), and I haven't noticed any regressions yet.

3 more to go

Please let me land the beta patches, they depend on other patches, and I have them all stacked up correctly. Currently waiting for two more patches to get approved, before I can push them all.

I found two regressions with the commited patches.
(a) openpgp key manager, click a key that never expires. The information after "expiry" is just a question mark "?". I think it was a text previously, or empty, I don't remember.
(b) openpgp key manager, delete a key. The prompt isn't properly formatted, it displays \n instead of line breaks.

(In reply to Kai Engert (:KaiE:) from comment #89)

I found two regressions with the commited patches.
(a) openpgp key manager, click a key that never expires. The information after "expiry" is just a question mark "?". I think it was a text previously, or empty, I don't remember.
(b) openpgp key manager, delete a key. The prompt isn't properly formatted, it displays \n instead of line breaks.

I will look into those and try to submit the patches by end of the day.

(In reply to Magnus Melin [:mkmelin] from comment #88)

these should not really be separate, instead the button element should be
using Fluent, with a label and accesskey as sub properties (or whatever it's
called)

We are using it in appendNotification. We need to pass an array of objects which contains information related to buttons including label and accessKey. So can't do much about it.

(In reply to Kai Engert (:KaiE:) from comment #89)

I found two regressions with the commited patches.
(a) openpgp key manager, click a key that never expires. The information after "expiry" is just a question mark "?". I think it was a text previously, or empty, I don't remember.
(b) openpgp key manager, delete a key. The prompt isn't properly formatted, it displays \n instead of line breaks.

Kai, do you want to have a separate patch for this or I just apend the changes in the last part 6?

(In reply to Khushil Mistry [:khushil324] from comment #92)

Kai, do you want to have a separate patch for this or I just apend the changes in the last part 6?

I assume we intend to uplift all of these patches to TB 78.
If that's correct, then it's ok to include these fixes as part of your new work.

(To clarify, I'd like all openpgp fixes to land for 78. At this time, there is only one reason to exclude patches: If a change is necessary because of platform changes post 78.)

Magnus has reviewed all the part-4, part-5, and part-6. I have updated part 6 with all the changes. Can you final check these changes?

We had two strings with the same key "key-expired" so it was causing problems. Corrected it in this patch.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b5e726d4296e
convert openpgp strings to Fluent - part 4 - jsm files continue. r=mkmelin
https://hg.mozilla.org/comm-central/rev/edee35309f49
convert openpgp strings to Fluent - part 5 - jsm files continue. r=mkmelin
https://hg.mozilla.org/comm-central/rev/06b8793bef23
convert openpgp strings to Fluent - part 6 -jsm files continue. r=mkmelin

Going to have to back out part 5 and 6 for lots of test failures. https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=a55755a0f3fe6e48e615cc6c54edcb8df30fdc9e
E.g. comm/mail/test/browser/smime/browser_multipartAlternative.js and comm/mail/components/extensions/test/browser/browser_ext_composeScripts.js

Backout:
https://hg.mozilla.org/comm-central/rev/02b477b49fc8f6fc35665548f236e109d1aee77e
https://hg.mozilla.org/comm-central/rev/778af58077993f28514c86ef3aa3eeb7b3c92c7f

key-revoked is another duplicate

Khushil, I assume you still have work in progress patches.

Could you please include the following typo fix (from bug 1647104) in your changes?
Thanks

-filter-decrypt-move-warn-experimental = Warning - the filter action "Decrypt permanently" may lead to destroyed messages.\n\nWe strongly recommend that you first try the "Create decrypted Copy" filter, test the result carefully, and only start using this filter once you are satisified with the result.
+filter-decrypt-move-warn-experimental = Warning - the filter action "Decrypt permanently" may lead to destroyed messages.\n\nWe strongly recommend that you first try the "Create decrypted Copy" filter, test the result carefully, and only start using this filter once you are satisfied with the result.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=2f55ba03e52475342c9bf1cb685089f470b03fda

Changes:

--- a/mail/components/compose/content/MsgComposeCommands.js
+++ b/mail/components/compose/content/MsgComposeCommands.js
@@ -56,7 +56,7 @@ var { ExtensionParent } = ChromeUtils.im
"resource://gre/modules/ExtensionParent.jsm"
);

-var l10n = new Localization(
+let l10n = new Localization(
["messenger/messengercompose/messengercompose.ftl"],
true
);

Added solutions to all the regression by the previous patches.

Changes suggested by Kai:

-filter-decrypt-move-warn-experimental = Warning - the filter action "Decrypt permanently" may lead to destroyed messages.\n\nWe strongly recommend that you first try the "Create decrypted Copy" filter, test the result carefully, and only start using this filter once you are satisified with the result.
+filter-decrypt-move-warn-experimental = Warning - the filter action "Decrypt permanently" may lead to destroyed messages.\n\nWe strongly recommend that you first try the "Create decrypted Copy" filter, test the result carefully, and only start using this filter once you are satisfied with the result.

Sure, I will rebase both the patches again.

It's just a small amount of code. Because I know what I changed, it might be easier if I do it. I'll attach updated revisions shortly.

I have done it here: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=3920d0920e9a6abfd7ba8696bfe2ec9ff706ad83
If the tests are good, I will upload these patches.

Khushil, thank you. Your patches look good. Let's use your patches.

(In reply to Kai Engert (:KaiE:) from comment #115)

Your patches look good.

I'm referring to the code conflict that was introduced yesterday. You have merged it well, and I've tested that this particular place works correct.
I haven't done a full review.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=3920d0920e9a6abfd7ba8696bfe2ec9ff706ad83

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=3920d0920e9a6abfd7ba8696bfe2ec9ff706ad83

Composer is broken with the attached patch.
On opening a composer window, I get:
JavaScript error: chrome://messenger/content/messengercompose/MsgComposeCommands.js, line 1: SyntaxError: redeclaration of var l10n

You should completely remove the following variable declaration, which apparently is in conflict with the l10n declaration from mailWidgets.js

(Apprently the JS engine accepted your redeclaration if it was identifical to the earlier one.)

diff --git a/mail/components/compose/content/MsgComposeCommands.js b/mail/components/compose/content/MsgComposeCommands.js
--- a/mail/components/compose/content/MsgComposeCommands.js
+++ b/mail/components/compose/content/MsgComposeCommands.js
@@ -56,7 +56,7 @@ var { ExtensionParent } = ChromeUtils.im
   "resource://gre/modules/ExtensionParent.jsm"
 );
 
-var l10n = new Localization(
+let l10n = new Localization(
   ["messenger/messengercompose/messengercompose.ftl"],
   true
 );

(In reply to Kai Engert (:KaiE:) from comment #119)

Composer is broken with the attached patch.
On opening a composer window, I get:
JavaScript error: chrome://messenger/content/messengercompose/MsgComposeCommands.js, line 1: SyntaxError: redeclaration of var l10n

You should completely remove the following variable declaration, which apparently is in conflict with the l10n declaration from mailWidgets.js

(Apprently the JS engine accepted your redeclaration if it was identifical to the earlier one.)

I am renaming the variable to l10nCompose in the MsgComposeCommands.js file so it will not create any confusion/overriding.

I am not sure how the patches here landed and modified the test behavior.
But can someone look at the warnings reported in
bug 1649019 ?
JavaScript Warning: "[fluent-dom] While translating an element with fluent ID "openpgp-search-signature-key" a child element of type "label" was removed. Either the fluent message does not contain markup, or it does not contain markup of this type."

TIA

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=ede9c123ca3098439883c4e4e3fc146b3dff7b50&selectedTaskRun=Q04uJiA5QzqIMuy6lYPcPQ.0

Included changes for bug 1649019 also so that we don't need to submit multiple beta patches.

We should uplift the last patches to 78.x
Sounds like the work for beta 78 is done, and trees are currently being merged.
I conclude the new uplift target is comm-esr78.

Thunderbird 78.0.0 (build2):
https://hg.mozilla.org/releases/comm-esr78/rev/44042a27cba7
https://hg.mozilla.org/releases/comm-esr78/rev/a639ba4a6446

We should remember to move the Fluent files to localization before next merge day so we get localizations going for the 78.2.

Move strings to localization. (Renamed a few files at the same time, and fixed a couple of ellipsis.)

it seems you deleted file key-wizard.ftl

Don't know what happened to that. It was supposed to be adjusted to keyWizard.ftl (matching the file it's used in)

Thanks. I'm briefly re-building esr78 (mostly from cache) and will doublecheck that it still works.

You missed this part.

r=kaie if you merge this into your patch

Well if you r+ mine we can commit both, and don't need a new patch.

But if you want to combine it, fine, too.

Will fold, thx.

We need this on the esr78 branch, right?

Now or later?

Yes needed for esr, but no need to land it for 78 just yet. It does need to be uplifted there before 78.2.

(All done)

Thunderbird 78.1.1:
https://hg.mozilla.org/releases/comm-esr78/rev/4a8cf3c3de4e