Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons to Not Parse Localized Strings

blog.sffc.xyz

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Reasons to Not Parse Localized Strings

#41

Post by pixl97 »

tmiku wrote: post #39
teddyh wrote: 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.

There is a feature in HN that brings stories back to the front page, can't remember what it's called at the moment, but must be because of that.

Re: Reasons to Not Parse Localized Strings

#42

Post by Dwedit »

RainyDayTmrw wrote: post #19
teddyh wrote: post #14

”People whose date formats break my system are weird outliers. They should have had solid, acceptable formats, like 平成10年8月1日.” (With apologies to patio11.)

For context, in case anyone needs, that's a common date format in Japan. Aside from using kanji characters, the big surprise to most of the rest of the world is that the largest epoch is specified as a royal era name[1], corresponding to the Japanese monarchy. This parallels, and the remark about patio11 refers, to this article[2], which has since become famous on HN. It ends with a similar remark from the author's p…

There are two sources for Japanese eras on Windows:

* Hardcoded into the system libraries/.net framework

* The Windows Registry

And this allows things to continue working even if the software is older than the newest era.

Re: Reasons to Not Parse Localized Strings

#43

Post by Dwedit »

withinboredom wrote: post #35
munch117 wrote: post #18

Earlier quoted context omitted.

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.

If you need to apply a setting like that to a single application only, there are ways to create a program that will detour all the registry reads.

Re: Reasons to Not Parse Localized Strings

#44

Post by maleldil »

yndoendo wrote: post #12
Waterluvian wrote: post #2

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 are trying to apply what you know versus what others know. No different than Farenheit vs Celsius or Yard vs Meter. Personal, the MM/DD/YYYY format, that is stander in the USA, needs to die and be replaced with YYYY-MM-DD. Same with 12 hour time and replacing it with 24 hour. As the saying goes l, Americans use am and pm because they can't count past 12. AM and PM are a waste of code and display area. What fits i…

No excuse for the date, but I get the 12/24 hour clock. 12h feels more natural when spoken. Where I'm from, we speak in 12h but always write down 24h. You'll see "20:00" written down, but you'll say "8 in the evening". We don't use am/pm, though.

Re: Reasons to Not Parse Localized Strings

#45

Post by stefs »

legulere wrote: post #22

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…

> decimal separator is a (thin non-breaking) space

i really hope you mean thousands separator ...

Re: Reasons to Not Parse Localized Strings

#46

Post by withinboredom »

Dwedit wrote: post #43
withinboredom wrote: post #35

Earlier quoted context omitted.

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.

If you need to apply a setting like that to a single application only, there are ways to create a program that will detour all the registry reads.

I'm sure there are -- but I'm not doing all of that for a one-off thing.

Re: Reasons to Not Parse Localized Strings

#47

Post by withinboredom »

finger wrote: post #37
withinboredom wrote: post #32

Earlier quoted context omitted.

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.

I don't know if you noticed the date on that was 2012 and it is currently 2025; along with my comment mentioning "rabbit hole, weeks ago" but all of those settings no longer exist.

Re: Reasons to Not Parse Localized Strings

#48

Post by croes »

withinboredom wrote: post #47
finger wrote: post #37

Earlier quoted context omitted.

You can in excel: https://superuser.com/a/407085 Also, I believe you can change the default separator in Settings somewhere.

I don't know if you noticed the date on that was 2012 and it is currently 2025; along with my comment mentioning "rabbit hole, weeks ago" but all of those settings no longer exist.

I just opened Excel M365, opened per Data -> From Text/CSV a csv file and coulds chose the delimiter.

I tested semicolon and comma and in both cases the autorecognition selected the correct delimiter but I could change it to equal sign, space, tab, user defined.

You can't change the decimal separator, but the field delimiter is possible.

Re: Reasons to Not Parse Localized Strings

#49

Post by munch117 »

withinboredom wrote: post #35
munch117 wrote: post #18

Earlier quoted context omitted.

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.

Wait, can you tell me how to set it for the whole OS? Then please do!
Post reply on HN