Custom regex rules allow you to create domain-specific quality assurance checks beyond Gridly's predefined QA check validations. These rules help enforce content formatting, syntax patterns, and consistency requirements specific to your localization project.
Create a new custom regex rule
- Navigate to Settings → Localization settings → Auto QA
- Switch to the Custom regex tab
- Click Add regex rule
- Fill in the settings:
- Name: Enter a name for your rule
- Error check rule: Select from the available rule types (More details below)
- Source/Target regular expression: Enter your regex patterns based on rule type.
- Description (optional): Additional context about the rule's purpose
- Include tags in check (optional): Enable if you need to validate tag content (More details below)
- Click Create to save the rule
Rule types and configuration
When creating a rule, you'll choose from three rule types. Each type has different configuration requirements.
Counts of regex matches differ
This rule type checks that the source and target text have the same number of specific regex patterns. It's particularly useful for validating paired punctuation, placeholders, or formatting tags.
Use cases:
- Ensuring consistent placeholder counts:
\{\{\w+\}\}to match variables like {{name}}, {{date}} - Validating paired punctuation:
"to check quotation marks - Checking bracket consistency:
\[|\]to match square brackets
Configuration:
- Source regular expression (required): Pattern to match in source text
- Target regular expression (required): Pattern to match in target text
Example:
This rule checks if the number of variable placeholders in the source text matches the target text.
Consider this segment, the variable placeholder {{name}} appears in source text but not in target text. QA check returns the custom regex error.
When the variable placeholder {{name}} is in both source and target, QA check returns no error.
Forbidden regex match in source
This rule type checks if a specified forbidden pattern appears in the source text.
Use cases:
- Detecting notes or marker texts:
TODO|FIXME - Identifying problematic characters:
[^\x00-\x7F]for non-ASCII characters - Catching formatting issues:
\s{2,}for multiple consecutive spaces
Configuration:
- Source regular expression (required): Forbidden pattern in source text
Example:
This rule flags any source text containing “TODO”, “FIXME”, or “TBD” markers that should not be included in production content. Note that the regex is case-sensitive, so "todo" or "fixme" in lowercase would pass.
When QA check detects the forbidden pattern in the source text, it will return a custom regex error.
Forbidden regex match in target
This rule type checks if a specified forbidden pattern appears in the target text.
Use cases:
- Detecting untranslated content in target text:
[a-zA-Z]{3,}for detecting Latin characters in non-Latin languages - Preventing placeholder or marker text from reaching production:
\[[^\]]*\]for bracketed placeholders like [PENDING] - Catching accidental copy-paste content from source:
Lorem ipsum|placeholder text|sample data - Blocking specific formatting or characters inappropriate for the target language:
\s{2,}for multiple spaces
Configuration:
- Target regular expression (required): Forbidden pattern in target text
Example:
This rule catches any bracketed placeholder text like [TRANSLATE] or [PENDING] that translators may have left in the target.
When QA check detects the forbidden pattern in the target text, it will return a custom regex error.
Include tags in check
By default, regex patterns run on text content only, excluding inline tags. You can include tags in your custom regex rules.
When disabled (default):
- Inline tags like
<bpt>,<ept>,<ph>are stripped before applying regex - Safer for general text formatting checks
- Prevents tag markup from interfering with content validation
When enabled:
- Regex runs on the complete string including all inline tags
- Useful for validating tag consistency or variables within tags
- Example uses: Checking
{{variable}}inside<span>elements, validating tag structure
Example:
This rule checks if variables wrapped in <b> tags appear the same number of times in both source and target text. Include tags in check is selected.
The {{name}} variable is between the <b> tags in the source text but not in target text. QA check returns the custom regex error.
Managing custom regex rules
Edit a rule
- Click the
icon to modify settings - All fields except rule type can be updated
Enable/Disable rules
- Use the Active toggle next to each rule
- Disabled rules won't run during QA check
Delete rules
- Click the
icon next to the rule - Confirm deletion in the popup dialog
Set severity level
By default, custom regex rules are assigned Warning severity level. To change severity level:
- Navigate to Severity settings tab and find your custom regex rule.
- Select the severity level: Error, Warning, or Info.
- Click Save.
Related resources