Localised formatting must not change the underlying amount

How number localisation can alter appearance without altering the property value, and where bilingual products can accidentally turn formatting into a data error.

2026-09-21

This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.

A buyer should be able to switch language and recognise the same amount immediately, even when punctuation, spacing or currency placement changes. Localisation is supposed to make a number easier to read in a particular language context. It should not create a second value.

That sounds obvious until numbers begin crossing boundaries inside a product. A value is stored, formatted for one locale, copied into another component, exported, parsed again or used in a calculation. If a formatted string starts behaving like source data, punctuation that was meant only for presentation can become part of the number’s meaning.

Formatting is presentation; the amount is state

The clean mental model is to separate the numeric value from its display. A hypothetical amount of 1,250,000 currency units can be rendered with different grouping symbols, spacing and currency placement. The presentation belongs to the locale. The amount belongs to the property record or calculation.

Unicode CLDR exists precisely because number symbols and patterns vary by locale. Decimal separators, grouping separators and currency formats are presentation conventions. A product can therefore show different strings in Russian and English while still preserving one underlying amount.

The dangerous step is to take the already formatted string and treat it as though it were the canonical value. Imagine one component receives “1,250” from a display layer and another parser interprets the comma according to a different convention. The result may still look plausible. That makes number localisation failures harder to spot than a broken image or a missing heading.

Rounding creates a similar boundary. A page may reasonably show a rounded guide while the calculation retains more precision. The rounded output should not then become the new input for another language version or a later calculation. Presentation can discard detail for readability; source data should not silently inherit that loss.

Locale bugs often appear when values leave their original component

An isolated page can pass visual review and still fail once the value is reused. Property products routinely move numbers between cards, comparison tables, saved lists, calculators and exports. Each transition is an opportunity for the display representation to be mistaken for data.

Units make this more important. “85” means little on its own. It might be square metres, a floor number, a percentage, a count or a price component. A bilingual product may translate the unit label, but the measured quantity must remain stable. If one edition shows 85 square metres and the other effectively shows 8.5 or 850, the defect is not translation quality; it is data integrity.

Currency should also travel with the number. A symbol alone can be ambiguous outside its original context, especially when a buyer copies a value into a message or opens an exported document later. A clear currency code or unambiguous label helps the amount keep its meaning after it leaves the page.

This is why I prefer pairwise checks for material numeric fields. The question is not only “does the Russian number look Russian?” and “does the English number look English?” It is also “do both strings come from the same underlying value, unit and date?” That third question catches a different class of failure.

Pair tests should follow the buyer’s journey

A test starts with a property in one language, then switches language, adds the property to a comparison, changes the display context and exports or copies the value. The visible strings may change. The amount should not.

This is not a demand for identical prose or identical formatting. Independent language editions are a strength. The invariant is narrower: material numeric facts and calculation inputs should retain identity across the journey. If a price is a guide, it should remain a guide. If it is tied to a particular currency, that currency should not disappear. If a value was rounded for display, the product should know that it is displaying a rounded representation rather than redefining the source.

The same principle is useful when diagnosing a discrepancy reported by a user. Instead of asking only which language is “wrong,” trace the value back to its source and then forward through each formatting step. That keeps the investigation about data lineage rather than typography.

Copying and export provide a second localisation test

A well-rendered browser page does not prove that the amount survives outside it. Buyers paste prices into messages, save a shortlist, print a page or move information into another tool. The more a value travels, the more valuable its currency, unit and date context become.

An export is especially revealing because it freezes the display. If an amount was built from a formatted string instead of a stable numeric value, the file may preserve the wrong interpretation long after the web page has been corrected. Keeping a clear separation between stored value and locale presentation reduces that risk.

Good localisation is almost invisible. The buyer notices familiar punctuation and readable currency placement, while the product quietly preserves one amount underneath. When the two language editions start producing different economic meanings, the problem is no longer localisation. It is a broken data contract between representation and value.

Sources

• Unicode CLDR — Number and Currency Patterns; locale-specific grouping, decimal and currency presentation; accessed 6 October 2026.
• Unicode Technical Standard #35, Part 3: Numbers — locale number symbols and number-format patterns; accessed 6 October 2026.