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.
- ...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:
- Have page template logic that "identifies" the main component on a page to place these fields appropriately. For example, it could be the first
articlecomponent in the list of component presentations, with appropriate fallback values or defaults if not available.
- 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.