> Parsing Is Not a Science It can and should be, though. I feel like we should have a separate word for parsing when the rules are not well-defined - something like "fuzzy parsing" (in a similar vein to fuzzy string comparison)
Reasons to Not Parse Localized Strings
31–40 of 49 posts
Re: Reasons to Not Parse Localized Strings
#32Microsoft Excel is the worst offender here. When you're on a locale with , as a decimal point it's not able to read CSVs with . as a decimal point. It uses ; instead of , as a field separator. Delegating parsing user input is a good idea, but sometimes the input methods you can rely on just don't cut it. By the way: The international way to express a decimal separator is a (thin non-breaking) space. There's no misund…
If you import the data from a file you can select the separator
Re: Reasons to Not Parse Localized Strings
#33Re: Reasons to Not Parse Localized Strings
#34How do people who use commas as decimals disambiguate 1,004 and 1.004 without changing the precision implied by number of decimal places?
You don't. It's ambiguous. Just like the string 01/03/2025 is if you don't know the source's locale. But it can be worse. Los Angeles, Sunday, November 2, 2025, 2:00:00 am is ambiguous. Is it PST or PDT?
Re: Reasons to Not Parse Localized Strings
#35How do people who use commas as decimals disambiguate 1,004 and 1.004 without changing the precision implied by number of decimal places?
What I used to do is set the thousands separator to ' in the operating system settings. That made Excel read CSV files with 1,004 and 1.004 the same, as one and four thousands. No one puts thousands separators in CSV files anyway, so that worked out. And it looked nice too. In today's Windows 11 I can't find that setting. You can't set the thousands separator separately, not anywhere that I can find. It's a tragedy.…
Re: Reasons to Not Parse Localized Strings
#36OT: Why does almost every comment in this thread currently say “2 hours ago”, when they were probably written when this story was first featured, about 3 days ago?
Re: Reasons to Not Parse Localized Strings
#37Earlier quoted context omitted.
If you import the data from a file you can select the separator
You can in libreoffice, but not excel. You _must_ change your locale. I went down this rabbit hole a few weeks ago trying to open some Dutch datasets.
Also, I believe you can change the default separator in Settings somewhere.
Re: Reasons to Not Parse Localized Strings
#38Re: Reasons to Not Parse Localized Strings
#39OT: Why does almost every comment in this thread currently say “2 hours ago”, when they were probably written when this story was first featured, about 3 days ago?
Re: Reasons to Not Parse Localized Strings
#40Take a moment to know that it’s * Crucial* not to localize strings in health software services because it can lead to data leaks and performance degradation. It’s better to work with global APIs so you’re protected from all sorts of risks.