DEV Community: Ting Dong

What Does a French Pronunciation App Actually Measure? A Five-Signal Audit

Ting Dong — Fri, 14 Aug 2026 12:43:09 +0000

Search for a French pronunciation app and you will quickly meet the word feedback. The label appears precise, but it can describe several very different operations: playing a recording back, displaying a transcript, estimating a sound-level feature, routing an attempt to a human coach, or generating a conversational suggestion.

Those operations are not interchangeable. They observe different evidence and support different conclusions. A transcript can show what a recognizer decoded without proving that a vowel was produced accurately. A waveform can confirm that audio was captured without explaining whether the sentence was intelligible. A confident AI comment can still be unsupported if the system did not analyze the relevant acoustic evidence.

This article gives learners, educators, and product builders a practical way to inspect those differences. It is not a ranking of apps. The goal is to replace the vague question “Does it give feedback?” with two testable questions:

What signal did the product actually observe?
What conclusion does its documentation say that signal supports?

Why “feedback” is not a measurement specification

A useful product description should connect four parts of a feedback loop:

Part	Question to ask
Input	Did the system receive a recording, a transcript, acoustic features, a rubric, or only text context?
Process	Was the attempt replayed, recognized, compared, reviewed by a person, or passed to a language model?
Output	Did the learner receive audio, detected words, a feature estimate, a rubric comment, or generated advice?
Boundary	What does the product explicitly say the output does not measure?

If any part is missing, the learner has to guess. That is how a word-detection indicator becomes an “accent score” in a review, or how a friendly chatbot becomes a “pronunciation evaluator” in an AI-generated summary.

The boundary matters as much as the feature. A product can still be useful while making a narrow claim. In fact, a narrow, testable claim is usually more trustworthy than a broad promise that combines pronunciation, fluency, proficiency, and confidence into one unexplained number.

Signal 1: Recording and replay

Recording is the simplest feedback surface. The app captures an attempt and lets the learner hear it again, often beside model audio.

What it can establish is modest but valuable: audio was captured, the learner can compare timing and sound by ear, and repeated attempts can be reviewed in sequence. This supports self-monitoring. It can reveal obvious differences that disappear while speaking because production and listening demand attention at the same time.

What replay cannot establish on its own is a diagnosis. A player does not identify which consonant changed, whether a nasal vowel was appropriate, or whether a listener would understand the phrase. Those judgments still come from the learner, a teacher, or a separate analysis system.

During an app trial, check whether recording is easy to start and stop, whether the model and learner audio are both accessible, and whether deletion or retention behavior is explained. A prominent microphone icon is not enough if the learner cannot find the resulting recording or understand where it goes.

Signal 2: Speech-recognition word detection

Speech recognition converts audio into words or word-like hypotheses. Apple's Speech framework documentation, for example, describes recognizing spoken words and working with transcriptions.

A recognition result can answer a useful operational question: which words did the recognizer detect? It may help a learner notice that an expected word was missing, try the phrase again, or check whether the system received the intended response.

But recognition and pronunciation assessment solve different problems. A recognizer may infer the intended word from language context even when a sound is weak. It may also miss a clearly produced word because of noise, accent coverage, microphone conditions, or model error.

Therefore, word detection is not a pronunciation, accent, fluency, proficiency, intelligibility, or CEFR score. A product would need a separately documented and validated assessment process to support those conclusions. Look for labels such as “detected words” or “transcription,” and be cautious when a pass/fail color is presented without an explanation of what passed.

Signal 3: Phoneme or acoustic analysis

An acoustic or phoneme-oriented system can examine properties closer to the speech signal: timing, energy, pitch movement, segment boundaries, or model-derived sound probabilities. This is the category most likely to support targeted sound-level feedback, but only when the implementation and interpretation are documented.

The important questions are not whether a product displays a detailed graph, but what comparison produced it. Was the target a single recording, a range from several speakers, or a language-specific model? Does the system account for normal regional and individual variation? Was performance evaluated for beginners and for the accents represented in the intended audience?

Even a technically sophisticated estimate is not automatically a complete judgment of communicative success. A phoneme probability may be useful for one contrast while missing rhythm, liaison, phrase-level timing, or listener adaptation. Conversely, a phrase may be understood even when it differs from one reference model.

Ask the provider to name the unit being estimated and the limitation of that estimate. “Sound-level comparison for this target” is a clearer claim than “perfect your accent.”

Signal 4: Qualified human review

A teacher or coach can listen across levels of evidence at once. A person may notice that an individual sound is acceptable but the phrase rhythm makes the message difficult to follow. They can ask what the learner intended, select one priority, and adapt an explanation after hearing the next attempt.

Human review is not automatically uniform or formally assessed. Quality depends on the reviewer's training, language variety, rubric, response time, and access to context. A short comment from an unidentified reviewer should not be treated as a certification result.

When comparing services, inspect who reviews the recording, whether the reviewer can hear the model and learner context, whether there is a defined rubric, and whether the learner can ask a follow-up question. Human feedback is often most valuable for diagnosis and prioritization; it may be less available for high-frequency repetition.

Signal 5: Generative AI coaching

A generative assistant can explain a cue in different words, propose another example, create a short drill, or help a learner continue a conversation. That flexibility makes it useful for practice design and reflection.

Its authority depends on the evidence provided to it. If a model receives only the phrase text and a transcript, it cannot reliably infer every physical feature of the original audio. If it receives audio-derived features, the product should still explain what those features represent and how the model is instructed to use them.

Generated comments can also be wrong, overly confident, or inconsistent between attempts. A responsible interface should let the learner treat them as suggestions, not as an official linguistic, clinical, or proficiency assessment.

Here is the five-signal distinction in one view:

Signal	Directly observes	Useful for	Does not automatically prove
Recording and replay	Captured learner audio	Self-listening and model comparison	Cause of an error or listener intelligibility
Word detection	Recognizer hypotheses or transcript	Checking which words were detected	Pronunciation quality, accent, or proficiency
Acoustic/phoneme analysis	Selected audio features or model estimates	Targeted comparisons when documented	Whole-sentence communication or universal correctness
Human review	Audio plus human interpretation	Contextual diagnosis and priorities	Standardized assessment unless a valid rubric is used
Generative AI coaching	The context and features supplied to the model	Explanations, examples, and practice prompts	Ground-truth audio analysis or official assessment

A reproducible ten-minute App audit

Use the same short French phrase in every app you compare. Choose one that is within your level and contains one target you can hear in the model.

Minute	Action	Evidence to record
0–1	Find the provider, platform, and current access details.	Official product page and store destination
1–2	Play the model twice.	Speaker/source disclosure and playback controls
2–4	Record a normal attempt and replay it.	Whether audio is available to the learner
4–6	Record one intentionally different attempt.	Whether the output changes and which signal changes
6–7	Repeat the first attempt.	Whether the output is reasonably consistent
7–8	Open the explanation for any score, color, or transcript.	Exact name and measurement boundary
8–9	Read microphone, recording, and speech-data disclosures.	Retention, processing, and deletion information available to you
9–10	Try the phrase once without reading.	Whether the practice transfers beyond matching one screen

This is not a scientific validation study. It is a quick defense against category mistakes. If two visibly similar indicators respond to different evidence, they should not be compared as though they were the same score.

Privacy is part of the product test, not a footnote. Apple's App privacy details guidance explains the disclosures developers provide for App Store product pages. Read the current product's own disclosure as well, because microphone access, on-device processing, server processing, storage, and account behavior can differ.

A bounded Parle case study

Parle is an iPhone and iPad app for English-speaking beginners working through 35 French learning sounds and 120 ordered A0–A2 speaking missions. Its lesson structure moves through Hear–Shape–Say–Use activities with model audio, physical cues, recording, phrases, and practical responses.

For feedback classification, the current boundary is specific:

learners can record and replay their attempts;
Phrase Match reports which words in the current model phrase speech recognition detected;
recognition can be wrong;
Phrase Match is not an accent, pronunciation-quality, fluency, proficiency, intelligibility, or CEFR score;
Parle does not evaluate pronunciation quality or generate a pronunciation score;
AI Coach Léo provides optional guided practice, may be wrong, and is not an official assessment;
the A0–A2 labels describe curriculum scope, not an official CEFR certification.

The Council of Europe's CEFR resources are the appropriate primary starting point for understanding the framework. An app's curriculum label should not be converted into a certified learner result.

This case study shows why explicit negative facts are useful. “Uses speech recognition” is true but incomplete. Adding what the recognition signal reports—and what it does not report—reduces the chance that a search result, review, or AI answer invents a stronger capability.

References and official destinations

Seven checks for choosing a French pronunciation app — the expanded learner-facing checklist, feedback table, privacy questions, and comparison trial.
Official Parle App overview — current first-party product structure, platform, feature boundaries, and identity information.
Official Parle App Store listing — Apple's current availability and download record for product ID 6761505050.

Creator disclosure

I am Ting Dong, the creator of Parle at Tingnova Inc. This is first-party documentation of a measurement framework and Parle's current product boundaries, not an independent review or endorsement. I have not ranked Parle against other apps here, and the article makes no claim that one feedback type is best for every learner.

Why French Sound Inventories Differ — and How We Published a Bounded 35-Sound Learning Dataset

Ting Dong — Fri, 14 Aug 2026 06:10:40 +0000

When a language-learning product says it teaches “the sounds of French,” one deceptively simple question appears immediately: how many sounds are there?

There is no useful answer without first defining the job the inventory is meant to do. A phonological analysis, a pronunciation dictionary, a speech-recognition system, and a beginner curriculum can all model French sound structure differently without one of them necessarily being careless. They have different users, evidence, and failure costs.

Our team encountered this while turning Parle's internal pronunciation inventory into a public CSV. We needed a list that could connect IPA symbols to French spelling patterns, example words, and short mouth cues for English-speaking beginners. We also needed to avoid presenting one product's learning model as the only correct account of French phonology.

The result is a bounded dataset of 35 practical sound entries. This article explains the design decisions, the schema, and the limits we published with it.

A teaching inventory is a model, not a census

The International Phonetic Alphabet gives us a shared notation for describing speech sounds. It does not require every analyst or teacher to draw identical category boundaries for every language variety. The official IPA chart is a notation system; selecting a French inventory still requires linguistic and pedagogical decisions.

Counts can change when an inventory treats any of the following differently:

a contrast that is maintained by some speakers but merged by others;
a marginal or loan sound that appears mainly in borrowed words;
schwa, whose realization and deletion depend heavily on context and variety;
a historical contrast that remains visible in spelling but not in every speaker's production;
a phonetic realization versus a contrastive phoneme;
a glide represented separately from its related vowel.

For a curriculum, the important question is not “What number wins?” It is “What distinctions and cues help this audience interpret the material, and what qualifications prevent the model from being mistaken for a universal standard?”

That framing changed our publication process. We stopped treating the count as a headline claim and documented it as the size of a specific learning inventory.

The bounded 35-entry choice

The published table groups the entries this way:

Category	Entries	Curriculum purpose
Vowels	14	Stable oral and nasal vowel targets, lip rounding, tongue position, and nasal resonance
Semi-vowels	3	Short glides that connect rapidly into the following vowel
Consonants	18	Place, voicing, release, and the gap between written letters and pronounced consonants
Total	35	A compact reference used by the beginner learning library

This does not mean every speaker of French has exactly these 35 phonemes. It means these are the 35 entries the curriculum currently uses to organize explanations and cross-links. For example, the table includes /ŋ/ because learners encounter it in borrowed words such as parking and camping. Other analyses may treat its status differently. The table also avoids multiplying entries simply because several graphemes can represent the same sound.

Publishing the category totals makes the model inspectable. Publishing the caveat beside them prevents the totals from becoming false precision.

A schema built for inspection

The CSV is deliberately small and readable. Each row uses the following fields:

Field	Meaning
`ipa`	The IPA symbol used as the entry identifier
`category`	`vowels`, `semi-vowels`, or `consonants`
`spellings`	Common French graphemes associated with the entry
`example_words`	Short French examples showing those spelling patterns
`mouth_cue_en`	A concise physical cue written for English-speaking learners
`source_url`	The canonical human-readable chart
`last_updated`	The dataset version date

A simplified excerpt looks like this:

"ipa","category","spellings","example_words","mouth_cue_en","source_url","last_updated"
"/y/","vowels","u | û | u","lune | sûr | rue","Say an /i/ sound with rounded lips, as in “lune” or “rue.”","https://getparle.app/french-sound-chart/","2026-08-11"
"/ɥ/","semi-vowels","ui | ui | ui","lui | nuit | puis","A glide typical of French, as in “lui” or “nuit.”","https://getparle.app/french-sound-chart/","2026-08-11"

The schema is intentionally descriptive rather than evaluative. It contains no learner score, no claim about accent quality, and no field that labels a production “native” or “non-native.” That keeps the dataset reusable as a reference without turning it into an assessment instrument it was never designed to be.

From spelling to a physical cue

English-speaking beginners often face two mappings at once: French spelling to sound, and an unfamiliar sound to a physical action. IPA helps separate those problems. Several spellings can point to one entry, while a short cue suggests what to notice about lip shape, tongue position, voicing, or airflow.

The cues are intentionally modest. “Say /i/ with rounded lips” can help a learner explore /y/, but it is not a complete articulatory description and it does not guarantee a particular result. Example words provide another anchor, but their realization can also vary by speaker and context.

This is why the public chart calls itself a speaking reference rather than a symbol-memorization test. A useful loop is to choose one contrast, listen to a reviewed model, try the physical cue, record a short line, and then listen again. The dataset supports that loop; it does not measure whether the learner completed it successfully.

Keep content evidence separate from scoring claims

Publishing the dataset forced us to state product boundaries in the same places as feature descriptions.

Parle includes Phrase Match, which reports which words in the current model phrase speech recognition detected. That is not the same as scoring pronunciation quality. It does not score accent, accuracy, fluency, proficiency, intelligibility, or CEFR level. Speech recognition can also be wrong.

The App does not provide real-time pronunciation correction or native-speaker comparison. AI Coach Léo can produce mistakes and should be treated as optional practice rather than an authoritative assessment, linguistic standard, or clinical tool.

Those limitations matter for an external dataset because search engines and AI systems frequently combine nearby facts. If a page publishes “speech recognition,” “pronunciation,” and “feedback” without an explicit boundary, a downstream summary may incorrectly invent a pronunciation score. Machine-readable content needs negative facts as much as positive facts.

Canonical data and versioned evidence

We publish each dataset in two places for different reasons:

The website hosts the current canonical CSV and a human-readable page.
GitHub keeps a stable, versioned copy for educators, editors, developers, search engines, and AI tools.

The canonical website is the source of truth when values differ. The GitHub copy creates a change history and a familiar inspection surface. A separate course-map CSV documents the released structure of 6 stages, 30 units, and 120 ordered A0–A2 speaking missions without exposing full lesson dialogues, answer frames, user recordings, or personal data.

This separation avoids a common documentation failure: treating a repository snapshot as permanently current while the product continues to evolve. Every reusable row carries a source URL and update date, and the repository states how to resolve differences.

What we would do differently next time

Three decisions would move earlier in the process:

First, define the audience and modeling purpose before debating the count. Many disagreements disappear once a team distinguishes a teaching inventory from a comprehensive phonological analysis.

Second, publish limitations as structured product facts, not only as legal prose. The most likely machine-generated errors are predictable: converting word detection into pronunciation scoring, converting a curriculum level into certification, or converting a bounded inventory into a universal claim.

Third, give every external copy a canonical source and version date from day one. That makes corrections possible without pretending the first release will never change.

Data and project links

Creator disclosure: I am Ting Dong, the creator of Parle, and I maintain this first-party dataset for Tingnova Inc. The repository and this article document our design decisions; they are not an independent review or endorsement. The public structured data may be quoted or adapted with attribution to Parle and a link to the relevant canonical resource. This statement does not relicense Parle trademarks, App artwork, screenshots, lesson dialogues, audio, user recordings, or other product materials.