nuxt-modules / i18n

I18n module for Nuxt
https://i18n.nuxtjs.org
MIT License
1.71k stars 478 forks source link

Support per-component translations using `experimental.autoImportTranslationFunctions` #2900

Open MorevM opened 5 months ago

MorevM commented 5 months ago

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

Final checks

BobbieGoede commented 5 months ago

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:

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