This project is archived and is in readonly mode.
number_to_human_size broken if current locale doesn't define number.format.separator or number.human.format.separator
Reported by Mihai Târnovan | August 14th, 2008 @ 07:07 AM | in 2.x
number_to_human_size kinda breaks, if neither precision/separator/delimiter are passed in options[] nor is there a corresponding translation for number.format.separator or number.human.format.separator in the current translation.
Example:
I18n.locale = 'en-US'
helper.number_to_human_size(1024**3) #=> "1 GB"
I18n.locale = 'KLINGON'
helper.number_to_human_size(1024**3) #=> 1.0
For the sake of backward compatibility with code that calls number_to_human_size with a single numeric argument when no translations for the aforementioned are available in the current locale, I think providing hardcoded fallback default for precision/separator/delimiter is reasonable.
Comments and changes to this ticket
-
Mihai Târnovan August 13th, 2008 @ 06:47 PM
Here's a patch. Sorry, but I don't use git (yes), so I'll attach a diff. This patch also allows storage units to be translated.
-
josh November 22nd, 2008 @ 07:21 PM
- State changed from “new” to “incomplete”
Can you please add some unit tests to the patch.
Also, I'd keep the STORAGE_UNITS constant.
-
-
josh November 24th, 2008 @ 07:24 PM
- State changed from “incomplete” to “committed”
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Mihai Târnovan