number_to_human_size in your language [attn JP, CN]

69 views
Skip to first unread message

Yaroslav Markin

unread,
Dec 4, 2008, 12:09:20 PM12/4/08
to rails-i18n
Hi all,

1. First of all, there is a bug with Rails Edge number_to_human size -- it still uses "Bytes", I'll correct that as soon as we figure out 2.

2. Current number_to_human_size formatting is something like that: "{{number}} {{unit}}". I wonder if it is okay for all languages. Seems that is perfectly OK with european and slavic languages, but I really wonder about Japanese or Chinese. If formatting is different, we'd better go with interpolation instead of just having an array of units.

--
Yaroslav Markin

Akira Matsuda

unread,
Dec 4, 2008, 4:50:45 PM12/4/08
to rails-i18n
Yaroslav

Hi,

thank you for considering about our (maybe strange?) language.
Yes, as for Japanese, we don't usually separate number and unit by a
space character, as you pointed out.
So, "{{number}}{{unit}}" like formatting is preferrable. I mean,

helper.number_to_human_size(10240, :locale => :ja).should_return("10キロ
バイト")

Akira

On Dec 5, 2:09 am, "Yaroslav Markin" <yaroslav.mar...@gmail.com>
wrote:

Sven Fuchs

unread,
Dec 7, 2008, 4:01:24 PM12/7/08
to rails...@googlegroups.com
Hey guys,

I guess with the tools available in Rails I18n we'd probably need to
use a format string like

number:
human_size:
format: "{{number}} {{unit}}"

... and then lookup the units as well (iirc that's already done?)


At some point we might want to refactor those number helpers etc.
according to something like CLDR does:

http://www.unicode.org/cldr/data/charts/by_type/number.pattern.html

Is there some Ruby libraray available that'd be able to parse and
apply format strings like these?

Yaroslav Markin

unread,
Dec 8, 2008, 3:17:51 AM12/8/08
to rails...@googlegroups.com
I was thinking about something like

      storage_units: # [Bytes, KB, MB, GB, TB]
        one: ["1 Byte", "1 KB", "1 MB", "1 GB", "1 TB"]
        other: ["{{count}} Bytes", "{{count}} KB", "{{count}} MB", "{{count}} GB", "{{count}} TB"]

But in this case, we'll need to patch SimpleBackend so it can make recursive interpolations for Enumerable. What do you think, is it an overkill?



On Mon, Dec 8, 2008 at 12:01 AM, Sven Fuchs <sven...@artweb-design.de> wrote:

Hey guys,

I guess with the tools available in Rails I18n we'd probably need to
use a format string like

number:
  human_size:
    format: "{{number}} {{unit}}"

... and then lookup the units as well (iirc that's already done?)


--
Yaroslav Markin

Yaroslav Markin

unread,
Dec 25, 2008, 4:30:42 PM12/25/08
to rails...@googlegroups.com
In case anyone wonders, here it is :)

http://rails.lighthouseapp.com/projects/8994/tickets/1634-number_to_human_size-helper-fixintroduce-pluralization-add-format-property

I believe we're safe to go with that, CLDR does not have anything about unit formatting anyway.


On Fri, Dec 5, 2008 at 12:50 AM, Akira Matsuda <pushi...@gmail.com> wrote:

Yaroslav

Hi,

thank you for considering about our (maybe strange?) language.
Yes, as for Japanese, we don't usually separate number and unit by a
space character, as you pointed out.
So, "{{number}}{{unit}}" like formatting is preferrable. I mean,

 helper.number_to_human_size(10240, :locale => :ja).should_return("10キロ
バイト")

Akira


--
Yaroslav Markin

Yaroslav Markin

unread,
Dec 26, 2008, 7:03:06 AM12/26/08
to rails...@googlegroups.com
As we were discussing this bug with Sven, we thought that maybe having keys for each unit (.byte, .kb, .mb) is the way to go, instead of having an array and guessing it size.

Does anybody know if there are languages that do not have translations for all units we have at the moment(Bytes..TB)?


On Fri, Dec 26, 2008 at 12:30 AM, Yaroslav Markin <yarosla...@gmail.com> wrote:
In case anyone wonders, here it is :)

http://rails.lighthouseapp.com/projects/8994/tickets/1634-number_to_human_size-helper-fixintroduce-pluralization-add-format-property

I believe we're safe to go with that, CLDR does not have anything about unit formatting anyway.


 
--
Yaroslav Markin

Reply all
Reply to author
Forward
0 new messages