starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 16:35:53 +02:00

[GH-ISSUE #1592] Feature Request: Korean TTS support for Phone Calls #1118

New issue

Open

opened 2026-05-07 00:30:23 +02:00 by BreizhHardware · 5 comments

BreizhHardware commented

2026-05-07 00:30:23 +02:00

Owner

Originally created by @hunydev on GitHub (Feb 4, 2026).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1592

Hello,

I am a user who actively utilizes the phone call feature in ntfy.
According to the documentation, it states:

As of today, the text-to-speed voice used will only support English. If there is demand for other languages, we'll be happy to add support for that. Please open an issue on GitHub.

I would like to request support for Korean TTS. This would greatly enhance the usability of the phone call alerts for Korean users.

Thank you!

Originally created by @hunydev on GitHub (Feb 4, 2026). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1592 Hello, I am a user who actively utilizes the phone call feature in ntfy. According to the [documentation](https://docs.ntfy.sh/publish/?h=phone#phone-calls), it states: > As of today, the text-to-speed voice used will only support English. If there is demand for other languages, we'll be happy to add support for that. Please open an issue on GitHub. I would like to request support for Korean TTS. This would greatly enhance the usability of the phone call alerts for Korean users. Thank you!

BreizhHardware commented

2026-05-07 00:30:23 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 4, 2026):

I am generally open to this. And Twilio does support many languages.

Do you have a suggestion of what the ideal user experience would be like? Should the Call header support a language, e.g. Call: +12345[de], or something?
Do you want the entire "You have a notification from ntfy on topic ..." to be also in Korean? Because then we'd have to make that translatable as well. Or is it enough to have just the payload?

@binwiederhier commented on GitHub (Feb 4, 2026): I am generally open to this. And Twilio does support many languages. 1. Do you have a suggestion of what the ideal user experience would be like? Should the `Call` header support a language, e.g. `Call: +12345[de]`, or something? 2. Do you want the entire "You have a notification from ntfy on topic ..." to be also in Korean? Because then we'd have to make that translatable as well. Or is it enough to have just the payload?

BreizhHardware commented

2026-05-07 00:30:24 +02:00

Author

Owner

@hunydev commented on GitHub (Feb 4, 2026):

What I’m describing below is a set of ideas at an exploratory level.

As a TTS engineer, I have a strong interest in this area and have spent some time thinking through different approaches. My general belief is that it’s best to start with a solution that achieves maximum impact with relatively minimal implementation effort.

1. Leveraging the country code in the phone number

The phone numbers used for ntfy’s phone call feature already include a country calling code, such as +1 or +82 (South Korea).
While a country code alone cannot directly determine the language of user-provided text, I think it is reasonable to infer a default language by using IETF BCP 47 language tags, which combine ISO 639 (language codes) and ISO 3166-1 (country codes).
For example, en-US represents U.S. English. With this approach, a phone number that includes the U.S. country code (+1) could default to English (en).
In the same way, a phone number like +8210xxxxxxxx could be parsed from the Call header and mapped to ko-KR, resulting in Korean (ko) speech output.
This approach does not require the user to explicitly specify a language, while still producing reasonably correct and user-friendly behavior for most cases.

2. Explicitly specifying the language in the Call header

As you mentioned, another approach is to allow the language to be specified directly in the Call header along with the phone number.
In this model, the phone number itself becomes less important from a language-selection perspective, and the intent is completely unambiguous.
This makes it very clear to the TTS system which language should be used for speech synthesis and gives users full control over the spoken language.

3. Using a multilingual TTS engine

This depends on what Twilio supports, but it’s worth mentioning that even with the current ntfy phone call feature, Korean text does get spoken if it’s included.
However, the result sounds extremely unnatural—similar to a non-Korean speaker reading Hangul phonetically using English pronunciation rules.
While Hangul characters are technically read, the speech is difficult for native Korean listeners to understand.
A multilingual TTS system is one where a single voice can naturally speak multiple languages. With such a system, even mixed-language sentences (e.g., Korean + English) can be spoken fluently enough for native speakers of each language to understand without difficulty.

4. (Very inefficient idea) Using an LLM to infer the language

To use a Korean expression, this would be a case of “the tail wagging the dog.”
This approach would involve integrating an LLM into the phone call flow, using the Call header and payload text to infer the language automatically.
It is clearly inefficient and heavyweight for this problem, but it has the advantage of requiring no new user-facing interface.
The LLM output could simply be a language code, making the integration conceptually simple despite the overhead.

About the introductory phrase

Regarding whether
“You have a notification from ntfy on topic …”
should also be spoken in Korean:

In my case, when I receive a phone call from ntfy, I already fully understand that this call itself is a notification. Because of that, I don’t consider it a problem at all if this introductory phrase remains in English.

Even if the introduction is spoken in English and only the payload content is spoken in Korean, that would be perfectly acceptable to me. Honestly, I would already be very grateful just to have the payload spoken naturally in Korean.

@hunydev commented on GitHub (Feb 4, 2026): What I’m describing below is a set of ideas at an exploratory level. As a TTS engineer, I have a strong interest in this area and have spent some time thinking through different approaches. My general belief is that it’s best to start with a solution that achieves maximum impact with relatively minimal implementation effort. ## 1. Leveraging the country code in the phone number - The phone numbers used for ntfy’s phone call feature already include a country calling code, such as `+1` or `+82` (South Korea). - While a country code alone cannot directly determine the language of user-provided text, I think it is reasonable to infer a default language by using **IETF BCP 47 language tags**, which combine **ISO 639 (language codes)** and **ISO 3166-1 (country codes)**. - For example, `en-US` represents U.S. English. With this approach, a phone number that includes the U.S. country code (`+1`) could default to English (`en`). - In the same way, a phone number like `+8210xxxxxxxx` could be parsed from the Call header and mapped to `ko-KR`, resulting in Korean (`ko`) speech output. - This approach does not require the user to explicitly specify a language, while still producing reasonably correct and user-friendly behavior for most cases. ## 2. Explicitly specifying the language in the Call header - As you mentioned, another approach is to allow the language to be specified directly in the Call header along with the phone number. - In this model, the phone number itself becomes less important from a language-selection perspective, and the intent is completely unambiguous. - This makes it very clear to the TTS system which language should be used for speech synthesis and gives users full control over the spoken language. ## 3. Using a multilingual TTS engine - This depends on what Twilio supports, but it’s worth mentioning that even with the current ntfy phone call feature, Korean text *does* get spoken if it’s included. - However, the result sounds extremely unnatural—similar to a non-Korean speaker reading Hangul phonetically using English pronunciation rules. - While Hangul characters are technically read, the speech is difficult for native Korean listeners to understand. - A **multilingual TTS** system is one where a single voice can naturally speak multiple languages. With such a system, even mixed-language sentences (e.g., Korean + English) can be spoken fluently enough for native speakers of each language to understand without difficulty. ## 4. (Very inefficient idea) Using an LLM to infer the language - To use a Korean expression, this would be a case of “the tail wagging the dog.” - This approach would involve integrating an LLM into the phone call flow, using the Call header and payload text to infer the language automatically. - It is clearly inefficient and heavyweight for this problem, but it has the advantage of requiring no new user-facing interface. - The LLM output could simply be a language code, making the integration conceptually simple despite the overhead. ## About the introductory phrase Regarding whether **“You have a notification from ntfy on topic …”** should also be spoken in Korean: In my case, when I receive a phone call from ntfy, I already fully understand that this call itself is a notification. Because of that, I don’t consider it a problem at all if this introductory phrase remains in English. Even if the introduction is spoken in English and only the payload content is spoken in Korean, that would be perfectly acceptable to me. Honestly, I would already be very grateful just to have the payload spoken naturally in Korean.

BreizhHardware commented

2026-05-07 00:30:24 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 4, 2026):

Sorry, but I won't read LLM generated comments. I don't want to talk to a robot. I want to hear your thoughts.

@binwiederhier commented on GitHub (Feb 4, 2026): Sorry, but I won't read LLM generated comments. I don't want to talk to a robot. I want to hear your thoughts.

BreizhHardware commented

2026-05-07 00:30:24 +02:00

Author

Owner

@hunydev commented on GitHub (Feb 4, 2026):

There seems to have been a misunderstanding. I am a Korean user and I am not very comfortable writing in English, so I asked an LLM to translate my response for me. I apologize for any confusion this may have caused.

Below is the original Korean text that I asked the LLM to translate. Please feel free to translate and read it.

내가 말하는건 아이디어 차원에서 정리해본 내용이다. 우선 내가 TTS를 개발하는 엔지니어로써, 이와 관련하여 관심이 많아 다양한 아이디어를 생각해보았다. 처음은 비교적 최소한의 구현으로 최대의 효율을 내는 것이 좋다고 생각한다.

전화번호에 포함되는 지역코드를 활용하는 방법

현재 ntfy에서 사용하는 phone call 기능에 사용되는 전화번호는 +1, +82(대한민국) 같은 국가 코드를 포함하여 구성이 된다.
국가코드로 사용자가 입력한 텍스트의 언어를 판단할 수는 없으나, ISO 639 (언어 코드) 와 ISO 3166-1 (국가 코드) 가 조합된 IETF BCP 47 (언어 태그)를 사용하면 해당 국가에서 사용되는 언어를 충분히 판단할 수 있다고 본다. 즉 en-US는 미국 영어를 나타내며 이를 가지고 미국(US) 국가 코드 +1 로 구성된 전화번호는 영어(en)를 지원하도록 하는 것이다.
이렇게 하면 대한민국의 경우 +8210xxxxxxxx 와 같이 phone call 용 전화번호를 헤더로부터 파싱하여 ko-KR 코드에 의해 KR(대한민국, +82) -> ko(korean, 한국어)로 발화하면 된다.

명시적으로 언어에 대한 코드 값을 헤더에 삽입하는 방법

언급해준 것처럼 Call Header에 phone call 전화번호와 함께 발화할 텍스트의 언어를 지정하는 방식이다.
이렇게 하면 사실상 전화번호는 중요하지 않고 사용자가 원하는 언어로 알림 텍스트를 발화하도록 TTS에 지시하기가 모호하지 않고 명확해진다.

Multilingual을 지원하는 TTS를 활용하는 방법

이것은 twillo의 지원여부에 따라 달라지겠지만, 현재 ntfy의 phone call 기능도 텍스트에 한글을 넣어도 말이 나오긴 한다.
하지만 마치 비한국인이 한글발음열을 영어로 쓰고 읽는것처럼 매우 어색하게 읽는다. 사실상 문자로써 한글은 읽지만 한국인이 듣기엔 이해하기가 어려운 발화이다.
Multilingual TTS는 동일한 화자가 다양한 언어를 자연스럽게 발화할 수 있는 TTS 또는 기술이라고 보면 된다. 즉 Multilingual을 지원하는 TTS에 한국어 + 영어 문장을 섞어서 사용해도 각각의 언어를 모국어로 하는 사람이 이해하기 충분할 정도로 자연스럽게 발화한다.

(매우 비효율적인 아이디어) LLM을 사용하여 언어를 판단하게 하는 방법

(한국어속담으로)배보다 배꼽이 더 큰 경우이지만, phone call 기능에 LLM을 연동하여 Call Header와 Payload를 보고 언어를 유추하도록 하는 방식이다.
매우 비 효율적이지만 사실상 인터페이스 추가사항이 없고 LLM 출력이 바로 언어 값으로 출력되니 단순하긴 하다.

추가로 ["You have a notification from ntfy on topic ..." to be also in Korean?] 에 대한 내용에 대해서는 나의 경우 ntfy가 phone call로 나에게 전화를 했다는 것을 충분히 인지한 상태이므로 해당 도입 문구를 발화하는 것은 전혀 문제가 되지 않는다고 생각한다. 즉 내용을 한글로 작성 후 phone call을 사용할 때 도입 문구가 영어로 나오고 이후에 내용은 한국어로 발성이 되어도 전혀 문제 없다. 오히려 이렇게라도 나와준다면 감사할 따름이다.

@hunydev commented on GitHub (Feb 4, 2026): There seems to have been a misunderstanding. I am a Korean user and I am not very comfortable writing in English, so I asked an LLM to translate my response for me. I apologize for any confusion this may have caused. Below is the original Korean text that I asked the LLM to translate. Please feel free to translate and read it. 내가 말하는건 아이디어 차원에서 정리해본 내용이다. 우선 내가 TTS를 개발하는 엔지니어로써, 이와 관련하여 관심이 많아 다양한 아이디어를 생각해보았다. 처음은 비교적 최소한의 구현으로 최대의 효율을 내는 것이 좋다고 생각한다. 1. 전화번호에 포함되는 지역코드를 활용하는 방법 - 현재 ntfy에서 사용하는 phone call 기능에 사용되는 전화번호는 +1, +82(대한민국) 같은 국가 코드를 포함하여 구성이 된다. - 국가코드로 사용자가 입력한 텍스트의 언어를 판단할 수는 없으나, ISO 639 (언어 코드) 와 ISO 3166-1 (국가 코드) 가 조합된 IETF BCP 47 (언어 태그)를 사용하면 해당 국가에서 사용되는 언어를 충분히 판단할 수 있다고 본다. 즉 en-US는 미국 영어를 나타내며 이를 가지고 미국(US) 국가 코드 +1 로 구성된 전화번호는 영어(en)를 지원하도록 하는 것이다. - 이렇게 하면 대한민국의 경우 +8210xxxxxxxx 와 같이 phone call 용 전화번호를 헤더로부터 파싱하여 ko-KR 코드에 의해 KR(대한민국, +82) -> ko(korean, 한국어)로 발화하면 된다. 2. 명시적으로 언어에 대한 코드 값을 헤더에 삽입하는 방법 - 언급해준 것처럼 Call Header에 phone call 전화번호와 함께 발화할 텍스트의 언어를 지정하는 방식이다. - 이렇게 하면 사실상 전화번호는 중요하지 않고 사용자가 원하는 언어로 알림 텍스트를 발화하도록 TTS에 지시하기가 모호하지 않고 명확해진다. 3. Multilingual을 지원하는 TTS를 활용하는 방법 - 이것은 twillo의 지원여부에 따라 달라지겠지만, 현재 ntfy의 phone call 기능도 텍스트에 한글을 넣어도 말이 나오긴 한다. - 하지만 마치 비한국인이 한글발음열을 영어로 쓰고 읽는것처럼 매우 어색하게 읽는다. 사실상 문자로써 한글은 읽지만 한국인이 듣기엔 이해하기가 어려운 발화이다. - Multilingual TTS는 동일한 화자가 다양한 언어를 자연스럽게 발화할 수 있는 TTS 또는 기술이라고 보면 된다. 즉 Multilingual을 지원하는 TTS에 한국어 + 영어 문장을 섞어서 사용해도 각각의 언어를 모국어로 하는 사람이 이해하기 충분할 정도로 자연스럽게 발화한다. 4. (매우 비효율적인 아이디어) LLM을 사용하여 언어를 판단하게 하는 방법 - (한국어속담으로)배보다 배꼽이 더 큰 경우이지만, phone call 기능에 LLM을 연동하여 Call Header와 Payload를 보고 언어를 유추하도록 하는 방식이다. - 매우 비 효율적이지만 사실상 인터페이스 추가사항이 없고 LLM 출력이 바로 언어 값으로 출력되니 단순하긴 하다. 추가로 ["You have a notification from ntfy on topic ..." to be also in Korean?] 에 대한 내용에 대해서는 나의 경우 ntfy가 phone call로 나에게 전화를 했다는 것을 충분히 인지한 상태이므로 해당 도입 문구를 발화하는 것은 전혀 문제가 되지 않는다고 생각한다. 즉 내용을 한글로 작성 후 phone call을 사용할 때 도입 문구가 영어로 나오고 이후에 내용은 한국어로 발성이 되어도 전혀 문제 없다. 오히려 이렇게라도 나와준다면 감사할 따름이다.

BreizhHardware commented

2026-05-07 00:30:24 +02:00

Author

Owner

@hunydev commented on GitHub (Feb 4, 2026):

저는 AI 도움 없이 서로의 의도를 오해하지 않고 영어로 의견을 수용하거나 말하기가 어렵습니다.
LLM 사용에 회의적이시겠지만 그래도 꾸준히 잘 사용하고 애정이 있는 서비스여서 한국어가 지원되었으면 좋겠다는 생각에 용기를 내어보았습니다.

(추가)
기억하실지 모르겠지만 작년에 +82 에 대한 phone call 기능이 동작하지 않는다는 문의 메일을 드렸었는데 그 때 빠르게 지원을 해주셔서 매우 인상 깊었습니다. 현재는 ntfy phone call 기능을 단순 비상 알림 용도 정도로 사용하고 있는데, 조금 아쉬워서 이슈를 등록하게 되었습니다.

@hunydev commented on GitHub (Feb 4, 2026): 저는 AI 도움 없이 서로의 의도를 오해하지 않고 영어로 의견을 수용하거나 말하기가 어렵습니다. LLM 사용에 회의적이시겠지만 그래도 꾸준히 잘 사용하고 애정이 있는 서비스여서 한국어가 지원되었으면 좋겠다는 생각에 용기를 내어보았습니다. (추가) 기억하실지 모르겠지만 작년에 +82 에 대한 phone call 기능이 동작하지 않는다는 문의 메일을 드렸었는데 그 때 빠르게 지원을 해주셔서 매우 인상 깊었습니다. 현재는 ntfy phone call 기능을 단순 비상 알림 용도 정도로 사용하고 있는데, 조금 아쉬워서 이슈를 등록하게 되었습니다.