Anthony Rudd

Any other hints such as it's a project package?  In GroupShare for example there are many settings to control access and if the GroupShare administrator assigns a role to you with the appropriate permissions unchecked then you won't be able to edit the project settings:

I created a project for a user with these settings above and only get access to this for example:

Jerzy Czopik said:

If customer package, you need to modify the *.sdlproj file. Simply check one of your projects and adapt the settings in the sdlproj accordingly. It is a simple xml.

I'd be very careful doing this.  If I was the project manager and I prevented you from making these changes then I wouldn't use you again if I found out you'd edited the files to workaround the controls I'd put in place.  Just because you can doesn't mean you should!  If you need to be able to make changes to the source, or anything else in the project settings, then I suggest you discuss this with your project manager and don't work around controls that may have been put in place on purpose.

Paul said:

I'd be very careful doing this.  If I was the project manager and I prevented you from making these changes then I wouldn't use you again if I found out you'd edited the files to workaround the controls I'd put in place.  Just because you can doesn't mean you should!  If you need to be able to make changes to the source, or anything else in the project settings, then I suggest you discuss this with your project manager and don't work around controls that may have been put in place on purpose.

This would apply, if the PM know what he/she is doing. You do not work as translator, so I am sure you do not see how packages are prepared. In 90% of all cases the restrictions there result from default setting, because no one takes care to learn how to use this. Same applies to QA—criteria are blindly marked. Typically all is set to be checked, regardless if it makes sense or not. And discussing this with a PM of a big company is like talking to the wind. They are not allowed to change anything, as the process there is "holy". However, this process has been developed without having the translator in mind.

So, in principle you are right. But when I go my way, I will deliver much better quality. And I think Anthony knows exactly what he's doing, so he will do no harm by changing the settings.

Would translation agencies speak to us translators and take our needs into account, there would be no need to change any settings. Obviously this also applies to us translator—would we be able to talk to the customers on that level, the life of us all would have been much easier. I'll try to talk about all this within the next ELIA Together event in 2021.

Jerzy Czopik said:

Would translation agencies speak to us translators and take our needs into account, there would be no need to change any settings.

I completely agree that talking to each other is important so that you all understand each others needs.  But suggesting in a public forum that users edit the sdlproj to remove the controls put in place by a project manager... any project a manager and not just the ones who don't know what they're doing is very bad advice.  If I was a project manager I'd be very unhappy about this.  Translators, even the really good ones, don't always appreciate the needs of project managers!  At the end of the day Jerzy the translator is completing work that they have been asked to deliver in accordance with the requirements of the person paying them to do the work.

Paul, this would be true in an ideal world... I am getting paid to deliver quickly the best possible quality. If I would not be able to change the QA settings, I would need some extra rounds to find obvious errors in my target language, which most of the PMs and many customers wouldn't even note... I use LanguageTool for grammar checking and do not know any single agency using this. But the results are great. I use regex for checking of measurement units, but most customers I know do not pay attention to that. Nonetheless, a number and an unit must be properly written, regardless the "requirements", which usually mean less pay for more faster work. Of course there are exceptions from this and the requirements are clearly specified. But it's easy to stick to those and even then an add-on on checking can only help.

From my point of view the only restriction which should not be overrun for no reason is the ability to merge segments over paragraph marks. All other settings will—when properly used—do no harm to the requirements. To the contrary—adding an extra proof step or using better settings in QA will help to meet these requirements faster and better.

Paul, this would be true in an ideal world... I am getting paid to deliver quickly the best possible quality. If I would not be able to change the QA settings, I would need some extra rounds to find obvious errors in my target language, which most of the PMs and many customers wouldn't even note... I use LanguageTool for grammar checking and do not know any single agency using this. But the results are great. I use regex for checking of measurement units, but most customers I know do not pay attention to that. Nonetheless, a number and an unit must be properly written, regardless the "requirements", which usually mean less pay for more faster work. Of course there are exceptions from this and the requirements are clearly specified. But it's easy to stick to those and even then an add-on on checking can only help.

From my point of view the only restriction which should not be overrun for no reason is the ability to merge segments over paragraph marks. All other settings will—when properly used—do no harm to the requirements. To the contrary—adding an extra proof step or using better settings in QA will help to meet these requirements faster and better.

That's all great Jerzy, but is completely missing the point.  If you need to be able to add these things because the project manager has locked the project down then you should discuss this with the project manager to support a workflow that will clearly be better for you and the project manager.  You should not make be promoting ways to circumvent the project controls in the way you suggested.

I can't even see a debate about this.  How do you know who will read your advice and try to make such changes without being aware of the possible implications?  The original question wasn't about being able to use all the good things you have mentioned here.  It was about being able to merge across paragraph breaks.  There are times, and you might not even know when, it's completely unacceptable to do this.  The underlying mechanism for merging across paragraph breaks is quite hidden by default, but can have negative consequences on the delivered target file:

https://multifarious.filkin.com/2016/11/21/bridging-the-divide-merging-segments/

I know you've said in the past you've never experienced a problem with this but you cannot say that means it's ok for everyone to make these changes even though the project was set up to specifically deny it.

This is not about ideal worlds etc... it's about open communication and not going behind the back of your customer when they have (wittingly or otherwise) set up controls in a project for work they are paying you for.