Interpolation doesn't work with invalid initialLocale

[marekdedic]

Describe the bug
Hi,
I have an app that gets its initial locale populated (via string replacement) by the server at runtime (weird, I know...) and a fallback locale set manually to "en". I noticed after an update that when the intialLocale doesn't get populated (e.g. in tests) and is therefore invalid, formatting still works (using the fallback locale), but interpolation stops working, showing property names (i.e. {myValue}) instead of the actual values.

To Reproduce
TBD...

To help us help you, if you've found a bug please consider the following:

• Please create a small repo that illustrates the problem.
• Reproductions should be small, self-contained, correct examples – http://sscce.org.

Occasionally, this won't be possible, and that's fine – we still appreciate you raising the issue. But please understand that svelte-preprocess is run by unpaid volunteers in their free time, and issues that follow these instructions will get fixed faster.

Expected behavior
Interpolation works and the fallback locale is used

Information about your project:

• Your browser and the version: Electron 106

• Your operating system: Debian testing

• svelte-i18n version: Works in 3.2.0, broken in 3.4.0

• Whether your project uses Webpack or Rollup: Webpack

[marekdedic]

By bisecting this repo, I have verified that the issue was introduced in d1d0306 - this is quite strange...

[marekdedic]

Ok, turns out that in the process of switching to pnpm, intl-messageformat got updated from 9.12.0 to 9.13.0 - if I pin it to 9.12.0, the issue is fixed

[brunnerh]

For me it did not work on the server even when setting the locale option explicitly to a valid locale.

E.g.

format('key', { values: { ... }, locale: 'en' })

Message was resolved, but values were not replaced, with a console error being logged:

[svelte-i18n] Message "..." has syntax error: n is not a constructor

Downgraded the package for now...

[marekdedic]

Hi,
I have submitted a fix in #217

[kaisermann]

As @brunnerh commented on #228, adding the canonical locales package seems to be unnecessary to fix the issue. Can any of you provide a minimal repro of the issue?

Also, we can use IntlMessageFormat.resolveLocale which is already in the library for validating the locale.

[kaisermann]

Released 3.7.3 which should help with both issues: #229

[marekdedic]

Thanks for the fix and sorry for the trouble!

[brunnerh]

What I observed appears to have a different source. Somehow the modules are resolved the wrong way.

My application's import resolves to node_modules/svelte-i18n/dist/runtime.cjs.js which has:

var IntlMessageFormat = require('intl-messageformat');
....
IntlMessageFormat.resolveLocale
...
new IntlMessageFormat(message, ...)

But the require('intl-messageformat') is resolved in such a way, that IntlMessageFormat is an object with a default property which contains the actual class, so the new IntlMessageFormat/IntlMessageFormat.resolveLocale errors. There probably is some mixing of CJS and ESM going on (this is always such a pain).

Unfortunately, I have not been able to create a minimal reproduction so far.
This should probably be tracked in a separate issue.

---

The logged errors could maybe be more generic, as these are lies:

[svelte-i18n] The initial locale "de" is not a valid locale.
[svelte-i18n] Message "..." has syntax error: IntlMessageFormat is not a constructor