Hi Paul,

The problem was caused because the source document was badly formatted, containing a mixture of numbers correctly formatted in French with the non-breaking space and other sections where they were formatted with the period as the thousands separator. The number checking in Studio's standard QA checker was turned off and the following images show the settings in the number verifier plugin. Despite the fact that both the space and period are shown as valid thousands separators, I got hundreds of errors saying "numbers modified/unlocalised". This means that relatively unimportant "unlocalised" errors are mixed up with serious "modified" errors.

My justification for my statement is that if error checking produces so many false positives that they cannot be examined manually, then there is, in effect, no error checking. It is a fact of life that translators have to deal with badly formatted documents and must do so without introducing errors of substance.

XBench located the error immediately and produced no false positives.

I hope this is of use and I am at your disposal if you have further questions.

Thank you for your time.

Neil

Hi Neil Allen

One simple way to detect such wrong or forgotten numbers and get a distince error message would be this regex:

This will interpret 123.456,12€ as three individual numbers, but it will flag up a modified number in all but one cases I can think of. (That case would be that no thousands separators are used in the source, but some kind of separator is used in the target.) This is not as comprehensive as XBench, but it would catch most mistakes I think. Again, using Regex Autosuggest might greatly reduce the amount of mistakes introduced into the target text.

The formatting check might be done as a separate step, again with the advantage of getting a distinct error message:

(((\d{1,3},)+\d+)(\.\d+))|((\d{1,3},)+\d{3}[ $€]?) ...or something similar would flag up numbers with a comma as thousands separator. (Just check the target.)

The position of a currency symbol or measurement would be a third regex, maybe (\d [€])|([€]\d) if you want to be alerted if the € symbol is anywhere but right after the last digit.

I am not saying this rivals Xbench - that is a whole product designed to do nothing but QA, but I think there are simple ways to use Studio's QA checks to safeguard against most number-related QA problems.

Daniel

I have to agree with Neil about the irritation of false positives and how it makes you annoyed with Studio.

I have had problems with false positives from date recognition in Austrian for years.

I reported it years ago and, since other people commented about other languages with date recognition problems in the same thread, I naively thought it would be corrected "soon".

For example "1. Januar 2018" is NOT recognised as a date in Austrian, but its translation into English as "1 January 2018" IS recognised as a date.

So I get 3 errors, two errors because the numbers "1." and "2018" are missing in the target segment ("1. Januar 2018" is recognised as 2 numbers separated by a word in Austrian) and then I get a third error because Studio thinks there is an extra date in the English target segment.

I have been thinking about converting the Austrian TMs and termbases to German (which does not have this problem) to get rid of the annoyance, but that means convincing the clients and then actually spending the time to do the conversion, so I will probably let it slide another few years before I finally lose my patience. If I had known this in advance I definitely would not have used Austrian.

Yes, it is technically possible to use regex when I happen to get another Austrian job that happens to have a lot of dates in it, but I don't have the patience for using a separate workflow in these cases. I just grit my teeth and spend the few additional minutes needed in that occasional job to check the list of "missing" numbers.

It does, however, leave a bad taste in my mouth every time. (Customer satisfaction?)

Best regards,
Bruce Campbell
ASAP Language Services

Unknown said:

Until then, I see XBench or some equivalent solution as being an absolute necessity for anyone who does financial or technical translations.

XBench: I would definitely do the same if I was in your position.

My point was not to say that everything is perfect with the Studio number check - it's not. I just meant to point out that there are simple ways (\d+ -> $1) to work around certain problems in most cases. Regex is far more limited than a programmatic solution, that's obvious. And, yes, checks that produce lots of false positives are useless - I turn them off.

Daniel

Hi all,

In general it's worth knowing how to get the best from Studio when you work with it.  It does have some strong points when working with numbers/dates/units/etc. but it can also be a complete pain in the neck.  For example, Studio uses the language cultures in your operating system to be able to recognise these things.  This means you never have to create paterns for anything you need as long as they are written in one of the ways your operating system would expect them.  This applies to your source and your target.  This is a nice feature and was put there for the right reasons which was making it easier for the user.

However, the drawback is that if these patterns don't match what your operating system expects then there is no mechanism for adding your own custom recognizers.  Tools like memoQ for example don't have this ability to automatically recognise them but it does come with a built in set of patterns that cover most things, and if you need anything else you can add them.

So the way to work with Studio, in my opinion, would be this:

1. Create your project
2. Check to see whether the source patterns are recognised as expected
3. If not then use something like the SDLXLIFF toolkit to "correct" these patterns so that the source patterns are recognised by Studio
4. Check to see whether the target output when autotranslated is what you expected.
5. If it is then you can now translate the project and the QA checks built in should give you better results
6. If it isn't then allow Studio to do its thing and translate anyway so you can properly QA the consistency of the values of your patterns.  Then search replace the target when the translation is complete with the patterns formatted as required

This is obviously not ideal, and I would prefer that we had more ability in the core product to cope with non-recognised patterns of any kind.  But until we do I would always work like this to avoid frustrations from not having control over what's happenning in the project.

Another thing that sometimes works is to add the patterns you need to your languages in Windows.  Then restart your computer and you may find that Studio now recognises the new pattern you wanted.  The only problem with this approach is that it doesn't transfer with a project for another user, but if you're working on your own it may be the best solution as it avoids the workflow outlined above.

Hi Neil Allen  Daniel Hug

I can see that I'm not the only one who likes the simple function of checking numbers without taking into account number format.

Checking numbers while taking into account their correct formatting is not really a trivial task. So such an approach in adverse circumstances will always involve a number of false positive results. Studio is a great tool that allows customization with individual needs in mind. Here you can download the Simple Numcheck plugin:

http://www.posteditacat.xyz/download/simple-numcheck-2019/

http://www.posteditacat.xyz/download/simple-numcheck-2017/

It checks numbers in Xbench29 style (only digits, without formatting). Plugins are not signed and you don’t find them in appstore. By default, plugin runs in every project and you don't need to initialize it each time. I've been using the plugin for few years. Tested on thousands of projects. No client made a complaint.

Simple Numcheck checks numbers (digits) and the order of numbers in the whole segment without any formatting. Reliability is 100%, virtually without false positives. In addition, it also checks alphanumeric expressions, but there are many false positives here. You can disable this option.

DArek