Default to auto-detected language in user registration email. #129

Merged

yrammos merged 1 commit from autodetect-registrant-language into master

2020-06-12 03:18:36 +02:00

yrammos commented

2020-06-11 20:56:27 +02:00

(Migrated from github.com)

The email address confirmation button in the user registration form currently defaults to config.languages[0].

With this PR, new users will be proposed to receive their confirmation email in the language of the UI, typically as autodetected by i18next-browser-languageDetector. (To be sure, I am also keeping config.languages[0] as a fallback, although I cannot imagine any conditions under which it would be useful; please feel free to trim if/as necessary.)

The user remains free to select an alternative email language. That said, I wouldn't be against the removal of button altogether. Isn't it safe to assume that the UI language applies to emails, as well?

Thanks!

PS: Side-question: Do I understand correctly that a lang field is attached to each user in the database? If so, when is it set and updated?

The email address confirmation button in the user registration form currently defaults to `config.languages[0]`. With this PR, new users will be proposed to receive their confirmation email in the language of the UI, typically as autodetected by `i18next-browser-languageDetector`. (To be sure, I am also keeping `config.languages[0]` as a fallback, although I cannot imagine any conditions under which it would be useful; please feel free to trim if/as necessary.) The user remains free to select an alternative email language. That said, I wouldn't be against the removal of button altogether. Isn't it safe to assume that the UI language applies to emails, as well? Thanks! PS: Side-question: Do I understand correctly that a `lang` field is attached to each user in the database? If so, when is it set and updated?

babelouest commented

2020-06-11 22:03:58 +02:00

(Migrated from github.com)

Thanks for the PR @yrammos ,

To answer your questions, why there is a select available for the lang is because UI lang are for now limited, but an admin can add 50 different langs in the e-mail if she/he can.

For example, a chinese user can navigate in English if but wants the e-mail in mandarin if the language is available in the e-mails.

On the opposite, if there are more langs available in the UI than in the e-mails, or different sets, this must be addressed to avoid UI bugs.

For example the UI langs are en, fr, nl, the user navigates in nl, but the langs available in the e-mail are en, fr, ru, your PR would select an unavailable language. In the end the user would receive an e-mail with the default language but the UI may be buggy. This is easily fixable by checking that the current UI language is available in the e-mail languages though.

In the registration plugin, the user isn't created yet, so there is no lang property attached yet. But in the e-mail code scheme, the lang property must be set

Thanks for the PR @yrammos , To answer your questions, why there is a select available for the lang is because UI lang are for now limited, but an admin can add 50 different langs in the e-mail if she/he can. - For example, a chinese user can navigate in English if but wants the e-mail in mandarin if the language is available in the e-mails. On the opposite, if there are more langs available in the UI than in the e-mails, or different sets, this must be addressed to avoid UI bugs. - For example the UI langs are `en`, `fr`, `nl`, the user navigates in `nl`, but the langs available in the e-mail are `en`, `fr`, `ru`, your PR would select an unavailable language. In the end the user would receive an e-mail with the default language but the UI may be buggy. This is easily fixable by checking that the current UI language is available in the e-mail languages though. In the registration plugin, the user isn't created yet, so there is no `lang` property attached yet. But in the e-mail code scheme, the `lang` property [must be set](https://github.com/babelouest/glewlwyd/blob/master/docs/EMAIL.md#user-lang-property)

👍 1

yrammos commented

2020-06-12 01:17:14 +02:00

(Migrated from github.com)

@babelouest my PR may have been premature. A more robust solution would be to:

Rename "default lang" to "fallback lang" for emails.
Require that "fallback lang" be one of the languages in the config.languages list (otherwise disable the checkbox for that language).
Do not instantiate the user registration plugin unless a fallback language is defined for it.
In the user registration form, attempt to instantiate the email language to that of the UI; if no email template exists for the UI language, use the "fallback lang" from above.

If this sounds good to you I can try to revise and resubmit.

@babelouest my PR may have been premature. A more robust solution would be to: 1. Rename "default lang" to "fallback lang" for emails. 2. Require that "fallback lang" be one of the languages in the `config.languages` list (otherwise disable the checkbox for that language). 3. Do not instantiate the user registration plugin unless a fallback language is defined for it. 4. In the user registration form, attempt to instantiate the email language to that of the UI; if no email template exists for the UI language, use the "fallback lang" from above. If this sounds good to you I can try to revise and resubmit.

babelouest commented

2020-06-12 02:20:46 +02:00

(Migrated from github.com)

Rename "default lang" to "fallback lang" for emails.

That can be done, although the meaning is similar

Require that "fallback lang" be one of the languages in the config.languages list (otherwise disable the checkbox for that language).

I think that's overkill, if the admin wants to provide multiple e-mail languages, she/he must provide the translation of the full application in those languages first, otherwise they can't add the language in the list.
My experience is that lots of non-english speaking users are familiar with english forms, it's easy to understand the meaning of Name, E-mail and Password so they can fill the form, but if they can have the confirmation e-mail in their own language, that's an easy nice-to-have.

Do not instantiate the user registration plugin unless a fallback language is defined for it.

That's already the case, you must enter at least one e-mail content and you have to have one default language in the e-mail content list. Although the e-mail langs don't have to be UI languages if the admin doesn't want to.

In the user registration form, attempt to instantiate the email language to that of the UI; if no email template exists for the UI language, use the "fallback lang" from above.

That more or less what I intend to do.
When you arrive in the registration page, the send registration e-mail is already present with the e-mail lang dropdown, after that, the user can change the UI lang. If so, the e-mail lang will be changed for the lang selected, unless the lang is unavailable for the e-mail, in that case the selected e-mail lang will be the default one.
And of course, the user can manually select the e-mail lang.

> 1. Rename "default lang" to "fallback lang" for emails. That can be done, although the meaning is similar > 2. Require that "fallback lang" be one of the languages in the config.languages list (otherwise disable the checkbox for that language). I think that's overkill, if the admin wants to provide multiple e-mail languages, she/he must provide the translation of the full application in those languages first, otherwise they can't add the language in the list. My experience is that lots of non-english speaking users are familiar with english forms, it's easy to understand the meaning of `Name`, `E-mail` and `Password` so they can fill the form, but if they can have the confirmation e-mail in their own language, that's an easy nice-to-have. > 3. Do not instantiate the user registration plugin unless a fallback language is defined for it. That's already the case, you must enter at least one e-mail content and you have to have one default language in the e-mail content list. Although the e-mail langs don't have to be UI languages if the admin doesn't want to. > 4. In the user registration form, attempt to instantiate the email language to that of the UI; if no email template exists for the UI language, use the "fallback lang" from above. That more or less what I intend to do. When you arrive in the registration page, the `send registration` e-mail is already present with the e-mail lang dropdown, after that, the user can change the UI lang. If so, the e-mail lang will be changed for the lang selected, unless the lang is unavailable for the e-mail, in that case the selected e-mail lang will be the default one. And of course, the user can manually select the e-mail lang.

babelouest commented

2020-06-12 03:24:42 +02:00

(Migrated from github.com)

@yrammos , I've updated the pull request with the change I described in the point 4 above.

If you have other feature requests or improvements, don't hesitate!

@yrammos , I've updated the pull request with the change I described in the point 4 above. If you have other feature requests or improvements, don't hesitate!