gatsby-source-datocms: localeFallbacks not working in latest versions.

It appears that localeFallbacks don’t work as expected in newer versions of gatsby-source-datocms

our defined localeFallbacks

localeFallbacks: {
  'en-DE': ['en'],
  'en-FR': ['en'],
  'en-BE': ['en'],
  'en-NL': ['en'],
  'en-GB': ['en'],
  'en-US': ['en'],
  'en-EU': ['en'],
  'fr-FR': ['fr', 'en'],
  'fr-BE': ['fr', 'en'],
  'nl-NL': ['nl', 'en'],
  'nl-BE': ['nl', 'en'],
  'de-DE': ['de', 'en'],
}

Below Im posting 3 examples of data being returned differently for different versions of those plugins. The query is the same across all 3 examples.

Example 1 (Working as expected):

gatsby-source-datocms@3.0.15 datocms-client@3.5.9

Screenshot from /___graphql: Screenshot 2022-05-27 at 13 24 09

Example 2 (Not Working): gatsby-source-datocms@4.0.4 datocms-client@3.5.9

Screenshot from /___graphql: Screenshot 2022-05-27 at 13 31 15

Example 3 (latest versions - Not Working) gatsby-source-datocms@4.0.4 datocms-client@3.5.21

Screenshot from /___graphql: Screenshot 2022-05-27 at 13 36 15

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 21 (15 by maintainers)

Most upvoted comments

Above fix was just published in gatsby@next (concrete version right now is gatsby@4.24.0-next.0).

pieh on Sep 8, 2022

@jpriceharrys If you debug the lines I linked above the logic says the following:

If there is no localised field, use the first locale defined in Dato
If there IS a localised field, check if the model requires all locales to have a value
If all locales are required
- Generate a node for all locales because the source plugin can expect data to be defined for all locales
If all locales are NOT required
- Check the entity for all locales that have a value and generate a node for each of those (I haven’t debugged this with data, but this is what I think happens for the line Object.keys(entity[camelize(firstLocalizedField.apiKey)]);, @jpriceharrys please verify if you can)

If my understanding is correct, given your more detailed post above, I now consider this a bug with gatsby-source-datocms. Because just as you say, you are required to fill in a value for a locale for a Gatsby Node to be created for that locale.

The localeFallbacks option will only get processed for locales that have a value, which kind of defeats the purpose. @stefanoverna do you agree?

If so should the logic change to include localeFallbacks in the decision for localesToGenerate? I think that all locales that have a fallback defined in localeFallbacks should get a Gatsby Node generated with the fallback value. I can probably get a PR drafted if this is something the maintainers are willing to merge.

michaellopez on Jun 8, 2022

That is correct @michaellopez.

We’re currently talking with Gatsby to see if we can do any better than this.

Ideally, we’d like to replicate the way localization works with our GraphQL API. This would allow us to generate only one Gatsby node per record, and let the developer customize the locale (and fallback locales) to be returned on a per-field level… but some pieces are missing in the Gatsby API atm.

I’ll keep you posted!

stefanoverna on Jun 6, 2022