Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localization should enable passing a default/fallback language #164

Closed
irenama opened this issue Feb 10, 2021 · 5 comments
Closed

Localization should enable passing a default/fallback language #164

irenama opened this issue Feb 10, 2021 · 5 comments
Assignees
Labels

Comments

@irenama
Copy link

irenama commented Feb 10, 2021

I ran into this problem when querying images for my localized project, though I think it is a general issue with how gatsby-source-graphcms queries localized content.

On GraphCMS images are localized per default, although it doesn't often make sense to actually upload two images (en/de). This brings me to my current issue:

As English is the default language I would like to fall back to the English content, if there is no translated content for de. As far as I can see, it's not possible to pass an array of locales: [de, en] like in the general GraphCMS documentation (and like I did before) but only filter by one distinct language. Through this, I am missing a lot of e.g images on the queries for the German translation.

de en
Bildschirmfoto 2021-02-10 um 09 11 39 Bildschirmfoto 2021-02-10 um 09 11 52

Am I missing something here or is this not possible to fallback/query the default language with the package yet? If so is there a way around it? Thanks in advance for clarifying! 🙂

@ynnoj
Copy link
Contributor

ynnoj commented Feb 10, 2021

@irenama Thanks for trying out the library.

Unfortunately the behaviour you're seeing is indeed expected. The nature of Gatsby's GraphQL layer makes it difficult for the library to implement the fallback pattern you see with your GraphCMS API.

However there are ways to achieve what you're looking to do using Gatsby APIs. You can add a custom resolver for the image field on the crossLinks type to add a locale field argument. Something like:

exports.createResolvers = ({ createResolvers }) => {
  const resolvers = {
    GraphCMS_CrossLink: {
      images: {
        args: {
          locale: {
            type: 'GraphCMS_Locale!',
            defaultValue: 'en',
          },
        },
        resolve: async ({ remoteTypeName, remoteId }, args, context, _) => {
          const toGatsbyId = (remoteId) => Object.values(remoteId).join(`:`)
          
         // Find the `en` node for this `CrossLink` entry
          const enCrossLinkNode = context.nodeModel.getNodeById({
            id: toGatsbyId({ remoteTypeName, remoteId, locale: args.locale }),
          })

         // Map over the related images on the `en` node to build an array of ids
          const imageGatsbyIds = enCrossLinkNode.images.map(
            (remoteImageIdFields) => toGatsbyId(remoteImageIdFields)
          )
          
          // Lookup localised nodes for `images`
          return context.nodeModel.getNodesByIds({ ids: imageGatsbyIds })
        },
      },
    },
  }

  createResolvers(resolvers)
}

This can be then used in queries:

{
  allGraphCmsPage(filter: { locale: { eq: de } }) {
    nodes {
      id
      locale
      sections {
        ... on GraphCMS_ServicesSection {
          id
          crossLink {
            images(locale: en) {
              id
            }
          }
        }      
      }
    }
  }
}

This example works where images is an array (multiple values), but can be easily adapted to fit a single relation.

Hope this helps!

@ynnoj ynnoj self-assigned this Feb 10, 2021
@ynnoj ynnoj added the question label Feb 10, 2021
@irenama
Copy link
Author

irenama commented Feb 11, 2021

Thanks for the detailed answer! Unfortunately, introducing custom resolvers would be an overhead for this project having a lot of nested 'sections' with images and the like.
If it may help someone searching in a similar direction: I think I need to keep using gatsby-source-graphl for that specific localized project.
Still, I'm happy to use this package in another upcoming project with currently no localization. Thank you for your work!

@ynnoj
Copy link
Contributor

ynnoj commented Feb 11, 2021

There are both trade offs and benefits to using this library over gatsby-source-graphql. It's just about determining the right fit for your project. Unfortunately there's no 'one size fits all' because of the nature of Gatsby's GraphQL layer.

There might be some future API/product improvements which making working with localised assets better. Right now it's not a great experience to have to re-upload the actual asset for any localised versions. I'll relay your feedback.

Will close this issue, but feel free to re-open if you need 👍

@ynnoj ynnoj closed this as completed Feb 11, 2021
@TarekMowafy
Copy link

Hello @irenama , i came across a similar challenge and i was wondering how did grasby-source-graphql resolve the null assets issue?

@irenama
Copy link
Author

irenama commented Apr 12, 2021

Hi @TarekMowafy ! The project, that I tested gatsby-source-graphcms for, was already using gatsby-source-graphql: with that all queries could fall back to a provided default locale, like so

page(locales: [$locale, en]) {
    ...PageFields
}

So that's convenient/straightforward: No missing content (though maybe mixed language). :)
The reason why I checked out gatsby-source-graphcms though, is that the Gatsby image magic (local, static/fluid images) does not come out of the box that way round. One would need to write a custom resolver for the assets to make use of that.
Hope this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants