You only need a key!

01Why is the SDL OpenExchange called the OpenExchange?

If you weren’t familiar with SDL and the OpenExchange initiative then perhaps the name suggests it could be a platform of some kind that supports an open exchange of information or tools to help manage the open exchange of data or processes that are not supported out of the box in the core products.  Maybe you might also think that the word Open could refer to some kind of opensource facility?

Well, it would be incorrect to state that this is open source because it’s not a “free license“, but if this is what you thought then you were on the right lines.

If you thought  any of the following then you’d be wrong!

  • The SDL OpenExchange is not available to anyone in competition to SDL… like Atril, or MemSource for example.
  • The SDL OpenExchange is not free and SDL will charge a fortune to make this available to you.

Why do people sometimes think this facility is restricted in these ways?  This is a good question, and I can only hazard a guess.  But I think it’s probably for two reasons.  First it’s simply because some people like to perpetuate the idea that SDL are closed and not open to everyone… particularly when the reality is that I think SDL are the only commercial provider in this space that provide as extensive a facility as this for free!  It’s very likely that if you choose any other commercial technology as your primary platform you are locked in and will either have to pay for access to a less extensive API or ask the vendor to add features before you can get them.  I’ll repeat this because contrary to the reputation we sometimes see perpetuated, the Studio Technology Platform is a lot more than a tool for translating files and managing your Translation and terminology databases.  It’s a platform that does provide this capability of course, but it also provides a SDK (Software Development Kit) and an API (Application Programming Interface) that is freely available to anyone with a full license of the Freelance or Professional versions of SDL Trados Studio and what you can do with this is what’s referred to as the SDL OpenExchange.  It is exactly the opposite of being locked in!

The second reason would be because in the olden days of TTX and ITD, TMW and MDB, formats created by Trados and SDL, it was sometimes voiced that these proprietary formats locked you in and forced you to stick with Trados or SDL technology.  If you were locked in I think it was the result of circumstance rather than any deliberate attempt on the part of Trados or SDL.  When these tools were first developed there were probably less viable alternatives, and certainly other tools were less commonly used as we know.  Today things are different and the modern tools developed by SDL are XML based making it easier for interoperability of files and for developers wanting to integrate or customise to suit themselves.  Things have moved on and the user is in control!

If you want to read a little more about what can be done with this platform then perhaps these articles will be interesting for you:

These articles are fairly generic around the capability of the SDL OpenExchange so you can get a good idea of what this is all about, but you can also use this link to get a range of articles about how tools have been created for all users:

Tools like these are made available through the SDL OpenExchange “App Store” which you can see here : SDL OpenExchange “App Store”.  But this is really the tip of the iceberg because many companies, and individual users, take advantage of the SDK and API to develop tools, and to integrate systems for their own benefit.  All of this with no additional charge from SDL!

So, why might we see a competitor complaining that the SDL OpenExchange is closed to them even though they have a license for SDL Trados Studio?  Well, we might be very “Open” but you still need a key!  In this case, the key is simply a valid usecase for us providing access in the first place.  What’s a valid usecase?  Quite simply, the facilities we provide free of charge are there to enable users of SDL technology to benefit by enhancing the value they get from the SDL technology stack.  Developing the SDK and the API is no small task and it costs SDL a lot of money to create and maintain it.  These kind of things would be a valid usecase:

  • Create a filetype to allow a Studio user to be able to open and translate proprietary files from an application not currently supported.
  • Create a plugin that allowed a Studio user to connect directly to a Translation Memory system of a different translation environment.
  • Integrate a quality assurance tool not developed by SDL into the Studio interface so that Studio translations could be interactively QA’d.
  • Add new views into Studio so that additional processes such as analysing files, connecting to remote content, searching internet based dictionary tools.
  • Add a plugin to Studio for any Machine Translation engine
  • etc.

The basic theme here is that development using the SDK and API should benefit the users of SDL Trados technology.  The SDL OpenExchange has not been provided for competitors to SDL Trados technology to use in support of development and features for their own products and users.  On a personal level I don’t see anything wrong with this approach, and I don’t see anyone else providing this much, never mind giving it away to their competition!  Certainly today we have applications on the OpenExchange that have been created by competing vendors, and we also have applications not on the OpenExchange that were developed specifically by competing vendors because they wanted to be able to introduce their technology to SDL users; especially where the end user already uses a variety of solutions and wants to see them working in a more interoperable fashion.  The capability SDL provides does make the SDL Technology stack a sensible choice for anyone who wants, or needs, the ability to integrate disparate systems or simply add their own tools and features.

We also have some vendors who have not been given the key… well one at least!  But when you consider we have over 800 approved developers with access to the SDL OpenExchange and only four we didn’t provide a key then I think this puts a little more perspective on it.  Most of the competitors to SDL who applied have done so with the intention of creating a plugin that would benefit a Studio user.  I mentioned Atril and MemSource as examples of competitors to SDL… here’s an example of what one of them has done which will benefit both Studio users and their own just in case you thought I was kidding!

02

In fact you may well have seen examples of plugins in other articles on this blog that have been created by competitors to SDL.

I think calling it the SDL OpenExchange is correct… and everyone gets a key if they have the right intentions!

6 comments
  1. Hi Paul,

    You say in your post “We also have some vendors who have not been given the key… well one at least!”: I suppose that is Kilgray (I base my supposition on what Jost wrote in his most recent toolkit: “Not surprisingly, Kilgray is very eager to bring SDL on board and, also not surprisingly, SDL has so far not permitted Kilgray access to its application programming interface through OpenExchange. “).

    Could you tell us if that is so, and why SDL has decided not to provide a key to Kilgray? As a user of both Studio and MemoQ, anything that permitted me a better interaction between the two programs would be a plus.

    Riccardo

    Like

    • Riccardo, this is not something I can discuss at all other than to repeat what I have already stated. The OpenExchange, the SDL OpenExchange, has been provided to provide benefits for users of SDL Technology. So if another vendor wishes to create something to benefit their users then they could provide a similar facility. So far I see no evidence of this and can’t relate to your comment at all. If other vendors did open up this way then you would be able to get what you want. MemSource for example do have a public API and it was straightforward for a developer to provide something that benefits both groups of users. Others who don’t have an open API have used their inside knowledge to provide something that Studio can use. But to expect SDL to provide tools so that you can provide a benefit for someone else not using SDL technology doesn’t make any sense to me… unless we were an open source provider. We are not.

      Like

  2. Jesse Good said:

    Thanks for the article. I had one request concerning API documentation.
    Is there any chance of being able to view the documentation offline or without having to login?
    This is one thing I have found to be troublesome.

    Like

    • Hi Jesse. The documentation is very comprehensive, it’s updated regularly so we can ensure users always have the latest stuff to work to, and it is only made available online to approved developers. I don’t think having it online is the troublesome part though, it’s the having to login part which is currently one or three steps more than seems necessary. I’d like to see this being improved too, but I don’t think we’ll see an offline version of the documentation being made available.

      Like

  3. Hannu Jaatinen said:

    Hi Paul,

    I tried to find the MemSource CloudTM plugin from OpenExchange, but couldn’t find it. Is it still available for Studio 2014?

    Hannu

    Like

    • Hi Hannu, it’s not been released yet. May be available this week as it was submitted for testing/signing at the end of last week.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: