[selimfedakar]

Problem

EnglishNumberNormalizer builds its ordinal table by hand-coding the irregular forms (first, second, third, fifth, twelfth) and generating the rest with a generic rule:

name + ("h" if name.endswith("t") else "th")

For "nine" that rule produces the key "nineth" — but the real English ordinal is "ninth" (the e drops). So the table ends up with a bogus "nineth" entry and no "ninth", and real "ninth" input is left unconverted:

"twenty ninth"     -> "20 ninth"        (expected "29th")
"the ninth of May" -> "the ninth of may" (expected "the 9th of may")
"ninth grade"      -> "ninth grade"     (expected "9th grade")
"one hundred ninth"-> "100 ninth"       (expected "109th")

"nine" is the only single-word ordinal whose stem changes irregularly and is not already hand-coded, so it's the only one affected (tenth, fifth, eighth, … are fine).

Fix

Hand-code "ninth" alongside the other irregular ordinals and exclude 9 from the generic rule.

Verification

302 passed for the English number-normalizer suite (no regressions). Added regression tests:

• test_ninth_ordinal_normalizes — standalone normalizer: "ninth" -> "9th", "twenty ninth" -> "29th".
• test_ninth_ordinal_through_gladia_3_pipeline — parametrized through load_pipeline("gladia-3", "en"): ninth, twenty ninth, one hundred ninth.

Both fail on main and pass with the fix.

Note

This module is derived from OpenAI Whisper's EnglishNumberNormalizer, and the same nineth typo exists upstream — so it is a faithfully-inherited upstream bug rather than one introduced here, but it is a genuine, reproducible defect in this module with a safe, local fix. Happy to adjust framing if you'd prefer to track it against upstream.