Open jihuayu opened 7 months ago
I am supportive of adding l10n support to vscode-clangd in principle.
I have a couple of questions about details:
@HighCommander4
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.
I have two solutions for this issue.
"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?
@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?
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