Trados Studio
Trados Enterprise
Trados Team
Trados GroupShare
Trados Business Manager
Passolo
MultiTerm
RWS AppStore
Connectors
Beta Groups
Managed Translation
MultiTrans
TMS
WorldServer
Language Weaver
Language Weaver Connectors
Language Weaver Edge
Tridion Docs
Tridion Sites
LiveContent S1000D
XPP
Language Developers
Tridion Docs Developers
Community Help
RWS User Experience
Internal Trados Ideas Community
Mercury
RWS Community Internal Group
RWS Professional Services
RWS Training & Certification
Style Guides
RWS Campus
RWS Enterprise Technology Partners
Trados Approved Trainers
XyUser Group
ETUG (European Trados User Group) Public Information
Nordic Tridion Docs User Group
Tridion UK Meetup
Tridion West Coast User Group
Trados Studio Ideas
Trados GroupShare Ideas
Trados Live Team Ideas
Trados Live Terminology Ideas
Trados Enterprise Ideas
Trados Business Manager Ideas
MultiTerm Ideas
Passolo Ideas
RWS Appstore Ideas
Tridion Docs Ideas
Tridion Sites Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
Managed Translation - Enterprise Ideas
TMS Ideas
WorldServer Ideas
LiveContent S1000D Ideas
Contenta S1000D
XPP Ideas
Events & Webinars
To RWS Support
Detecting language please wait for.......
About
Number Verifier represents an application that allows to set up settings based on which the numbers verification process is executed.
While the standard number verification in Trados Studio may often be sufficient there are some occasions when a bit more control would be preferable, for example when translating documents that contain lots of numbers. This Number Verifier plug-in allows you to fine-tune settings to provide you with the desired balance between the number of false positives and potentially missed errors.
How to use
To have the app running, ensure that under the 'Verification' option the 'Number Verifier' is checked.
Using the Number Verifier plug-in is simple: the first four options always need to have at least one of them checked:
All other settings apply to one or more of these options. Once you are clear about what type of error you wish to check for you can set which segments should be checked. The options are basic and allow you to exclude segments that are locked or 100% matches, as well as segments that have no translation at all. An important point to note is that segments with content, but with the status ”untranslated”, will not be checked if you use the ”Exclude untranslated segments” option. It is assumed that segments with content will be draft at least.
You can select "Exclude tag text" if you find that you get duplicate error messages since the change of a number in a tag constitutes a tag change that is reported by the tag verifier.There have also been cases where leading zeroes have caused problems in verifying numbers. To cater for this you will find an option at the bottom of the settings to ”Omit leading zero” from the source and/or target.The Number Verifier also creates a log file of the issues it has found. You can select the Extended option for Messages if you want the source and target text to be included in the log file. A nice enhancement in version 1.1.8.6 and above is to identify the numbers that are affected in the extended option. This is very useful if you have many numbers in the segment and only one or two are wrong.
AlphanumericsIn addition to plain numbers, the Number Verifier plug-in can also be used to find changes to alphanumeric names. For example, if VT500 has accidentally been translated as VR500 an error can be displayed. Here, an alphanumeric name is defined as a string of characters starting with one or more uppercase letters (A-Z) followed by any combination of digits (0-9) and uppercase letters. (Please note that if VT500 has been translated as VT300 this will also be identified as a modified number.)You’ll also find an option to specify custom Alphanumeric separators. Studio will recognise alphanumerics but only under certain conditions:
The Number Verifier allows you to specify whatever separators you wish and still verify correct transposition from the source to the target translation.
LocalizationsStudio always uses the rules set by the Windows operating system to decide what a number should look like. In reality, life is more complex than that, so there are three options you can use and you must select one of them.
If a number in the source is identified as using one of the possible thousands or decimal separators specified for the source separators, the translation must contain corresponding numbers with any of the separators specified for target separators or else the number will be considered modified/unlocalized.
If a number in the source is identified as using one of the possible thousands or decimal separators specified for the source separators, the translation may contain corresponding numbers with either the same separator as the source number or with any of the separators specified for target separators, or else the number will be considered modified/unlocalized.
The same thousands or decimal separators as in source must be retained in the translation or else the number will be considered modified.
You can select the thousands and decimal separators you want to allow. For example, you may allow one or more thousands separators depending on language standards. Similarly, you may allow for both a period and a comma to be used as a decimal separator, in order to allow for cases where for some reason more than one language standard should be allowed. The selected separators will then be combined with the Localizations setting to determine what should be considered a modified/unlocalized number. You can also specify a custom separator to suit any requirement you may be dealing with.
The option ”Check for Hindi numbers” should be disabled unless you specifically wish to QA check the use of Hindi as opposed to Arabic numerals. The rules used are:
Arabic -> Hindi0 -> ٠1 -> ١2 -> ٢3 -> ٣4 -> ٤5 -> ٥6 -> ٦7 -> ٧8 -> ٨9 -> ٩10 -> ١٠The numbers are written left to right as they are for Arabic numerals but without any thousand separators. The decimal becomes a comma. So this:1,234.89 or this 1.234,89would be written like this:١٢٣٤,٨٩
Number Format Errors
Choose to report number format errors when you want to recognize both generic and custom issues given specific settings provided by the user.
How to run verification
After all the settings were applied, the user can start translating the document. After confirming the segment(s), by pressing the F8 keyboard, the Number Verification process is executed. Once is finished, if any warning/errors were found, are all displayed in the Studio Messages window.
Show message details
Users can visualize the message details using 2 options, that can be selected from the Number Verifier Settings grid:
The "Brief" option shows the details which include the document name, error message with the text issue(s), the segment number where the issues were found and also the content of the Source and Target. (The description of the "Brief" option can be seen also if the user hovers the mouse over it.)
The "Extended" option displays the exact text which was found as an issue in the translation. The found text is coloured, so it can be easily distinguished. (The description of the "Extended" option can be seen also if the user hovers the mouse over it.)
Tooltips
1. Tooltips added for the Messages options in "Number Verifier Settings" grid
Users can see the details of the options "Brief" and "Extended" by hovering the mouse over each option.
Extended Results
The "Extended" option is showing the verification results in more detail.
Logging
The application logs information about the flow which is useful to identify issues that might occur. If some errors are caught, the NumberVerifierLogs.txt file will be created at the following location: C:\Users\{UserName}\AppData\Roaming\RWS AppStore\Number Verifier\NumberVerifierLogs.txt and it will contain errors details. The file can be attached to the email / Sdl Community forum topic when a problem regarding the application is raised.
Consistency Checker
This checks to see whether numbers (or sequences, if at least one of them is not a number) from the source match those in the target.
Given the fact that the user makes some choices regarding the separators used as thousand and decimal separators for the source and the target separately, and also whether 0 can be omitted either in source or in target, to be able to decide whether the number in the source is the same as the number in the target, we have to:
From the perspective of the user, the errors are of two kinds:
In the normalized form of the number:
t - thousand separator
d - decimal separator
Also, there's a new setting added:
When