Size options can be overriden

[rdolgushin]

I added the ability to overwrite default size options (for example, if you need to use localized size suffixes).

[avoidwork]

Is there functionality you'd like to add?

[rdolgushin]

Yes, I want to add ability to overwrite size options because there is no i18n, but I realized that for this purpose is necessary to overwrite much more parts of filesize and there are many controversial issues, which I can not resolve.
As a result, I decided to make fork with supporting of only one language - Russian (https://github.com/rdolgushin/filesize.js).
If in the future you could to find some way to implement localization support, it would be very good!

[avoidwork]

They're based on the international system of units (SI), specifically Metric & JEDEC. Changing the output to a localized language is an interesting request, but I don't know if there's much value in adding it to the core lib. It could be a simple test to perform a string.replace() at the return. Realistically, you don't want to change the existing code.

[rdolgushin]

Great solution! Little bit slowly, but much more simpler than create ten forks for ten languages. Thanks. I think next time I will do so.

[avoidwork]

I have a functional implementation at #49 ... does that look ideal?

[avoidwork]

I'm not sure if the key should be 'language', 'locale', or 'l18n'. What do you think?

[rdolgushin]

I'm not sure if the key should be 'language', 'locale', or 'l18n'. What do you think?

I saw your code and I think that most right name for the key is 'suffixes'.

[rdolgushin]

I have a functional implementation at #49 ... does that look ideal?

Looks pretty good! 👍

[avoidwork]

So far I've pinged 3 coworkers, and we've all got different opinions on what the key should be. Do you know of prior work that handles this kind of overriding? I feel that 'locale' is wrong based on the fact that it's not going to use the system locale setting.

[rdolgushin]

In many projects that I've seen, such things was named as 'messages' or 'locales'. For example such mainstream framework as Rails (and many Rails-inspired frameworks) has 'locales' - https://github.com/gitlabhq/gitlabhq/blob/master/config/locales/en.yml

[rdolgushin]

Please, see it - https://github.com/mugifly/jquery-simple-datetimepicker/blob/master/jquery.simple-dtpicker.js
I think you'll like it.

[avoidwork]

My original commit had 'lang' as the key, but I changed it to be 'language' for clearer meaning. I'm tempted to leave it as is, unless a compelling argument is made. Please, ask your peers what they think; this is not going to be a commonly used feature, but I would like it to make sense to those that use it.

[rdolgushin]

My peer (just one) very inspired by Rails and preferred 'locale' (but it does not result in any arguments, moreover, that it is just like him). But I see you want something more accurate. To my mind more accurate and flexible concept will be the 'suffixes', because it is not limited to the scope of the localization - you can add arbitrary suffixes without binding to some language or (may be) locale.

[avoidwork]

Ok, unless someone else makes a good argument, I'll change it 'suffixes' in approx 12hr, and this will become 2.0.1.

[rdolgushin]

Ok. Thank you for your interest about this problem!