Back to LanguageTool Homepage - Privacy - Imprint

Language Server for LanguageTool

I have begun work on a new integration for LanguageTool in the way of implementing a server speaking the Language Server Protocol. My immediate target is Visual Studio Code; however, the server component could be used with a number of other editors. Currently, I have both the Language Server and the VS Code extension in the same repository, though I plan split them once matured.

The Visual Studio Code extension lives at:
The language server is at:

There is still a bit of work to go before I can publish to the VS Code Marketplace, but right now it will show the found problems for English (any variant) and replacing with the suggestions works.

Is there any chance I could have permission to use the LanguageTool logo with this?

I think I have the code ready to be able to send a first release to the Visual Studio Code Marketplace, I am just working now trying to get some publication stuff done via Travis CI instead of doing it on my local command line.

Yes, feel free to use it (at least for now, I cannot promise that I’ll never have to withdraw that permission).

It lives!!

To get it to publish, I had to restrict it to English to reduce the file size. With all languages included it was coming in at 105 MB while the limit is 100 MB.

Can’t you set the languages up as sub-extensions? set them up as ‘language-packs’. (If the marketplace admins agree to this, then any user will be able to choose what languages they’ll use it for and not have to bother with downloading the rest.)

Good idea! I think that can work. The marketplace supports dependencies for extensions, so I could make an extension per language and make them all dependent on a core extension that actually provides the functionality. A quick demo shows extensions do not (currently) appear to be sandboxed at all and I can peek into other extension’s files.

Originally I had been thinking the extension would need to download the languages. That is what RedHat’s Java extension did before the limit was raised enough they could ship directly. Multiple extensions seems like it would a better user experience.

@SkyCharger001 I took your advice and it worked well! There is now a an updated version of the VSCode extension and a language support extension for every LanguageTool language.

@dnaber - Would you be open to integrating code for a Language Server Protocol implementation? I would be more than happy to help maintain it. I would envision it as a sub project just like the current languagetool-server implementation. I’m a long-time user of LanguageTool, particularly with both the Atom and VSCode editors, and I have experience with Java development.

Adam Voss, the young man who was working on an LSP implementation for LanguageTool, passed away in July. I only found out two days ago via an email from his father. Prior to passing away, he created an organization on GitHub and added me as the only other member. Adam and I have never spoken, nor exchanged emails. I didn’t know him, but based on what little I’ve read about him over the past few days he seemed like a very bright and kind young man. I’ve spent most of today reviewing his code, and while it’s pretty solid stuff, I foresee many problems with trying to maintain it as a separate project. And to be honest, continuing Adam’s project is not something I can do alone.

If you don’t feel integrating his work into LanguageTool is right at this time, that’s okay. I’ll see if I can find other contributors to help continue what he started, but having the LSP implementation become part of LanguageTool itself felt like the right place to start.

You can see my profile on GitHub for more details on my work.


I could only put 2 links in the other post. Here are two more that might help inform your decision:


David, I don’t know about LSP and I’m not sure other committers do. But as long as you maintain the code, I think we could add it as another Maven module to the official LT repo. If you want, you can create a pull request for that.

Thanks for getting back to me, Daniel. If you’re okay with it, I’ll open an issue about the situation on the languagetool repo to help raise awareness with the rest of your committers and give them the opportunity to weigh in. That’ll also keep the conversation closer to the code.

In the meantime, I’ve forked the languagetool repo and am learning the build process. I’ll continue working in his original repo as well to get an idea of how to integrate it under a new module (i.e. languageserver-lsp). I also noticed he had all the code under MPL-2.0, so I’ll need to consult an IP attorney about the implications of merging in with languagetool under LGPL. Fortunately, I already know one that I can consult, so that shouldn’t take me long.

Thank you again for getting back to me and for being open to the suggestion. I’ve no idea why Adam left me in charge of this code, but I don’t want to see his work or the spirit of what he was trying to do just disappear.

Yes, please do. What will the result of the code be - will it be an option for languagetool-server.jar to run in LSP mode or its own JAR, e.g. languagetool-lsp.jar?

What I’ve done so far would produce another jar called languagetool-lsp.jar. I think mixing it into the existing languagetool-server.jar would potentially become confusing for end-users due to too many command-line options.