https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/en-USTelligent Community 12 Non-Productionhttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60790/api-calls-to-pretranslate-files-using-deepl-plugin-no-longer-work/192626Thu, 02 Apr 2026 09:38:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:91e948be-af5a-4fde-b65a-511064be7aa9TTS TeamWe use the latest published version, 7.1.5.0https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60790/api-calls-to-pretranslate-files-using-deepl-plugin-no-longer-work/192622Thu, 02 Apr 2026 07:29:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:9ee628e6-b875-4294-90a2-ce6b300bc7a7Patrick Andrew Hartnetthey TTS Team , what is the version of the plugin that is installed on the machine where you are running the automation?https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60767/create-project-via-api-shows-files-as-reference/192618Wed, 01 Apr 2026 15:20:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:8093b56a-7aee-406b-b768-452919cf5140Patrick Andrew Hartnetthey Mark Owens , I’ve investigated this issue and have been able to reproduce it. The problem appears to start during the Automatic Task Scan step. At that stage, the SourceFile role should normally be identified as Translatable , Reference , or Unknown . However, in my testing, the files are consistently being set to Unknown or Reference , even for file types that would normally be expected to be translatable (for example, a simple .txt file). Because the scan is not classifying the files correctly, the bilingual files are not generated , and as a result the downstream project automation steps do not proceed as expected. At this point, this appears to be a product issue rather than expected behavior. I have escalated it to the Studio team for review. I do not have an ETA yet, but I will update this thread once I have more information. Thanks for reporting it and for providing the sample materials, which helped confirm the behavior. Internal Reference: SRQ-30939https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60790/api-calls-to-pretranslate-files-using-deepl-plugin-no-longer-workWed, 01 Apr 2026 14:25:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:1884f22f-c17e-4bf7-94c6-3d7e99be4f17TTS TeamHello, Since DeepL changed their authentication methods, we no longer can pretranslate our files using API calls to Trados 2024. It still work when pretranslating "manually" from within Trados Studio, but when using the API call project . RunAutomaticTask ( targetFiles . GetIds () , AutomaticTaskTemplateIds .PreTranslateFiles ) , it won't work. We've narrowed it down to DeepL API key authentication: when adding the DeepL provider manually in Trados Studio, the API key is automatically authenticated when you enter it in the settings dialog for DeepL, but when our external tool uses Trados API to add the DeepL provider to the project using our API key, no such validation occurs, and that's what blocks the pretranslation task from working. So my question is: is there any way to make it work, it worked just fine before the authentication change? We even tried duplicating the API key authentication when adding the provider to the project, but no luck there. Thanks for any help on this subject.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60767/create-project-via-api-shows-files-as-reference/192610Wed, 01 Apr 2026 11:10:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:90b8edf2-fb5c-448a-b6b8-3b6d9ac75522Mark OwensThanks Patrick, You should receive an email with links to the relevant fileshttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60767/create-project-via-api-shows-files-as-reference/192609Wed, 01 Apr 2026 10:32:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:6b5d7ce6-3138-4e25-bcbf-bdce748598dcPatrick Andrew HartnettHi Mark Owens , can you share the code project (and possibly the project template) so that we can understand better what the problem might be. pls send to phartnett@rws.com Don't send the zip in the e-mail, instead upload it to Dropbox, onedrive or other and share the download link with me via e-mail. then I'll take a look and provide some feedback.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60767/create-project-via-api-shows-files-as-referenceMon, 30 Mar 2026 11:05:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:546ec328-8073-4256-a901-267366c7be39Mark OwensHi I've recently upgraded to Trados 2024, and am running code that creates a new project from a Studio 2024 template, add files, and machine translates. All VS references are for Studio 2024 assemblies. The template is setup exactly as you'd expect to do this. There is no memory selected, and the DeepL translation configuration is correct. The file types for the template have most entries in the list unticked, but XML2: MadCap Compliant is ticked. The program steps are: Create project AddFolderWithFiles (recursively) Save project Scan files Save project ConvertToTranslatableFormat (via RunAutomatiobTask) CopyToTargetLanguages (via RunAutomatiobTask) Save project Modify settings to applyAutomatedTranslation Save settings Save project PreTranslateFiles (via RunAutomatiobTask) Save project It never seems to use the project template setting to recognise the .htm files are translatable. If I create the project manually, with the same template, same source files, it performs the MT as expected. There must be some sort of gotcha going on. Can anyone tell me where I'm going wrong? Thanks Markhttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60518/request-for-meeting-to-clarify-tm-matching-behavior-with-lara-integration/191838Tue, 10 Mar 2026 08:13:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:5f6c4c93-e7fc-411e-a0f0-3b33f0fc83e7Patrick Andrew HartnettHi Giulia Ceccacci , maybe a better start would be to provide a sample project and steps + expectations, so that we can reproduce the exact scenario you are describing above? We can then better determine if what you are describing is expected behavior or not and take it from there. WDYT?https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60518/request-for-meeting-to-clarify-tm-matching-behavior-with-lara-integrationThu, 05 Mar 2026 09:18:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:9c97e842-f14e-485a-9aeb-5ee2c7dd9d11Giulia CeccacciMy name is Giulia Ceccacci and I work at Translated, where I focus on technical support for Lara, our AI translation platform. I've recently been running several tests on the integration between Lara and Trados Studio, and I’ve noticed a few behaviors regarding translation memory matching and segment confirmation that I would like to better understand from your side. In particular, I’m seeing some inconsistencies in how TM matches (including 90% matches) are recognized by Trados depending on whether the TM is selected in Trados, in Lara, or in both. In some cases Lara correctly retrieves a match from the TM, but Trados does not recognize it as a TM match, which means the segment still needs to be manually confirmed. Additionally, I’m observing a bug where the suggested translation reverts to the source language when the segment is confirmed, which we are currently investigating on our side. Since some of these behaviors may depend on how Trados handles TM matches, pre-translation settings (e.g. Keep Existing Translations), and external providers, I think it would be very helpful to schedule a short meeting to walk through the scenarios together and clarify what we should expect from the Trados side. Would you be available for a quick call in the coming days? Let me know, GiuliaTranslatedTrados StudioLara Translatehttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60491/tradosapi-within-plunet-ran-out-of-memory-message/191728Wed, 04 Mar 2026 13:56:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:16ece204-300a-45cc-88fc-97a345696c4fDaniel BrockmannYes - we have enhanced memory handling over the years so the situation got better, but we were still hitting a hard limit with 32-bit with approx. 3 GB max. Now with 64-bit, that limit goes away and we should not run into such OOM errors anymore on current hardware. So it might be good to validate that when you can with the beta version.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60491/tradosapi-within-plunet-ran-out-of-memory-message/191725Wed, 04 Mar 2026 13:48:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:e7c8c35b-f099-4a0d-8c55-3aeac1a6cb53David McDermitHello Paul Thank you. I don't know. this has been an issue going on between Plunet and RWS and us for about 4 years now. Each states the newest version will fix the issue over the years. Right now it sometimes works. I would hate to get to the point where does not work at all. Thus hesitation bringing in a beta test version. I will have to discuss with IT.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60491/tradosapi-within-plunet-ran-out-of-memory-message/191710Tue, 03 Mar 2026 23:37:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:da79b14e-1021-4e03-ac0f-4677d64714c5PaulDavid McDermit For reference this relates to our reference CRQ-41550 . The current status of this refers to it being a problem that should resolve itself when we move to the 64-bit version of Trados Studio. If you would like to test that theory we are beta testing the 64-bit version of Studio in the beta community right now? We can add you to that. Regards Paul.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60491/tradosapi-within-plunet-ran-out-of-memory-messageTue, 03 Mar 2026 14:54:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:28ba674c-5dd2-4faf-9e31-e865969cae1eDavid McDermitHello Have been having an issue with the TradosAPI within Plunet to run analysis of translation requests. Presently have updated the server and all programs within Plunet and the TradosAPI. This seems to have fixed the Critical error message we would get when running jobs over 1100 words. After getting everything up-to-date we are now running into a Ran out of Memory message when running larger jobs. What can I supply that might help solve this issue?PlunetTradosAPIhttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviour/191638Fri, 27 Feb 2026 16:12:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:64d96a4a-34f0-4943-b0d0-69281d337ff6Damien MorardHello Alexandru Florescu Thank you for your investigation and for the detailed explanation. I was able to test the proposed solution using the example I originally provided, and it now works as expected. The translation units are successfully added with the updated configuration. Many thanks for your help and guidance. Damienhttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviour/191637Fri, 27 Feb 2026 15:30:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:dcce18bc-4d70-4535-aa96-4b4e58cf635bAlexandru FlorescuHello Damien , Thank you for reaching out. We have investigated the reported issue and were able to reproduce it using your specific format. The root cause appears to be that the default ImportSettings instance does not automatically allow for adding translation units. To resolve this, you need to explicitly define the properties that govern how the process handles those units. For example, try configuring your ImportSettings as follows: var importSettings = new ImportSettings() { PlainText = true, ConfirmationLevels = new [] { ConfirmationLevel.Unspecified }, NewFields = ImportSettings.NewFieldsOption.AddToSetup, ExistingTUsUpdateMode = ImportSettings.TUUpdateMode.Overwrite, ExistingFieldsUpdateMode = ImportSettings.FieldUpdateMode.Overwrite, TUProcessingMode = ImportSettings.ImportTUProcessingMode.ProcessBothTUs, }; Using this configuration, the translation units were added successfully in our tests. Additionally, if you are working with GroupShare APIs in a .NET environment, we recommend using the GroupShareKit package. It is specifically designed to streamline this process. You can find more details at this link . Please let us know if this works for you or if you need further assistance.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviour/191300Tue, 17 Feb 2026 15:31:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:cf6431bf-3c9f-4a97-8a56-126a2efd149eDamien MorardThank you for your message.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviour/191219Fri, 13 Feb 2026 08:53:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:4a99c95f-bcad-4c14-9d47-85e29b71e0dfCommunity JiraThank you for bringing this to our attention. Our development team will review it in the context of our ongoing projects and priorities. Your understanding and patience as we assess this matter is appreciated. We have recorded the issue in our tracking system under the reference number SDLCOM-6722https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviour/191218Fri, 13 Feb 2026 08:50:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:53444c27-85b9-4c6f-b1d3-329ddfbc9fb6Patrick Andrew HartnettHi Damien Morard , I'll review this with the team and circle back to you.https://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60313/groupshare-adding-translation-units-directly-via-trados-api-always-results-in-discard-expected-behaviourMon, 09 Feb 2026 15:43:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:a9545179-4dae-43b2-9dd4-ea2807543581Damien MorardHello everyone, I’m currently experimenting with the Trados APIs to programmatically populate a server-based GroupShare TM (GS 2020 / Studio 2021), and I’ve run into a behaviour that I’d like to better understand or confirm. Context GroupShare 2020 Trados Studio 2021 Server-based TM created specifically for testing User has admin roles in GroupShare Importing a TMX manually via Studio works Importing a TMX programmatically via the API also works However, when trying to add Translation Units directly via the API, nothing is persisted. What I’m trying to do I’m using ServerBasedTranslationMemoryLanguageDirection.AddTranslationUnit(...) to insert a simple TU (plain text, no tags). Below is a simplified example of the code I’m using. (It does not contain all variables/constants, but should give a clear idea of the approach.) private static void Main() { try { AssemblyResolver.Resolve(); var server = new TranslationProviderServer( new Uri(GROUPSHARE_TM_ENDPOINT), useWindowsAuthentication: true, userName: null, password: null); var tms = server.GetTranslationMemories(TranslationMemoryProperties.None).ToList(); Console.WriteLine($"Connection OK. Found {tms.Count} TM(s) on the server:"); foreach (var t in tms) { Console.WriteLine($"- {t.Name} | {t.Id}"); } var tmRef = tms.FirstOrDefault(t => string.Equals(t.Name, TM_NAME, StringComparison.OrdinalIgnoreCase)); if (tmRef == null) { return; } var tm = server.GetTranslationMemory(tmRef.Id, TranslationMemoryProperties.None); if (tm == null) { return; } var sourceCulture = new CultureInfo("en-GB"); var targetCulture = new CultureInfo("fr-FR"); var ld = tm.LanguageDirections.GetLanguageDirection("en-GB", "fr-FR"); if (ld == null) { return; } var tu = new TranslationUnit { SourceSegment = BuildPlainTextSegment(sourceCulture, "Hello world!"), TargetSegment = BuildPlainTextSegment(targetCulture, "Bonjour le monde !") }; var importSettings = new ImportSettings(); var result = ld.AddTranslationUnit(tu, importSettings); Console.WriteLine($"Cached TU count: {tm.CachedTranslationUnitCount}"); Console.WriteLine($"Actual TU count: {tm.GetTranslationUnitCount()}"); Console.WriteLine($"TM IsReadOnly: {tm.IsReadOnly}"); Console.WriteLine($"TM SupportsUpdate: {tm.SupportsUpdate}"); Console.WriteLine($"Has Delete permission: {tm.HasPermission(TranslationMemoryPermissions.Delete)}"); Console.WriteLine($"Has Add permission: {tm.HasPermission(TranslationMemoryPermissions.Add)}"); Console.WriteLine($"Has Edit permission: {tm.HasPermission(TranslationMemoryPermissions.Edit)}"); Console.WriteLine($"ImportResult: {result}"); } catch (Exception ex) { Console.WriteLine("Error while inserting TU:"); Console.WriteLine(ex); } } private static Segment BuildPlainTextSegment(CultureInfo culture, string text) { var segment = new Segment(culture); segment.Add(new SdlText(text)); return segment; } Output After running this code, I consistently get the following output: Cached TU count: 0 Actual TU count: 0 TM IsReadOnly: False TM SupportsUpdate: True Has Delete permission: True Has Add permission: True Has Edit permission: True ImportResult: Discard-(0, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)-OK So: No exception is thrown Permissions look fine The TM is writable But no TU is added ImportResult always comes back as Discard Additional observation / question When switching to a TMX-based approach (i.e. generating a TMX file and importing it via the API), the import works correctly and the TUs are effectively added to the server-based TM. In contrast, inserting TUs one by one via AddTranslationUnit consistently results in a Discard without any explicit error, even when using an admin account. This makes me wonder whether direct TU insertion via the API is intentionally restricted in GroupShare, or if there is some server-side policy or design decision that silently discards such inserts. Is this behaviour expected for server-based GroupShare TMs, and is the recommended or supported approach to populate them exclusively via batch TMX imports rather than direct TU insertion? Thanks in advance! DamienGroupShareTranslation Memory APItrados APIserver based memoryhttps://community.rws.com/developers-more/trados-portfolio/trados-studio-developers/f/sdk_qa/60256/trados-api-extraction-failure-file-version-could-not-be-identified-new-case-comment/191067Mon, 09 Feb 2026 08:27:00 GMT10acfa76-f078-475b-a7ef-fc5b3e8d2934:75bfffd6-8235-4a9d-83f9-58ca9c63f84ePatrick Andrew HartnettHi Dpto. Tecnico Linguaserve , A few important points: The error is thrown when constructing Sdl.ProjectAutomation.FileBased.FileBasedProject, i.e. while trying to read the project metadata and determine the project/version. This is often unrelated to what “looks OK” inside the SDLXLIFF. The stack trace includes ApiTAO, which I don’t recognize, what is this?. Also, this looks like it may be a standalone project automation process running outside Studio, so the execution context and referenced assemblies/versions matter. To get started, could you please share: A minimal reproducible package : ideally the full project folder including the .sdlproj and the SDLXLIFF that triggers the issue (not just the SDLXLIFF). Your Trados Studio version/build and the version used to create the project. The exact input values you pass (the projectPath and fileId ), and confirm whether projectPath points to the .sdlproj . The full exception output ( ex.ToString() ), including inner exceptions. A small code snippet / repro project showing how you instantiate FileBasedProject and how you resolve/load the Trados assemblies (especially if running as a service or on a server). If you prefer to send this information privately, please send a link where I can download the files to phartnett@rws.com