Hi Sebastian,

Have you taken a look at the Tag object in the SDK documentation?  It looks like you have to create a new Tag object based on the markup sent back from your server.

Best regards,

Patrick Porter

Thank you Patrick! That does look like the plausible component, doesn't it?

What I don't know yet is what the transformation from the server response to Tag constructor arguments is supposed to look like, and even less, what processing will be needed with an XML response containing several tags.

I am already stumped one step earlier, though, in the transformation _from_ SDL elements. I have a hunch that a solution here will inform me considerably on the reverse transformation.

I have an ISegmentElementVisitor implementation like in the sample app, which doesn't yield proper tags.

The method for a TagToken looks like this at present, for instance:

       public void VisitTagToken( Sdl.LanguagePlatform.Core.Tokenization.TagToken token ) {

           _text += token.Tag; // I've tried all the operations I could think of: token.Tag.TextEquivalent, token.ToString(), ...

       }

The closest thing to a tag-like output was something like "<1 x=1 id=ph22 text-equiv="0x1"/>" (for something that in the editor looks like <field id="1" value="0x1"/>). I don't quite believe that this is what an exported tag is supposed to look like!

Have you got any idea what I am missing here?

Thanks, Sebastian

Hi Sebastian,

That is in fact what the tag markup will look like, even though the value in the editor is different.  It seems that this has something to do with the way that the tags are stored in the sdlxliff file.  There is a sort of index of the different tags, and in the underlying xml for each segment, instead of the text that you would see in the editor, the tags get an "id", if you look in the xml of the sdlxliff for that tag id, you will see a listing that contains the info.  I'm not really sure the reason for handling them that way, but if you create a tag with that same markup and other properties, Studio will handle it properly.

I hope that helps.

Hi Patrick,

I am still making progress on this matter, and I just want to thank you and let you know that your input has helped me tremendously. Now I know that that weird output is indeed what I have to work with/around (having some trouble with XML parsers choking on non-alphanumeric tags, but I'm sure I'll get there).

Wishing you an enjoyable weekend!

Hi Patrick,

I just wanted to let you know that I recently achieved my goal on this point, which together with the other solved issue (bulk processing) paved the road to a new deployed version of our plugin. And I want to thank you again: your input really was instrumental!

The "missing link" to the goal was understanding that the stringified tag really didn't contain sufficient information for rebuilding the Tag object but that I had to export the properties to the transfer document one by one, and parse & convert them again on the way back in for use as arguments to the Tag constructor.

All best, Sebastian