https://community.rws.com/product-groups/trados-portfolio/rws-appstore/Including: Desktop & Clouden-USTelligent Community 12 Non-Productionhttps://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/10058/where-else-do-plug-ins-live/193237Fri, 24 Apr 2026 10:27:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:ca9e60d2-a6d3-49fa-8476-e388680e69e6Michael BeijerThanks for the great info, Paul, I've updated it already! Ahem, I mean Claude Code updated it.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/10058/where-else-do-plug-ins-live/193235Fri, 24 Apr 2026 10:17:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:2f236361-9b59-4d89-bcff-5576f02633c1Paul FilkinMichael Beijer There are a few things worth noting however... for completeness: Path inconsistency. The Roaming path is shown as ...\Plugins\ while the other two end in ...\Plugins\Packages\ . Studio stores the packaged .sdlplugin in Plugins\Packages\ and extracts to Plugins\Unpacked\ regardless of scope, so the Roaming line should also end in \Packages\ . Might be a typo. "Active Directory" framing might be a bit dated. Roaming profile sync via classic on-prem AD is increasingly rare. I think many corporate setups today run Entra ID (Azure AD) with Intune, FSLogix profile containers, or OneDrive Known Folder Move, and OneDrive KFM does not redirect AppData\Roaming by default. Might be worth saying something like "in environments that sync the Roaming profile (classic AD roaming profiles, FSLogix, etc.)" rather than implying AD domains always sync it. Minor wording. "If you are not on a corporate domain network, this behaves the same as 'This computer for me only'" isn't quite right either, because it still writes to Roaming vs Local . Functionally identical for a single-PC user, yes, but the folder is different, and this matters if they ever later join a domain or move the profile. Looks really comprehensive though, and more than reasonable... I like all this documentation and wish all developers did it!https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/10058/where-else-do-plug-ins-live/193234Fri, 24 Apr 2026 10:04:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:7b76809a-af8b-44dd-b074-42286bbc9fa1Michael BeijerHi Paul Filkin I have a related question. I'm working on the help documentation for my Supervertaler for Trados plugin. Of the three locations that appear in the plugin installer dialogue, which would you recommend I direct new users to select, if any? My inclination was to go with the first one because the dialogue always seems to open with that one preselected, but I'm not sure. (1) "All your domain computers": Location: C:\Users\mbeijer\AppData\Roaming\Trados\ For example: C:\Users\mbeijer\AppData\Roaming\Trados\Trados Studio\18\Plugins (2) "This computer for me only": Location: C:\Users\mbeijer\AppData\Local\Trados\ For example: C:\Users\mbeijer\AppData\Local\Trados\Trados Studio\18\Plugins (3) "This computer for all users": Location: C:\ProgramData\Trados\ For example: C:\ProgramData\Trados\Trados Studio\18\Plugins\Packages I also noticed a new option that helps with the previously messy situation where a plugin might be left in the wrong place. " Remove this plugin from all installation folders (recommended if you installed manually or multiple times) " Here is what I have so far in my help system: https://supervertaler.gitbook.io/trados/getting-started/installation Does this sound reasonable?https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60687/openai-provider-for-trados-studio-documentation-seems-incorrect-to-me/193228Fri, 24 Apr 2026 07:36:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:a92c473f-e36d-416b-8c0e-3f6b19e2134fPatrick Andrew HartnettImportant technical point: In a single pre-translate action, providers do not operate as if one provider can immediately consume another provider’s output within that same pass. So if TM, DeepL, and OpenAI are all enabled together in one ordinary pre-translate step, OpenAI does not reliably get access to the translation produced by TM or DeepL in that same process in the way a “review/update this translation” prompt would require. That’s why the OpenAI-specific batch task was added: to support the “second-pass review/update” scenario in one batch-task process. There is no other reason for that specific batch task to exist.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60687/openai-provider-for-trados-studio-documentation-seems-incorrect-to-me/193227Fri, 24 Apr 2026 07:28:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:a9d0533b-ff59-4116-94e2-e4e5f350aee8Patrick Andrew HartnettHey Jesse Good , your observation is valid, and I agree the current documentation can be confusing. For a normal pre-translation workflow , the best approach is typically not to use: Pre-translate Files followed by Pre-translate Files with OpenAI provider as a standard two-step sequence. The reason is that, in the first step, TM/MT/OpenAI can already run and OpenAI results may be cached. By the time the second OpenAI-specific step runs, it may mostly reuse cached output rather than meaningfully reprocessing segments based on TM matches. So for everyday pre-translation, the better workflow is indeed: run Pre-translate Files with TM first, so TM and fuzzy matches are leveraged, then run OpenAI afterward only for content not already covered. That said, the “Pre-translate Files with OpenAI provider” batch task was originally introduced for a more " specific scenario" : when OpenAI is being used to review or update an existing translation , rather than simply generate a first-pass translation. For example: first pre-translate with TM or another provider such as DeepL, then run OpenAI with a prompt intended to review/improve/update the existing translation. This is important because, within a single pre-translate action, providers run independently, so OpenAI does not necessarily have access to the translation output produced by TM/another provider in the way a “review this translation” prompt would require. So in short: for standard pre-translation , use Pre-translate Files with the OpenAI provider selected as needed; the OpenAI-specific batch task is really intended for the review/update translation scenario. I do agree the current naming/documentation is misleading, and we should improve that clarification.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60933/multilingual-excel-file-type---source-text-with-sentence-ending-characters-in-one-cell-is-not-correctly-taken-over-in-the-target-segment/193226Fri, 24 Apr 2026 07:13:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:7130818f-d829-41b5-a28a-9529e8543db8Patrick Andrew HartnettHi Barbara Zobrist , What you are seeing is expected behavior with the Multilingual Excel File Type . When Import Multilingual Translations (Excel) is run, Studio can safely segment only the source . It cannot reliably determine how the existing translation in the target cell should be segmented, because the target may contain a different number of sentences or a different sentence structure. ( community.rws.com ) For that reason, the import task deliberately places the entire target-cell content into the first segment of the paragraph rather than trying to distribute it automatically across all split segments. This was done as the safer option, to avoid incorrect alignment and duplicated or misplaced content in the exported file. ( community.rws.com ) So unfortunately there is no automatic way to correctly associate one multi-sentence translation cell with multiple source segments during import. In these cases, a manual post-edit/review is needed so you can split or move the imported translation to the correct segments yourself. ( community.rws.com )https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60897/wordlight-plugin-to-highlight-text-crashes-trados/193223Fri, 24 Apr 2026 06:45:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:c1e840e7-2738-4d17-a79c-47ad7c9a07fePatrick Andrew HartnettHi Giorgia De Zen , srry you’ve run into this. If Trados freezes when you click the plugin, the best next step is to remove Wordlight completely and, if needed, reinstall it afterwards. In Studio 2021, plugins are stored under the Studio 16 folders; I'd recommend removing the plugin from both Packages and Unpacked because leftover files there can cause this kind of behaviour. ( community.rws.com ) Please try this: Close Trados Studio completely In Windows Explorer, enable Hidden items Check these folders and remove the Wordlight plugin from both Packages and Unpacked if you find it there: C:\Users\%USERNAME%\AppData\Roaming\SDL\SDL Trados Studio\16\Plugins\Packages\ C:\Users\%USERNAME%\AppData\Roaming\SDL\SDL Trados Studio\16\Plugins\Unpacked\ If not there, also check: C:\Users\%USERNAME%\AppData\Local\SDL\SDL Trados Studio\16\Plugins\Packages\ C:\Users\%USERNAME%\AppData\Local\SDL\SDL Trados Studio\16\Plugins\Unpacked\ C:\ProgramData\SDL\SDL Trados Studio\16\Plugins\Packages\ C:\ProgramData\SDL\SDL Trados Studio\16\Plugins\Unpacked\ ( community.rws.com ) If you prefer, you can also try the standalone plugin installer/manager here: C:\Program Files (x86)\SDL\SDL plugin installer\Sdl.Community.SdlPluginInstaller.exe ( community.rws.com ) After removing the plugin files, restart Windows and then test Trados again. If needed, reinstall the plugin from the AppStore afterwards. Important: ensure Studio is closed before deletion and note that the folders are recreated when the plugin is reinstalled. ( community.rws.com ) If it still freezes after a clean removal/reinstall, it may point to a plugin conflict rather than a wrong download. Maybe check if other plugins are conflicting with it by removing them one at a time?https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60882/trados-data-protection-suite-not-working---studio-2024-sr1/193215Thu, 23 Apr 2026 14:05:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:b8d2562e-8232-4b22-8d96-f33021ee2d1dGreta MagyarThank you for the help. Working with the Dev team we have the solution: install the TM Anonymizer tool separately, which will create the required JSON file.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60877/deepl-plugin-keeps-forgetting-settings-studio-2024/193212Thu, 23 Apr 2026 12:46:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:bb595942-240d-4c79-a4a3-cd005cbe848aFlaviu TriteanHi Sarah Dussen , I tried to replicate the issue but I can't. Please, can you provide more info on the workflow? Also can you replicate that every time? How often that happens?https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60948/deepl-api---issue-with-tag-recognition-display-and-display-of-glossary-terms/193193Thu, 23 Apr 2026 08:05:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:807e2d5b-6895-4454-a41c-a5d3dedcac0aPatrick Andrew HartnettHi Elisabeth Orion , Thanks for the detailed description; What yr describing seems to be more like a DeepL API behavior than a Trados plugin defect. 1. Tag issue The key point is the Tag handling = None setting. When this is set to None , the content is effectively sent to DeepL without telling the API to treat tags as markup . So if your segments contain inline tags/placeholders, DeepL may interpret them as normal text, move them, expose them, or return them in an unexpected way. The plugin in Trados Studio simply attempts to render those results. That also explains why: the problem appears with None the problem does not appear with XML So for content that contains tags, XML/HTML tag handling is the recommended option . Using None is really only appropriate for plain text without markup. 2. Glossary terms shown between quotes The Trados DeepL integration does not apply extra quotation marks to glossary terms on its own. It sends the text, the selected settings, and the glossary id to DeepL, then displays the translation returned by the API. So if a glossary term is sometimes returned as: rail surface "rail surface" that would point to DeepL’s translation output , not Studio adding formatting afterward. 3. Why this may have started suddenly Since you mention that: it started recently you did not change your settings reinstalling the plugin did not change anything the most likely explanation is that something changed on the DeepL side rather than in the Trados plugin. What I would recommend Do not use Tag handling = None for segments containing tags. Use XML instead. If possible, test the same segment directly against the DeepL API with the same: glossary source/target languages tag handling setting If the same behavior occurs there, please raise it with DeepL , as they control the API behavior and glossary/tag processing.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60681/deepl-plugin-suddenly-not-working/193173Wed, 22 Apr 2026 08:35:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:155a24fc-d61e-41cb-aff0-985cacf1d1b6Daniel BrockmannThis has been fixed by DeepL and hopefully works for you again Carlo Capussotti , Anca Stoian - the issue was on their end as we suspected.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60948/deepl-api---issue-with-tag-recognition-display-and-display-of-glossary-termsWed, 22 Apr 2026 08:17:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:31572fa4-5cf2-4310-8fac-b83a9d5c8d42Elisabeth OrionWe have encountered an issue with tag recognition and display when using DeepL together with our glossary. This issue has been occurring since last week and did not exist previously, although we have not changed any settings. The problem first appeared in week 16 (mid-April). When using a glossary and leaving tag handling set to the default option None , we observe the following issue with tags in the source text: Screenshot of our settings: We tested different settings and the problem seems to appear only when the default setting Tag Handing None is used. It does not appear when XML is chosen. EDIT: We also tried to uninstall DeepL Plugin and reinstall it, latest version. --- Additionally to this, another problem appeared around the same time when using a glossary: The glossary entries are used but sometimes displayed between "...". See screenshot: Since this problem appears only in some segments and not in all of them we do not know how to do further testing to understand why this is happening. We use Trados Studio 2024, DeepL API and have a DeepL Team subscription; I’ve noticed that there have been quite a few issues with DeepL in Trados discussed here lately. Has anyone else encountered a similar problem? Does anyone know what could be causing this behavior, or what we could try in order to resolve the issue? Thank you in advance for any ideas or inputs.deepl apiGlossaryhttps://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60932/deepl-plugin-not-working/193172Wed, 22 Apr 2026 07:41:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:5b641ac0-8e13-446b-aa44-456d29f4dc33Federica CavallaroDear Ana Sabo thanks, the plugin is finally working.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60932/deepl-plugin-not-working/193164Tue, 21 Apr 2026 14:44:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:9fd28feb-232e-4fe0-9259-01def068ba3aRajan ChopraThanks for the update. The issue has been resolved.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60929/persisting-trouble-with-deepl-plugin/193161Tue, 21 Apr 2026 12:45:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:cd39363e-7971-468d-bd7d-88a8ca192e35Ana SaboHI Floriane Dollat Please post about your issue on a new thread and I will raise a ticket with the technical team to investigate further. Kind regards,https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60882/trados-data-protection-suite-not-working---studio-2024-sr1/193159Tue, 21 Apr 2026 12:39:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:4fae06c7-abfc-49a9-963c-e57ef6892970Greta MagyarThank you Patrick Andrew Hartnett looking forward to hear more.https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60929/persisting-trouble-with-deepl-plugin/193154Tue, 21 Apr 2026 11:24:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:6156431a-dd95-4ff4-a9a4-11a7c039d0c7Olivier MORICEHi Ana Sabo , Hooray, it's working again! THANK YOU to the support and development teams for being so prompt and helpful with this issue. Kind regards, Olivierhttps://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60929/persisting-trouble-with-deepl-plugin/193152Tue, 21 Apr 2026 10:50:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:0dbd62e5-f53a-49f4-880f-4f66e8acac1eFloriane DollatDoes it work again for you or do you also get "Deepl can't be opened and is therefore deactivated" ? I have the same Trados version as youhttps://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60929/persisting-trouble-with-deepl-plugin/193151Tue, 21 Apr 2026 10:37:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:7b223c3b-aa27-48de-8fa7-9e36f06d1280Floriane DollatI'm still experiencing problems, "Deepl can't be opened and was deactivated" when I try to add it to the TM of the projects. It was working just fine until yesterday morning. Even after the fix and after deleting, reinstalling the plugin, it's still not working. I have Trados 2024 SR1https://community.rws.com/product-groups/trados-portfolio/rws-appstore/f/rws-appstore/60925/deepl-in-studio-2022-does-not-function-any-more-tried-the-update-button-on-the-top-in-studio-something-happens-but-no-update/193150Tue, 21 Apr 2026 10:15:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:e57332de-bba5-4a27-9772-6a25dc8eb23eAna SaboHi Susanne Gansloser-Hartmann I'm happy to hear that is working now. Thank you for letting us know. Kind regards,