1710825 - Improve wording of public bulk mail notification string (style/logic)

Status: RESOLVED FIXED

(Thunderbird :: General, task)

Description

[Thomas D. (:thomas8)]

Attachment: Screenshot: current oddly-phrased notification

STR

1. compose with 15 recipients in To and CC to trigger public bulk mail notification
2. look at the wording of the first sentence of the notification

Actual

The 15 recipients in To and Cc can see the address of each other. You can avoid disclosing recipients by using Bcc instead.

There's something wrong with the language style and logic in the current bulk mail notification:

• "of" is typically used with things, so it's odd to use it with people.
• using "address" (instead of "addresses") feels logically wrong and unnecessarily playing down the real-world effect this will have. Even if there are only two people, they will see each other's addresses (not address), more so with 3+ people. Grammar of good authority corroborates this:

  Lisa and Kate hated each other’s husbands. (Lisa hated Kate’s husband and Kate hated Lisa’s husband.)
  https://dictionary.cambridge.org/grammar/british-grammar/each-other-one-another

• "can" (present tense) is also not quite correct, as at the present time of composing, recipients cannot see each other's addresses yet. If the message gets sent, they will...

Expected

Let's improve the wording like this:

The 15 recipients in To and Cc will see each other's addresses. You can avoid disclosing recipients by using Bcc instead.

We also want this for translations, so I've updated the l10n-id to be in sync with related IDs.

Comment 1

[Thomas D. (:thomas8)]

Attachment: 1710825_publicBulkRecipientsNotificationString.diff

This changes the string per comment 0.

many-public-recipients-info = The {$count} recipients in To and Cc will see each other's addresses. You can avoid disclosing recipients by using Bcc instead.

We also want this for translations, so I've updated the l10n-id to be in sync with related IDs (many-public-recipients-bcc, many-public-recipients-ignore).

Comment 2

[Thomas D. (:thomas8)]

Attachment: Screenshot with improved string (patch of attachment 9221558).

Comment 3

[Lasana Murray]

Comment on attachment 9221558 [details] [diff] [review]
1710825_publicBulkRecipientsNotificationString.diff

Review of attachment 9221558 [details] [diff] [review]:
-----------------------------------------------------------------

Sure!

Comment 4

[Thomas D. (:thomas8)]

Thanks Lasana!

Comment 5

[Magnus Melin [:mkmelin]]

Comment on attachment 9221558 [details] [diff] [review]
1710825_publicBulkRecipientsNotificationString.diff

Review of attachment 9221558 [details] [diff] [review]:
-----------------------------------------------------------------

It is actually singular address, I think. Using plural makes it sound like all (other) potential addresses would be visible.
Singular form "each other's address" has 4 times more hits on google as well.

Please note: Review procedure is that a peer or owner should be involved in the review flow.

Comment 6

[Thomas D. (:thomas8)]

Attachment: 1710825_publicBulkRecipientsNotificationString.diff

Alright, no problem! I've changed it back to singular which is certainly good:
The {$count} recipients in To and Cc will see each other's address. ...

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

Review of attachment 9221558 [details] [diff] [review] ⧉[details] [diff] [review]:
It is actually singular address, I think. Using plural makes it sound like
all (other) potential addresses would be visible.

Yeah, I hear you. Sort of... maybe. Seems that it works both ways (singular or plural), and plural is getting more common and also considered correct [1][2].

Singular form "each other's address" has 4 times more hits on google as well.

True, but at the same time, "each other's faces" (with quotes) has more than twice as many hits on google over "each other's face", so apparently using the plural does not imply that everyone has more than one face...

[1] https://jakubmarian.com/each-others-vs-each-others-in-english/
[2] https://dictionary.cambridge.org/grammar/british-grammar/each-other-one-another

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fc57dfa5d1b6
Improve wording of public bulk mail notification string. r=lasana,mkmelin

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d32912fff6e3
followup to fix fluent apostrophs. rs=fluent-lint DONTBUILD

Comment 9

[Thomas D. (:thomas8)]

(In reply to Pulsebot from comment #8)

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d32912fff6e3
followup to fix fluent apostrophs. rs=fluent-lint DONTBUILD

Thanks!

Comment 10

[Thomas D. (:thomas8)]

Fwiw, TB 78 is probably wontfix, but not unaffected as it does have the original typo (inconsequential):
https://hg.mozilla.org/releases/comm-release/file/9921e1929e744e2f5e64163f036c215f2960fc1f/mail/components/compose/content/MsgComposeCommands.js#l4137
function udpateAddressingInputAriaLabel(row) {

Comment 11

[Thomas D. (:thomas8)]

Sorry, my comment 10 ended up on the wrong bug, was meant for bug 1711270.