Vue-i18n: Adding `scope` option to translations

[SzNagyMisu]

Feature request

I would like to be able to do the following in components:

this.$t('message.path', { scope: 'my.very.long.scope.to.the.message' })
// or
const myScope = 'my.very.long.scope.to.the.message'
this.$t('message.path', { scope: myScope })

or even better:

const MyComponent = {
  template: `<p v-t="'message.path'"></p>`,
  i18n: { scope: myScope }
}

So basically, my goal would be to have my locale messages in one place and provide a socpe for a component, so that I can type less when translating lots of deeply nested messages.

All I can do now is:

const MyComponent = {
  template: `<p v-t="myScope + '.message.path'"></p>`,
  data () {
    return { myScope = '...' }
  },
  // and
  methods: {
    translateMessage (message) { return this.$t(`${this.myScope}.${message}`) }
  }
}

But having a scope option for components would be more elegant (or, at least, less cumbersome...).
Of course, the fallback logic should be considered too.

@kazupon what do you think?

Also, I would be more than happy to try and provide a PR for the feature.

---

IssueHunt Summary

Backers (Total: $15.00)

• 0maxxam0 ($10.00)
• varna ($5.00)

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.
  

[kazupon]

Hmm 🤔, Certainly it maybe useful to support it.

Typically, As a sign that the path becomes longer, I think that we can not be managing the locale messages well.
When the locale messages gets bloated, I recommend using SFC i18n custom block. As a result, the path will be simple, due to you can manage locale messages on a component units

[SzNagyMisu]

@kazupon I think there is truth in what you say, so I will just try and use SFC I18n custom block whereever it is possible.
Thanks for the idea!

Should I close the issue?

[vansteki]

+1 for scope option
SFC i18n custom block is good.
But I think the scope is also a helpful and practical feature.

[Bosee]

+1 for scope option
very useful for large project

[bponomarenko]

it is possible to achieve the same result with built-in filters, which will syntax nicer:

```js
const scoped = key => 'root.scope.' + key;

const MyComponent = {
filters { scoped: scoped },
template: <p v-t="'.message.path' | scoped"></p>,
methods: {
translateMessage (key) { return this.$t(scoped(key)) }
}
}

[IssueHuntBot]

@0maxxam0 has funded $10.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[Nettsentrisk]

This seems to be a parallel to the namespaces option in the vue-i18next library or the keyPrefix option.

When you're building a large application, or a web site, you will typically want to split up your translations into namespaces/groups/sectors. The key paths would then reflect this.

However, let's say you want to use translations in a component, but you only want to use translations from a certain namespace in that component. Having to write out the entire path is cumbersome.

So if you set a namespace/scope/prefix option on the i18n options for a component, then you will be instructing $t() etc. to prepend/use the namespace/scope/prefix to all calls to $t() within that component.

So instead of $t('components.componentName.level1.level2') you could have $t('level1.level2') by setting the namespace/scope/prefix to components.componentName.

[paulgeisler]

How is this feature coming along?

[matthew-white]

I work on a project with volunteer translators who contribute using Transifex. We're adding internationalization to a Vue project now, and I think our workflow will be similar to the one that Vue CLI uses for Transifex: en.json is imported to Transifex as it changes, then Transifex exports a JSON file for each locale.

With this workflow, I think it'd be difficult to use SFC i18n custom blocks. However, it's a fairly large project, so paths can also get fairly long.

I think being able to add a scope option to a component would be very helpful. I also think it'd be helpful for components to be able to access paths outside the scope in case they need to mix scoped messages with more general messages. (For example, a component that mostly only needs messages under a specific path might also need to access the localized app name.) Maybe it could work in a similar way as fallbackRoot?

[varna]

I started using i18next a year ago because of namespaces feature. Still regularly checking progress here.

[issuehunt-app[bot]]

@varna has funded $5.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.