Under Community Review

easily send components from a page for translation

Currently if you want to translate the components contained in a page, you can either:

  1. translate the page. However this will localize the components in the local country sites instead of in the translation blueprint layer, because the website publication where you store pages is the translation source, instead of the english content publication source. 
  2. Run a where used report on the page, locate each component in the English content publication and translate them one by one, or add them one by one to an existing translation job. 

It would be great to be able to do a Pull translation from the page in the website publication level, which would simply translate all components on the page, in the correct translation layer of the blueprint rather than in the local country sites. 

Let me know if there is a workaround or best practice for this.

Thank you

Philippe Conil
Parents

  • Good idea!

    Ideally, the Components added to the translation job (based on translating a Page they appear in) would resolve to the would-be parent Publication, if they weren't localized. This is how Components act on their own. See the documentation on resolving push or pull jobs. Otherwise, this could be a complicated user interaction for users to choose the context.

    I'm familiar with these workarounds for managing the translation of Components in a different (higher) context than from their containing pages:

    • Event System to replace the Components with equivalent versions, higher in the BluePrint
    • Bundles, naming conventions, and possibly Metadata to associate the Components and the pages. The idea is to go up the BluePrint and put all the related items into a Bundle and then translate the Bundle.
    • More recently, I've seen BluePrint hierarchies that favor language over regions, meaning it might be okay to translate from the page level (I know, right?).

     I think this last point will take a while to catch on since historically you would want to separate Pages from Components to maintain a separate translation layer in the BluePrint and be able to reuse content independent of where it appears on pages.

    But... more headless setups could likely mean you need fewer Publications to represent websites and channels. The idea is you mainly need a content API endpoint of sorts, where Pages create structure for content, and various applications pull content and pages as needed.

    It's a radical change, but we've seen design, mobile, and other channel-specific Publications go away as website practices and digital experiences change. Perhaps pages will be less about web pages and more about digital experiences?

    Anyways, +1 to the idea. Especially as more customers take advantage of translation review and preview capabilities in Sites and translation systems, more editors and reviewers will work in the context of a "page."

Comment

  • Good idea!

    Ideally, the Components added to the translation job (based on translating a Page they appear in) would resolve to the would-be parent Publication, if they weren't localized. This is how Components act on their own. See the documentation on resolving push or pull jobs. Otherwise, this could be a complicated user interaction for users to choose the context.

    I'm familiar with these workarounds for managing the translation of Components in a different (higher) context than from their containing pages:

    • Event System to replace the Components with equivalent versions, higher in the BluePrint
    • Bundles, naming conventions, and possibly Metadata to associate the Components and the pages. The idea is to go up the BluePrint and put all the related items into a Bundle and then translate the Bundle.
    • More recently, I've seen BluePrint hierarchies that favor language over regions, meaning it might be okay to translate from the page level (I know, right?).

     I think this last point will take a while to catch on since historically you would want to separate Pages from Components to maintain a separate translation layer in the BluePrint and be able to reuse content independent of where it appears on pages.

    But... more headless setups could likely mean you need fewer Publications to represent websites and channels. The idea is you mainly need a content API endpoint of sorts, where Pages create structure for content, and various applications pull content and pages as needed.

    It's a radical change, but we've seen design, mobile, and other channel-specific Publications go away as website practices and digital experiences change. Perhaps pages will be less about web pages and more about digital experiences?

    Anyways, +1 to the idea. Especially as more customers take advantage of translation review and preview capabilities in Sites and translation systems, more editors and reviewers will work in the context of a "page."

Children
No Data