And if you work with French languages, you can set the punctuation more accurately than in the "general QA settings".

Unknown said:

I noticed that it is shorter than the QA checker section higher up in the settings.

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.

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

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?

Unknown said:

Perhaps worth sharing the actual response you received that you did not reply to yet:

Ah, I'm afraid I didn't notice the answer at all.
Since the time the Beta group RSS feed is mixed together with the generic Translation Productivity group feed it's extremely difficult to keep track.
It used to be WAY easier back in 2016 when the Beta group had separate RSS feed.

Unknown said:

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").

And I also strongly believe that adding "just parts" is actually more complicated from development and maintenance perspective than duplicating the complete tree (of course assuming some sensible architecture of the application).

Unknown said:

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.

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)?

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?

In general, project templates are out of question for the "working style" I'm talking about.

You guys seem to be too focused on "translator's working style", but the working conditions and style of a typical LSP loc engineers I know is completely different... it's basically "you never know what's going to happen in next hour"... i.e. which (new) project you get assigned on, what will be the conditions, etc...
One needs to share various individual settings among various people working on various projects (and often unfortunately having TOTALLY various levels of knowledge about CAT tools and localization in general!), so using project templates or basing project on previous project is a no-go...

Regarding the "how this should be done" - well, that's not easy to tell just from top of my head, it needs to be properly thought-through, taking in account many consequences.
In any case I would expect to get SINGLE settings file which would contain ALL settings... and export should probably allow me to select what I want to include (something like checkboxes for the generic part and each individual language) and similarly for import - import should probably allow importing only settings for languages actually existing in the project (optional adding new languages to project based on languages included in QA settings file sounds perhaps like unnecessary, unneeded and overcomplicated functionality).