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

[GS] internationalisation of the search syntax #83887

Open
pgayvallet opened this issue Nov 20, 2020 · 3 comments
Open

[GS] internationalisation of the search syntax #83887

pgayvallet opened this issue Nov 20, 2020 · 3 comments
Labels
discuss enhancement New value added to drive a business result

Comments

@pgayvallet
Copy link
Contributor

pgayvallet commented Nov 20, 2020

Related / follow-up of #74290

This started with a sync discussion with @myasonik that noticed that the search syntax is not dependent on the locale.

For example, when in zh-CN, to filter by type:dashboard, you still need to type type:dashboard.

The question is, do we want to change the syntax to support the current locale?

For example, when I look at the Chinese translations:

  • type: 类型 (coming from the type filter label in SO management)
  • dashboard: 仪表板 (coming from the dashboard label in breadcrumb the dashboard app)

Should the filter terms that the user type (type:, tag:) be dependent of the locale?

The user would then need to type 类型:dashboard instead of type:dashboard to filter by dashboard

Should the filter values (e.g, for type, dashboard, visualization) be also dependent on the locale ?

The user would then need to type 类型:仪表板 instead of type:dashboard to filter by dashboard

Note that the issue is not present for tags, as the user searches by tag names, which are input provided by the user. If the tag name is 无法保存仪表, searching for tag:无法保存仪表 already works.

If we do either of the previous points, should we also allow to use english in the filtering syntax?

The user would be able to use either 类型:仪表板 or type:dashboard to filter by dashboard

Overall I'm mixed. This may be a better user experience, but would be introducing a lot of complexity by adding i18n logic inside the parsing algorithm. Also, that kind of advanced search syntax is fairly technical, so I feel like sticking to english may be sufficient.

cc @alexfrancoeur @ryankeairns @myasonik wdyt?

@pgayvallet pgayvallet added discuss enhancement New value added to drive a business result labels Nov 20, 2020
@ryankeairns
Copy link
Contributor

Adding to this point, it seems this would necessitate a broader discussion as this syntax is also used in other places (e.g. Stack Management > Saved Objects). I think it's best to take a monitoring stance on this situation. It's not unprecedented or new and, to my knowledge, is not an issue with high demand. The search feature is still quite usable and this would be purely an enhancement.

@myasonik
Copy link
Contributor

If it's not translated, the only thing I worry about it is whether or not we ever display the English names of all the saved object types.

In the table, it looks like we keep the English for the tooltip so that's good. Is there anywhere else we display the saved object type names?

Screenshot 2020-11-20 at 08 09 39

Then the only other thing that I can think of is making sure we don't translate this part of our UI/docs (i.e., when we say You can filter using "type:{savedObjectName}" we need to make sure to not translate "type" in that string).

@Bamieh Do you have anything more you can think of we should consider for this?

@Bamieh
Copy link
Member

Bamieh commented Jan 29, 2021

I think we should be displaying the english type since this is what we support when searching. IMO this behaviour should be enough for now:

If the tag name is 无法保存仪表, searching for tag:无法保存仪表 already works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss enhancement New value added to drive a business result
Projects
None yet
Development

No branches or pull requests

4 participants