Ambiguous date, number, and unit formats are among the most common localization errors in documentation. The format "05/06/26" means three different dates depending on the reader's locale. "1,000" means one thousand in English but one (with a decimal) in several European locales. These ambiguities cause real errors — users setting up the wrong date for a scheduled report, or entering data in the wrong unit.
This article covers the localization dimension of formatting. The underlying formatting rules — which separators to use, how to write dates, how to handle units — are defined in the Numbers, Dates, and Time guide. Follow those rules as your baseline. The guidance below covers what additionally changes or requires attention when content is translated or read internationally, and is the authoritative source for the localization-specific detail summarized in the Writing for Translation and Localization guide.
Dates
The standard formats defined in the Numbers, Dates, and Time guide — ISO 8601 (YYYY-MM-DD) for technical contexts, and "29 May 2026" for prose — are chosen precisely because they eliminate locale ambiguity. Use them consistently.
When content is translated, instruct translators to apply the locale-appropriate date format rather than carrying the English format through. Machine translation tools do not automatically reformat dates. Include explicit instructions in your translation brief.
Avoid relative date references ("last week," "recently") in content that will be translated. They become inaccurate as documentation ages and do not survive translation meaningfully. Use specific dates or describe timing in duration terms: "within 30 days."
Numbers and Currency
The English convention — comma as thousands separator, period as decimal — is reversed in many European and Latin American locales (1.000.000 and 3,14). Machine translation does not reformat numbers. When publishing to multilingual audiences:
- Do not assume your number format will be preserved in translated output. Flag number-heavy content for locale-appropriate reformatting by translators.
- Always specify the currency code alongside the symbol:
100." "$" is ambiguous internationally. - Use clearly fictional amounts in examples, labeled with the currency code.
Units of Measurement
Use SI (metric) units as your primary unit. Most of the world uses metric; US customary units are not internationally standard. Where your audience includes US readers, include the US equivalent in parentheses: "100 kilometres (62 miles)."
Define abbreviations on first use in every article: "100 megabytes (MB)." Do not assume readers in all locales will recognize the same abbreviations.
Time Zones
Time zones require special attention in international documentation. Always specify the time zone when referencing a specific time:
- 14:30 UTC
- 09:00 EST (UTC−5)
Avoid ambiguous abbreviations — "CST" refers to both Central Standard Time (UTC−6) and China Standard Time (UTC+8). Use a UTC offset or the IANA time zone name ("America/Chicago") when precision is required.
Telephone Numbers
Always include the country code when writing phone numbers in internationally distributed content, using the same international format specified in the Phone Numbers section of the Numbers, Dates, and Time guide: +1 (555) 123-4567. Use this format consistently for fictional examples across all documentation, rather than varying the punctuation or omitting the country code, so phone number formatting doesn't become its own source of inconsistency across the knowledge base.
Form Fields That Auto-Localize
Some UI elements — date pickers, number inputs, browser-native form controls — automatically adapt their display format to the reader's browser or operating system locale, without any documentation changes needed. This is a platform/UI behavior, not something you write around: don't add extra explanation of locale-specific formatting for a field that already localizes itself. Where you're unsure whether a specific field auto-localizes or displays a fixed format regardless of locale, confirm with whoever owns that part of the product before writing instructions that assume one behavior or the other.
Quick Reference
| Element | Standard | Localization note |
|---|---|---|
| Date (technical) | ISO 8601: YYYY-MM-DD | Unambiguous across all locales |
| Date (prose) | 29 May 2026 | Day-Month-Year avoids US/EU ambiguity |
| Time | 24-hour + time zone | Always include UTC offset or IANA name |
| Numbers | 1,000 / 3.14 (English) | Flag for reformatting in translated locales |
| Currency | $100 USD | Include ISO currency code; never assume symbol is universal |
| Units | SI primary; US customary in parentheses | Define abbreviations on first use per article |
| Phone numbers | +1 (555) 123-4567 | Always include country code; use one consistent format for fictional examples |
Self-Audit Checklist
Before publishing, check the article against these questions:
- Do all dates use ISO 8601 (technical) or the Day-Month-Year prose format, with no relative date references in translatable content?
- Has number-heavy content been flagged for locale-appropriate reformatting by translators?
- Does every currency value include an ISO currency code, not just a symbol?
- Are units given in SI/metric as primary, with US customary in parentheses where the audience includes US readers?
- Is every unit abbreviation defined on first use in the article?
- Does every specific time include a UTC offset or IANA time zone name, avoiding ambiguous abbreviations like "CST"?
- Do phone number examples use the single consistent international format specified across this knowledge base?
- For any auto-localizing form field, has the documentation avoided adding unnecessary locale-specific explanation?