Kibana Globalization - Phase 2 - React

[Bargs]

#8766 Provided access to translations client side and integrated angular-translate for translating angular views.

We need to develop a similar mechanism for translating React views.

@cjcenizal @stacey-gammon @weltenwort as React proponents perhaps one of you has prior experience translating React components? Are there any libraries similar to angular-translate that we could use?

[cjcenizal]

I have no experience with internationalizing React apps, and very limited experience with internationalization in general.

[stacey-gammon]

No specific experience internationalizing a React app. I did work on a project that used a translation service for vanilla js (plus c++), though I think we used an internal tool to apply them, so no help there.

Angular-translate doesn't provide the translations, right? Just the mechanism to apply them?

Perhaps we need to be looking at a mechanism that is not framework specific, but could eventually be used in both. https://github.com/i18next/i18next looks interesting.

[weltenwort]

So far all React projects I worked on successfully used higher-order components that inject a translation function into the wrapped component. https://github.com/i18next/react-i18next provides such a HOC for integration with i18next.

[kimjoar]

In Cloud UI we've used https://github.com/yahoo/react-intl. But we haven't "pushed it enough" to have a feel for it's "edges".

[Bargs]

@kjbekkelund do you use Format.js as well or is react-intl a module you can use standalone?

[Bargs]

@hickeyma @spalger while looking into solutions for translating react components I've begun to realize we skipped a beat in phase 2. Right now we feed our translations directly into angular translate. This couples our translation bundle format (and any future number/date/currency conversion rules) to angular translate. I think we need to use a UI framework agnostic library (like i18next or Format.js) to consume the translation bundles and provide localized strings to the UI framework. This way we can ensure the localization output will always be the same regardless of which UI framework is consuming the translations.

[kimjoar]

We use format.js (via react-intl)

[spalger]

Good call @Bargs. What do you think @hickeyma? Any chance you want to try it out and send a PR?

[hickeyma]

@Bargs, WRT #10823 (comment), the translation bundle is loaded into the client side at startup and available to be used by any process/framework etc. It is an object (translation id/translation string) which in the case of the angular-translate framework, it loads as part of its translations.

The object is independent of any framework. Any framework can load the object or query for a specific translation using the translation key.

Is this what you are asking about or have I missed the point?

[Bargs]

@hickeyma there's still an implicit dependency between the translations and the framework loading the translations. Take KIBANA-EXISTING_MATCH_PERCENT for example. This message supports variable replacement with the {{ }} syntax. Let's say we want to use a translation framework for React that expects variable replacements to use ${ } instead of {{ }}. Now we've got a problem.

Things may get even more messy if we want to advance from simple translations to things like localized date, number, and currency formats. From what I can tell, most translation frameworks support these through special rule sets per locale, and the rule sets probably look different for each framework.

We need an additional layer on the front end that can consume translation files and localization rule sets in a framework agnostic way. Each UI framework can then get its translations from this service's API instead of directly from the translation bundles.

I've only briefly looked at a few options so this needs some more research. At first glance I like that Format.js is built on top of standards. The downside is that there doesn't seem to be any existing angular integration, so we might have to build that ourselves if we went down that route.

[kimjoar]

I don't know the history around translations, but I can include a couple of examples of how our Cloud UI relies on format.js (through react-intl). We've been very happy with it so far, but there's definitely more technologies and legacy to consider for Kibana.

Pluralization example:

<FormattedMessage
  id='cluster-snapshots.shard-failures-heading'
  defaultMessage='{ failures, plural,
    =0 {No shard failures}
    one {1 shard failure}
    other {# shard failures}
  }'
  values={{
    failures: failures.length
  }} />

(more examples here: https://formatjs.io/guides/message-syntax/)

And being able to add html elements within a translation (here adding a <strong>), while maintaining full control:

<FormattedMessage
  id='plan-attempt-change.instance-capacity'
  defaultMessage='Change {instanceCapacity} from {from} to {to}'
  values={{
    instanceCapacity: (
      <strong>
        <FormattedMessage
          id='plan-attempt-change.instance-capacity-memory-per-node'
          defaultMessage='memory per node' />
      </strong>
    ),
    from: <em>{ prettySize(oldInstanceCapacity) }</em>,
    to: <em>{ prettySize(newInstanceCapacity) }</em>
  }} />

(we extract these defaultMessages into an en.json file, but they're actually nice for readability during development).

Would be fantastic to have something that works as smoothly as this for both React and Angular.

[Bargs]

Oh wow, I like how you can compose the FormattedMessages. It looks like we could possibly use the core libraries to cobble something together for Angular.

[hickeyma]

Ok, I think I get the picture now. You would like a globalization framework independent of the underlying UI framework (i.e. replace angular-translate with agnostic framework).

It makes sense as the example of variable replacement does pose problems outside of Angular.

[hickeyma]

@Bargs, Thinking further on this, I am wondering are we over complicating? Is this not equivalent to the #8766 (comment) about not having HTML tags in the translation strings? Should variables be part of the framework code (i.e. HTML ot JS) and not included in the agnostic translations?

[Bargs]

@hickeyma are you suggesting the translations not support dynamic text at all and instead we should break them into multiple translations surrounding the dynamic text like you did here with the html? I think that will be too cumbersome and it won't give translators enough power. Since different languages have different rules translators need to be able to move the dynamic part around within their sentence.

[hickeyma]

@Bargs I agree that could be cumbersome but this is what happens with the HTML tags. If index pattern view is anything to go by, then there is more tags within text to handle.

Lets have a discussion during the week to talk this out further.

[Bargs]

I already said in my review of the phase 2 PR that we need to figure out a better way to handle the html. Kim's example above shows one way of doing it.

[cjcenizal]

I've been working a lot with the existing translated text as part of my work on improving the "Create index pattern" flow (#12530). My experience underscores the point of this issue: I wanted to migrate our code to use React components for improved testability, but I was constrained by our dependency upon angular-translate.

I also agree that translators need the freedom to move HTML tags around and specify framework-agnostic variables within a translation string, as this was something I frequently encountered while working on #12530.

[cyberdak]

Any progress on this issue?

Recently I start a translate work on kibana, found something wired in "en.json", the key is not enough to complete the translate work.

Also found something can't do translate part . like thr route code in index.js,it is hard-code.

[Bargs]

@cyberdak Right now the work on the translation system is on the back burner. It'll be awhile before we have time to re-think and address the issues brought up in this thread.

[epixa]

I'm going to close this issue out in favor of #17201