DG
Hi,
Do you know if it is possible to change the following setting ? (depending on the language)
.JPG)
It seems that you can not modify this setting, after you created the attribute.
Thanks a lot
Daniele
Ciao Daniele,
I dare say in 99.9% of the cases it does not make sense to have a value attribute language dependent. Let's say you have an attribute with 3 values to choose from:
sí, no, forse
and the values translate to
yes, no, maybe
Someone maintains the attribute for an object in Italian to be sí. If the attribute were language dependent, in English it would show as "unmaintained" and could be set to "no", while the Italian reader still would read "sí". So it makes more sense for value attributes not to be language dependent, but to have translations for the value options. Then readers get the same information from the attribute, no matter which language they use.
I know, it was not the answer to the exact question you asked, but with respect to your example, this is the answer to be given.
Regards, M. Zschuckelt
Ciao M. Zschuckelt,
thanks for your cooperation, but like you said, it's not the answer to the exact question I asked.
I wonder if anyone knows if it is possible (and if so how can I do it) to change this setting, after you created the attribute.
Regards, Daniele
Ciao Daniele,
point taken, so here is my answer to the actual question: If you changed that setting in a productive environment from language dependent to independent you would have to answer, which is the language to keep and which languages to discard. You would run the risk of losing a lot of data. And if you changed that setting in the opposite direction, you would have to declare, which language the current values are to be copied to (or all). In the other languages the attribute would not be maintained any more.
In both cases you fundamentally change the character of the attribute type, and if there were any scripts working with that attribute type, they would likely break or produce surprising results. One should accept, that a language dependent attribute is something completely different from a language independent one.
The clean way of handling this use-case is defining a new attribute type (maybe with the same name, rename the old one, if you like), so you obtain a new GUID for the new attribute type. Then you migrate the values to the new type with any strategy you require in your case.
Regards, M. Zschuckelt
Hello Daniele,
also consider the governance aspect: In production scenarios there are likely to be owners of objects, that signed with their blood for a certain statement in the attribute (in a certain language). If you change the type, that is permanent, even in history. The ARIS server could not deliver the old information any more, because it lost the type information and methods to access it. Information stored in earlier versions of an object could become unreadable, because you cannot select the language for the attribute any more. So there are good reasons for not allowing that aspect of the type changed, just as you would not change the type from text to integer, losing all non-integer values.
Last but not least, and then I will stop: Suppose you have multiple ARIS environments (or multiple ARIS customers share their methods) and you do that change only in one environment: The transfer of ARIS content between the environments would become impossible instantly, if there were any disagreement on the type of an attribute type, that has a certain GUID. That is the charm of GUIDs. Once they exist, you know who they are. And your old backups (.adb) would become useless as well. And if you stored any content information outside of ARIS in XML files (created with XML-Export), they would also break.
Regards, M. Zschuckelt
