WIP: feat(gatsby-source-drupal): Add multilingual support by prefixing nodes not in the default language with their langcode

[Auspicus]

Description

We're currently using gatsby-source-drupal to pull content from our D8 site and we got stuck trying to pull content from another language because it gets overwritten by the last source plugin in the list. eg. gatsby-config.js

...
{
  resolve: `gatsby-source-drupal`,
  options: {
    baseUrl: `http://example.com`,
  },
},
{
  resolve: `gatsby-source-drupal`,
  options: {
    baseUrl: `http://example.com/es`,
  },
},
...

Documentation

• Add information about the new parameters language and defaultLanguage to the README.md

Related Issues

Addresses #10020

[Auspicus]

Things left to do:

• see how this plays with fast builds
• confirm backwards compat
• add documentation to README.md

[Auspicus]

Probably better to just pass in languagePrefix. I think that makes the most sense from a DevX perspective. "I am trying to use an endpoint with a /es/ prefix, I put languagePrefix: es into the gatsby-config"

[smthomas]

This is getting pretty close, but there are a few things we need to consider before this can be merged:

1. Right now this expects a JSON:API endpoint to only return entities from one language. I have plans to be able to bundle multilingual endpoints into a single endpoints (for efficiency reasons and build time performance). Ideally, we could create a way to use the langcode returned from the entity instead of just using a constant language prefix from gatsby-config.

2. This isn't going to work with incremental builds, fastbuilds, or instant preview yet. In utils.js there is a handleWebhookUpdate function that needs some updating. I think this is the start of what needs updating. Right now it just tries to use the UUID to find the node, we need to make sure it appends the same language prefix here so it finds the correct node.

[smthomas]

Will this always work? It seems that this will default to "/en/jsonapi" which doesn't seem to work out of the box with JSON:API.

I think the better approach might be to default to the current URL (baseURL/apiBase) unless a language prefix is added to gatsby-config.js. If it's added then it can be appended to the URL.

[Auspicus]

I saw the same thing, fortunately Drupal does redirect /// to / so in the case a languagePrefix is not specified it would change to baseUrl//jsonapi rather than baseUrl/es/jsonapi which both work. I don't like forcing a redirect in default case though so I will definitely refactor this so that it's not required when langaugePrefix is not specified.

[Auspicus]

Got fast builds working with the translated content there's just some funkiness going on with the relationships in the translated content that needs to be resolved. Most likely the references are just missing their prefixes in some cases.

[Auspicus]

@smthomas With the administer languages permission it seems like we could use /jsonapi/configurable_language/configurable_language to fetch the languages available for the site and then the /jsonapi/language_content_settings/language_content_settings to figure out which entities can be translated. There's an attribute on language_content_settings called language_alterable which tells us that the entity might have content in another language.

I might rework this PR to do that but for the mean time we are using a forked version that just specifies the languagePrefix directly in the gatsby-config.js. I'll push the final changes for this PR tomorrow which should make fast builds work with it and then start working on getting it progamatically figuring out which languages are available with what I described above.

If we only have to pull translations for content that has translations available it should make the process a lot faster rather than including 2 different gatsby-source-drupal plugins and having it pull the entire site in both languages.

This request will get all translatable entities:

/jsonapi/language_content_settings/language_content_settings?filter[language_alterable]=true

[Auspicus]

Closed in favor of #26720