Blogs - All Comments

RE: Create Project Groups in SDL WorldServer using the REST API

Ina Song — Tue, 27 Aug 2019 08:32:29 GMT

Because our localized products have a large amount of source files that needs to be handled in one project group, so we think the ais mount mode may be more efficient for big products. Could you please share your thoughts here?

Thanks in advance!

RE: Create Project Groups in SDL WorldServer using the REST API

Ina Song — Tue, 27 Aug 2019 08:30:54 GMT

Hi Philip,

I am Ina Song, I am a user of SDL WorldServer with version 11.3. Now we are working on the integration with WS REST APIs, It's great to see your sharing here. So could you please demo how to use aisFiles when creating a project group by REST API? I tried but I am not quite understanding about how to use the field "aisFiles" in this API.

Looking forward to your reply.

RE: Sdl Studio PowerShell toolkit is now open source

Dano George — Mon, 01 Jul 2019 10:39:12 GMT

Hello Romulus,

RE: Connecting to SDL WorldServer using the /login REST API call

Laurent Gottardo — Wed, 05 Sep 2018 12:29:54 GMT

Dear all,

What are the steps to develop custom REST API endpoints for WS 11.3.1 ?

Many thanks for your help.

Best regards,

Laurent

RE: SDL Studio plugin manifest

Gary Hess — Mon, 02 Oct 2017 14:43:03 GMT

As of today, when I try to visit romuluscrisan.com, my browser reports:

Error 526 Ray ID: 3a786dff6f7f26f6 • 2017-10-02 14:42:41 UTC

Invalid SSL certificate

RE: Options to extend and customize Trados Studio

Romulus Crisan (former member) — Fri, 10 Mar 2017 07:54:57 GMT

[mention:0a7b4bd5362d45bc883afc365a3e169e:e9ed411860ed4f2ba0265705b8793d05] 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 [mention:0a7b4bd5362d45bc883afc365a3e169e:e9ed411860ed4f2ba0265705b8793d05] 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.

RE: Options to extend and customize Trados Studio

Evzen Polenka — Fri, 10 Mar 2017 07:48:00 GMT

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.

RE: Options to extend and customize Trados Studio

Paul — Thu, 09 Mar 2017 22:51:23 GMT

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.

RE: Options to extend and customize Trados Studio

Evzen Polenka — Thu, 09 Mar 2017 22:24:23 GMT

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 :(

RE: Options to extend and customize Trados Studio

Jesse Good — Thu, 09 Mar 2017 13:45:27 GMT

[mention:817439eb018f4729981806eeb24f1b52:e9ed411860ed4f2ba0265705b8793d05] 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.

RE: Options to extend and customize Trados Studio

Romulus Crisan (former member) — Thu, 09 Mar 2017 09:36:33 GMT

Thank you for the comments.

[mention:0a7b4bd5362d45bc883afc365a3e169e:e9ed411860ed4f2ba0265705b8793d05] 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.

[mention:8bf485d2f9844254b54ab433f63f642e:e9ed411860ed4f2ba0265705b8793d05] 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?

RE: Options to extend and customize Trados Studio

Jesse Good — Wed, 08 Mar 2017 23:16:24 GMT

> 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?

RE: Options to extend and customize Trados Studio

Evzen Polenka — Wed, 08 Mar 2017 18:18:32 GMT

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 :-\.

RE: True interactive translation prediction (ITP) in your CAT tool

Paul — Mon, 22 Feb 2016 06:31:09 GMT

Very clever solution Patrick, I like it. I also like your explanation... one of the clearest explanations I have ever seen.

RE: SDL Plugin Installer error – Where are the buttons?

Romulus Crisan (former member) — Thu, 07 Jan 2016 08:47:19 GMT

The latest version available on OpenExchange includes the fix too. The next major update for Studio will also include the fix. To download the latest version you can go here: www.translationzone.com/.../sdlplugininstaller-797.html