I'll think what I can do. I'll come back in a couple of days with a plan

I've submitted some code here #1844
@amje, @korvin89, @ValeraS, can you look at this PR, please?

BTW why don't we just accept pull requests with new language keysets? This looks simpler, compared to calling a separate function before the app startup.

But yeah, it prolongs the onboarding process for a foreign project, because you need to either make a fork and fix it there, or to wait for the PR to be accepted

We've talked about it, and the implementation in #1844 lacks proper typing.

The new idea is to infer keys from */i18n/en.json files, something like this:

import type BreadcrumbsEn from '../../../Breadcrumbs/en.json';
import type DialogEn from '../../../Dialog/i18n/en.json';

type Keysets = {
    breadcrumbs: typeof BreadcrumbsEn;
    dialog: typeof DialogEn;
};

function test() {
    const keyset: Keysets = {
        dialog: {
            close: 'Chiudere',
        },
        breadcrumbs: {
            breadcrumbs: 'briciole di pane',
            label_more: 'Di più',
        },
    };
    registerCustomKeyset('it', keyset);
}

But in this implementation we'll need to add newly added component keys manually to this Keysets type, and if the developer of new component forgets about Keysets, our users might see this component untranslated. So I'm thinking about running a little script before every commit with Husky, that will ensure keysets' integrity for us. What do you think, guys? @korvin89 @ValeraS

Also I've heard that you have some parts of code ready, what will we do with it?