Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discuss] Best practices for using i18n on the server. #97650

Open
oatkiller opened this issue Apr 20, 2021 · 5 comments
Open

[Discuss] Best practices for using i18n on the server. #97650

oatkiller opened this issue Apr 20, 2021 · 5 comments
Labels
discuss impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:i18n Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@oatkiller
Copy link
Contributor

oatkiller commented Apr 20, 2021

Hi all. I want to discuss our expectations around using i18n on the server. Server code often defines messages for HTTP responses, logs, and perhaps to populate fields in SavedObjects or other documents. Some server code may even generate strings that are then shown on the UI.

What do users expect? Should log messages be translated and localized? Does SDH rely on English language log messages? Will we break things or annoy users if we change our current behavior?

Is Kibana generally consistent in this area? Should we use i18n for all messages on the server? This i18n guideline suggests using i18n when writing NodeJS code. I've included a table below that documents the behavior as its found in the Security Solution.

Security Solution

Types of messages found in server side code Do you use i18n?
Human readable HTTP bodies (e.g. when a HTTP route returns a status code of 200 or 500 and includes a message in the response body) No
Log messages No
Messages that are stored in SavedObjects or in ES documents in data indices ?
Messages that are included in HTTP responses and then shown in the UI ?

Here is a template you can copy if you'd like to use it to document what your plugin is doing:

Template

Types of messages found in server side code Do you use i18n?
Human readable HTTP bodies (e.g. when a HTTP route returns a status code of 200 or 500 and includes a message in the response body)
Log messages
Messages that are stored in SavedObjects or in ES documents in data indices
Messages that are included in HTTP responses and then shown in the UI
add other types as needed
@botelastic botelastic bot added the needs-team Issues missing a team label label Apr 20, 2021
@Bamieh Bamieh added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Localization and removed needs-team Issues missing a team label labels Apr 20, 2021
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@FrankHassanabad
Copy link
Contributor

FrankHassanabad commented Apr 20, 2021

For lists plugin:

Template

Types of messages found in server side code Do you use i18n?
Human readable HTTP bodies (e.g. when a HTTP route returns a status code of 200 or 500 and includes a message in the response body) No
Log messages No
Messages that are stored in SavedObjects or in ES documents in data indices No
Messages that are included in HTTP responses and then shown in the UI No

@stacey-gammon
Copy link
Contributor

cc @Bamieh

I don't think it is possible to translate dynamic strings that are not hard coded.

@Bamieh
Copy link
Member

Bamieh commented Jun 9, 2021

I don't think it is possible to translate dynamic strings that are not hard coded.

correct this is not possible since our label extraction tool parses the ast tree statically to extract the ids and messages.

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Nov 4, 2021
@exalate-issue-sync exalate-issue-sync bot added loe:large Large Level of Effort loe:medium Medium Level of Effort and removed loe:small Small Level of Effort loe:large Large Level of Effort labels Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:i18n Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

6 participants