SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL Speech to Text
SDL Managed Translation - Enterprise
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Tridion Docs Developers
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL Contenta S1000D
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
Does anybody know how selecting CDATA section text in the starts-with() function works when writing XPath-based parser rules?
I've been trying to test this using the following XML and I'm having no luck:
I tried writing a parser rule that selects <value> elements if the <key> element starts with the letter 'a'. I wrote the following XPath query as a test:
This should work - in fact, every other XPath processor I've tried here returns the correct nodeset. For example, here's XPath Visualizer:
But when used in an XML parser rule, the query returns absolutely nothing.
Here's the parser rule:
Here's the result - there are no segments:
I've also tried selecting the text node on <key> elements instead:
Neither of these work either.
Is this a limitation of the starts-with() function in Studio? Or does anybody know how Studio expects these types of nodes to be selected? I'm running out of ideas here!
Thanks very much.
Hi David Smallwood
I know it's not ideal, but could you add an attribute to the elements you want to translate in pre-processing, then parse for that attribute in Studio and finally remove the attribute…
Thanks for your suggestion!
I think there's no getting around having to modify the XML in some way to work around this issue in Studio 2017 and your suggestion is probably the cleanest way…
It's embedded content so you need to use the embedded content processor. This article will explain:
Thanks for your response, but in this particular case, the node containing the CDATA section is part of a predicate in the XPath query, not the node to process for translation, so it won't be ran through the embedded content processor.
As a workaround, I've stripped the CDATA section syntax from the necessary elements so that the predicate works as expected. This is OK in my particular case but is not an ideal solution, especially if the content in CDATA section contains reserved XML characters. It would be great if anybody knows a way around this!
By bad for not reading your post completely. Sorry.
I can verify your find and I think it should work as I think starts-with is an xpath 1.0 feature (I believe fn: was introduced in xpath 2.0 and this is not supported). I eacalated to the filetype manager for more information.
In the meantime do you have to use this method for finding hat you need or can you apply something else? I don't know how much of an example to illustrate starts-with you used compared to the real life requirement. For xample this works:
Perhaps the real data could work in some way like this?
Thanks for your help with this, Paul - much appreciated!
Whenever I've come across this behaviour in the past, I've always been able to do exactly what you mentioned and use the contains() function instead, but I've been working on a file this morning where the only option would be to use starts-with(). Using contains() in this particular case would pull through parts of the document that shouldn't be translated.
As I say, I was able to workaround this particular case by removing the CDATA syntax from the affected elements, so I have managed to work around this in the meantime. I've also noticed that if the element doesn't contain a CDATA section, the starts-with() function works as expected, so it's definitely only happening with CDATA sections. I'll be interested to hear what your filetype manager thinks though!
EDIT: I should also clarify that I'm using Studio 2017 SR1!
I haven't heard from the filetype manager yet but the support team tested the file with the Beta version of SR2 due for release fairly soon. It works in there... so the fastest fix for sure will be in that.
David Smallwood said:EDIT: I should also clarify that I'm using Studio 2017 SR1!
Just noticed this... it's unlikely it will be fixed in this version. 2019 SR2 has a completely new XML filetype capability and this will not be made available for older versions of the software.
Completely off topic, but can you share what is the new XML file type capability offered in SR2? Thanks!
Hi Naoko Jones
I just added you to the Beta... you can check the discussion in that group and also try the Beta out.
How can I join the Beta for that? I am very interested.
I have added you so you should find the group is available to you in your "My Groups":
If you don't see it just log off and on again.
Thanks for looking into this, I really appreciate it. Like others have suggested, although we're not currently using Studio 2019 here, I would be very interested to join the beta group to see what changes have been made to the XML file type!
I have also added you to the Beta group. Look forward to your feedback in the Beta community.
Excellent, thanks Paul.
Would it be possible to join the beta? We have a few larger XML-based projects coming up and I'd be interested to know how the XML file type has changed.