Purpose of the QA section in the specific language pair section (Studio 2019)

Question

What is the purpose of the QA Chceker section in the specific language pair section of project settings in Studio 2019? 
 I noticed that it is shorter than the QA checker section higher up in the settings. 
 If export the checker profile from this section, is it saved together with the settings from the section higher up, or is it a separate *.sdlqa file?

Jerzy Czopik · Answer

Quite simple: in multilingual projects you can use different settings per language. For example I use the word list to find forbidden words in Polish (for example I would not like to see "kompresor" or "komponent" in my translation). This works fine for Polish, but if you create a project with more than Polish as target, Polish word list will not make any sense in other languages. Now you are able to define the settings language depending.

Paul · Answer

Hi Evzen Polenka 
 Unknown said: I questionned this too - why only some settings (only those considered by someone at SDL as "worth it") are present in the language-specific part... What's the point complicating it this way instead of making all settings available at language level... simple, logical, intiutive. 
 Perhaps worth sharing the actual response you received that you did not reply to yet: 
 Unknown said: We thought it would be best to put prioritiy on an initial set of language specific settings based on customer feedback over the years (e.g. around RegEx checks and word lists). We did not want to overload the settings tree initially. It would be great to get examples where the other settings categories would also be important to have at the language pair level, and we can then consider this for future refinements in this area. This would also apply to other verifiers such as the tag verifier - would be great to know examples where you would consider this important. Maybe see if you want to log an idea around this shortly after the public release (now is not yet appropriate, as the release is still in beta, so new ideas around this would be confusing for anyone who is not in the beta group)? 
 Perhaps Piotr Bienkowski can provide some useful feedback on what's required here too? 
 Thank you 
 Paul

Paul · Answer

Unknown said: Thanks for both replies, but I'm still interested if these language specific settings are saved to a separate *.sdlqa file or together with the general settings when I export them using the export button. 
 Hi Piotr Bienkowski 
 If you make changes at the "General" level they will be reflected in the various specific anguage pairs you have created. However, once you make a change to one of the specific language pairs they will become unique to that language pair and anything you want in both locations will have to be applied twice. 
 The export file is essentially the same for the general settings as it is for the specific language pairs, so importing either of them into the other will work. But they will only apply to the settings you imported them into. So if you import into General that's the only place they go. 
 I hope that makes sense?

Paul · Answer

Unknown said: So it means that if I have a project with 25 target languages and fine-tune the settings for each and every language, I would have to export each of the 25 different settings (plus the generic one) to separate files? And then import every single settings file separately (and be VERY careful into which langauge I'm importing it, otherwise I screw up badly the whole project)? 
 Hi Evzen Polenka 
 I think it would help to understand why you would want to do this. If it's because you want to be able to use them on the next project then project templates, or creating on the basis of the previous project springs to mind. 
 If there is a good usecase for this then coming up with a sensible way to manage multiple imports like this, as you might want some but not all for example, could be a challenge. The Apply Project Template application has not been updated to take account of these new settings at language level, so perhaps we have an opportunity to try something out and find the most appropriate solution. Do you have any ideas on how this should be done?

Paul · Answer

Hi Piotr Bienkowski 
 
Not necessarily the Pro version, but for anyone who works with multiple language pairs, even in the reverse direction of a single language pair it could be handy.

Paul · Answer

Unknown said: 
 
 Daniel Brockmann 
 It would be great to get examples where the other settings categories would also be important to have at the language pair level 
 
 And that's the point - the answer is "everywhere". Over the years, with dozens of VERY different projects targetting dozens of VERY different languages for dozens of VERY different clients with VERY different requirements, one simply needs everything. Once this, other time that, another time something else... And even if some option might be needed "only once in 10 years" it makes absolutely no difference - it doesn't matter if "I'm missing it every other day or only once in 10 years" because even "only once" is already too much. Especially if it's just because someone thought that "we should start slowly" and/or "we should add only stuff people ask for" (I have to again remind the notoriously known "silent majority"). 
 
 I think from your persepective this is true. Our own experience is very different and adding lots more options to every language pair just in case they are needed isn't a very smart thing to do. The vast majority of users don't want so many options (despite what you may think ), they would rather things were simplified. 
 During the Beta there was no feedback from anyone on this, and the product team didn't want to just blindly duplicate what seemed to be just global settings. Instead they took the view that we could enhance this over time once they get examples of where the current flexibility is not enough. 
 In some ways I'm with you on this Evzen because I like to see all the options available, but we have to remember that this tool has to meet the needs of many users and to just say we need all the options just in case isn't good enough... especially when you use the once in 10-yrs example. I do think we should address the import issue though. That seems a no-brainer to me and would not add a lot of complexity for users who simply don't need it.

Trados Studio > 1. Trados Studio

Purpose of the QA section in the specific language pair section (Studio 2019)