You are currently working on UAT 

Recognising HTML code in XML attributes

Hi,

Is there a way to have Studio recognize embedded HTML inside XML attributes (not elements)? If I add the attribute name as an element, the text does not show up for translation. If I add it as an attribute, the text does show up for translation, but the HTML codes are not recognised as such as I then can't add the structure information for the embedded content processor. Any help would be much appreciated.

Best regards, Lieven

Example:
<TemplateText name="TemplateText10583" width="100%" height="100%" htmlText="&lt;HTML&gt;&lt;BODY&gt;&lt;P ALIGN=&quot;left&quot;&gt;&lt;FONT SIZE=&quot;12&quot; COLOR=&quot;#2e2e2e&quot; LETTERSPACING=&quot;0&quot; KERNING=&quot;0&quot;&gt;&lt;FONT SIZE=&quot;18&quot;&gt;&lt;B&gt;Sample text that would need translating. &lt;/B&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;" />

  • Actually it's rather something like "anything that a piece of software is unable to do, but logically should be, e.g. by the nature of the existing settings or other logic implied by the usual usage of existing features".

    Users don't care if the problem si caused e.g. by a typo or wrong condition in code (i.e. a real bug by your definition) or simply by "oh, the author has not thought about that possibility" (i.e. bad design or simply limited imagination/knowledge).
    So from this simple, transparent and common-sensical perspective is the inability to parse HTML from attribute content clearly "a bug"... simply because there are no technical reasons why it should not work, there is no clear clue suggesting (or documentation saying) that it should not work... so users logically expect it to work.

    An "enhancement" would be e.g. implementing full embedded content processing to Excel parser. Such functionality is currently not there at all (the existing regex processing is kind of part of the Excel parser, it does not use the generic embedded content processors), so yes, implementing this is an enhancement.
    But once it's implemented, it will be expected to work on ANY content which the Excel parser is able to extract (or, if there would be any technical limitations, or if only partial functionality will be implemented, it will be expected to be clearly documented). Users are not interested in excuses like "the developer never intended (read: has not though of) to parse HTML from an ActiveX control caption".

    The point i sthat we are not talking about 20 EUR shareware produced by someone in his spare time, we are talking about 2k+ EUR software produced by "industry leader". So I guess it's not that much that users paying so much money expect a "logically implied" functionality.

  • If a piece of software was not built to handle a particular scenario then its failure to deliver cannot be termed a bug. I agree with you that it makes complete sense for it to behave in the way you (and probably every person who has to handle files like this, myself included) would like but the fact is the original implementation was never built with this in mind. You may think it's splitting hairs to call it an enhancement but it's not. It makes a difference in where it sits in the priority of work because fixing something that is broken is a lot different to adding something that was never there in the first place.

    There is definitely unexpected and illogical behavior here, especially around the selection of XPath versus the named element/attribute, although I can see why the XPath would not be restricted in the same way. This is a bug in my opinion since Studio automatically assigns the context of Tag to an attribute so it should do the same thing even when creating a custom XPath rule. That would at least make the behaviour consistent until the filetype is enhanced (if it is!) to support the use of embedded content within an attribute.

    The cost of the software is completely irrelevant. Just because software is commercial doesn't automatically make it immune to the problems of software development in general. But of course you do have a right to expect more and a right to make your requests heard. In this case it would be a good idea to create an idea to support the enhancement of the filetypes so they handled embedded content in an attribute. You don't have a support contract, but you do have the ability to make suggestions in the appropriate place. I'd like to see this too so I created one you can vote on:

    community.sdl.com/.../support-handling-of-embedded-content-in-xml-attributes

    Paul Filkin | RWS

    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

  • Paul said:
    It makes a difference in where it sits in the priority of work because fixing something that is broken is a lot different to adding something that was never there in the first place.

    Hehe, this different prioritisation is precisely one of the reasons why I refuse to call such things enhancement.
    Because the fact that it was never there is actually the bug ;-) And that's why it's not adding NEW functionality, but adding something what should have logically been always there... Do you feel the difference? ;-) I bet you personally do... but for some reason I don't believe the "prioritisation commitee" does... which effectively makes such "enhancement requirement" stillborn :-\

    And I feel basically the same about the suggestions in Ideas section :-\
    Plus, the evaluations of the ideas seem to be done in quite weird way - I just quickly went through a few ideas marked as Delivered and sorted by the highest score and majority of them were simply NOT delivered, but just incorrectly understood (and subsequently marked as delivered). Another bunch of ideas is "solved" by recommending to use some 3rd party plugins/apps :-\. And I'm wondering how many of the maybe hundreds(?) of ideas submitted in the last year(!) were REALLY and FULLY implemented...

    And that's where the cost of the software of course starts to matter... While one would really not expect much from a spare-time "fan programming" one-man project, the expectation is dramatically different when one pays lot of money AND the product claims to be industry-standard created by industry-leader, backed by big company's numerous development teams. Then one simply expects to get something back... But, looking through the forums, basically anything what goes beyond trivial things like resetting Studio profile or using the appropriate file type and/or filetype setting options is just left unsolved for years... :-\
    Eventhough I may understand various aspects from "the other side of the story", I still have the right to feel frustrated and perhaps also somehow betrayed...

  • Hello all, , ,

    I had the same issue, and I resolved it with the following:

    Having done this, html control characters have been converted to tags.

    And this is the XML:

    Cheers!

    Pavlos

    Pavlos Ponos
    Localization Engineer

    Tell the world.

    NLG GmbH
    +30.2310.502.192 ext. 6259         
    NLGworldwide.com

    Follow us on LinkedIn | Visit our New Website

  • I had the same issue, and I resolved it with the following:

    Hi

    I think you are just handling the elements and not html code inside an attribute.  That's the problem.

    Paul Filkin | RWS

    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

  • Hello ,

    This is the closest thing I can consider in these cases, at least it works in my case.