Imagine releasing a travel booking app in several new markets. The interface has been translated, the checkout flow works, and the campaign is ready. Then users begin missing hotel check-in dates because “04/05” means April 5 in one market and May 4 in another. A flight reminder scheduled for 7:00 appears as 19:00 after a time-format mismatch. A baggage limit shown in pounds is mistaken for kilograms, leaving travelers confused at the airport.
None of these issues are traditional translation mistakes. The words may be correct, but the experience is still broken.
Numbers, dates, times, currencies, and units look simple because they feel universal. But in localization, they are some of the easiest details to get wrong and some of the fastest to damage trust. A misplaced decimal separator can change a price. A wrong date format can cause a missed appointment. A unit conversion error can make a product size, recipe, dosage, distance, or delivery estimate completely misleading.
These details matter because they connect digital content to real-world decisions. Users rely on them to pay, travel, measure, cook, shop, schedule, and plan. When the format does not match local expectations, the product can feel confusing, careless, or unsafe.
That is why numbers, dates, and units need their own QA pass. Linguistic review alone is not enough. Localization QA must check whether every format, symbol, separator, unit, currency, calendar reference, and time display works correctly for the target market before users are forced to discover the mistake themselves.
The Quick Answer: The Assumption of Universality
The primary reason numbers, dates, and units break during localization is the false assumption that they don't require translation. Developers often hard-code formats that work in English (like MM/DD/YYYY dates), assuming they work everywhere. Translators, focusing tightly on words, might overlook the necessary format conversions or, worse, translate the unit names but leave the numerical values in the source format.
The solution is to stop treating these elements as universal constants. Instead, they must be treated as highly localized content requiring specific rules, automated checks, and careful in-context review as part of a broader strategy for Quality Control for Localization: Catch Errors Before Users Do.
Where Things Go Wrong: The Usual Suspects
If you want to catch errors quickly, you need to know exactly where to look. Experience shows that numerical and formatting errors cluster around three specific areas where international standards diverge wildly.
The Decimal and Separator Chaos
The most frequent offender in internationalization is the humble dot and comma. In the United States and the UK, a period indicates a decimal, and a comma separates thousands (e.g., 1,234.56). In many parts of Europe, South America, and Asia, this usage is completely flipped (e.g., 1.234,56).
If your translation process doesn't account for this, financial data becomes incomprehensible or vastly incorrect. Furthermore, some languages, like French, often use a non-breaking space as a thousands separator (1 234,56). If this isn't handled correctly in the software, the space can cause awkward text-wrapping issues where the number gets split across two lines in the user interface.
The Date Format Minefield
Few things cause more operational headaches than ambiguous date formats. The US standard of Month/Day/Year is practically unique globally. Most of the world uses Day/Month/Year, while many Asian countries and international ISO standards use Year/Month/Day.
If an event deadline is displayed numerically as "04/05/2024," an American user sees April 5th, while a British user sees May 4th. If your platform handles bookings, appointments, or time-sensitive releases, this ambiguity is unacceptable. This becomes even more complex in constrained media where space is limited, such as mobile UI buttons or comic speech bubbles, a challenge discussed further in our guide on LQA for Short Drama, Webtoons, and Web Novels.
The Unit Conversion Trap
Units of measurement present a two-fold challenge: formatting and actual value conversion. First, there is the issue of the metric system versus the imperial system. A weather app telling a user in Paris that it is "70 degrees" is useless if it doesn't specify Fahrenheit, and actively misleading if the user assumes Celsius.
Second is the danger of translating the unit name without converting the value. If source text reads "The car was traveling at 100 mph," and it is localized into Spanish as "El coche viajaba a 100 km/h," the translation has just significantly altered the facts of the situation (100 mph is roughly 160 km/h). This type of error can have serious real-world consequences in technical or medical translation.
Examples in Action: Variety Across Languages
To truly understand the scope of the problem, it helps to see how these formatting rules clash in the real world.
German (Currency & Numbers):
Source (US English): The price is $1,499.99.
Broken QA: Der Preis beträgt $1,499.99. (Wrong separators, symbol in wrong position).
Correct QA: Der Preis beträgt 1.499,99 $. (Correct dot/comma usage, currency symbol placed after the number with a space).
Japanese (Dates):
Source (US English): Due Date: 03/15/2024
Broken QA: 期限: 03/15/2024 (Ambiguous format to a Japanese user accustomed to YYYY start).
Correct QA: 期限: 2024年3月15日 (Clear, natural Japanese format using Year-Month-Day order with Kanji separators for clarity).
French (Spacing in Units and Currency):
Source (US English): It weighs 50kg and costs €200.
Broken QA: Il pèse 50kg et coûte €200. (Cramped, wrong symbol placement).
Correct QA: Il pèse 50 kg et coûte 200 €. (French requires a non-breaking space between the number and the unit or currency symbol).
The Numerical & Formatting Checklist
Because these errors are so common and so damaging, they require a dedicated pass during the review process. While they should be part of your comprehensive Localization QA: The Checklist That Prevents Bad Releases, it is worth isolating them for a focused review.
Before finalizing any localized product, testers must verify these specific elements in the final build:
Numeric Separators: Are thousands and decimals formatted correctly for the target locale (dots vs. commas vs. spaces)?
Currency Formatting: Is the currency symbol correct? Is its placement (before/after amount) and spacing correct for the region?
Date Ordering: Are numerical dates unambiguous (e.g., using ISO YYYY-MM-DD where possible)? Is the order correct for the local expectation?
Time Format: Is the 12-hour (AM/PM) or 24-hour clock used appropriately for the region?
Unit Conversion Accuracy: If unit names were translated (e.g., "miles" to "kilometers"), were the numerical values converted accurately?
Unit Spacing: Is there appropriate spacing between the number and the unit of measurement (e.g., "10 cm" vs "10cm") according to target language rules?
Conclusion
Numbers, dates, and units are the functional skeleton of your localized content. They are not open to interpretation in the same way literary prose is. When they break, the product doesn't just look bad—it stops working correctly for the user, leading to confusion, mistrust, and costly errors. By recognizing that these elements are highly sensitive to cultural context and establishing rigorous QA protocols to check them in the final build, you ensure that your global launches are defined by success, not by embarrassing formatting bugs.
Preparing for a complex global launch without functional localization errors? Download Feels Local and try it on your next project for free. When you’re ready to catch issues with numbers, dates, units, and formatting before release, subscribe to Feels Local and launch with confidence.
