GlobalizeCompiler does not work unicode extensions in locales.

[cahuja]

As per http://www.unicode.org/reports/tr35/#Locale_Extension_Key_and_Type_Data a locale should be able to handle unicode extensions such as

• ca (Calendar algorithm)
• cf (Currency format style)
• co (Collation style)
• cu (Currency type)
• em (Emoji presentation style)
• fw (First day of week)
• hc (Hour cycle)
• lb (line break style)
• lw (line break word handling)
• ms (measurement system)
• nu (numbering system)

Now, I know many of these options are not supported by Globalize, but I know we can atleast handle -u-nu (numbering system), -u-cu (currency type) and -u-cf- (currency format style)

When running this in the Globalize compiler, there is an assumption that the passed in locale would match the CLDR directory structure.

➜  node-sandbox ./node_modules/.bin/globalize-compiler -l ar-EG-u-nu-latn -o dest.js app.js        
fs.js:808
  return binding.readdir(pathModule._makeLong(path));
                 ^

Error: ENOENT: no such file or directory, scandir '/home/site/ExternalRepos/node-sandbox/node_modules/cldr-data/main/ar-EG-u-nu-latn'
    at Error (native)
    at Object.fs.readdirSync (fs.js:808:18)
    at jsonFiles (/home/site/ExternalRepos/node-sandbox/node_modules/cldr-data/index.js:36:22)
    at /home/site/ExternalRepos/node-sandbox/node_modules/cldr-data/index.js:60:21
    at Array.reduce (native)
    at mainPathsFor (/home/site/ExternalRepos/node-sandbox/node_modules/cldr-data/index.js:59:18)
    at Function.cldrData.entireMainFor (/home/site/ExternalRepos/node-sandbox/node_modules/cldr-data/index.js:90:29)
    at cldr (/home/site/ExternalRepos/node-sandbox/node_modules/globalize-compiler/lib/compile-extracts.js:30:57)
    at Object.compileExtracts (/home/site/ExternalRepos/node-sandbox/node_modules/globalize-compiler/lib/compile-extracts.js:55:18)
    at Object.<anonymous> (/home/site/ExternalRepos/node-sandbox/node_modules/globalize-compiler/bin/globalize-compiler.js:82:28)

How should I resolve this? The problem is that when using Globalize with the globalize-compiler and the webpack plugin, we are assuming that the locale passed to Globalize matches the CLDR data directory.

Any guidance would be helpful.

[rxaviers]

Globalize compiler, by default (i.e., when cldr property isn't provided), uses the npm cldr-data module (more specifically cldrData.entireMainFor( locale )) to get CLDR content. It's indeed not wise to use locale there, instead we should figure out the correct filepath.

I will post another comment with an approach to do that.

[rxaviers]

Related rxaviers/cldrjs#30

[cahuja]

The issue you have linked to describes a particular solution if your using Globalize server-side. When doing so, you can write node scripts and load a bunch of cldr content in memory.

However, I am using Globalize on the client and using webpack and the globalize webpack plugin (and consequently the globalize-compiler) to create intermediate outputs that will be packaged off to the client. In this scenario, when using the webpack globalize plugin, how do I get more fine tuned control of things like which numbering system I should use (or other unicode extensions).

[rxaviers]

As a related note, on globalizejs/globalize#758 @casey-speer said:

@rxaviers I see what you're saying. But this is what happens if I pass 'en-US' as the locale to the compiler:

Error: ENOENT: no such file or directory, scandir '/Users/cspeer/repos/i18n/node_modules/cldr-data/main/en-US'

Would it be possible to add a compiler step to map the given locale, e.g. en-US, to the normalized locale? My concern is that clients of my compiled formatters are able to use a consistent format for the locale string across locales.