Use of local messages in composable

[faber-mondata]

Clear and concise description of the problem

In my current project, I use component specific message files in local i18n scopes which works amazing!:

// component.vue
<script setup lang="ts">
  // Imports
  import { useI18n } from "vue-i18n";
  import i18nMessages from "./component.i18n";

  // I18n
  const { t } = useI18n({ messages: i18nMessages });
  
  const projectStatus = getProjectStatus(project);

  </script>

{{ t("component.message") }} 

{{ projectStatus }}

But if I want to do the same for a composable:

// composable.ts
  // Imports
  import { useI18n } from "vue-i18n";
  import i18nMessages from "./component.i18n";

  export function getProjectStatus(project) {
      const { t } = useI18n({ messages: i18nMessages });
      
      if(project.problem)
           return t("status.problem");
      else
           return t("status.noProblem");
  }

It doesn't work, because both calls of useI18n will execute on the same component. And the result will be:

Important Component Message // From the component.i18n messages

status.problem 

Suggested solution

1. I missed something and it's already possible => I'll improve the docu
2. Allow stacking of useI18n by calling useI18n to create new scope on top of the "current one"

Alternative

Merge messages into the existing i18n instance:

const { t, locale, mergeLocaleMessage } = useI18n();
mergeLocaleMessage(locale.value, i18nMessages[locale.value]);

But then the composable directly affects the messages of the component, which can lead to undesired side effects, when both use the same key.

Additional context

No response

Validations

• Read the Contributing Guidelines
• Read the Documentation
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[mrleblanc101]

@kazupon 11.1.6 seems to have introduced a huge breaking change !
11.1.6 broke multiple of our projets because of this change.
In our case, we have const { t } = useI18n() inside a Pinia Store.

[mrleblanc101]

I guess it's an error on our end, but it's not clear !
Simply changing from const { t } = useI18n(); to const { t } = useI18n({ useScope: 'global' }); fixed the problem.
It make sense, since a composable or a Pinia store don't have a <i18n> customBlock, but shouldn't this error ignore those ? Otherwise, the error should like to the documentation with a detailed explanation.

[mrleblanc101]

Sorry, I'm not sure this is 100% related.
I copy-pasted the error message exactly and Github search gave me this ticket, but I realize this issue does't mention my error message exactly.

[kazupon]

Just this issue, I fixed that we call useI18n twice in locale scope in #2203
anther, reproduction.
https://codesandbox.io/p/devbox/w42jlm?file=%2Fsrc%2FApp.vue

This issue has been fixed in the PR, but as mentioned in issue #2223, the fix is still incomplete, and some people are calling useI18n multiple times within the local scope of composable. Therefore, we plan to revert the change and make it an opt-in option in createI18n.

[faber-mondata]

The problem with the fix of #2203 is, that it doesn't solve the issue of wanting to instantiate an i18n instance with a composable specific local scope. Maybe it's just me, but I see a great benefit in also scoping composable messages to avoid polluting the global i18n scope and making them more modular.

The reproduction https://codesandbox.io/p/devbox/w42jlm?file=%2Fsrc%2FApp.vue helps a lot to visualize the issue.
My proposal is, that both components and the clockMsg should work. So there would only be "green ticks" here https://codesandbox.io/p/devbox/vue-i18n-test-forked-xdqsm5?file=%2Fsrc%2Fcomponents%2FComp1.vue

[ebisbe]

How should we handle the case of wanting to use translations inside a composable? The composable should expect to get the translations or something related to the global scope?