"Number is missing in target segment or is not properly localized"

Question

Hi, I am a free lance translator for Czech language, and my very important question about Studio 2019 is: How can I manage the message: "Number is missing in target segment or is not properly localized". In fact the Studio 2019 (as all previous versions of Trados/Studio) doesn't know the rules to respect using the numbers in the documents in Czech. So, the above mentioned message is very null and void/disturbing/ineffective. 
 As translator, am I able teach the Studio to manage the numbers as needed? 
 If not, should it be possibile for the SDL make known to everybody this very fatal failure? 
 Many thanks in advance for all useful reactions 
 Miroslava

Lydia Simplicio · Answer

Hello Miroslava Nečasová , 
 Studio should recognise the correct number formatting based on the languages of your project. 
 Are the numbers underlined (blue)? in the source prior to translation?- e.g. 
 
 For automatic number recognition to work, you must have a valid TM attached to your project. 
 Then check your settings in Verification/QA checker- 
 
 I also note that you seem to imply you have had issues with number recognition in previous versions as well, so I would check your own PC settings as well as these are picked up from the 'Region and Language' settings in Windows as follows-

Does this help?

Daniel Hug · Answer

Hi Tomi Dobaj and Miroslava Nečasová 
 I think it's quite understandable that started into this by pointing out the basics. The QA number check and in a way also the Number Verifier App are basic and I use them when I translate documents with simple number formats. The Number Verifier actually is quite powerful, but it also has its limits. (By the way, Number verifier works well for me with German and English including product codes like D1234.) 
 You are correct, Tomi, in pointing out that Regex is a way to deal with more complex formats, but I am a bit surprised by what almost sounds like an accusational tone in your post. There is a whole forum about using regex and as far as I can see most questions there are answered in a very timely manner: https://community.sdl.com/product-groups/translationproductivity/f/171 
 I think that is quite a service, since you are actually requesting a service which is akin to custom software development, and you would normally have to pay for that... 
 So if you have a document with a specific number format, why not post your regex question there? Then store it on your computer as you might be able to use it again in future. Over time you will get a collection of regular expressions that might cover all your normal requirements in all languages you deal with. 
 There are very complex formats, like Bible quotations in different countries, and even one and the same country might have more then one standard - your customer might request a specific one. How could an off the shelf solution cover all that? 
 So I hope you feel very free to post your regex questions in the above mentioned forum! (They just need to be specific with good examples.) 
 All the best 
 Daniel

Paul · Answer

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: 
 
 Create your project 
 Check to see whether the source patterns are recognised as expected 
 If not then use something like the SDLXLIFF toolkit to "correct" these patterns so that the source patterns are recognised by Studio 
 Check to see whether the target output when autotranslated is what you expected. 
 If it is then you can now translate the project and the QA checks built in should give you better results 
 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.

Paul · Answer

Hi 
 Unknown said: However, this still does not answer the question of why German date recognition works when the default long date format is the same as in Austrian. 
 I spent a little time to look at this today, in particular this part (although I only have W8.1 so there may be differences): 
 Unknown said: If I look at the Windows 10 default long date formats for German and Austrian they are both "dddd, d. MMMM yyyy". Studio nevertheless recognises German dates in the format "d. MMMM yyyy" -- but it does not recognise Austrian dates in this format. 
 Let&rsquo;s start with what I see for Windows. I see this with German: 
 
 So this would be, for example: 
 Sonntag, 17. Februar 2019 17. Februar 2019 17. Feb. 2019 Freitag, 1. Februar 2019 1. Februar 2019 1. Feb. 2019 
 I see this for Austrian German: 
 
 This could be this: 
 Sonntag, 17. Februar 2019 17.Februar 2019 Freitag, 01. Februar 2019 1.Februar 2019 
 If I put these into Studio with the appropriate TMs then I see this. I picked a long date for localization in target, the important part is recognition in source: 
 de(DE)

It seems to pick up all the formats apart from d. MMM. yyyy and I have no idea why this is not seen, but I will find out. This is a good example of the problems some users have though and whilst it&rsquo;s a pain the solution can be achieved by converting the source with a search replace regex in the source so Studio recognises the dates and handles them correctly. 
 The Austrian however works exactly as expected for me: 
 de(AT)

What language pairs are you using for your TMs? perhaps this is adding a variable I'm using differently to you?

Paul · Answer

Hi You are not showing the relevant date in your regional settings, but perhaps note that in mine anyway there is no space between the date and the month. It does seem pretty odd, but I reproduced faithfully what windows was looking for and it's recognised. This is a great example of the flaw in our rather prescriptive recognition system.

Paul · Answer

Unknown said: Hi Bruce Campbell what you have shown above, i.e. automatic substitution, is determined not by the Windows settings, but by the Studio Auto-substition settings: 
 Hi DArek, 
 We're only talking about recognition here, not auto-substitution, so thet target language settings in Studio are irrelevant. Or am I misinterpreting you?

Trados Studio > 1. Trados Studio

"Number is missing in target segment or is not properly localized"