Markus 

Markus said:

Trados seems to randomly set segments to Confirmed that were not confirmed in XTM.

I'd be surprised if this was random... I'm sure there is some logic in how the statuses are being handled.  Presumably you are handling XLIFF files from XTM if they contain this level of detail and they change, so have you mapped them in the settings?

That's why I said "seems" ;) I have the exact same options as in your screenshot, would you have any other ideas by any chance? Thank you

 Markus 

Markus said:

I have the exact same options as in your screenshot, would you have any other ideas by any chance?

Only one... what did you actually choose and why? I only showed the interface, I didn't show what options I used and these will depend on your needs.  For example when I select the dropdown there is a list:

Each one of these can correspond to something I can set in the Studio status dropdown.  So what did you use to set up your XLIFF mapping and why?

For example, in the online help here you can find some info: docs.rws.com/.../configuring-xliff-file-types

The instructions provided describe the settings for managing segment status mapping when working with XLIFF files in Trados Studio. To better understand these settings, perhaps this is helpful?

File opening: This setting configures the correspondence between the XLIFF status and the Studio status columns when opening an XLIFF file. It ensures that the target content statuses are correctly mapped according to the selected values in each column when importing the file into the translation tool.

File saving: This setting is similar to the file opening setting but applies when saving an XLIFF file. It establishes the correspondence between the XLIFF status and Studio status columns based on the selected values for each column. This ensures that the target content statuses are correctly mapped when exporting the translated content back to an XLIFF file.

Segment locking: This setting is responsible for applying a lock operation on segments with a specific status that has been checked. Locking segments prevents any further editing, which can be useful for maintaining the integrity of translated content that should not be altered.

Map state-qualifier attribute values when reading file: This setting creates a correspondence between segment states in the Studio Editor and the state-qualifier attribute values in the source XLIFF file. This mapping helps maintain the original segment statuses when importing the XLIFF file into the translation tool.

Map state-qualifier attribute values when writing file: This setting establishes a correspondence between segment states in the translated target file and the state-qualifier attribute values. This mapping ensures that the segment statuses are properly maintained when exporting the translated content back to an XLIFF file.

These settings are essential for managing segment status mapping when working with XLIFF files in translation tools. They help maintain the integrity of the translation process by preserving the original segment statuses and ensuring the appropriate handling of segment locking.

So, if you used the defaults then there is a good chance they are not delivering what you need based on the source XLIFF files you are getting from XTM.  If you can share an example XLIFF from XTM that is giving you problems then we may be able to support you better in working out how you should configure these options to suit your needs.

Thank you, Paul - unfortunately I don't have any experience with these settings as I never had issues with XLIFF files in any Trados version. I believe the issue is somehow created on XTM's end, but their support hasn't gotten back to me in days.

Can you please let me know how I could share the files from XTM with you, I wouldn't want to do so publicly?

Thank you again

Markus 

Of course... you can send them to pfilkin at sdl dotcom

Thank you, Paul - I just sent the email!

 Markus Meuter 

Thanks for sending me the file.  I looked through it and there are only three states used within the entire file:

no state at all
translated
signed-off

These are mapped as these respectively:

not translated


translated


translation approved

These are the only mappings that are possible with this file.  The reason you perhaps think it's random is because of this sort of thing that is actually in the source file itself:

or this:

The alt-trans match-quality attribute is tool specific and we don't use this.  If you do, by using the option to map the state qualifiers, then you'll get a value in there as I have shown in the screenshots above.  In this case for every "exact-match" you'll get a 100% match, and for every "fuzzy-match" you'll get an 80% match as this is the hardcoded value that Studio will place on it.  There is no mechanism to use the alt-trans "match-quality" value at all.  So you may see different percentages in the file but they won't be used.

So... in relation to your question here:

Markus Meuter said:

is there any way to import the files with the exact same segment status?

It already does.

Markus Meuter said:

The issue is that the files contain many fuzzy and out of scope 100% matches as well as unedited MT from the client

There is nothing in the XLIFF that Trados Studio can use to see this.  There are more state qualifiers available to XTM that might be helpful, for example:

http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#state-qualifier

But the only ones used in your file are these:

leveraged-tm
fuzzy-match
exact-match
leveraged-inherited
x-fuzzy-forward
x-alphanum
x-numeric
x-measure

The last four are custom extensions so we would not recognise these anyway, but none of them relate to being able to identify the things you have mentioned here (fuzzy, out of scope 100%, unedited MT).

So, that's your problem as far as I can see.  Nothing we can address without two things:

1. a new filetype based on supporting XTM specifically with all their custom extensions, and
2. information being available in the file that we can then use to identify what you want to use it for

I hope that helps to explain things a little... but maybe not quite as straightforward as you'd hoped?

Thank you for the extensive reply, and my sincere apologies about the confusion. I was searching this post for 30 minutes yesterday, but could not find it via Search or the notifications area.

Markus 

No worries... did the reply help?