Fix Chinese input and Apple ASR locale selection#254
Fix Chinese input and Apple ASR locale selection#254stego-z wants to merge 2 commits intoaltic-dev:mainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c78766907
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
|
|
||
| if model == .cohereTranscribeSixBit { | ||
| if model == .cohereTranscribeSixBit || model == .appleSpeech || model == .appleSpeechAnalyzer { |
There was a problem hiding this comment.
Including .appleSpeechAnalyzer in this shared picker exposes all CohereLanguage values, but the analyzer is documented in SettingsStore.SpeechModel.languageSupport as supporting only EN/ES/FR/DE/IT/JA/KO/PT/ZH. Selecting unsupported options (e.g., Arabic, Greek, Dutch, Polish, Vietnamese) is silently ignored because AppleSpeechAnalyzerProvider.resolvedRecognitionLocale() falls back to English, so users can believe they set a target language while getting English transcription instead. Restrict the menu for Apple Speech Analyzer to its supported locales (or surface an explicit validation/error) so selection reflects actual runtime behavior.
Useful? React with 👍 / 👎.
|
@codex can we merge this PR? |
|
To use Codex here, create an environment for this repo. |
|
hey thanks for the PR ; was these changes intentional ? would love your comment on here. What it should do ideally: If the user is using Chinese, recommend Whisper. It is not just recommending Whisper. I am down foe the paste method etc and splitting different Chinese types. but recommending model seems too biased. Do you have any model on top of your mind for Chinese? I can try to add it actually. Qwen ASR or anything else? Thanks. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be764f239d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| enum SpeechLocaleResolver { | ||
| static var prefersChineseRecognition: Bool { | ||
| Locale.preferredLanguages.contains { Self.languageCode(from: $0) == "zh" } |
There was a problem hiding this comment.
prefersChineseRecognition now returns true if any preferred language starts with zh, and SpeechModel.defaultModel uses this flag to switch Apple Silicon users to Whisper Base. This means users whose primary language is not Chinese but who keep Chinese as a secondary fallback will still be treated as “Chinese-first” and get a different default model path than intended. Restrict this check to the highest-priority preferred locale (or an explicit Chinese selection) so secondary language fallbacks do not silently change onboarding/default model behavior.
Useful? React with 👍 / 👎.
| if self.defaults.string(forKey: Keys.selectedCohereLanguage) == "zh" { | ||
| return .traditionalChinese |
There was a problem hiding this comment.
zh setting without forcing zh-TW
The migration path for older installs maps stored SelectedCohereLanguage == "zh" directly to .traditionalChinese. Because SpeechLocaleResolver.locale(for:) maps that to zh-TW, existing users who previously chose generic Mandarin are now forced onto the Taiwan locale when using Apple speech models, which can degrade recognition for users expecting mainland/Simplified behavior. The migration should preserve neutrality (or infer from system Chinese locale) instead of hard-coding Traditional Chinese.
Useful? React with 👍 / 👎.
|
Hey, thanks again for the review. I’ve adjusted the PR so Chinese only affects the recommendation path now, and it no longer silently overrides the model the user already picked.
I also kept the CJK reliable-paste behavior and the insertion split by text type, since that part seems to match the intended behavior.
I ran Qwen ASR on my M4 Mac mini and M2 MacBook Pro Max, and it felt a bit too slow for me, so I wouldn’t want to make that the default recommendation either. For now, I think it’s better to keep the model choice open unless we find something that’s clearly better for Chinese on these Macs.
The build is passing on my side now as well. Let me know if you want me to tweak anything else.
Cheers.
… ALTIC ***@***.***> 於 2026年4月5日 06:26 寫道：
altic-dev
left a comment
(altic-dev/FluidVoice#254)
<#254 (comment)>
hey thanks for the PR ; was these changes intentional ? would love your comment on here.
What it should do ideally:
If the user is using Chinese, recommend Whisper.
If the user uses Apple Speech / Apple Speech Analyzer / Cohere, use the app’s chosen language.
If the dictated text contains CJK characters, force reliable paste for insertion.
What it is doing instead:
It is not just recommending Whisper.
It changes the actual returned selected model if macOS preferred languages contain Chinese.
So a user may have chosen Parakeet, but the app can silently behave as if Whisper is selected.
In onboarding, even if the user picks English only or Multiple languages, the code can still push Whisper first just because Chinese exists in macOS language preferences.
I am down foe the paste method etc and splitting different Chinese types. but recommending model seems too biased. Do you have any model on top of your mind for Chinese? I can try to add it actually. Qwen ASR or anything else? Thanks.
—
Reply to this email directly, view it on GitHub <#254 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWFHEXRUBEM444PHGMTNS5T4UGDYTAVCNFSM6AAAAACXMIZB32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBXHA2DMOJVHA>.
You are receiving this because you authored the thread.
|
2 participants
Summary
Notes