• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 130 subscribers
  • Views 2039 views
  • Users 0 members are here
Options
Related

Studio removing a space when adding a non translatable Xpath expression in an inline element

Felipe Gonzalez Lopez

This is a small part of the XML but it's where the problem can be found:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd"[]>
<?ish ishref="GUID-30A044EB-6781-42AA-8E66-6F2BEA18DDD9" version="20" lang="fr" srclng="en"?>
<topic id="GUID-30A044EB-6781-42AA-8E66-6F2BEA18DDD9" xml:lang="fr">
  <body cid="tDdOC">
    <strow cid="23ohnL">
      <stentry cid="2HSQLH">
        <note type="caution" id="GUID-692BEE2D-DEC3-4235-B182-192CF3F9BDCB">
          <p cid="1nxlD5">It is highly recommended to use
 <msgph varref="minoclairname">ABX <cmdname cid="t780e"></cmdname></msgph> for these cleaning operations. Refer to the Material Safety Data Sheet for handling precautions.
 </p>
       </note>
    </stentry>
  </strow>
 </body>
</topic>

After the sentence "recommended to use" there is a space I need to keep. I need the following rules among others.
ONLY the msgph elements with an attribute varid and an attribute translate="yes" should be translated. Never translate msgph elements if there is a varref attribute even if there is a translate="yes" attribute. (msgph elements always have a varid or varref attribute)

In Studio XML parser from higher to lower priority.

//msgph[@varref] : not translatable, inline, whitespace inherit from parent
//msgph[@translate='yes'] : translatable but in protected mode, inline, whitespace inherit from parent
msgph : not translatable, inline, whitespace inherit from parent

When adding //msgph[@varref] studio 2014 sp2 removes the space after "to use". It shows the lock for the msgph element as expected.I have some wordarounds like linarize the XML file or always preserve the whitespace in the p element or in the general whitespace options of the filetype but I's prefer not do it that way.
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
  • 0
    Hi Felipe,

    I'm not 100% sure I follow what you are trying to do here. Do you always want to extract the "p" element even when the "msgph" should not be translated, or do you want to ignore the "p" element too under these circumstances?

    I think that if you want to keep it but then ignore the inline elements that follow then the only way to preserve the whitespace is to use the always preserve whitespace option. Why don't you wish to use this?

    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

  • 0 in reply to Paul

    Hi Paul, 

    Thanks for your answer!

    In the example above the element p is translatable.

    When using the following rules.

    //msgph[@varref] : translatable (except in protected content), inline, whitespace inherit from parent
    //msgph[@translate='yes'] : translatable (except in protected content), inline, whitespace inherit from parent
    msgph : translatable translatable (except in protected content), inline, whitespace inherit from parent

    This is what I get in Studio.

    As you can see there is a space after "...recommended to use". The whitespace worked as expected. It replaced the space + tabs by a single space.

    As soon as I change the rules  and I put the element msgph as not translatable when there is an attribute called varref, the space is no longer there.

    //msgph[@varref] : not translatable, inline, whitespace inherit from parent
    //msgph[@translate='yes'] : translatable but in protected mode, inline, whitespace inherit from parent
    msgph : not translatable, inline, whitespace inherit from parent

    I just want to lock the msgph element that should not be translated when there is a varref attribute (client rules) but not loosing the space. As you can see the sentence is concatenated and the space is indeed needed so I want to keep everything visible for the translators.

    I see no reason why the space is removed. It's not a visual issue, if I export the file the space is no longer there.

    Preserving whitespace in an element or even in the whole file type doesn't seem to be a good idea as many times apart from the space itself there are many tabs and it may not be very nice for the translator.

    Please notice that this is just a small example, there are many files with thousand of lines.

    Thanks, 

    Felipe