search

microsoft / language-server-protocol

Defines a common protocol for language servers.
https://microsoft.github.io/language-server-protocol/
Creative Commons Attribution 4.0 International
11.33k stars 804 forks source link

Add localization option in initialization request. #754

Closed tinaschrepfer closed 4 years ago

tinaschrepfer commented 5 years ago

The initialization request should have an option for specify the locale of the client, so the server can return localized strings for errors, code actions, etc.

dbaeumer commented 5 years ago

The interesting question is whether this needs to be a command line argument to the server instead. The reason is that quite some NLS mechanism / frameworks needs the very early when the process is started and this can later on not be changed dynamically any more.

dbaeumer commented 5 years ago

I looked into this for 3.15 but it is not as trivial as it sounds. Two things:

Most systems (even VS Code) still use 639-1 so going to 639-2 requires a mapping table.

Opinions?

@tinaschrepfer what do you use in the API?

pawelurbanski commented 4 years ago

Any progress on this issue?

rwols commented 4 years ago

A server could also read the LANG environment variable?

dbaeumer commented 4 years ago

Correct but we want to also support the case where the server run on a different machine.

mickaelistria commented 4 years ago

I think we should provide this as a command line argument as well. Proposal is --locale

As far as I know, the LSP spec doesn't say anything about command-line options at the moment. Does it? I wouldn't mind if specification were starting to recommend CLI options, like --locale or --stdio or other connection options that would standardize the startup commands. That would IMO be beneficial to all clients/servers that would ask themselves less questions about how to play nice together and would be more "instinctively" able to sort out the best command to bind client and server. However, not all deployments are local (I elaborate about it below).

The reason is that quite some NLS mechanism / frameworks needs the very early when the process is started and this can later on not be changed dynamically any more.

Sure, but if you consider things like multi-tenant language servers, or "proxy" language servers that can delegate to other ones, a single locale wouldn't fit. Although many NLS frameworks are limited to initialize early, I don't think the specification should then be limited by it, as there can easily be cases where the initialization option is the only reliable input we can get for a LS "session",

Correct but we want to also support the case where the server run on a different machine.

This seems to echo my previous comment: some deployment stories do not allow to control sufficiently the startup CLI options to rely solely on it.

My current impression is that

which format do we use. ISO 639-1 ISO 639-2

From Eclipse IDE persepective, the IDE can only be configured with ISO-639-1 AFAIK, but it's trivial with standard Java to turn a ISO-639-1 code to a ISO-639-2 code, so I'd suggest we just go for the better/the most universal to avoid some limitations if it's trivial to target less limited standards.

dbaeumer commented 4 years ago

I decided to go with IETF BCP 47 language tag as defined here: https://en.wikipedia.org/wiki/IETF_language_tag

This seems to be the standard used.