Options to extend and customize Trados Studio

Options to extend and customize Trados Studio

I'm absolutely sure that Trados Studio is the most customizable product on the market. To me this a no brainer; all you have to do is to go to the SDL AppStore and have a look at the number of plugins and applications that are available. And that is not all, because there are at least the same number of customizations carried out which are not published on the store because they are built to fulfill a specific need. Depending on the extension or customization you either have something that adds a new options inside Trados Studio or you have an exe that you have to run alongside Trados Studio. In this article I want to talk about this two options and when and why you should choose them.

"Why" is important

Both options require software development skills and rely on the same Trados Studio APIs. Deciding which type of extension/customization to build is key in order to provide the best solution to fulfill the user need. If you are looking to publish your application on the SDL AppStore then it is important to know that we encourage publishing of Trados Studio plugins instead of the standalone applications, and for every new extension or customization that is to be published we will not approve it as a standalone application unless there is a strong reason behind it. Of course there are still quite a few of them on the store and we are working to migrate them into plugins where appropriate.

Standalone applications

The first version of Trados Studio APIs didn't allow any form of user interface extension so the only option to provide a friendlier experience was to build an application that ran alongside Trados Studio.

Pros

  • They don't require Trados Studio to run.

Cons

  • Limited to project automation and translation memory operations.
  • If your application works with the Project Automation API it must be deployed in the Trados Studio application folder.
  • Need to run a separate application besides Trados Studio.
  • The Provided features will not be in the context of Trados Studio workflows.
  • No support provided in the future Trados Studio appstore integration.
  • The developer must create a custom installer.

Trados Studio plugins

Plugins were around from the first version of the Trados Studio APIs but didn't support any form of user interface extension until the introduction of the Integration API.

Pros

  • Integrate as part of Trado Studio workflows.
  • Provide Trados Studio contextual options.
  • Ability to create custom file types, verifications, translation providers, terminology providers, display filters, project and batch task automation.
  • No need to develop an installer as Trados Studio comes with the plugin installer.
  • Ability to disable a plugin without having to uninstall it.

Cons

  • Limited to certain user interface integration points inside Trados Studio.
  • Plugin installer limited in terms of plugins dependency deployment.

To my mind most of the times building a plugin for Trados Studio should be the go to option most of the time. Although there are though situations where a standalone application is needed, like the SDL Analyse where we wanted to give the user the ability to run an analysis outside Trados Studio.

Please leave a comment with your thoughts, ideas and suggestions.

  • This sounds like it's written by someone without enough imagination how stuff can (or should) work.

    If the "one bloated application with millions of plugins" concept would be that great, all the Unix world - proven to be highly effective by decades of its history - would be using it. But it's not.

    My comments to the standalone application "cons":

    > If your application works with the Project Automation API it must be deployed in the Trados Studio application folder.

    Not entirely true, ref. to PowerShell Toolkit for example.

    Plus, any such need is NOT a consequence of "I want a standalone application", but rather an "API short-sightedly designed for plugins only" (or a limitation caused by the .NET hell maybe?)

    > Need to run a separate application besides Trados Studio.

    Heh... this is actually a PRO: "NO NEED to run Trados Studio" and have to do a million of clicks to do my stuff in there...

    > The Provided features will not be in the context of Trados Studio workflows.

    That's not the standalone app concept's fault... but rather a problem of the bad design, see above.

    > No support provided in the future Trados Studio appstore integration.

    Again, that's SDL's fault, not the standalone app's :-\

    > The developer must create a custom installer.

    Doh, why?! Do you really believe that applications MUST have an installer?

    Is this perhaps based on the .NET hell experience, where applications install countless amount of hundreds-of-megabytes DLLs and similar crap?

    There is enough applications around which are just standalone EXE, with only dependencies on standard OS built-in libraries, without the need to write a bunch of crap to registry etc. One can simply run the EXE right away and that's it - THAT is what deserves to be called a good application.

    The entire article seems to be a highly biased, the list of "cons" of standalone apps seems to be artificially made-up just to make it look bad :-\.

  • > If your application works with the Project Automation API it must be deployed in the Trados Studio application folder.                      Yes, issue LTB-1136 is a huge one for me and a common one you see posted in the forums. I don't know if it is allowed, but just wondering what is on the priority list?

  • Thank you for the comments.

    I wouldn't consider powershell scripts as a standalone application because they require a certain level of IT knowledge and for sure they are not seen as a viable solution by the casual translator, project manager or reviewer.

    What we are trying to obtain with plugins is simplicity for the casual user, so your comparison with Unix doesn't make to much sense. Unix is a great operating system but not for consumers. One key objective around extension and customisation is to provide them in the most simplest and easiest form possible. I would rather compare the plugin ideas with Apple Store or Google Play which for sure are a huge success of this concept.

    I'm not saying standalone app's are bad, actually we've just released the SDL Analyse as a standalone app, but what I'm trying to say is that you can definitely get a better experience for the casual user if you add your features closer to what they do normally rather than force them to move to other applications and make them do a constant switch between them which leads to losing their focus and context which causes lots of human errors.

    Regarding .NET dll hell I'm not saying is not a real concern when you develop an application but this is not the main reason you should make a plugin, however our plumbing around plugin creation make things simpler for the developer.

    Having an app that depends only on the OS means that SDL should talk with Microsoft and include the features in Windows? Otherwise I can't really see how you can rely just on the OS. Registering Trados Studio assemblies in Windows GAC is not a good option because it's adding other limitations and problems.

    That's on our to development satisfaction list but it's not a top priority. Can you please give me a few reasons why you need to create a standalone application and not create a plugin?

  •  Right-click context menu that creates project, opens Trados Studio and then editor view. That pretty much automates the entire process. Also, want to quickly produce very small apps (console app) for very specific jobs and protyping/experimenting with the api.

  • Romulus, it looks like you missed my point completely.

    First, I was mentioning the Powershell Toolkit simply as an example of "non-plugin thing" which apparently does NOT need to be deployed in Studio application folder and still works without problems (as opposed to your claims in the article).

    This has absolutely nothing with PowerShell requiring IT knowledge or not. And while we are at that, RUNNING PS scripts does not require any it knowledge at all... just as RUNNING any application doesn't.

    Maybe you think that PS scripts have to be run only from PS console, or so... that's simply not true. Not only it's possible to run PS script e.g. using a simple hybrid batch file (which is BTW what I use in my enhanced PS Toolkit), but PS scripts can be even compiled to standard executables, with normal GUI etc., so user doesn't even know that he's running PS script.

    I'm not against plugins as a concept, when it makes sense... but I'm against nonsensical forced integration of everything just because someone finds it cool and wants to make a buzz about plugins.

    Putting things closer to users does NOT mean to make everything a plugin...

    You want to make things easier to use? Then fix the poor UX and some long-standing design flaws in the first place... stop leaving things half-baked and unfinished...

    I mentioned applications depending only on libraries already present in OS to contradict your claim that standalone application MUST have an installer. Sure, complex applications MAY (and most of them do) need own installer, but it's definitely not a must. Especially if we are talking about small application which may be essentially just calling a few Studio API functions.

    This leads me to my example of why I do not want Studio plugin, but standalone application - because I do NOT want to click million times to do my stuff. I want my actions to be scriptable - e.g. to create a project using info parsed in the form of plain text (list of languages, project location, TMs location, etc.) from some external system and passed to this application as command line parameters... and the same for e.g. importing translation packages - did you ever tried to import like 36 return packages MANUALLY ONE-BY-ONE (which is the only option in Studio - ref. above to the part about poor UX)? I better use the script to tell Studio "import all packages located in C:\foo into project located in C:\bar" and that's it! Why would I bother clicking through some GUI to export target files if it can be done easily using command like "ts et c:\bar d:\export" (which can be stored in a script, so I can do it using a SINGLE push on Enter)?

    Seems to me that people are so degenerated by all the clicking and taping and scrolling that they don't know anymore what "effectivity" is and means :(

  • Evzen, I think you're missing the point.  The article was written to explain the difference between the use of a standalone tool and a plugin, and in particular how we will be able to handle these efficiently when we integrate the appstore into Studio so that the management of these apps is simplified.

    Perhaps you could offer a solution to the management of apps developed by many different developers so that there was a consistent way for users to download, upgrade, get notified of changes etc.  If you did that I'd be more interested in what you have to say.

  • Problem is that what you say is not what I see in the article. The article feels like it describes differences between plugins and standalone application IN GENERAL, not from the perspective of "how good/bad can those be handled by the current architecture of appstore, etc.". So yes, I might have missed this point... since I couldn't recognize the point in the article.

    Regarding handling applications in appstore - what exactly should be that problematic? Downloading is the same, changes notification is the same as well... Okay, in such case some unified installer would be handy, what is the problem with that? Some pre-configured "installer template" which installs all applications to a same place (similarly to plugins), puts Start menu links in the same place, etc. Of course that "same place" where the applications would be installed would need to be added to PATH, so that one can run the application from anywhere (as one would expect), etc. I don't see that as a showstopper... but I admit that I may be well missing something since designing such architectures is not my primary job.

  • I know PS can have GUIs and can be run as an exe but I've personally never seen an application done like that (maybe it's just me).

    I'm huge advocate to use whatever it make sense for you to fulfil your needs. In your situation given your knowledge and experience I perfectly understand why a solution which involves scripting and  command line parameters is better and faster than what you have OOB. Please keep in mind that while clicking might not be the best experience you can get in some situations neither a solution which requires passing command lines parameters is appropriate for a casual user. It might be for you and other people with IT background but not for the majority of users.

    You're saying that putting things closer to the user doesn't mean is it has to be a plugin. I prefer to do my activities inside an application rather than switching between multiple applications (Microsoft Visual Studio is considered to be probably the best code editor exactly because of this reason). So for example rather than creating a separate application that can nicely handle 36 packages I would prefer to have that options seating alongside the default open package option within Studio ribbon. That gives me the opportunity to assign a shortcut if I want which gives allows me to start the process by touching just 2-3 keyboard keys.

    I'm not trying to say you're wrong it's just that I see this topic form a different angle.

    With my article I wanted to project the potential result you can get with this options and what has the potential of making the customisation more usable and simple for the casual user. It's not meant to be an evaluation from pure technical standpoint. Also I don't believe in silver bullets so as I said in my article if there is a good reason for the standalone application than it's absolutely fine, in fact we've just done that recently.