[Deprecation service] Using i18n for deprecation messages

[Bamieh]

Previously we've discussed using i18n for the deprecations service.

At the moment we're not recommending using i18n for the deprecation messages based on the following reasoning:

• use i18n: localized content for better user experience.
• not using i18n: Consistent with ES deprecation logs since they have no i18n. It would also be easier to search the web and find answers with a non localized string.

At the moment We dont have a strict convension about localizing logs/errors coming from the server.

CC @timroes @alisonelizabeth @joshdover

[elasticmachine]

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

[lukeelmers]

We dont have a strict convension about localizing logs/errors coming from the server.

IMHO we should generally stick with the ES convention of not localizing deprecations & errors in the logs or in API responses themselves, however, the complicating factor here is what to do when these things are specifically designed to be surfaced in the UI instead of just a log file. In those cases, it may be worth the additional effort to localize (while keeping the underlying logs in English).

This reminds me of a related discussion around solving a similar problem in the Notification Center: #90297 (comment).

[Bamieh]

it may be worth the additional effort to localize (while keeping the underlying logs in English)

@lukeelmers That is an interesting take on how we might approach this. I think its worth experimenting how the API would look like if we go with this approach and the compatibility of our i18n extraction tool is with such implementation.

In UA we'd love to eventually be able to show more than just a static messages for the deprecations. Having support for some markup and react components as well is similar to a need we have in NC.

[timroes]

It would also be easier to search the web and find answers with a non localized string.

I personally find this point a bit weak for an argument. The same would apply for virtually any translation we have inside Kibana. It's way easier to find something around a feature, help, anything if it's all the same language :-) So I don't think we can use that as a logic for not translating errors.

In my opinion we offer a UI to the user, and every part we have under control we should localize. I think we mostly don't do that for ES responses/errors not because of "we didn't want it", but because it was technically not (easily) fiesable? I believe we should translate any user facing texts as long as we can.

As Luke mentioned I'd be a bit careful about "documented APIs" responses and localize strings inside there, but I wouldn't treat the case of deprecation logs as such one (especially not the one shown in the API).

I am trying to look at it from a user-perspective, and have a hard time seeing how any user would be there, using Kibana in a non-English version and be: "Oh well I am happy those things are still in English.".

[Bamieh]

@timroes Thanks for the input. I'm going to update the docs and FAQ guide to include the usage of i18n.

[joshdover]

@Bamieh can we close this issue?

[Bamieh]

@joshdover not yet. We need to pass i18n into the getDeprecation function to enable people to use it.