How should dates, numbers and currencies be formatted in transcripts? First preserve the underlying spoken meaning, then apply a documented transcription style appropriate to the target locale. Use standards-based locale data such as Unicode CLDR/ICU for dynamic number, currency and date formatting rather than inventing conventions manually. For legal, research or verbatim transcripts, avoid changing ambiguous spoken values into a format that implies certainty not present in the audio.
| SEO title | Locale-Specific Transcription: Dates, Numbers, Currency & Conventions |
|---|---|
| Slug | locale-specific-transcription-dates-numbers-currency |
| Meta description | Learn how locale-specific transcription handles dates, numbers, currency, times, addresses and conventions while preserving spoken meaning. |
| Primary keyword | locale-specific transcription |
| Search intent | Informational / Technical |
| Hero image | 200-locale-specific-transcription-conventions.jpg |
| Hero alt text | Locale-specific transcript normalization interface showing dates, numbers, currency, time and address formats |
| Article body words | 1907 |
For production speech-to-text workflows, see our AI Transcription service for the delivery path behind the guidance in this article.
Speech transcription sits between what a person said and how readers expect written information to appear.
A speaker may say:
“twenty-four oh nine twenty-six”
The transcript could represent that as:
- 24/09/2026;
- 09/24/2026;
- 24 September 2026;
- the spoken words.
The correct choice depends on the transcription standard, audience and locale.
Locale-specific transcription therefore needs explicit rules for normalization.
CLDR provides locale-specific number symbols and currency patterns used by many internationalized software systems.
Transcription versus localization
A source-language transcript may preserve the speaker’s original convention.
A localized transcript may adapt display.
These are different deliverables.
Do not silently localize a legal transcript.
Numbers
Speech:
“one thousand five hundred point five”
Possible normalized:
1,500.5
But target locale may display:
1.500,5
The value must remain the same.
Decimal separators
Locales use:
- period;
- comma.
For software output, use locale formatter.
For source transcript, follow project style.
Thousands separators
Can be:
- comma;
- period;
- space.
A wrong separator can change interpretation.
Store underlying numeric value where possible.
Currency
Speech:
“twenty-five dollars.”
Transcript:
$25 or 25 dollars.
Which dollar?
Could be:
- USD;
- CAD;
- AUD.
Context matters.
Do not infer currency code without evidence.
Currency display
CLDR currency patterns define locale-sensitive placement and spacing around currency symbols.
Use them in localized applications.
For evidentiary transcript, preserve what speaker said.
Dates
Numeric dates are dangerous.
4/5/26
can mean:
- April 5;
- 4 May.
If speaker says:
“April fifth, twenty twenty-six”
you can safely normalize to unambiguous form.
If speaker says:
“four five twenty-six”
context may be ambiguous.
Mark or preserve.
ISO dates
2026-04-05
is machine-friendly.
But it may not be the best human transcript format.
Use ISO for metadata and localized form for display where appropriate.
Times
Speech:
“three thirty.”
Need:
- AM/PM?
- time zone?
Do not invent.
If speaker says:
“3:30 p.m. Eastern”
preserve zone.
Localized output may use:
15:30.
But legal transcript may retain spoken form.
Time zones
Meeting transcripts across regions should preserve time-zone context.
Do not convert time automatically unless deliverable requires.
A converted time is derived data.
Percentages
Speech:
“five point two percent.”
Normalize:
5.2%
if style permits.
Check decimal locale.
Phone numbers
Do not reformat if it risks changing digits.
For customer-facing localized records, international E.164-style storage can be separate from display.
Transcription goal:
- accurate number.
Addresses
Address conventions vary by country.
Spoken address should preserve:
- street;
- unit;
- postal.
Do not translate place names unless project policy requires.
For structured systems, parse after transcription.
Measurements
Speech:
“ten miles.”
Translation/localization could convert to kilometers.
Transcription should not convert unless requested.
Conversion changes representation/value unit.
Store source value.
Ordinals
Speech:
- “twenty-first.”
Transcript:
- 21st;
- words.
Style guide decides.
Some languages use different ordinal notation.
Years
Speech:
“twenty oh five.”
Normalize:
2005
if unambiguous.
Money ranges
Speech:
“between five and six thousand dollars.”
Do not output:
$5–$6,000
which can be ambiguous.
Use:
$5,000–$6,000
or spoken words according to style.
Fractions
Speech:
“one and a half.”
Could be:
1½; 1.5.
Context:
- measurement;
- age.
Choose style consistently.
Scientific numbers
Technical speech:
“one times ten to the minus six.”
Preserve mathematical meaning.
A specialized transcript may use:
1 × 10^-6.
Review.
Legal transcripts
Legal style often prioritizes fidelity.
Do not “localize” evidence.
If witness says dollars, keep dollars.
If date is ambiguous, preserve or flag.
The transcript is source representation, not conversion.
Research interviews
Researchers may want words as spoken.
Normalization can erase:
- speech behavior.
Define methodology.
Meeting notes
Clean transcript can normalize:
- dates;
- numbers.
This improves readability.
Store original audio.
ASR inverse text normalization
Speech systems often apply inverse text normalization (ITN):
spoken words → written forms.
Examples:
- “five dollars” → $5.
ITN is model/provider-specific.
Review important numbers.
Locale-aware ITN
The recognizer needs correct locale.
English US and English UK may interpret number/date conventions differently.
Set recognition locale accurately.
Dynamic system design
Best architecture stores:
- raw spoken transcript;
- normalized value;
- locale.
Then applications can display appropriately.
Do not destroy raw evidence.
CLDR
Unicode CLDR provides locale data used by:
- ICU;
- browsers;
- libraries.
It covers:
- number symbols;
- currency patterns;
- date formats.
Use these rather than maintaining manual locale tables.
ICU
ICU implements internationalization support using Unicode/CLDR.
Developers can format:
- numbers;
- dates;
- currencies
consistently across languages.
Quality checks
For transcripts, verify:
- digits against audio;
- currency;
- date;
- units;
- time.
Numbers deserve targeted review because ASR can be highly confident and wrong.
Automated number comparison
If creating localized transcript from source transcript:
- extract numeric values;
- compare after formatting.
Formatting can change characters but not value.
Language-specific number words
Some languages form numbers differently.
ASR needs:
- number grammar.
Do not apply English ITN rules universally.
Script-specific digits
Locales may use:
- Latin;
- Arabic-Indic.
Display choice can differ from spoken language.
Use locale policy.
Search and analytics
Normalized numeric values help search.
Store semantic fields separately.
Example:
- transcript display;
- parsed date ISO.
This supports both fidelity and computation.
A practical style-guide section
Define:
- integers;
- decimals;
- currency;
- dates;
- times;
- units;
- phone;
- addresses.
Include examples for each locale.
This prevents reviewer inconsistency.
Locale-specific number normalization configuration
A production system can store a normalization profile containing:
- decimal separator;
- date display;
- time convention;
- currency display;
- numeral system;
- unit policy;
- phone/address rules.
The ASR layer preserves semantic value; the display layer applies the profile.
This separates language recognition from localization.
Spoken ambiguity should survive normalization
If a witness says:
“It happened on five six.”
and context does not establish whether that means May 6, June 5 or something else, the transcript should not convert it to one date.
Use:
- spoken words;
- reviewer note;
- client clarification.
Normalization should never manufacture certainty.
Locale conversion versus factual conversion
Formatting:
- 1,500.50 → 1.500,50.
Unit conversion:
- miles → kilometers.
Currency conversion:
- USD → EUR.
The last two change the represented measurement/value and require a separate business rule. Do not bundle them into transcription “localization.”
Normalizing telephone and account numbers
For numbers that function as identifiers, preserving digits matters more than localized separators. Store a canonical value separately from display.
For phone:
- canonical E.164 where valid/known;
- transcript display reflects what was spoken.
Do not infer missing country codes automatically.
Dates in multilingual recordings
One speaker may use US month/day conventions and another use day/month. The recognition locale and speaker context can help, but explicit spoken month names are safer.
In legal or financial transcripts, prefer unambiguous written month forms when the style guide permits.
Time-zone normalization
If the transcript is converted into meeting notes, the application may show times in each reader’s zone. Keep the source spoken time and original time zone in metadata so conversions remain auditable.
A transcript should not silently replace “3 p.m. Eastern” with “10 p.m.” without explaining the transformation.
Searchable structured facts
Extract normalized facts into fields:
- amount;
- currency;
- date;
- unit.
Keep the transcript text intact. Search/analytics can use the structured fields while human readers see faithful language.
This is safer than trying to make one string serve both evidentiary and computational purposes.
Quality evaluation for ITN
Measure both:
- transcription lexical accuracy;
- semantic normalization accuracy.
A model that correctly hears “five dollars” but renders $50 has an ITN failure, not ordinary ASR failure. Separate error labels make engineering fixes clearer.
Locale-specific testing
Create test cases for every active locale:
- decimal;
- thousands;
- ambiguous date;
- 12/24-hour time;
- currency symbol position;
- negative amount;
- percentage;
- phone.
Run them after ASR/normalization changes.
Final principle
Locale-specific transcription should create readable local presentation without changing the facts that were spoken. Preserve raw evidence, normalize only when the meaning is clear and treat conversions as separate operations.
Locale-specific transcript templates
Organizations can create templates for different use cases:
US legal
- month-name dates where ambiguity exists;
- dollars as spoken;
- no currency conversion;
- source time zone retained.
EU business notes
- locale date/number format;
- 24-hour time;
- localized display.
Research verbatim
- spoken numbers preserved according to study guide;
- minimal normalization.
Templates make normalization policy repeatable.
Parsing after transcription
Do not force ASR to output every structured field perfectly. A downstream parser can identify:
- dates;
- money;
- phone numbers.
Then a validator checks the parsed value against the transcript.
This modular approach makes corrections easier than embedding all business logic inside the speech model.
Confidence for normalized values
Store a confidence or review flag separately for:
- lexical recognition;
- parsed value.
The word sequence can be clear while date interpretation is ambiguous.
Example:
“four five twenty-six”
Speech confidence high; date semantic confidence low.
Locale data should be versioned
CLDR releases change and applications update libraries. Store or record the library/version used for deterministic formatting where reproducibility matters.
For ordinary UI this may be unnecessary, but regulated reports can benefit from precise generation records.
Currency minor units
Some currencies use:
- two decimal places;
- zero;
- other conventions.
Use CLDR/financial rules rather than assuming every currency behaves like USD.
If the speaker gives an amount explicitly, preserve the value regardless of display convention.
Addresses and transliteration
An address may need:
- original script;
- romanized form;
- localized country name.
Postal delivery requirements differ from explanatory display. Define output purpose.
Numbers in subtitles
Subtitle normalization should favor fast readability while remaining faithful. Use digits for many numbers if the style guide permits, but check that long strings do not overwhelm cue width.
For spoken phone numbers, preserving grouping can improve readability.
Audit trail for derived normalization
If a final transcript displays a normalized date, keep the original spoken token sequence in metadata or raw transcript. This allows future verification.
Final QA example
For every normalized fact:
- listen/read source;
- confirm value;
- confirm locale formatting;
- confirm no unintended conversion;
- approve.
This is especially important for money, deadlines and identifiers.
Final principle
The safest multilingual transcript separates what was spoken, what value it represents and how that value is displayed for a locale. Once those layers are separated, localization becomes predictable without sacrificing source fidelity.
Frequently asked questions
Should transcripts convert spoken numbers to digits?
Often for clean/business transcripts, but verbatim/legal styles may preserve spoken form. Define policy.
Should currencies be converted?
No. Formatting may localize; currency conversion is a separate operation.
What if a date is ambiguous?
Preserve the ambiguity or flag it rather than inventing an interpretation.
What is CLDR?
Unicode’s Common Locale Data Repository provides locale conventions used by internationalized software.
What is inverse text normalization?
Converting spoken forms such as “twenty dollars” into written forms such as $20.
Conclusion
Locale-specific transcription is about balancing fidelity and readable written convention.
Preserve what the speaker meant, define normalization rules and use standards-based locale data for formatting. Treat dates, numbers, currency and addresses as structured information when downstream systems need them.
Most importantly, do not let “clean formatting” silently change the facts in the audio.
Research references
- Unicode CLDR number symbols:
- Unicode CLDR number and currency patterns:
- Unicode CLDR:
- ICU User Guide:
