Live data from Hacker News

Reasons to Not Parse Localized Strings

blog.sffc.xyz

31–40 of 49 posts

Re: Reasons to Not Parse Localized Strings

#31
post #8

> 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)

It’s called “guessing”.

Re: Reasons to Not Parse Localized Strings

#32
post #30

Microsoft 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

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.

Re: Reasons to Not Parse Localized Strings

#34

How 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?

That's not an ambiguous date because Nov 2 2025 is PST, not PDT.

Re: Reasons to Not Parse Localized Strings

#35

How 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.…

You have to set it for the whole OS... it's like someone who works at Microsoft decided that you should never work on a file generated in a different locale.

Re: Reasons to Not Parse Localized Strings

#37
post #30

Earlier 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.

You can in excel: https://superuser.com/a/407085

Also, I believe you can change the default separator in Settings somewhere.

Re: Reasons to Not Parse Localized Strings

#38
Take 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.

Re: Reasons to Not Parse Localized Strings

#39
post #33

OT: 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?

Hovering over the time-ago item on the comment header displays the exact post time, and interestingly it shows times from Feb 16 (3 days ago) for many of the "2 hours ago" comments. Must be an artifact of some moderation tool.

Re: Reasons to Not Parse Localized Strings

#40

Take 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.

Performance degradation?
Post reply on HN