starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Notifications in different languages #253

New issue

Closed

opened 2026-02-28 01:40:23 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 01:40:23 -05:00

Owner

Originally created by @saschabrockel on GitHub (Sep 21, 2021).

Describe the solution you'd like
It would be nice if the notifications would be in the same language as the interface or that you could choose the language or even individualize them. Currently, I've set the web interface to German but I'm still getting my mails, Discord & Telegram notifications in English. The problem is that not everybody speaks English especially older people.

Originally created by @saschabrockel on GitHub (Sep 21, 2021). **Describe the solution you'd like** It would be nice if the notifications would be in the same language as the interface or that you could choose the language or even individualize them. Currently, I've set the web interface to German but I'm still getting my mails, Discord & Telegram notifications in English. The problem is that not everybody speaks English especially older people.

deekerman

2026-02-28 01:40:23 -05:00

closed this issue
added the
feature-request

A:notifications
labels

deekerman commented

2026-02-28 01:40:27 -05:00

Author

Owner

@zsxeee commented on GitHub (Sep 21, 2021):

Seems we need the server-side translation, including response message and notification message.

@zsxeee commented on GitHub (Sep 21, 2021): Seems we need the server-side translation, including response message and notification message.

deekerman commented

2026-02-28 01:40:27 -05:00

Author

Owner

@Saibamen commented on GitHub (Sep 22, 2021):

@zsxeee The simplest way -> return message codes (with parameters if any) from server. Frontend will translate it with interpolation (https://www.i18next.com/translation-function/interpolation)

@Saibamen commented on GitHub (Sep 22, 2021): @zsxeee The simplest way -> return message codes (with parameters if any) from server. Frontend will translate it with interpolation (https://www.i18next.com/translation-function/interpolation)

deekerman commented

2026-02-28 01:40:27 -05:00

Author

Owner

@Saibamen commented on GitHub (Sep 22, 2021):

But for notifications, IMO it will be better if translation keys will be in new object-key, like:

notifications: {
   LOGIN_SUCCESS: "Logged in successfully",
   UNEXPECTED_ERROR: "Unexpected error detected. Please try again, check if you have latest app version or report a bug in GitHub"
}

@Saibamen commented on GitHub (Sep 22, 2021): But for notifications, IMO it will be better if translation keys will be in new object-key, like: ``` notifications: { LOGIN_SUCCESS: "Logged in successfully", UNEXPECTED_ERROR: "Unexpected error detected. Please try again, check if you have latest app version or report a bug in GitHub" } ```

deekerman commented

2026-02-28 01:40:28 -05:00

Author

Owner

@zsxeee commented on GitHub (Sep 22, 2021):

@Saibamen After check "notification-providers", I found many notification messages have their message text with little difference. It will make many unnecessary translation works.
Before add translation keys, I think we need a common message format/template first.

@zsxeee commented on GitHub (Sep 22, 2021): @Saibamen After check "notification-providers", I found many notification messages have their message text with little difference. It will make many unnecessary translation works. Before add translation keys, I think we need a common message format/template first.

deekerman commented

2026-02-28 01:40:28 -05:00

Author

Owner

@louislam commented on GitHub (Sep 23, 2021):

@Saibamen After check "notification-providers", I found many notification messages have their message text with little difference. It will make many unnecessary translation works.
Before add translation keys, I think we need a common message format/template first.

Agree, but it is not an easy task, as some notification payloads are very special such as Discord and MS Teams.

@louislam commented on GitHub (Sep 23, 2021): > @Saibamen After check "notification-providers", I found many notification messages have their message text with little difference. It will make many unnecessary translation works. > Before add translation keys, I think we need a common message format/template first. Agree, but it is not an easy task, as some notification payloads are very special such as Discord and MS Teams.

deekerman commented

2026-02-28 01:40:28 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 9, 2021):

While the card on discord etc. are nice, I think that the priority should be creating a general text template to use for most supported notifications (with potentially some specific ones for the special cases like twitter with its character limits).

Ideally, the templates could be over-ridden by the user for customization, or personal translation if a community translation has not yet been done. In the best case, you could override the templates on a per-notification basis, as well as override the default notifications (thus updating all notifications without needing to update them separately).

From the quick searching I have done, I think liquidjs might be a good option for the templates, as Liquid appears to be a reasonable enough language for what most kuma users need, and the library is actively maintained.

The special cases that need an object, such as discord's card, might be done by accepting a JSON object as the "template", and running each non obj/array in the object against the template engine. You could also generate raw JSON with the template, and use that. In either case, building a custom template or translation would be a bit messy for discord etc., but it would still be possible.

There are several other issues that I think all boil down to more customization on the notification message (#524, #582, #172, #208, #428) and I think using a template engine would solve the lot, while also potentially providing a work-around to a number of others such as #570 and #40 (depending on the data available to the template)

I would be willing to take a crack at a proof of concept implementing luquidjs, but there is a small chance someone else will need to finish it as I will be loosing some of my free time following next week. If you think that this has a good chance of being used, I will create a new issue to track progress.

@deefdragon commented on GitHub (Oct 9, 2021): While the card on discord etc. are nice, I think that the priority should be creating a general text template to use for most supported notifications (with potentially some specific ones for the special cases like twitter with its character limits). Ideally, the templates could be over-ridden by the user for customization, or personal translation if a community translation has not yet been done. In the best case, you could override the templates on a per-notification basis, as well as override the default notifications (thus updating all notifications without needing to update them separately). From the quick searching I have done, I think [liquidjs](https://github.com/harttle/liquidjs) might be a good option for the templates, as Liquid appears to be a reasonable enough language for what most kuma users need, and the library is actively maintained. The special cases that need an object, such as discord's card, might be done by accepting a JSON object as the "template", and running each non obj/array in the object against the template engine. You could also generate raw JSON with the template, and use that. In either case, building a custom template or translation would be a bit messy for discord etc., but it would still be possible. There are several other issues that I think all boil down to more customization on the notification message (#524, #582, #172, #208, #428) and I think using a template engine would solve the lot, while also potentially providing a work-around to a number of others such as #570 and #40 (depending on the data available to the template) I would be willing to take a crack at a proof of concept implementing luquidjs, but there is a small chance someone else will need to finish it as I will be loosing some of my free time following next week. If you think that this has a good chance of being used, I will create a new issue to track progress.

deekerman commented

2026-02-28 01:40:28 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 11, 2026):

I don't think that we will add this.
This is a fairly large issue and i18n in our backend is a larger task as-is.

If someone is willing to work on this, I think time is much better spend on the following issue instead

https://github.com/louislam/uptime-kuma/issues/646

TL;DR: Some monitors already are templatable (!= translated), but the list is small.

If someone wants to do an RFC what it would take to move towards this goal, I wold like to read is.
Otherwise, this issue is not planned

@CommanderStorm commented on GitHub (Jan 11, 2026): I don't think that we will add this. This is a fairly large issue and i18n in our backend is a larger task as-is. If someone is willing to work on this, I think time is much better spend on the following issue instead - https://github.com/louislam/uptime-kuma/issues/646 TL;DR: Some monitors already are templatable (!= translated), but the list is small. If someone wants to do an RFC what it would take to move towards this goal, I wold like to read is. Otherwise, this issue is not planned