We have a similar problem when we want to send selected structure groups only to translation for breadcrumbs. As an example, when we created a translation job for 24 structure groups in Sites with the first checkbox selected, translation jobs in TMS contained 498 structure group files and 246 page files instead of 24 structure group files. We need a way to send 24 structure files only to TMS without sending sub structure groups and pages from Sites. Because of this limitation, our current process is all manual - copying and pasting content from Sites into a separate file, sending the separate file to translation and coping and pasting translated content back to Sites language by language. Can you split the option for organizational items into "selected" and "nested" to be more consistent with other content types? Can you also make option names consistent across the content types so that we do not have many checkboxes when the multiple types are added to a single translation job?

The idea of checkboxes per content type would be like this:

•  Page:
  1. Translate selected item:  Translate page
  2. Translate nested content items: Translate components on the page
•  Category:
  1. Translate selected item:  Translate category
  2. Translate nested content items: Translate nested keywords
• Organizational Item (Bundle, Structure Group, Folder, etc.):
  1. Translate selected item: Translate selected organizational item 
  2. Translate nested organizational items: Translate nested organizational items 
  3. Translate nested content items --> Translate non organizational items for example, pages, components, etc. contained in organizational items

+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.