User-Defined Checks
With User-defined checks, you can create your own checks in Verifika which enables you to address any unique client requirements that go beyond the scope of built-in checks.
Check Anatomy
Creating a check is straightforward. Essentially, you're telling Verifika to report segments where the source and/or target text includes specific elements you want to verify.
[1] Check name: Make sure to give your checks descriptive names. These names will appear as error descriptions in your report and help organize it.
[2] Search parameters (CTWRP)
[3] Search modes
[4] Languages: Specify which languages the check should be applied to. This way, you can create checks that work for all languages or only for certain languages like Chinese or Spanish.
[5] Group in: Use this option to categorize related checks, making it easier to manage them.
For an overview of Verifika's search capabilities, please refer to the Search section.
  • Check examples
    Consider the following check examples that could be beneficial for your projects.
Number Formatting as in Source
By default, Verifika uses language standards for checks like number formatting. However, sometimes client requirements specify that numbers in the target text should match the formatting in the source. Instead of setting up new profiles for each language, you can use user-defined checks to specify number formatting used in the source.

Say your source has a period for decimals (0.5) and a comma for thousands (11,200) with exception for 4-digits (1200). To verify that target follows the same formatting, you'll need just 2 checks with the following regular expressions in the source:
  • [1] For decimals: (\d+.\d+)
  • [2] For thousand separators: (\d+,\d+|\b\d{4}\b)
With cross-segment back-reference (B) activated for the target expression \1.

The ready checks will look like below.
By setting up these checks, you can detect mismatches in number formatting that should have followed the source.
Untranslated Prepositions and Conjunctions
It's a common error to leave words like "and," "or," "for," etc., untranslated in the target text. Instead of delving into the reasons, let's focus on a straightforward set of checks to address this issue.
Negative Numbers Matching
If you've disabled the standard check for mathematical signs but still wish to ensure that both source and target segments contain the same number of negative numbers, you can create a check to do just that.

Use \D(-\d+) regex for source and \1 with the "B" parameter for target. \D means any non-digit symbol and is used here to exclude number ranges from the check.

Remember to choose the search mode "Different amount of text is found in source and target" to identify discrepancies.
This setup will help you spot any inconsistencies in the number of negative numbers between source and target segments.
Missing Comma between Tags
To catch missing commas between formatting tags, like in enumerations, use the regex (>,\s<) with the T parameter enabled. This allows the search to include tag content. In the target field, again use \1 which is a cross-segment back-references (B). This is another example of how versatile and useful the B parameter can be.
Was it helpful?