Thank you for the comments.
Evzen Polenka 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.
Jesse Good 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?
> 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?
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 :-\.