Locale filter doesn't work

I have a data model called Podcast which doesn’t have translation currently enabled, however it is queried within a generic function that often does have translated content, so it is queried for various locales.

My issue is that no matter what locale is queried, the content is returned.

For example, this query returns 3 results despite no Japanese content being available:

query MyQuery {
  allPodcasts(locale: ja) {
    id
  }
}

Actually this is worse than I thought. The locale filter doesn’t work right at all. Even on translated content types it’s returning results that aren’t of the locale requested.

Hi @kaushik :slight_smile:

records do not have a “locale” per se. Localization is a setting you enable/disable on a single field. So, this means that it’s a field that has some locales, not a record.

I suppose that the Podcast model has a localized field. Let’s call it title. If you wanna fetch all of the podcasts ids where the title has a japanese locale, then you should do a graphql query like this:

query MyQuery {
  allPodcasts(locale: ja, filter: {title: {neq: ""}}) {
    id
  }
}

Hope this clarifies a bit! :slight_smile:

So it’s normal/expected that on a model with no localized fields, that query you posted returns results?

Because that seems wrong to me.

Yes it’s normal. A query like this:

query MyQuery {
  allPodcasts(locale: ja) {
    id
    title
  }
}

means: fetch all podcasts and for each podcast, get me the id and the title. If title has a japanese content, show me that content in japanese, otherwise returns me an empty string.

If you wanna retrieve only the podcasts with a title in japanese, then you need to filter like in the previous post :slight_smile:

The filter that rejects records with an empty title does not seem to work anymore.

But using the filter filter: {title: {isPresent: true}} does work.

Another filter that also works is: {_locales: {allIn: [ja]}. In my case I use {_locales: {allIn: [$locale]} and provide the locale as a variable that I use both for the locale property and for the filter:

query MyQuery($locale: SiteLocale!) {
  allSomerecords(
    locale: $locale
    filter: {_locales: {allIn: [$locale]}}
  ) {
    …
  }
}

This is how I tested the filter: filter: {title: {neq: ""}}

  1. Create a new model called LocaleTest
  2. Add the localizable, single line field title
  3. Create two records, one in English with the title “Only English” and one in two languages (in my case English and Swedish) with the title “Multilingual” in both languages
  4. Run the below query and note that both records are returned, one with an empty title
query LocaleTest {
  allLocaletests(
    locale: sv
    orderBy: _firstPublishedAt_DESC
    filter: {title: {neq: ""}}
  ) {
    title
  }
}

Is this still the way to do this? Or is there a more reliable way to know if there’s any localized content in a certain page, other than checking a specific field?

Hi @thiago,

The advice above is still generally applicable, namely that localization happens per-field, not per-record (in the CMS) or per-page (on your frontend). Those are three separate concerns, and the CMS doesn’t “know” which pages on your website correspond to which models/records/fields/locales — you would define all of that in your queries.

What is the underlying problem you’re trying to solve, here? Through the CMA there is a fields query you can use to enumerate all fields of a model and see which ones are localized: https://www.datocms.com/docs/content-management-api/resources/field/instances

But from the frontend via the GraphQL CDA, generally you can use some combination of locales + fallbacks (definable at a field, record, or query level) to get the right data.

If you can please explain your use case a bit more, maybe we can help find the best approach?

Thanks for the response, Roger!

I’m trying to set up a condition on the code to create pages only for languages where we have localized fields filled out. But it seems like I’ve accomplished it with the param filter: {_locales: {anyIn: [de]}}.

Seems like this is a reliable solution.

1 Like