Get the latest tech news
Reasons to Not Parse Localized Strings
As a programmer, it is natural to think of data as a series of one-to-one relationships between string identifiers and objects in a computer. Many standard libraries in programming languages allow for round-tripping between strings and objects, including JSON, ISO-8601 date strings, and URL encode/decode. So, if you can create a localized string, such as with .toLocaleString() in ECMA-402, why can’t you parse that string back to an object using a function like .fromLocaleString()? The answer comes down to the fact that i18n is fundamentally different from data interchange. This document lays out why you should not parse localized strings and the best practices for what to do instead. Parsing Is Not a Science What is the number represented by the localized string
For apps with heavy data entry, such as spreadsheets and calendars, developers and designers often want to use date parsing to make the input easier. If you still feel the urge to implement your own input component, think again, especially if you haven’t worked in the i18n field before and are unfamiliar with the unique problems that will arise. For example, in data mining and natural langauge understanding, you may find yourself with large amounts of unprocessed text, and you need to parse numbers out of it.
Or read this on Hacker News
