Is there a specific reason your translations are in json files, and not using a system such as gettext? IMO those .po files are much easier to translate for non-tech people, especially with many third party apps available for editing them. There are libraries available for many languages, so you don't have to do anything manually in most cases.

Stop reinventing the wheel.

Major translation systems like gettext (especially the GNU variant) have decades of tooling built up for "merging" and all sorts of other operations.

Even if you don't want to use their binary format at runtime, their tooling is still worth it.

I have to spend time looking at all files, figuring out which keys i haven’t added there

It sounds like a simple bash script could do that for you. Take keys from the English language file, compare against other language files, find missing keys for each language.

A trick the indie game development community has used for years is just a simple excel file. CSVs are the easiest to work with if you are unfamiliar. First column is the ID of the text that you can reference in code, and each column is a translation of that text. Get the initial translation in place, typically English, then email the excel file to anyone who ask to create as fan translation. Also, unless you are translating the Illiad, the extra memory use is negligible.

You could write a script that updates other files based on english file. It could put someting like

"key": "UNTRANSLATED"

to missing fields.

Part of my CI/CD is a script that makes builds fail if any of my languages are missing keys, it takes English as the desired result and checks all the keys to ensure they all exist and prints a report of the ones that are missing in csv format so I can send them to translators. I generally run this manually before committing, but having it in the CI/CD helps preventing these errors from making it into production...

Here's some Apache-licensed code that addresses this exact problem. The language files are in CSV format and get turned into JS files as a build step. It prints warnings for strings that are missing from other languages. In dev environments, there's middleware that watches for edits to the CSV files and rebuilds the JS files.

If you are using TypeScript it's quite easy to create a system where the type system will enforce the existence of all translations. I think it should be possible to create a similar solution for other languages as well.

For example:

const enTranslations = { MENU: '' };

const plTranslations: typeof enTranslations = { MENU: '' } as const;

const t = (key: keyof typeof enTranslations) => get language() == 'pl' ? plTranslations[key] : enTranslations[key];

Missing keys will fail compilation. If you want to skip check you can always use //@ts-ignore

Additionally the type system will enforce only valid translation keys so you won't be able to make a typo it forget to add English translation.

There are existing approaches: GNU gettext and Mozilla fluent comes to mind. I would try to use one of those. I understand that Mozilla Fluent has good support for the Web (unsurprisingly).

We return / display the translation key name if no translation is available for that language, including for the default (English).

Also, on dev / test environments we can enable a config (.env) setting to append the text " [UNTRANSLATED]" to every value that doesn't have a translation, as they're easier to spot in the website / interface.

I'm talking about a PHP /Laravel project so it was easy to override the default translation engine behaviour.