Support for advanced grammar, style and spell checking using LanguageTool

[pereorga]

LanguageTool is a free and open-source grammar/style/spell checker.

That would be a great improvement to current spell checking.

[vslavik]

This is not realistic to do client-side, given LanguageTool's Java nature.

[pereorga]

And what about calling their REST API? http://wiki.languagetool.org/public-http-api

(can also be run locallly)

[vslavik]

I am aware. Running locally is out of the question because of the JRE requirement; it doesn't matter if it is in-process or out-of-process, it matters that it requires JRE. The public API is (see your link) not meant for production use. The only realistic way to do this is to self-host LanguageTool server and do it remotely.

None of the above implies I don't want to have it. On the contrary, I do see LanguageTool as potentially useful (and had it on my tentative to-maybe-do list already) — although perhaps not as useful as it is for proofreading larger bodies of text than what is typically in POs. You can see the focus on that in LT's commercial offering too, which would be insanely cost-prohibitive for real-time checking one item at a time.

In any case, getting a usable LT instance is the easy part. This will require major UI changes to the text editor too, namely the ability to highlight parts of text differently from standard spellchecking, and be able to provide corrections UI atop such highlighted fragments. Such UI is needed for other planned things as well, so is happening, but this issue is effectively blocked until then.

[pereorga]

The public API is (see your link) not meant for production use. The only realistic way to do this is to self-host LanguageTool server and do it remotely.

I was thinking of calling the API only after the editor had typed the whole translation, but I didn't think too much in the details. (That's why I thought the public API server should be fine for sporadic translations and could even be set as default - and users can host LT locally too, that's easy to do indeed.)

This will require major UI changes to the text editor too, namely the ability to highlight parts of text differently from standard spellchecking, and be able to provide corrections UI atop such highlighted fragments.

Personally, I like the unobtrusive design of the Grammarly plugin for Microsoft Office; https://imgur.com/a/HqYqn9l

That's just an idea: In Poedit, correction suggestions could be located at the right sidebar, maybe at the bottom (always below translation suggestions).

Such UI is needed for other planned things as well, so is happening, but this issue is effectively blocked until then.

I see. What other planned things? Is there a roadmap?

[pereorga]

Also, note that highlighted fragments are not obligatory. They are nice, but what is essential in LT (especially for short sentences such the ones generally used in Poedit) is that the suggestions are shown, so (maybe) the text editor does not need to be changed from the start.

[MayeulC]

Hello, I am interested in this feature as well. I just bought a poedit subscription to help me translate my thesis through po4a via automated translation, and I am currently proofreading the translations.

Having support for LanguageTool would help me quite a bit with this, it's better at suggesting tone changes than DeepL's "formal" output. I have a premium LanguageTool subscription (which was handy while writing the thesis), so one would just need the ability to specify the endpoint and log in (or API key) in the client. Users could run their own LT instance, host it on premises (company-wide setup), or use the online API (Premium or free).

the ability to highlight parts of text differently from standard spellchecking

I don't really think this is needed, I'd rather completely replace spellchecking with LT's. Of course, it would be better to have different highlight colors for grammar, typo, suggestions, etc, as LT does.

Running locally is out of the question because of the JRE requirement; it doesn't matter if it is in-process or out-of-process, it matters that it requires JRE.

I don't quite get this though. The distribution would be completely independent of poedit, it would be up to the user to install LT.

The public API is (see your link) not meant for production use. The only realistic way to do this is to self-host LanguageTool server and do it remotely.

The public, free API is probably not enough for big users, so this feature should be disabled by default. This would also safeguard against possible confidentiality issues as well. As for the API itself, I think it is pretty well-documented and stable, software such as TeXstudio have had LanguageTool integration for a while.

[vslavik]

translate my thesis through po4a

This is the crux of the matter: Poedit is primarily a localization tool and you are in extreme minority with this "off-label" use. Hence your much higher interest in LanguageTool.

it would be up to the user to install LT.

I am not interested in doing — and then supporting — anything requiring complicated setup by users. Enter API key (which was not a thing in 2019) is fine-ish, but that's about the extent of it.

The rest of your comment contains some strong opinions on how thing could or should be done etc. If you'd like to contribute a PR, I'd certainly welcome that, but if you're not, I'll just note that oftentimes things are considerably more involved than they appear at first glance...

[pereorga]

For what is worth, OmegaT features a LanguageTool plugin, but it's not up-to-date.

For example, you can also use LanguageTool with Transifex or Weblate easily through the LanguageTool browser extension, without any complex configurations.