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.

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.

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.

Hi Anthony Rudd, Paul, Jerzy Czopik

It very much depends on the level of knowledge and the available time to learn of the agency project managers. I'm fortunate in that the agency I do most of my work for are open to discussion. I even recently sent their MD a copy of my profile settings file so they could test out my settings (customised for maximum speed and stability) without having to go through all the settings themselves. I know I'm very fortunate to have such a good relationship with them!

We should not change PM's settings unless it is according to the agency's required end result. It would of course be wrong to blindly change project settings because we 'like them that way'. However, an expert like Jerzy is never going to do that because he knows precisely what he's doing.

We absolutely shouldn't merge segments over paragraph marks unless the agency is OK with that (with some file formats this can cause target file generation failure). Neither should we change the Source unless we're absolutely sure the PM/client would be OK with that (unless we are only delivering the target file). Structural settings changes such as these shouldn't be made unless the client is OK with that.

However, using the individual verification settings in the client's project settings the most effectively we can to achieve the best translation & localisation results most efficiently is surely going to improve matters for everyone handling the project. A question to ask here is, if we have changed anything in the Project Settings, then deliver a package, will the Client's project settings be overruled by the import? If not then it really doesn't matter what one has changed in the verification settings.

Have a lovely day and stay safe!

Ali