How People Translate Quickly | Locale Numbering Systems and Digit Shaping QA: Show Digits, Separators and Signs the Way Each Locale Expects Without Changing Numeric Value

People searching numbering systems localization, digit shaping, Arabic-Indic digits, locale number formatting, native digits, CLDR numbering systems, localized digits, or how to show numbers correctly in different languages are trying to solve a problem that ordinary translation does not solve. The underlying numeric value can be perfectly correct while the visible representation is wrong for the locale. A product may show Latin digits where native digits are expected, use the wrong decimal or grouping separator, place minus signs or percent signs awkwardly, or format identifiers as ordinary numbers when they should remain unchanged.

Current CLDR guidance distinguishes default, native, and traditional numbering systems and supplies locale-specific number symbols and patterns. CLDR also distinguishes the digit set itself from the surrounding symbols and formatting rules. That is important because digit shaping is not simply “replace 0–9 with another ten glyphs.” The right representation depends on locale, product context, number type, user expectation, script, and whether the value is a mathematical quantity, identifier, date, phone number, account code, or formatted measurement.

This article has one dominant job: build a numbering-system and digit-shaping QA workflow that preserves the numeric value while displaying digits, separators, signs, and patterns appropriate to the requested locale. It does not replace number verification, which compares source and target values for missing or changed numbers. It does not replace locale-aware currency/date formatting. This page owns the representation layer: which digits are shown, which numbering system is selected, how symbols are rendered, where digit substitution is appropriate, and where it must never touch an identifier.

Quick answer

A reliable numbering-system QA workflow is:

1. determine the requested locale and the product’s supported numbering-system policy;
2. distinguish mathematical quantities from identifiers such as account numbers, phone numbers, SKUs, and version numbers;
3. use locale data rather than manual digit substitution;
4. verify the default numbering system for each locale;
5. support explicit numbering-system preferences where the product allows them;
6. check decimal, grouping, percent, plus/minus, exponent, and infinity symbols with the same locale data;
7. test negative, decimal, large, and zero values;
8. test RTL contexts where digits and signs interact with bidi rendering;
9. keep underlying numeric data typed as numbers until formatting time;
10. never translate or reshape protected identifiers merely because they contain digits.

The central rule is:

format numbers for the locale; preserve identifiers for the system that owns them.

What a numbering system is

A numbering system defines how numeric values are represented.

The most familiar is the Latin decimal system:

0123456789

CLDR uses the code:

latn

Other decimal digit sets include Arabic-Indic and other script-associated systems.

CLDR also recognizes algorithmic or traditional systems that do not behave like a simple ten-digit substitution.

This means a product should not treat “localized numbers” as one string-replacement table.

Default, native, and traditional are not always the same

CLDR distinguishes several concepts.

Default numbering system

The system normally used to display numbers in the locale.

Native numbering system

The system associated with the locale’s script.

Traditional numbering system

A traditional numeral system where one is relevant.

A locale can therefore have:

• Latin digits as default;
• script-specific digits as native.

The product should follow the intended convention rather than assuming “native script must always mean native digits.”

Step 1: identify the value type

Before applying digit shaping, ask:

What kind of numeric-looking value is this?

Possible types:

• quantity;
• price;
• percentage;
• measurement;
• phone number;
• account number;
• postal code;
• serial number;
• version;
• date component;
• time;
• IP address;
• model code.

Only some of these should follow ordinary numeric formatting.

Quantity versus identifier

Quantity:

12345.67

Meaning: a numeric value that can be:

• grouped;
• rounded;
• localized.

Identifier:

0012345

Meaning: a sequence of digits whose exact form matters.

If you group it as:

0,012,345

or drop leading zeros, you corrupt identity.

Numbering QA begins by classifying the data.

Worked example 1: invoice total

Underlying value:

12345.67

The locale formatter may produce different visible forms:

• different grouping separator;
• different decimal separator;
• possibly different digit set.

The underlying numeric value remains 12345.67.

That is proper localization.

Worked example 2: account number

Account:

001234567

Do not:

• insert grouping separators;
• round;
• convert to another value;
• drop zeros.

Whether digit shaping is allowed depends on the system’s operational requirements. In many products, technical identifiers remain in Latin digits even inside a locale that uses another default numbering system.

Treat the identifier policy separately from numeric formatting.

Step 2: do not translate numbers as strings if the application can format them

Weak architecture:

source message contains:

1,234.56

Translator manually changes punctuation.

Better:

runtime stores numeric value:

1234.56

Formatter uses target locale.

Then translator works with:

• placeholder;
• full sentence.

This avoids inconsistent punctuation across thousands of messages.

Step 3: use CLDR-backed formatters

Modern internationalization libraries generally use CLDR or compatible locale data.

Use:

• ICU;
• platform number formatter;
• framework i18n API.

These already understand:

• digit set;
• decimal separator;
• grouping separator;
• percent pattern;
• sign placement;
• currency patterns.

Do not rebuild locale rules in spreadsheets.

Step 4: understand digit shaping

Digit shaping is the process of displaying a numeric value with the digit characters expected for the chosen numbering system.

Conceptually:

Latin: 123

Another decimal system: corresponding three digit glyphs.

The numeric magnitude does not change.

Only representation changes.

Digit shaping is not translation

The translator should not manually rewrite: 123 into another set of Unicode digit characters in every sentence.

That creates:

• inconsistent digits;
• search differences;
• copy/paste surprises;
• formatting bugs.

Use the formatter.

Step 5: decide whether the user can choose the numbering system

Some applications let users choose:

• locale;
• numbering system separately.

Unicode locale extensions can express such preferences in some environments.

If the product exposes this choice:

• persist it;
• format consistently.

Do not make the translation strings carry the preference.

It belongs to locale/configuration data.

Step 6: verify default numbering systems

Test representative locales.

Do not assume:

• Arabic language → Arabic-Indic digits always;
• Hindi → Devanagari digits always;
• Tamil → Tamil digits always.

Actual default usage can favor Latin digits depending on locale and platform convention.

Use current locale data.

Step 7: verify number symbols

Digits are only part of the picture.

Also test:

• decimal separator;
• grouping separator;
• plus sign;
• minus sign;
• percent sign;
• per-mille sign;
• exponential separator;
• infinity;
• NaN display if user-facing.

A product with correct native digits but wrong separators is still poorly localized.

Step 8: grouping separators vary

English commonly displays:

12,345.67

Other locales may use:

• period;
• space;
• narrow nonbreaking space;
• apostrophe;
• different grouping sizes.

Do not treat comma as “thousands separator” in source strings.

It is a locale-specific symbol.

Minimum grouping can vary

Some locale conventions suppress grouping for four-digit values but use it for larger values.

CLDR contains data for minimum grouping behavior.

Test:

• 999;
• 1,000;
• 9,999;
• 10,000;
• 100,000.

Do not assume one grouping threshold.

Step 9: decimals

Test:

• 0.5;
• 1.5;
• 1234.5;
• trailing zeros if fixed precision;
• high precision.

The decimal symbol can differ.

A translated help article that says:

enter 1.5

may need a locale-aware example.

If the value is a literal configuration syntax that requires a dot, do not localize it.

Context again matters.

Step 10: percentages

A percentage has:

• numeric value;
• percent sign;
• spacing;
• sign position.

Different locales can place the symbol differently or require a space.

Use percent formatting.

Do not concatenate: number + "%".

Step 11: negative numbers

Test:

• -5;
• accounting negative;
• negative percentage;
• negative currency.

Minus sign placement can interact with:

• currency;
• RTL text;
• digit shaping.

A generic string prefix is fragile.

Use the number/currency formatter.

Step 12: plus signs

Some products display: +5%

for growth.

The plus sign belongs to the formatted value.

Test:

• LTR;
• RTL;
• native digits.

Do not assume the sign will visually remain on the same side under bidi.

Step 13: currency values

Currency formatting combines:

• number system;
• decimal/grouping symbols;
• currency symbol/code;
• spacing;
• sign placement.

Underlying amount should remain numeric.

Currency identity should remain explicit.

The translator should not manually decide where USD belongs in every string.

Step 14: measurements

A value such as:

15 km

has:

• number;
• unit.

The number follows locale formatting.

The unit display may follow CLDR unit patterns.

Do not independently translate:

• number;
• unit;
• spacing

unless the architecture requires it.

A formatter can often handle the complete measure.

Step 15: phone numbers are not ordinary quantities

A phone number is a structured identifier.

Do not:

• add numeric grouping according to ordinary number formatting;
• convert plus sign into a localized sign;
• round;
• remove leading zeros.

Phone formatting should follow telephony conventions, not generic decimal formatting.

Digit shaping may also be constrained by interoperability and user expectations.

Step 16: postal codes

Postal codes may contain:

• digits;
• letters;
• leading zeros.

Treat them as identifiers.

Do not apply decimal grouping.

Do not translate letters.

Preserve exact operational identity.

Step 17: versions

2.10.4

is not a decimal number.

If a number formatter sees it as a number, it can destroy the version.

Protect:

• dots;
• leading zeros;
• segment order.

A version is structured text.

Step 18: IP addresses

192.168.0.1

is not a localized decimal.

Do not change digit set or punctuation unless the networking system explicitly supports it.

Technical documentation should preserve exact syntax.

Step 19: percentages in source examples

A teaching page may include:

12.5%

If the example is conceptual: localize display.

If it is literal code: preserve syntax.

Article writers should mark code examples clearly so the translation pipeline knows which layer owns formatting.

Step 20: dates are related but separate

Dates contain digits but are not ordinary decimal numbers.

Use:

• date formatter;
• calendar rules.

Do not pass a date through a generic number formatter.

Numbering-system preferences may still affect visible digits.

The date formatter should handle that integration.

Step 21: time

Time can contain:

• digits;
• colon;
• day-period marker.

Use locale-aware time formatting.

Do not localize each part manually.

Step 22: scientific notation

Scientific/engineering content can display:

• exponent;
• plus/minus;
• decimal.

Some notation is standardized.

Some display is locale-aware.

Define whether the value is:

• human-readable localized number;
• literal machine notation.

Do not blur them.

Step 23: mathematical formulas

Formula: x = 1.25

may be intended as formal mathematical notation.

A localized textbook might use locale decimal conventions in prose but preserve certain formulas.

Domain style decides.

Numbering QA needs content type.

Step 24: IDs in screenshots

A screenshot can show:

• order ID;
• price.

The price should format to locale.

The order ID should remain exact.

Visual review should distinguish them.

This is why “make all digits native” is not a valid localization instruction.

Step 25: RTL contexts

Arabic and Hebrew interfaces add bidi complexity.

A formatted number can contain:

• digits;
• sign;
• currency code.

The entire formatted number should usually be treated as one coherent run.

Test:

• sign position;
• currency position;
• punctuation;
• surrounding RTL sentence.

Number formatting and bidi QA intersect.

Step 26: user input

Display formatting is one side.

Input is another.

A user may type:

• Latin digits;
• native digits.

Decide:

• what forms are accepted;
• how input is normalized;
• what is displayed back.

Do not force users to change keyboards unnecessarily.

Step 27: parse under the right locale

String: 1,234

can mean:

• one thousand two hundred thirty-four;
• one point two three four

depending on locale.

Never parse a localized numeric string using the wrong locale.

This is a data-integrity issue.

Step 28: display and storage should be separate

Store: numeric value.

Display: localized formatted string.

Do not store: 1.234,56

as the canonical numeric representation unless the database schema explicitly stores localized text.

Separation keeps calculation reliable.

Step 29: round trips

For editable numeric fields:

1. numeric value;
2. locale format;
3. user edits;
4. locale parse;
5. numeric value.

Test that the round trip preserves value.

A display that looks correct but parses wrongly is dangerous.

Step 30: copy and paste

Users may copy a localized number into:

• spreadsheet;
• email;
• another app.

Consider whether native digits and separators will be understood downstream.

Product requirements may choose:

• locale-native display;
• Latin digit display for interoperability.

There is no universal rule.

Failure mode 1: replace 0–9 manually

Result: inconsistent digit shaping.

Repair: locale formatter.

Failure mode 2: apply number formatting to identifiers

Result: account/version/postal code corrupted.

Repair: data-type classification.

Failure mode 3: assume native equals default

Result: unexpected digit set.

Repair: current locale data.

Failure mode 4: localize decimal syntax inside code

Result: example no longer executes.

Repair: protect literals.

Failure mode 5: concatenate percent sign

Result: wrong spacing/order.

Repair: percent formatter.

Failure mode 6: format before passing to locale system

Result: source punctuation frozen.

Repair: typed numeric value.

Failure mode 7: test only positive integers

Result: negative, decimal, grouping bugs escape.

Repair: edge-value matrix.

Failure mode 8: ignore RTL

Result: sign/currency ordering looks wrong.

Repair: bidi-aware runtime testing.

Failure mode 9: parse with source locale

Result: numeric value changes.

Repair: target locale parser.

Failure mode 10: count digits as identity proof

Result: visually localized account number becomes operationally different.

Repair: protect identifiers.

A number-type decision table

Value	Locale format?	Preserve identity?
quantity	yes	numeric value
price	yes	amount + currency
percentage	yes	numeric value
measurement	yes	value + unit
phone	special formatter	yes
postal code	no generic number format	yes
version	no	yes
IP address	no	yes
account ID	usually no generic number format	yes

This table prevents many category errors.

Build a numeric-format test matrix

A mature localization program should not rely on one happy-path example.

For every supported locale, test:

• zero;
• one;
• negative one;
• 0.5;
• 1.5;
• 999;
• 1,000;
• 9,999;
• 10,000;
• 1,000,000;
• percentage;
• currency;
• measurement.

This quickly exposes:

• grouping;
• decimal;
• sign;
• digit-set;
• spacing;
• bidi issues.

The same fixture can run after a CLDR, ICU, framework, or platform update.

Numbering-system preference is a user setting in some products

A locale can imply a default numbering system.

That does not mean every user wants it.

Some users prefer:

• Latin digits;
• native digits;
• traditional numerals.

If the product exposes a numbering-system setting:

• store it independently;
• apply it consistently across the product;
• avoid hard-coding digits inside translated strings.

The translation should not need to change when the user changes digit preference.

Unicode locale extensions

Some internationalization libraries support locale identifiers with Unicode locale extensions that can request a numbering system.

The implementation detail varies by platform.

The architectural lesson is more important:

numbering-system choice belongs to locale configuration, not to translated prose.

This keeps rendering systematic.

Do not store shaped digits in translation memory for dynamic quantities

If a translator manually converts digits inside dynamic examples, the TM can preserve one particular representation even when the runtime locale should choose another.

A dynamic number should be:

• placeholder;
• formatted at runtime.

Static examples can be localized when pedagogically useful.

Separate dynamic data from literal examples.

Static examples still need policy

Documentation often contains literal numbers.

Example:

Enter 1,234.5 in the Amount field.

Should the target use local formatting?

Usually yes if:

• the product UI accepts localized input;
• the example is for human understanding.

Maybe no if:

• the field syntax requires ASCII machine input.

The translator needs to know which kind of example it is.

Context notes help.

Numeric examples and screenshots

A screenshot may show source-locale numbers.

If the product localizes numbers at runtime, the screenshot can become misleading.

Options:

• localize screenshot;
• use neutral cropped image;
• add note.

Do not change the text translation to match an outdated screenshot.

The runtime product should be the authority.

Numbering systems and search

A user may search for:

• 123;
• equivalent native digits.

Should both match?

That is a product-search decision.

Search normalization can map digit systems for lookup while preserving the displayed query.

Do not assume display choice must also control search equality.

Numbering systems and analytics

Analytics should normally store canonical numeric values.

Do not group:

١٢٣

and:

123

as different business values merely because display differs.

The display layer should not leak into metrics.

For string-based analytics labels, normalize under a documented policy.

Numbering systems and database queries

A numeric database column stores:

• numeric value.

A text identifier column stores:

• exact identifier.

Do not convert between them casually.

If a product receives native digits in a numeric input field:

• parse them under locale;
• convert to numeric value.

If the field is an identifier:

• preserve according to identifier policy.

Digit shaping and validation messages

Suppose a target form displays native digits but an error says:

Use digits 0–9.

That can confuse users.

Error copy should match the accepted input policy.

If both Latin and native digits are accepted, say so only if necessary.

If only Latin digits are accepted because of a technical standard, explain the constraint.

Digit shaping and passwords/PINs

A PIN can look numeric but behave as an identifier.

Whether native digits are accepted depends on:

• authentication backend;
• keyboard;
• security design.

Do not change PIN digits during display unless the product intentionally does so.

Security fields need exact behavior.

Credit-card numbers

Card numbers are identifiers.

Display grouping often uses fixed conventions.

Do not run them through a general locale number formatter.

Preserve:

• digit sequence;
• grouping policy;
• masking.

A locale may change surrounding prose, not the card number identity.

IBAN and financial references

These can contain letters and digits.

They are not localized numbers.

Treat them as structured identifiers.

Confusing them with numeric values can create severe payment errors.

Order numbers

Order IDs may be all digits.

They still behave as identifiers.

Leading zeros and exact sequence matter.

A support UI may choose to display Latin digits regardless of target numbering system for operational consistency.

That is a legitimate product policy.

Years

A year is semantically numeric but often follows date conventions.

CLDR date formatting handles the visible representation.

Do not use ordinary grouping:

• 2,026 is not a year format.

Special categories need the correct formatter.

Page numbers

Page numbers may be localized or remain Latin depending on publication style.

A print layout may use:

• target numbering system;
• Roman numerals;
• fixed Arabic numerals.

Document design controls this.

The translator should not manually substitute page-number fields.

Section numbering

Section numbers can be:

• decimal;
• Roman;
• alphabetic;
• locale-specific.

If numbering is generated: use the document system.

If the number is part of a source string: identify whether it is literal or generated.

Translation should not accidentally renumber structural references.

Footnotes

Footnote markers can follow:

• digits;
• symbols;
• letters.

The layout engine should manage them.

Do not localize markers independently from references.

Lists

Ordered lists can use:

• 1, 2, 3;
• localized digits;
• letters;
• Roman numerals.

Web/CSS/document frameworks may handle marker styles.

The translation should preserve list structure.

Do not type localized numbering manually unless the format requires it.

Numbering systems and pagination controls

A UI may show:

Page 1 of 10

The words translate.

The numbers should be locale-formatted if product policy says so.

Use one message with numeric placeholders.

This also allows target grammar to reorder:

10 pages total, page 1.

Numbering systems and charts

Charts show:

• axis values;
• data labels;
• percentages;
• currencies.

Use locale-aware number formatters.

Avoid pre-rendering English-formatted labels into the data source.

A chart can be visually correct yet numerically confusing if separators use the source locale.

Numbering systems and tables

Tables should align:

• decimal values;
• percentages;
• currency.

Locale changes may alter character width.

Test:

• column fit;
• decimal alignment;
• RTL.

A narrow column designed for 1,234.56 may behave differently with other digits and spacing.

Numbering systems and font coverage

If the selected font lacks the requested digit glyphs, the product may show:

• tofu;
• fallback font;
• inconsistent metrics.

Font glyph QA and numbering-system QA interact.

A correct formatter still needs a font that can render the output.

Numbering systems and Unicode normalization

Digit characters are distinct code points.

Normalization is not a digit-shaping mechanism.

Do not expect NFC/NFD to convert Latin digits into Arabic-Indic digits.

Number-system selection belongs to formatting.

Numbering systems and casefold/search normalization

A search normalization pipeline may decide to map digit sets to a common numeric form.

That can be useful.

Keep it separate from display.

Users should see:

• their query;
• localized result.

The search index can use a canonical internal representation.

Numbering systems and OCR

OCR can return:

• native digit;
• Latin digit;
• similar symbol.

For numeric quantities: parse with locale awareness.

For identifiers: verify exact source.

Do not silently convert OCR output before deciding the data type.

Numbering systems and MT

Machine translation may copy numeric strings.

That is often correct.

But MT usually should not be responsible for locale number formatting.

Post-processing or runtime formatting should handle:

• separators;
• currency;
• unit patterns.

This division reduces inconsistent output.

Numbering systems and CAT tools

CAT editors display source numbers as text.

Translators may feel pressure to “localize” every number manually.

Project instructions should distinguish:

Static human-readable number

May need locale adaptation.

Runtime placeholder

Do not edit.

Protected identifier

Preserve exact.

Formula/code

Preserve syntax.

This classification is more useful than “numbers are nontranslatable.”

A translator decision tree

You see a numeric string.

Is it a placeholder or runtime value?

Yes: preserve token.

Is it an identifier?

Yes: preserve exact structure.

Is it a literal human-readable quantity?

Yes: follow target-locale formatting or project style.

Is it code/formula?

Yes: preserve required syntax.

This prevents over-editing.

A developer decision tree

You have a number to display.

Does it represent quantity?

Use locale-aware number formatter.

Currency?

Use currency formatter.

Percentage?

Use percent formatter.

Date/time?

Use date/time formatter.

Identifier?

Use identifier formatting, not numeric formatting.

The code should know the semantic type.

QA by semantic type

A high-quality QA report can say:

12345.67 appears in prose as a raw source-formatted decimal.

That is more actionable than:

number changed.

Number verification and number formatting checks should be separate.

One protects value.

One protects representation.

Test native digits in input components

Display and input can diverge.

A native-digit locale may display:

• native digits

but numeric keyboard returns:

• Latin digits.

Test real devices.

The system should accept what users can type.

Do not design from desktop screenshots alone.

Test screen readers

Assistive technology may pronounce:

• digits;
• separators;
• currency

according to language and formatting.

A number that looks right can sound wrong if:

• language metadata;
• symbol placement

is incorrect.

High-value financial and accessibility surfaces deserve spoken testing.

Test copy as plain text

Copy a localized number.

Paste into:

• spreadsheet;
• plain text;
• calculator if appropriate.

This reveals:

• nonbreaking spaces;
• digit set;
• separators.

The product can decide whether interoperability meets user expectations.

Build a locale-number fixture page

Display:

• 0;
• 1;
• -1;
• 1.5;
• 1234.5;
• 10000;
• 25%;
• currency;
• measurement;
• phone;
• account ID.

One screen helps engineers and linguists see which values are:

• locale-formatted;
• identifier-preserved.

Use it after locale-data upgrades.

CLDR updates can change behavior

Locale data evolves with common usage and standards.

A framework or ICU upgrade can change:

• symbol;
• grouping;
• pattern.

This is not necessarily a regression.

Compare against current CLDR and product requirements.

Version the locale-data dependency where reproducibility matters.

Do not hard-code CLDR output into translation strings

If CLDR changes a pattern: the application should benefit automatically.

Hard-coded localized number strings freeze old conventions.

Keep locale data in the formatting layer.

A numbering-system governance card

For each market:

Default digits: platform/CLDR default. User override: yes/no. Technical IDs: Latin/exact. Phone: telephony formatter. Currency: locale formatter. Dates: locale formatter. Input: accepted digit systems. Search: digit normalization policy.

This is enough to prevent many inconsistencies.

Failure mode 11: locale choice changes display but not input parser

Result: users see one format but must type another.

Repair: align input policy.

Failure mode 12: native digits applied to API payload

Result: backend rejects value.

Repair: canonical data representation.

Failure mode 13: identifier is parsed as number

Result: leading zeros disappear.

Repair: string/identifier type.

Failure mode 14: support agent cannot search localized order ID

Result: operational friction.

Repair: keep ID canonical or normalize search.

Failure mode 15: test environment uses fallback font

Result: digit layout differs from production.

Repair: real font in QA.

A release checklist

For each target locale:

• correct default numbering system?
• separators correct?
• grouping correct?
• negative sign correct?
• percent correct?
• currency correct?
• identifiers preserved?
• date/time handled by dedicated formatter?
• RTL tested?
• input parser accepts intended digits?
• font renders all digits?
• fallback behavior known?

Search-intent transfer

People searching:

• “numbering systems localization”
• “digit shaping”
• “Arabic-Indic digits”
• “locale number formatting”
• “native digits”
• “CLDR numbering systems”

need one operational answer:

keep numeric values canonical, choose the appropriate locale numbering system for display, format symbols with locale data, and keep identifiers out of the generic number formatter.

That is the job this URL owns.

A twenty-minute audit

Pick four locales:

• one Latin-digit default;
• one locale with native non-Latin digits;
• one RTL locale;
• one regional variant.

Render:

• quantity;
• percentage;
• currency;
• account ID.

Compare.

This quickly shows whether the product:

• formats data semantically;
• or merely copies source punctuation.

The deeper principle: value and representation are different

The number: 1234.5

is a value.

Its visible form can vary.

An account ID: 0012345

is not a value in the same sense.

Its characters are identity.

Localization gets faster and safer when software knows the difference.

Why this improves speed

Without semantic formatting, translators repeatedly:

• change punctuation;
• change spacing;
• debate digits;
• correct inconsistent numbers.

With locale-aware formatting:

• one formatter handles the pattern across the product.

The translator reviews meaning.

The platform renders numbers.

Final operating model

classify value type → keep numeric values typed → choose locale + numbering system → format through CLDR-backed API → preserve identifiers → test edge values and RTL → validate input/output round trip

That architecture scales.

Build formatter ownership into the product architecture

A recurring source of inconsistency is that every feature team formats numbers independently.

Checkout uses one library.

Analytics uses another.

Emails concatenate symbols manually.

The PDF generator stores preformatted strings.

The result is one product with four numeric dialects.

Assign clear ownership:

• one locale-data source;
• one approved number-formatting layer;
• documented exceptions for identifiers and machine syntax.

Shared formatting removes repeated translator intervention.

Test source examples separately from live runtime values

Documentation can contain both:

• literal examples written by an author;
• values injected at runtime.

These should not be treated the same.

A literal teaching example may need a localized representation so the reader sees the convention used in their market.

A runtime value should normally be formatted by software.

Mark the distinction in structured content or authoring guidance.

This prevents translators from manually editing placeholders and prevents developers from freezing source-locale examples into every market.

Number formatting and accessibility

Screen readers announce numbers through language and locale rules.

A number can look correct while being read awkwardly because:

• language metadata is wrong;
• currency symbol is detached;
• punctuation is interpreted under another locale.

For financial, medical, and other high-value surfaces, include spoken testing.

The goal is not only visual correctness.

The user must understand the number.

Number formatting and export files

CSV, spreadsheet, and machine-readable exports often require a stable canonical format rather than the user-interface locale format.

Do not assume the localized display string should be written into:

• APIs;
• CSV data columns;
• database exports.

A robust product separates:

display representation from machine interchange representation.

This is especially important for decimal separators because a comma can be both a decimal mark and a CSV delimiter.

Number formatting and parsing errors

A dangerous failure pattern is:

1. display number using target locale;
2. send the displayed string back to backend;
3. backend parses using source locale.

Example:

Display: 1,25

Backend expecting English decimal syntax can interpret it incorrectly or reject it.

Keep numeric state as a number internally.

Format only at the presentation boundary.

Parse user input with the user’s locale.

Numbering-system QA after framework upgrades

A new ICU, CLDR, browser, mobile OS, or framework release can update locale behavior.

Regression tests should capture:

• representative digits;
• separators;
• grouping;
• percent;
• currency;
• sign placement.

A changed output is not automatically wrong.

Compare it with the updated locale data and product requirements.

The important part is that the change is known rather than surprising.

One final implementation test

Pick one locale and switch its numbering-system preference without changing the translation strings.

If the product correctly updates:

• quantities;
• percentages;
• currency;
• date digits where applicable;

while preserving:

• account IDs;
• version numbers;
• phone identifiers

then the architecture has correctly separated numeric presentation from identity.

That is the design target.

A good numeric formatter should therefore make the common case invisible: translators see meaningful placeholders, users see familiar numbers, and technical identifiers remain untouched. The fewer manual number edits required in translation, the healthier the internationalization architecture becomes.

One final product rule

If the product cannot say whether a numeric-looking value is a quantity or an identifier, localization will eventually guess wrong. The durable fix is to encode that semantic type in the data model. Once the system knows what the value is, formatting becomes predictable: quantities are localized, identifiers are preserved, and translators stop making case-by-case decisions that software should already understand.

Summary

Locale numbering systems and digit shaping determine how numeric values appear across languages and regions. CLDR distinguishes default, native, and traditional numbering systems and supplies locale-specific number symbols and patterns.

The reliable workflow is:

classify quantity versus identifier → use locale data → format digits and symbols → preserve canonical data → test edge values, RTL, input, and copy/paste

Do not manually translate every digit.

Do not apply number formatting to identifiers.

Give the formatter the right semantic type.

Frequently asked questions

What is a numbering system?

A system used to represent numeric values, including the set of digits or algorithm used to display them.

What is digit shaping?

Displaying a numeric value using the digit characters associated with a chosen numbering system.

What is CLDR’s default numbering system?

The numbering system normally used for numbers in a locale.

Is the native numbering system always the default?

No. Some locales use Latin digits by default while also having a native script-associated numbering system.

Should translators manually change digits?

Usually not for runtime values. Use locale-aware formatters.

Should phone numbers be localized like quantities?

No. They are structured identifiers with their own formatting rules.

What about account numbers and postal codes?

Treat them as identifiers. Preserve leading zeros and exact sequence.

Do percentages need locale formatting?

Yes. Number symbols, spacing, and percent placement can vary.

How do numbering systems interact with RTL?

Signs, currency, punctuation, and digit runs can reorder visually, so test them with bidi-aware rendering.

Can users type Latin digits in a native-digit locale?

Many products allow it. Input policy should be explicit and tested.

Does Unicode normalization convert digit systems?

No. Numbering-system selection belongs to the formatting layer.

How does numbering-system QA improve translation speed?

It replaces repeated manual number editing with one consistent locale-aware formatting system.

Internal-link opportunities

• How People Translate Quickly | Number Verification: Compare Numbers, Dates, Percentages and Units Before They Become Silent Errors
• How People Translate Quickly | RTL and Bidirectional Text QA: Keep Arabic, Hebrew, Numbers, URLs and Punctuation in the Right Visual Order
• How People Translate Quickly | BCP 47 Language Tag Validation: Route Every Translation to the Right Language, Script, Region and Locale
• How People Translate Quickly | Font Glyph Coverage and Fallback QA: Prevent Missing Characters, Tofu Boxes and Mixed-Typeface Breakage Across Scripts
• How People Translate Quickly | ICU MessageFormat Plurals and Selects: Keep Dynamic Messages Grammatically Complete Across Languages
• How People Translate Quickly | Locale-Aware Collation and Sorting QA: Order Names, Files and Search Results the Way Target-Language Users Expect