ember-intl: "Message can not be parsed" warning on specific locale

Environment

  • Ember Version: 3.10.1
  • Ember CLI Version: 3.10.1
  • Ember Intl Version: 3.5.2

Steps to Reproduce

I have ypk-us-ak locale (stands for Yupik lang) in my app. But for some reason I get warning in build time:

WARNING: [ember-intl] ypk-us-ak: "dayCount" message can not be parsed: Cannot read property 'indexOf' of undefined

NOTE: it happens only if pluralization is involved. Translation works, despite of warning.

Repo with replication: https://github.com/yratanov/intl-bug

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 15 (13 by maintainers)

Most upvoted comments

@yratanov @maxymczech it appears in both of your scenarios these are invalid locales. Surprised there isn’t warnings that this is invalid - may need to fix that bug separately.

https://github.com/unicode-cldr/cldr-core/blob/34.0.0/availableLocales.json

Also, we should filter out invalid locales when validating messages at build time. https://github.com/ember-intl/ember-intl/blob/d6973ebb100611363ad16c27be4b92a28a848a9a/lib/broccoli/translation-reducer/utils/validate-message.js#L33-L47

I now warn and skip message validation for invalid/unknown language codes. Will be versioned in 5.1.1. Thanks

Bruh, thank you very much, renaming cz.json to cs.json instantly solved the problem. The app worked perfectly fine with the wrong locale by the way. Would be nice to fix that error message.

@jacobq it’s marked as wontfix because as of ember-intl@5 we no longer bundles pluralization rules - they all come from the runtime wherever your app is run in.

One way to detect if your locale is supported is run: Intl.DateTimeFormat.supportedLocalesOf('jp') - in your browser(s) you target to make sure you’re dealing with a real locale. If it returns the locale then it’s a real locale that’s supported in your targeted runtime.

Perhaps in the future I can do this at build time by comparing against this list but I’m unsure how accurate that is with all the browser vendors.

@maxymczech definitely, I created a separate issue for tracking that bug #1097

Going to close this one for now, thanks for reporting everyone!