Closed kreintjes closed 7 years ago
relying on I18n
and presence of number.format.separator
doesn't seem right to me.
Isn't to_i
just enough?
irb(main):003:0> '4,4222'.to_i
4
irb(main):004:0> '4.4222'.to_i
4
@leikind It would for parsing to an integer, but I am trying to parse to a float/decimal. to_f
and to_d
aren't working, they simply ignore the comma and round the values down:
[10] pry(main)> '1,234'.to_f
=> 1.0
[11] pry(main)> '1,234'.to_d
=> 0.1e1
Relying on I18n
does not seem a problem to me. Wice_grid has activerecord as dependency, which has activesupport as dependency, which has i18n as dependency. So I18n
should be present in any environment in which wice_grid is used. The same goes for number.format.separator
since it is a default Rails key. However, if you would like, I could build in a check for I18n
and number.format.separator
being present.
Another solution would be to add a configuration variable to wice grid to set the decimal separator. Although that would lead to additional configuration, while this works out of the box. Let me know which solution you prefer.
let's have some fallback behavior / default separator(s) if number.format.separator
is missing and I'll merge it
@leikind Done. When I18n or separator is not present, there is no replacing necessary (dot will already be the likely separator). So when looking up number.format.separator
fails, either because I18n or the translation is missing, it simply skips the replacing.
Ps. Your gem is great when having an application which needs many tables with basic sorting, filtering and exporting mechanisms. Thanks!
Also do not crash or give invalid text representations of numbers to PostgreSQL. Fixes https://github.com/leikind/wice_grid/issues/338. Any suggestions are welcome!