If you are thinking of using Kibana in a language other than English then that is not a good idea right now. The fundamental problem is that the infrastructure for internationalization is not there and there is also the other issue of no localization. Don’t despair though, as help is on the way in the shape of excellent ongoing Elastic open source community work. Read on, if you want to find out more.


IBM leverages the open source Elastic Stack in a number of its offerings across units like Cloud, Cognitive and IoT. IBM strives to release offerings fully globalized with a defined set of supported languages. It therefore identified the globalization (combination of internationalization and localization) of Kibana as a core feature to be delivered. There had also been interest in the community for globalization as shown by this community issue raised. As “OpenByDesign” is IBM’s mantra and having long tradition in open source communities, it knew the best approach is to empower IBMers to become contributors and deliver the design and implementation directly into the community.


The journey involved many great discussions, prototyping and considerations! 🙂 The outcome of all this is a design which is an integrated framework for the federation of multiple globalization frameworks. This means an agnostic service which is independent of the underlying globalization frameworks, and therefore consumed by those frameworks instead of the translations directly. It should be noted that the design covers globalization of text strings on Kibana views and does not include data visualization yet. This will be covered in a future design document.

The architectural diagram which follows gives an overview of the components:

Kibana Globalization Architecture

The agnostic service is achieved by the internationalization (i18n) JavaScript class which is enabled per Kibana server instance. It means that there would be an i18n engine per tenant if Kibana is being used in a multi-tenancy configuration. The i18n engine manages the translations lifecycle; registering all translations and loading the correct locale when required. The translations are loaded on the client side with the HTML payload when Kibana is first accessed. The locale of the translations is decided by the accept-language HTTP header of the user. It will choose the highest priority locale of the header as supported by Kibana. The angular-translate globalization framework renders the AngularJS views using the translations loaded in the client side.

An important part of the design is to provide plug-and-play capability (i.e. code free) for localization engineers when providing translations of different languages. This is achieved by using the Kibana Plugin Yeoman Generator to generate a translation plugin. The localization engineer then adds the translation file(s), references the file(s) in ‘uiExports’ extension in the plugin, drops the plugin in the plugins location, and then restarts the Kibana server. Hey presto, you now have the Kibana view strings translated. This ability for the plugin to register its translations on the fly is because of plugin extension supported by the Kibana core. Refer to the Kibana design document for more details.


You are probably saying that is all well and good but is there anything tangible to go on but a design? Yes, there is and it has been broken down into the following four phases:

  1. Phase 1: Add the i18n engine
  2. Phase 2: Add the angular-translate globalization framework and provide AngularJS view translation template
  3. Phase 3: Enable translations on existing AngularJS views
  4. Phase 4: Contribute language packs


Where are we now and what does it mean to the person that wants to use Kibana in a different language to English? Phase 1 has been delivered in Elastic Stack 5.2.0 and provides the groundwork for internationalization. Phase 2 is currently in progress and it will provide the mechanism for enabling translation of strings on existing Kibana AngularJS views. The delivery of the first two phases provides the underlying infrastructure for internationalization. Phase 3 completes the internationalization by enabling translations on existing views by extracting the strings and providing IDs for the angular-translate framework to render. Phase 4 is the final piece of the jigsaw which is the addition of the language packs. This would require some consultation with the Elastic community for the most effective approach on delivering these packs in Kibana plugins, and which packs would be supported by Kibana releases.

Wrapping it up

In conclusion, we may just be at the beginning but we have made a good start. Once Phase 2 is merged then it will be about getting more people involved to enable translations in views and the translating of these views to different languages. It opens it up for community members to help bring Kibana globalization home.

For further information, there is a talk at Elastic{on}17 on globalization. If you have any further questions, feel free to reach out to me.

2 comments on"Kibana is Learning New Languages"

  1. Great post – things like this are a long road, and this looks like excellent progress

  2. Lisa McCabe March 01, 2017

    Great work Martin and team!

Join The Discussion

Your email address will not be published. Required fields are marked *