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

Hi Adrian,

Please don't misunderstand me. I think Studio is a good tool. And worth the money I spend on it. I am just trying to be realistic.

Studio's user base is far smaller than, say, Microsoft Office. So we have to expect a higher price. And Studio has more competition than programs like Microsoft Office, so we have to expect a lot of marketing hype.

For example, what about LookAhead? Every time I see it mentioned in the forums, Paul is still recommending that people turn it off. It is a feature that looks good in the marketing material and helps to sell the product, but SDL's initial try at the coding didn't quite work.

So, what should SDL do? Immediately fix it?

I am just speculating, but I imagine it gets treated like everything else. It probably goes through "triage" and gets assigned a priority, but since it is not a core part of the product, it will get handled after important work on Studio's core functions -- assuming that SDL's limited resources ever allow it to move beyond the core work, and SDL doesn't spend too much time developing new bells and whistles to market.

In the meantime, while we wait for a functional version of LookAhead, it is still being marketed.

New users come in with high expectations based on all of the features that are available. I know my expectations were high at first.

But even though my expectations are lower now and I stay as close as I can to the "out of the box" settings so I won't be blindsided by mysterious bugs that cripple Studio, I still think it is a valuable tool and worth what I pay for it.

I am happy that the basic functions of Studio are slowly improving instead of slowly falling apart at the seams.

And Paul is doing an amazing job of providing support for Studio and acting as a "punching bag" for upset users letting off steam (not a pleasant task at times, I'm sure). He is a priceless part of the product package.

That doesn't mean I am happy about everything. I complain when I find problems and hope they are added to a list somewhere. But after I have complained, it is out of my hands.

Paul and everyone else on the Studio team want to keep their jobs, so they will do what they think is right to survive in a competitive market, not what I want them to do.

Best regards,
Bruce Campbell
ASAP Language Services

Hi 

Unknown said:

Perhaps you could test a similar file and send it to me. Then we could compare lag times.

Good idea... I used this one - http://prawnpdf.org/manual.pdf - converted to a DOCX in Studio and then translated without any clean up first.  The file is around 107 pages, 15k words and a PDF conversion so probably fairly similar.  I put my experience here:

Ok Paul, good to know. We all know complaining does tend to make things go faster in business, though. At least here in Middle Europe. I'll watch your vid in past time, thanks for that.