i18n of every static text strings

[emmacunningham]

Is your feature request related to a problem? Please describe. In https://github.com/elastic/elastic-charts/pull/219, text is used to inform the user that there is no chart to render because they have deselected all series. This text should probably be localized, but it's probably easiest if elastic-charts doesn't handle the localization itself but rather receives a prop for the text so the consumer is responsible for localization.

Describe the solution you'd like A way to pass in localized text for areas where we currently have hardcoded text strings (so far #219 is the first instance that I can think of where we have this).

Describe alternatives you've considered Never use text strings anywhere in elastic-charts :) The no data state could be just an icon. (But then there are accessibility issues.)

Additional context

Kibana Cross Issues

Checklist

• [x] this request is checked against already exist requests
• [x] every related Kibana issue is listed under Kibana Cross Issues list
• [x] kibana cross issue tag is associated to the issue if any kibana cross issue is present

[emmacunningham]

@markov00 curious what you think about how to handle this small bit of text and localization. Besides this, the only other place where I think text could come up is in warnings concerning configuration issues.

[markov00]

Hey @Bamieh, do you have any idea on how we can handle this? What do you suggest?

There are some other points where we will need to localize text in the future:

• we want to add some sort of loading state (maybe it will be just a simple icon indicator but will require some accessibility text)
• accessibility: we need also to include some automated description on charts like:

  this chart shows 3 line series and 1 bar series, the 3 line series are: A, B, C, the bar series is: D. The max values for A is 10, min 2 etc etc.

• we are also looking at the possibility to add some hints on the chart configuration to the user like: "hey your pie chart has too many slices, please reduce it to 5 max" or similar hints.

[flash1293]

Sorry for just chiming in here :)

What's wrong with passing in locale information (e.g. <Chart locale="de-DE" ... />)?

On a first glance it looks like passing in locale information is sufficient because elastic-charts knows better how to phrase certain things than a consumer would - seems like a cleaner separation of concerns IMHO. Detecting/defining the correct locale would still be the responsibility of the consumer.

An advantage of passing in texts instead of just a locale is that the consumer can rephrase texts if it makes sense for their use case, but with the disadvantage of each consumer having to pass in translations which multiplies i18n efforts if there is more than one (localized) consumer.

[Bamieh]

Currently we do not support localization in outside packages. If possible, I highly encourage for allowing the user of the package (ie kibana) to pass the localized strings instead of hosting them in here. Or introducing a binding layer of some sort for package users to customize strings, then we'd be able to localize elastic-charts from kibana.

Currently kbn-i18n package is hosted inside kibana, along with all the tools for validating and extracting labels. Our process for extracting strings and scheduling with translators is adapted around the stack releases. The process is still getting refined and I'm afraid introducing more factors would further increase the complexity.

Another idea is to have our kibana tools parse elastic-charts translation labels from inside node_modules. This way we can have external labels but the tooling and process are still inside kibana.

CC @bmcconaghy @azasypkin

[bmcconaghy]

Definitely agree that the best thing would be to have Kibana code pass in the localized strings. Failing that, the idea to parse elastic-charts in node_modules with Kibana tools seems like it might work, we'd just have to investigate and see if there are issues with it.

[azasypkin]

Currently we do not support localization in outside packages. If possible, I highly encourage for allowing the user of the package (ie kibana) to pass the localized strings instead of hosting them in here. Or introducing a binding layer of some sort for package users to customize strings, then we'd be able to localize elastic-charts from kibana.

++, that gives consumer of the lib a choice of i18n framework and localization processes they would like to rely on and doesn't force elastic-charts to deal with some specific i18n framework, l10n processes keeping it more lightweight and easier to maintain in the long run.

EUI is dealing with i18n in this manner allowing both Kibana and Cloud UI to decide how i18n/l10n is done and I haven't heard of any issues with that approach yet. For example, we're getting pseudo-localization support in EUI for "free" since EUI is just consuming pseudo-localization "i18n tokens" Kibana gives to it. Also Kibana is going to support many more languages in the future and if all independent packages/components are going to maintain their own translations we'll need to somehow coordinate these efforts and we may end up with a huge mess instead :)

[nickofthyme]

@Bamieh do you know if kibana still does not support localization in outside packages? We recently have more use cases for this and are just passing the localized strings to charts.