First of all, my apologies for not responding sooner, and my thanks for all your replies and suggested avenues for exploration. 

A little context: 

At the OECD, we've been using Multitrans for the last decade, complemented by Deja Vu, which arrived about 5 years ago. The only way to share resources between the two tools is by .tmx. Our Multitrans corpora contain many thousands of file pairs, and so we've been aligning these using Align Factory for use with Deja Vu, or for our external translators to use with whatever CAT tool they have - which is how we have ended up here!

We're switching our two tools for Studio in the near future, and of course need to transfer all our current resources. Some of the TMs are going to require importing several hundred tmx files, which is why we were hoping to be able to batch-import, preferably using the filename itself, to avoid a) modifying the metadata of each .tmx file, or b) entering the metadata for each .tmx individually at the moment of import. 

I hope this sheds some light, although it is starting to look like we're no going to be able avoid using the metadata fields, and modifying the metadata for each one....any other ideas most gratefully received!

Many thanks again,

Lucy-Jane

Question is, WHY do you need/want to have each translation unit marked with the filename it comes from... because such thing does NOT happen during the standard translation workflow anyway.
When importing bilingual content at the end of translation workflow into some mater TM you can mark the imported translation units by updating a user field in the TM, but this happens for the entire imported batch, not for individual files... unless the size of the batch is a single file, of course.

So, are you saying that you did not build any TM during the past decade, so the only thing you have now are the TMXs for individual aligned file pairs? That sounds weird...

In any case, modifying the metadata for each individual TMX can be of course done programmatically, so you don't need to do it manually.
But you need someone with some programming/scripting skills to create such tool for you... Or you can check if some of the tools from OKAPI Framework has such capability.

I could add such functionality to STraSAK, but as mentioned above, there is a fundamental SDL documentation missing, so until SDL fills the missing pieces of information, no progress in this are.

Question is, WHY do you need/want to have each translation unit marked with the filename it comes from... because such thing does NOT happen during the standard translation workflow anyway.
When importing bilingual content at the end of translation workflow into some mater TM you can mark the imported translation units by updating a user field in the TM, but this happens for the entire imported batch, not for individual files... unless the size of the batch is a single file, of course.

So, are you saying that you did not build any TM during the past decade, so the only thing you have now are the TMXs for individual aligned file pairs? That sounds weird...

In any case, modifying the metadata for each individual TMX can be of course done programmatically, so you don't need to do it manually.
But you need someone with some programming/scripting skills to create such tool for you... Or you can check if some of the tools from OKAPI Framework has such capability.

I could add such functionality to STraSAK, but as mentioned above, there is a fundamental SDL documentation missing, so until SDL fills the missing pieces of information, no progress in this are.

Weird as it may sound, that's how it is! Multitrans is basically an indexing tool, and so is document-based, not segment-based; it compiles static document repositories (corpora), rather than TMs. It is possible to export Multitrans content to tmx format, but unfortunately has too many bugs for us to use, and the required metadata isn't exported. The nature of translation at the OECD means it is vital for translators to know exactly where each segment is coming from. 

Yes, writing a script for the modification of the metadata is pretty much the conclusion we've reached as well...we were very surprised that the file name isn't retained by Studio, given that it is retained when importing to DVX!  

Lucy-Jane Michel

I don't know what your timescales are, but we are going to start work on a small import plugin for Studio shortly.  This will support the import of SDLXLIFF files first, but we will then add TMX support.  The idea being it will optionally add the following metadata to fields in the TM:

- TU number from the SDLXLIFF

- filename

This may help you if you are unable to get a sensible approach anywhere else in the meantime.

Thank you Paul - that is very good news!

Our timescale is pretty short, as roll-out of Studio is planned for February/March, so we'll need to find a solution soon - at least for our key resources to begin with - but we're getting there. 
The import plugin with these options certainly be extremely useful for the future. I can hear the sighs of relief already!

Lucy-Jane Michel

That's great... we'll try to do this as quickly as we can.  You might also be interested to know that we are also nearing completion of an updated vrsion of the Multitrans plugin for Studio that is here:

https://appstore.sdl.com/language/app/sdl-multitrans-plug-in-for-sdl-trados-studio/1007/

The current version has some limitations in that you can only use resources attached to the project you select.  The updated version will allow you to select any resources from a Multitrans instance and use them in your project.  We are also providing separate plugins for just MultiTrans Termbases and MultiTrans TMs so that it would be possible to use them in a standard Studio project for example.

If you'd like to test them when we release to Beta let me know?  We're pretty close.

Thanks very much Paul. I believe the plug-ins are for Multitrans Prism? We're on Multitrans 6, not Prism, and phasing it out over 2020. If the plug-ins are usable with Multitrans 6, I'd be delighted to test them, if my manager gives the green light. 
Quick question: how can I ensure we're informed as soon as the import plugin is available? Is there a notification system to sign up to, or something similar?  

Lucy-Jane Michel

Lucy-Jane Michel said:

If the plug-ins are usable with Multitrans 6

No, they've been buit for the latest version of MultiTrans.

Lucy-Jane Michel said:

Quick question: how can I ensure we're informed as soon as the import plugin is available? Is there a notification system to sign up to, or something similar?  

For new apps, your best bet is to either sign up to the RSS feed, or follow #sdlappstore on twitter.  For existing apps we have a plugin which will help with update notifications as it will also download and install the updated versions.  This article might be interesting:

https://multifarious.filkin.com/2018/04/02/app-notifications/

And the notifications plugin is here:

https://appstore.sdl.com/language/app/appnotifications/1020/

Fantastic, signing up right now. Thank you, Paul! 

Paul, do you by any chance have an idea of when the import plugin might be available? I should've asked you that earlier in our conversation!

Lucy-Jane Michel

I would guess it will be available within the next month as we are working on other things at the moment.

That's great - we might even be able to use it before we roll out Studio, which would be fantastic.