Document translation links don't work with custom structure builder menus

[gpoole]

Using intl-input with the Sanity kitchen sink example I've noticed that the translation links don't work properly. I found I was able to hide translations by patching the default filters, for example:

        S.listItem()
          .title('Pages')
          .schemaType('page')
          .child(
            S.documentList('page')
              .title('Pages')
              .menuItems(S.documentTypeList('page').getMenuItems())
              .filter('_type == "page" && _id != "frontpage" && !(_id in path("i18n.**")) && !(_id in path("drafts.i18n.**"))')
          )

But I've found that the links for the document translations tab don't work with the URL structure this creates. For example, using that desk structure the base page URL looks like this:

http://localhost:3333/desk/pageBuilder;pages;<uuid>

But the link to edit the translation is:

http://localhost:3333/desk/__edit__i18n.<uuid>.<language>%2Ctype%3Dpage

This does seem to edit the translated document but it also causes the selected item and position in the menu hierarchy to be reset.

[nicktaylor]

Similar setup here, but with .child(() => ...) after .filter(...) have you tried adding .canHandleIntent(intent => (intent === 'create' || intent === 'edit')) before the .filter(...). Also, add .schemaType('page') to your S.documentList.

        S.listItem()
          .title('Pages')
          .schemaType('page')
          .child(
            S.documentList('page')
              .title('Pages')
              .schemaType('page')
              .menuItems(S.documentTypeList('page').getMenuItems())
              .canHandleIntent(intent => (intent === 'create' || intent === 'edit'))
              .filter('_type == "page" && _id != "frontpage" && !(_id in path("i18n.**")) && !(_id in path("drafts.i18n.**"))')
          )

[gpoole]

Thanks for the suggestion @nicktaylor. I'm not working on the project that used this anymore and don't have access to check unfortunately, but if that's correctly keeping the parent page highlighted in the nav when you view a translation then yes that should be a fix for the original problem.