Support per-component translations using experimental.autoImportTranslationFunctions

[MorevM]

Describe the feature

Auto-import of $t is a great feature, but it clutters the console with messages in case per-component translations are used (no matter if they are used together with global translations or only them).

I know I can turn these messages off, but I'd rather not do that - they might be useful in case of a typo or something.

Currently (with the experimental feature turned off), I split imports like this:

const { t } = useI18n({ useScope: 'local' });
const { t: $t } = useI18n({ useScope: 'global' });

const globalMessage = $t('globals.send');
const localMessage = t('something-related-only-for-this-component');

I have some global translations that are used in many components / composables, and I have local translations that only relate to one component, and I'd like to keep those mechanics but take advantage of the auto-import feature without cluttering up the console.

---

Technically it looks pretty straightforward to import { t, d, n, ... } using local scope together with { t: $t, d: $d, n: $n }, but I'm not sure what else this approach might affect.

Minimal reproduction: https://stackblitz.com/edit/bobbiegoede-nuxt-i18n-starter-6x9weq?file=pages%2Findex.vue

What do you think?

Additional information

• Would you be willing to help implement this feature?
• Could this feature be implemented as a module?

Final checks

• Read the contribution guide (The contribution guideline of nuxt-modules/i18n is compliant with Nuxt too).
• Check existing discussions and issues.

[BobbieGoede]

The current behaviour is specifically made to mimic the globally injected properties (excluding $i18n for now) in the component template, see https://vue-i18n.intlify.dev/guide/advanced/composition.html#implicit-with-injected-properties-and-functions, this also describes the reasoning for prefixing with $.

I do see the value of having auto imported/initialized translation functions using the local scope in your use case, if we want to add this functionality it would still need to be prefixed with something else so we don't end up polluting the script with these variables.

First things that come to mind would either be:

• Prefixing with $l which communicates local scope
  • e.g. { t: $lt, d: $ld, ... }
• Prefixing with $$ which communicates a deeper scope
  • e.g. { t: $$t, d: $$d, ... }

I'm open to suggestions and curious if more projects would be interested in this feature.