Péter Orosz 

I scan read your question quickly and it looks as though you just want to understand what the TagID is?  Normally it's just an ID code Studio gives to the underlying tags (TagID is a mandatory property of the tag object - sdlxliff is a valid xliff) in the source that are effectively placeholders used to compare source with target for QA or placeables in a TM.  It's often easier to work without wysiwyg turned on as this can be distracting when all you need to focus on as a translator (most of the time) is making sure the translation is correct and the tags in the source are placed in a location in the target that matches their location in the source.  So whether they are formatting, or anything else, is irrelevant.  It's just their placement that's important.  TagID often makes this easier, especially with very taggy files.

In practice I think you should be dealing with the process to make sure tags are handled correctly before going to review using retrofit, otherwise you are handling unfinished work before a review like this.

Dear Paul

I once was offered a Plumber Trainer position because

- I used to be a trainer at a travel agency

and

- I am also very clever with my hands, painting, gardenig, plumbing...

One of my pet peeves is HR folks scan reading my CV, then offering me totally unsuitable jobs.

(The other one is HR folks scan reading my CV, then not offering me anything at all.)

So please take your time perusing my Marvel comic book, and I’ll be waiting for your response in March :O)

***

I know what a tag ID is.

If you take a look at, say, point 4 in my example:

- tag „5” in SOURCE (in this case: bold) matches tag „5” in TARGET

- tag „11” in SOURCE (in this case: underlined) matches tag „11” in TARGET

...etc.

I wanted to find out what those „Encyclopedia Britannica-looking” long tag ID’s are doing there in 10, 11 and 15.

 Péter Orosz 

Well... I do have some sympathy with the HR folks who have a lot of work to do and often have to try and get through as many of the hundreds of speculative CV's as they can in often very tight timescales.  I also imagine your example is just another reason why AI won't be replacing humans any time soon!

However, your weird looking codes are there because your reviewer #2 added formatting changes to the Word file that are then introduced after the SDLXLIFF was already created.  Since tags are just placeholders to Studio with unique IDs the only safe thing to do is create an ID that will be completely different from anything already in the SDLXLIFF file.  So in this case Studio creates and a GUID prefixed with the word Align.  I imagine you know what a GUID is, and I don't know for sure without wasting a developers time... but Align is probably prefixed because the retrofit is a reverse alignment so it seems a sensible convention to allow a human to see why such a weird looking Tag ID might be in there.

But to answer your question again...

Péter Orosz said:

Tag ID – looks weird – should the translator understand those long codes?

No.  They are just tags.

Paul said:

all you need to focus on as a translator (most of the time) is making sure the translation is correct and the tags in the source are placed in a location in the target that matches their location in the source.  So whether they are formatting, or anything else, is irrelevant.  It's just their placement that's important.

And on this:

Péter Orosz said:

So, are 10, 11 and 15

    - some BUG that you can fix,

or    - some designed stuff that I don't understand but you now explain to me? 

Not a bug.

Péter Orosz said:

If you take a look at, say, point 4 in my example:

- tag „5” in SOURCE (in this case: bold) matches tag „5” in TARGET

- tag „11” in SOURCE (in this case: underlined) matches tag „11” in TARGET

...etc.

Because they were placed in Trados Studio by transferring them from the source.  They are not additional tags introduced from some other application.  And before you ask why we need to do that for formatting tags that are recognised in Studio keep in mind that the underlying filetype could be any of the supported filetypes in Studio, and the tags could be representative of anything... not just simple formatting.  So the use of a GUID when users operate such an illogical process ensures a consistent and hopefully error free approach to dealing with this scenario.

Péter Orosz said:

I wanted to find out what those „Encyclopedia Britannica-looking” long tag ID’s are doing there in 10, 11 and 15.

I hope this is enough of an explanation for you?

 Péter Orosz 

Well... I do have some sympathy with the HR folks who have a lot of work to do and often have to try and get through as many of the hundreds of speculative CV's as they can in often very tight timescales.  I also imagine your example is just another reason why AI won't be replacing humans any time soon!

However, your weird looking codes are there because your reviewer #2 added formatting changes to the Word file that are then introduced after the SDLXLIFF was already created.  Since tags are just placeholders to Studio with unique IDs the only safe thing to do is create an ID that will be completely different from anything already in the SDLXLIFF file.  So in this case Studio creates and a GUID prefixed with the word Align.  I imagine you know what a GUID is, and I don't know for sure without wasting a developers time... but Align is probably prefixed because the retrofit is a reverse alignment so it seems a sensible convention to allow a human to see why such a weird looking Tag ID might be in there.

But to answer your question again...

Péter Orosz said:

Tag ID – looks weird – should the translator understand those long codes?

No.  They are just tags.

Paul said:

all you need to focus on as a translator (most of the time) is making sure the translation is correct and the tags in the source are placed in a location in the target that matches their location in the source.  So whether they are formatting, or anything else, is irrelevant.  It's just their placement that's important.

And on this:

Péter Orosz said:

So, are 10, 11 and 15

    - some BUG that you can fix,

or    - some designed stuff that I don't understand but you now explain to me? 

Not a bug.

Péter Orosz said:

If you take a look at, say, point 4 in my example:

- tag „5” in SOURCE (in this case: bold) matches tag „5” in TARGET

- tag „11” in SOURCE (in this case: underlined) matches tag „11” in TARGET

...etc.

Because they were placed in Trados Studio by transferring them from the source.  They are not additional tags introduced from some other application.  And before you ask why we need to do that for formatting tags that are recognised in Studio keep in mind that the underlying filetype could be any of the supported filetypes in Studio, and the tags could be representative of anything... not just simple formatting.  So the use of a GUID when users operate such an illogical process ensures a consistent and hopefully error free approach to dealing with this scenario.

Péter Orosz said:

I wanted to find out what those „Encyclopedia Britannica-looking” long tag ID’s are doing there in 10, 11 and 15.

I hope this is enough of an explanation for you?

Well, it's a relief to hear I'm not expected to interpret those frightening GUIDs.
Cheers, accepted, don't let the bedbugs bite!