Andrew James Wood

Easy enough to do this using regular expressions in notepad++, and also change the language codes at the same time.

In terms of handling this in Studio without editing the file this is not currently possible.  At least not yet... but it will be soon using a new filetype we are working on for the appstore.  Keep an eye out for a multilingual XML filetype which should be available mid-late September.

Thanks Paul

So, would changing the language code mean changing

      source-language="de-DE"

to

      source-language="en-GB" 

And after that it's just a question of swapping around

      <source> and </source>

with

      <target state="translated"> and </target>

(that's provided, of course, that all the original target units are translated and confirmed in Trados Studio)?

I've done the above with a test file, but I get the error message "Invalid structure of the trans-unit id ...." when adding the file to a project and trying to convert it to a translatable format.

Andrew James Wood

Nope.  It means putting the target content into the source elements and then renaming the language code.  If you change the order of the source and target elements then of course you will break the structure of the file.

Paul

Gah, of course!

I'll need to brush up on my regular expressions then.

Thanks!

Andrew James Wood

You'll like the new filetype when we release it... brilliant piece of work and a real timesaver for many things!

Thanks - I'll keep an eye out for it!

Paul

That sounds very exciting!

Hi ... I was actually wondering if you'd pick up on this!  It is very exciting... just a taster of the capabilities:

1. properly handle bilingual XML files as bilingual files,  So not just translation of the source by adding it into the target elements.
2. create a multilingual project from a multilingual XML and properly create a target file that pieces together all the bilingual files from the Studio project into a fully populated and translated multilingual XML
3. apply embedded content processors
4. if you use the HTML embedded content processor we added support to still apply placeholder tags to the translatable content
5. opens up the possibility to handle crappy XLIFF files in a more efficient way than the current XLIFF filetype supports
6. solves the problem Andrew raised in this thread quite nicely because you simply specific the xpath for the languages and the language direction of the project is what determines the order.  So you can tell it to handle the source as target and the target as source, and because we also allow mapping of languages to the xpath of the content we can tell it the new target is whatever language we like.  One thing we don't do is support rewriting of the language codes.  I think this is doable as well, but we may not do it on the initial release.  I'll have a think about it.

The UI is clever, and the features are very nice.  If you can think of anything you struggled to handle in the past let me know and we can take a look and see whether we can support it better while we're at it.

Hi ... I was actually wondering if you'd pick up on this!  It is very exciting... just a taster of the capabilities:

1. properly handle bilingual XML files as bilingual files,  So not just translation of the source by adding it into the target elements.
2. create a multilingual project from a multilingual XML and properly create a target file that pieces together all the bilingual files from the Studio project into a fully populated and translated multilingual XML
3. apply embedded content processors
4. if you use the HTML embedded content processor we added support to still apply placeholder tags to the translatable content
5. opens up the possibility to handle crappy XLIFF files in a more efficient way than the current XLIFF filetype supports
6. solves the problem Andrew raised in this thread quite nicely because you simply specific the xpath for the languages and the language direction of the project is what determines the order.  So you can tell it to handle the source as target and the target as source, and because we also allow mapping of languages to the xpath of the content we can tell it the new target is whatever language we like.  One thing we don't do is support rewriting of the language codes.  I think this is doable as well, but we may not do it on the initial release.  I'll have a think about it.

The UI is clever, and the features are very nice.  If you can think of anything you struggled to handle in the past let me know and we can take a look and see whether we can support it better while we're at it.

Paul

Is there a chance to beta test it?

Of course.  It's still alpha at the moment as we're still adding standard xml settings that you'd expect to see, but as soon as I have a build we're happy to go to Beta I'll let you know.

Andrew James Wood

The long wait is over... first release of this new filetype is available for 2021 SR2:

https://community.rws.com/product-groups/translationproductivity/w/customer-experience/6039/multilingual-xml-filetype

We do have some more features in the making, but have released it with SR2 as it's already a godsend!

Hello Paul !
I am trying to do the same thing but since I am in the future now the filtetype is ready! However I struggle a lot using it. When I put my Xliff files in the new project it won't recognize them as anything else but the Xliff file. I think my Xpath is correct and the languages properly added.

Any suggestion ? :)

Thanks ! 

Andrea

Test Test

Did you make sure the filetype wildcard uses *.xliff to match the extension of the file you are opening?  Other than that we'll never know unless you share what you have done by screenshot or settings file... and also a sample of your XLIFF.

I'd also recommend you start a new thread.