Processing of internal vs. structural tags
Thread poster: andboe

Local time: 01:01
May 12, 2015

Hi everyone,

I'm afraid my first post here will be a bit technical. Sorry for that. I'd really appreciate feedback though, even if it's just to confirm that I'm stuck between a rock and a hard place with my problem. Oh, and I'll be using {curly brackets} to display XML tags in this post, since I don't know how to turn HTML off.

I'm currently trying to come up with import settings for XML files produced by an authoring tool called Help and Manual.
What H&M does is put every text element in a {text} tag pair such as this:

{para styleclass="Normal"}
{text styleclass="Normal"}This is text{/text}

That may sound sensible at first, but I'm getting the feeling that this is actually a bad idea. As soon as I apply any kind of formatting within a text item, I'm creating an elaborate tag structure such as this:

{para styleclass="Normal"}
{text styleclass="Normal"}This{/text}
{text styleclass="Bold"}is{/text}
{text styleclass="Normal"}text{/text}

The way I see it, I'm left with two choices when importing the file:
  • I can either tell MemoQ to interpret {text} tags as inline. This will potentially cause an excessive number of editable tags in the translation UI, up to a point where it's practically impossible to translate efficiently.
  • Or I can tell MemoQ to interpret {text} tags as structural, which will result in useless segmentation which I'd have to correct manually.

Is this correct? If yes, are there any means in MemoQ to soften the negative effects of either approach?

[Edited at 2015-05-12 12:14 GMT]


Local time: 02:01
Russian to English
+ ...
For Help & Manual I had to use Déjà Vu May 13, 2015

andboe wrote:
...I'm currently trying to come up with import settings for XML files produced by an authoring tool called Help and Manual...

Hi Andboe,

In last November I got a good piece of work (about 800 conventional pages / 1800 characters with spaces each), which had to be done with XML files produced by that H&M application (Oh dearicon_smile.gif ).
I spent a couple of days trying every possible way to import correctly the truncated text. In vain. Then I tried the same in Trados Studio. The result was the same - nothing good.
Well, then I tried Atril DéjàVu and watched the good lesson here
Amazing, but it helped after an hour that I spent for setting right the filter. I variated options and saw the imported result. When the result became appropriate, I saved the XML-filter and used it to import all files. The only problem was that when I imported, I had to view the segments (reading quickly the segments without translation), as some dozens of thousands segments happened to be truncated because of those tags and had to be joined. Plus, some unnecessary (20-30 segments out of 4 - 5 thousand) text segments appeared. But the job is almost done - I was allowed to translate that during 6-7 months, with some additional checks from programmers.
So, try another tool for this particular job and good luck to you.


Local time: 01:01
Déjà Vu won't solve my problem May 13, 2015


thanks for the reply. I just watched the youtube tutorial you posted. I'm afraid my problem would be the same in Déjà Vu. I'd still have to decide whether {text} tags should be inline or structural.

I'm starting to believe that I'll just have to live with the lesser of two evils and set up the import filter to interpret {text} tags as inline. That way, at least segmentation will be correct.


To report site rules violations or get help, contact a site moderator:

You can also contact site staff by submitting a support request »

Processing of internal vs. structural tags

Advanced search

SDL MultiTerm 2019
Guarantee a unified, consistent and high-quality translation with terminology software by the industry leaders.

SDL MultiTerm 2019 allows translators to create one central location to store and manage multilingual terminology, and with SDL MultiTerm Extract 2019 you can automatically create term lists from your existing documentation to save time.

More info »
Anycount & Translation Office 3000
Translation Office 3000

Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.

More info »

  • All of
  • Term search
  • Jobs
  • Forums
  • Multiple search