I'm trying to define text enclosed in single or double curly brackets in an HTML file as placeholders. For example.
Translate
<p>Do not translate this {{ variable }} and don't translate that { variable } either.</p>
The following expression works fine Notepad++, but it doesn't work in SDL Studio.
\{+[^}]+\}+
1. Why doesn't the expression work?
1. What regex flavor(s) does SDL Studio support?
I created a new HTML based file type. I then selected Embedded Content.
In the Embedded Content dialog box, I enabled Other elements identified by and selected the Structure information option.
I then clicked Configure > Add, selected Placeholder and entered the regex
The information missing is how you set up the embedded content rule as this provides Studio with the information it needs so it applies your rule in the right context. For example.... I created this:
The variables are located in three different elements (h1, p and time). So for this to work I need to specify the following in the html filetype:
This is of curse assuming the variables are in elements like this. If they are within server side scripts then you need to use the appropriate "Server side scripts" option.
Perhaps this helps? For my simple test file it works just fine:
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
The same approach is required, but you need to know what the parent element would be for the script. You don't show this in your example. But this could be problematic... for example. Assume I have this:
<!DOCTYPE html>
<html>
<body>
<h1>Testing {variables} in html</h1>
<div>
<h2>{{ section.settings.text-box }}</h2>
<a href="{{ section.settings.link }}">
{{ section.settings.linktext }}
</a>
</div>
{% schema %}
{
"name": "Call to action",
"settings": [
{
"id": "text-box",
"type": "text",
"label": "Heading",
"default": "Title"
},
{
"id": "link",
"type": "url",
"label": "Link URL"
},
{
"id": "linktext",
"type": "text",
"label": "Link text",
"default": "Click here"
}
]
,
"presets": [
{
"name": "Call to Action",
"category": "Promotional"
}
]
}
{% endschema %}
<p>Do not translate this {{ variable }} and don't translate that { variable } either.</p>
<time>Testing more {{variables}} inside {variable} html.</time>
</body>
</html>
The shopify json (I know you don't have this...) is under the body element in my made up example. So I can create an embedded parser to handle it and do this:
This will get me this:
However, since this is at the body level nothing else is parsed... and this is clearly not helpful. I can't see how to get at only this script in this location without the ability to be more specific with the parser rule condition path. Maybe it's just my lack of knowledge so I will investigate this more... but so far it's a problem.
If your actual file has the variables at the body level of the html then you'll have the same problem. But what you could do is this:
1. translate the parts you need in the script.
2. Save the target file
3. remove the rule and translate the target file in the normal way with just the html file
So two passes, but it would work.
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
ok Hans Kröger
It is difficult because the html parser is based on looking at files that are ordered with text always coming inside the elements.
The embedded content parser looks at what's inside the elements and treats them as text which is what allows you to handle your variables.
If you now inject script outside of these elements then you can only define an embedded processor to handle the content between the highest parent element... in your case the <html> element by the sounds f it. So in effect you are now saying treat the entire file as text and you'll define the rules for everything.
This will be quite tricky but if you're happy to handle everything as placeables it's easy enough:
Gets you this:
It's not too bad because structural elements will be moved out and you won't make a mistake. Inline tags, which I don't have in this example will be trickier since they won't be handled as opening and closing pairs and the translator will have to be very diligent to make sure they are placed in the right order.
Frankly, I think that if this type of file is something we're going to be seeing more and more of then it would be worth developing a filetype to handle this sort of embedded content in a different way. Perhaps you should raise this here and see if anyone else thinks it's a good idea:
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
