Adrian Komiński 

On this we can agree!

Unknown said:

Needless to say Word preview worked beautifully in Trados 2011 with Office 2007... (couldn't help it, Paul)

But the problem here is not Studio, it's Word.  Once Microsoft moved to their click to run installer they stopped providing the required components that are needed to be able to deliver an embedded preview.  So we have had to try and find other ways to make this work.

Unknown said:

EDIT: tried doing the embedded preview, and Trados actually gave me an error, so... yeah, should've posted this in the old thread. But then, I don't even need the embedded preview at all.

Today I run the click to run version and can actually achieve all three variants of the preview without the problems you descibe so would be inclined to look at external influences first.  These would be things like you security software and available permissions to be able to run both applications smoothly.  Try disabling your security software temporaily, and any backup software you might be running and see if this helps.   If it does add things back in until you find the cause of your issue.

My sole security software is the wretched Windows 10 itself and its built-in security features. I'd gladly disable Windows 10 forever - and switch to Mac - had the different translation software I use been compatible with the latter.

So, which Office SHOULD we buy, then?

Besides, the thing sometimes works fine, and sometimes doesn't, due to which I'm not sure if I can buy your explanation! At this very moment I'm in the process of translating a file that keeps crashing on me every 5th segment or so, and then re-opening. Sometimes it won't even re-open, displaying some lame error (file couldn't be opened, or something) - and then opening again obediently when I re-launch the preview manually.

This doesn't ALWAYS happen with every file, but it does so quite often, with different documents. I don't work with any "special" formats or anything. Just regular .docs / .docxs.

No point, really. Same thing just happened with another file, derived from another source… it happens with so many different files - and there's so many different symptoms - that I don't find it justified to look around for a file that I could actually share with you (without breaching an NDA).

So, let's get this clear: WHICH Word version exactly is officially "supported" by Trados?

Unknown said:

So, let's get this clear: WHICH Word version exactly is officially "supported" by Trados?

Adrian Komiński , did you read the release notes?

Adrian Komiński 

Unknown said:

Release notes? Who reads release notes?

Well... you should!

Unknown said:

But now that I read it: how can they recommend Word 2007 if it's incompatible with Studio 2019 (or at least Word 2007 was incompatible with Studio 2017 when I tried it...) in terms of the real-time preview function?

You can have a realtime preview with Word 2007 in 2017, and in 2019.  We did go through a period of having issues dealing with certain versions of Word because of their transition to the Click to Run installer, but it didn't affect all versions and there were solutions in the knowledgebase if you looked.  I seem to recall that it used to be this sutuation:

Embedded – does not support click to run
MS Word – supports all including click to run
HTML – supports all including click to run

IMPORTANT: Don't attempt the Embedded Option at all if you need to run the HTML preview as this may prevent the correct functioning of the HTML preview afterwards.

But today I can do all of these even with a click to run installation.  So you having problems points to something else and it would make sense to get help from the support team.

Hi Paul,

I have tried Studio Preview before, but never started using it because of the lag in displaying changes in the Preview window.

Based on your comments, I decided to try it again.

I turned off all virus checking software before doing the test. I am running Studio 2017 SR1 in Windows 10 (all updates applied). I have Microsoft Office 2019 installed on my computer.

Here are my notes:

1. I opened Studio, opened a project, opened a file, and clicked on Preview.

- The Preview window opened and an Embedded preview was automatically generated.

- You mentioned in your previous post that I should not use the Embedded option if I need to run the HTML preview, so I played around to find out how to avoid automatically generating a preview.

- First, I tried closing the file, closing Studio, restarting Studio, reopening the file and clicking Preview. The same thing happened.

- Then I tried closing the Preview window and closing the file, but NOT closing Studio. When I reopened the file and clicked on Preview the Preview window surprisingly did not appear. It did not appear until I closed the file and reopened it. Then the Preview window appeared automatically (I did not have to click Preview) and did not automatically generate a preview.

- I then tried leaving the Preview window open when closing the file. When I reopened the file, the Preview window opened automatically (I did not have to click Preview) and did not automatically generate a preview.

- In summary, I found that in order to open the Preview window without it automatically generating a preview, I had to leave the Preview window open when I closed a file. The Preview window would then open automatically the next time I opened the file and would not automatically generate a preview.

2. Once I had figured out how to successfully open the Preview window without it automatically generating an Embedded preview, I generated an HTML preview and noted the following:

- The segment text is not highlighted in the HTML preview window and the HTML preview does not move to the text for the current segment

- Ctl-F cannot be used to find text

- Because the text is not highlighted, does not move to the current segment and there appears to be no find function, the HTML preview seems pretty useless to me

- I used a stopwatch to time how long it took for a change in Studio to be reflected in the HTML preview

- It took around 5 seconds for a change to be reflected in the HTML preview

- In my opinion, this is too long to be of any practical use (and it seems like an eternity when in the middle of a translation)

3. I then tried the Microsoft Word preview. Before generating the preview, I closed the file and reopened it. I left the Preview window open when I closed the file, so that it would open automatically when I reopened the file.

- The segment text is highlighted in the Word preview and the cursor moves to the location of the segment text

- This looked promising

- But it took around 8 seconds for a change to be reflected in the Word preview

- In my opinion, this is too long to be of any practical use

4. I then tried the Embedded preview. Before generating the preview, I closed the file and reopened it. I left the Preview window open when I closed the file, so that it would open automatically when I reopened the file.

- The segment text is highlighted in the Embedded preview and the cursor moves to the location of the segment text

- But it took around 8 seconds for a change to be reflected in the Embedded preview

- In my opinion, this is too long to be of any practical use

The long lag before changes appear in the Preview window is the reason I have never used the Studio Preview function.

This does not appear to have changed.

I am curious to hear whether you experience shorter lags. Are you testing using small test files or large, potentially messy files typical of a production environment?

Best regards,
Bruce Campbell
ASAP Language Services

Hi  

Can you share the same file you used and I'll be happy to conduct exactly the same tests?  It would be interesting now you have attempted to benchmark the performance.

Unknown said:

- You mentioned in your previous post that I should not use the Embedded option if I need to run the HTML preview, so I played around to find out how to avoid automatically generating a preview.

I mentioned this is what used to be the issue (it was all in italic because I was referring to the advice I used to provide some time ago).  This is no longer the case and I don't have that same set of problems.

Ok, interesting, thank you. I'm not going to use Office 2007 anyway, though. Due to my Surface environment, it's most reasonable to stick to the latest Office releases (touch/ink compatibility issues, etc.). And having two side-by-side installs is a pain in the you-know-what in Windows.


My experience is similar to Bruce's. Also, I've seen the external (!) Word preview crash very often with different files recently. It looks like it does that when it encounters an apparently problematic segment - maybe containing a section break, some unusual tag, or something else - I don't know. Plus the irritating lag and unreliability of highlight (sometimes works, sometimes doesn't) just ruins the overall experience.

And a working preview IS an important function when you like knowing where you are in the document exactly without constantly searching for the segment's location.


Paul, maybe you're just working with some very basic .txt or .docx files of "lorem ipsum" sort when claiming everything is fine on your end? The translator's reality is messy PDF converts and ABBYY outputs - with this type of stuff the preview does the worst job. With other type of stuff (flowing text, maybe with a few tables) you hardly need a preview at all...

It'd be interesting to hear from other people too.

Hi Adrian,

I am not sure what the situation is at Paul's end, except that his Studio installation is probably perfect and he has the resources behind him to chase down the answer if our experience differs from his -- and he feels this is a high enough priority for his time.

In the meantime, which means longer than I can remember, I have been using a Dragon command to find out where I am in long documents. It should be (relatively) easy to create an equivalent AutoHotkey macro if anyone is interested.

The Dragon command is built to work with PDF files, but this is not a limitation, since I use CutePDF Writer to create a PDF version of every file I receive to translate. Working only with PDFs standardizes everything, which makes my work quicker and easier.

The Dragon command first checks to see whether any text is currently selected. To do so, it clears the clipboard, does a copy (Ctr-C) and checks whether any text is now in the clipboard (length of clipboard = 0?). If there is something in the clipboard, the command uses that text. If no text was selected (i.e. clipboard is empty), it assumes that the cursor is in the target segment. It then goes to the source segment (F6), selects the first line of text in the source segment (Shift-End) and copies it to the clipboard (Ctr-C). It then deselects the first line of the source segment (Left) and switches back to the target segment (F6). Then the command makes Adobe Reader the active window. (The correct PDF file has to be open in Reader.) Someone who uses AutoHotkey will have to figure out how to switch to the proper window. I know it is possible, as I used AutoHotkey before I changed over to Dragon. Then the command executes the find command in Reader (Ctr-F followed by Ctr-V to paste the clipboard into the find field, Enter to execute the command, and Escape to exit from the find command). The find command works most of the time, although occasionally there is a difference between the Studio segment and Reader that forces me to move up one segment and try again. (The Dragon command is shown after my signature below.)

So whenever I get a document to translate -- of any kind -- I immediately use CutePDF Writer to create a PDF version. I display this PDF file on a second monitor instead of using Studio preview and use my Dragon command when I get lost and need to find out where I am in the file or need to look at the context of the segment I am translating. I also have a Dragon command to switch back to Studio (the command basically just executes HeardWord ("switch",  "to", "SDL Trados Studio") plus a few other things to ensure I am in the Studio Editor and in the current target segment).

This is quick and easy, and I use the PDF anyway to look at other parts of the file while I am translating, which means that waiting 5 to 10 seconds for the Studio preview to update is an excruciating experience in comparison.

My Dragon command (advanced scripting for DPI15) is shown below my signature. I hope this helps someone :-)

Best regards,
Bruce Campbell
ASAP Language Services

"find in reader" Dragon command for DPI15

Sub Main

Clipboard ""                        ' empty the clipboard
SendKeys "^c",True            ' if something is selected, copy it to the clipboard
Wait 0.1

If Len(Trim$(Clipboard$())) = 0 Then        ' check whether any text was selected
   SendKeys "{F6}+{End}^c",True            ' if not then get first line of source segment
   Wait 0.1
   SendKeys "{Left}{F6}"
End If
Wait 0.15

HeardWord ("switch", "to", "Acrobat Reader")
Wait 0.15

SendKeys "^f",True
SendKeys "^v",True
SendKeys "{Enter}",True
Wait 0.1
SendKeys "{Esc}"

End Sub

Neat solution, Bruce, if a bit of a hassle to implement indeed. I'd probably rather just have my $700 software do what it should do. Will remember this if everything else fails, though. But then - if you have a 15 documents project, creating a PDF from all of them is a time devourer in itself.

Hi Adrian,

With respect to the time needed to use CutePDF, it installs as a printer, so it is quick and easy to use. I have it set as my default printer, so I just select the files, right click and choose print. I use a standard folder for preparing projects and it is also the folder CutePDF uses to deposits the PDF files.

With respect to the Studio Preview, I agree that I would prefer to have it work properly :-)

But over the years I have tended to use fewer and fewer of Studio's bells and whistles. The fewer I use, the fewer mysterious problems I have with Studio.

For example, take what is happening with Studio 2019. I bought the upgrade, but am waiting for the SR1 release before I install it. You can see from the forums that Studio 2019 is buggy -- but most people probably don't stray too far from the "out of the box" settings, so the bugs that are found and corrected will most likely be associated with those settings. In my view, this makes straying too far from the "out of the box" settings like walking into a mine field that hasn't been cleared yet, and might never be cleared.

I am therefore happy to just use the basic features of Studio in order to avoid the possibility of being stuck completely without a translation tool for days or weeks while someone at SDL hunts for a solution or workaround. (It is worrying to see people report that they cannot use Studio even after completely uninstalling and reinstalling.)

So, yes, it was a bit of a hassle to set up the Dragon command, but it was a good exercise in learning how to write Dragon commands, and learning some of the limitations and workarounds for Dragon commands.

I also don't expect SDL to address the Studio Preview problem or most of the other problems I have had with Studio any time soon, so I look for workarounds whenever I can.

Best regards,
Bruce Campbell
ASAP Language Services

I should also mention that the reason I don't expect SDL to address some Studio problems is simply because no software developer can afford to address all problems. Like everyone else, SDL has finite resources.

The question is simply where do they draw the line and decide which bugs to fix.

For example, there was a discussion a while ago about the fact that the Advanced Display Filter can search for tags. That is great, if you are looking for tags, but if you are looking for "the cow jumped over the moon" and the text in your segment contains tags, e.g. "the cow jumped over the <bold tag>moon<end bold tag>" then you are not going to find it unless you know exactly where the tags are and what they contain and include them in the search text.

To me, this was a serious problem, and everyone should at least know about it. I suggested that a button be added to turn tag searching on or off. It would also alert people to the fact that tags could be included in the search, something that most people are probably still unaware of.

The fact that no change has yet been made is just another indication to me that SDL has quite limited resources for Studio. The Advanced Display Filter problem is, after all, one that potentially affects everyone, so you would expect it to be given some sort of priority. (Although SDL might not expect many people to use the Advanced Display Filter, which would lower its priority in their eyes.)

And that is why I don't expect SDL to address the Studio Preview problem or many of the other problems I encounter with Studio any time soon.

Like every other piece of software, I just accept Studio for what it is, with all of its limitations, try not to break it and hope that it will slowly improve. 

Best regards,
Bruce Campbell
ASAP Languages