You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current behaviour - to be replaced with new behaviour
Events: Publishing an entity creates literals in a language field based on the displayed fallback language when the field was not touched
Events: Saving an event entity does NOT create a literal in a language field based on the fallback language when the field is not touched
Place/Person/Org: Saving an entity creates a literal in a language field based on a displayed fallback language when the field was not touched
New behaviour
Make events, places, persons and orgs all behave the same way when it comes to creating a literal in a language field.
Remove the difference between saving and publishing in Events
Make Save behave the same across all classes / entity types using Event saving behaviour as the model
Saving (publishing) an entity will only create a literal in a field that a user explicitly touched (edited) and has something in it (a text string). It will not create a literal in a field that is untouched:
All entities: Saving an event entity will NOT create a literal in a language field based on the fallback language when the field is NOT touched
Events: Publishing an event entity will NOT create a literal in a language field based on the fallback language when the field is NOT touched
Warnings will continue to appear to inform the user that there is content doesn't match the language on the website until all fields have been touched / updated (I believe this continues to work as is, no change)
In Edit view: what happens if the user touches / clicks in a field and deletes the fallback language text that is displayed, but does not replace it with anything (i.e. leaves the field empty)? A literal will not be created, i.e. we will NOT create a literal that is blank upon saving/publishing. Instead, the next time someone views that entity in Edit mode, the fallback language will be displayed.
TO BE DECIDED for Read-only view: I am still debating which approach to take if a fallback language is being displayed because there is no language literal. In the read-only view, should we:
Show a field as empty, i.e. stop displaying the fallback language?
Display the fallback language in the field and display the language literal tag (this would be a change)?
leave it as is
In List views: leave it as is, no change.
The text was updated successfully, but these errors were encountered:
@troughc@saumier What happens when "dismiss" is pressed in the banner, which indicates there are language fallbacks present?
Currently, pressing dismiss will enable all fallback values to be their active value. And upon saving these values will be saved.
@troughc@saumier What happens when "dismiss" is pressed in the banner, which indicates there are language fallbacks present?
Currently, pressing dismiss will enable all fallback values to be their active value. And upon saving these values will be saved
@SyamBabu-M 'Dismiss' should not enable the fallback languages to be the active value which is then saved (the fallback languages as the actual values). Dismiss is used by a user to close the banner only.
The big idea/goal is that the user intentionally sets (chooses) the fallback language as the active value. Let me know if you need any further clarification.
Reference user story: #1371
Current behaviour - to be replaced with new behaviour
Events: Publishing an entity creates literals in a language field based on the displayed fallback language when the field was not touched
Events: Saving an event entity does NOT create a literal in a language field based on the fallback language when the field is not touched
Place/Person/Org: Saving an entity creates a literal in a language field based on a displayed fallback language when the field was not touched
New behaviour
The text was updated successfully, but these errors were encountered: