Support for abstracted usage of $t

[chrisbarton126]

The application in which I am currently using vue-i18n features an abstraction away from $t such that there is a custom mixin used within the components that handles some additional functionality but ultimately calls $t.

As such, when using vue-i18n-extract I am receiving false-positives on the majority of keys within my language files as it cannot detect them being used in calls to $t by virtue of this being abstracted away from the components.

What would the scope be for adding an additional configuration option which would allow the name of another function(s) to be submitted that could also be taken into account?

[pixari]

Hi @chrisbarton126. Can you provide an example?

I'll analyse it and will create a new issue out of it.

Thank you.

[chrisbarton126]

Hi @pixari

The below mixin is something I use so that in my components I can provide a key as well as a default value. This way if the key doesn't exist then the UI doesn't just render the key value it instead has a valid value to fall back to. As such whenever I run vue-i18n-extract it appears to be loading the .vue files and looking for calls to $t or usage of the <i18n> component, of which my code base has very few / none.

// main.js
Vue.mixin({
  $getDictionaryItem: function(key, defaultValue) {
    // if the key exists on either selected or fallback locales then return the translation.
    if (i18n.te(key, i18n.locale) || i18n.te(key, i18n.fallbackLocale))
      return i18n.t(key, Array.from(arguments).slice(2));

    // key doesn't exist, use the defaultValue parameter to return a formatted string.
    let value = defaultValue;
    if (arguments.length > 2) {
      value = Array.from(arguments)
        .slice(2)
        .reduce((val, item, idx) => {
          return val.replace(new RegExp("\\{" + idx.toString() + "\\}", "gi"), item);
        }, value);
    }
    return value;
  }
});

// Component.vue
<div> {{ $getDictionaryItem("messages.hello-world", "Hello World") }}</div>

Thanks for taking the time to have a look!

[amanpatel]

This is supported by i18next. Why it is missing in i18n community, I'm not sure. Having the default translations within the component files not only simplifies management, but it actually is readable because you don't see some random key when you look at a component template.

Please consider it!

[Spittal]

Hey @amanpatel we intentionally limited the scope of this project to vue-i18n. We have discussed about making this tool more generic so you could supply your own Regex patterns to extract anything matching from your code, but for now that's outside the scope of the project, and unfortunately that includes any custom abstractions for default vue-i18n method names.

[chrisbarton126]

Hi @Spittal I appreciate that the scope of this project is targeted to vue-i18n. @pixari appeared willing to analyse the idea of abstractions, and potentially create an issue from the feature request. Do I assume that the final verdict is that this will indeed not be considered?