5

We have a multilanguage site mantained via Tridion 2011. Short example: English publication->French publication. So the French publication is a child publication in this example.
In pages our Metadata Schema defines the tags "Page Title" and "Description". So these fields are being generated into the "HTML" from Metadata Schema.
So in order to change/localize the Page Title and Description of the pages, we have to localize them under the French publication.

This is not good because if we change something on English page, like the order of page content components in "Component Presentation", it will not reflect on the French page.
This is not a content change, rather a page structure/layout change, changing order of items appearing on the page, adding new content components etc.

Is this a common approach, to generate Page Title and Description HTML meta tags by using Metadata Schema's?

Why not creating additional content components for these HTML tags instead of using "Metadata Schema" defined tags? That way actually the page could remain unlocalized... Only the page content components should be loclaized. This way if there are some structural changes done on the source publication page (English) it would effect the French version too.

Which approach is accepted and advised, I assume it's possible to implement this second approach without issues...I mean there are no restrictions in Tridion doing so, right?

Thanks, bvl

Improve this question

3 Answers 3

Reset to default
10

This is where the complexity of Content Modeling really comes around the corner. There are several approaches to a certain problem, and each one of those will have pros and cons.

  1. It is well accepted to place things like a page title, description and keywords in Page Metadata.

  2. For a multi language BluePrint it is unwanted to have a need to localize Pages for translation reasons

Bringing point 1 and 2 together that dictates that you cannot place translatable content directly in the Metadata of a Page. So to work around that you will have to revert to using Component Links.

Your Page Metadata Schema will contain a Component Link field pointing to a Schema which defines values for the translatable texts you require in the Page. Now you only need to localize that Component and never have a need to localize your Pages for translation.

Improve this answer
5
  • When the decision was made about content modelling I wasn't there...So now I'm the one facing with it and mantaining. I suppose we could use some automatized tool or script to transfer the data from these pages metadata and create for each page a corresponding component template and transfer those fileds there. :) It could be a lot of manual work doing that now. Thanks!
    – BVL
    Sep 26, 2013 at 13:36
  • 1
    You could spend time trying to automate it, but also take a look at manual transfer, see my related blog post about that tridiondeveloper.com/how-to-say-goodbye-to-your-migration-tool
    – Bart Koopman
    Sep 26, 2013 at 14:42
  • An intersting perspective, Bart... So you are surrounded with lot of blond hair girls. :) And you probably like Anouk too, I mean not the migration tool, but the singer. I always try to make the most efficient decision... I try to estimate the manual work and benefits compaired to a "tool". Good blog! p.s. no blondies nearby... :(
    – BVL
    Sep 26, 2013 at 14:52
  • Unfortunately she was only needed for a few months and we had to say goodbye to her. But definitely no complains from me on that department :D. I fully agree on most efficient solution, that's why I brought it up, cheap labor like temp hires can do a lot more work than you can build tools for, its just that most ppl think manual labor is more expensive while it can be the cheapest and most efficient way.
    – Bart Koopman
    Sep 26, 2013 at 15:18
  • I've encountered the exact same issue, and eventually told the content editors that they need to maintain meta components for all their global page types. Meta components based on product pages, articles, and homepages. A lot of work, but the content editor was glad he could have complete control over every page meta of every page without having to localise the page.
    – MDa
    Sep 27, 2013 at 8:40
3

You've discovered the practice of "minimizing localizations", which Manuel Garrido describes in this post. A matching BluePrint would place all of the following in Global Content:

  • Translatable content
  • Web page title and metadata in components (rather than in page metadata)
  • Navigation items like titles and breadcrumbs

Content Model Practices

Yes consider SDL Tridion components for "page" (HTML) metadata. But it doesn't need to be a "page" component for every page. Consider:

  • An "article" or "press release" component may have the fields you want for pages they're on.
  • The component could be another page-related item such as a banner. You might call the component "SEO"
  • The Page name in Tridion could be the Title

You could also offer defaults such that when an authors don't specify certain fields you can the value from the structure group (recursively up to a default for a given publication).

Machine Translation Impact

If using something like SDL WorldServer with Tridion, especially with machine translation, it almost doesn't matter where you put your (HTML) page fields such as Page Title. You would unlocalize child pages and then resend items through translation to change the fields and component presentation order in child pages. Items and phrases that have already been translated wouldn't incur the same translation "costs" as they're matched to previously-translated items.

Improve this answer
0
1

There are numerous options.. One is to use a 'magic component' as a look up table. Another is to use the event system to see what the change is and if it is a re-order of the components then to place that change onto the child pages that are localized, or to trigger an alert.

The other question might be why does the order of the Component Presentations matter?

Improve this answer
2
  • Well, except in cases where we have a 1:1 page-to-content relationship or content sort automatically, the order of component presentations should determine the order of the content on the page, right?
    – Alvin Reyes
    Sep 27, 2013 at 11:43
  • Yes, in our case, it matters...and the order of components in c presentation is the same as the content order appearing on the page itself like you said.
    – BVL
    Oct 2, 2013 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.