In reply of https://github.com/rxaviers/cldrjs/issues/30#issuecomment-121424745

README.md

See comments.

@rxaviers See globalizejs/globalize#460 as a starting point. At the moment, I am working to globalize our server-side components built on node.js and express. We use handlebars for template rendering. I was debating between FormatJS and globalize, and decided to try globalize first because it also supported parsing (which is a need of ours to handle user form submissions).

The documentation indeed needs lots of improvements and that's something we're working on the moment. I will reply you on such issue...

In node, I am building an internal i18n module that:

• Loads the locale JSON data I created in .NET, and creates a Globalize object for each supported locale. I want to pre-load all of this for performance reasons, and to re-use objects across requests with the same locale.

Ok. One note about performance is to try to cache your formatters and parsers. E.g., var fmt[locale] = Globalize(locale).dateFormatter(options);. Then, use fmt[locale]. It will be 10x faster than creating the formatter/parser every time.

Alternatively, simply don't worry about it when we land (if we land) our built-in cache support. Currently implemented on globalizejs/globalize#436.

• Provides a set of handlebars helpers (a la FormatJS), such as formatCurrency, formatShortDate, etc that I use in my templates, and when executed will use the res.locals.intl (Globalize) object to render out the correctly localized version of the data.

Do you have plans to open source it? Currently, @kborchers and I have been developing a React.js integration and the idea is to list the integrations in our Globalize documentation.

Yes, I'm planning to pre-create and cache the various formatters I need (and allow for lazy creation of others as necessary). That's part of what I was asking about in my original issue linked above.

I will certainly consider open sourcing the integration; at the moment it's a bit specific to our code as it has some LCID to locale string mapping, so I'll have to think about whether I can refactor it to be more widely useful.

One other related challenge I've had is figuring out a "default" currency to use for a given locale. Is that something that is defined/available via cldr data? I found the way to see all available currencies for a locale, but I didn't see any obvious way to pick out which one was the current "default". I think that -- and a better locale to bundle mapping -- would be important for a library like this to be useful to a lot of folks.

I will certainly consider open sourcing the integration;

Awesome. Please, keep me posted on its progress.

figuring out a "default" currency to use for a given locale

http://www.unicode.org/reports/tr35/tr35-numbers.html#Supplemental_Currency_Data

supplemental/currencyData.json has a region mapping with currencies. You can use that data to figure out the default currency of a region.

I think that

This could live in Globalize. Needs a good API. Feel free to submit an issue proposing one. Take into account http://www.unicode.org/reports/tr35/tr35-numbers.html#Currencies

and a better locale to bundle mapping

This could live in cldrjs. Needs a good API.

A way to manage currencies

Alternatively, simply don't worry about it when we land (if we land) our built-in cache support. Currently implemented on globalizejs/globalize#436.

Do you have any timeline on when this might be incorporated?

Good question :P, I've created an exclusive PR for cache support globalizejs/globalize#470 (I've decoupled it from 436)

The cache support depends on PR#436 and I hope we're close to land it. So, basically we should decide if the benefits of the cache support outweigh its addition.