This is an update to a question I posted more than a year ago - with no responses.

GroupShare seems to handle locked segments differently from Studio - this leads to "credibility" problems with our translators when we do not include locked segments in their work order and their analysis shows the higher, all-inclusive but wrong, number.

Steps to reproduce (Studio 2017 and 2019, GS 2017, CU10):
1. In Studio, create a simple project.
2. Prepare the target file(s) by pre-translating them and locking segments that you don't want to be touched by the translator.
3. Check your analysis (you should have the option "Report locked segments as a separate category"). You see numbers for locked segments.
4. Publish your project. Look at your analysis numbers now - no locked segments, and your no-match now has increased by the number of locked words. This is odd, because you actually want to make sure that these segments are NOT to be worked on and they certainly should not appear in the no-match category.
5. Re-run the analysis, this time on the GS-based project. Your numbers will now be as they were initially, with locked segments identified as such.
6. During the analysis, the files are checked out to you. After checking them back in, the locked segments count will again drop to zero and the no-match will increase again.

Has anyone else experienced the same issue, and if so, what is your solution.