Detecting language please wait for.......
Hello - we have several thousand tmx files to import, but the Studio TM doesn't display the tmx file name, whether it be the actual name of the file, or a property within the tmx file. Is there a way for this info to be kept and displayed? Many thanks!
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,
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.
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 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:
And the notifications plugin is here:
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!
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.
In the meantime you might want to take a look at the AHK script Former Member created here:
He does some quite clever stuff with AHK.
This is extremely interesting - I'll be taking a much closer look and running some tests with it. My thanks to Kelly Edward!
Hi, Paul,I don't want to hijack the thread but will this plugin support TM Server or are you planning to do it only for file-based TMs? Will it be possible to import multiple files and add a different text field to each file?
Importing the same files into more than one TM in one go would also be interesting.We do import TMX often and having both SDLXLIFF and TMX in the plugin would be good. Daniel
Hi Daniel García Magariños
Daniel García Magariños said:Importing the same files into more than one TM in one go would also be interesting.
Funny... we discussed this earlier and I couldn't see the purpose of this so we simplified the UI to only select one TM. Why would you want to do this?
Daniel García Magariños said:Will it be possible to import multiple files and add a different text field to each file?
Example? The current idea is to optionally add the name of the fle and the number of the segment in the SDLXLIFF that was imported. If it was a different text field for each file that would seem unworkable for a lot of files, but maybe useful for a few. What's the usecase for this?
Daniel García Magariños said:will this plugin support TM Server or are you planning to do it only for file-based TMs?
We're currently only planning to do this for filebased TMs.
Yes, I have some use cases.
Import the same files (SDLXLIFF or TMX) into more than one translation memory:
- You keep different translation memories according to different criteria: you might have a translation memory with final translations on Automotive translations and a different translation memory for Legal translations. Then you have some TMX or SDLXLIFF files from legal translation related to automation that you want to import into both translation memories. If you could import them into both TMs in one go, it would be useful.
There can be arguments in favour and against having the same content in two different TMs, of course. You could have all the translations in one translation memory and label them properly but then the size of the translation memory is one factor that will impact Studio's performance.
- Importing several SDLXLIFF files with different text fields:
A typical situation for me would be that you have translated during the last three years manuals for different products and then you want to create a translation memory only with the manuals from the last year.
You take your final SDLXLIFF files and you want to import all of them in one go but you want to use a different value for a text field for each of them (as they are manuals for different products). For me the logical thing is not having to run the import 10 times add each time a different field. It would be more straightforward to add them to a grid (or drop them) and in the grid specify the fields and I want to use for each file and then finalise the import.
I realise it sounds much simpler than it really is and it might very well be the case that not enough users would have a need for those features, specially for file-based TMs.Daniel
We have similar situations at the OECD - as you say, there are arguments for and against this modus operandi, but it would certainly be useful to have the possibility of uploading the same tmx to different TMs at the same time.
Interesting idea! It should be fairly simple to enhance the STraSAK import feature to support multiple target TMs. I might look at this.
Unlike SDL, in the "it should be fairly simple to implement" cases I don't need to ask "why would you want to do that"... ;-)
Daniel García Magariños said:It would be more straightforward to add them to a grid (or drop them) and in the grid specify the fields and I want to use for each file and then finalise the import.
Aha... that's just too complicated and definitely NOT what one would call unattended batch processing.Specifying different fields (i.e. multiple ones) and different values for each file is definitely a too manual process... this is NOT a task for batch processing... i.e not a task for STraSAK.
Daniel García Magariños said:For me the logical thing is not having to run the import 10 times add each time a different field.
Actually, repeating the import multiple times IS a perfectly logical thing to me! ;-)
But of course only if the import itself is completely automated, i.e. NOT via some weird GUI wizard where one has to manually select (or even drag'n'drop) source and target files!
Repeating the import by simple recalling the previous command line and only changing the definition of fields/values (using some simple way, e.g. using command line parameters or some text file) is IMO the logical process.
Evzen Polenka said:that's just too complicated ... i.e not a task for STraSAK.
... but perhaps one for SDL ;-)
yes... the complicated GUIs and weird UX experts... ;-)Go for it! ;-)