Don't send welcome emails to users if there is no translation available in that user's primary language

RESOLVED FIXED

Status

developer.mozilla.org
Sign-in
--
blocker
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mars, Assigned: groovecoder)

Tracking

Details

(Reporter)

Description

4 years ago
From bug 775485 comment 20: we should should only send welcome emails to users if there is a translation of the welcome mail into the user's primarly langauage.  Otherwise we'll just be spamming them.
How do we define the user's primarly language?
Flags: needinfo?(mars)
(Reporter)

Comment 2

4 years ago
Punt
Flags: needinfo?(mars) → needinfo?(lcrouch)
I planned to use the Accept-Language request header when they registered. It's the same logic we use for automatic language detection when viewing the site.

:hoosteno, can you help us make the call here?
Flags: needinfo?(lcrouch) → needinfo?(hoosteeno)
Keywords: productwanted
Whiteboard: [pm-wanted]
(Reporter)

Comment 4

4 years ago
We've already decided to build this feature, so no need for the productwanted flag :)
Keywords: productwanted
Whiteboard: [pm-wanted]
1) I do agree that we should not send welcome emails in languages we have no reason to think the recipient speaks. If we don't have a welcome email in the language we guess that they speak, we should not send one.

2) I do agree that we should try to guess a user's language and we should use that guess for the welcome email (assuming #1). I think the locale in the URL is more accurate than the one in the header; in many cases they are identical, but when they're not it's because the user has used the dropdown on the page to change the locale. In this instance the header is wrong.

3) I think we could go so far as to save that locale in the profile so it's available for future uses. Right now if your browser is set to fr, and you sign up, we put "English" in your profile setting under Langue. The guesses coming out of the above will be better in a great majority of cases than defaulting to "English", so let's put them there instead.
After talking with some folks, I think #3 above is creeping scope. The scope here is really clear: Let's unblock welcome emails by

a) not sending them if we don't have one in the appropriate language and
b) guessing at the appropriate language based on request content

If b) includes some storage requirement, let's not mix it up with "preferred language" on the profile just yet.
Flags: needinfo?(hoosteeno)
Note: The email copy is sliced up into sentences & paragraphs as we put dynamic variables and content into it. 

So, we can't be 100% sure that 100% of email is translated. I'm writing the code to spot check multiple strings in the email before sending though, so we can be reasonably sure it's translated.

Comment 9

4 years ago
Commits pushed to persona-allauth at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/9cf4d155cbeced14ceded388fe25237ae7905ac8
fix bug 1029071 - send translated welcome emails

use pofile to check for translated strings

tests for default, translated, and untranslated

add trans blocks to HTML email

https://github.com/mozilla/kuma/commit/2e9b3b5e528464e565f6041ce3020f4ee3476bdf
Merge pull request #2569 from groovecoder/allauth-welcome-emails-1029071

fix bug 1029071 - translated welcome emails

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 10

4 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/9cf4d155cbeced14ceded388fe25237ae7905ac8
fix bug 1029071 - send translated welcome emails

https://github.com/mozilla/kuma/commit/2e9b3b5e528464e565f6041ce3020f4ee3476bdf
Merge pull request #2569 from groovecoder/allauth-welcome-emails-1029071
You need to log in before you can comment on or make changes to this bug.