• State Verified Answer
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 4 subscribers
  • Views 4289 views
  • Users 0 members are here
Options
Related

What's in the New API for Trados Studio 2017?

Jesse Good

So far I know there will be a new filtering API for the new filtering view and the Groupshare REST API will have a lot of other new functionality.

I wonder if there is anything else we can look forward to?
Rate translation
×
Suggest better translation
×
  • 0 in reply to Andrea-Melinda Ghisa
    Which of the MANY reported API bugs and omissions will be fixed?
    Which of these fixes will get in Studio 2015 and how quick?
  • 0 in reply to Evzen Polenka

    Hello Evzen,

    We have a long list of fixes and enhancements we want to see that relate to the APIs but every one of them failed to make it into this initial release of Studio 2017, and I don't know how many will be retrofitted into 2015 once the development team start to look at them.  Depends on the effort... some will and some won't.

    At the start of the release work we were hopeful to be able to do more, but as time went on we were unable to focus resource on this area because of the volume of work we had for other things.  I'm hopeful we will be able to do more in 2017 through the cumulative updates and service pack releases, and we will keep this community updated of the progress.

    I have copied a screenshot of the "Developer Satisfaction" list we have already submitted.  There is too much detail behind all of this to share it all in here and we can't make this available to non-SDL users, but if you think we might have missed something based on this image alone or want some more detail on a specific item then feel free to ask and we'll be happy to oblige.  It's as important for us to make sure we have captured what's missing as it is for you:

    Regards

    Paul
  • 0 in reply to Paul
    Thanks, Paul.
    I'm glad to finally hear that at least there is some real will on SDL side to do something about that. So far we can see just gazzillion of unanswered bugreports around the forum, discussions being just cut off whenever it came to a conclusion that there is a clear bug in Studio/API/wherever, etc...

    One thing - you do realize that releasing fixes ONLY for Studio 2017 is HIGHLY unfair, right?
    Unless you offer a free upgrade (or some really symbolic price like 20 bucks), of course...

    I do realize that maintaining multiple codebases is difficult... but that's not our (the users') problem, is it?
    As long as we, users, are required to pay BIG money for each new release - and no, the discount offers I see around don't solve anything; there is still too big amount left to be paid even after discount - you, the producer, should be obligued to keep also non-current versions on the same functionality/fixes level.
    Or you can simply switch to subscription-based licensing, just as antivirus companies did loooong time ago... then it's okay to support only the latest released version (unless you cripple some functionality in the new version, of course... like e.g. the alignment editor).
  • 0 in reply to Evzen Polenka
    Hi Evzen,

    I have some sympathy with you... but not a lot! Why don't you have a support & maintenance contract? In my opinion anyone serious about their business should have this and when you do your question simply isn't an issue. In fact if more people did this then we would not be having as many discussions as we do now about the things that are not fixed because we would find it easier as a business to justify additional resource to pay for it.

    We definitely have to keep fixing things and want to support our users with as much as we can, but I think it's a 2-way street. We want to provide you with something that works best for all the things you want to do. In return you pay for that service. If you only pay for one version and no maintenance that doesn't seem fair at all.

    But that's just my opinion.

    Regards

    Paul
  • 0 in reply to Paul

    If it would be free, no problem with that. But these mafia-like practices (pay for the right to live... ugh, report bugs)? No, thanks, sorry.
    And I'm guessing that the company I work for as contractor is of the same opinion - AFAIK they had this contract, but after just wasting this money (since SDL support stuff was not even able to understand the bugs they were reporting, not mentioning actually fixing it) they decided to not renew the contract.

    I'm fine with the idea of paying extra for extra features requested by particular user/company (especially for specific ones which may not be as useful for wider userbase). But I'm absolutely NOT fine with paying for fixing bugs. That's unacceptable.
    If fixing bugs is too expensive for you, then you simply should not introduce them in the first place... as easy as that. It has been proven that at the end of the day this is cheaper than putting something together quickly/cheaply and then fixing the mess.
  • 0 in reply to Evzen Polenka

    You're reporting bugs in here for free aren't you?  I don't believe these comments about SDL Support not being able to understand the bugs.  I hear them now and again whenever they are investigated and there are always two sides to them.  Support & Maintenance is not just about this, it's about getting every upgrade, being able to report technical problems and expect a timeous resolution or be able to escalate it if you don't get it, and more importantly it's about putting some skin in the game to ensure you are doing whatever you can to support the successful operations of your business.  I don't understand how any business can operate otherwise.

    Unknown said:
    If fixing bugs is too expensive for you, then you simply should not introduce them in the first place... as easy as that.

    Brilliant!  I'll just tell the team who deliberately put them there to stop.  Might save us some money and we can concentrate on other things :-)
  • 0 in reply to Paul

    Unknown said:

    I have copied a screenshot of the "Developer Satisfaction" list we have already submitted.  There is too much detail behind all of this to share it all in here...

    Hi Paul (I finally found this thread...) - do you have any further info about fixing the API related bugs mentioned? Any roadmap or so?

    Just to remind, some of the problems were summarized here: https://community.sdl.com/developers/language-developers/f/61/p/542/35274#35274 (the Newtonsoft Json.NET problem seems to be resolved in Studio 2015 SR3 release).
  • 0 in reply to Evzen Polenka
    Hi Evzen,

    Up to now there has been no dedicated attempt to address the items in that list because the teams were working on other priorities. We had a meeting last month, across all the parts of the business, to discuss what we need to be doing this year and developer satisfaction does have a place at the table. I know the product management team are working on the priorities for this category of work because we have been asked to check the order of priority so we can see how this fits into a grouping of items where we might be able to tackle several at a time as they deal with the same area of code.

    I'm telling you this to be open with you Evzen, not to start a fight! This is just how it is. But what you can do, if you are interested, is to give me your order of priority for the things you need the most and I will carry this forward as we plan the work in.

    Regards

    Paul
  • 0 in reply to Paul

    I would say that the most problematic thing is the memory hog, see e.g. here: community.sdl.com/.../34489
    This is definitely not just API related, there were numerous reports about memory problems happening during nornal "GUI" analysis or pre-translate. And e.g. if the code mentioned in the linked thread contains only pre-translate or analysis instead of packages creation, the same thing happens.

    BTW, while we are at the packages creation - the wizard has VERY annoying behavior that failed creation of SINGLE package makes ALL remaining packages creation being skipped (it's visible on the screenshot in the linked reply). It should of course continue with next package in the list, not cancel the entire operation :(.