Localized email templates not being used during self-service registration

[glen-84]

Localized email templates not being used during self-service registration

Description

This is a critical issue for us. Despite a locale cookie being set, neither the locale nor preferredLanguages are part of the form, and localized email templates are therefore not used. Am I missing something here? What determines which localized templates to use?

I tried adding:

[@helpers.hidden name="locale" value="vi" /]
[@helpers.hidden name="user.preferredLanguages" value="vi" /]

... to the form, but it doesn't seem to help.

Affects versions

1.36.4

Steps to reproduce

Steps to reproduce the behavior:

1. Add localized email templates.
2. Register from a page with the locale set to a locale matching one of the localized email templates.
3. Receive a verification email in the default language instead of the localized language.

Expected behavior

I expect the localized templates to be used based on the locale cookie. I also expect to be able to set user.preferredLanguages via the registration form, or have these automatically set based on the locale, so that subsequent emails are also sent with the correct language.

Screenshots

n/a

Platform

(Please complete the following information)

• Device: Desktop
• OS: Windows 11
• Browser + version: Chrome 102
• Database: PostgreSQL 12.9

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

Additional context

Our integration is up on staging and is supposed to go live soon. I hope that I'm just missing something obvious here, otherwise this is a big problem.

Possibly related to: #1693, #1713.

You can work around this using advanced registration forms: #1738 (comment)

Note that even if admins have localized the theme and a user selects a different language during the registration process using the locale picker, they do not receive the localized email.

Documentation

• Change to basic registration API
• Review any existing registration guides (talk to Dan)
  • https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms
  • https://fusionauth.io/docs/v1/tech/guides/basic-registration-forms
• Review core concepts screen shots for needed updates
• Add Preferred languages to Application Registration Configuration fusionauth-site#1949

[mooreds]

If you set preferredLanguages using the admin UI, are emails sent using the correct locale?

[glen-84]

Yes, I tested that.

It wouldn't help as a workaround though, because of the same issue impacting #1580 (the email is sent before the transaction is complete, so there's no opportunity to set the lang pref before that).

Are you able to reproduce both issues?:

• Locale cookie not used for localized template selection.
• Not possible to send user.preferredLanguages during registration.

Unless I'm making a mistake somewhere, this means that it's not possible to send localized email verification emails. This is bad.

[mooreds]

Hi @glen-84

The issue is that you are using the free basic registration. A limited number of parameters are allowed for basic registration, and the user's locale is not one of them, unfortunately.

You can use advanced registration and build a form that allows the user to choose user.preferredLanguages from a list (or set it using Javascript from a cookie if you'd prefer). When I did that, I was able to get a localized email verification email upon registration.

Here's what the registration form looked like with the user.preferredLanguages field included:

Please note that you must purchase a license for the advanced registration functionality; the Starter plan will suffice. https://fusionauth.io/pricing has more information.

I'm happy to leave this open as long as we rename the issue to 'user.preferredLanguages not set by locale cookie'. Would that suit?

[glen-84]

@mooreds

I really can't accept that. I've spent weeks integrating FusionAuth, including writing a 600 line Kickstart file*, a custom theme, and all of the token management features that I expected to be part of the SDKs. We've also shelled out additional dollars for a staging deployment due to the defective web hook system.

Email localization is listed as a feature of the Community version:

And this formed part of our overall decision to go with FusionAuth, including cloud hosting at $325/month.

We have 2-3 localizations of our site and we need the emails to be localized as well (both at registration and later by using a stored locale or preferred language).

I really like the product, despite a few of these non-trivial issues, but if we'll be forced into upgrading due to a feature that is clearly listed as being included, then I'll no longer be able to recommend your service, and we'll have to think about less costly alternatives in the future (we're a small company).

I am very disappointed to hear of this.

_{* Feedback}

[mooreds]

Hi @glen-84

I hear and understand your frustration. I'd love to be able to fix and implement all the enhancements and issues that people file, but we unfortunately have limited staff and a lot of projects that need to be done.

I understand the workaround of paying for a starter license is unappealing.

We can leave this issue open and it is possible we'll add locale support to basic self-service registration. It is also possible that I've made a mistake in my testing and there is a way to set the locale without advanced registration forms (though given the efforts both of us have made, I think it unlikely).

I'll update the title of the issue and leave it open.

we'll have to think about less costly alternatives in the future (we're a small company).

We'd love for everyone to use FusionAuth, but we understand that there may be features or issues that mean it's not a fit for every situation.

I truly appreciate all your feedback, issue filing and useful comments, but if at the end of the day FusionAuth doesn't work for you, it doesn't work for you.

[glen-84]

@robotdan

Can you please confirm whether or not this is a bug, so that we're able to make a more informed decision on how to proceed?

The website clearly states that email localization is supported in the Community edition. It's a bit pointless being able to create localized email templates if verification emails always use the default language?

[robotdan]

Dan is correct in that you can't set user.preferredLanguages in a hidden field when using basic self-service registration, it will be ignored. This capability would be limited to the advanced registration forms which requires a paid edition of FusionAuth.

I think you're question is, if you set the locale on the themed paged using the selector should it be utilized to send localized emails during a self-service registration flow. My initial thought is no, that locale selector was initially only added to allow themes to be more easily localized by the end user.

However it isn't a bad idea to try and preserve that value for sending emails during this workflow, or it may not even hurt to just create the user with that preferred locale. But the current intent of the selector on the themed page for locale is just to modify the localization of the page itself.

The website clearly states that email localization is supported in the Community edition. It's a bit pointless being able to create localized email templates if verification emails always use the default language?

Email localization is for sure included in all versions of FusionAuth, this is not a paid feature. I don't know that I'd say it makes localized email templates pointless, but for this specific case yes - I can see why it is not helpful for you.

I can think of a few options:

1. If the locale is set via the selector which drops a cookie, FusionAuth sets the user's preferred locale during self-service registration using this value if not defined.
2. We add user.preferredLanguages as an option on the basic self-service registration configuration.

Maybe it makes sense to do both. @mooreds or @glen-84 thoughts?

[glen-84]

Thanks for your reply, Dan.

We set the cookie based on the query string depending on which localized website a user came from (.in.th, .vn etc.), but it's essentially the same as selecting one via the selector.

The difference between the locales and preferred languages is a bit subtle, but I can see how keeping them separate may make sense – f.e. just because someone registers on an English site doesn't mean that that is necessarily their preferred language ... I suppose.

Using an explicit locale selection to populate a hidden preferredLanguages field might make sense, as in that case a user would at least be involved in the decision to some extent.

Allowing user.preferredLanguages during basic self-service registration may be the easiest/cleanest solution. I didn't really see it as an advanced feature since it's neither a custom field (similar to username) nor does it facilitate multi-step forms or other advanced features, and it would enable this basic use case of sending the verification email using the correct locale.

---

If you have a rough idea of when this might be added, it would really help us to plan our release. For example:

"In the new few days" -> We'd probably wait for it.
"In 1-2 months" -> I might consider paying for a temporary upgrade with my salary until it is added.
"2+ months or no idea" -> We'd probably have to come up with an entirely new solution. 🙂

[robotdan]

Hard to say on the timeline.. this probably isn't a big lift but we have several larger projects in flight that are consuming most of our engineering resources at the moment.

I would guess 2+ to get it into plan officially.. but a small feature such as this is more likely to get slid into an existing feature branch. So it is possible it could be sooner if we find a bit of slack in our current projects.

I didn't really see it as an advanced feature since it's neither a custom field (similar to username) nor does it facilitate multi-step forms or other advanced features, and it would enable this basic use case of sending the verification email using the correct locale.

I agree. This wasn't left out intentionally in the sense that it is "advanced", but the current basic self-service option is essentially just the older way of doing self-service registration, and when we built "advanced" with a form builder we just left the existing code as is and kept it in the community version.

W/out looking at the code in detail yet - I would lean towards adding user.preferredLanguages to the basic self-service registration feature and leave the theme locale selector as is.

[glen-84]

Is it a large task to add this one field to basic self-service registration?

We're having to send non-translated emails in production due to this issue.

It's been pushed back 7 minor versions already. I provided a lot of feedback, and all I'm asking for is for this one issue to be prioritized a bit.

[spwitt]

Internal

• https://github.com/FusionAuth/fusionauth-app/pull/215
• add preferredLanguages to ApplicationRegistrationConfiguration fusionauth-client-builder#65
• Add preferredLanguages Localization Key fusionauth-localization#59

[mooreds]

Thanks for your patience and feedback @glen-84 ! I'm going to be glad to see this feature released in 1.44.

[mooreds]

Is this going to make it into 1.46.0?

[geoalexidis]

Hello,

This doesn't look like a lot work left to be done. What are you guys waiting for?

We're facing the same issue. It has been over a year since this issue was created.

Thanks and BR

[mooreds]

Thanks @geoalexidis, appreciate the feedback.

We're hoping to get this into the next release. We've had other priorities, unfortunately. I'm sure you understand that we have a lot of requests from both the community and customers as well as internal work and can't fulfill all of them as quickly as we'd like.

[elliotdickison]

Hi all, I'm on 1.47.1 and I'm adding [@helpers.hidden name="user.preferredLanguages" value="pt_BR" /] to the template for my registration form. I can confirm that the "user.preferredLanguages" field is being submitted with the rest of the form when a user registers, but the user's preferred language is still not being set. I'm using basic forms for simplicity even though I'm a paid user.

[elliotdickison]

Turns out I just needed to enable the "Preferred languages" registration field for the app first.