Dynamic translation keys

So I’m not sure how to solve this really, but here’s the problem.

It picks this up as a Missing i18n Entry lang.label.${choice}

And in my lang files it picks these up as Unused i18n Entry

lang.label.ar-AE
lang.label.de-DE
lang.label.en-US
lang.label.es-ES
lang.label.fr-CA
lang.label.fr-FR
lang.label.he-IL

My code has this within a loop where choice is one of [ar-AE, de-DE, en-US, etc]:

<label :for="choice">{{ $t(`lang.label.${choice}`) }}</label>

Could your tool treat the ${choice} as a wildcard somehow and therefore not flag these items as missing?

[ghost]

Proposal 1

A quick workaround could be a “classic” ignore comment to tell vue-i18n-extract to ignore some entries we know are highly dynamics.

code:

translateOption(field, opt) {
  return opt === null || opt === '' ? '' : this.$t(`${field}.${opt}`); // vue-i18n-extract: ignore
},

translation:

export default {
  field: {
    example: 'some translation', // vue-i18n-extract: ignore
  }
}

---

Proposal 2

Building on the previous example we can use the comment to “tag” the dynamic lines with the used strings, as a mapping, to avoid dangling translations in case of refactoring.

code:

translateOption(field, opt) {
  return opt === null || opt === '' ? '' : this.$t(`${field}.${opt}`); // vue-i18n-extract: tag=ABC
},

translation:

export default {
  field: {  // vue-i18n-extract: ABC:field
    example: 'some translation', // vue-i18n-extract: ABC:opt
  }
}

[Spittal]

Yeah there are several occasions where you want some dynamic content in your paths. I’ve seen this with:

1. The v-t directive that allows for an object to be passed through, as opposed to a string literal.
2. A case that I patched out a while ago https://github.com/pixari/vue-i18n-extract/commit/30fb684b2a25fb1e3dcdb7ff32e165dde9e26e6d which allows for using a dynamic :path in a <i18n> component
3. A template literal variable like in the example the OP posted.

I’ve thought a lot about how we can achieve support for dynamic paths… Let me sort of ‘brain dump’ here and maybe someone smarter than me can chime in:

1. Recognize via the RegExp matchers that an I18NItem path is dynamic. Dynamic can mean different things (see the list above) so we need ways to know which ‘type’ of dynamic path we have.
2. Somehow get the component name associated with the dynamic path. This is harder than is sounds, because we can’t assume the template and component script are always in the same file.
3. Once we have the component name, boot up the Vue app and find the component based on it’s name. This isn’t full proof because we’re just assuming that the component will be in the tree, which isn’t always the case…

This is where I hit a wall, there isn’t some ‘full proof’ way to evaluate the dynamic path without making a lot of assumptions about the users source code.

So, I’m open to hearing some other solutions. Or, possible workarounds we should document to make sure users know that this is a limitation of the library.