Thanks to the persistent disbelief of some users, particularly cranky financial and legal translators who don't understand the challenges of programming, that it really is "impossible" to enable a project or TM update
based on an edited monolingual target text, Kilgray has decided to just do it and make this feature available to the masses
with the next release, memoQ 2013 R2. It's not a perfect solution, but a great start, and when the rest of the specification is implemented later, it will be
really, really good.
Here's an example of the first step reimporting a short
text in which every sentence except the first was rewritten and rearranged (click the pic to see it full-sized):
This monolingual alignment and the matches it assigned was totally automated - no adjustments by me. When applied to the translation document in memoQ, it doesn't change the order of the translation, but it does make updating the translation memory much easier. I can also use the tracked changes feature for versioning to look at the edits in more detail, and the view can be filtered to show the changes in a large document more clearly to ensure that nothing was missed.
What good is this? Well, so far Kilgray is rather fixated on the idea that one might receive edited documents from a proofreader or a client at some later date and import the changes to the project to update the TM. Maybe, but in many cases, this won't really happen in my workflow. If I finish I project, now I very often send the documents to a LiveDocs corpus, where they make a marvelous pseudo-TM (if a bit slow or slower sometimes) and an excellent context reference for concordance searches. I then delete the documents from the project, because I use projects as "containers" for repeated business, so unless some day the monolingual updates are made available for a document in LiveDocs, I may often not be able to take advantage of it. One could, of course, apply the same principle of monolingual alignment to a translation memory or even a TMX file, and I am sure somebody will do that before long if it doesn't already exist in some flaky academic freeware for supernerds somewhere.
So why am I so excited about this feature? Because I already use it every day. It saves me time and puts a big smile on my face. When I get ready to deliver translation, the last step for me is to look at it in the source application - Microsoft Word, PowerPoint, etc. There I make last-minute adjustments, change words, combine sentences, split sentences, delete things, etc. A lot of these changes never make it back to the TM, because that maintenance can be a major pain in the backside, especially when there's a lot happening on my desk and in my e-mail inbox. This feature is a big step toward reducing that stress.
Kilgray isn't done with this by any means. Plans for source text merges to allow combined sentences in an
edit to be handled easily have not been implemented yet, but I'm told that will follow no later than
the next version. I hope so. The current beta version is also a bit dodgy with many formats I've tested so far beside DOCX and TXT, and
changes of target text file type have been forbidden in the current
version, as have any edits except segmentation adjustment and linking
during the monolingual alignment.I plan a lot more testing to understand the limits of the current implementation, and I expect there will be many improvements in this area. But this is an excellent start.
When the specification was developed, Kilgray was unaware that something like this was already available from SDL in one of that company's pricy "regulatory" licenses (I wonder if the idea came from watching the video of the public argument about this option at memoQfest two years ago - I know that remarks about the SDL OpenExchange were followed closely). However, SDL has taken no great advantage of this to offer such a feature to a wider user base yet, so I have no idea how well it looks. But mark my words - in a few years, this innovation will be one of those things that users of any good CAT tool should take for granted!
Hi Kevin,
ReplyDeleteYes, this is a really amazing feature, and one which, if I remember correctly, I asked for on the mailing list a long time ago. Finally we have a way to get those last minute changes made in the final (monolingual) document back into your project.
If I send my translation to a proofreader who will be looking at both source and target, I send them a bilingual format. However, now I can also send a proofreader who is only supposed to look at the target language a file that I can use to update my project!
With a little luck, CafeTran will be the first to copy this one;)
Michael
In the past several years I've heard this same wish from quite a number of sources. It's a natural thing to think of for somebody who is just focused on working efficiently. That's why I prefer to listen to new users with no "useful" background in technology and who don't think first about how much time and effort some feature might take to develop (first assumptions like this are usually totally off the mark anyway, high or low).
ReplyDeleteOverall I think that technology providers need to spend a lot more time talking to - or more importantly, listening to - the technically challenged and "ignorant" people in their fields, because they are the ones who almost always offer the best insights. Most of the best tips on this blog come from things I observed watching absolutely clueless beginners or biting my tongue when asked "ridiculous" questions by someone who thinks a spreadsheet is something that goes over the grass at a picnic. If you don't pay attention to people like that you might end up with a cool new feature like those DOCX target comments that memoQ 2013R2 now includes but have no way to switch them off or choose which ones to include. LSP PMs who have nearly gotten fired for accidentally passing on comments I've sent for their eyes only in bilingual RTF files know how dangerous something like that might be :-)
Finally a good reason to upgrade from MemoQ 6.0!
ReplyDeleteIn SDL Studio there is something a little different. You can export the Bilingual text as a table in a DOCX format. Someone else can edit it using Track Changes in Word, and then you can import the changes back. It is quite handy, but lacks the functionality discussed in this article, which is quite great as I also tend to do my final read-through in the native application while making some last minute minor edits that are a pain to reflect back in the bilingual file manually.
ReplyDeleteAs far as I know there isn't an Open Exchange app for this yet, but I might be misinformed.
No, Shai, for those with the Trados Professional license, there is apparently an additional option involving the review of monolingual target documents. It's part of the opaquely articulated functions for the regulatory domain. But despite the fact that I was involved directly with regulatory matters in the medical device industry in the late 1980s and through most of the 1990s, I seldom understand a word of anything I see from SDL on that topic. The subject actually didn't interest me much, because a feature which is locked away from most of the users I would have contacts with is irrelevant to me. They've got it or I managed to misunderstand and they haven't, but in two years I'm sure it will be touted as one of the great innovations of SDL Trados 2017 :-)
DeleteThis DOCX table feature you mention is a somewhat more fragile answer to an ancient feature of Déjà Vu, which produced such "external views" for review by persons who don't use CAT tools and which could also be used (in a somewhat inconvenient way sometimes) for translation outsourcing. This feature was later adopted my memoQ, Fluency and others. I use such exports a lot for convenient reference to the source text as I read or to give comments of feedback of troublesome parts of the work. However, some things really do require checking in the full functional context of the target file, and that's where this feature Kilgray is about to introduce represents huge progress.
It's not perfect by any means yet, and right now I can identify quite a number of quirks with different formats (strange things with Java properties files the other day, but to be fair I was bending the "rules" in a pretty crazy test). Most of these issues will be straightforward to fix, however. And I'm already getting benefit out of the feature for current jobs, though right now I'm so cautious about checking that it's actually worked that I probably spend any time saved verifying that the desired changes were in fact imported. But I expect that for pre-release software. If I am still doing that in three months I'll see it differently.
Well, I have never worked with the Studio Professional version, but a functionality that is limited only to a certain edition (let alone one that is aimed at the "agencies") can hardly be called a feature.
ReplyDeleteMemoQ new implementation is indeed a innovation (we rarely see these nowadays, most of the stuff is just gimmicks), and one that fits perfectly into my own workflow that usually ends with reading the text in its native layout.
Currently, to save time, I usually try as much as I can (not always possible though) to use the Preview function to do my final read-through and insert all these minor edits directly into the bilingual file. In that regard Studio's ability to change the layout of the various windows that make up the editor environment is quite convenient, but the preview itself is often lacking (in most TEnTs) so this is not a perfect solution.
I'm sure that the monolingual proofreading feature has its issues, and just as certain that they will be ironed out soon. I'm also quite positive that you are right in your prediction that this feature will be copied by other software developers. Actually, I have a lot to say about the role that software developers have in the creation of some of the less-than-ethical practices that creep into the marketplace, and the plateau that the translation supporting technology has reached, but a good thumb rule is that if you really try to innovate, if you truly listen to the users (including the articulated but less technical ones as you have mentioned, Kevin) instead of telling them what they want and need while trying to sell them snake oil, marketing gimmicks, and empty promises, you will do good by everyone, yourself included.
Stefan Gentz has me more or less convinced me that I'm mistaken about SDL staking out this ground first in some way, but that doesn't really matter anyway. Most of the people in this field have a hard time articulating the value of most features, probably because there is such a great diversity of project requirements, and defining general principles isn't trivial. Have a look at the latest post on this release and the new video that shows this feature and a few things about tracked changes.
Delete