LanguageTool Plug-in open beta for SDL Trados Studio

Update 2021 by the LanguageTool team: Get the latest SDL Trados add-on here.

I would like to share my plug-in for SDL Trados Studio.
Plug-in works as global verifier and connects with LanguageTool sever via RestAPI.
Plug-in works stably and is signed by SDL. However I don’t consider it as final.
I’m very curious about your opinion.

You can download plug-in and preliminary user manual here:
https://1drv.ms/f/s!AndXlncO4RLoymbxMg2ng_9vCzRA

DArek

Thanks. I’m not a user of SDL, so I won’t be able to provide feedback, but I can link it on our Wiki. Will the plug-in itself be Open Source?

Taking into account LanguageTool is Open Source I think it would be good to publish this plug-in also as Open Source. When I better familiarize with github I publish final version as Open Source.

And one more thing, the plug-in works with Studio 2014, 2015 and also should work with Studio 2017.

If you want more Beta Testers for this plugin maybe it makes sense to post into the plugin community in the SDL Community forums? At least you’ll find plenty of willing Studio users in there. I was directed here by another user who pointed me to a question in the SDL Community from a user who was actually looking for the very solution you are trying to provide.

Regards

Paul

Hi, if someone sends me a Studio Package, and they don’t use/don’t have the plugin installed, will the plugin work on this type of projects? I am wondering because yesterday I was translating a package and no LT rules were triggered. Yes, I checked that the local server was running. :slight_smile: Another option is that my writing was perfect :wink: but I made a few deliberate mistakes and still no rules were triggered.

The plugin works just fine on my own Studio projects, so, very big THANK YOU for developing it. I am a long term user of LT in LibreOffice, and I am glad that the tool’s reach has finally been extended.

Piotr, the case you described it is typical for SDL Trados Studio projects settings and also for verification plugins, because Studio is project-based tool. For example Number Verifier works in such way. However, my approach is different. LanguageTool should work even for projects/packages created on Studio without my plugin installed.

Please set your desired settings (in any project) and save them as user defaults (Save As User Defaults). These settings will be stored in Windows settings and will be applied always when Studio project don’t contain LanguageTool Plugin settings.

From now you can download LanguageTool Plugin for SDL Trados Studio from site:

Under construction – Post-edit a CAT (English)
or
Under construction – Post-edit a CAT (Polish)

Another thing that comes to my mind is opening multiple files at once in Studio as one view (that is what I did yesterday). Could this possibly block the plugin from working?

Hmm, I’m rather sure the merged files view doesn’t cause any problems.

Does your problem apply to verification after confirming segment or hit F8 key?

If you think LanguageTool Plugin doesn’t work, check LT server console to see log of requests sent from LanguageToll Plugin and processing results. I’d rather check verification settings that is ‘Enable LanguageTool Plugin’ check box, and ‘Exclude’ check boxes.

@DArek, would you please provide me with a plug-in for GVim text editor as well? I would like to have a Code::Bloks, CodeLite and Eclipse CDT plug-in too. Waiting to hear from you.

DArek, I have tested your plugin with Studio 2014 and Studio Express 2015, It works really fine, Thanks a lot for this awsome tool. You have implemented nearly all API parameters, Congratulation.
I would like to suggest some improvements to make the tool even better and to make the plugin settings portable.
Is it possible to implement the following functions:

  • Enable Bitext-Rules and pass the source segement with the srctext parameter on to LT
  • Save and import the profile settings to/from a user defined file location. Such files could be shared with translators to make sure everybody uses the same language and included or exluded categories/rules
  • Optionally specify a file to read the settings from upon execution

Then: Many translators do not like to deal with system issues. So my idea is the following: If you could provide a possibity to start the languagetool server from the plugin interface. Ideally with the option to use a customized config file.
Why that? There is the use case that you define particular rule files for different customers or products. In this case you can start the LT server and specify an additional rule file folder. Those settings are stored in the users root folder as .languagetool.cfg. Most translators will not be able to use this feature.

My config file looks like this:
disabledRules.de-DE=
taggerShowsDisambigLog=false
autoDetect=false
disabledCategories.de-DE=
serverPort=8081
useGUIConfig=false
enabledRules.de-DE=
language=de-DE
serverMode=false
errorColors=
extRulesDirectory=C:\Path_to_customized_rule_files

The path to the .languagetool.cfg file can be specified upon server start with the --config option.

Thanks

Jorg, big thanks for feedback.

As for Bitex, currently LT doesn’t support bitex rules via RestAPI :frowning:

As for LT Plugin settings import/export, it is on my To Do list. I will try to implement it on first final version.

As for reading the settings from config file, I don’t want to multiply configuration methods. LT Plugin settings are already enhanced in comparison to other Studio plug-ins. I’m going to add support of multiple profiles settings (3 or 4 profiles selected from drop-down list) to allow quick change of settings. But I will think it over.

As for automatic LT server start, it is also on my To Do list. Thanks for pointing out the server config file to me I will take it into account. I think it could be useful.

Thanks

DArek, looks great, thanks.
I will be happy to test your further versions :smile:.

The RestAPI does support bitext rule checking. Okapi CheckMate in the Rainbow suite uses it. And I used it programmatically to check entries from a database. It works like a charm…

You need to have a valid bitext file in the respective language folder. LT comes with bitext rules for RU, PL and GL.
Copy the attached bitext.xml into the languagetool org\languagetool\rules\de folder.

bitext.zip (692 Bytes)
With the http call:
http://localhost:8081/v2/check?language=de-DE&motherTongue=en-US&enabledonly=no&srctext=Choose Select Instance in the dropdown list.&text=Wählen Sie in der Dropdown-Liste Variante wählen.
you should get the following answer from LT:

{
“software”: {
“name”: “LanguageTool”,
“version”: “3.5”,
“buildDate”: “2016-09-30 09:59”,
“apiVersion”: “1”,
“status”: “”
},
“language”: {
“name”: “German (Germany)”,
“code”: “de-DE”
},
“matches”: [
{
“message”: “Möglicher Rechtschreibfehler gefunden”,
“shortMessage”: “Rechtschreibfehler”,
“replacements”: [],
“offset”: 18,
“length”: 14,
“context”: {
“text”: “Wählen Sie in der Dropdown-Liste Variante wählen.”,
“offset”: 18,
“length”: 14
},
“rule”: {
“id”: “GERMAN_SPELLER_RULE”,
“description”: “Möglicher Rechtschreibfehler”,
“issueType”: “misspelling”,
“category”: {
“id”: “TYPOS”,
“name”: “Mögliche Tippfehler”
}
}
},
{
“message”: “Falsche Terminologie: EN: ‘Select Instance’: ‘Variante’ ändern in ‘Variante auswählen’. Fehlerkategorie: WT;Serious (5)”,
“shortMessage”: “”,
“replacements”: [],
“offset”: 33,
“length”: 15,
“context”: {
“text”: “Wählen Sie in der Dropdown-Liste Variante wählen.”,
“offset”: 33,
“length”: 15
},
“rule”: {
“id”: “SELECT_INSTANCE”,
“subId”: “1”,
“description”: “EN: Select Instance, DE Variante wählen -> Variante auswählen”,
“issueType”: “terminology”,
“category”: {}
}
}
]
}

You can ignore the first message. The second error message comes from the bitext rulel

Please let me know if you need more information.

Thanks

It’s interesting. I used the specification from LanguageTool HTTP API and there is no details about SRCTEXT parameter. I will check this.

I think this parameter was lost when switching to JSON. Your example works, but srctext might just be ignored.

You are perfectly right, It’s not listed as a swagger parameter.
@dnaber: Will the srctext parameter be deprecated, or is it simply missing?

It still appears to work with 3.5…
Check out my sample. It uses V2 and it would not return the second message if it ignored the srctext parameter.

@dnaber: OK. Apparently you are right. The query returns the same error if the srctext is missing. So apparently the bitext file is evaluated, but only for the target language part. Is that possible? Any chance for the srctext parameter to return?

Well, it’s an item somewhere on my TODO list. That means I have no idea when it will be added again. Pull requests welcome.