In addition to a list of predefined tests offered by The Validation Expert, Alchemy CATALYST facilitates an unlimited number of custom defined tests to be included.  You can create your own tests in one of the following categories.  To access this area of the product choose EXPERTS > Validate > Options  and press button beside one of the following tests.

 

Consistent Pattern Tests

Use this test to define a text pattern that should remain unchanged during translation.

If the specified pattern is found in the source and also exists in the translated target, then the pattern is consistent and no error is raised.  If the pattern is found in the source but not in the translated target an error is raised and is listed in the results bar.

An example of such a test may be to ensure a company or product name in a source text also exists in the target text.

See Define Consistent Pattern Test for more information.

 

Correct Translation Tests

This test type is used when a particular source text or pattern must be translated in a particular way.

A pattern is specified for the original text and if found, the valid translation pattern is searched in the translated text.  If both patterns match, no error is raised.  If the original pattern exists in the source, but the valid translation does not exist in the target, then an error is raised and listed in the results bar.

An example is when an imperial to metric conversion is required during translation, i.e. a test could verify if the word inch exists in the source, that cm exists in the target.

See Define Correct Translation Test for more information.

 

Invalid Term Tests

Use this test to define a term that should not exist in a valid translation.  Examples are old product or feature names that should no longer be used, but could still be referenced in a localization project.  This is also a useful test for frequently misspelled words.  The test fails if the defined pattern exists in a translation. The definitions can be made with plain text matching or with regular expression matching.

The list displays your defined tests and allows new definitions to be added.  Equally, the Remove and Edit buttons permit changes to already existing tests. The description area in the dialog shows the comment that was added during the creation process to describe what the test does.

See Define Invalid Term Test for more information.

 

Clipped Text in Dialogs Check

The Clipped Text in dialogs Validation Test verifies that translated text displays without any clipping on a dialog box.

With the option Ignore controls heights selected, this validation test ignores the height in calculating if a segment is clipped or not.

This check applies to  Win32 dialogs, .NET forms (framework and .Net5+), WPF and RESX.

Why use this option?

The Clipped Text in dialogs check compares the size of the segment (accounting for the font used) and the size of the control and if the size of the text is larger than the control, it reports it as clipped. In some situations, the text does not appear to be clipped even though the comparison above returns that the text requires a larger space than the control.
That’s because for certain characters, the system requires a certain space to include some empty space around the characters, so even if characters don't appear clipped visually, they require more space than what the control has.

For cases where the requirement for extra vertical space around the characters is not needed to display the segment without being visually clipped, you may use Ignore controls heights to not report them.

 

Glossary Consistency Check

Use this Validation Test to verify each segment which contains glossary terms are translated according to the Active Glossary file(s). This check can be configured to run in 3 ways, with default as "Anywhere in the text segment".

The validation of text between tags works on the inner most open-close tags pair (as in <b> some text </b>).

The test allows to check separately by tag or attribute or attribute's value, and also on a combination of tag and/or attribute and/or value.

 

Missing space around tags

Use this test to check the presence of spaces before and/or after inline tags. Tags are added to the validation test in 3 categories for which the test will fail if the requirement is not met.

By default, this validation test will check all self-contained tags. That is tags that do not require an equivalent closing tag.

 

Require a space before OR after there tags

Regular tags requiring a whitespace at one end, such as <b>, <strong>, <u>, <i>, etc... They require one space to be present at either end of the tag. They are tags delimiting a style within the string and are not treated like a word.
The validation test will fail should no space is present either before or after the tag.

 

Require a space before AND after these tags

Self-closing tags requiring whitespaces at both ends, such as Madcap tags. They require a space at either end because they are replaced by a word during compilation; the tag is a placeholder.
The validation test will report an error if either the space before or after is missing.

 

Skip space validation for these tags

Tags that are considered themselves as whitespace, thus do not require a space around them, for example the MadCap tag <MadCap:keyword>.
The <nbsp> inline tag is always treated as a space in CATALYST and so it is unnecessary to have it listed in this or any other Category.
The validation test by default will not report an issue as no space is required.

 

Acceptable characters between tag and space

The acceptable characters list includes a set of characters which are allowed to be present between the inline tag and the space character. If a tag is followed by one of the acceptable character, the test will ignore this character and allow the space to follow or precede it without failing.

Example:

In the string “This is a<tag>: element” the character : is considered as a valid separation (whitespace) between the <tag> and the next word element.

Treat these characters as space

Characters in this list are considered as equivalent of a whitespace within the scope of the missing space around tags validation test. They are allowed to substitute the space character.

Example:

In the string “This is very <tag>-important” the character - is treated as a space character and the Validation test does not report a missing space between <tag> and the word important.

 

Tags found at beginning or end of string

In all cases, the test is ignored for inline tags found at the beginning or the end of a string (at the extremities). This is because a space will not be necessary after a tag located at the end of a string and likewise at the start. This also applies to "space at both sides" inline tags. Depending on the position of the "space at both sides" tag at start or end of the string, the relevant space test before or after the tag will be ignored.

Inconsistent Inline Tags Check (excluding attributes)

This validation test verifies that the number of inline tags in source and target segments is identical. It will check that the same tag found in source is also found in target and vice versa.

For example, a Bold <b> tag found in source is replaced by an Italic <i> tag. This test would fail as it isn't the same tag. The Validation errors would report that a <b> tag is missing in translation and a <i> tag is not present in source.

Click on the Browse button [...] to extend the functionality of the test with the following options:

Include tag order sequence check

Check inline tags found in the translation match exactly the order in which they are listed in the source string. This is particularly useful with documentation file formats, such are .docx, where a difference in the inline tag's order can cause the translated file to fail to extract.

 

Include attributes inconsistency check

Check HTML attributes found within inline tags are matching. While the Inconsistent Inline Tag Check will report missing or extra tags, using this option will verify that the attributes within the matching tags are the same.

You may however ignore attributes found in certain inline tags if you know they will need to be translated. For example the attribute "alt" (alternative text for an image) found within an image <IMG> inline tag because it is expected to be translated. Adding the "img" tag to the Tag names exceptions will mean the attributes inconsistency check will not report on translated "alt" attribute strings.

 

Maximum Size Check

Defining a maximum size in the segment's properties means the translated text must fit within a restricted space which can be set in Characters or Pixels. By default CATALYST automatically wraps text within the frame created in the Translator Toolbar, representing the expected automatic wrapping of the text in the native project at runtime. This is with option Wrap text for Maximum size testing selected and applies to size limits in Characters on more than one line, and to size limits set in Pixels.

Example of a translated segment with a Maximum size set to 200 x 60 pixels with the option Wrap text for Maximum size testing selected:

Deselect the Wrap text for Maximum size testing if you do not wish for the text in the Translator Toolbar to automatically wrap and manually enter carriage return (newline) characters to control the wrapping of the text.

The same translated segment as above but with the option Wrap text for Maximum size testing deselected:

The Validation test fails where it didn't when enabling the text wrapping. Users need to enter newline characters in the desired position to fix the validation error

 

Proportional Size Check

Use this test to check the expansion of translation does not exceed a certain size measured in characters or percentage of the source string.

When setting "longer than percentage of source text length:", 100% represent the same length as the original text.

 

Inconsistent translations

In the workspace window the Filter Inconsistent Translated allows to list all instances of source strings for which at least more than one translation is used.

 

For example:

 

Original string

Translated string

Click this button to proceed

Appuyer sur ce bouton pour continuer

Click this button to proceed

Appuyer sur le bouton pour continuer

Click this button to proceed

Appuyer sur ce bouton pour continuer

 

 

This test will check and report all the string above because one of them is translated inconsistently.

 

Original string

Translated string

 

Click this button to proceed

Appuyer sur ce bouton pour continuer

Click this button to proceed

Appuyer sur le bouton pour continuer

Click this button to proceed

Appuyer sur ce bouton pour continuer

 

 

Click on the Browse button [...] for the Inconsistent translated test to select from a list of special characters which should be ignored when comparing translations for consistency. For example a full stop which is sometime found at the end of a sentence while not used other times.

 

 

The Duplicates and Inconsistent Source/Target Options dialog is common with the String list column options.

 

Changing one will change them all.

 

 

Check for inconsistent translations across multiple projects

You may check for consistency against other projects using the Batch of files option on the General tab of the Validation Expert. The most common scenario is to check for consistency against previously translated and released projects. For example the Help or Documentation project associated to a software project which has already completed translation.

 

Select Batch of files in the Validation Expert and list all the TTK projects to check for consistencies.

It is advised to only select "Inconsistent Translations" and/or "Inconsistent Sources" tests to avoid mixing errors from all other tests which all only apply to the active project.

 

 

The results of the Validation, using Inconsistent Translations test with Batch of files, will output to the Validation Results window with a group for each inconsistent segment.

 

You can expand each group and click on the individual segment error to automatically open the relevant TTK and highlight the string.

 

Inconsistent sources

In the workspace window the Filter Inconsistent Original allows to list all instances of the same translation used for different source strings.

 

For example:

 

Original string

Translated string

Cancel order

Annuler la commande

Cancel the order

Annulez la commande

Cancel the order

Annuler la commande

 

This test will check and report all the duplicate translated strings above for which the source is different. The Test will thus report:

 

Original string

Translated string

 

Cancel order

Annuler la commande

Cancel the order

Annuler la commande

 

 

 

Click on the Browse button [...] for the Inconsistent sources test to select from a list of special characters which should be ignored when comparing sources for consistency. For example a full stop which is sometime found at the end of a sentence while not used other times.

 

 

The Duplicates and Inconsistent Source/Target Options dialog is common with the Analysis Expert and with the String list column options.

 

Changing one will change them all.

 

Check for inconsistent sources across multiple projects

You may check for consistency against other projects using the Batch of files option on the General tab of the Validation Expert. The most common scenario is to check for consistency against previously translated and released projects. For example the Help or Documentation project associated to a software project which has already completed translation.

 

Select Batch of files in the Validation Expert and list all the TTK projects to check for consistencies.

It is advised to only select "Inconsistent Sources" and/or "Inconsistent Translations" tests to avoid mixing errors from all other tests which all only apply to the active project.

 

 

The results of the Validation, using Inconsistent Sources test with Batch of files, will output to the Validation Results window with a group for each inconsistent segment.

 

You can expand each group and click on the individual segment error to automatically open the relevant TTK and highlight the string.

 

 

Maximum Lines Check

This check is designed to detect translations in which the number of lines exceeds a defined number. The check is based on the present of newline characters, so word wrapping will not have an impact.

Number of Lines in translation greater than in the Original Text

Use this option if you want this check to report any segment for which the text is on more lines than the source text. This check will report even if the Validation Expert option Ignore error if present in source is used.

 

Number of Lines in Translation greater than [Value]

Use this option to hard set a specific number of lines across all segments.

 

Number of Lines in Translation greater than value specified in Memo

Use this option if your project includes a generic text in the memo field to define an allowed number of lines in the translation.
For example, memos in your project may include the text Max lines: x to define a limit of x number of lines. In which case you could use the following regular expression to Validate the translations.

Toggle the Group containing lines count value to highlight the section of the regular expression within bracket which include the numerical limit. In most cases, such as the above, the group will simply be one as there is only one pair of brackets.
An example where you would need to select a different group number would be for this regular expression which can look for the text rows OR lines.

For the check to take the correct information as the maximum number of lines, the Group should be set to 2. For convenience, the selected group is highlighted in blue in the regular expression.