Hello Michael Bauer ,

I have only been able to reproduce this in the following scenario-

I open the single file translation - translate and then close the file.

However, if I open the file - translate and then manually save the file before closing, I always (when reopening the same file or another SFT) then I always see the Translation Results Window.

I suspect this happens when a client selects just the first part of a code like gd-GB i.e. it's set to gd and Trados for some reason throws a hissy fit because it's expecting gd-GB. It accepts the file but it has a "message" about this so it defaults to the Messages tab.

In any case, I'm not really asking anyone to reproduce this. I simply want to know if I can force the tab that Trados lands on.

Michael Bauer said:

In any case, I'm not really asking anyone to reproduce this. I simply want to know if I can force the tab that Trados lands on.

I don't believe you can.  You could try removing the message window, but without testing it I think it might come back if it's got something to say.

That doesn't help either because the message window seems to re-appear by default i.e. I can click it away in a particular file, but when I open another file, boom, there it is again.

Hi Michael Bauer

I think I know what you mean. Or it might be a similar problem.

I have the messages window floating on a different monitor and even though I close it whenever I am finished going through the messages from a verification, it generally pops open again when I leave and re-enter Editor view, so I have to close it again.

Closing it the second time seems to keep it closed until the next verification, and closing it has become second nature to me by now.

I never thought of bringing it up before, because I doubt it would be changed anytime soon. (At least I wouldn't hold my breath waiting.)

So if you always leave the messages window open, the same mechanism might be constantly drawing the focus to that window.

Just a guess.

It sounds related in the sense that it seems hard to get Studio to remember certain 'settings' between different work files. But I agree that a quick fix is unlikely... there's too much focus on new features in my view and not enough on fixing existing issues that affect end-user workflow and user-friendliness.

Yes, I agree. But from SDL's point of view those new features are probably important for marketing.

If other people have something like "LookAhead", then Studio has to have it too. Or fragment matching.

For marketing, of course, the important thing is to get something implemented.

From what I have seen, there appears to be less pressure to get it to actually work after it has been marketed.

Those new bugs probably just get added to the big bug list and wait their turn like everything else.

Michael Bauer said:

But I agree that a quick fix is unlikely... there's too much focus on new features in my view and not enough on fixing existing issues that affect end-user workflow and user-friendliness.

Michael Bauer

I'd say the current way it works is intentional becase if there is a problem with the file you should know about it.  If it's really bothering you you could change the language code in the source file, or depending on the source file you might be able to tweak the settings to deal, with this... turn off validation perhaps?

Alternatively submit an idea in http://ideas.sdl.com and see if you get enough support to encourage the product manager to consider the change above other tasks.

a) messing with the code in client files is not a happy thought

b) I did say "spread across many files" in the original problem description. If I get a word count of 80 spread across 60 files (yes, there are clients like that) then even if it was advisable to change the code, it would not be practical. And please don't say "tell the client". There are clients you can tell things for a decade and nothing changes.

c) if it's intentional, I'd like to know what the use case is for focussing on a warning about an issue that isn't actually preventing the translator from working with the file. I don't need software to nanny me about stuff that the software would prefer to be different but that actually don't have to be different.

d) Ideas, right, another opaque process where it's not clear how much "support" is needed for an idea to "encourage" a manager. Take the https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/tm-management-tool Idea, been up there since 2017, it's the 3rd most voted for (at 87) idea ...

Michael Bauer said:

a) messing with the code in client files is not a happy thought

Depends on your confidence I think and how much soething bothers you.  Changing a language code is trivial.  Probably a routine thing for many localization engineers.

Michael Bauer said:

b) I did say "spread across many files" in the original problem description. If I get a word count of 80 spread across 60 files (yes, there are clients like that) then even if it was advisable to change the code, it would not be practical. And please don't say "tell the client". There are clients you can tell things for a decade and nothing changes.

Fair enough.

Michael Bauer said:

c) if it's intentional, I'd like to know what the use case is for focussing on a warning about an issue that isn't actually preventing the translator from working with the file. I don't need software to nanny me about stuff that the software would prefer to be different but that actually don't have to be different.

Perhaps Daniel Brockmann can give you a good answer to this one.

Michael Bauer said:

d) Ideas, right, another opaque process where it's not clear how much "support" is needed for an idea to "encourage" a manager. Take the https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/tm-management-tool Idea, been up there since 2017, it's the 3rd most voted for (at 87) idea ...

Ideas could have a thousand votes and never get implemented.  They could also have one vote and get implemented.  Whether they get accepted or not depends on many things:

• how easy they are to implement
• whether they are in line with the strategic objectives we have for the software
• whether they make sense and contain clarity.  The one you mention for example looks like a hotch potch of ideas, some of which are already possible in the software and others which just ask for an API to be available (which it already is).  My guess is only part of what's in there would really be new.

In general I think an improved tool to simplify these operations would be useful and given the number of votes it may be something that gets done in the future.  Normally Daniel Brockmann would comment on them as he picks them up.  Certainly over the years there have been many ideas adopted and implemented into the software.