I wonder if we could have this option.
I find it useful when doing manual QA to check correct the configuration of numbers from USA type in source (decimal format and thousands separator) to UE type in target. For the moment, part of this manual check is possible with Filter > Segments with no letters, but it misses segments with numbers with letters.
Hello LAX, here SFO, can you please give some examples?
Hi. Unfortunately, not an airport, it's just my name.
If you notice, in the Filter field we find:
Segments with font color
Segments with highlight color
Segments with letters
Segments with no letters
Segments with no letters gives you numbers, basically.
Segments with letters gives you letters and numbers and letters and no number.
What is missing is the last option, ie. Segments with numbers (both with letters or without, we don't care).
This is the one relevant (at least to my interests). It allows me to quickly check if my thousands separator is correct (e.g. 10,000 > 10 000) and decimal as well (e.g. 0.01 > 0,001).
What I have been doing at the moment is ridiculous, I do several Target searches for:
Hopefully it's clear now?
It should be possible to use QA Consistency > Glossary for this.
So I created a sample project like this:
And a QA glossary containing only two expressions:
To notice that this QA fails.
Igor, am I missing something here?
I've also set this preference:
I created a non-translatables glossary:
And ran QA Non-translatables. Not all errors are caught:
> Filter > Segments with numbers
Update 11 may have it.
When adding the numbers literally to the QA glossary, the first type is caught, the second isn't:
Why is that, Igor?
Okay, for the second type, I came up with a multiple filtering action (aamof, this one can be used for the first type too, with a adjusted regex):
First filter on all source segments that contain numbers with 3 decimals. Make sure that Multiple is checked:
Keep the dialogue box open, check the target scope box, enter the search string for the target:
My assumption with this is that any deviant number with three decimals, isn't localised (has been forgotten). Hence the search for
> the second isn't:
Possibly, because of the punctuation characters defined in the "Don not match" list.