# Japanese (ja-JP) STT outputs kanji for spoken names — can it return a phonetic (katakana/kana) reading instead? **URL:** \ **Category:** Support Help\ **Tags:** general\ **Created:** [June 23, 2026, 12:49am UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164 "2026-06-23T00:49:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![goro.yanagi](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/goro.yanagi/32/2192_2.png) [@goro.yanagi](https://community.retellai.com/u/goro.yanagi)\ **Post date:** [June 23, 2026, 12:49am UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164/1 "2026-06-23T00:49:01Z")
Hi Retell team, We’re building a Japanese-language voice agent (Conversation Flow) that collects the caller’s name during a reservation and reads it back for confirmation. ## Problem For a Japanese voice agent, the STT returns spoken personal names as KANJI (natural Japanese orthography), not as the phonetic reading the caller actually spoke. Kanji is ambiguous about its reading, so the spoken information is lost the moment the STT commits to a kanji spelling. Concrete example from a real call: - The caller clearly says the reading “Toyoshima” (とよしま). - The STT transcript comes back as the kanji “豊島”. - “豊島” has multiple valid readings (Toshima OR Toyoshima), and we have no way to recover from the kanji alone which one the caller actually said. (Other everyday examples: 東 = Higashi or Azuma; 新谷 = Shintani or Araya; etc.) ## To be clear about where the conversion happens The kanji-to-kana conversion is done on OUR side, downstream of Retell — we run our own LLM to guess a reading from the kanji STT output. We are NOT asking Retell to do kana conversion. We only do this lossy guess because the STT gives us kanji in the first place; when it guesses the more common reading (“Toshima”), the agent reads back the wrong name and the caller has to correct us. If the STT could return the phonetic reading directly, we could drop this lossy downstream step entirely. ## Technical details - Agent: agent\_57b261c7d9fdd102163a5f0fd0 (name: voiceai\_stg\_a3867e4c) - Response engine: Conversation Flow (type “conversation-flow”, version 0) - Channel: voice - Languages (multilingual agent): ja-JP, en-US, ko-KR, zh-CN - Voice (TTS): voice\_id custom\_voice\_c9cd94fd5a53bca14cc385c189, voice\_model “s2-pro” - STT-related agent settings: only `language` and `boosted_keywords` ([“さくらカフェ”,“ランチ”,“洋食”,“バイキング”,“ヒスイ”,“中華”,“ディナー”]) are set. `stt_mode`, `vocab_specialization`, `denoising_mode`, `normalize_for_speech`, and `pronunciation_dictionary` are all unset (defaults). - Example call exhibiting the issue: call\_e5c7b48dcf661f1112911876eef ## Questions (all about the STT output, not downstream) 1. Can the Japanese (ja-JP) STT be configured to return a phonetic reading (katakana / hiragana / furigana) for recognized speech, instead of — or alongside — the kanji? 2. Does the API expose an alternative or phonetic transcript / word-level reading for a recognized segment that we could use for proper nouns? 3. Are there any STT settings (model selection, `stt_mode`, `vocab_specialization`, formatting options, custom vocabulary) that bias the Japanese transcription toward phonetic output, particularly for name-collection steps? 4. Which STT provider/model is used for Japanese (ja-JP) on a Conversation Flow voice agent, and does it support a reading/furigana output mode? The reading — not the kanji — is what we need for an accurate spoken read-back and for our records, so any way to obtain the phonetic form at the STT layer would solve this for us. Thanks in advance for any guidance. ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [June 23, 2026, 1:04pm UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164/2 "2026-06-23T13:04:12Z")
Thanks for the detail write up , i have escalated your Call ID and Questions to the team for a review. Regards ---
**Author:** ![rweale](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/rweale/32/2102_2.png) [@rweale](https://community.retellai.com/u/rweale)\ **Post date:** [June 23, 2026, 1:22pm UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164/3 "2026-06-23T13:22:42Z")
Unfortunately no, Retell’s Japanese STT doesn’t have an option to force phonetic output instead of kanji. Your best bet is using the pronunciation\_dictionary setting in agent config — you can map kanji names to their kana readings, and the STT should respect those hints. If that doesn’t work reliably, you might need to ask callers to spell their name phonetically or switch STT providers that support this. ---
**Author:** ![goro.yanagi](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/goro.yanagi/32/2192_2.png) [@goro.yanagi](https://community.retellai.com/u/goro.yanagi)\ **Post date:** [June 24, 2026, 6:26am UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164/4 "2026-06-24T06:26:10Z")
Hi @rweale Thank you for your answer!! I’ll find another solution. Goro ---
**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\ **Post date:** [June 25, 2026, 12:47pm UTC](https://community.retellai.com/t/japanese-ja-jp-stt-outputs-kanji-for-spoken-names-can-it-return-a-phonetic-katakana-kana-reading-instead/3164/5 "2026-06-25T12:47:39Z")
Hey @goro.yanagi We currently have no option for katakana output; the transcript is delivered directly from the STT provider. We’re continuing to investigate possible solutions.