`formatMessage` with deep paths

• I am on the latest ember-intl version
• I have searched the issues of this repo and believe that this is not a duplicate

Environment

• Ember Version: 3.16.8
• Ember CLI Version: 3.16.2
• Ember Intl Version: 5.3.1
• Browser(s): Chrome / Firefox
• Node Version: 12.18.1

Steps to Reproduce

Calling intel.formatMessage referencing properties on nested objects using dots doesn’t work. I’m not sure if this is intended to work or not but:

// This works:
this.intl.formatMessage(`Hello {foo}!`, { foo: 'world' }); // Hello world!
// But this doesn't
this.intl.formatMessage(`Hello {foo.bar}!`, { foo: { bar: 'world' } }); // SyntaxError: Expected "," but "." found.

Using t allows me to reference a nested object:

this.intl.t('foo.bar', { foo: { bar: 'Hello world!' } }); // Hello world!

But I want to take a complete string and substitute out the dynamic portions (which I guess is what formatMessage is for?).

I’ll dig a bit deeper but I wanted to check if this was expected behavior or if there was a better way to achieve what I’m trying to do?

[vitch]

Thanks for the reply.

I’ve had a look around and haven’t found another implementation which supports deep objects. Even things which support yaml seem to show flat objects. This kind of surprises me but makes me think that trying to use nested objects will involve swimming upstream.

I could pre-process my data (I was using this for dynamic string interpolation with support for pluralisation etc rather than straight up translation) and templates to e.g. flatten the objects and replace relevant .s with _s but I will first think about what it would be like to only use flat data.

Thanks again - we can close this if you’d like since I don’t think there is much that can be done about it in this repo…

[jasonmit]

Was it an intentional addition to the behaviour of t in this repo?

To support nested translations? Yes, this was intentional but also in a different scope than the intl-messageformat compiler. The parser/compiler never deals with translation keys just translation messages.

I’m guessing that the addition of . in property names will be a hard sell upstream

I’d look into other messageformat implementations (most languages have a library) and see if any accept argument types referring to a deep object. If so, it might help the argument. I’m also unsure if even the ICU msg format spec supports it - I’d also investigate that.