• State Verified Answer
  • Replies 7 replies
  • Subscribers 433 subscribers
  • Views 4171 views
  • Users 0 members are here
Options
Related

XLF has no segments in Studio 2017, but parses fine in 2015

Clark Munson

XLF files from a web proxy translation tool we use are parsed fine in Studio 2015. However when I open the same file in 2017, there are no segments at all. 

I tried 'highly encouraging' it by adding translate="yes" into each trans-unit and group tag, but no change. Would anyone have any other suggestions? 

Thanks! - Clark

Here's the first trans-unit, if it helps to diagnose. (you can test by pasting this into a text file and giving it extension .xlf)

<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file source-language="en-US" target-language="es-ES" original="zejs1qho" datatype="xml">
<header>
<tool tool-id="easyling" tool-name="easyling"/>
</header>
<body>
<group translate="yes" id="zejs1qho_tm:S6V8yv0KmwDaSu8kYzyWNaP4Rn5xfPIFy+hz+piaqeY=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=" xlink:href="www.URL.com/asset.php extradata="{&quot;trimmed&quot;:false}" datatype="plaintext">
<trans-unit id="zejs1qho_tm:S6V8yv0KmwDaSu8kYzyWNaP4Rn5xfPIFy+hz+piaqeY=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=#0" datatype="plaintext">
<source>source content for translation</source>
<note annotates="general" from="easyling">Dom-Path: html:-1/head:-1/title:18/#text:0</note>
<note annotates="source" from="easyling">www.URL.com/asset.php
<note annotates="target" from="easyling">es-es-zejs1qho-p.app.easyling.com/asset.php
<note annotates="source" from="easyling">created-at: 2018-03-09 15:04:14</note>
</trans-unit>
</group>
</body>
</file>
</xliff>
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents Reply
  • 0 in reply to Clark Munson

    Unknown said:
    Is there perhaps a 'tricky' thing I could add in front of those phrases to force Studio to break the segment there?

    You can create separate TM and try to play with segmentation rules: set the " - " or " | " sequence as "before break" and see how the segmented file will look like.

    Unknown said:
    Any suggestion to get rid of those tags?

    Probably only one: let the author create SENSIBLY PARSED XLIFFs.
    The point is that XLIFFs are expected to be processed as-is, without any further "fiddling". All the "fiddling" is expected to be done during parsing of the SOURCE FORMAT, BEFORE/WHILE CREATING THE XLIFF.

    If the author of the XLIFF is incapable of making the XLIFF content sensible, then (s)he should NOT be doing that at all... and better send the original format, so that capable people can process it using sensible way.

    Seeing that "easyling", my wild guess is that it's some WordPress-based webpage translation... isn't it? :-\
Children
No Data