Translated Emails

[lukevella]

Previously this was quite hard to do because the email templates where precompiled html files but now that we are using React as a templating engine for emails it should be possible to use react-i18next to translate these emails as well.

The subject lines will need a separate solution (hopefully using i18next) since they are not part of the templates.

_RAL-247

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[ltguillaume]

Any progress on this? 🙂

Since emails are an integral part of the registration and subsequent login process, unfortunately there are quite a few people that cannot use this if the emails aren't translated.

[ltguillaume]

@lukevella I think this is really essential for the people to not get confused, so if you'd like, perhaps I could create a PR for this, provided that I'm given some pointers on how this translation framework is implemented.

[lukevella]

Just want to add that for this feature to be delivered we need to be able to know the users preferred locale on the server side. One way to do this is to include the locale as a parameter for each function that could trigger an email. This can be quite cumbersome and is error-prone. Another option is to modify how user sessions work such that a locale is always set. Currently it's only set when explicitly modified by the user. I'd much prefer the latter option but it's a significant piece of work.

[ltguillaume]

As soon as a user/participant is created, the language in which Rallly is currently being displayed can be saved to the profile. I'm not sure why this would be a significant piece of work.

For existing users, after logging in, do a check if the profile contains a manually set language, otherwise save the current browser language to the user's profile.

[lukevella]

That only works for new users and I believe is partially done. We still need a way to get this info from existing users and even guests that don't have an account can receive emails which should be in their preferred language.

[ltguillaume]

Like I said:

For existing users, when/after logging in, do a check if the profile contains a manually set language, otherwise save the current browser language to the user's profile.

If they haven't accessed the website yet, fallback is English.

I don't see a difference for guests (I assume you mean participants): when they go to the website, their browser language can be determined and saved, too.

[lukevella]

Looks like you updated your previous comment with more info. Thanks for that.

I'm not sure what your goal is with your comments. Would you like me to say that this is not a significant piece of work? Simply writing down ideas doesn't solve the problem.

[ltguillaume]

Sorry about that, I do hope I didn't sound too pushy there. I'm just trying to understand why it would entail much work, since it does seem like only a few adjustments from my POV. But then again, I have no experience with Next.js/prisma.

[lukevella]

I only said that it is significant. It merits having its own issue which I intend to create in due time.

As you might have noticed, when you start pulling this thread you will find various different cases that need to be handled that are not immediately obvious.

My comment was a note to myself and to anyone that cares that there is slightly more to this task than being able to render emails in different languages.

[hangya]

Just wanted to add, that in our use case, since our target audience is using the same language, it would also work if we could set a default email language at server level, using some global setting/environment variable; maybe that would be easier to implement than to check user-level preferences.

[melegiul]

Hi. First of all thank for providing this awesome tool. I really like it. :tada:

I know, you recently just removed the good first issue label. But do you think you would still accept PRs from the community?

[lukevella]

@melegiul, possibly yes! If you're interested, maybe reach out on Discord and we can discuss the approach before starting any work or submitting a PR.

[lukevella]

Closed by #1278. Translations can be submitted through Crowdin

[ltguillaume]

I see

You're receiving this email because a request was made to login to **<domain />**. If this wasn't you contact <a>{{supportEmail}}</a>.

(excluding **). Should this be

You're receiving this email because a request was made to login to **<a>{{domain}}</a>**. If this wasn't you contact <a>{{supportEmail}}</a>

[lukevella]

Hi @ltguillaume, the translation text is correct here because <domain /> gets replaced with a link to the domain where the email was sent from. I understand this is a bit confusing since we treat support email differently so will consider amending this at some point.

[ltguillaume]

Ok, got it! As long as it works, it's fine, but indeed, the use of {{variable}} was what I expected.