Luiza Kipper

Hi Luiza,

SDLXLIFF is valid XLIFF 1.2.  But perhaps, one thing you can try is making sure you have this option checked BEFORE you create yor project:

Some systems are not capable of dealing with this and it adds additional information to the SDLXLIFF (still valid under 1.2) that they may not be dealing with appropriately.  You might need to recreate your project and pre-translate from your TM to achieve this.

I'm afraid the problem is a very different one.

The customer send her XML and is expecting XLF made from that. From what I know Studio does NOT work this way. It is always what comes in, that comes out. In this very case the customer request is not possible to fulfill unless the XML will be parsed by some tool (I would NOT know which) to XLF PRIOR to loading it in Studio.

Otherwise your hint is very valid. IMO this should be the default setting, as 99,9% of clients I know do expect exactly that: plain XLF without segmentation information.

You're right about the XLF Jerzy... not sure why I thought about that when the source was XML.  But on this:

Jerzy Czopik said:

The customer send her XML and is expecting XLF made from that. From what I know Studio does NOT work this way.

Studio works exactly this way with every format you put in there as you get a valid XLIFF file for every source file you add to a project.  It might not be a vanilla XLIFF (whatever that is!) but an SDLXLIFF is a valid XLIFF.  Very strange request though.

Sorry, my answer was misleading. I of course know very well, that Studio uses valid XLIFF during the translation, but it contains tons of extra information, which usually no customer expects. What they expect, is usually just source and target in the segment. As you say "plain vanilla XLF". And it is probably feasible to modify SDLXLIFF via regex to get plain vanilla XLF, but I'm afraid this is beyond the vast majority of translators in this world.

Maybe you know about a tool creating a XLF file from a XML file?

Jerzy Czopik said:

And it is probably feasible to modify SDLXLIFF via regex to get plain vanilla XLF, but I'm afraid this is beyond the vast majority of translators in this world.

But why would you do this Jerzy? I think Luiza Kipper should probably go back to her customer and ask for clarification on what they want and why.  It should really be down to the customer to either specify the requirements for a "strict"... ish XLF 1.2 (there isn't really such a thing) or ensure they can import an SDLXLIFF as this is also 1.2 compliant.

Luiza Kipper changing the extension won't do anything other than help the application recognise the file for it's first pass.  If it is looking for something very specific then it may not get any further.  You really should go back and get some clear insructions from your client.  Converting XML to XLIFF could also be problematic depending on what's in the XML and where the translatable text is.  It certainly seems a very strange request the way you have explained it to us.

Well, I would indeed try to manipulate the SDLXLIFF to get the plain structure

<translation unit>
  <source>text source</source>
  <target>text target</target>
</translation unit>

in the hope this will fulfill customer needs.

OTOH it should on the customer to provide the proper format for translation. Unfortunately, as we see in daily practical examples, many clients do not even have a clue of what is possible, so they create adventure-like xlfs (like Word Perfect & Co.) and throw this stuff on us translators, of whom the vast majority is overloaded by such demand.

I wouldn't encourage anyone to try this Jerzy... SDLXLIFF is a lot more complex than this and simply taking what you see in the source and target and creating a file with the structure you suggest by manipulation outside of the API could be a mistake.

If you really wanted to do this perhaps export to Excel first so the content is all correct and then create your basic XLIFF.  Or even open the SDLXLIFF in another CAT that can export a more basic XLIFF.

But really... this is a fairly crazy requirement.

It is, indeed. But you have given me a hint, how one could deal with that very easily... At least I think.

Use Legacy Converter to TMX, open that in Olifant, and you have a table - which is easy to convert to something like the XLF structure in Word.

It is, indeed. But you have given me a hint, how one could deal with that very easily... At least I think.

Use Legacy Converter to TMX, open that in Olifant, and you have a table - which is easy to convert to something like the XLF structure in Word.