String#to_money parsing issue

[bertBruynooghe]

when parsing 1.234 with a currency that has , as decimal_mark and . as thousands_separator, the currency settings are ignored, and . is considered to be the decimail_mark.

I patched the code locally in my rails project:

module Monetize
  class << self
    def extract_cents_with_decimals_addition(input, currency = Money.default_currency)
      decimal_mark = I18n.t('number.currency.format.separator')
      input = "#{input}#{decimal_mark}0" unless input.include?(decimal_mark)
      extract_cents_without_decimals_addition(input, currency)
    end
    alias_method_chain :extract_cents, :decimals_addition
  end
end```

[aredondo]

In some corner cases, Monetize tries estimate the correct decimal separator itself rather than blindly trusting the separators set in the currency.

Modifying this behaviour breaks a number of test cases in the gem, so without resorting to a major version change, I think this can only be fixed with a configuration variable.

[aredondo]

Can you please check if this change resolves the issue for you? Before parsing, you need to set Monetize.enforce_currency_delimiters = true.

[bertBruynooghe]

undefined method enforce_currency_delimiters=' for Monetize:Module (NoMethodError)`
on monetize (1.1.0)

[aredondo]

It seems you didn't apply the change in your code. Can you clone my fork? It's at https://github.com/aredondo/monetize.git. If you are using Bundler, the github: 'aredondo/monetize' modifier should work.

[aredondo]

@semmons99 There is no feedback on this issue. I still find the configuration option interesting, as the default behavior may be somewhat surprising for some currencies. What do you think of merging the change and closing this?

[semmons99]

I'm good with it. Is there a Pull Request open? I may have missed it.

[bertBruynooghe]

Couldn't test this yet due to the context of my problem: needing money-rails in my project, and couldn't get dependencies right.
But from inspecting the code, it looks like it could solve my particular issue.
It is however discussable that if only one separator is present without always_enforce_currency_delimiters being set, the separator is considered as decimal mark (like in the example above). Looks to me it should get the separators from the default/passed currency, and maybe in combination with another setting not to break existing behaviour.

(in 400#24 there is no doubt as to what function # has, but in 400#000 the current estimation is most of the times wrong, as most currencies will not be expressed in thousands)

[aredondo]

If what you mean is that, by default, Monetize should work as if always_enforce_currency_delimiters was enabled, I agree. But this sort of change in default behavior can maybe fit better in major version changes. Hence the configuration flag.

[bertBruynooghe]

I agree with the configuration flag, but I'm just saying it is not solving all problems. Sometimes you want for obvious cases the delimiters to be derived from the string, but in this case, you still have an issue when someone puts in 7,000 or 7.000, as it is not to be derived from the string itself if the dot/column have to be considered as decimal mark or thousands separator. (Currently it assumes it to be the decimal mark, but since this is a currency, it is much more likely that the user intended the opposite, as currencies are rarely described with 3 decimal places. For 7,00 and 7.0000 the current assumption in the code is correct.)