Under Community Review

Hi Ron,

Thank you for your ideas!

Please provide more input on the expected functionality (preferably with use cases why one or other approach is important):

  1. When localizing an item, CM copies all fields from the parent item. After that, changes to the parent component are not propagated to localized ones. Is this expectation correct for non-localizable fields or should they behave like shadow copies of parent field (e.g. new value should be propagated to local copies as well)?
  2. In order to keep parent-child fields in sync, would it be acceptable to deny changing non-localizable field value on the parent component if it was localized somewhere down in the BluePrint?
  3. Is this feature needed for content (e.g. content of the component) or for other item's metadata fields (e.g. metadata on the structure group) or both?

Non-localizable fields

Fields marked as non-localizable in a schema cannot be edited in localized components (should appear as read-only field in local copies). 

Example of configuring a non-localizable field:

Tridion Sites Ideas schema configuration interface showing a field detail section with 'Non-localizable' checkbox circled, indicating the field is set to be non-editable in localized components.

Ron Grisnich
Parents

  • Would be a very useful feature. Currently developers achieve this with Event System. Can you please explain what would be the behaviour if someone mark a field in schema when it is already in use and localized components contain local value to the field?

  • in reply to Suman Daripa

    I would suggest we keep it simple. If the field already exists and components are created based on it when the change is made, the system simply tells the user "Hey, there's content localized already - proceed at your own peril". Nothing would be updated in the existing content (the same as when you make schema changes today) - but they would fail validation when opened/changed in the future.

    If you're changing a content model already in play then aligning content should be part of that exercise and usually, this requires manual intervention anyway.

    Just to add - this would be a great idea as there's many a content model that ends up being more complex than it needs in order to breakup/protect specific content from being localized or edited even though it naturally belongs together with other content elements.

Comment
  • in reply to Suman Daripa

    I would suggest we keep it simple. If the field already exists and components are created based on it when the change is made, the system simply tells the user "Hey, there's content localized already - proceed at your own peril". Nothing would be updated in the existing content (the same as when you make schema changes today) - but they would fail validation when opened/changed in the future.

    If you're changing a content model already in play then aligning content should be part of that exercise and usually, this requires manual intervention anyway.

    Just to add - this would be a great idea as there's many a content model that ends up being more complex than it needs in order to breakup/protect specific content from being localized or edited even though it naturally belongs together with other content elements.

Children