Best Practices to maintain text for labels and link buttons throughout the website In Tridion CMS

Question

How should we maintain the text for labels and link buttons throughout our website?

For example, we have link buttons named “see more” on a few pages and now the editors have a requirement to to replace the text with “View Detail”. We generally manage such stuff through a resource component. Could anybody explore the best practices to implement such functionality? Below are few requirements for this:

1. We do not want to add a resource component in each page as a component presentation.
2. Any change in the resource file should not require publishing of referenced pages (something can be achieved through dynamic template).

We are using razor/C# for our templating.

Answer 1

I used both Key/Value pair schemas and "Label" schemas (see here for a good example), and decided that using label schemas ends up being a better approach for the following reasons:

• No problems with localized label components
• No need to train people maintaining the site that the Key part of a Key/Value pair cannot be changed
• Easy to add new keys (just add them as fields in the schema)
• Easy to have different types of values (string, date, RTF even)

Having it in a component makes it then very easy to either use at publish time for values that do not change ever and publish as a resource file to the delivery tier that your application can use.

EDIT If you use a .NET front-end, consider publishing this as a RESX file.

Answer 2

What I usually do, is have a labels component with Key/Value pairs (eg. key: "label.seemore" => value: "See more" ) published as a single XML file to the front end for each language / locale publication.

All the front end needs to do then is to read that XML file from the file system and get the appropriate label for each part in a web page.

This would satisfy your requirements, and if the labels needs to be updated, you only have to edit that resource component, and then publish the XML page out again.

Answer 3

I agree Key/Value pairs and Label schemas would be the current Best Practices to maintain text for labels and link buttons throughout the website.

Category & Keywords as Another Option

I've yet to see them used for a general "label management" approach, but you can also use Categories and Keywords to get the following benefits:

• Visible author-friendly (and localizable) title/name text
• Non-localizable key you can program against
• Where Used works for keys selected in fields
• Nestable keywords
• Re-use (if needed)
• An additional Description field in case Key/Value isn't enough

One of the biggest catches with this approach is templating the values to a preferred format; the keys are available via C# with TOM.NET (login required). See other approaches to access keyword keys in this SO question.

Content Modelling and Requirements

Also consider confirming the context or content model before changing See More to View Detail. It looks like you've already started with the two requirements.

1. We do not want to add a resource component in each page as a component presentation.

   • This implies the View Detail label is not "of the page," but should be available globally, across the site.
   • Be sure to place this high enough in the BluePrint for re-use and to work with any translation Publications.

   • You can also confirm any other rules for when See More needs to be View Detail.

     If it's a 1-to-1 change (always change it), then a single resource component works. But your content model changes if it's per Structure Group, per component template, or per author choice for each component presentation (where a keyword selection might be a better fit).

2. Any change in the resource file should not require publishing of referenced pages. ([achievable] through dynamic template)

   Bart Koopman confirmed in an aswer to my SO question that indeed, a RenderComponentPresentation() call would be a good way to avoid publishing referenced pages.

Answer 4

I've found that having a schema that specifies the keys introduces a lot of maintenance. What's easier is to just have a label schema, with a single text field for the value. The key is the component title. You can easily have a dedicated folder (usually part of the site layout, not the content) and use various techniques to make the label text available where it needs to be:

1. Template out .Resx files for use in a .NET application, or properties files in Java
2. Use a template building block to make the labels available in the package. A simple naming convention is enough here.