We really like the concept of language fallbacks work within the context of the gatsby-source-datocms. One issue that we are working through is the ability to specify required fields on a query. The DatoCMS model allows a field to be localized and required - but a side-effect is that all fields are required to be duplicated when only a single string may vary between locales.
One issue that we are trying to figure out is how to enforce at GraphQL query time the integrity of the data model.
It would be great if the concept of the fallback map that gatsby-source-datocms could be specified within the DatoCMS and used to validate a model upon save. As a workaround we currently have to omit the ‘required’ field so we don’t have maintain duplicate content when customizing ‘en-gb’ from ‘en’.
The downside of this approach is that the GraphQL schema shows that the field values are optional.
Is there a way around this - would it be possible to make country agnostic entries be required, but country overrides be optional?
Hello @todd.brannam
I’m not sure if I’ve understood what you are looking for. Have you already noticed that you can enable localisation on a fields basis? Meaning that fields that are the same across locales do not need translation.
Would that solve your problem?
Yes - we’ve noted the ability to do field level localization - the problem is that we would like to enforce that a model must have required fields when being resolved. If we mark a field as being required - then all the locales must have a value, ideally we would be able to just localize a base language (‘en’) and leave en-gb or en-ca blank, currently this would not pass validation - which makes sense since the CMS itself doesn’t expose the concept of fallbacks (even if just for the validator). Currently we sometime omit the ‘required’ field to reduce duplicated content, but the side effect is that the GraphQL schema indicates the field as optional and we aren’t able to make clear to content authors what is a required field.
Hello @todd.brannam but in your case then how can we enforce that a record has required translations if we do automatically copy over (fallback) the main language to the others? Isn’t the same as marking the translation not mandatory and dealing with that as fallback values?
We should implement fallback values also on the API level and not only in the clients, we agree on that. But I struggle to understand your use case 
Thanks for asking me to try to clarify.
I didn’t mean to suggest that the content would be copied over within the CMS. Instead that the validation rules would only be fallback aware. (from a CMS view perspective, perhaps the UI might indicate that the field already has a fallback mapped value).
My thought process is that models with a large number of fields that are shared in multiple locales could be shared, and when a country specific locale needs a single field to be customized, only that field would need to be edited and maintained. It seems to me that it makes it more clear overtime which content is the same and which ones are customized. My fear is that we need to separately edit 5 english locales which are nearly identical, and lose track of which fields are different for a reason (for country specific copy).
One example we currently have is a ‘string table’ which contains a table of localizable strings. We have an ‘en’ table and a ‘en-eu’ table - the ‘en-eu’ table only needs to override a single entry - the one that is different. We are considering supporting ‘en’ in lots of countries, but keeping a bunch of identical strings seems like it would add some editorial overhead.
yes @todd.brannam I see your point now.
We’ll discuss this internally. Not sure what we can do in the short term about that though. We’ll be in touch as soon as we have news.