Vilius Butiskis

http://multifarious.filkin.com

I am sorry, but I don't find this resource helpful as it does not mention TMX not once

Vilius Butiskis said:

Sad, it looks like a step back.

Hi there,

It is a step back in order to be able to take a different, more effective step forwards. My appraisal of the article is that certain functional access was based on 'old code' and had to be removed to improve speed and efficiency, but would most likely be re-added based on end user requirements, based on new, faster code.

In the article Paul gives several possible ways to open TMX files in Studio. I use the method he described last... if I receive a tmx, I always create a new memory based on the client's previous TM (so that I have any customisation instantly available) then I import the TMX into that. It's clean and quick and I can name it according to the date I received it and its context. It has the extra advantage of being the latest version so no need to upgrade. I much prefer that to adding it to an existing TM.

I'm pleased that old code-based stuff has finally been eliminated. 

All the best,

Ali

Vilius Butiskis

Vilius Butiskis said:

Sad, it looks like a step back.

I'd agree with you... but I'm pretty sure it's temporary and we will do something to address this in a future release without keeping the old code which was the priority for now.

Vilius Butiskis said:

it looks like Trados is choosing a path where the app is becoming more and more a client app like many other CATs.

You could not be more wrong.  We removed this to get rid of old code.  In terms of what we have done we are maintaining Studio as a desktop application AND making it possible to work in the cloud by synchronising them both.  I don't think any other CAT tool does this to the extent we have now and we will improve.  Becoming an app that always requires a cloud connection is not an objective.  Synchronising the two is an objective.

If returning functionality from the older version to a newer one is on the roadmap that is fine even if no new functionality for managing TMs is planned (though I have expected that). For example such trivial tasks as removing formatting tags from old TM entries without updating entry dates; extracting groups of high similarity TM entries to delete wrong ones – there were 7 iterations of Trados Studio and I still must rely on 3rd party tools or my programmed tools.

It is a relief there are other solutions (including running Studio 2019 alongside) for now. But are there any obligations for devs of those add-ons to maintain compatibility with all future updates of Studio 2021 for which I have purchased the license?

Vilius Butiskis

Vilius Butiskis said:

But are there any obligations for devs of those add-ons to maintain compatibility with all future updates of Studio 2021 for which I have purchased the license?

No.  I don't even know what applications you're referring to either.

There aren't even obligations on SDL to keep providing the features you have today.  It's unlikely we'd remove things that people use and need, but there are no obligations.

I was referring to add-ons that can be used as substitutes for removed functionality.

Thanks for explaining the company's attitude, I have nothing else to add.

Vilius Butiskis said:

Thanks for explaining the company's attitude

This has nothing to do with the company's attitude.  This is the reality of all software development the world over.  Nobody has an obligation to continue to maintain compatibility.  If it makes sense on the whole then most will do it... nobody has to.

When one buys Windows or any other peace of software there is usually a timeframe indicated until when it will be fully maintained and improved, then security maintained and finally deprecated. In this case it sounded really harsh, like we may remove features at will, may discontinue development at any moment and you should not have any expectations as a buyer. Further more feature removal was not mentioned for those who placed pre-release orders.

Vilius Butiskis

Vilius Butiskis said:

When one buys Windows or any other peace of software there is usually a timeframe indicated until when it will be fully maintained and improved, then security maintained and finally deprecated.

As there is here too... but that does not preclude any software developer from changing the way things are delivered or even if they are included at all during this period.  It's simply not possible to promise things like this so I answered your direct question.

We have deviated from the topic a lot :) thank you for your help with TMX files

Hi Alison,

In my view you are only thinking from a translator point of view. This is, a receive a new project, in one language, with one TM in TMX format and it just takes a few minutes to create a .SDLTM and import the TMX file. Ok fine.

First of all I would like to say that a TMX is NOT an old decrepated format BUT The Translation Memory eXchange standard format. This is an XML specification for the exchange of translation memory data between computer-aided translation and localization tools. Nowadays most if not all CAT/Localization tools use this format, so it allows to exchange TMs between them.

Now try to think from a LSP perspective. I am the one preparing the projects. I work with a new client and I receive dozens or hundreds of TMs in TMX format that I have to convert to .SDLTM (different specialities 25-30 languages). I receive tons of different translation projects where the client uses CMS/Tools that export the translations memories in the standard TMX on daily basis. It’s a huge waste of time creating .sdltm one by one file and importing the TMXs.

It’s not only a problem to open the TMX. We cannot Upgrade the TMXs to .SDLTM in batch mode and we can’t import the TMX format when creating a new project (In 2019 studio allow to upgrade the TMXs when creating a new project)...

I understand that SDL removes Google translator. They want to sell their platform “Be global”. But the TMX format???

Regards,

Felipe

Hi Alison,

In my view you are only thinking from a translator point of view. This is, a receive a new project, in one language, with one TM in TMX format and it just takes a few minutes to create a .SDLTM and import the TMX file. Ok fine.

First of all I would like to say that a TMX is NOT an old decrepated format BUT The Translation Memory eXchange standard format. This is an XML specification for the exchange of translation memory data between computer-aided translation and localization tools. Nowadays most if not all CAT/Localization tools use this format, so it allows to exchange TMs between them.

Now try to think from a LSP perspective. I am the one preparing the projects. I work with a new client and I receive dozens or hundreds of TMs in TMX format that I have to convert to .SDLTM (different specialities 25-30 languages). I receive tons of different translation projects where the client uses CMS/Tools that export the translations memories in the standard TMX on daily basis. It’s a huge waste of time creating .sdltm one by one file and importing the TMXs.

It’s not only a problem to open the TMX. We cannot Upgrade the TMXs to .SDLTM in batch mode and we can’t import the TMX format when creating a new project (In 2019 studio allow to upgrade the TMXs when creating a new project)...

I understand that SDL removes Google translator. They want to sell their platform “Be global”. But the TMX format???

Regards,

Felipe

Felipe Gonzalez Lopez

Felipe Gonzalez Lopez said:

I understand that SDL removes Google translator. They want to sell their platform “Be global”. But the TMX format???

Actually you're wrong on both counts.

We removed Google translator because it's no different to any other plugin on the apptore.  To be honest I've argued against that being in the product for years so I'm glad we finally removed it.  It has nothing to do with wanting to sell our own platform... in fact we offer it for free for all users up to a point (enough for freelancers never to have to pay at all) compared to Google who do not.  So now you access Google MT via the MT Enhanced plugin which we will work on to improve further as it was originally developed by a 3rd party developer many years ago and badly needs an overhaul.

The TMX format... it was accessible because it was part of the "Upgrade TM" routines so when this was removed and made part of a plugin it also went.  The unfortunate part is that when the development team completed the plugin the omission of the TMX quick upgrade was an oversight.  Try to imagine just how much was going on when all this happened... and it was missed.  Wasn't even picked up in Beta testing with real users.  It will come back.

So I think we can drop this particular part of the discussion as I'd already said we'll put it back in the verified response to this thread.

Thank you Paul

I knew you would answer this post better than I could.

Ali