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

11–20 of 49 posts

Re: Reasons to Not Parse Localized Strings

#11

Post by trinix912 »

toast0 wrote: post #7
OptionOfT wrote: post #3

On Windows one can change how a date is rendered, without changing the locale. I need to look up if this is propagated to browsers. Also, I hate DOB selectors which don't allow me to manually enter the date, and default to today, and don't have a year Now I need to click at least (age - 1) * 12 on the In general, I wish more websites would use native date / number / dropdown pickers. Workday is the worst offender her…

Try clicking the year number and the month name. Those often show a pop up with less clicking required to get to where you want.

But those are unintuitive and still more time consuming than a masked numeric XXXX-XX-XX with a dropdown calendar. Which is what Windows provides anyways.

Re: Reasons to Not Parse Localized Strings

#12

Post by yndoendo »

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 in 2 characters takes up 5 characters.

Re: Reasons to Not Parse Localized Strings

#15

Post by eyelidlessness »

Retr0id wrote: 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)

Renaming the problem doesn’t make it go away. It might be useful for identifying the subset of parsing which is problematic, but I think the article already achieves this well by specifying the subset of input under discussion.

Re: Reasons to Not Parse Localized Strings

#16

Post by pwdisswordfishz »

Retr0id wrote: 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 "scraping".

Re: Reasons to Not Parse Localized Strings

#17

Post by Waterluvian »

trinix912 wrote: post #10
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?

It depends on the local norms. Where I live, 1,004 is decimal, 1 004 or 1'004 is 1004 which makes it even more clear than the en-US default. That is, the 1.004 variant is never used, and if it is, it is assumed to be a decimal (misspelling) of 1,004.

So is there no such thing as "100,000,004" and having no idea if that's a decimal or a thousands separator?

Re: Reasons to Not Parse Localized Strings

#18

Post by munch117 »

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?

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. I see Excel misreading CSV files all the time. I don't use Excel that much myself and I understand what's going on, so it doesn't affect me all that much directly, but for my Excel warrior colleagues, it's another matter.

Re: Reasons to Not Parse Localized Strings

#19

Post by RainyDayTmrw »

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 prior experience as an American expatriate in a less populous and less cosmopolitan part of Japan, when a clerk remarked that Patrick McKenzie was a troublesome name to have in Japan, and why didn't he change it to something convenient and ordinary like Tanaka Taro[3].

This has since become HN folklore.

[1] https://en.wikipedia.org/wiki/Japanese_era_name [2] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... [3] https://news.ycombinator.com/item?id=6145768

Re: Reasons to Not Parse Localized Strings

#20

Post by bryanrasmussen »

Waterluvian wrote: post #17
trinix912 wrote: post #10

Earlier quoted context omitted.

It depends on the local norms. Where I live, 1,004 is decimal, 1 004 or 1'004 is 1004 which makes it even more clear than the en-US default. That is, the 1.004 variant is never used, and if it is, it is assumed to be a decimal (misspelling) of 1,004.

So is there no such thing as "100,000,004" and having no idea if that's a decimal or a thousands separator?

In Denmark for example the decimal and comma are reversed in meaning, so you would not have a Danish 100,000,004 because that is an obvious non-Danish number.
Post reply on HN