What I found is that:
If the logged in user’s userAccount field ‘locale’ being set to en_US, everything works fine. It seems that Moqui tries to translate the entity field value to the language of the user’s locale specified to. If locale is left to be empty, Moqui somehow utilizes the locale which browser detected.
In my case, it probably is set to be zh_CN. It happens that I have a ProductFeature entity having a field ‘description’ = ‘Brown’, LocalizedMessage entity with a field ‘original’ = ‘Brown’, locale = ‘zh’ , localized=‘棕色’. Then the EntityDataEdit screen shows ‘棕色’ in then ‘description’ input field. As I change other fields value, and submit, this localized value will be submitted to persist as well. This causes a trouble.
Anyone have a clue? Browser is Chrome 120.0.6099.201, Moqui version 3.0.0. database Postgresql 14, java version 11. Tested by Moqui demo code from github. Anyone can try this? Could try to set users locale to ‘zh_CN’, then a LocalizedMessage with locale set to ‘zh’, localized to a nonsense string.
As calling getMap(), it will return the localizedMessagge value.
This is the only entity definition found in udm component with field attribute
enable-localization
set to be “true”
And the side effect of getting localizedMessage in getMap() is that： when calling EntityValue’s toString() Method, you will see the original value of the whole, when try to get access to the value of a field by entityValue.${fieldName}, it will give the localized value. This is both confusing and dangerous.
What would you like to happen? I’m not sure how setting the locale to zh using the existing localization is a problem.
What you describe seems to be more of an edge case. If you require your account to be in english while your browser’s localization is Chinese, set the localization to english for your account. I could be wrong and don’t understand your problem though.
That is unfortunate behavior, looks like the concern is if the form is then submitted then the localized value will be saved in the base field (ProductFeature.description), which unless it is what the user is trying to do would be an unexpected and likely unwanted change.
What to do about it is another question, perhaps not localizing the value when used in an edit form or perhaps saving the value in the corresponding LocalizedEntityField record (for the entity, field, PK, and locale). Implementing either would be a bit troublesome, but either should be doable.
Normally it would not be a problem to set locale to any locale. My case is not happening so often. To reproduce this behavior, there are some steps to follow:
Having a entity definition with some fields defined with attribute enable-localization set to be 'true' , like ProductFeature entity
Having a ProductFeature entity instance, like the following: <mantle.product.feature.ProductFeature productFeatureId="PftSAEGrade5W30" productFeatureTypeEnumId="PftSAEGrade" description="5W-30"/>
Having a LocalizedMessage instance like the following: <moqui.basic.LocalizedMessage original="5W-30" locale="es" localized="Ejemplo"/>
Then when logged in, set the current user’s UserAccount.locale to 'es'
Go to EntityDataEdit screen to edit the productfeature instance with productFeatureId="PftSAEGrade5W30"
Then the description input field value would be 'Ejemplo' instead of '5W-30' if I am not wrong.
The wanted behavior would be that in the entity editing form it should always show the original value instead of localized value.
Possible to having getMap() having a parameter specify if the localized value is wanted or the original value is wanted? With default set to localized to be compatible with now behavior, then somewhere when needed original, specify it explicitly.
Anyway, this is not through thought. Just a gut feeling.
