Set a fallback locale

Feature requests
,
#1

It would be nice to set a fallback locale that in case the other locales aren’t filled when you request the particular locale, it would be filled by the fallback locale.

And maybe there’s a switch on the field/model on whether the field is filled with the fallback locale or left as blank/null.

#2

hello @hesedel.pajaron welcome :slight_smile:

Where would you like to see the fallback values? Directly in the APIs?

Currently we have implemented that logic in the Gatsby source plugin and in our Middleman extension, maybe you can already use those?

#3

Hi @mat_jack1, thanks for the reply!
Well, I would’t first think of using plugins meant for other static site generators.
I also wrote my own logic to merge the missing fields.
I assume the plugin also uses DatoCMS Content Delivery API? And fetches both languages then merges?

It would be great if this was already returned by the API when querying.

#4

Yes, I’m not sure what you are using yourself, I mentioned our plugins as examples.

We are using the REST API in the plugins at the moment, we want to switch to GraphQL but it’s not done yet. But yes, we merge the information in the plugin right now.

OK, we’ll consider returning the fallback already in the API, would be good for us too :slight_smile:

1 Like
#5

I’m just using a deepmerge with another language and English.
This is fine at the moment as I’m doing this when building the project.
But I’ll soon be using it on the client side and would rather not have to do the double request and merging there.
Thanks!

#6

definitely useful :+1:

Graphcms has this kind of fallback (https://graphcms.com/docs/reference/localization) that looks nice:

Defining a Fallback

   {
      messages(locales: [de_ch, de, en]) {
        subject
        locale
      }
    }

Locales will be served in the order they are requested, left to right (Swiss German, German, English).

3 Likes
#7

It’s quite strange that localization can be optional but doesn’t have a fallback setting. Such API is quite error prone imo. Also manually querying fallback language results in over-fetching and complexity on the client side. This is quite frustrating for my project since I have to deal with 5 languages, otherwise I would love to use datocms.

#8

I also think the “required” validator on localized fields could improve to “require on primary language” or “require on all languages”.

Right now, if I have multiple localized fields in a model, I want them all required but the user only wants to translate one field, it is not possible. The moment you add a language for a record, every required field must have a value…