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

Missing locale data for: "en-US". Using default locale: "en" as fallback. #204

Closed
catamphetamine opened this issue Nov 3, 2015 · 5 comments · Fixed by #282
Closed

Missing locale data for: "en-US". Using default locale: "en" as fallback. #204

catamphetamine opened this issue Nov 3, 2015 · 5 comments · Fixed by #282

Comments

@catamphetamine
Copy link

[React Intl] Missing locale data for: "en-US". Using default locale: "en" as fallback.
@catamphetamine catamphetamine changed the title [React Intl] Missing locale data for: "en-US". Using default locale: "en" as fallback. Missing locale data for: "en-US". Using default locale: "en" as fallback. Nov 3, 2015
@catamphetamine
Copy link
Author

I found the cause of the error:

<IntlProvider locale={locale} messages={messages}>

It doesn't support a properly formatted locale.

A workaround:

function get_language(locale)
{
    const dash_index = locale.indexOf('-')
    if (dash_index >= 0)
    {
        return locale.substring(0, dash_index)
    }
    return locale
}

// not real locale
<IntlProvider locale={get_language(locale)} messages={messages}>

@ericf
Copy link
Collaborator

ericf commented Nov 3, 2015

You'll need to load locale-data/en.js to get support for en-US. By default only the root, en locale data is provided.

It doesn't support a properly formatted locale.

This is incorrect. The locale data files are provide per language, e.g. en.js, but they contain data for all locales in that language, e.g. en-US, en-GB, etc.

@ericf ericf closed this as completed Nov 3, 2015
ericf added a commit to ericf/react-intl that referenced this issue Jan 13, 2016
This is a major refactor of React Intl's build and npm package
layout.

Locale data is now package-relative and can more easily be loaded:
```js
import enLocaleData from 'react-intl/locale-data/en';
```

There is now only one copy of these locale data files in the package
and they are UMD modules which export the locale data for a language.

Rollup is now being used to build a _single-file_ React Intl module
for three different targets:

- `ReactIntl` global: Browser build with bundled dependencies
- CommonJS (`main`): For Node/Browserify/Webpack with `require()`-d
dependencies
- ES6 (`jsnext:main`): For consumption via `import` with `import`-d
dependencies

All of the builds are compiled with Babel and bundled into a single
module file. Rollup is used to fold all of the internal `src/`
modules into one. The difference between `lib/index.js` and
`lib/index.es.js` is the latter has everything compiled expect the
`import`/`export` statements for React Intl as a whole package.

The `.babelrc` files have been moved to closer to the source code
which they apply. This allows for test or example code to leverage
experimental ECMAScript syntax without leaking it into the main src.

These changes should result is a smaller and faster package as all of
React Intl's code is folded into a single module scope, and the Babel
helpers are only included once (instead of per module file). As well
as fixing support for IE8.

Fixes formatjs#203
Fixes formatjs#204
Fixes formatjs#275
Fixes formatjs#277
ericf added a commit to ericf/react-intl that referenced this issue Jan 13, 2016
This is a major refactor of React Intl's build and npm package
layout.

Locale data is now package-relative and can more easily be loaded:
```js
import enLocaleData from 'react-intl/locale-data/en';
```

There is now only one copy of these locale data files in the package
and they are UMD modules which export the locale data for a language.

Rollup is now being used to build a _single-file_ React Intl module
for three different targets:

- `ReactIntl` global: Browser build with bundled dependencies
- CommonJS (`main`): For Node/Browserify/Webpack with `require()`-d
dependencies
- ES6 (`jsnext:main`): For consumption via `import` with `import`-d
dependencies

All of the builds are compiled with Babel and bundled into a single
module file. Rollup is used to fold all of the internal `src/`
modules into one. The difference between `lib/index.js` and
`lib/index.es.js` is the latter has everything compiled expect the
`import`/`export` statements for React Intl as a whole package.

The `.babelrc` files have been moved to closer to the source code
which they apply. This allows for test or example code to leverage
experimental ECMAScript syntax without leaking it into the main src.

These changes should result is a smaller and faster package as all of
React Intl's code is folded into a single module scope, and the Babel
helpers are only included once (instead of per module file). As well
as fixing support for IE8.

Fixes formatjs#203
Fixes formatjs#204
Fixes formatjs#275
Fixes formatjs#277
ericf added a commit to ericf/react-intl that referenced this issue Jan 13, 2016
This is a major refactor of React Intl's build and npm package
layout.

Locale data is now package-relative and can more easily be loaded:
```js
import enLocaleData from 'react-intl/locale-data/en';
```

There is now only one copy of these locale data files in the package
and they are UMD modules which export the locale data for a language.

Rollup is now being used to build a _single-file_ React Intl module
for three different targets:

- `ReactIntl` global: Browser build with bundled dependencies
- CommonJS (`main`): For Node/Browserify/Webpack with `require()`-d
dependencies
- ES6 (`jsnext:main`): For consumption via `import` with `import`-d
dependencies

All of the builds are compiled with Babel and bundled into a single
module file. Rollup is used to fold all of the internal `src/`
modules into one. The difference between `lib/index.js` and
`lib/index.es.js` is the latter has everything compiled expect the
`import`/`export` statements for React Intl as a whole package.

The `.babelrc` files have been moved to closer to the source code
which they apply. This allows for test or example code to leverage
experimental ECMAScript syntax without leaking it into the main src.

These changes should result is a smaller and faster package as all of
React Intl's code is folded into a single module scope, and the Babel
helpers are only included once (instead of per module file). As well
as fixing support for IE8.

Fixes formatjs#203
Fixes formatjs#204
Fixes formatjs#275
Fixes formatjs#277
ericf added a commit to ericf/react-intl that referenced this issue Jan 14, 2016
This is a major refactor of React Intl's build and npm package
layout.

Locale data is now package-relative and can more easily be loaded:
```js
import enLocaleData from 'react-intl/locale-data/en';
```

There is now only one copy of these locale data files in the package
and they are UMD modules which export the locale data for a language.

Rollup is now being used to build a _single-file_ React Intl module
for three different targets:

- `ReactIntl` global: Browser build with bundled dependencies
- CommonJS (`main`): For Node/Browserify/Webpack with `require()`-d
dependencies
- ES6 (`jsnext:main`): For consumption via `import` with `import`-d
dependencies

All of the builds are compiled with Babel and bundled into a single
module file. Rollup is used to fold all of the internal `src/`
modules into one. The difference between `lib/index.js` and
`lib/index.es.js` is the latter has everything compiled expect the
`import`/`export` statements for React Intl as a whole package.

The `.babelrc` files have been moved to closer to the source code
which they apply. This allows for test or example code to leverage
experimental ECMAScript syntax without leaking it into the main src.

These changes should result is a smaller and faster package as all of
React Intl's code is folded into a single module scope, and the Babel
helpers are only included once (instead of per module file). As well
as fixing support for IE8.

Fixes formatjs#203
Fixes formatjs#204
Fixes formatjs#275
Fixes formatjs#277
@SachaG
Copy link

SachaG commented Jun 9, 2016

I just ran into this issue. So just to clarify, in the following snippet fr works but fr_FR doesn't:

import fr from 'react-intl/locale-data/fr';
import { addLocaleData } from 'react-intl';
addLocaleData([...fr]);
...
<IntlProvider locale="fr" messages={myStrings}>

Is that the expected behavior? What would I need to do if I did want to use fr_FR or fr_CA instead?

@ericf
Copy link
Collaborator

ericf commented Jun 9, 2016

@SachaG The locale needs to be a BCP-47 language tag. Replace _ with -.

@mccrodp
Copy link

mccrodp commented Feb 19, 2018

Hey @ericf, thanks for your answers. I am getting this in Gatsby w/ community i18n plugin. I have added the locale-data as you can see here, but I still get the below error. Any more specific ideas to what is missing? I have only de and en-US langs set, no en at the moment as it's not my repo.

commons.js:77217 [React Intl] Missing message: "selectLanguage" for locale: "en-US"
commons.js:77217 [React Intl] Missing message: "selectLanguage" for locale: "de"
commons.js:77217 [React Intl] Missing message: "selectLanguage" for locale: "en"

This seems to be workign now via:

import { addLocaleData } from 'react-intl';

import en from 'react-intl/locale-data/en';
import 'intl/locale-data/jsonp/en';

addLocaleData(en); // It seems this also adds "en-US" locale?

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jul 20, 2021
And clarify that it's an "IETF BCP 47 language tag" [1].

`react-intl`'s doc on `IntlProvider` doesn't currently say that this
is the kind of thing it wants for the `locale` prop [2]. But it
seems likely:

- In 2016, a GitHub "collaborator" said, "The locale needs to be a
  BCP-47 language tag" [3].

- @formatjs's doc on something else, the `IntlMessageFormat`
  constructor in the `intl-messageformat` package, takes a
  similarly-named parameter, `locales` that's documented with, "A
  string with a BCP 47 language tag, or an array of such
  strings" [4].

And include a migration, to preserve the user's current setting
across the rename.

[1] https://en.wikipedia.org/wiki/IETF_language_tag
[2] https://formatjs.io/docs/react-intl/components#locale-formats-and-messages
[3] formatjs/formatjs#204 (comment)
[4] https://formatjs.io/docs/intl-messageformat/#intlmessageformat-constructor
gnprice pushed a commit to chrisbobbe/zulip-mobile that referenced this issue Jul 20, 2021
And clarify that it's an "IETF BCP 47 language tag" [1].

`react-intl`'s doc on `IntlProvider` doesn't currently say that this
is the kind of thing it wants for the `locale` prop [2]. But it
seems likely:

- In 2016, a GitHub "collaborator" said, "The locale needs to be a
  BCP-47 language tag" [3].

- @formatjs's doc on something else, the `IntlMessageFormat`
  constructor in the `intl-messageformat` package, takes a
  similarly-named parameter, `locales` that's documented with, "A
  string with a BCP 47 language tag, or an array of such
  strings" [4].

And include a migration, to preserve the user's current setting
across the rename.

[1] https://en.wikipedia.org/wiki/IETF_language_tag
[2] https://formatjs.io/docs/react-intl/components#locale-formats-and-messages
[3] formatjs/formatjs#204 (comment)
[4] https://formatjs.io/docs/intl-messageformat/#intlmessageformat-constructor
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

Successfully merging a pull request may close this issue.

4 participants