Under Community Review

Let's collect some more feedback.

I see that we are currently talking about separation (during localization process) of name and file name properties that can be treated as metadata and everything else (that is related to content part) like page template, list of components, and metadata fields assigned to the page since they are part of page schema that defines page layout (regions).

So I would separate ideas about partial localization and the possibility to push/pull content changes from parent items.

Please share your thoughts on what is more relevant for you.

Either page file name changes are often required for localized content or the possibility to synchronize content with parent item would be more beneficial 

For name and file name we might change these properties to allow editing them on shared items. So you do not need to even localize

Separate localization of page properties and metadata from page contents

There are closed/dismissed ideas which are similar to this.

It would be great if we could only localize page properties (title, url) and metadata, for SEO reasons for instance, and maintain corporate control on the list of components a page contains. Currently, once you localize a page, any component added on the parent page will not be reflected in the child page. This should be an OOTB option. Currently customers need an event system or UI extension to apply their English page content changes also into localized pages. 

Potential approaches: 

- 2 localize options: localize page properties & metadata vs localize page content + corresponding translation options to only translate page properties & metadata vs also translating components within the pages. 

- Popup when saving a parent page which has localized children: "would you like to apply your content changes to localized versions of this page?" if Yes it would update the CP list in the localized pages, could be even better by having the choice of which local country sites to apply changes to with checkboxes. The page properties should not be overwritten (this could be an extra option too).  

Philippe Conil

  • I see that we are currently talking about separation (during localization process) of name and file name properties that can be treated as metadata and everything else (that is related to content part) like page template, list of components, and metadata fields assigned to the page since they are part of page schema that defines page layout (regions).

    So I would separate ideas about partial localization and the possibility to push/pull content changes from parent items.

    Please share your thoughts on what is more relevant for you.

    Either page file name changes are often required for localized content or the possibility to synchronize content with parent item would be more beneficial 

    For name and file name we might change these properties to allow editing them on shared items. So you do not need to even localize

  • Yes! The fact that page content and page metadata are combined has led to practices like minimizing (page) localizations. In practice, most but not all of the Web page SEO metadata can be handled in a "main" Component for the page, such as an article or banner Component. However, localized URLs are often based on page titles and it'd be great to manage the title or an explicit URL independent of the rest of the page!

    I've seen and heard of the "push" approach you describe, , as well as the related idea of a "pull" approach where local editors get some kind of update that a would-be parent has changes to review (and perhaps accept into the local versions). I also see overlap with the idea of non-versioned metadata, which is information that doesn't follow the same workflow or even BluePrinting rules as regular content fields. For either idea, perhaps a UI for AppData might be an elegant solution? :-)

    To take a broader view, I see a need for global navigation and (SEO) metadata management. So rather than localizing page titles separate from page content, I'd want to control the local URLs for pages. Perhaps the user might even want to manage all of this metadata centrally in one view, rather than in the typical BluePrinting approach across multiple screens. At least that's my 2 cents. ;-)