Not really... TBH it wonders me, that someone has problems with packages. I deal heavily with packages, both receiving these from clients and making my own. Until now I never have seen such error, so I strongly suppose something is wrong on her end. As we both don't know the configuration of her PC, the only viable solution is to advise her to do the following, step by step until the error does not appear anymore:

- Reset Studio (gateway.sdl.com article 2014)
- Run a repair installation of Studio via control panel
- Reinstall Studio from a freshly downloaded installer (over the current installation)
- Uninstall and reinstall Studio from the same installer
- Uninstall Studio, use Freshstart from the appstore, install again

One of these actions should bring a relief.

Hi Jerzy Czopik

I just updated my original post after looking for possible culprits again. I remember posts about problems with unicode characters - do you have experience with that?

File names like this:

Daniel

There was a bug in that respect indeed, but I would suppose it has been resolved some CU versions before. Might be, that a simple update of her installation will help. In my post I assumed, the software is fully up-to-date.

The translator contacted SDL's support (did not know she had a support contract) and they were able to help her out. The reason was that there was a TM created with a translation provider not installed on the translator's computer - that must be Record Source TM. Support removed that TM from the project and created a fresh TM.

So having a TM with Record Source TM in a project will cause an error if the other party does not have this installed?

It would be good to know this. Is that kind of thing documented somewhere?

Daniel

Unknown said:

So having a TM with Record Source TM in a project will cause an error if the other party does not have this installed?

I would expect any plugin that adds a resource to the project that gets included in the project will cause a problem if it's missing.  It seems obvious to me, and it may be documented somewhere but probably not specific to just RecordSourceTM.  AnyTM would ave done the same thing before it was added to the core product.

Record Souce TU is an add-on to Studio. It needs to be installed, when it is used. Unfortunately the variety of Studio plugins is high and one should know what is installed on own PC to make sure, the other party has installed the same. But I agree, this should not bring a package to a crash. Instead, a warning should be there, that the necessary plugins for that very package are not installed. You can post this as an idea here: community.sdl.com/.../

Hmmm, this is crazy... a clear BUG should not be recorded as "idea for new feature" :-\

Or, has the Ideas section turned to a kind of bug reporting form over the years?! :-O

I agree that this is something akin to a bug. Paul Filkin writes that a plugin that adds a resource will cause issues if that plugin is not installed on the receiving computer - but how should one know which plugins a translator is using?

There should at least be a warning when creating the package: "Warning, this package will require plugin ABC to be opened." And the error message for the translator should also say: "Error. To open this package you need to install plugin ABC."

How do I know which plugins "create a resource" for a project? Is it only about TMs and maybe termbases (IATE, TermExcelerator...)? Does anybody know which plugins have the potential to cause this kind of issue?

This is what I meant when I titled this thread "Failsafe packages - how".

Daniel

Unknown said:

There should at least be a warning when creating the package: "Warning, this package will require plugin ABC to be opened." And the error message for the translator should also say: "Error. To open this package you need to install plugin ABC."

I disagree with this.  I think the package should simply open and ignore any resources that are not available.  I'm actually surprised this doesn't happen already.

It's quite possible that a company may have created their own plugins that we know nothing about so telling the translator what they need to go and get is unlikely to have a consistent approach.  We could read the name of the plugin in use, but only if we know what it's doing and where to find this information in the project package.

I would say the best solution (irrespective of how we solve the bug part... for which we need to be able to reproduce) is for the project manager to make sure that anyone in their supply chain is using the plugins that they require them to be using before sending the package across.

Paul Filkin

Paul Filkin said:

for which we need to be able to reproduce

I will happily send you the package if that is any help...

Paul Filkin said:

I think the package should simply open and ignore any resources that are not available.

That would indeed be better. I was phrasing what I would consider the minimal solution.

Paul Filkin said:

the project manager to make sure that anyone in their supply chain is using the plugins that they require them to be using before sending the package across.

That would be which plugins? Is there a rule of thumb what plugins would be required? I can't print out my list of installed plugins and require all translators to install all - just in case...

Daniel

Paul Filkin

Paul Filkin said:

for which we need to be able to reproduce

I will happily send you the package if that is any help...

Paul Filkin said:

I think the package should simply open and ignore any resources that are not available.

That would indeed be better. I was phrasing what I would consider the minimal solution.

Paul Filkin said:

the project manager to make sure that anyone in their supply chain is using the plugins that they require them to be using before sending the package across.

That would be which plugins? Is there a rule of thumb what plugins would be required? I can't print out my list of installed plugins and require all translators to install all - just in case...

Daniel