Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling Globalize with cldr/supplemental data being accessible #41

Open
harel opened this issue Mar 11, 2017 · 3 comments
Open

Compiling Globalize with cldr/supplemental data being accessible #41

harel opened this issue Mar 11, 2017 · 3 comments

Comments

@harel
Copy link

harel commented Mar 11, 2017

I'm having a problem using the globalize-webpack-plugin when production is set to true.
My application allows switching locales on the fly. It also looks at some cldr data within globalize in a couple of instances (to pull current locale's time format or the current locale's first day of the week.

For example, when locale is a loaded Globalize instane:
locale.cldr.get('supplemental').weekData
or
locale.cldr.supplemental.timeData.preferred()

However, although it works fine when production is false, once i set it to true and build, the compiler, and rightly so, omits the cldr attribute from the compiled Globalize.
I can see that the globalize compiler allows compiling with cldr data in, but I can't see how to tell the webpack plugin to do this.

Any ideas? Or is there an alternative way to have those data points available in the compiled instance?

Update: If i fudge those values in my source, to progress with the runtime, my app then fails to parse any messages, and in some cases parses data from the wrong file (a few sparse cases).

@harel
Copy link
Author

harel commented Mar 12, 2017

After reading a lot of issues related to this, and even more experimentation, I came up with this (please correct me if I'm wrong):

I can set production to true, and have globalize compiled as well as my lang files included in the app, but i cannot, for example, do something like:

user.locale = Globalize
user.locale.formatMessage('something')

Only items that were called directly as Globalize.formatMessage('something') will be compiled.

I can run with production = false, but none of the lang files are compiled and I need to manually load up the json file and set it into the Globalize object.

So another part of this question is how do I run "normal" globalize (not runtime/compiled version)? Do I need the webpack plugin at all in that scenario?

@rxaviers
Copy link
Owner

rxaviers commented Mar 12, 2017

user.locale = Globalize
user.locale.formatMessage('something')

Correct, the static parser isn't able to understand this, therefore this won't be compiled for production.

For example, when locale is a loaded Globalize instane:
locale.cldr.get('supplemental').weekData
or
locale.cldr.supplemental.timeData.preferred()

Can you use formatters instead? Could you give a little of more details about why do you need that data?

@harel
Copy link
Author

harel commented Mar 12, 2017

In one instance I am using the locale data to get first day of the week for a calendar, and in another I'm formatting just the hour portion of a calendar time based on the preferred hour format of the locale. I also have a mixin that provides a _msg function which attempts to format a message and returns the [key] if its not there.

So am I correct in assuming that in order for me to use this, I have to either use uncompiled Globalize (which I assume is what you mean by 'normal', or for a compiled version I need to explicitly:

  • Import Globalize into any file that uses it (Do i need to .locale(lang) in each file?)
  • call all formatting functions direct from the Globalize class
  • not use the mixin for translations and call formatMessage direct from Globalize
  • manually load up the locale lang files and load it into Globalize

If I do insist on using the mixin, will I have to actually manually formatMessage each key in the lang file in order for them to get picked up by the compiler?

is that correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants