As an agency, we want to have a default development locale.
Reproduction steps
Create a new GitHub repo and init a new theme.
Ignore all locales as you should never override this for the client.
Add a default EN locale and maybe another one.
Push the theme to a store.
Add/remove a translation from the EN default and release the theme on a new version.
This is the point you find out you can’t add or remove translations in your release as the .json should be ignored, because otherwise you’re about to override the clients added translation in the translation editor.
Additional info
As an agency it is really hard to add, update or remove translations without having a default locale that the client doesn’t have to use at all.
We ignore all locale json files, so we never override the custom translations of the client.
This is a really common pain point for agencies managing themes across multiple stores — I’ve seen this come up a number of times. The core challenge being that you need to ship new translation keys with releases, but you can’t push locale files without overwriting the merchant’s customized translations.
I can see you’ve already opened a feature request on the theme-tools repo for a dedicated development/fallback locale file — that’s the right place for it.
In the meantime, a couple of patterns other agencies have used:
A separate “source” locale file (e.g. en-dev.default.json) that you maintain in version control, with the actual en.default.json gitignored. On deploy, you copy the source into place. This is clunky but gives you a separation between your keys and the merchant’s overrides.
Using schema locale files (en.default.schema.json) for anything that can live in section/block schema — these are less likely to be edited by merchants directly and can be safely pushed.
That said, these are workarounds, not solutions. The idea of a fallback locale that provides default values for keys the merchant hasn’t customized is solid, and I’ll flag this internally as well.