Incompatibility between two identical memories regarding field settings (only difference being some fields in one are multiple and not in the other one)

We have been using several memories with a defined set of Field settings for a while. We recently realized that two of those Fields were not multiple so we decided to create a new identical memory in which we changed those two fields to Multiple. Now, when we try to use and update in the same project one memory created with the original Field settings and another one created with the new Multiple Field settings, we cannot modify all fields. If the Update box is checked for both memories some fields disappear, if we uncheck the Update box of one of the memories, all fields are available and we can add them. Why isn´t it possible to use and update both memories and keep all the fields? If it´s two different memories, why cannot Studio treat differently the Multiple setting in each of them? Apart from recreating all the original memories by modifying the Multiple setting, is there another easier solution to be able to update both memories (old template and new template) with all the fields? See images attached.
Thanks for your help,

Beatriz

Trados Studio Translation Memory Settings window showing a problem message indicating fields cannot be edited because the translation memory is open in the maintenance editor.

Trados Studio Project Settings window with a focus on the Update checkbox for new and original translation memories, highlighting that some fields disappear when both are checked.

Trados Studio Project Settings window showing the Update checkbox unchecked for the original translation memory, allowing all fields to be visible and editable.
  



Generated Image Alt-Text
[edited by: Trados AI at 8:04 AM (GMT 0) on 29 Feb 2024]
emoji
Parents
  • I wanted to add an extra problem I just discovered in case somebody can help. If I try to import into a memory based on the new "Multiple" field settings (still identical fields and values -if it is a list- though) an original memory or .tmx which contains some of the same fields/values (just not Multiple), the import fails either completely or partially (only part of the segments are imported, the rest is just errors without an explanation of what caused the errors). Any ideas why? Again, I am importing segments with certain Fields that may contain just one value (either text or list) into another memory with the exact same fields but the setting to allow multiple values. Thanks.  

    emoji
  •  

    I created my own mock scenario where I had:

    TM1 with custom fields type text
    TM2 with custom fields type text multiple

    You are absolutely right, the update UI options go wrong at this point. Because the custom field names between the 2 TM's are all the same but the field type is different.  
    For this my collage  will review with support/development and hopefully give you a reference number or some additional information. 

    However if both TM's have the same field type (text or multiple) - then it seems to work for us.
    So this issue seems specific to when the custom fields are the same but have different types. 

    Putting this odd behaviour to one side,may I ask why create a "duplicate" TM with the only difference being the field type?
    Is it your long term goal to maintain both TM's moving forward?

    Without knowing your reasons, had this been me -  I would have simply changed the field type and remain using 1 TM.
    It would not be my recommendation having 2 TM's practically the same and both enable for update.

    If you could expand what your long term goal is when it comes to these 2 TM's then I maybe able to offer you best practices or practical advice that will prevent the need to manage 2 TM's that are practically the same. Not only could you be compromising your leverage by having "duplicate" translations, it could make PM and template management fussy onto of additional database maintenance effort. 

    Looking forward to your thoughts and comments, as well any updates from  

    Have a good evening

    Lyds

    Lydia Simplicio | 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

    emoji
  • Thank you for your reply Lydia.

    I think you are right. The problem is the field type (multiple or not) since we have been using and simultaneously updating several TMs with the same fields and types for years without problems, and we are also able to import the content of several TMs into one without errors or lost segments.

    So this is the situation. We (a few hundred translators and the number will increase) use translation memories that have all been created using a template that contains several customized fields and values (some text, some list). When that template was originally created, no much thought was given to the field type (multiple or not) since the TMs would just be used locally by the translators. Therefore, most or all of the fields are not multiple. The translators manage their own local memories, create their own local projects (not the PMs) using customized project templates and always add standardized metadata using those fields and values (this information is very important and we want to keep it). Unfortunately, we don´t have access to a server solution or server-based memories right now (and that won´t change for a while), so in order to share our content (we work in teams for the same clients and we often share projects), we decided to merge the content of all individual translators TMs for each team into 1 global team TM that is then shared with all the members, who add it to their projects for consultation purposes (not update). And that´s where the problem lies. Since the TM does not accept multiple values, when we import identical segments that have different values (translated by different translators, for different clients, in different projects), only one value is saved (I assume the first or the last to be imported). That´s why we created the same translation memory but just changed the field type to multiple, so that all values could be kept. We would have loved too to provide the new TM template (allowing multiple values) to translators currently using Studio who need to create new TMs and to those who are just starting to use Studio and need to create all their TMs.

    It is not possible to take the existing TMs and change the field type to multiple because all the exiting values are lost forever. Studio warns you about that data lost, I tested it, and indeed all my TM existing values were gone.

    It is not feasible to ask our translators currently using Studio (several hundred) to export the content of their TMs (between 3 and 25 each), create new memories with the new TM template and reimport their content into them (not even sure if that would work given the import problems we encountered) . It would be extremely time-consuming and risky.

    So it seems that we are stuck with our original TM template (no multiple values) for both our individual TMs and global TMs.

    Any advice would be welcome. I would also like to understand why the import (of content of memories with no multiple values into a memory allowing multiple values) does not work.

    Thanks in advance.

    Beatriz

     

    emoji
Reply
  • Thank you for your reply Lydia.

    I think you are right. The problem is the field type (multiple or not) since we have been using and simultaneously updating several TMs with the same fields and types for years without problems, and we are also able to import the content of several TMs into one without errors or lost segments.

    So this is the situation. We (a few hundred translators and the number will increase) use translation memories that have all been created using a template that contains several customized fields and values (some text, some list). When that template was originally created, no much thought was given to the field type (multiple or not) since the TMs would just be used locally by the translators. Therefore, most or all of the fields are not multiple. The translators manage their own local memories, create their own local projects (not the PMs) using customized project templates and always add standardized metadata using those fields and values (this information is very important and we want to keep it). Unfortunately, we don´t have access to a server solution or server-based memories right now (and that won´t change for a while), so in order to share our content (we work in teams for the same clients and we often share projects), we decided to merge the content of all individual translators TMs for each team into 1 global team TM that is then shared with all the members, who add it to their projects for consultation purposes (not update). And that´s where the problem lies. Since the TM does not accept multiple values, when we import identical segments that have different values (translated by different translators, for different clients, in different projects), only one value is saved (I assume the first or the last to be imported). That´s why we created the same translation memory but just changed the field type to multiple, so that all values could be kept. We would have loved too to provide the new TM template (allowing multiple values) to translators currently using Studio who need to create new TMs and to those who are just starting to use Studio and need to create all their TMs.

    It is not possible to take the existing TMs and change the field type to multiple because all the exiting values are lost forever. Studio warns you about that data lost, I tested it, and indeed all my TM existing values were gone.

    It is not feasible to ask our translators currently using Studio (several hundred) to export the content of their TMs (between 3 and 25 each), create new memories with the new TM template and reimport their content into them (not even sure if that would work given the import problems we encountered) . It would be extremely time-consuming and risky.

    So it seems that we are stuck with our original TM template (no multiple values) for both our individual TMs and global TMs.

    Any advice would be welcome. I would also like to understand why the import (of content of memories with no multiple values into a memory allowing multiple values) does not work.

    Thanks in advance.

    Beatriz

     

    emoji
Children
  • And I have another related question.
    One of the latest improvements in Studio is the fact that when you have a long list of values in a field, instead of having to manually scroll down the list to pick the desired value, you can just start typing the name of the value and Studio will fetch it for you. I just discovered that this seems to work only when that field is not multiple. When you have a multiple type List field, we are back again to manually having to select each value. In the example below, if I type 009 to select that client, Studio automatically checks  the boxes for the following client codes: 002, 004 and 909. Is this a bug or normal behaviour? Why can´t it work as with a non-multiple field? You type a code/name, Studio brings it up, you select it, you add (if necessary) a second value/line (like with Text fields) and redo the process of typing the code/name to select it. Thanks.

    Trados Studio project creation window showing a list of client codes where typing 009 incorrectly selects multiple codes including 002, 004, and 909.

    emoji


    Generated Image Alt-Text
    [edited by: Trados AI at 8:04 AM (GMT 0) on 29 Feb 2024]