Home News and articles01.02: Is It January 2 or February 1? Localization Traps That Cost Money

01.02: Is It January 2 or February 1? Localization Traps That Cost Money

A date string like "01.02.2025" means the start of February in one country and the start of January in another. If an online store or app displays such a date without accounting for the locale, customers may read it differently from what was intended. These details rarely make it into the technical specification, yet they are the source of returns, missed deadlines, and awkward customer support emails. Let's look at the most common localization traps and how to avoid them.

Dates and Time: One Day, Three Readings

The order of date components varies by country. In Russia, Germany, and most of Europe, the "day.month.year" format is standard. In the US, the month comes first, so "03/04/2025" there means March 4, not April 3. In Japan, China, and Korea, the order is reversed: year first, then month and day.

Time follows the same pattern. Russia, most of Europe, and Latin America are used to the 24-hour clock, while the US, Canada, Australia, and India widely use the 12-hour clock with AM and PM. A time written as "5:00" without a marker can be read differently in different countries, and a meeting set for "five" could end up twelve hours away from the intended time.

To avoid guesswork, use the ISO 8601 standard in data and APIs (for example, 2025-02-01T14:30). In the interface, display dates using locale-aware formatting rather than typing them manually.

Number Separators: Comma Where You Expect a Period

The number "1 500,75" in Russia and "1,500.75" in the US represent the same value. In Germany and Brazil, a period separates thousands and a comma marks the decimal part: "1.500,75". Switzerland uses an apostrophe: "1'500.75". In India, digit grouping is different: "1,00,000" means one hundred thousand.

This error is especially insidious. If a price of "1.500" was meant to be one thousand five hundred but the system read it as one and a half units, the customer would only notice the difference at checkout. That's why you should never concatenate number strings manually in code. Use locale-based formatting and verify number parsing when importing files.

Currencies: Symbol, Placement, and Rounding

The currency symbol seems minor, but it easily causes confusion. The "$" sign is used in the US, Canada, Australia, and several other countries, so without a currency code, "$" could mean dollars of any of them. This is why international contexts call for the three-letter code from the ISO 4217 standard: USD, EUR, RUB.

The placement of the symbol also varies. English-speaking countries write "$100", France uses "100 €" with a non-breaking space, and Russia uses "100 ₽" or "100 руб." Sometimes the problem shows up in translation: a phrase such as "price includes VAT" may require a different sentence structure in another language, and if text is assembled from fragments with an inserted amount, the word order can break.

Rounding also depends on the currency. The Japanese yen usually has no decimal places, while the Kuwaiti dinar is divided into thousandths. If a system calculates amounts with two decimal places for all currencies, the total may differ from the bank statement by a few cents, and in large volumes, by noticeable sums.

Metric and Imperial Systems

Most of the world uses the metric system, but the US uses feet, pounds, gallons, and degrees Fahrenheit. In the UK, road signs show miles, and milk is sold in pints, though a British pint is larger than an American one: about 568 milliliters versus roughly 473. The gallon also differs on either side of the Atlantic.

For an online store, this means product dimensions, parcel weight, and packaging volume should be displayed in units familiar to the customer, while preserving accuracy. A translator working with instructions must determine whether a unit should be translated or the value converted. For example, if a manual specifies "10 inches," a Russian edition would be better served by "25 cm," while keeping the original figure in parentheses if it matters for technical specifications.

Phone Numbers, Addresses, and Names in Forms

Registration forms most often break in three fields. Phone numbers: in Russia, a number may look like "+7 (999) 123-45-67," in Germany the length varies, and many templates with a rigid mask reject valid numbers. It is better to use a field with a country code selector and a library for phone number validation.

Addresses: in Japan, the order runs from largest to smallest unit (prefecture, city, district, block number), while in Russia and Europe it is the reverse. US postal codes consist of five digits, while UK postcodes are alphanumeric combinations. A field labeled "Postal code, digits only" excludes many real addresses.

Names: in Spain and Latin America, people often have two surnames, in Iceland a patronymic is used instead of a family name, and some people have only a single name. An apostrophe in a surname like "O'Brien" or a hyphen should not cause errors. The minimum requirement is simple: do not make two fields mandatory where it isn't necessary, and accept any Unicode characters.

How to Avoid Errors: Standards and Testing

Working with formats begins not at the testing stage but at the design stage. Here is what helps:

Store dates in ISO 8601, numbers unformatted, and currencies with ISO 4217 codes, leaving display formatting to the locale.
Use standard localization libraries instead of home-built templates, such as ICU or built-in platform tools.
Give translators context: the text should make units, currency, and the type of date clear, not just the words.
Test the interface with dates like 01.02, 12:00, and 1 000,50 across several locales, including those where the order differs.
Involve native speakers in final review. They will more quickly notice when "five in the evening" is written as "17.00" in places where that is not how people say it.

The main takeaway is simple: format is part of meaning. A good translation preserves not only the words but also how the reader will understand the date, the price, and the distance. If localization is planned in advance, these traps are almost free to avoid. If they are discovered after release, fixing them costs more than anything else.