In a JSON file, allow references to other keys

I’m submitting a … (check one with “x”)

[ ] bug report => check the FAQ and search github for a similar issue or PR before submitting
[ ] support request => check the FAQ and search github for a similar issue before submitting
[ x ] feature request

Current behavior

Today, we can only set strings and variables like {{myVar}}. It would be great to be able to include other existing keys (like a partial translation).

Expected/desired behavior

{
   "greetings":"Hi",
   "text":"[greetings] from Github!",
   "text2":"[greetings] there!"
}

myService.get('text').subscribe(
    (value) => {
         console.log(value);
         // Hi, from Github!
    }
);

What is the motivation / use case for changing the behavior?

Today, we have to concatenate the translations on our side:

myService.get(['greetings', 'text']).subscribe(
    (translations) => {
         console.log(translations.greetings + ' ' +  translations.text);
    }
);

[SamVerschueren]

Don’t see any valid reason to do that. Just repeat the Hi and make it inline. This would just add complexity to the library without a real benefit imo.

[pfeigl]

This can be easily implemented via a TranslateCompiler (see ngx-translate documentation on how to register it). We are using this simple implementation:

export class TranslationCompiler extends TranslateCompiler {
    public compile(value: string, lang: string): string {
        return value;
    }

    public compileTranslations(translations: any, lang: string) {
        for (const key in translations) {
            if (translations.hasOwnProperty(key)) {
                translations[key] = this.resolveReferences(translations[key], translations);
            }
        }
        return translations;
    }

    private resolveReferences(value: string, translations: any) {
        return value.replace(/@:(\S+)/, (matches, key) => this.resolveReferences(translations[key], translations));
    }
}

Please be aware of the following problems you might face with this very simplistic implementation:

• The compiler does support recursion, but does not check for infinite loops (aka back-and-forth references)
• The compiler does not support nested translations
• The compiler does not work with the compile method, as at this point the translations are no longer known (would require to keep track of all translations based on their language and merge them if multiple setTranslation calls for the same translation would be made)
• Because of obvious syntax restrictions, the compiler can only reference keys which do not contain whitespace-characters