Michaël Temmerman

Does it look like this:

Or this?

The second one has not been fully segmented and only contains the source.  In this case Studio will open it like this:

The first one is already segmented, so Studio has no choice but to do this:

By the way, I manually deleted all the <target> segments in my xlf file and tried to open that in Studio. I was hoping that it would work correctly like that, but the problem remains. Studio simply does not segment correctly...

Michaël Temmerman

Michaël Temmerman said:

I was hoping that it would work correctly like that, but the problem remains. Studio simply does not segment correctly...

Then you are doing something wrong.  I tested and it works like this for me:

As opposed this:

These are the files I used:

<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en-US" trgLang="fr-FR" version="2.0" >
  <file id="com.liferay.journal.model.JournalArticle:1130917">
    <unit id="title">
     <segment>
      <source><![CDATA[Sentence one. Sentence two. Sentence three.]]></source>
      <target><![CDATA[Sentence one. Sentence two. Sentence three.]]></target>
     </segment>
    </unit>
  </file>
</xliff>

<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en-US" trgLang="fr-FR" version="2.0" >
  <file id="com.liferay.journal.model.JournalArticle:1130917">
    <unit id="title">
     <segment>
      <source><![CDATA[Sentence one. Sentence two. Sentence three.]]></source>
     </segment>
    </unit>
  </file>
</xliff>

Make sure you are creating the project from scratch with the adapted file.

I also note that your XLIFF is actually XLIFF 2.0 where CDATA is allowed, but definitely frowned upon.  It's a lazy mans XLF and difficult to handle for localization.

Michaël Temmerman said:

Is this something Studio cannot deal with then?

Studio can deal with it if the file is prepared correctly.  No different to any other tool that's capable of handling XLIFF 2.0... and there are not many!  In fact you may find other tools wouldn't offer you the segmentation for a source only XLF either as they will treat each translation unit as a segment.

Hi Paul,

Thanks for helping out. I really don't know what to do anymore. I have tried so many options, but none of them work. Whenever I open this xlf file in Studio, the big segment in the second half of the page always comes out as one big segment in Studio, even though there's quite a bit of text there.

So this is the useless result in Studio:

I've tried to play around with options for embedded content as well, but none of those seem to make a difference. Any further tips will be much appreciated, as I have run out of ideas and really need to be able to handle these files efficiently, as there will be many of them.

Best regards,

Michael

Michaël Temmerman

It's not a Studio problem.  It's a problem of how the XLIFF has been put together.  Embedded content won't help you here at all.  The solution for you is to delete the target element completely.  Not just the content of the element, but the entire element.  Seeing as your source is the same as the target this shouldn't be a problem.

But if that won't work for you for some reason, you could try creating a custom XML filetype for this and translating the target element only.

That seems to work quite well with my test file:

I put my setting file here so you can give it a try:

xliff2.0alternative.zip

Hi Paul,

I understand that the xliff my client sent me is not really the way it should be. I will definitely pass on your message. But chances are I will still have to deal with this kind of file.

Your settings file is a major improvement, but it still does't segment correctly  where there are tags: <p> and <h2>. Is there a way around that? Can I create an extra rule somewhere to make Studio recognize the tags </p> and </h2> as the end of a segment?

I tried to add two segmentation rules at the TM level (to make Studio consider </p> and </h2> as break characters, but that messed the whole thing up even worse than before ...

Thanks again for your valuable help!

Hi Paul,

I understand that the xliff my client sent me is not really the way it should be. I will definitely pass on your message. But chances are I will still have to deal with this kind of file.

Your settings file is a major improvement, but it still does't segment correctly  where there are tags: <p> and <h2>. Is there a way around that? Can I create an extra rule somewhere to make Studio recognize the tags </p> and </h2> as the end of a segment?

I tried to add two segmentation rules at the TM level (to make Studio consider </p> and </h2> as break characters, but that messed the whole thing up even worse than before ...

Thanks again for your valuable help!

Michaël Temmerman

Michaël Temmerman said:

Your settings file is a major improvement, but it still does't segment correctly  where there are tags: <p> and <h2>. Is there a way around that? Can I create an extra rule somewhere to make Studio recognize the tags </p> and </h2> as the end of a segment?

Of course.  I don't have your file so just created the basics.  Now you need to enable embedded content processing and create the rules you need.  Simple task, and will actually be quite neat like this.

Hi Paul,

OMG, I can't believe it's finally working. Thanks so much. You're amazing.

If this can help other people too, as it seems it has been a problem for many in the past: I just activated the option Process embedded content inside CDATA element with HTML embedded content. 

Thanks again!

Best regards,

Michael

Hello Paul,

I hope you don't mind me asking again. The client came back to me saying that Studio has put coding in the target segment that their software can't deal with. And their software doesn't even know how to handle the tags anymore that were put there by itself to begin with.  Do you think there is a way around this?

This is the end result for the client:

Thanks so much already for your help.

Michael

Michaël Temmerman

Michaël Temmerman said:

And their software doesn't even know how to handle the tags anymore that were put there by itself to begin with.

That's hilarious!

Michaël Temmerman said:

Do you think there is a way around this?

Yes.  Don't put the tags there in the first place if they are not required.  Really... you need to throw this back at your client.  If you can't then you should pre-process the files to remove all the embedded content tagging before you handle in Studio.

Thanks. I'll talk to the client and can only hope that she can somehow deliver the texts in a different format.