Capitalizing on the fallback locale feature
While adding the first language, it became clear that not every field needed to be translated because there was only a change of dialect, rather than a change in the entire language. On top of that, the team encountered a problem with the GraphQL schema for a new locale.
It turned out that when the translation fields were not filled, they couldn’t build the website because Graphql couldn’t build a data model for non-existent content types, which they were trying to get on the front end. The fallback locale feature came to the rescue.
For example, let’s say we have countries with the same language but different dialects, like Germany (de-DE) and Austria (de-AT). Only a few fields should have different content, so you can use the de-DE fallback for the de-AT page. It means that if you do not manually add the translation for de-AT, the content for this field will be taken from de-DE.
Setting the de-DE fallback to all locales fixed our GraphQL schema issues — temporarily. After a few iterations of adding new languages with de-DE fallback, they realized that this approach wasn’t good enough, because there was a risk that de-DE content would show up in non-German language versions as well.
They started with setting up new languages without the fallback, and of course, they encountered failing builds because of the GraphQL errors again.
At first, to fix this, they started to generate a graphqlSchema file with Gatsby, but it didn’t work as expected. They followed the Gatsby error message to set up dummy content for all content types so that GraphQL could query at least once for each content type. And it worked!
The most significant advantage of Contentful translations is that automated translations don’t have to be set or kept inside the repository. The editors do not have to duplicate the content between locales; they can use just one locale fallback.