More metadata

[mattkime]

addresses #80

adds ability to configure additional metadata fields and whether they're required.

fields: For specifying additional metadata fields and whether they're required. Takes an object with field names as key names, which specify whether they're required. fields: { metadata: { required: true }, otherdata: {required: false} }

[mattkime]

changed this test to rely on deepEqual instead of text string content. different object key order was breaking tests

[mattkime]

this is breaking tests in older node versions

[ericf]

@mattkime thanks for working through this! I want to have a deeper understanding of your use cases so I can internalize them. Could you provide some real world examples of defineMessages and <FormattedMessage> that shows how you plan to use this feature?

[mattkime]

We'll have a field that references a story or epic in our ticketing system - jira='MW-123'. This helps provide context for translating to new languages down the road.

[ericf]

I'm most interested to see a JSX and/or JS example of exactly what you're thinking.

[mattkime]

@ericf Does this clarify?

<FormattedMessage
     id='abc1234'
     description='card title'
     jira='MW-1234'>
     Article: {title}
</FormattedMessage>

but this is obviously only one side. The other half is extracting the data and providing it to the translators.

[ericf]

Hmm… there's something here I'm not liking about expanding the props of <FormattedMessage>. But I do see the value in structured metadata. What if description could be any value as long as it can be statically evaluated and is JSON-serializable string or object?

<FormattedMessage
  id='abc1234'
  description={{
    text: 'card title',
    jira: 'MW-1234',
  }}
  defaultMessage='Article: {title}'
/>

And this would extracted to:

[{
  "id": "abc1234",
  "description": {
    "text": "card title",
    "jira": "MW-1234"
  },
  "defaultMessage": "Article: {title}"
}]

[mattkime]

Sounds good, I'll take another swing at the pr

…

On Thu, Dec 22, 2016 at 3:06 PM Eric Ferraiuolo ***@***.***> wrote: Hmm… there's something here I'm not liking about expanding the props of <FormattedMessage>. But I do see the value in structured metadata. What if description could be any value as long as it can be statically evaluated and is JSON-serializable? <FormattedMessage id='abc1234' description={{ text: 'card title', jira: 'MW-1234', }} defaultMessage='Article: {title}' /> And this would extracted to: [{ "id": "abc1234", "description": { "text": "card title", "jira": "MW-1234" }, "defaultMessage": "Article: {title}" }] — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMcNC76AKHEs-h-wDXhNx3DullLxDkks5rKuZfgaJpZM4LToXY> .

[mattkime]

I verified that this works for extraction as long as I get rid of a trim() call.

The next step is providing for some sort of verification of the description fields. i'd like to provide a function to enforceDescriptions.

[ericf]

I verified that this works for extraction as long as I get rid of a trim() call.

The description should be type-checked and only call trim() if it's a string.

The next step is providing for some sort of verification of the description fields. i'd like to provide a function to enforceDescriptions.

This would likely only be possible if you use Babel via its API. Since .babelrc files need to be JSON, you can't provide a function. I think verifying the existence of the description is within the scope of this plugin, but validating its contents should be up to your build to post-process the .json files.

[ericf]

Closing in favor of #87