Initial go at localizing some components

[chandlerprall]

Converts a number of text locations to use EuiI18n.

Couple notes:

• we need a lint rule to validate usage outside of TypeScript
• As @pugnascotia expected, I did hit a couple locations where I'd expect the localization will affect the placement of variables. Specifically these are (& linked to the change)
  • EuiSuperSelect
  • EuiComboBoxPill
  • EuiComboBoxOptionsList

I updated EuiI18n's default prop to accept a function which consumes a passed values object and returns the formatted text/element. The other option (as Rory suggested) is have a formatter function be exposed through the EuiContext. This would let the default messages be forwarded directly to e.g. react-intl. I tried bringing react-intl directly into EUI to allow defaults to be processed by it for a cleaner API, but it doesn't look like you can get JSX in messages without directly using their FormattedMessage component. The other way to go instead is to throw away EuiI18n and use react-intl directly in EUI, with the hard dependency it brings - the API surface is largely the same, basically replacing EuiI18n -> FormattedMessage.

Thoughts @snide @pugnascotia ?

[snide]

@chandlerprall and I chatted briefly over Slack on this. He's gonna reach out to people on the downstream consumer teams to get feedback (since I'm the least helpful here). There's no need to rush into decisions and we can wait a day before going nuts in the repo.

Exciting that even given the syntax questions, we're able to cover so much of the repo so quickly. That's always a good sign :)

[pugnascotia]

So where are we at with react-intl? It's attractive to have less code to maintain, especially when the APIs seem to be converging.

[chandlerprall]

EUI will not be including react-intl - there is a necessity to keep our implementation untangled from whatever solution Kibana may be using. I've updated this PR to solidify the described methods of formatting localized strings, and have also added (but need to update the PR description) support for placeholders in those strings, e.g.

<EuiI18n
  token=""
  default="{greeting}, {name}"
  values={{ greeting: 'Hello', name: 'Rory' }}
/>

This PR is technically ready for review but blocked for merging by elastic/kibana#24707 to add enzyme support for React's new context API.

[chandlerprall]

@pugnascotia this is fully ready for review. The conflicts are around the original I18n revert which is now ready to be re-reverted.

[pugnascotia]

Is this getting localised too? Not obvious that it is.

[chandlerprall]

No, activityLabel is used in forming the tokens later. However, how I'm using it here breaks the planned static analysis of tokens, I'll refactor.

[pugnascotia]

In case whitespace matters:

Suggested change

	default={` When you're done, press Escape to stop ${activity}.`}
	default={`When you're done, press Escape to stop ${activity}.`}

[pugnascotia]

Should ENTER be localised?

[chandlerprall]

It is still localizable, the consumer can ignore that default value in their formatting:

'euiComboBoxOptionsList.createCustomOption': ({ searchValue }) => {
  return i18n.translate(
    'common.ui.euiComboBoxOptionsList.createCustomOption',
    {
      defaultMessage: 'Hit <EuiCode>ENTER</EuiCode> to add {searchValue} as a custom option',
      values: { searchValue // forwarded from EUI's call into this function }
    }
  );
}

Since react-intl allows JSX in the translations, the key value can be ignored and the localized value put directly into the message.

[pugnascotia]

Ooof, not handling item/items? :-P

[chandlerprall]

Wasn't going to refactor any logic as part of this :-D

[pugnascotia]

Personal style choice - since each branch here returns, I'd remove the else nits. No big deal though.

[chandlerprall]

Updated to remove else blocks.

[pugnascotia]

How come?

[chandlerprall]

Updated code to use a type cast instead of completely ignoring the line to better communicate intent.