clangd / vscode-clangd

Visual Studio Code extension for clangd
https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd
MIT License
594 stars 97 forks source link

Add l10n support to clangd vscode extension #560

Open jihuayu opened 7 months ago

jihuayu commented 7 months ago

I found that clangd-vscode, as a widely used plugin, does not support l10n. Adding localization support can improve the usability of this plugin for developers whose native language is not English. So, I suggest adding l10n support to this plugin.

Starting from VSCode version 1.73.0, VSCode introduced the l10n API. We can use it directly.

If you think adding l10n support is ok, I am willing to work on it.

Also see

VSCode doc about l10n VSCode l10n GitHub repo VSCode extension l10n sample

HighCommander4 commented 7 months ago

I am supportive of adding l10n support to vscode-clangd in principle.

I have a couple of questions about details:

  1. The current minimum vscode version required by the plugin is 1.65.0. Does adding l10n support mean we'd have to bump that to 1.73.0, or can the support be conditional on the actual vscode version being used?
  2. Parts of the plugin's functionality (related to the auto-install feature) is contained in a dependent repository, node-clangd. The code in this repository does not have access to the VSCode API (since it's shared by another plugin for a non-VSCode editor), but it does contain user-exposed error message strings such as this one. Is there a way we can localize these strings too?
jihuayu commented 7 months ago

@HighCommander4

For Question 1

Yes, we need to upgrade to version 1.73.0. It was released in October 2022, so it has been around for a while now. I believe most people have already upgraded to this version. If we don't upgrade the version, we can handle localization in the code based on the VSCode version. However, for the properties, commands written in package.json, we won't be able to localize them. So, I suggest upgrading to version 1.73.0.

For Question 2

I have two solutions for this issue.

Each of these methods has its advantages and disadvantages. Which one do you think is better?

HighCommander4 commented 6 months ago

@HighCommander4

For Question 1

Yes, we need to upgrade to version 1.73.0. It was released in October 2022, so it has been around for a while now. I believe most people have already upgraded to this version. If we don't upgrade the version, we can handle localization in the code based on the VSCode version. However, for the properties, commands written in package.json, we won't be able to localize them. So, I suggest upgrading to version 1.73.0.

Ok, unless we hear an objection in this thread, I think bumping the minimum vscode version is fine.

Older vscode versions will still be able to load older vscode-clangd plugin versions.

For Question 2

I have two solutions for this issue.

* The first one is to add simple l10n support to node-clangd and set the localized language in the VSCode plugin.

* The second solution is to use node-clangd message directly as the localization key in VSCode. For example, if node-clangd returns `"Failed to install clangd"` we can use `"Failed to install clangd"` as the key in the localization file, and provide the corresponding localized string like `{"Failed to install clangd": "the l10n string"}`.

Each of these methods has its advantages and disadvantages. Which one do you think is better?

Looking at how the node-clangd plugin is structured, I see that there is an existing interface named UI, which defines method signatures that the respective consumers (vscode-clangd and coc-clangd) implement.

So, it seems natural to add a localize(message) function to that interface. The vscode-clangd implementation can call l10n.t(message), while the coc-clangd implementation can just return message. (In the future, if coc-clangd also implements localization, it can do it in its implementation.)

What do you think?