[NV-1798] 🚀 Feature: Allow localization of templates

[nils-van-zuijlen]

🔖 Feature description

As of #2496 the subscriber stores its locale information, but this isn't used anywhere.

It would be nice to allow localization of the templates, so that a subscriber with a given locale receives notifications in his own locale.

🎤 Why is this feature needed ?

We do have users with multiple languages using the same product, and currently it would not be possible to use the same template for all locales, forcing us to do more in our app than seems necessary.

✌️ How do you aim to achieve this?

The template API could allow to specify a default locale for the main template, and alternate versions with the same id but different locales.

🔄️ Additional Information

A question left is whereas to match language codes (en, fr, es, ...) to locale codes (en_US, en_GB, fr_BE, es_BR, ...) or not.

👀 Have you spent some time to check if this feature request has been raised before?

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] I have read the Contributing Guidelines

Are you willing to submit PR?

None

_NV-1798

[SebastianStehle]

Perhaps the structural workflow should be somehow separated from the actual content. Consider you have like 50 different notifications (I know this from notifo), which share the same logic, then it would be super annoying to repeat the workflow over and over again.

[ryshu]

I quite agree with the observation but the problem here would be more to be able to tell the server, for a given text, how to translate it into another language if the latter is available on the template.

If I think about it, we can imagine a solution like that:

1. The template is built with a trigger and an email to send content as usual:

Hello {{ subscriber.firstName }}

2. By default, if not any locale is provided by the user, the server renders the default template, which is:

Hello Oscar

3. The user provides a local file for fr for example and if the subscriber has 'locale=fr', you should have:

Bonjour Oscar

It does not impact logic and might be a better way to use i18n than the change of template or others things that break any monitoring logic of our templates usages provided by the API.

Useful link to go deeper:

• https://github.com/smhg/gettext-parser
• https://www.gnu.org/software/gettext/

[SebastianStehle]

I think this does not work. First I doubt that automatic translation can work with placeholders and keep the grammar intact. Second you want to have full control over the text. Lets say you have one community manager per language and you want to end your email with a good bye from this manager. Then you have to change the text per language.

I see it more decoupled:

1. You have templates for emails and so on. Perhaps one generic notification email template and one template for security issues.
2. You have definitions of workflows which define the logic of your notifications.
3. You have a templates for notifications that you want to send, e.g. "XYZ has seen your post". Here you probably want to reference an email template and a workflow template.

Then you build combinations of this.

e.g.

"Your account has been hacked" + "Security Issue Email Template" + "Send always to all channels workflow"

[oba2311]

Thanks Sebastian - i18n is something we have on our radar for a later stage indeed and would be interesting to think about it together. For now I"ll add it to our backlog.

[ryshu]

Thanks for the feedback

For automatic translations, it works like this (with placeholders, and other tools to deal with grammar issues like plurals and such), so I guess it's satisfying enough for developers and translators.

For full control over the text, we indeed want to be able to translate the whole text. However, we don't want to repeat ourselves and we will have to manage the translation sentence by sentence as indicated. But this is for me the case of all the translation frameworks that could be used (for example https://www.i18next.com/ offers parcel translation).

I would have liked to see, in the proposed solution, how it could answer the translation problem. Indeed, the block-by-block construction is essential, but the fact that the user receiving the notification understands it is even more so in my opinion (a user will prefer to receive 3 notifications that he understands rather than one that he must translate because it is not in his native language).

Management of languages is for me a must-have on a notification center. and therefore eager to see how you will respond to this challenge later. I hope that it will not bring too much change to the software if it is designed after the other features, nor that it will force your teams to make a choice rather than another, nor that all your users will have to rethink their templates after evolutions.

[oba2311]

Thanks @ryshu , I'd encourage you to stick with us till we later this year tackle i18n and then I'd invite you to design the feature with us.

[johannesspohr]

Is there any update on when we can expect this? We're currently evaluating Novu for a bigger project and this is a must-have for us (I'm a bit confused to find out it doesn't exist, as it's clearly stated on the front page).

[scopsy]

@johannesspohr we are shaping this in the upcoming weeks, if you have a couple of minutes to jump on a call to discuss your particular usecase and etc, will highly appreciate it! https://calendly.com/dima-grossman/product-ideation

[L-U-C-K-Y]

@johannesspohr we are shaping this in the upcoming weeks, if you have a couple of minutes to jump on a call to discuss your particular usecase and etc, will highly appreciate it! https://calendly.com/dima-grossman/product-ideation

@scopsy also very important for us, sent you an invite for a meeting, maybe our team can help with the backend implementation.

[andreujuanc]

I wanted to integrate novu but without i18n it was not possible at all. (there is also the issue of having http api trigger only, but that's for another time)

[scopsy]

@andreujuanc let me know if you will have sometime to discuss the translation management, would love to show our current design and approach 🙏

[andreujuanc]

Hey @scopsy , thanks for the reply! Not much time ATM. But I'll subscribe to this thread.

[andreujuanc]

I'll dm you on twitter.

[leaanthony-sc]

I am also evaluating this and lack of i18n is a complete showstopper.

[veshant]

Novu seems to address our needs for a notification system, except for it missing translation functionality.

[MrSnoozles]

Same here. Been following Novu for almost 2 years, but without i18n we won't be able to adopt it.

How I would imagine it:

• define available languages and map them to subscriber properties. Example: English (default) Spanish (used if property language === 'es')
• then whenever you're entering anything the user will see, be it text or a template, you will get the option to enter it for every language.

When the flow is run, the property defined in the subscriber is checked and determines the template/text used.

[scopsy]

@MrSnoozles totally makes sense! The team is working hard on localization at the moment, and we willbe releasing afirst version mid January publicly. And next week feature flagging this to specific orgs. Will keep updating this thread on progress!

[MrSnoozles]

@scopsy Happy new year. I'm excited to try the first version after following the project for so long.

(Imo not super important for a first version, but:) Something that we had to consider in our custom made notification solution was

• different date and time formats depending on the region (e.g. 24hour / 12hour format ; dd.mm.yyyy vs mm/dd/yyyy etc)
• timezones (e.g. for a notification like "Reminder: the online meeting starts at [datetime in your timezone]"

[jainpawan21]

@scopsy Happy new year. I'm excited to try the first version after following the project for so long.

(Imo not super important for a first version, but:) Something that we had to consider in our custom made notification solution was

• different date and time formats depending on the region (e.g. 24hour / 12hour format ; dd.mm.yyyy vs mm/dd/yyyy etc)
• timezones (e.g. for a notification like "Reminder: the online meeting starts at [datetime in your timezone]"

Hi @MrSnoozles

On average how many different version of timezone format is required. I feel this use case can be handled using payload variable + if else condition + dateFormat handlebar helpers in case formats are two or three.

[nils-van-zuijlen]

Hi @MrSnoozles

On average how many different version of timezone format is required. I feel this use case can be handled using payload variable + if else condition + dateFormat handlebar helpers in case formats are two or three.

Time and date formats should be handled per locale, especially if you want to allow formats like "October, 12th 2023" (en_us) which would be "le 12 octobre 2023" in french and could be "the 12th of october, 2023" in en_gb.

Django does it that way and provides codes for "long" and "short" date formats. See the end of the date template tag documentation https://docs.djangoproject.com/en/5.0/ref/templates/builtins/#date

Of course, one could also specify a specific format in each translated template.

I would argue that timezone adjustments are out of the scope of localization, as they may be easier to implement separately, by using datetimes with timezone in the arguments and having a timezone field in the user profile.

[leaanthony-sc]

Hey all 👋 Just wondering what the latest status is on this? Thanks!

[scopsy]

Hi @leaanthony-sc! You can find more information about this here: https://docs.novu.co/content-creation-design/translations

At the moment timezone based scheduling is not support, but will be rolling this out quite soon. Closing the issue for now.