1823084 - Migrate strings from "Junk" to "Spam"

Status: RESOLVED FIXED

(Thunderbird :: L10n, task, P3)

Description

[Alessandro Castellani [:aleca]]

We should stop using "Junk" to indicate "Spam" messages for en_US locales.
Almost all other email providers use "Spam", and we're currently using these two terms interchangeably without much consistency.

Bonus reason: "Junk" is also used as vulgar male slang sometimes.

Comment 1

[Corey Bryant]

I just came across this and it's pretty confusing. Right click a message -> Mark -> As (Not) Junk

There are a lot of hits (1667) for "Junk" in comm-central, not all strings of course.

Comment 2

[Alessandro Castellani [:aleca]]

I'll take care of this

Comment 3

[Alessandro Castellani [:aleca]]

We got a total of:

• 31 fluent strings ✅
• 43 DTD strings ✅
• 39 properties strings

I'll do them in chunks so their easier to review.

Comment 4

[Alessandro Castellani [:aleca]]

Attachment: Bug 1823084 - Update strings from Junk to Spam. r=#thunderbird-reviewers

"Junk" is sometimes used as a derogatory term, and more recently
Spam is more commonly used in email software and services.

This is primarily an English problem, therefore a fluent migration is
needed to ensure that we don't force translators to needlessly update
strings that are still valid in other locales.

• Replace Junk with Spam only for fluent strings.
• Add a fluent migration to maintain the strings for all other locales.

Comment 5

[Alessandro Castellani [:aleca]]

Attachment: Bug 1823084 - Migrate Junk dtd strings to fluent. r=#thunderbird-reviewers,coreycb!

Comment 6

[Anje]

Recently - last update - all imap accounts stopped using Spam as folder name in Folder Pane but it's still used in per Properties and profile mail account and webmail. They suddenly display 'Junk' which is wrong and confusing. see bug 1979511
That bug has been set as a wontfix because apparently this bug is fixing it.
But is that correct?
It just seems odd that all imap accounts which were already using Spam, but got altered to Junk when this is explicitly the opposite direction Thunderbird seems to be moving towards.

Alessandro - Will this bug fix bug 1979511 ?

Comment 7

[Alessandro Castellani [:aleca]]

Yes, apologies for the delay, I'm tackling this change so the English localization is correct.
I'll try to prioritize this and get it done soon.
Sorry for the annoying inconsistencies

Comment 8

[Alessandro Castellani [:aleca]]

Attachment: Bug 1823084 - Migrate Junk properties strings to fluent. r=#thunderbird-back-end-reviewers,#thunderbird-front-end-reviewers

Comment 9

[Ben Campbell]

Attachment: Bug 1823084 - Migrate Junk properties strings to fluent. r=#thunderbird-back-end-reviewers,coreycb!

Comment 10

[Yogesh]

Can I ask if other locales - specifically en_GB and en_IN also have this change enabled?

Comment 11

[Yury]

Can you please remove the use of ToNewUnicode(). This is not correct.

If you want to assign an UTF-8 string (nsCString) to an UTF-16 (nsString), please use, for example:

nsString actionValue;
nsAutoCString filterActionSpam;
...
actionValue = NS_ConvertUTF8toUTF16(filterActionSpam);
// or
actionValue.Assign(NS_ConvertUTF8toUTF16(filterActionSpam));

ToNewUnicode() is used where the raw string pointer is needed, for example:
https://searchfox.org/comm-central/rev/59e54529a5756a6bd53654461c5ebf2bd8cd1c77/mailnews/extensions/mailviews/nsMsgMailViewList.cpp#32-37

Comment 12

[Alessandro Castellani [:aleca]]

Thanks for the ping.
Please, feel free to leave comments and suggestions directly on Phabricator if you have more

Comment 13

[Yury]

Thanks for the adjustments. OK, will do so in the future (although I seem to remember that at some stage I wasn't able to add Phab comments). I just had a cursory look at the patches and noticed the string processing. Check my BMO profile for all the correctness fixes I've contributed. Nice job to get this bug straightened out, BTW.

Comment 14

[John Bieling]

I think I see test fails related to this patch in my try.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=10e8060efc04fbb0ccf6a8e8863fc61354e24c90

Could you create a dedicated try for this stack?

Comment 15

[Alessandro Castellani [:aleca]]

I did have a try run: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=bcb497d5e418f78811ff1680d50f1d39ffdcf112

I thought I had checked that all those failures were per-existing.
Are you referring to the browser_folderPaneContext failure? I tried running that test locally with and without my stack and it fails all the times.

Let me know if I'm missing something.

Comment 16

[Alessandro Castellani [:aleca]]

Removing check-in due to test failures

Comment 17

[Anje]

In beta 143.0b3
I'm also seeing my gmail trash folder is now called 'Deleted' and it should be called 'Bin' as per server name.
So this issue is effecting both the 'Spam' and 'Bin' folders on imap incorrectly named 'Junk' and 'Deleted'

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d71d091c9678
Update strings from Junk to Spam. r=mkmelin
https://hg.mozilla.org/comm-central/rev/4a4e5f0e4163
Migrate Junk dtd strings to fluent. r=mkmelin,coreycb!
https://hg.mozilla.org/comm-central/rev/3712c9482741
Migrate Junk properties strings to fluent. r=BenC,arschmitz,mkmelin,tobyp

Comment 19

[John Bieling]

I am sorry, I have to back this out again. The X5 fail is also caused by this stack. It was present in the original try, my own try and also aleca's latest try:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&author=alessandro%40thunderbird.net&selectedTaskRun=UYZ24_60Q7mpUQlQIEVrpw.0

Comment 20

[John Bieling]

Backout is somewhat tricky. I filed Bug 1987900 as a regression.

Comment 21

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/comm-central/rev/0c5725005363
Backed out changeset d71d091c9678 for causing test fails. r=backout
https://hg.mozilla.org/comm-central/rev/44eb57e92512
Backed out changeset 4a4e5f0e4163 for causing test fails. r=backout
https://hg.mozilla.org/comm-central/rev/246588cf31a9
Backed out changeset 3712c9482741 for causing test fails. r=backout

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b9e251eb29a6
Update strings from Junk to Spam. r=mkmelin
https://hg.mozilla.org/comm-central/rev/124f2987ba3c
Migrate Junk dtd strings to fluent. r=coreycb,mkmelin
https://hg.mozilla.org/comm-central/rev/68750fe7f836
Migrate Junk properties strings to fluent. r=BenC,arschmitz,john.bieling,mkmelin

Comment 23

[[e-mail]]

(In reply to Yury from comment #11)

Can you please remove the use of ToNewUnicode(). This is not correct.

Agreed.

If you want to assign an UTF-8 string (nsCString) to an UTF-16 (nsString), please use, for example:

nsString actionValue;
nsAutoCString filterActionSpam;
...
actionValue = NS_ConvertUTF8toUTF16(filterActionSpam);
// or
actionValue.Assign(NS_ConvertUTF8toUTF16(filterActionSpam));

Better still, CopyUTF8toUTF16(filterActionSpam, actionValue);

Comment 24

[Yury]

You're a little late to the party, since this was landed:
https://hg-edge.mozilla.org/comm-central/rev/3712c9482741#l30.44
then backed out and landed again, this time, incorrectly:
https://hg-edge.mozilla.org/comm-central/rev/68750fe7f836#l32.44

A little worrying that what was committed the second time differs from what was first landed.

And then bug 1994890 reinstated the original version:
https://hg-edge.mozilla.org/comm-central/rev/2f0a21eb272e#l6.13

Comment 25

[Yury]

I'll address comment 23 in bug 1999335.