Since I learned earlier this year about plans to integrate LSP.net's Online Translation Manager (OTM) - the workflow solution I use for secure data transmission in my projects - and SDL Trados Studio I have kept track of the progress of this effort with some interest and satisfaction. Although it is unlikely to be of immediate benefit to me, an occasional user of SDL Trados desktop applications, I have followed the combinations of business process tools with their translation implementation counterparts for many years, and this seems to be one of the few efforts that really deserves the label "integration". Too often that word is used to describe reading a text file with an analysis of files and applying a scoping grid to ensure that one's profits remain suitably modest or non-existent.
When I contacted OTM's architect this week to get the latest news before heading to Warsaw for the translation management conference, he described the development and testing over the past month and the probable completion of the middleware component next week. By the end of October, the OTM workflow system should have a new range of features to complement the Trados workflows for analyzing and testing the viability of files for translation processes, applying customer-specific weighting tables to matches and more.
The release of the new version of OTM and the SDL Trados integration features is expected in November after testing with a pilot group is completed. Given the good record of LSP.net for releasing stable versions of its software over the past three years, I expect a well-tuned, useful advance of functionality. The integration will be available for testing and use free of charge for some months in its rollout phase to ensure that potential users have every opportunity to master its application to their business processes. Several licensing models are being considered afterward to allow users flexibility.
Contact LSP.net for further details on this product. When the test phase is completed, I hope to interview some of the current group of companies working with this solution and find out the best and the worst of its implementation.
Showing posts with label integration. Show all posts
Showing posts with label integration. Show all posts
Jun 27, 2012
OTM integration for SDL & more ahead
Some months ago, I dropped into the offices at LSP.net for a chat and was surprised by a white board covered with interesting scribbles that hinted at the most fundamental change of design yet for the translation workflow management tool OTM. In the two and a half years I have used the platform, I have seen many positive developments, which have scratched off nearly everything on my initial wish list (with other plans that may take care of the few remaining items of streamlining for freelancers by sometime late this year or early next year), but I really didn't expect to see significant integration with translation environment tools except perhaps a bit of analysis log reading for quotation purposes.
I was wrong. A few days ago, the official announcement of the integration plans for OTM and SDL Trados Studio hit my inbox, and discussions with the system's architect have made it clear that there's more ahead, though schedules are a bit vague at present. It's not clear from the post on the LSP.net blog, but the both the server and desktop (freelance) versions of SDL Trados will be integrated with the new middleware component, though there will be some differences in function.
I'm not a huge Trados fan as much as I respect some of the developments in recent years, but I'm excited by hints that the online workflow tool may make it easier to use SDL Trados to generate project file collections not only for translators using Trados but for those with other tools as well. If this really happens, I think it will be a great boost for interoperability and reduce the perceived "bother" of working with translators who use tools with which the project manager may not be competent.
Another thing that I like about the development plans for CAT integration with OTM is that the middleware component is actually vendor-neutral. This means that it can facilitate integration at the server and desktop level with more than just SDL Trados in the future. Where this may lead is unclear right now, but I think that the changes announced for memoQ version 6 for Microsoft Office file handling in the server API make that an obvious candidate, though the lack of a client API for memoQ still means that there is more potential benefit to Trados users.
Although I'm quite encouraged by this new direction for my workflow tool, I probably won't use these functions myself, mostly because Trados is not my tool of choice for translation, though it is an important part of some of my preparation, data migration and terminology output workflows. OTM has an enormous range of features - it's designed to run a medium-sized or larger translation agency with widespread global interests - and some of the presentations of this enormous range of functions can be quite intimidating. But like other tools I use that have many function - Microsoft Word and memoQ, for instance - I need only a small fraction of those functions for my routine work, and the underlying simplicity of the environment enables me to use the parts I need with great efficiency and security for my clients. And on those rare occasions when I need to work as more than just the Lone Translator, I can draw on whatever I need.
The pace of development for OTM has slowed since I first became involved with it as the issues identified in the pilot phase were solved, often in some surprisingly useful and original ways. But the SaaS solution continues to grow in very practical ways, such as improved security, and its development is still driven by the same basic needs that led to its creation in the first place - the needs of its users to "punch above their weight" profitably in competitive project management.
I was wrong. A few days ago, the official announcement of the integration plans for OTM and SDL Trados Studio hit my inbox, and discussions with the system's architect have made it clear that there's more ahead, though schedules are a bit vague at present. It's not clear from the post on the LSP.net blog, but the both the server and desktop (freelance) versions of SDL Trados will be integrated with the new middleware component, though there will be some differences in function.
I'm not a huge Trados fan as much as I respect some of the developments in recent years, but I'm excited by hints that the online workflow tool may make it easier to use SDL Trados to generate project file collections not only for translators using Trados but for those with other tools as well. If this really happens, I think it will be a great boost for interoperability and reduce the perceived "bother" of working with translators who use tools with which the project manager may not be competent.
Another thing that I like about the development plans for CAT integration with OTM is that the middleware component is actually vendor-neutral. This means that it can facilitate integration at the server and desktop level with more than just SDL Trados in the future. Where this may lead is unclear right now, but I think that the changes announced for memoQ version 6 for Microsoft Office file handling in the server API make that an obvious candidate, though the lack of a client API for memoQ still means that there is more potential benefit to Trados users.
Although I'm quite encouraged by this new direction for my workflow tool, I probably won't use these functions myself, mostly because Trados is not my tool of choice for translation, though it is an important part of some of my preparation, data migration and terminology output workflows. OTM has an enormous range of features - it's designed to run a medium-sized or larger translation agency with widespread global interests - and some of the presentations of this enormous range of functions can be quite intimidating. But like other tools I use that have many function - Microsoft Word and memoQ, for instance - I need only a small fraction of those functions for my routine work, and the underlying simplicity of the environment enables me to use the parts I need with great efficiency and security for my clients. And on those rare occasions when I need to work as more than just the Lone Translator, I can draw on whatever I need.
The pace of development for OTM has slowed since I first became involved with it as the issues identified in the pilot phase were solved, often in some surprisingly useful and original ways. But the SaaS solution continues to grow in very practical ways, such as improved security, and its development is still driven by the same basic needs that led to its creation in the first place - the needs of its users to "punch above their weight" profitably in competitive project management.
May 10, 2012
memoQfest 2012: practical outsourcing with memoQ desktop editions
This week I'm in Budapest for Kilgray's memoQfest, the annual gathering of users and curious bystanders as well as CAT tool competitors who want to learn how to get the technology right.
This morning I gave a presentation on a topic which has become a regular part of my consulting with colleagues and clients... or better said, has been a part of my work with them from the beginning of my association with the language services industry. Every time I hear a translation agency or corporate translation consumer say that a qualified translator with the subject expertise needed cannot be used because he or she doesn't work with the "right" translation environment tool, I am saddened by the foolishness of that statement or the lack of understanding it reveals. In mature IT sectors interoperability and lossless data exchange have been common for decades, though sometimes one must be clever to get there. But the cottage industries for languages are, in many ways, stuck in the IT mentality of the early 1980s despite the fact that the actual technology today is more like Y2K. Gut Ding braucht Weil as the Germans say.
At a memoQ master class yesterday, Kilgray COO István Lengyel stated that "Interoperability is the art of compromise." True, but if you keep your wits about you and apply them, the compromises are usually not as awful as originally assumed.
memoQ is distinguished by the great ease with which it can manage data to be used in translation with nearly any other translation environment. SDL Trados Studio actually does a few things better, but overall, the utility and ease of use for memoQ is far greater in most cases. It's like a Swiss Army knife of translation integration, with one or more reasonable workflows for almost anything.
Today's talk was a 45 minute distillation of a workshop I usually deliver in half a day. It was a bit of a challenge to pare it down in the limited time available with last-minute translation projects having more content than planned and late nights talking to colleagues from around the world. For experienced users, most of what I had to say was "old hat"; some new memoQ users were surely overwhelmed by a flood of "new" information. I hope that each listener was able to leave the session with at least one useful idea to apply and improve their business. For those who fell asleep and couldn't take notes or anyone else who likes to play "guess the context" with lecture slides, here is a link to the slides from the talk. Questions are welcome on whatever appears mysterious; most of it is somewhere on this blog in great detail. Re-use is permitted for any morally acceptable purpose (with attribution please). When Kilgray puts the video of the talk online, I'll post it here so those slides make more sense.
This morning I gave a presentation on a topic which has become a regular part of my consulting with colleagues and clients... or better said, has been a part of my work with them from the beginning of my association with the language services industry. Every time I hear a translation agency or corporate translation consumer say that a qualified translator with the subject expertise needed cannot be used because he or she doesn't work with the "right" translation environment tool, I am saddened by the foolishness of that statement or the lack of understanding it reveals. In mature IT sectors interoperability and lossless data exchange have been common for decades, though sometimes one must be clever to get there. But the cottage industries for languages are, in many ways, stuck in the IT mentality of the early 1980s despite the fact that the actual technology today is more like Y2K. Gut Ding braucht Weil as the Germans say.
At a memoQ master class yesterday, Kilgray COO István Lengyel stated that "Interoperability is the art of compromise." True, but if you keep your wits about you and apply them, the compromises are usually not as awful as originally assumed.
memoQ is distinguished by the great ease with which it can manage data to be used in translation with nearly any other translation environment. SDL Trados Studio actually does a few things better, but overall, the utility and ease of use for memoQ is far greater in most cases. It's like a Swiss Army knife of translation integration, with one or more reasonable workflows for almost anything.
Today's talk was a 45 minute distillation of a workshop I usually deliver in half a day. It was a bit of a challenge to pare it down in the limited time available with last-minute translation projects having more content than planned and late nights talking to colleagues from around the world. For experienced users, most of what I had to say was "old hat"; some new memoQ users were surely overwhelmed by a flood of "new" information. I hope that each listener was able to leave the session with at least one useful idea to apply and improve their business. For those who fell asleep and couldn't take notes or anyone else who likes to play "guess the context" with lecture slides, here is a link to the slides from the talk. Questions are welcome on whatever appears mysterious; most of it is somewhere on this blog in great detail. Re-use is permitted for any morally acceptable purpose (with attribution please). When Kilgray puts the video of the talk online, I'll post it here so those slides make more sense.
Dec 10, 2011
Heads in the Cloud? Or somewhere else?
From a somewhat different perspective, Hungarian translator Csaba Bán noted that bits and dribbles of text translated via project management tools in the Cloud, while perhaps offering some efficiencies for an LSP or other company, too often unnecessarily fragment and waste the translator's time for inadequate compensation under most current schemes. I've heard a number of my clients talk about developing web-based "instant interfaces" for quickie translation service, and I know of a number of companies who have had something like this for years, but it all seems a bit like a sleazy back alley encounter on the fringes of a Red Light district with too great a chance of the translator's business suffering ill health from such indulgence. Cloud solutions which do not cleanly integrate with a translator's working environment tools but which require copying and pasting in various fields and windows are simply inefficient (despite some tools offering Clipboard integrations) and not very attractive. And appropriate minimum charges and premiums to offset the disruptions caused by too many dribbles during the day are called for. This requires some thought, and I can't pretend to offer any brilliant solutions to the dilemma, as I think each situation will have to be considered individually until a good set of general principles for best practice emerge. I have one such case I'm puzzling over myself right now: how to charge for "tweet translation" for a long-term client who runs a PR agency. So far I haven't, because the volume has been modest and fits well enough into the ordinary flow of our business discussions, but the case has me thinking.
As readers of this blog probably know, I am also involved in other types of Cloud-based project management for translation. When I began to encounter the first web-based administration interfaces with my agency clientele a decade ago, I hated them. In fact, I have dumped several otherwise rather good clients, some paying rates on par with decent direct clients, because I found their systems too cumbersome and prone to fault. One of the worst was a custom mess from an international LSP whose Swiss branch was a frequent customer; half the time, secure deliveries via their portal were simply impossible and I had to resort to insecure e-mail attachments. (Yes, these can be passworded, but that involves additional trouble.)
Gradually, decent standard solutions emerged. A number of my clients are happy with the German Plunet solution; I favor LSP.net's OTM, not because I localize the English interface but because it's comprehensive, legally secure, provides robust processes and archiving, is software as a service (SaaS) at modest cost, and I don't have to screw around with the infrastructure at my dilapidated country estate with its lousy bandwidth availability; and there are other acceptable alternatives beside the rather nightmarish mess of the Open Source solution I once tortured myself with for several months (Project ]open[ Translation). A good online administrative solution like this has many advantages over desktop or LAN solutions, and I have discussed many of these benefits in previous posts about OTM. Even the best solutions I have seen, however, have one glaring weakness: login management!!!
This is a big problem with many online applications. We all have too many damned passwords to juggle. When suddenly I have another dozen or two dozen logins to translation project administration systems for my agency and big corporate clients, things begin to get dicey if cookies, utilities like KePass or other methods are not applied. Personally, I would like to see options for OpenID and other integrations as one is beginning to see with some of the social media. Despite the hassles sometimes involved here, I think Cloud-based tools of this kind are among the most useful for managing translation-related processes and making them secure. I use my OTM for encrypted deliveries of confidential files and for providing clients with full access to their project backup archives. This is a blessing if I'm off somewhere taking a break and someone desperately needs a copy of a translation I did last year which has gone missing.
Dec 2, 2011
Don't surrender freedom again - demand interoperability
Once upon a time, in my youth, communication, including translation, used media that were more or less common standards. Any pen or pencil could write on most any paper or vellum, and while one might have preferences in a brand of typewriter, the choice mattered little to the end result. Transmission by postal mail, courier, teletype or (later) fax also used mostly compatible protocols, and fewer things got lost in the pile of junk mail, as the kinder, gentler form of "spam" was called in those days.
Then the rise of IT and media technologies in the commercial and consumer world shattered this pax, and a myriad of information fiefdoms rose and fell, with users as the foot soldiers and cannon fodder in their conflicts. Eventually, on the main stages of IT, the vendors were forced to realize that their futures depended not on information fortresses but in open exchange and interoperability.
In IT backwaters such as the translation "industry", old practices persisted like medieval kingdoms and customs around the Himalayas, but eventually modern data sanitation reached even this provincial niche, which had adopted some computer tools while ignoring most best practices to maintain proprietary strangleholds. But eventually, the march of progress reached even those altitudes, and TMX, TBX and XLIFF became common parlance. And all is well or shall soon be. Really?
In the 203rd edition of his Tool Box Newsletter (premium version), Jost Zetzsche discusses a recent article in Forbes magazine (Cloud Computing's Vendor Lock-In Problem: Why the Industry Is Taking a Step Backward) and its implications for IT service consumers, including those involved in the translation business. The original article and Jost's commentary are very much worth reading (which is why I subscribe to the full content of his newsletters). His insights included the following comment:
"While we have data exchange standards that are more or less well supported (TMX for translation memories, TBX for termbases, XLIFF for the translation data, and the upcoming Linport for translation packages), there are no mechanisms that enable tool A to enter into the server- or cloud-based workflow of tool B. So, if your client sends your project not as data but as a login that you can use within a tool to access an online-based project or -- even more simply -- to actually log into an online-based tool that automatically gives you access to online-based data, all the hard-fought-for advances in widely accepted data exchange standards are nullified."
This is one of the problems which has concerned me, along with the loss of platform freedom for translators currently wanting to work on server-based projects. Although I know some translation companies, such as Translators International in the Netherlands, who use their server-based memoQ and other technology to make translatable content available to their language pair teams in a variety of best practice, compatible formats, in too many cases, server-based projects lead to a kind of lock-in which ultimately is in no one's best interest. Across Systems, with its wicked policy of deliberate incompatibility, represents the worst case I know, because it is not even possible to work with data exports of some kind as one can with respectable systems such as some SDL technologies, memoQ, Ontram and others.
Various influencers within SDL, Kilgray, Atril, MultiCorpora, Andrä AG and elsewhere are probably quite tired of hearing me pluck the strings of my dream harp loudly and repeatedly in their presence: I want to see online server communication standards which enable a client user of Trados Studio or Wordfast Pro to connect to a memoQ Server project, or someone with a memoQ Translator Pro installation to connect to an Ontram or SDL server project and work most effectively using the ergonomic tools with which the translator or editor is most familiar. I don't buy the arguments of "difficulty" at face value; just look at all the integration plug-ins that are being released by various vendors, with remote TM or termbase access, and it's fairly obvious that at least some degree of online interoperability should be achievable without much pain.
Jost's commentary concludes with a quote from the Forbes article: "Only one thing will eliminate or reduce the risk of vendor lock-in in the long run: if end-user customers start demanding standardization and interoperability, just as they have in the past with on-premises applications... providers will fall in line."All of us - individual translators, translation companies and corporate customers who manage their own translation services with server-based technologies - need to demand that all the credible providers of translation environment technologies "fall in line".
Subscribe to:
Posts (Atom)