Some Premium rules are really useful, and one of the reasons why I decided to a Premium subscription is that I can check “Up to 150,000 characters per text field”… That sounded okay for my use case. But then I figured out that this number is not current when I check LaTeX documents in my editor (using ltex-ls). This relies on the API at LanguageTool HTTP API, which supports only up to 60,000 characters per request.
This is somewhat disappointing, at least. Of course, I can try to ensure that files are smaller, but 150,000 and 60,000 is a big difference and I feel somewhat cheated on. Ok, yes, it says, “text field” and I could have found the API docs earlier, but I also think it’s strange that the limit is different. Why should you be allowed more characters in the browser than using other request methods?
Hi, so I understand you have configured ltex-ls to use your email and API Key? If that’s the case, please contact our support (see here for the email), but all we can do is offer you a refund. ltex-ls would need to split the text into smaller chunks before sending it to the API.
I see… Okay, I’m considering it, but I haven’t decided yet.
Ok, yes. However, that requires changes to ltex-ls, and then I suppose we’ll run into the minutely limit pretty quickly.
Edit: Maybe let me rephrase it as customer feedback, in the hope that this is helpful for the future: With small limits, paying for Premium is not clearly better than self-hosting (or using ls-ltex, which ships LT). Sure, you get better rules, but you also hit the limits quickly. The latter means you need to resort to starting checks manually/when the file is saved (instead of continuous checking), which is not a great UX. Overall, this makes me doubt that it’s worth paying.
I have the same issue when using it in VSCode. After the shutdown of Grammarly’s API, I got the premium version of LT, but due to the API limit, it doesn’t work for my daily documents (scientific papers). I use the “ltex-ls-plus” VSCode extension.
The current limit is enough for interactive (i.e. while-you-type) checking in the browser add-on, so I think it should be okay for other add-ons, too. So, the VSCode extension should make sure to not send too many requests, e.g. not on every keystroke.
Perhaps we’re talking past each other. The issue is not the limit on requests per time. Sure, any applications which hits these time-based limits should send requests only every few seconds and not on every keystroke. And this is totally reasonable.
The actual issue we face here is that many documents (e.g., larger LaTeX or Markdown files) can be over 60,000 chars when encoded as a request (with markup retained etc.) In that sense, this differs from the browser add-on because one typically doesn’t edit large documents in the browser.
In other words, more chars per request would be helpful here, in particular considering that the web interface (which IIUC is also designed with larger docs in mind) allows for up to 150,000 chars. Of course, applications can split requests, but that’s more of a hack than an elegant solution.