Just to shed some light on this I will try to explain why the two behaviors are happening and would love your input on what to improve.

No new entries with default values created automatically

• Translations are very similar to a O2M relation behind the scenes, a translation is just a DB entry pointing to the parent item
• The interface is responsible for creating the correct O2M items in the _translations table behind the scenes, once a modification of that language's translation is detected
• So, if no modification happens, no new item is created in order to not unnecessarily create n many (one for every language) new items in the translations table, every time a new item is added to the parent collection. That is also the reason a new item is created once you make a modification

New default values don't update existing items

• This is very much in line with all other default value. You will also notice this behavior when creating a new default value for a string field. All existing items that don't have a value set are not updated, since the default value is just a DB default after all, that only applies to newly created items

With this in mind, I would say that the second observation is very much how it is handled with all other default value and is intended to stay that way.

For the first observation I'm asking what the expected or improved behavior would be? Should new items for all languages always be created by default, or only if some of the fields might have a default value? Is that better than not creating it? I can also see situations where this might lead to more problems than the current implementation, eg. if the field is a dropdown field with choices and we still want to retain the behavior of not creating all translations at once, since there is some semantic meaning behind the existence of a translation (it should be used, instead of a fallback language, for example).

Another option I could see is that it should be configurable in the translations interface how the translation item creation should be handled. That seems like the cleanest solution in my opinion.

Happy to hear your thoughts!

On the first observation.

I'd expect when the default values are shown on the application and I'm saving that Item that the values are also set on the database. I can imagine that the first approach you are describing could cause issues, but a field that has a default value and it doesn't change (because it doesn't have to be) feels a bit broken.

In this situation the default values is only being set on only one language (possible default language). I believe this should be the case for default values as well when you have multiple languages. The default language needs to be set before you can set the default values? If this would make sense? (what do you think?). Would that be a more clear solution? As the situation I have described in the issue above it is mostly prominent when you have only one language available (which was the default).

The last solution could be a cleaner solution for sure. I do believe we would want to make this clear for the person who is setting this up what the behaviour/expectation will be.

Regarding the second observation.

I could be wrong here. I don't think when setting a default value should automatically update the defaults for everything (if this is not possible), but when somebody goes to an existing item the default values are being shown. When nothing is changed outside of that and you'll save and come back the values are there but actually they are empty makes this a bit odd.
I'm not sure how we would want to tackle this, but I can imagine that we could make sure if it's already saved and the DB returns NULL we don't have to show the default value for older items?

Let me know!