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.  

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.  

Beatriz de Vega 

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 Oana Nagy 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 Oana Nagy 

Have a good evening

Lyds

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

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.