Multi language Email issues

[luisramos0]

Follow up from openfoodfoundation/openfoodnetwork#3189, there are currently 6 different issues with multi language emails, this epic represents those issues. When the work is started, we can create individual issues. Some solutions are still not defined, here's a summary of my analysis:

This wiki page summaries all emails: https://github.com/openfoodfoundation/openfoodnetwork/wiki/Emails

1. Forgotten password email (case 3 in the wiki)

The email is always sent in English.
This is done in devise (a dependency of spree).
Additionally, the email itself is not styled, so we may also need to redo the email template.

2. Order shipped email (case 7 in the wiki)

The email is always sent in English.
This is done in spree.
Additionally, the email itself is not styled, so we may also need to redo the email template).
To replicate this one you need to go to the bulk order management page and before you see the ship button you need to capture payment.

3. Enterprise manager (new account) invitation email and sign up email (case 11.1 and 11.2 in the wiki)

There's no way to know whats the new user locale, the best option here is to user current user locale.

4. Subscription confirmation email
I (case 13 in the wiki) and then all subs emails (case 14-20)

When creating a subscription for a new customer there's no way of knowing the customer locale. Again, the best option is to use the current user locale. I am not sure but in this case, I think there will be no user created so there will be no place to store the locale.

5. Order created in the backoffice (not described in wiki)

Same as in subscriptions, when we create an order in the backoffice for a new customer that has never logged in, there's no way to know what the user locale is. Best option is to use current user locale. I am not sure a user record is created in this case...

6. GUEST user checkout emails


Guest user is not registered in the DB so there is no place to store the user locale (I thought of using the session locale but the email is sent on delayedJob which is a different process without access to the session locale).
@maikel commented: “I think the clearest way to use Delayed Job is to create custom jobs for whatever we want to delay. These jobs can store the current locale of the guest and use it for sending the email.“


In these 3 last cases of 1. guest user checkout, 2. order created in the backoffice and 3. subscriptions with new customer, the same problem applies to all order emails (resend confirmation in the backoffice, order cancelation, invoice, etc). All these emails need to be in the user locale, but in some cases, there is no user record to store the locale. This needs to be investigated.

Issue list

• [Emails->Signup] Send user signup email (with confirmation link) in user's language, not in default language #469
• [Emails->Signup] Send user welcome email (after clicking confirmation link) in user's language, not in default language  #470
• [Emails->Signup] Clicking the link in the confirmation email should open the website in the user's language #471

[luisramos0]

openfoodfoundation/openfoodnetwork#3043 was an s3. I keep this one in s3. Specially for the first two cases where "forgot password" and "order shipped" emails are still being sent in English :-/

[luisramos0]

point 2 here has been addressed in openfoodfoundation/openfoodnetwork#5763 ✔️
all the other points are still open I think 👍

[RachL]

@luisramos0 @sauloperez is point one doable now? Or do we still rely on devise?

[luisramos0]

The email is in devise but it was always doable, we just need to override it on our side.
I am not sure what is the method but probably we just need to implement this password_change method on our user_mailer. Should be an easy one.

BTW, most of these are easy, we could break this epic in smaller issues and tag then good-first-issues.

[RachL]

Ok issue created here : openfoodfoundation/openfoodnetwork#6007

@luisramos0 @sauloperez I'm unsure how to reproduce the other cases:

• Enterprise manager (new account) invitation email and sign up email (case 10.1 and 10.2 in the wiki) - it seems to work for me

• Subscription confirmation email
I (case 12 in the wiki) and then all subs emails (case 13-17)

• Order created in the backoffice (not described in wiki)

• Guest checkout

Is it correct I need to try those for a user that is in a different locale than me? I'm guessing this needs a redesign on how we are assigning a locale to a user?

[luisramos0]

The user locale is the last locale the user was on on their lastest logged in session. I think we are fine here.

• 10.1 - "it worked" do you mean it used the locale of the inviting user? did it send in Italian on FR live for example? if that was so, maybe this is not a problem.
• subs - login with subs customer and change locale to Italian (to verify locale you need to open icognito tab, see it's the instance default language, login with that user, and see the locale automatically change to the user locale. This is why it is better to test with a language that is not the instance default). Then, use your FR user and setup Subscription for the customer. Subs emails to the customer should go in Italian. I think they will be sent in FR right now. Actually, maybe better to have the manager use another language than FR (like English in FR live) so you can differentiate between "manager locale" and "instance default locale".
• same as above for the customer, make it Italian in FR live. Make the manager locale English. Then create an order in the backoffice for that customer. Order confirmation to customer should go in Italian. Order confirmation to hub should go in English. Are they both going in FR right now? I dont know.
• Change language of your "not logged in session" to Italian and checkout as guest. Confirmation email should go in Italian.

Let me know if this is useful or if you have any questions.