Calvin F 

Just to add to the answer from Jerzy in relation to this specifically:

Calvin F said:

Is there a technical reason/limitation why it would not be possible to import a return package?

Why exactly do you want to do this?  It sounds to me as though you don't really understand how the package process works.  If you created the return package then you should have updated your TMs with the content from the project before you get to this stage... and you could still do this afterwards.  So no need to import an SDLPPX.

If you received a return package from the person you sent it to then you would just open it and this would update your project with the work done.  You review it, and when you're happy you would update your TMs from the project.  Still no need to import an SDLPPX.

So what is your reason for wanting to do this?

Calvin F 

Just to add to the answer from Jerzy in relation to this specifically:

Calvin F said:

Is there a technical reason/limitation why it would not be possible to import a return package?

Why exactly do you want to do this?  It sounds to me as though you don't really understand how the package process works.  If you created the return package then you should have updated your TMs with the content from the project before you get to this stage... and you could still do this afterwards.  So no need to import an SDLPPX.

If you received a return package from the person you sent it to then you would just open it and this would update your project with the work done.  You review it, and when you're happy you would update your TMs from the project.  Still no need to import an SDLPPX.

So what is your reason for wanting to do this?

Hi Paul.

I realize my end goal here is rather unclear since I offered no information in my original post about my reasoning; the initial response appears to have misinterpreted that I am speaking in terms of a single project here, where what I am asking would indeed be unnecessarily over-complicating things. I figured the reasoning wouldn't make a difference since my question remains the same and still boils down to whether there are technical rather than practical aspects as to why this is not an option.

Essentially, I have come across numerous types of situations where a TM would have to be updated with multiple completed projects, and the ability to import sdlrpx files would simplify this process. Currently, this means checking each package for the target language and extracting the sdlxliffs from the target language folder before importing them into the TM.

This process would be simplified if the import of sdlrpx files directly were possible. I figured I could add this possibility by programmatically checking the target-language attribute in the sdlproj file as a means of getting the correct language folder and then importing the appropriate sdlxliffs via the Studio API. I was concerned that I was mistaken that it would be this simple because I figured this would be an option in Studio already if that's all there was to it.

But this does indirectly answer my question, then. It seems it doesn't have anything to do with the technical aspect, but rather that there is no demand for this feature and what I'm trying to do is far more niche than I realized. I'll go ahead and give the code a shot then.

Thanks.

Calvin F 

From what I read you complicate this process yourself.

All return packages belong to projects, which are stored somewhere on your hdd. So just locate this projects and add target language folders in the TMX import wizard. This will import the sdlxliff files from there. No need to separate any sdlxliff files from the packages.

Calvin F 

Jerzy Czopik said:

So just locate this projects and add target language folders in the TMX import wizard. This will import the sdlxliff files from there. No need to separate any sdlxliff files from the packages.

Exactly.

Calvin F said:

Essentially, I have come across numerous types of situations where a TM would have to be updated with multiple completed projects, and the ability to import sdlrpx files would simplify this process. Currently, this means checking each package for the target language and extracting the sdlxliffs from the target language folder before importing them into the TM.

Well, I think this requirement is niche.  But you could solve it programmatically since the sdlrpx is a package, so you would just read the sdlproj to get the languages then if they match your TM import the sdlxliff files from the target folder.

I don't see this as something we would do, not even as an app, for the following reasons:

• the sdlrpx may not have had a final review (it may, but it also may not and we have no idea) so the content may not be suitable for import to a TM
• it's far easier to do this on a project by project basis when you complete them with an update TM batch task.  No need to check anything for languages etc.

I think as a tool for you then it may well be a great idea based on the way you're working.  Not too difficult either.

This is exactly what I was wondering. Thank you very much!

(I swear I don't have some super bizarre way of working I'm not a translator, but on the tech side. Currently having to deal with a lot of archived data, where sometimes there isn't a project folder but only an sdlrpx, or there is a project folder but the sdlrpx is more up-to-date, etc.)

Calvin F 

Project folder must not necessarily have the same date as the return package. The folder is usually created when receiving the project, while the sdlrpx has a date when the project has been finished.

This said I am already certain you noticed, that a sdlrpx is only a zip file. So what you would need is a program unzipping only the target folder from the sdlrpx to a defined location.