From what I can see, DeepL allows for glossaries to be used via its API. I can't see that being possible in the Trados Plugin, but I am wondering whether there are plans to make that feature available? It would add a lot of value.
https://www.deepl.com/de/docs-api/glossaries/
Daniel
Yes, there are plans. But we have limited resource and this is further down our priorities list. I'm a bit disappointed nobody ever takes the open source code we provide and extends it for the greater good of all users... it would certainly make the experience of all users a much better and more dynamic one.
But in the unlikely event anyone ever does this we will get around to it when it reaches the top of our own list.
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
I know, and I understand. Translators don't seem to be programmers.
I know you offer the SDK and everything, but the threshold is still there. Did you ever have a "beginner's code camp" or something? Some kind of online boot camp where somebody holds my hand while I do my first steps? If that was a regular (yearly) thing maybe you'd get a number of enthusiasts off the ground. (Or maybe that is already happening and I missed it?)
Daniel
We actually had several thousand developers registered when we used to do this via the old appstore, not all were translators, but some were. There are quite a few notable translators developing today. I think my point was it would be great if we could build more of a contributory platform for plugins because everyone would benefit from this. Instead, what I see very often is developers taking the code we have opensourced and then using it for their own purposes within their own creations. I think this is also ok and it is indeed one of the reasons we opensource to help developers get a start in what they're doing... but I have always been disappointed at the lack of reciprocity for benefit of everyone.
Did you ever have a "beginner's code camp" or something?
In fact we did do this. When we first set up the appstore and started opensourcing code the first developer we had in our dedicated team at the time wrote a series of blog articles to help developers get started, and they are still available on his personal blog today:
https://romuluscrisan.com/openexchange-where-do-i-start/
The reference to OpenExchange is what the AppStore used to be called... a name I wish we'd kept as I think this not only differentiated us from an "AppStore" that everyone has these days, but it also embraced the concept of being open which is a philosophy we still adhere to today.
In addition to this we also ran a series of open days around the world and I travelled with Romulus around Europe and Asia where we ran a day of training to help interested parties get started. Despite the effort we put into this, and the cost involved because we did not charge at all for his, I'd have to say that the events were not well attended. Also disappointing. I think part of the reason for this is the immaturity of this industry in recognising the benefits of having a developer and being able to build your own solutions around an established technology that will do the basics and allow you to build on whatever you want. Some companies definitely do take advantage of this and it's noticeable just how much they do as we see a lot of these efforts that never get published on the appstore. And I think these progressive companies learned how investing in even a single developer reaps massive rewards to help them step up against their competition and improve their overall localization processes.
We have spoken many times about how we might go about creating content to help more developers get started, but our experience of the past does make it hard to prioritise and definitely doesn't help us get any budget to do anything more than what we can manage to do ourselves, within our team, more based around the willingness and dedication of our team to give up their time to create it. Reading these forums it's always clear to me how much our teams are underestimated and how much their individual sacrifices to try and help goes completely unnoticed. No surprise there, but I am always surprised at how these guys continue to deliver despite the negativity we often see in here.
Apologies for the small rant, but what you are asking for is exactly what we put a lot of effort into in the past and got nowhere. However, I am always open to any suggestions we can incorporate alongside our own plans and maybe even find enough of a reason to prioritise them a bit more.
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
That link is very good, although it's from 2015 and a bit outdated in some respects. Then there is this:
https://developers.rws.com/studio-api-docs/articles/intro.html
How stable is the API? Does it still make sense to write for Studio 2021?
Daniel
Yes... that link is just part of where the API documentation can be found. Sadly nothing there to really help you take the step from knowing nothing to being able to use the documentation to create your own work. The old link from Romulus is still good because the concepts are important.
How stable is the API? Does it still make sense to write for Studio 2021?
If you only have 2021 then no problem. You will have to rebuild plugins for 2021 to be supported on 2022, and when we move to the next major release after 2022, whatever that is called, you'll probably have to rebuild that too. We haven't had a major release for years that didn't require apps to be rebuilt, and often with changes to the code as well due to breaking changes. So if the latter is what you mean by breaking changes we almost always get them! But don't let that put you off... we always help developers with the changes that are needed and our appstore team have over a hundred to work through each time! Tedious but doable.
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Yes... that link is just part of where the API documentation can be found. Sadly nothing there to really help you take the step from knowing nothing to being able to use the documentation to create your own work. The old link from Romulus is still good because the concepts are important.
How stable is the API? Does it still make sense to write for Studio 2021?
If you only have 2021 then no problem. You will have to rebuild plugins for 2021 to be supported on 2022, and when we move to the next major release after 2022, whatever that is called, you'll probably have to rebuild that too. We haven't had a major release for years that didn't require apps to be rebuilt, and often with changes to the code as well due to breaking changes. So if the latter is what you mean by breaking changes we almost always get them! But don't let that put you off... we always help developers with the changes that are needed and our appstore team have over a hundred to work through each time! Tedious but doable.
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Translate
