What is the best way to localize Schemas so we can make region specific changes?

Question

What is the best way to localize the Schemas in SDL tridion 2011?

We have a schemas for Articles and products. We need to localize this for some region specific changes.

Is there a clean solution for this?

Answer 1

You can localise and change the schema field descriptions, to allow a local team content editors to see friendlier labels, which is a nice touch. You may also localize a schema to apply a different workflow.

You can't localize a schema to add new fields or change the structure of it. This is by design in the CMS. Imagine if a user accidentally unlocalized this schema, the content stored against it would not be valid.

I'd recommend creating an additional schema for your local content type.

Answer 2

As John says above, you cannot add or remove fields from a localised Schema.

One possible alternative would be to use an Embedded Schema for the fields that you definitely want to keep in all Publications and then to have a new 'outer' Schema to add any additional fields (possibly also in an Embedded Schema).

You would need to consider the editorial, templating, maintenance and BluePrint trade-offs of this against just having a new Schema though.

Answer 3

Schema differences across publications really depend on your content model. I wouldn't assume the need to localize schemas unless it's for translated fields for authors using other languages as Jonathan and John describe.

For suggestions on cleanly separated approaches, consider using Categories for fields.

• These can be localized or managed independently of the schemas that use them.
• Keywords in these Categories will have a key value that's the same across the BluePrint, but descriptions and titles (names) can be localized in different Publications.
• This means components can be shared across publications without localization, but have a setting (keyword) that varies by publication.

Also consider Publication-specific metadata or "configuration" components to create site-wide settings for Articles and Products. Your templates could then use these without needing to localize schemas or templates.

Just in case we're talking about content, I tend to recommend (Tridion) localization for translation needs, but separate components and metadata for profiling and channel-specific variations as described in this post on TridionDeveloper.

In other words, if "regions" means languages on the site, component localization may be a good fit. If it means different content authors, then go ahead and localize schemas.

Answer 4

If your Region specific changes includes either changing the Field Description or you want to change apply a modified region specific workflow, then you can go ahead, localize the schema and do the required changes.

If your Region specific changes includes more than that, then I would recommend you to revisit your Blueprinting Hierarchy.

From my personal experience, I can not visualize a scenario where you really need to localize a schema and require changes more than what have specified above (and by other professionals in their answers) Provided you have a good Blueprint and schema design.