Not Planned
over 1 year ago

Update: This idea is currently not planned based on our program planning and prioritization of all Tridion Sites ideas for early 2018. We may revisit this and other great ideas based on more information and additional votes.

Split the Translation of Structure Groups and Pages

With such combination Translation Manager + Worldserver, we want to translate Structure Groups and Pages in different translation jobs, because the most of the pages is not needed to be translated and so we don't want them to get localized.
As you can see in the screenshot a user only has the option to select the translation of structure group and pages. Is there a possibility to split that.



Our thought how that could work the best is that you have three checkboxes (and even more for Bundles for example)

1. Translate structure groups
2. Translate pages
3. Translate components

  • +1 - We want to send just structure groups (and sub-structure groups) for translation to translate the menu, plus the URLs for the site. You definitely don't want to send all pages and components in the same job.

    As there is no context in TMS (you don't really see if a piece of text is a filename/URL or metadata or content) its much clearer to have a separate job for this (in our tests URLs were always translated with spaces and special characters which then failed import in back in the CMS because the translators had no idea that the content was a URL)

  • When users want to translate Structure Groups separate from Pages, is it always in separate translation jobs or might they sometimes want Structure Groups AND Pages in the same job?

    And what are they trying to accomplish when translating Structure Groups?

    For example, I'd often use Structure Group fields for translatable content related to website navigation. In this case, what users really want to translate would be all the Structure Groups related to navigation (site navigation,  secondary navigation, breadcrumbs, site map, etc.). In this case, I'd focus on some type of "translate navigation" setup in the implementation using things like the event system, workflow, and/or advanced search.

    Thinking Lars point through, I can imagine the "complete" setup for options for each type of item would also include checkboxes for nested organizational items (think Content Porter's selection options). :-O

  • We have for a while been considering how we can allow more control over the translation resolving while still maintaining a simple UI.

    The main issue with checkboxes is Bundles would require 6 checkboxes (+/-) - so if you add 10 bundles you would have 60 checkboxes on this screen. If you add a bundle, a page, and a folder you would end up with three items all having different sets of checkboxes available.