Where to place "page content" to minimize localization

Question

I'm trying to interpret the practice of minimizing localization into practical implementation scenarios.

Using Tridon page metadata with fields for website page metadata such as title and keywords implies we may need a "page Translation" layer to translate these fields.

We can eliminate this layer by minimizing localization and placing these in components. Manuel Garrido describes we can consider "a single Translation Layer in the BluePrint" by managing:

• ...web page title and metadata in components in the global content publication
• ...Navigation, breadcrumbs and sitemap titles as content in the global content publication

I see at least two approaches:

1. Have page template logic that "identifies" the main component on a page to place these fields appropriately. For example, it could be the first article component in the list of component presentations, with appropriate fallback values or defaults if not available.
2. Create page-specific fields in components and place them in a Global Content publication.

Before recommending these approaches, could I get help confirming:

• I've heard page localization and unlocalization isn't as big of an issue with Translation Manager. We can unlocalize changes, but during the translation job, items matching translation memory would get re-translated. Costs are probably out of scope, but is this unlocalize/re-localize approach really "free?" Wouldn't someone need to still run and wait for the translation jobs (to be completed by translators)?
• Out of the options above, would either be easier to manage? I like the semantic approach of the first (SEO/page metadata in the "main" component), but how would you manage these "shadow" page components (e.g. event system to keep the component is a folder setup matching structure groups below?).

Specific, TRex-friendly question:

If I want to minimize translation and remove a Page-translation layer in a BluePrint, where should I store the fields? If it really depends, then maybe answer where you would store the fields.

Answer 1

We are using the option #2 for all global roll out as it is working out to be a better option : Create page-specific fields in components and place them in a Global Content publication.

Reasons:

• Easier Page Management for ongoing maintenance : Once the pages localized, if Editor added a component on the page he then has to go to each localized page and the same component (page assembly) after translating. This is huge deal of work when we are dealing with large number of countries.

• Better control of Publishing items : Assume home page or landing pages has multiple sections of content where each group is managing them separately (e.g.; press releases, events etc) and you marketing team is managing the SEO aspects. If we keep metadata at page level, Now you need to publish the page for any change in the meta. If we keep it as separate component (assuming dcp) it could be published on its own without dealing the complete page publish.

Answer 2

Definitely avoid Page localization, unless it is necessary to localize the URLs (I wish Tridion had a better solution for this), and also avoid content metadata (eg SEO data) in Page metadata, for the reasons you and Ram list already.

Personally I don't really like the approach to have separate metadata components for all pieces of content - it seems clumsy and unnecessary - especially if the majority of pages in your site have an obvious main component (ie an article or similar). Also I strongly believe that this metadata belongs on that article component, particularly with SEO.

Tridion's component-based content architecture give you a wonderful platform to manage, share and reuse content across sites/apps/devices/channels but if you fragment the content too much (page meta + component + metadata component) then you may have a bit of headache to sew it all up again when later along the line in your implementation you need to use it somewhere else.

When identifying the main component, I find that this is typically determined by the template and not schema. It can help to draw parallels with dynamic linking logic - if I was linking to this page, which component would I link to.... So you could for instance use the component from the CP with highest template priority, or a naming convention in the template (include (Main) in the CT title) or indeed metadata on the CT.

Some pages do not have an obvious main component, and here you may indeed find it useful to have a metadata component - this will also solve your headaches of creating links to this page - as you now have a component to link to (note this component does need to be rendered, even if the Output of the CT is an empty string - otherwise Tridion CD will not know that this CP is on the page).

As for things like having separate sitemap, breadcrumb and navigation titles - this sounds like the sort of number of variations that will confuse editors, and most likely site visitors too - is this really necessary? Typically I have a single 'short title' metadata field, which is auto-populated (using the event system) from a component field (like the heading) in the case that the editor has not provided a value. Remember that on different channels and devices there may not be a sitemap or breadcrumb, so name your metadata fields wisely