Dates, Numbers, Currencies and Units: Localizing the Details
Words are only part of localizing a page. The same digits mean different things in different places, so a perfectly translated page can still confuse readers if dates, numbers, prices and measurements are left in the source format. Use locale-aware formatting for display, state your currency and units clearly, and keep the underlying values unchanged.
Why this matters
Look at what MDN's documentation of the JavaScript internationalization API shows for the same date and number in different locales:
- Dates: US English uses month-day-year order (12/19/2012), British English uses day-month-year (19/12/2012), and Korean uses year-month-day (2012. 12. 19.). A date like 12/11/2012 is ambiguous without the locale.
- Numbers: German uses a comma as the decimal separator and a period for thousands (123.456,789) and a currency example of 123.456,79 €. India uses thousands, lakh and crore grouping (1,23,456.789).
So 1.234 can be one thousand two hundred thirty-four or a little over one, depending on the reader. These details are small, and they cause real errors in orders, bookings and instructions.
What to localize
| Detail | What can differ |
|---|---|
| Dates | Order (day, month, year), separators, month and weekday names, calendar |
| Times | 12 or 24 hour clock, time zone display |
| Numbers | Decimal and thousands separators, digit grouping, digits themselves in some scripts |
| Currency | Symbol, symbol position, spacing, decimal places, which currency you charge |
| Units | Metric or imperial, paper sizes, clothing and shoe sizes |
| Phone numbers and addresses | Country code display, address line order, postcode formats |
| Names | Order of given and family names, honorifics |
| Text direction | Left to right or right to left (see our RTL guide) |
Rule 1: keep values neutral, format at display time
Store dates as unambiguous values (an ISO date, a timestamp), numbers as plain numbers and prices as an amount plus a currency code. Format them when you show them, for the visitor's locale. Do not translate formatted strings stored in the database, or you will end up translating 3,50 € into 3.50 € by accident.
Rule 2: use locale-aware functions, not hand-built strings
In JavaScript, Intl.DateTimeFormat and Intl.NumberFormat format values for a locale, taking a locales argument; MDN advises specifying the language (and possible fallbacks) explicitly so the right format is used. Most server platforms and CMSs have equivalents. Build with these instead of concatenating strings, and pass the same language tag your page uses; the W3C advises keeping language tags as short as possible and adding a region only when it matters, as with pt-BR versus pt-PT. See language and region codes.
Rule 3: be explicit about money
- State the currency at least once: a bare
$can mean several currencies. - Charge what you show. If you display local prices, make sure checkout charges the same amount. If you only convert for information, say it is an estimate.
- Taxes and shipping. Customers in many countries expect tax-inclusive prices; decide per market and say which you show.
- Rounding and decimals. Some currencies have no minor unit; let the formatter decide.
Prices, tax and shipping lines belong to the high-risk text discussed in translating checkout and forms. We do not state tax rules here; they vary by country and change, so check them for your markets.
Rule 4: units and sizes need real conversion
Changing the word "inches" to "pouces" does not convert 12 inches to centimetres. Either store measurements in a base unit and convert for display, or provide both. For clothing and shoes, sizing systems differ, and a size chart is safer than a silent conversion. This is general practice and not something we can cite to a standard.
Rule 5: leave formats alone inside protected text
Product codes, model numbers, phone numbers in contact blocks and code samples should stay exactly as written. Mark them as do-not-translate (in HTML, translate="no") so neither a machine nor a reviewer rewrites them.
What a translation tool can and cannot do
Most website translation tools change text, not values. LgTranslate's quality checks flag one related problem: a number that appears in the source but is missing from the translation (the numbers-changed warning). It does not convert currency or units, and it treats text such as {price} as a variable it keeps as it is. Handle conversion and formatting in your platform or theme, then let translation take care of the words around them.
Quick audit
- Open a translated page that shows a date, a price, a measurement and a number over a thousand.
- Ask a native reader whether each looks natural and unambiguous.
- Check the checkout summary and the confirmation email, which often use a different template.
- Switch language back and forth: does the format follow the language, and does the value stay the same?
- Note what your platform does not format and add it to a fix list.
Next step
Pick one translated page with a price and a date and run the audit above today. If you use LgTranslate, review those strings in the editor, mark codes and brand text as do-not-translate, and add anything the checks flag to your review list.
Key takeaways
- Translation changes words, not values or formats; localize formats separately.
- Store neutral values and format at display time with locale-aware functions.
- State your currency, and charge what you show.
- Convert units properly or show both, and protect codes and phone numbers from translation.
Sources
- Intl.DateTimeFormat – MDN Web Docs – locale-dependent date order (checked 2026-11-06)
- Intl.NumberFormat – MDN Web Docs – locale-dependent number and currency formatting, the locales argument (checked 2026-11-06)
- Choosing a language tag – W3C Internationalization – keep tags short, add region only when useful (checked 2026-11-06)
- translate global attribute – MDN Web Docs – keeping text out of translation (checked 2026-11-06)
Frequently asked questions
Does translating the text also convert dates, prices and units?
Usually not. Translation changes words; formats and values are a separate step. A translated page can still show a date in the source format, a price in the wrong currency or inches to people who use centimetres.
Should I convert prices to local currency automatically?
Only if you can charge in that currency or clearly state that the figure is an estimate. Showing a converted price that you will not honour at checkout damages trust. Decide your currency policy first, then format.
How do I format numbers correctly in code?
Use the browser or platform's locale-aware functions, such as JavaScript's Intl.NumberFormat and Intl.DateTimeFormat, instead of building strings by hand.