context.locale overwritten by getResourceFromContext if Drupal returns entity with different langcode.

[MartinDavi]

Hey, this is something you're already aware of based on these comments but is an issue in our configuration:

      // Fix for subrequests and translation.
      // TODO: Confirm if we still need this after https://www.drupal.org/i/3111456.
      // @shadcn, note to self:
      // Given an entity at /example with no translation.
      // When we try to translate /es/example, decoupled router will properly
      // translate to the untranslated version and set the locale to es.
      // However a subrequests to /es/subrequests for decoupled router will fail.
      if (context.locale && input.entity.langcode !== context.locale) {
        context.locale = input.entity.langcode
      }

The problem for us is we do not want to serve default locale content when requested translation does not exist, so we do something like this after requesting the resource:

const nodeOfRequestedLocaleDoesNotExist =
    context.locale !== resource.langcode;

But because getResourceFromContext has overwritten the context.locale to be whatever the entity.langcode is, we have to store what the original locale was at the top of getStaticProps or whatever, and use that for all subsequent requests.

Wondering if https://www.drupal.org/i/3111456 has made this unnecessary or if this is just something we need to keep in mind and work around.

[MartinDavi]

This also causes an issue if the Drupal language negotiation path is different from the locale. For instance we've set Drupal to serve German from /de-de and the same in next.config.

But the langcode on the resource itself is de. So de-de !== de and now our context.locale is overwritten with a locale that will not resolve correctly for all subsequent requests.