8000 Unintended style/language changes in Japanese and request for editable Formatting prompt · Issue #111 · amicalhq/amical · GitHub
[go: up one dir, main page]

Skip to content

Unintended style/language changes in Japanese and request for editable Formatting prompt #111

Open

Description

@kuroha-clover

Describe the bug
When dictating in Japanese, the output is often unintentionally translated into English, changed into a formal written style, or changed into a polite form (Keigo). Additionally, unwanted newlines are sometimes added to the beginning and end of the text.

App Version
v1.0.1

Model Information

  • Local: Qwen2.5 3B (Q4_K_M), Qwen2.5 3B (Q8), Llama 3 8B Swallow (Q4_K_M), Qwen2.5 7B (Q4_K_M)
    • Note: These are maybe instruct variants.
  • Amical Cloud

System Information

  • Operating System: Windows 11
  • RAM: 32GB
  • GPU: NVIDIA RTX 3060 Ti
  • CPU: Intel i5-12400F

To Reproduce
Steps to reproduce the behavior:

  1. Set the language to Japanese and enable the Formatting option.
  2. Perform dictation using a local model or Amical Cloud model.
  3. Observe that casual spoken input is sometimes changed into a formal written style or a polite form (Keigo).
  4. Further Test: Create a custom Modelfile for Ollama with temperature 0 and strict instructions (e.g., "Do not translate", "Do not change the style/tone"), then use it for Formatting in Amical.
  5. Observe that the output still ignores these parameters and results in the same unintended style changes and newlines.

Expected behavior
The Formatting feature should only perform its intended cleaning tasks—such as removing fillers (e.g., "えーと", "あのー"), fixing repetitions/self-corrections, and correcting obvious typos.
Crucially, it should preserve the original tone and language of the speaker. If I speak in a casual style, the output should remain in that same casual style, not be "upgraded" to a formal written or polite (Keigo) form.

Additional context

  • Investigation: I am not an engineer, but I’ve been using AI tools and the internet to troubleshoot this. I suspect that Amical's internal system prompt for Formatting is so dominant that it overrides user-defined model settings.
  • Feature Request: Please consider making the prompt for Formatting editable for users. This would allow us to customize the instructions to ensure the output matches our specific needs without being overridden by default settings.

Activity

  1. haritabh-z01 commented on Feb 27, 2026

    @haritabh-z01
    Contributor

    @kuroha-clover can you try disabling formatting while having amical cloud as the transcription model? Does it still convert to the polite form?
    If you can share a couple of sentences / recordings of what you said and what it converted into. I can run some tests on our cloud side.

  2. kuroha-clover commented on Feb 27, 2026

    @kuroha-clover
    Author

    if I disable formatting, the output doesn't convert to polite form. However, I lose the filler removal and proper punctuation, which are the features I really want to use.
    Regarding the examples, I've forgotten the specific sentences I used earlier. Also, I can't record a new test right now because my family is sleeping nearby!
    I'll get back to you with some specific "input vs. output" examples as soon as I can record again.

  3. kuroha-clover commented on Feb 27, 2026

    @kuroha-clover
    Author

    Also, I want to use a Local model rather than the Cloud model.

  4. haritabh-z01 commented on Feb 27, 2026

    @haritabh-z01
    Contributor

    We will soon be adding the ability to configure prompts, so you should be able to tweak them as you see fit and use local models for formatting as need be.

  5. kuroha-clover commented on Feb 28, 2026

    @kuroha-clover
    Author

    Thanks for the update! Configurable prompts are exactly what I need. I'm sure it will solve most of these issues.

    I ran some tests (6x each), and surprisingly, the formatting issues even occurred while I was dictating this very response! (with Amical Cloud dictation and formatting)

    Filler & Self-correction failure: "えーと", "なんかあの" and corrections like "10:00... no, 11:00" are often not cleaned up.
    Meaning/Tone change: Casual questions are sometimes converted into polite statements, altering the original intent.

    Test Results:

    Spoken: "10時、いや11時に駅前でいい?" (Is it okay at 10:00... no, 11:00, at the station?)
    Output: "11時に駅前でいいです。" (Changed to a statement; self-correction failed)

    Spoken: "なんか、あのー...めっちゃ便利..."
    Output: "なんかあの" remained in all 6 tests (Filler removal failed).

    Spoken: "今日の晩御飯...どう?"
    Output: 3/6 times became polite ("...ですか?") and "えっと" remained.

    Spoken (Meta test): "...送る文章考えて。" (While dictating this reply)
    Output: Became formal: "...作成してください。" / "...考えてください。"

    I'm really looking forward to the update!! Thanks for your support! (And sorry for the long post!)

  6. haritabh-z01 commented on Feb 28, 2026

    @haritabh-z01
    Contributor

    @kuroha-clover for the first instance
    the default expectation would be self correction but preserving the tone and keeping it as a question, right?
    i.e., 10時に駅前でいい?

  7. kuroha-clover commented on Mar 3, 2026

    @kuroha-clover
    50A0
    Author

    Yes, exactly! The expectation is to preserve the casual tone and keep it as a question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0