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:

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-oss[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.

[geauser]

Any updates on this feature request?

[kuba-lilz]

When the locale messages gets bloated, I recommend using SFC i18n custom block.

Perhaps I'm not seeing an obvious workaround, but using SFC i18n custom block means that the only practical way to manage translations is to let translators access whole code repository, work directly inside source code and require them to use version control tools. Something businesses might not be happy doing when outsourcing translations, and many translators wouldn't be comfortable with due to technical barrier.

Is there a way to at least import content into SFC i18n custom blocks? Something conceptually similar to:

<script>
import englishTextData from "~/languages/english.yaml" ;
import japaneseTextData from "~/languages/japanese.yaml" ;
</script>

<i18n>
{
  "english": englishTextData.pageA.componentB,
  "japanese": japaneseTextData.pageA.componentB
}
</i18n>

which of course doesn't even compile.

On a side note - I would take an exception with automatically proclaiming large translation files as bloated without examining the project.

[xmcx3]

const genNS = (ns: stirng) => ((key: string) => `${ns}.${key}`)

const ns = genNS('hello.world')

this.$t(ns`path`)

[FabianMontoya]

How is this feature coming along? It should be a must of this library