Automatic Language Checking when writing Problem Statements

[kerstinandree]

Is your feature request related to a problem?

English is not my mother tongue, so I make some language mistakes when writing a problem statement for a text exercise or when creating questions for the quizzes. Currently, I always have to copy the written text to another platform, e.g., Grammarly, which checks for language mistakes. This is quite time-consuming.

Describe the solution you'd like

It would be great if the problem statements and questions I create in Artemis are automatically checked for language mistakes. E.g., by integrating Grammarly. TUM already has a license, so it would be quite convenient.

Describe alternatives you've considered

No response

Additional context

No response

[krusche]

Would be a nice feature, yes 👍 if someone is willing to implement that, great. But it might not be as easy as it sounds

[sarpsahinalp]

Grammarly Text Editor SDK was discontinued on January 10, 2024 and therefore Grammarly doesn't have an API to use.

[BaumiCoder]

Maybe such a feature could be provided indirectly. There are Browser Plugins for Grammarly and LanguageTool (another services which can be also run local, without transfer all you texts to some cloud). I am using LanguageTool, and it automatically works in many text input field on the web, which are for multiple lines (e.g. the text pox for the GitHub comments here).

The Problem Statements in Artemis are not recognized by the Plugin. Maybe this problem with the Plugin could be solved to provide language checking. Recognizability for this field maybe also increase accessibility for other tools like screen readers.

[krusche]

@BaumiCoder great idea. Any idea what we need to accomplish so the problem statement will be recognized?

[Hialus]

Any idea what we need to accomplish so the problem statement will be recognized?

According to a Grammarly Support article

Grammarly’s browser plugin mainly supports textarea and div elements with contenteditable=”true.” Grammarly doesn't work in input fields.

Note: Our product also requires custom integration for cases of iFrame usage. If your text fields are using iFrame, please contact us by submitting a request here, and we will help you with the issue.

Since we are using the ace editor it may be somewhat difficult, as it is not using a single text area. When this is changed to use Monaco it will seemingly not be much easier: https://github.com/microsoft/monaco-editor/issues/1977

[BaumiCoder]

@BaumiCoder great idea. Any idea what we need to accomplish so the problem statement will be recognized?

Sorry, I do not know which kind of text fields are considered by the LanguageTool Plugin. I could not find any technical documentation of the plugin. (The existing repo for the source code is of an old version. The actual seems to be closed-source.)

In the places, where Monaco is already in use in Artemis, the LanguageTool Plugin does not work. I am not sure if it recognizes that there is source code displayed in some way (and it does not check source code) or if it has an general problem with Monaco.