papandreou / inter Goto Github PK

Zoneinfo.js
var val = Object.values(moment.tz._zones).some(function (x) { return typeof x !== 'string' && x.name === timeZoneId ;});

apparently, for this timeZoneId, we are getting different names, we are getting the following error.
Error: Timezone America/Ciudad_Juarez not found in moment-timezone.

Maybe make it customizable, support AMD etc.

Does anyone have a suggestion for a name?

It would be great if inter can be used as a library, without installing uglify-js.

It seems that there is currently no currency rendering method? The patterns are available in CLDR and the implementation shouldn't be too hard to figure out either.

The syntax could look like this:

inter.load('en');
inter.renderCurrency( 10000.23, 'EUR' ); // €10,000.23
inter.renderCurrency( 10000.23, 'EUR', true ); // EUR10,000.23

The 2nd param is of course, the currency we want to see the results in. The 3rd param is borrowed from Google Closure's implementation where they let the user decide if they need a global or local representation of the currency symbol.

Hello, I tried building inter with CLDR 23.1, because 22.1 has some wrong locale data. However, I had no success - the process just keeps running forever. I got tired after about half an hour.

Any idea what might cause this? I used CLDR 23.1 as the input.

We could expose digits, rounding, cashDigits, cashRounding from supplementalData.currencyData.fractions, for instance as part of inter.getCurrency

If a currency is not in the list, I suppose we should fall back to using 2 as value for those four properties.

I know the original ICU implementation does not provide this, but it makes a lot of sense. User should be able to provide the precision for renderPercentage method. Sometimes it is necessary to show something like 0.5%. Currently, it's only possible to go as low as 1%.

currently renderCurrencyShort has a fixed precision of 2 digits after the decimal point for all currencies example:

renderCurrencyShort(10, 'JPY', 'latin') will render 10.00 which is not correct since JPY does not support decimal digits according to ISO-4217, my suggestion is to add an extra parameter for precision to renderCurrency or add a precision value to each element in the currencies array and let it decide the number of decimal digits for each one.

First, thanks a lot for this module. It has no doubt been a lot of work!

Consider this as a discussion from someone who does not fully understand the motivation or rationale behind the current architecture.

As I understand, if I want to use inter in the browser, I need to build a different version of it for each locale. If I use a single locale in my client-side app, that works just fine. But when I need to use 2 different locales at the same time, I will probably get into trouble. Why? because I need to load the FULL logic + data both times.

Wouldn't it make more sense to separate the logic from data so that loading multiple locales in the browser (say 2-3 at a time) will be a lot lighter?

In 4191753 the defaultDateTimePattern property was removed from the calendars, but it turns out I am using this in another library, like this:

var timeFormatString = inter.getDateFormat(formatId[0]),
      dateFormatString = inter.getDateFormat(formatId[1]);
      dateFormat = inter.calendars.gregorian.defaultDateTimePattern.replace('{0}', timeFormatString).replace('{1}', dateFormatString);

Could you advise what the ideal way of replacing this in my end is?

For a territory to be classified as a country, it currently has to be listed in https://github.com/papandreou/inter/blob/master/worldInfo/countries.csv and not be historical, nor a subdivision. The list appears to be a a bit outdated (the timestamps in the last column of the file say 2007-10-24). South Sudan declared its independence in 2011, and there has probably been other changes as well.

@bramstein, I think I got the file from you, do you know where I can find an updated version?

CC: @birkestroem

var inter = require('inter').load('en_in');
console.log(inter.renderNumber(10000000.23));

Results in:

TypeError: Cannot call method 'charCodeAt' of undefined
    at subformatFixed (/Library/WebServer/Documents/node_projects/test_inter/node_modules/inter/build/root.js:175:121)
    at format (/Library/WebServer/Documents/node_projects/test_inter/node_modules/inter/build/root.js:350:84)
    at Object.(anonymous function) [as renderNumber] (/Library/WebServer/Documents/node_projects/test_inter/node_modules/inter/build/root.js:573:162)

I guess this is an issue with this specific locale

For makeFileSizeRenderer, I've got a use case for always showing the size in GB, even though the size might be just a few bytes.

If I were to make a pull request to add such support, would you also like me to rewrite the function so it doesn't use the Function constructor, but just return a normal function instead?

Trying to format a number like 123456789201921 reveals the underlying issue with float-precision math that JS has. The result is something like 123,456,789,201,920.992 while it should be 123,456,789,201,921.

I stumbled upon this while working on my own fork of Numeral-JS. The issue can probably only be solved if using a specialized library like Big.js

Of course, this is probably an edge case, but perhaps it is something to be considered.

For some reason, npm published inter v1.10.0 without having created the 'build' folder, nor erroring out.

npm publish
> [email protected] prepublish /some/local/path
> rm -fr build && ./bin/buildInter --type node -o build --all --golf --jobsize 100
+ [email protected]

I've unpublished it now, but have to check tomorrow what's going on.

I was trying to give inter a go but stumbled upon this:

ReferenceError: umalqura is not defined
    at /Library/WebServer/Documents/node_projects/test_inter/node_modules/inter/build/et.js:1669:41
    at /Library/WebServer/Documents/node_projects/test_inter/node_modules/inter/build/et.js:3:26

It looks like it's caused by these 2 lines:

monthNames: P.calendars.islamic-umalqura,
eraNames: P.calendars.islamic-umalqura,

Accessing a property name with a dash in using dot-notation, is, of course, invalid. You should be using literal notation instead.

monthNames: P.calendars['islamic-umalqura'],
eraNames: P.calendars['islamic-umalqura'],

I think it would be best if you would check if the property name has any dashes and use literal notation only then, because literal notation can have a small impact on file size (which matters, if used in browser).

console.log(inter.renderSpelloutCardinal(2439871));

Gives: üks miljonit nelisada ükskümmend üheksa tuhat kolmkümmend üks

The above result is totally messed up. It should say:
kaks miljonit nelisada kolmkümmend üheksa tuhat kaheksasada seitsekümmend üks

Basically, translated to english, it is currently saying:
One millione four-hunderd onety-nine-thousand thrity-one

I guess there must be a serious flaw in the cardinal function generator.

See: https://github.com/papandreou/inter#interrenderpercentagenumber-numdecimals

Both inter.renderPercentage and inter.getPercentageRenderer should take a numDecimals argument, but instead they expect a numberSystemId.

I think they should definitely accept an argument that enables the user to control the number of decimals. Preferably even minDecimals and maxDecimals.

Building [email protected] on [email protected] fails

time.target.mk:92: recipe for target 'Release/obj.target/time/src/time.o' failed

Looks like the time package requires an update to 0.11.4 for building fine.

For instance check if the input is a number representing the amount of milliseconds since unix epoch, or a parsable date string

In CLDR, there is a currencySpacing section available, which has the same content for each number system and locale. This information is being made available by node-cldr now:
papandreou/node-cldr@a31ab16

In currencySpacing, there's a regex "[:^S:]", which according to this page stands for Symbol:
http://unicode.org/glossary/#graphic_character

In the case of currencySpacing, we could limit its range to just currency symbols:
http://unicode.org/charts/PDF/U20A0.pdf

We could expand [:^S:] to:
/[^\u20a0-\u20cf \u0024 \u00a2-\u00a5 \u0192 \u058f \u060b \u09f2 \u09f3 \u0af1 \u0bf9 \u0e3f \u17db \u2133 \u5143 \u5186 \u5706 \u5713 \ufdfc]/

@papandreou do you agree with doing such an expansion in inter, or would it fit better in node-cldr?