I was in the interesting position a couple of weeks ago to address InterpretAmerica, the premier interpreting event that aims not only to bring together the different strands of the world of interpretation but also to be a catalyst for new developments in the field, including technology. My position was interesting because I'm not an interpreter, and the truth is that I really know very little about the field. But my interpreting expertise -- or lack thereof -- wasn't the reason why conference organizers Barry Slaughter Olson and Katharine Allen invited me. Instead, they wanted an outside perspective on a separate but related world -- translation -- that would detail some of the successes and failures of translators in their dealings with new developments, especially technology.

Collectively speaking, of course, we have been very slow to accept technology as a positive and productive part of our lives, which in turn had some negative impact on the development of technology. You know what I'm talking about. For the longest time, things like termbase systems were really not built for our needs -- because we neither showed interest as consumers nor were willing to engage in the development process. Other technologies virtually disappeared because we didn't show the interest that was necessary to justify ongoing development (think of Xerox's outstanding work with bilingual terminology extraction or TM-based authoring -- see below).

So I retold some of those and other stories as examples of what happens if you do (or don't) engage with technology.

I also tried to put together a time line from a translator's viewpoint of translation technology development. (Naturally this would look different from the viewpoint of a translation company or academia.)

I would be interested in hearing some comments about this. Did I forget something important? Did I time developments incorrectly? Or am I too optimistic about the MT productivity breakthroughs?

Another thing that happened at the conference -- "perhaps the most touching moment" -- was the passing of the torch of sorts with Jeromobot being handed over to interpreters. But more on that in a later edition of the Tool Box Journal.

SDL Trados Studio 2015 has arrived

SDL Trados Studio 2015 is the culmination of 30 years of experience in translation technology. In this time we have continually listened and learned from our customers, to ensure we continue to provide the best possible translation experience.

Discover the new exciting ways to increase productivity, ensure the highest levels of translation quality and personalize your Studio 2015.

Learn more » 

Claudia Alvis, Translator at Hispanic Languages

Can you believe it? I was called out after the last Tool Box Journal for creating headings that were too cryptic -- and now this?

Of course, I'm talking about how many monitors translators use. And why the mirroring? Because (Unicode and) I can!

Now, not everyone is quite as well-equipped as Rina Ne'eman (note not just the 65 or so monitors but the very hip stand-up desk as well) --  

but I was really interested in how many translators are using more than one monitor. Why? Because if the number turned out to be overwhelmingly in favor of more than one monitor, then this would have a real implication for tool developers that we potentially could all benefit from. Translation environment tools have traditionally suffered from an overload of panes and windows on one screen -- and this is only getting worse with new kinds of resources having to find their place on the screen. If developers can trust that the vast majority of users use several screens, they might be able to apply different screen estate strategies (while still making it possible to work on one screen, of course).

So without further ado, these are the results of my (very unscientific) survey among Twitter followers. Of the 70 translators who responded, 20% never use more than one monitor, 50% always use more than one monitor, and 30% mostly use more than one monitor.

The sample is too small to be completely reliable, and so is the method of choosing survey participants (for instance, you would have to assume that there's a basic interest in technology if someone follows me on Twitter), but these are still interesting numbers that should communicate to developers that developing the user interface of translation environments for two screens is a real possibility. 

Welcome, memoQ 2015!

We know you're wondering what's new in memoQ 2015... MatchPatch, the new project management dashboard, and the web-based project and user management are just a few of the many features that memoQ 2015 brought.

Check out highlights in this video, download the latest free trial version, and be more productive from day #1!

Contact us if you have questions, and enjoy working with your new-old friend, memoQ 2015!

Don McLean's "Vincent" is still one of those songs that makes me cry just a little every time I hear it. I don't think he really had Star AG's many products in mind when he serenaded the "starry, starry night" in the song's refrain -- but we can make it work for the purposes of this article.

An entire team at Star took a couple of hours last week to guide me through several of those products, and some truly are interesting.

We've discussed translation memory-based authoring a good number of times here and elsewhere. From our perspective as translators, it's a no-brainer: If technical authors used translation memories and termbases as they write in the same way translators do, not only would the documentation they produce be more consistent, there would be a much greater number of matches when it comes to the translation phase. After all, many of the authoring choices would be based on matches in existing translation memories, which in turn would turn into matches again when it comes to the new translation pass.

In my very first column in the ATA Chronicle eight years ago, I described a prime opportunity for translators with experience in working with (the challenges of) translation memory and terminology maintenance to act as consultants for technical writers. In this case, we're looking at a scenario where a technology that we as the end users didn't use (almost) disappeared because of us. It was really up to us to make this technology a go -- technical writers are just about as thrilled about it as we were when translation memory was first offered (i.e., "not"), and since we didn't take on these (ahem, very well-paid consulting roles), nothing happened.

SDL scratched its AuthorAssistant last year, and Sajan's Authoring Coach suffered the same fate. As far as I know, only two companies offer TM-based authoring products today: Across with its crossAuthor and -- now I finally come to where I was going the whole time -- Star with its MindReader.

MindReader can be used in Word (which is part of the 1800-euro single-seat package), FrameMaker, and Arbortext (the necessary add-ons for these systems cost extra), as well as Star's own content management system GRIPS. The way it works is simple enough: You work within Word or FrameMaker as you always have, but you also see a second, independent MindReader pane that gives you the matches from the memory that match your current writing. As with translation memory, you can set the fuzziness level, you can take the segment from MindReader over with a keyboard shortcut, or -- and this is where Star's particular way of dealing with translation memory or, as they call it, "reference material," comes into play -- you can open the originating file and copy a lot more than just that one segment.

The source material for the "authoring memory" can be Transit reference materials, Transit projects, XLIFF files (including SDLXLIFF), or even existing source documents (in which case you don't get the benefit from the additional TM leverage).

Terminology work also operates as it does in a translation project. The terms that should be used are automatically confirmed (or you are asked to avoid those that really SHOULD NOT be used), and you can add terms on the fly. The benefit of the latter is that if the project goes into many languages, it's actually the original author who controls what kind of terminology should be sitting in the termbase. While the translators still have to translate the terms, they don't have to worry about selecting which ones to add since that has already been done for them.

Another Star product is called MindReader for Outlook, and it does exactly what you would guess. It creates a database from all your past sent emails and suggests text based on what you are presently entering (the suggested text is displayed in the lower half of the email you are composing). Very clever if you write a lot of repetitive emails (if you're as creative as I am you won't get many matches . . . just kidding -- I've actually bought the program and am having lots of fun with it). True to Star's "memory principle," you can also open the complete previous email and copy more than just a sentence at a time. And the fuzziness level of the automatic searches is also adjustable in a newly added Outlook toolbar.

The price is not much of a detriment to this tool (49 euro). Potentially more problematic is its use of resources (it requires the SQL Server in the background, which is a little resource hungry), but it hasn't been too much of a problem for me to uninstall it again.

Here is what I really like about this tool, though: It took a little bit of creativity for translation tool developers to come up with TM-based authoring for technical authors. But they're part of the same supply chain as translators, so it didn't require a stroke of genius to come up with it. What I think is so cool about a tool like MindReader for Outlook is that its audience really has nothing at all to do with translators. It's everyone. I love it when I see that the technologies I'm using can also directly benefit my mom, my high school friends, and my neighbors. That's thinking outside the box.

It also took some thinking outside the box for the MT implementation that Star is offering. Star Moses is, as the name implies, like most statistical-based machine translation engines based on the open-source Moses engines. Unlike many other providers, Star doesn't leave the training of Star Moses up to the user but offers it as a paid (and ongoing) service. And while it's possible to use the Star Moses engine outside of Star Transit (some large corporate clients use it as an internal and required "Google Translate substitute" with a similar web interface), the most interesting approach comes into effect as one of the resources within Star Transit.

I have previously talked about MT-based fuzzy match repair. Déjà Vu is the primary tool that uses this method. The idea of the concept is that if I can query a machine translation engine just for the "incorrect" part of a fuzzy TM match and automatically replace that component with what the MT offers, I might be miles ahead (well, probably just centimeters, but every little bit counts, right?). This is a great way of dealing with MT as a productivity enhancement, and I think it will be one of the ways we'll deal with MT in the future.

Another way might be what Star has developed and coined as "TM validated MT match." The thinking is this: Traditionally we have looked at MT as something that should come into play if there is no perfect or fuzzy match within the TM. This makes sense because the TM is, of course, the gold standard, created as it is by us (or our team). What if, Star thought, we also displayed MT suggestions alongside fuzzy matches? They might be of as good or even better quality, especially if it's just a terminological difference that makes the TM match fuzzy. And what if we evaluated the MT suggestions (I always hate saying "MT match") on the basis of our fuzzy TM matches?

Here's an example (that Star used in the presentation):

• The source sentence is "Pressure increase too slow when filling reservoir"
• The fuzzy TM match is "Druckanstieg zu schnell bei Füllung des Tanks" ["Pressure increase too rapid when filling reservoir"]
• The MT suggestion is "Druckanstieg zu langsambei Füllung des Tanks" ["Pressure increase too slow when filling reservoir"]

The program is able to compare the fuzzy TM match (for which it "knows" that there is only one unknown term) with the MT suggestion to find out that there is no other difference between the two than that particular term. It then concludes that the MT suggestion in all likelihood is correct -- the worst it could be is to have one term incorrect -- and it becomes an "Advanced MT match."

Clever, huh?

Now, this is not going to work really well with Google Translator or Microsoft Translator because the suggestions will likely be all over the place and therefore will make it unlikely that the fuzzy TM matches will prove to be valuable in evaluating the MT suggestions. But if your MT engine is essentially based on your and maybe some additional TMs, you likely will have a much greater success rate.

Now, Germans have the reputation of not being very enthusiastic, and I'm very happy to either prove that wrong or be one of the exceptions -- because I am very enthusiastic about all the different ideas that are popping up left and right when it comes to a productive and intelligent use of machine translation. It's so much "fun" (remember, I've lived on the US West Coast for almost 20 years!) to see bright minds come up with new ideas. And what's great for us is that the best ideas so far have always come back to the resource that we hold most dear: the translation memory.

Other Star products include the FormatChecker. This tool checks about 50 different potential errors in Word or FrameMaker documents, ranging from typographical errors to duplicated spaces, paragraph marks, manual references, and many others. The intention is to create well-formed documents before the translation even starts, thus aiming at a better return on translation memory matches and/or better entry of data into the translation memory.

A massive Star tool is Star CLM (Corporate Language Management) for, not surprisingly, the language management within corporations. It's a system that is able to monitor content changes in content management systems through watch folders and largely automates the production chain. While it does not have to be used alongside Star Transit, it is certainly streamlined for its use. Competitors? Won't surprise you to find SDL, Across, and Plunet in that list.

As a subscriber to the Premium version of this journal you have access to an archive of Premium journals going back to 2007.

You can access the archive right here. This month the user name is toolbox and the password is mydogisaseehund.

New user names and passwords will be announced in future journals.

If you would like to promote this journal by placing a link on your website, I will in turn mention your website in a future edition of the Tool Box Journal. Just paste the code you find here into the HTML code of your webpage, and the little icon that is displayed on that page with a link to my website will be displayed.

If you are subscribed to this journal with more than one email address, it would be great if you could unsubscribe redundant addresses through the links Constant Contact offers below.

Should you be  interested in reprinting one of the articles in this journal for promotional purposes, please contact me for information about pricing.

© 2015 International Writers' Group