Idea Delivered

Idea has been implemented in Sites 10.1,  Granular Blueprinting feature.

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
  • 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.

  • in reply to Suman Daripa

    Thanks for your response, Suman. In my opinion, there are multiple approaches feasible, including only allowing this on new fields and overriding the values of fields in localized components (potentially loosing (localized) content).

  • 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?