uttrflow / uttrflow/uttrflow-swift

Dictation must always write Latin-script English or romanised Hinglish: never Devanagari, never a translation

Open
#730 0 comments 0 reactions 1 assignee Claimed by @naveen-bhatt View on GitHub
area:dictation bug P1
Dominant language
Swift
Stars
4
Forks
17
Avg merge
3h 32m
Merged PRs (30d)
277

Description

## Decision

Uttrflow writes English in the Latin alphabet, and nothing else. Hindi and Hinglish speech is written as romanised Hinglish, the way people type it in a chat: "haan thik hai", "main abhi aata hoon", "karna" (not "karanā"). It is never written in Devanagari, and it is never translated into English. Uttrflow is not a translator.

This applies to every piece of text dictation inserts or produces, whichever engine tidied it and whether or not any engine tidied it at all.

## What happens today

Romanising is left to the AI tidy (Apple's on-device model or a local model). Whenever that step is not taken, Devanagari reaches the screen, and when it is taken the answer is not checked for being a romanisation:

- **The rules path keeps Devanagari.** Apple's model declines most Hindi dictation as an unsupported language (#445), so most Hindi dictation is tidied by the rules and inserted in Devanagari. The same happens when no model is installed, when the model times out, or when the tidy fails and the words are inserted untidied.
- **An AI answer can be a translation or the prompt's own example** and the guard accepts both (#700, #196).
- **Recognition forces the wrong language.** The first piece's language is held for the whole dictation, so a Hindi sentence after an English one is decoded as English and comes back translated (#698). The Languages setting is never read, so short Hindi replies are decoded as English words (#699).
- Knock-on issues that exist only because Devanagari reaches the output: a doubled stop after "।" (#701), and a dictionary that cannot match Devanagari words (#709).

## What changes

1. **A deterministic romaniser** for Devanagari, used by the rules path, written the way people type: no diacritics, the inherent vowel dropped at word ends and in the usual medial positions, nasalisation written "n", and a table of common spellings (है hai, हाँ haan, ठीक thik, नहीं nahi, मैं main, क्या kya). Measured against the romanised references of the committed Hindi and Hinglish corpus passages.
2. **A final output guard** in the pipeline: text about to be inserted holds no Devanagari or other non-Latin letters. Anything left is romanised; Latin punctuation, digits and emoji are untouched.
3. **A translation guard** on the AI tidy: when the recogniser wrote Devanagari, a rewrite that does not match the romanised draft's words (a translation), a rewrite in another script, or a rewrite that repeats a worked example from the prompt is refused, and the deterministic romanised draft is used instead.
4. **Recognition** reads the Languages setting: when it includes Hindi, each piece detects its own language among the ticked ones instead of inheriting the first piece's, and a single ticked language is decoded as that language.

## Acceptance criteria

- No dictation path inserts Devanagari: rules, AI tidy, untidied fallback. Tests fail on today's code.
- The romaniser's table cases and its accuracy on the corpus are recorded in `Docs/`.
- A translated rewrite and a worked-example echo are refused and the romanised draft is kept.
- English dictation output is byte-identical to today's on the English corpus.
- The principle is stated in `AGENTS.md` and `Docs/cleanup.md`, and no doc says otherwise.

Related: #445, #698, #699, #700, #701, #703, #704, #709, #196.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.