Add lightweight language detection and safe fallback mechanism for TTS

[dhanashreehingnekar28]

Related to #76

Summary

This PR introduces a lightweight language detection system along with a safe fallback mechanism to improve the robustness of the TTS pipeline in Speak.

Problem

Currently, when users input text in unsupported or non-Latin languages, the TTS system may produce incorrect, unintelligible output or fail silently. This impacts usability in multilingual environments.

Solution

• Added a new module language_detector.py using Unicode-based script detection
• Integrated detection into the speech.py pipeline before speech synthesis
• Implemented a safe fallback to English when the detected language is unsupported
• Added logging for better debugging and future improvements

Features

• Detects common scripts:
• Devanagari (Hindi)
• Arabic
• CJK (Chinese/Japanese)
• Prevents broken or unintelligible speech output
• Maintains compatibility with both Kokoro TTS and eSpeak fallback

Impact

• Improves reliability and user experience in multilingual scenarios
• Prevents runtime failures and unclear audio output
• Aligns with fallback and robustness improvements in TTS pipeline

Example

Input: Hindi text
Before: Incorrect or broken audio
After: Graceful fallback to English speech output

Testing

• English input → works normally
• Hindi / Arabic / Chinese input → fallback triggered correctly
• Verified no regression in existing TTS functionality

Future Work

• Integrate advanced language detection (e.g., fastText, langdetect)
• Map detected languages to appropriate TTS voices
• Provide UI feedback for unsupported languages

[dhanashreehingnekar28]

Hi mentors,

This PR adds a lightweight language detection and fallback mechanism to improve TTS robustness, especially when unsupported languages are passed.

Would love feedback on:

• Whether this aligns with current roadmap
• Suggestions for improvement

Happy to iterate based on your guidance. Thanks!

[dhanashreehingnekar28]

Hi mentors,
I’ve updated the PR to mark it as related to the fallback mechanism issue (#76), since it contributes to robustness in the TTS pipeline via language detection and safe fallback.
Would appreciate your feedback on whether this approach aligns with the intended direction. Thanks!