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

21–30 of 49 posts

Re: Reasons to Not Parse Localized Strings

#21

Post by mantas »

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?

Not sure where OP is from, but in my whereabouts „100,000,004“ wouldn’t show up in the wild. We use spaces to separate if really needed.

Re: Reasons to Not Parse Localized Strings

#22

Post by legulere »

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 misunderstanding possible.

Re: Reasons to Not Parse Localized Strings

#23

Post by Retr0id »

eyelidlessness wrote: post #15
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.

It doesn't make the problem go away, but it makes it clear that parsing itself is not the problem

Re: Reasons to Not Parse Localized Strings

#24

Post by Waterluvian »

mantas wrote: post #21
Waterluvian wrote: post #17

Earlier quoted context omitted.

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

Not sure where OP is from, but in my whereabouts „100,000,004“ wouldn’t show up in the wild. We use spaces to separate if really needed.

Ah makes sense. In Canada we were taught to use spaces to separate, and decimals for decimals. But being stuck so close to the US we end up with a mess of everything.

Re: Reasons to Not Parse Localized Strings

#25

Post by patio11 »

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…

Tiny correction: in 2010, I invented a thing parallel to something many well-educated Americans of my acquaintance believe with respect to the centrality of their experience, for the Falsehoods essay.

In 2012, a clerk actually asked my wife and I, when we got married, whether it wouldn't make more sense for me to change my name. Then he wouldn't have to spell Patrick McKenzie on the wedding paperwork, and, approximate quote, "I already have to get one name change form out for her so filling out a second one is no trouble at all."

Re: Reasons to Not Parse Localized Strings

#26

Post by frizlab »

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…

> On Windows one can change how a date is rendered

I think that’s true on all OSes

Re: Reasons to Not Parse Localized Strings

#27

Post by LegionMammal978 »

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…

> By the way: The international way to express a decimal separator is a (thin non-breaking) space. There's no misunderstanding possible.

According to whom? The CGPM recommends thin spaces as thousands separators, and either points or commas as decimal separators. NIST, ISO, etc. generally copy this, sometimes stipulating the decimal separator as one or the other.

Re: Reasons to Not Parse Localized Strings

#28

Post by layer8 »

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…

This is a relic from the olden times were application data was rarely exchanged across locales, and people expected software to conform to the local conventions (and they largely still expect it). Microsoft never changed this because it would have broken (and would still break) a vast number of systems and workflows.

Re: Reasons to Not Parse Localized Strings

#29

Post by thaumasiotes »

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 was a post on Language Log once scoffing at the stupidity of the Chinese for their feeling that Uyghurs should use normal Chinese names.

I asked a friend in Shanghai whether she thought Uyghur names should be allowed. She responded: "Huh? You don't get to choose what other people's names are. They tell you their names, and then you have to call them that.

And if you really want to think about weird names, there's a country called 'St. Vincent and the Grenadines'!"

(In other minority-names-in-China news, I have a Mongol friend whose name is Saruul. Her parents sinicized this as the three Mandarin syllables sha-ru-la, which look like a normal Chinese name. I don't actually know what she prefers to be called, but I suspect most people she knows call her Rula.)

Re: Reasons to Not Parse Localized Strings

#30

Post by croes »

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…

If you import the data from a file you can select the separator
Post reply on HN