When Studio was designed, they gave absolutely no thought to the idea that someone might want to use scripting, or might not want to use the mouse.

I have no idea why they designed it that way. Scripting languages have been around for decades and if Studio had been designed for coders, then it would have been designed completely differently. Voice recognition has also been around for decades. Everyone knew it was going to be big.

Clearly the UI is not Studio's strong side, and clearly SDL does not have the resources to redesign it.

Maybe SDL should think about making the UI open source.

There might be enough users with programming background interested in redesigning the UI as an open-source project.

Some of the information you mention might even be accessible to a redesigned UI.

Just saying...

Best regards,
Bruce Campbell
ASAP Language Services

Unknown said:

Maybe SDL should think about making the UI open source.

There might be enough users with programming background interested in redesigning the UI as an open-source project.

That's almost funny Bruce!  Aside from the fact I'm doubtful there are enough interested users with the right level of expertise to deliver this I know from experience that even things people complain about for ages get zero traction from other developers when we opensource them.  We have a whole site of opensource applications and virtually no pull requests at all despite there being plenty of requests from users for enhancements.

Unknown said:

When Studio was designed, they gave absolutely no thought to the idea that someone might want to use scripting, or might not want to use the mouse.   ...  Some of the information you mention might even be accessible to a redesigned UI.

Studio is accessible to coders, but not to scripters.  All of the things mentioned are accessible to coders and scripters capable of adding code to their scripts.

In many ways I would of liked to have seen the COM interface made available to Studio as well but when I look at the level of integrations possible and the sort of things I have seen people do with the APIs I do think we made the right decision with the API we have.

Unknown said:

even things people complain about for ages get zero traction from other developers when we opensource them.  We have a whole site of opensource applications and virtually no pull requests at all despite there being plenty of requests from users for enhancements.

No pull requests means just that no one is interested in giving their code back to SDL and open source it, no that no one is interested or able to do the changes.

Besides, that does not surprise me at all - given how awfully expensive Studio is, one simply expects to get a reasonably functioning software, not some DYI Ikea-style stuff! And even if one does some enhancements for him/herself, it's absolutely no wonder that he/she is not willing to give the code for free back to SDL to eventually incorporate it in next (awfully expensive) version...

Unknown said:

In many ways I would of liked to have seen the COM interface made available to Studio as well but when I look at the level of integrations possible and the sort of things I have seen people do with the APIs I do think we made the right decision with the API we have.

Look at all the possibilities in Microsoft Office... it's all available via COM interface!
Studio is FAR FAR AWAY from it.

Unknown said:

No pull requests means just that no one is interested in giving their code back to SDL and open source it, no that no one is interested or able to do the changes.

Indeed this is one thing that it means.  I have plenty of experience in trying to get others to contribute to some of these things and we got zero back.  So what makes you think opensourcing an editor would be any different?  People would just do what they already do and make changes for themselves.

Unknown said:

Besides, that does not surprise me at all - given how awfully expensive Studio is, one simply expects to get a reasonably functioning software, not some DYI Ikea-style stuff! And even if one does some enhancements for him/herself, it's absolutely no wonder that he/she is not willing to give the code for free back to SDL to eventually incorporate it in next (awfully expensive) version...

The basic truth is people do things for themselves and that's it.  The provision of the APIs is not anything anyone is paying for.  If it is and you only know how to work with COM then why are you buying it in the first place?  Show me another commercial translation software that provides APIs to the same extent as we do?  And what solutions made by developers (who don't already work for SDL) did we put in the software today?

We don't have to provide code for anyone to use, and we don't have to build applications for people to benefit from.  We chose to because it's helpful and because we actually hoped people would contribute to help improve these solutions for everyone by being part of a community striving to improve things.  You and Bruce are polar opposites... I think Bruce probably thinks the way I did when we started the opensource facilities (at least this is the sense I get from his posts) whereas you have a more cynical view of everything.

Unknown said:

Look at all the possibilities in Microsoft Office... it's all available via COM interface!
Studio is FAR FAR AWAY from it.

So where were all these amazing things when Trados was around and you could use the COM interface?  Where are all the amazing things you can do with MultiTerm that still offers a COM capability?  There is absolutely no comparison between what we see today and what we used to see with Trados.  But perhaps you just don't know... so I can't argue with that.

Comparing Studio with Microsoft Office... nice one!

Unknown said:

So what makes you think opensourcing an editor would be any different?

This was not my idea, it was Bruce's ;-).
I personally don't think it would be any different. I was following up just on the "no giving back to opensource community".

Another problem might be that a big portion of the developers actually making some Studio enhancements are not entitled to give it back to the opensource, since they make it as part of their employment job... i.e. they don't own the rights for the code.

Unknown said:

The basic truth is people do things for themselves and that's it.  The provision of the APIs is not anything anyone is paying for.  If it is and you only know how to work with COM then why are you buying it in the first place?

The fact that the interface has switched from COM (Trados) to .NET only (Studio) may not be obvious for everybody.
And if people are used to Office automation - or the entire COM-based Windows automation in general - they may be unpleasantly surprised.

Unknown said:

Show me another commercial translation software that provides APIs to the same extent as we do?

There is none, AFAIK, that's true.
But it looks like it's kinda abandoned for quite some years - it did not move forward in any way (enhancements, bugfixes) for quite some time, which does not give any positive feeling too...

Unknown said:

And what solutions made by developers (who don't already work for SDL) did we put in the software today?

Probably none, since a) there were none, and/or b) you employed recently some of the developers ;-) (I believe e.g. Patrick Hartnett was not working for SDL in the past, right?), so I would expect to see some additions in near(?) future.

Unknown said:

So where were all these amazing things when Trados was around and you could use the COM interface?  Where are all the amazing things you can do with MultiTerm that still offers a COM capability?

I could automate it from engineering scripts.
Though, as I realized recently when trying to do some 'more serious' work with MultiTerm, some things are simply broken and don't work.

Unknown said:

There is absolutely no comparison between what we see today and what we used to see with Trados.

Sure, the amount of available functionality is much bigger, there is no doubt about it.
The bigger question is why is couldn't it be made available via COM... it should be essentially just a few lines of code (though I'm not a developer, so I might be wrong here).

Hi Paul and Evzen,

Sorry for inadvertently causing a small storm.

Paul, I agree that open-sourcing might be a pipe dream. You may be right that "people do things for themselves and that's it."

And I agree it is unlikely that Studio users will have the time or inclination to devote to an open-source project like this. They are too busy translating.

But look at the many good open-source programs there are, such as Autohotkey, Perl, GIMP, Equalizer APO, etc. or, closer to home, the Okapi Framework, which includes Olifant.

One or two people in the IT business might be attracted if some elements of Studio were open sourced. Who knows, maybe even one or two members of the Okapi Framework.

I will tell you what was in the back of my mind when I accidentally set off the storm.

I recently ran across an open-source project that is different from the ones I have seen before: Asuswrt Merlin firmware for ASUS routers.

Yes, I know that Studio is massively larger in scale than a Linux-based router firmware. The reason I mention this project is that the process used seemed different to me.

Eric Savageau advertises himself as an "IT consultant and computer psychiatrist. Asuswrt-Merlin developer." So he is probably using this as a hobby/showcase project, which also probably applies to many other open-source projects.

And this caught my eye about the project itself: ASUS has made parts of the firmware open-source, not all of it.

Savageau's primary goals for Asuswrt-Merlin are "to enhance the existing firmware without bringing any radical changes, and to fix some of the known issues and limitations, while maintaining the same level of performance as the original firmware.... New feature addition is very low on the list of priorities for this project."

ASUS monitors the project and apparently implements some of the changes into their own stock version over time. So ASUS is open to and actively involved in this interesting form of collaboration that somehow benefits everyone. ASUS probably also monitors the forums to keep track of what problems are being discussed.

So, I was thinking about this interesting process that provides users with a choice between two very similar firmwares. The similarity makes it easy for users to switch back and forth between the two versions whenever they want. It also makes it easy for changes in either version to be incorporated in the other, so it is easy for ASUS to incorporate improvements made to the Asuswrt-Merlin version into its stock version. And it is easy to adapt the Asuswrit-Merlin version to changes in the stock version.

When I recently bought new ASUS routers, I initially used the stock firmware, but quickly noticed problems with the quality of service features. That led me to the Asuswrt Merlin forums, where exactly the same problems were being discussed. Apparently many routers suffer from it. Luckily, someone had written a workaround script, and the problem was solved when I installed the Asuswrt Merlin firmware along with this script on my routers.

So I wasn't really thinking about the COM vs .NET issue or anything specific like that.

I was just thinking in general about how some people in the IT industry seem to take on pet projects to showcase their skills and how ASUS was open to the form of collaboration that was being used in this particular open-source project.

And, yes, all of this was ultimately motivated by "me wanting to do something for myself": I would benefit if SDL somehow attracted one or two IT professionals to collaborate on a volunteer basis on improving some parts of Studio :-)

Best regards.
Bruce Campbell
ASAP Language Services

My final comment on this topic, inspired by another user in the forum just discovering that apps like SdlToolkit can process big files much faster than the Studio editor.

The reason for the difference in the time needed by SdlToolkit and the Studio editor is most likely because SdlToolkit does not have to display anything. The editor appears to hit a bottleneck when segments are prepared for display.

Of course, this bottleneck only affects users trying to work with large files. Given the small number of users that would benefit, it might not make economic sense for SDL to divert resources to eliminate the bottleneck.

On the other hand, it might be an interesting enough problem to attract an IT professional as a showcase project -- assuming the code is not a pile of spaghetti that prevents this part from being separated out.

Why do I say there is a bottleneck?

When you open a file, the segments at the beginning of the file are shown relatively quickly. But have you noticed what happens when you open a big file and then use Ctrl-End right away to move to the end? You get moved part way to the end of the file. Every time you use Ctrl-End you move a bit further, so it appears that Studio is busy creating some sort of display buffer, moving sequentially from the beginning of the file to the end. When you try to move to the end, you have to wait and wait and wait until Studio finally finishes processing to the end of the file.

Another strategy would be to start display processing at the beginning of the file, but then immediately move to the end of the file when Ctrl-End is pressed, fill enough of the buffer at the end to display the segments there, and then return to processing the remainder of the file in the middle.

If you then type, for example, PageUp to move upwards from the end of the file, Studio could again break off processing the middle of the file, move to the end again, fill the buffer there to display enough segments to satisfy the PageUp, and then return to processing the middle of the file. And so on, until the whole file has been processed.

What about when you apply a filter. Once again, Studio seems to start at the beginning of the file and work its way to the end. And it freezes up until it has processed the entire file for display, even though only a few dozen segments are displayed at any one time. An alternative, albeit more complex idea, would be to jump around the display buffer again, filling in areas that have to be displayed and then letting the user do other things while continuing to process in the background.

This might be easier to implement with multiple processes. One process, something fast like SdlToolkit, would quickly move through the file, maybe creating multiple layers for display -- but without worrying about how everything will look on the actual display. For example, imagine this process could simply create another layer and put a 0 or 1 in each segment on this layer to indicate whether it should be displayed according to the current filter. A second process could then worry about preparing the actual content to be displayed and could guide the focus of the first process if it needed to display an area that did not have the 0's and 1's yet. And a third process could handle the actual display.

I could, for example, quickly open a big file, select all segments with a status of Translated, lock them, save the file and close it again before Studio was anywhere near to processing all of the segments for actual display.

A change like this could speed up Studio in two ways. First, by removing what appears to be a bottleneck around display processing, and second by opening the door to multiple processes, i.e. using multiple cores.

In terms of SDL's economics, something like this might be a low priority.

An IT professional looking for a showcase project, on the other hand, might find changing a single-process program to multiple processes attractive -- because the economic benefits are different.

In summary, is the sort of thing that went through my mind when thinking about open-sourcing parts of the editor.

I was thinking about things that SDL doesn't appear to be focusing on anyway, might be attractive from a conceptual point of view and probably wouldn't involve disclosing secrets of value to competitors.

Best regards,
Bruce Campbell
ASAP Language Services

My final comment on this topic, inspired by another user in the forum just discovering that apps like SdlToolkit can process big files much faster than the Studio editor.

The reason for the difference in the time needed by SdlToolkit and the Studio editor is most likely because SdlToolkit does not have to display anything. The editor appears to hit a bottleneck when segments are prepared for display.

Of course, this bottleneck only affects users trying to work with large files. Given the small number of users that would benefit, it might not make economic sense for SDL to divert resources to eliminate the bottleneck.

On the other hand, it might be an interesting enough problem to attract an IT professional as a showcase project -- assuming the code is not a pile of spaghetti that prevents this part from being separated out.

Why do I say there is a bottleneck?

When you open a file, the segments at the beginning of the file are shown relatively quickly. But have you noticed what happens when you open a big file and then use Ctrl-End right away to move to the end? You get moved part way to the end of the file. Every time you use Ctrl-End you move a bit further, so it appears that Studio is busy creating some sort of display buffer, moving sequentially from the beginning of the file to the end. When you try to move to the end, you have to wait and wait and wait until Studio finally finishes processing to the end of the file.

Another strategy would be to start display processing at the beginning of the file, but then immediately move to the end of the file when Ctrl-End is pressed, fill enough of the buffer at the end to display the segments there, and then return to processing the remainder of the file in the middle.

If you then type, for example, PageUp to move upwards from the end of the file, Studio could again break off processing the middle of the file, move to the end again, fill the buffer there to display enough segments to satisfy the PageUp, and then return to processing the middle of the file. And so on, until the whole file has been processed.

What about when you apply a filter. Once again, Studio seems to start at the beginning of the file and work its way to the end. And it freezes up until it has processed the entire file for display, even though only a few dozen segments are displayed at any one time. An alternative, albeit more complex idea, would be to jump around the display buffer again, filling in areas that have to be displayed and then letting the user do other things while continuing to process in the background.

This might be easier to implement with multiple processes. One process, something fast like SdlToolkit, would quickly move through the file, maybe creating multiple layers for display -- but without worrying about how everything will look on the actual display. For example, imagine this process could simply create another layer and put a 0 or 1 in each segment on this layer to indicate whether it should be displayed according to the current filter. A second process could then worry about preparing the actual content to be displayed and could guide the focus of the first process if it needed to display an area that did not have the 0's and 1's yet. And a third process could handle the actual display.

I could, for example, quickly open a big file, select all segments with a status of Translated, lock them, save the file and close it again before Studio was anywhere near to processing all of the segments for actual display.

A change like this could speed up Studio in two ways. First, by removing what appears to be a bottleneck around display processing, and second by opening the door to multiple processes, i.e. using multiple cores.

In terms of SDL's economics, something like this might be a low priority.

An IT professional looking for a showcase project, on the other hand, might find changing a single-process program to multiple processes attractive -- because the economic benefits are different.

In summary, is the sort of thing that went through my mind when thinking about open-sourcing parts of the editor.

I was thinking about things that SDL doesn't appear to be focusing on anyway, might be attractive from a conceptual point of view and probably wouldn't involve disclosing secrets of value to competitors.

Best regards,
Bruce Campbell
ASAP Language Services

Good opinion

Personally, I think they do their best always regarding;
MultiProcessing, Concurrent, Asynchronous, Parallel, Responsive or UltraSuperNoBottleNeckFast whatever technology you named.

There is nothing customers can do.
Just wait and see.