You are currently working on UAT 

  • State Suggested Answer
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 429 subscribers
  • Views 8777 views
  • Users 0 members are here
Options
Related

Recognising HTML code in XML attributes

Lieven Lannoo

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;" />
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents Reply Children
  • 0 in reply to Evzen Polenka
    Hi Evzen, I had never noticed this and always assumed it was just not possible, especially because Patrik advised it wasn't possible to apply embedded content to an attribute. However, I tried this just now using a sample made from the text above and it still doesn't work for me as the entities are converted, but not tagged. Can you make it work?

    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

  • 0 in reply to Paul Filkin
    Nope, doesn't work for me either...
    But I see no reason why it should not work, apart from a bug... entities get converted, i.e. a perfectly valid HTML code should be passed to the HTML embedded content processor... so there is no reason why the processor would not parse it accordingly.
    It's probably some "internal rule" that attribute value cannot be passed to embedded content processor. But from the XML perspective it's not anything "illegal"... It's weird and the 'inventor' of such structure should burn in hell, sure... but it's valid XML.

    Obviously, this is not new ;-)
    www.proz.com/.../243871-how_can_i_use_embedded_content_in_xml_attribute_text.html
  • 0 in reply to Evzen Polenka
    It's certainly not new, been like this since Studio 2009. I'm sure it's not a bug because that would suggest it should work but doesn't. You might think it should but according to the developer who wrote this code it was never intended to handle embedded content in XML attributes so it's really something that should be an enhancement request.

    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

  • 0 in reply to Paul Filkin
    Well, sounds like hairsplitting to me... ;-)
    The fact that someone couldn't imagine an attribute containing anything more than a simple text does not really excuse the illogical functionality.

    It shouldn't matter where does the embedded HTML come from... the embedded content processor should simply process the input regardless of who is passing it into it. And the XML parser should pass further whatever embedded content it's told to, regardless of where does it come from.
    That's what the GUI suggests to the user, i.e. that's what the user expects it to be doing.
  • 0 in reply to Evzen Polenka
    Of course it’s not. It’s simply a definition of what’s a bug and what’s not. By your definition anything that a piece of software is unable to do whether it was ever intended or not would be a bug.

    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

  • 0 in reply to Paul Filkin

    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.
  • 0 in reply to Evzen Polenka
    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

  • 0 in reply to Paul Filkin

    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...