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

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:

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:

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.