ERROR [I18nService] Translation "<key>" in "<language>" does not exist.

[Susccy]

Why is this error constantly thrown in the console despite the translations working fine with fallback languages? If a fallback language is provided, this shouldn't be an error because it is expected and wanted behavior. It should be a warning at most but even then I'd want to be able to disable the log completely as it is totally unnecessary.

[rubiin]

A minimal reproduction is needed

[Susccy]

The behavior can be easily deduced from the source code:

nestjs-i18n/src/services/i18n.service.ts

Lines 102 to 123 in 08b68df

	if (
	translationsByLanguage === undefined ||
	translationsByLanguage === null ||
	!translation
	) {
	if (lang !== this.i18nOptions.fallbackLanguage || !!defaultValue) {
	if (this.i18nOptions.logging) {
	const message = `Translation "${key as string
	}" in "${lang}" does not exist.`;
	this.logger.error(message);
	}
	const nextFallbackLanguage = this.getFallbackLanguage(lang);
	if (previousFallbackLang !== nextFallbackLanguage) {
	return this.translate(key, {
	...options,
	lang: nextFallbackLanguage,
	});
	}
	}
	}

The unnecessary error is logged in line 111. As you can see it will still try more languages after the error is logged, meaning it is expected behavior when utilizing fallback languages and thus not an error. Here it should be a warning at most.

Only if the translation couldn't be found in any fallback language, then it should throw an error.

[toonvanstrijp]

@Susccy I agree that the log on line 111 should not be presented since it's indeed expected behaviour. Would you be able to create a PR that removes this log, but still gives a log when the translation couldn't be found in any fallback language?

[Susccy]

I will look into it when I have time.

[rubiin]

I will probably push a fix . What are we going to name the option though. enableTranslateLog with default being true so as to not break backward compatibility

[Susccy]

depends on your exact goal @rubiin - do you want to keep the default log as an Error or change it to a Warning?

Personally I think the most logical solution would be to change the current Error log to a Warning (for when more fallbacks are still available) + adding an additional Error log for when all fallback langs have been tried but didn't work. Then the new option disableMissingTranslationWarning: boolean (default false), when set to true, would disable the warning logs but keep the error log.

[Susccy]

I don't see how changing this log in any way could break backwards compatibility as it's just a log, nothing actually functional is happening here.

[rubiin]

yeah true

[abouroubi]

Is there any news on this ?
The log is pretty much polluting all our log files

[rubiin]

you could use logging: false