Multi-language Support with Spaces

[iamhowardtheduck]

Describe the feature: Ability to assign a specific language to a Space

Describe a specific use case for the feature: A user has teams with varying languages that all use the same platform.

edit: blocked on support for dynamic i18n configuration. See comment below.

[iamhowardtheduck]

@arisonl , apologies for the assignment.

[elasticmachine]

Pinging @elastic/kibana-localization (Team:Localization)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[ghost]

This would be an excellent feature to have. I know that at this moment in time Kibana is locked to a specific language for the entire instance. So for example, if needing to have the ability to display Kibana in English OR Japanese, there would need to be a unique Kibana instance for English language and another unique instance configured for the Japanese language.

Here are my ideas:

• Continue to allow Elastic Stack admins to lock a language in place for an entire instance. I definitely do not recommend removing this capability.
• Add the ability to lock down a language to a Kibana Space.

But even better,

• Allow users to swap between languages on-demand or at-will AFTER opening their Kibana Space. For example, an admin can define a Kibana space "default language". In my case I would define a space to open in English language at launch. But users could change their language to the other ones available if they so choose. The same example could be used in a different way such as having a Kibana space that opens with Mandarin by default but I could flip to English to help support the team. One idea for the UI component is on the top right of the Kibana window there are icons for news and help. Add another icon (such as a gear or language icon) for dynamic language selection for that user's browser session:

One big complication I can foresee with dynamic language selection is figuring out how to properly handle situations where field names, index names, visualization titles, dashboard titles and things like that are saved in a different language than the Kibana UI specfic assets. So if my dashboards and visualization titles and fields have Mandarin language characters, but I flip the UI language back to English then both languages would need to be allowed onscreen (or vice versa). So I might see the Kibana apps in English but all of my titles and descriptions would be in Mandarin. I can see the possibility of confusion from a user perspective but might be worth it anyways if language selection is a requirement.

[iamhowardtheduck]

Thank you @joedissmeyer, this is immensely helpful!

[legrego]

@elastic/kibana-localization are there plans to make i18n configuration dynamic, so we could support features like this (or even user-specific in the future)?

[Bamieh]

@legrego making i18n locale config dynamic without restarting the server requires some hefty changes on the server side. Although possible, the localitzation team (me) does not have the capacity to work on this one for now.

We do have a stale-draft PR for applying those changes on the browser side: https://github.com/elastic/kibana/pull/44606

I've created that PR to check how much work is needed to have this change in place, turns out it is a huge one.

[legrego]

Thanks @Bamieh, I appreciate the update!

[dbuijs]

Having this capability is important before removing the ability to override kibana.index because having two different locales is the reason why we run more than one Kibana instance on the same elastic cluster. We would very much like to use Spaces for this but cannot until we can set different locales for different spaces.

If at all possible, this ticket should be implemented at the same time or before https://github.com/elastic/kibana/issues/82020 to minimize the impact of removing this feature.

[kobelb]

Hey @dbuijs, realistically we will not have this issue addressed before we remove the kibana.index setting. We haven't begun work on this issue, and from what I understand, it's a considerable amount of work.

I'd like to figure out whether or not the following configuration would work around the limitations of having different language support for different spaces.

Even after we remove the ability to specify the kibana.index settings in the kibana.yml, we can still have multiple different Kibana instances with different i18n.locale settings:

We can then create a space for each language. These spaces will be the same across all language instances of Kibana.

However, we can use Kibana's RBAC model so that different language speakers only have access to the corresponding space:

[dbuijs]

This is extremely helpful, thank you. It's less than ideal but that will be workable.

The use case is for dashboards that connect to the same elastic search indices, but in different languages. The locale setting on Kibana covers the interface elements, but we need different index pattern settings to cover translated fields in the indexed content. This needs to be customizable because some fields are agnostic of language (like numbers and identifiers), some fields have different formatting in different languages (like dates) and some fields have corresponding fields in the other language.

On Thu., Sep. 30, 2021, 10:10 a.m. Brandon Kobel, @.***> wrote:

Hey @dbuijs https://github.com/dbuijs, realistically we will not have this issue addressed before we remove the kibana.index setting. We haven't begun work on this issue, and from what I understand, it's a considerable amount of work.

I'd like to figure out whether or not the following configuration would work around the limitations of having different language support for different spaces.

Even after we remove the ability to specify the kibana.index settings in the kibana.yml, we can still have multiple different Kibana instances with different i18n.locale settings:

[image: Screen Shot 2021-09-30 at 7 08 32 AM] https://user-images.githubusercontent.com/627123/135471222-f3462e56-4de4-45b7-8368-41539e6f7a8a.png

We can then create a space for each language. These spaces will be the same across all language instances of Kibana.

[image: Screen Shot 2021-09-30 at 7 08 52 AM] https://user-images.githubusercontent.com/627123/135471261-337f2f9e-fd98-4773-aee2-9df7cb74bd93.png

However, we can use Kibana's RBAC model so that different language speakers only have access to the corresponding space:

[image: Screen Shot 2021-09-30 at 7 09 15 AM] https://user-images.githubusercontent.com/627123/135471294-7b8d3d9e-0823-4254-b950-c9dd44dc5e5e.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elastic/kibana/issues/57629#issuecomment-931358761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXE57HOYVFKUKLIITY56U3UERVUPANCNFSM4KU3XBRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[jedidja]

Any updates on when this might be addressed, or at least when discussions might start on when it could be addressed? :)

[pgayvallet]

TIL that we even had an issue opened for this (cc @Bamieh)

From a technical standpoint:

Long story short, we currently lack the proper server-side architecture to support dynamic locale/language support. The problem is the same for supporting different locale per space, or different locale per user.

If on the browser-side, having multi-locale support would be fairly easy to achieve, given it technically only means loading a different locale per browser environment, on the server, that's a totally other story, as server-side components and services would need to be able to use a dynamic locale depending on some arbitrary context (userId, currentSpace, anything else).

However, atm, the Kibana i18n service can be statically imported from basically anywhere on the server-side, from places where this 'i18n context' wouldn't be able to be inferred and, often, not even easily explicitly propagated.

If exposing a scoped i18n service from request handler would solve the problem for 'scoped' code execution (e.g all code execution initiated from a request handler) would solve part of the problem, there is still the problem of code execution that is not explicitly bound to a request handler (e.g any background task service such as task manager). For such services, we would need to introduce a way for them to propagate the context the task is executed within (quite similar to what we do with 'fake requests' to impersonate the user for some tasks such as reporting).

Note that even if we were to introduce such i18n service enhancement from Core, we would still need all consumers of the i18n service (meaning: all Kibana teams) to adapt all their current usages of i18n to use the new scoped service exposed from the request handler, which means realistically a multi-thousands files diff.

TLDR: Dynamic locale support is a fairly common need that Kibana should (ihmo) support, but the technical implications and the cost are so significant that it never felt like it was worth focusing on the enhancement.

FWIW, there is this an issue about creating an RFC around this problematic: https://github.com/elastic/kibana/issues/36645. But it didn't really move for ages.

@arisonl (also cc @lukeelmers FYI) from a Product perspective, do you think this dynamic locale support may be something that could/should be reprioritized with the introduction of user settings (when it would make sense to allow users to specify their own locale)?

[lukeelmers]

do you think this dynamic locale support may be something that could/should be reprioritized with the introduction of user settings

These were my thoughts exactly. Knowing how large of an effort this would be, it doesn't seem worth the investment to try to fix it before we have proper user settings, as (I'd imagine) that's how we'd want the user experience to look moving forward.