Modify the tag definition rules in XLIFF (or XLF) files

Hello everyone,

I'm receiving a lot of XLF files these days and would like to know if there is a way of modifying the tag definition rules as we would do with a regular XML, or if maybe there's another way.

I need to set as inline tags some expressions like these that Studio currently treats as regular text:

<[[text_to_be_blocked]]>

{{text_to_be_blocked}}

Thank you very much in advance,

Berta

  • Hi Berta,

    You can't do this with the out of the box XLIFF filetype. I do have an unfinished Beta version of an openexchange filetype for XLIFF that allows you to do this. Drop me an email if you're interested and you are welcome to try it. It's been on our list to complete after the first round of testing got such little interest that we dropped the priority to focus on other things and just didn't pick it back up again yet.

    Regards

    Paul
    pfilkin@sdl.com

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • Hi Berta
    hi Paul,
    I have the exact same problem with .xlf files created from Drupal. I want to set as inline tags expressions such as
    [date], <p>, <br>, <\td> etc.
    So far I have worked on these files as is and gone to great pains to not overwrite or change these control characters.
    But it would be much nicer and more productive to have them as inline tags.
    I work with SDL Trados Studio 2017.
    Any shift in priority for you?
    Regards,
    Ursula
  • I strongly doubt that this will ever be changed. You are basically barking the wrong tree.

    The main point here is that the Drupal so-called XLIFFs are notoriously known to be a COMPLETE CRAP, which hardly has anything else in common with XLIFF than the file extension.

    The people who created the so-called XLIFF export in Drupal apparently had absolutely no idea about the XLIFF format and how it works...
    What they do is that they basically just enclose the COMPLETE HTML code in <source> element and put it in a file with XLIFF extension :-(. This is of course totally wrong. It's very similar to a changing a Word file extension to AVI and pronouncing it a videoclip... :-\

    So, the problem lies on the Drupal side. THEY produce crippled format. It's NOT XLIFF.

    EDIT: Attaching a sample "XLIFF" just exported from Drupal 8 - it's a complete joke :(

    JobID1_en_cs.zip

    EDIT2: Another sample saved with Drupal's "Extended XLIFF processing" option turned on. Result - file is crippled even more :(.

    JobID2_en_cs.zip

  • Hi , and ,

    We didn't change the priority because it became something the core development team tackled in the end. You can expect to see this in the next update to Studio 2017.

    Until then, the best approach, especially if these files have not been partially translated already is to handle them as XML and just translate the target element.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • Hi Paul,
    thanks for this. I am very curious then to see the next Studio 2017 update then.
    Regards,
    Ursula
  • Hello Paul, we are using Trados 2014 and are looking for a solution how to additionally define HTML tags when working on xlf files.

    It is not a bug of a CMS system, when xlf files contain html tags, this is pretty normal when developing a website within a CMS system. So we#ll need solve this and not any IT provider.

    In your post, what do you mean by treating the xlf files as XML? Could you tell us how exactly. Eg. shell we change the file extension to xml before opening and after translation back to xlf, does this really work? Or can we use some xlf and xlm.ini both together?

    How can we aditionally protect the HTML tags in XLIFF projects?
    Or more generally, how can we define aditional tags to be protected for those files types?

    Thx

    Peter
  • Treating XLF as XML is pretty easy, if your source AND target element do already contain the source.
    You develop a XML file type, where the tag "target" (xpath //target) is set to always translatable, structure and is defined as "paragraph" structure element (for example, you can define something else), while the element //* is set to not translatable.
    Then you activate processing of embedded content by a html parser for the structure element "Paragraph" (or whatever you defined). This is particularly all what you need.

    _________________________________________________________

    When asking for help here, please be as accurate as possible. Please always remember to give the exact version of product used and all possible error messages received. The better you describe your problem, the better help you will get.

    Want to learn more about Trados Studio? Visit the Community Hub. Have a good idea to make Trados Studio better? Publish it here.

  • Hey Jerzy, thanks a lot. I'm quite new to defining that so i 'll see how i manage.

    First I noticed that the <target> is empty, so i'll try to use notepad++ to populate it with the source.
    Second, the target tag is exactly <target xml:lang="fr">
    Third, and my actual problem to be solved, the text to be translated is enclosed by inline html formatting, for example lt;/p&gt;&#13;
    &#13;
    &lt;p&gt;&amp;nbsp;&lt;/p&gt;&#13;
    &#13;
    &lt;p&gt;

    or even worse

    &lt;/div&gt;&#13;
    &#13;
    &lt;ul style=&quot;list-style-type:circle&quot;&gt;&#13;
    &lt;li&gt;&#13;
    &lt;div class=&quot;leadtext&quot;&gt;brennbarer Stoff&lt;/div&gt;&#13;
    &lt;/li&gt;&#13;
    &lt;li&gt;&#13;
    &lt;div class=&quot;leadtext&quot;&gt;Zündenergie&lt;/div&gt;&#13;
    &lt;/li&gt;&#13;
    &lt;li&gt;&#13;
    &lt;div class=&quot;leadtext&quot;&gt;Sauerstoff&lt;/div&gt;&#13;
    &lt;/li&gt;&#13;
    &lt;/ul&gt;&#13;
    &#13;
    &lt;div class=&quot;leadtext&quot;&gt;

    what do you think, will your method work?
  • For duplicating text use Studio. The easiest and fastest way. Just open the file as single file project or create a project with all files. The language direction must fit. If creating a single-file project, open the file and copy all source to target. In a project let this be done in a pretranslation task (without a TM). Now your file(s) are bilingual in Studio. Go to project settings, select the File types, XLIFF file type and activate the option "Do not store segmentation in translated file"

     

    Then save the file(s) as target. This way you will have bilingual XLIFF files.

     

    In Studio create a new file type XML (embedded content).

    Give it a decent name, also name the file type identifier. In the next step chose "Create on default settings". Add the xpath parser rule //* NOT translatable, then add //target as always translatable, and in the line "Structure info" go to Edit, click on top and select "Paragraph". Next step add "xliff" as a root element.

    This way your file type will be ready. When you confirm it, go to Embedded content and select HTML 5... for "paragraph" - this should do the trick.

    We (Loctimize) can also create the file type for you, if you wish. To have it done, send the file(s) to support at loctimize dot com.

    _________________________________________________________

    When asking for help here, please be as accurate as possible. Please always remember to give the exact version of product used and all possible error messages received. The better you describe your problem, the better help you will get.

    Want to learn more about Trados Studio? Visit the Community Hub. Have a good idea to make Trados Studio better? Publish it here.

  • hello Jerzy, thank you for the support. I managed to create the billingual xliff file as you described. now I´m stuck with creating the filter.
    you wrote : "Next step add "xliff" as a root element."??
    where shell do it, is a part of the //targer parser rule or a new one?
    i`m using german software though....