[add data] prototype for string resources

[BigFunger]

Prototype Only

Adds string resources to the application. This allows us to define string resources outside of the views in which they are consumed.

This could also be modified in the future to create an i18n/l10n system.

This strings are stored in a registry that can added to by anywhere in the system.

Moving parts

• A 'resource' string filter is added
• A 'string_resources' webpack shim is added. This would need to be imported into any directive that uses string resources.
• A string_resources.js file is added in src/ui/public. This is where the key/values are defined.

.../add_data_steps/pipeline_setup/string_resources.js

import registry from 'ui/string_resources/registry';

registry.register({
  addData: {
  pipelineSetup: {
    headerTextCallout:
      'Let\'s build a pipeline!'
    ...
  }
}

.../pipeline_setup/index.js

...
import './string_resources';
...

.../views/pipeline_setup.html

...
<!-- Use the resource filter and a dot separated property name to access a string in the resources file -->
<em ng-bind="'addData.pipelineSetup.headerTextCallout' | resource"></em>
...

.../directives/filebeat_wizard.js

...
import 'string-resources'; //webpack shim
...

[Bargs]

Using es6 backticks would eliminate the need for +'s at the end of each line.

[Bargs]

I was thinking about it some more, and I think the Angular filter is ok if it remains a thin layer over a plain module that does the real internationalization work down the road. This way we can have the convenience of the filter in Kibana, but other plugins that might use different view technology can still make use of and add to the module.

Along those lines, should we make this pluggable now? I'm thinking plugins should be able to both add and consume resource strings, and the strings should be namespaced with the name of the plugin that added them.

One last thought at the moment. Could/should we combine this with the dynamic doc links module? #6989

[BigFunger]

I moved the strings into a registry and added them to a few more pages to get a better feel for what this would look like across the application.

[rashidkpc]

Why use a filter instead of a directive here?Using {{}} all over the place will cause all of those expression to be dirty checked and the filter to be re-evaluated with every $digest cycle. What about something like

<button
  class="btn btn-primary"
  ng-click="wizard.nextStep()">
  kbn-text="commonButtons.next"
</button>

Interestingly, in the future, you could expand the role of the thing passed to kbn-text to include meta data. You could make it an object instead of a string and supply tooltip and aria values to be added to the element, which would simplify the markup.

[rashidkpc]

Also, much discussion has been had on this subject in this thread: #6515

[rashidkpc]

@epixa your thoughts on the design here would be helpful

[epixa]

What's the motivation here in the context of add data?

[Bargs]

@epixa this came up during a couple of discussions about in-page documentation for the Add Data wizards (#6851). Ideally the user will be able to use the wizards without getting dumped to outside documentation, so we plan on adding lots of help text to the page.

@debadair told us this help text would be easier for the docs team to review and help manage if it were pulled out into separate string resource files. There are obvious benefits for internationalization down the road as well, but we're not trying to solve that entire problem here. Mainly we're just trying to get static text out of the html templates.

[epixa]

That makes sense, thanks!

The biggest concern I have is that we're using JS modules as a state management system - simply importing the registry results in an essentially-global, mutable singleton. I recommend at the very least changing ui/string_resources/registry to a function that returns a new registry object, and then we could invoke that function once during setup and expose it through angular's DI system.

I don't think these configurations should be created during runtime, either. Instead, we should put configuration like this inside static configuration files (json or yml) that we then load into memory at startup. This would allow us to develop more tooling around the configuration itself without being coupled to a running instance of Kibana, and it would also mean that we could handle errors in parsing configuration in helpful ways, whereas something like a missing comma in the current implementation would just crash the entire application.

Finally, overall this seems like something that could be handled statically at build time rather than on the client at runtime. This whole implementation would essentially become a devDependency, and there would be no lingering issues with or concerns for performance impacts in production builds.

[Bargs]

@epixa @BigFunger perhaps we should chat over zoom or IRC about this. I have a few questions before we dive too deep:

• How much of this do we want to tackle in the context of Add Data?
• Is a partial solution worse than no solution at all? Or can we build something that's a step in the right direction without building a full i18n system right now.
• @debadair this one is for you. Internationalization aside, would your team benefit simply from having text snippets all in one place inside Kibana, rather than scattered throughout html templates? Just wondering how much benefit we'll gain here taking a step towards a better system vs. waiting till we have time to tackle the problem in full.

[srl295]

OK, yes we just opened the PR #7247 for issue #6515 - need to combine efforts of course.

[Bargs]

Yeah now that I look at that PR and issue, there's a huge amount of overlap. Given that prototyping is already under way in #7247 it seems kinda foolish to reproduce that work here. Unless anyone has a compelling argument to the contrary, I think we should forget about trying to implement some half measure in Add Data that's just going to get thrown away after #6515 is complete.

[epixa]

No objections here. For now, let's just put the add data help info directly into the templates.