Under Community Review

Batch Rule Management & Validation for Custom File Types

Dear Trados Developers, 
I wish you all the best and thanks for always catering to our needs and ideas. Trados is always my preferred CAT tool.

Currently, the Document Structure and Inline Tags interfaces for custom file types require users to manually input "Opening" and "Closing" patterns one by one. For complex projects—such as localized software strings or legacy proprietary formats—this process is highly manual, error-prone, and inefficient.

Proposed Solutions

1. Batch Import/Export of Structure Rules

Developers should implement an Import/Export mechanism for Regex rules.

  • Supported Formats: .csv, .tsv, or .xlsx.

  • Functionality: A simple mapping system where columns represent:

    • Opening Pattern

    • Closing Pattern

    • Multiline (Boolean)

  • Benefit: Allows power users to maintain libraries of preset rules and deploy them to new file types in seconds rather than hours.

2. Integrated Regex Validator & Tester

To reduce "Project Settings" errors that only appear after attempting to open a file, an integrated validation tool is needed within the UI.

  • Regex Engine Parity: The validator should use the same engine Trados uses at runtime (e.g., .NET Regex).

  • Real-time Feedback: A "Test" field where users can paste a sample string of code to see if their patterns correctly identify and highlight the intended translatable text or tags.

3. Syntax Highlighting & Error Catching

The input fields for Opening/Closing patterns should include basic syntax highlighting to identify unclosed parentheses, escaped characters, or invalid quantifiers before the user clicks "Add."

Technical Use Case Example

In the provided screenshot, rules such as (?<=\|\|\|) and ^\d+\|\|\| are being used. When managing dozens of such delimiters, a single typo in a manual entry can break the entire file parsing logic. Batch importing ensures consistency across different workstations and projects.Trados Studio Project Settings window showing the Document Structure tab with fields for Opening and Closing patterns, a Multiline checkbox, and a table of existing rules.

Sameh Elsharkawy

  • One more thing too to complete the idea:

    Advanced Extraction: Support for Regexp Capturing Groups

    To reach parity with modern localization platforms like Phrase, Trados should implement support for Capturing Groups within the Regex rules.

    • The Feature: Instead of extracting the entire match of a regular expression, Trados should allow the user to specify a capturing group (e.g., $1 or ${content}) that contains the actual translatable string.

    • The Problem it Solves: Often, translatable text is wrapped in specific syntax that is too complex for a simple "Opening/Closing" pair logic. Currently, if a user matches a string like ID_101:"Translate Me", Trados might extract the quotes or IDs as part of the segment.

    • The Benefit: With capturing groups, a user could define a rule like ID_\d+:"(.*)". By telling the system to only extract Group 1, the translator sees only "Translate Me" in the editor, while the IDs and quotes remain protected in the background.

      By adopting these features—Batch Import, Global Regex Filtering, and Capturing Group Support—Trados would move from a rigid, manual entry system to a flexible, professional-grade configuration suite. 

  • If I also my add one important part to the idea above! 

    Global Regex Filtering (The "Phrase" Model)

    To further streamline the user experience, Trados should consider implementing an optional Global Rule Toggle.

    In competing tools like Phrase, users are not forced to create individual "Opening/Closing" pairs for every single rule. Instead, they can provide:

    • A single, combined Regex that defines all translatable content.

    • A single, combined Regex that defines all non-translatable/hidden content.

    By allowing a unified Regex field (using the | OR operator), power users can manage their entire document structure in one string. This eliminates the "death by a thousand clicks" of adding rules one by one and allows for much easier copy-pasting of complex logic between different file type configurations.