This issue was noticed on more than one Arabic instance.
When typing text in a field, another field supposedly unrelated is filled in the same time with the same value. Selecting an item in a list could also fill another unrelated filed (during the input process) with random numbers (Maybe the key of the value)

This error is triggered when the user wants to translate items from Arabic

A work-around is to setup all entity names / attributes in latin characters
Just for completion purposes: this issue has been confirmed and it is a bug.
Our property name sanitizer replaces non-latin characters with underscores.
This was done both to prevent invalid JS keys (a requirement) for the metadata and, also, to keep the metadata properties "semantic". In that way, you can read the mongo documents like:
{
entity: '9afsdg098b',
title: 'Case 3F',
metadata: {
country: 'Ecuador'
}
}
Of course, if the property is created in Arabic (for example) directly, then every property will be just underscores. Those that have the same number of underscores get linked when filling in forms, and in the database they are stored only once. So, if you have only two properties with the same length, in the database we would only store one property named "_____" which will fill both properties.
As mentioned, there is a simple workaround: define the property in Latin characters and then translate it. This works perfectly.
In the long run, of course, we need to change the sanitizer to something error-proof. How to approach this and retain the semantic reading of properties is a challenge.
Thank you Rafa for this detailed and quick response.
Is there a timeline to work on this issue?
Not at the moment. We encourage users to set the property names in latin characters and then use translations (even if using a single RTL language instance) to define the non-latin labels.
An update on this. The issue happens as well with the Thesauri and Thesauri items. In case the thesaurus item is created in non latin characters, just opening the translation of the list and saving, trigger the error
@RafaPolit @daneryl I guess this got fixed with the new safe name approach?
@txau for instances that existed before the fix, the default is still the old safe name, only new instances are using by default this.