fix for #230 #231

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
Member

muxcmux commented Nov 27, 2012

define spec and implement parsing currencies with different thousands_separators and decimal_marks. issue #230

Owner

semmons99 commented Nov 27, 2012

Hey @muxcmux,

The problem we're trying to fix here is that when parsing a string, it should respect the given currencies rules for decimal markers and thousands separators and not try to second guess it.

Member

muxcmux commented Nov 27, 2012

Wouldn't that introduce backward incompatibilities? For example, this:

"100.37 EUR"      => Money.new(100_37, "EUR")     ,

would no longer be valid

Owner

semmons99 commented Nov 27, 2012

I always have a hard time deciding what to do here.

Anyone @RubyMoney/money-devs @RubyMoney/money-admins care to weigh in?

Member

semaperepelitsa commented Nov 27, 2012

The formatting rules do not depend on currency, they depend on locale. In US English you write "€10,370.55" and in Russian - "10 370,55 €".

This doesn't matter when you are dealing with a local currency only. But it is not uncommon to have an additional one.

Contributor

realmika commented Nov 27, 2012

Yes, I would agree with @semaperepelitsa. The thousands and decimal separators are entirely decided by locale. For example, in Swedish you would always write "," before the fractional part. I.e Swedish 10,37 is written "10.37" in Ruby. This is, of course, a major pain in the ass since the numpad period button won't work unless the keyboard layout is changed to "en/us".

Member

muxcmux commented Nov 27, 2012

@mikaelwikman I couldn't agree more, but that seems to raise more questions than it answers. In such case, why do we need to keep information on thousands separator and the decimal sign? This should be locale-specific, like @semaperepelitsa suggested.

Contributor

realmika commented Nov 27, 2012

Indeed. We might need to rethink all current functionality that involves the thousands separator and fractal sign. We could probably do some automatic mapping from the current settings by using Country gem to figure out the locale, and use this by default. This way we'd still be backwards compatible. After that the logical course of action would be to add locale to the interfaces and let it fall-back to the one defined in the configuration.
I'm currently swamped with work, all scheduled up to end of January. So someone else would need to take a crack at it :)

semmons99 closed this Jan 3, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment