Vue 3 support

[leokolezhuk]

🚀 Feature Proposal

Currently the usage of vue-template-compiler in this package prevents using the parser in a vue 3 project.

Supporting both vue 2 and vue 3 versions would be very beneficial I believe.

Motivation

Example

Please provide an example for how this feature would be used.

[Toilal]

Maybe a simple solution would be to make vue-template-compiler a peerDependency.

[leokolezhuk]

Maybe a simple solution would be to make vue-template-compiler a peerDependency.

I think that wouldn't be enough as vue-template-compiler is used directly in the vue lexer. In case of vue 3 that would need to be updated to use the @vue/compiler-sfc package instead.

I would perhaps move out the VueLexer out of this package. Then you can maybe have separate lexers for vue2 and vue3 in another package.
I am not even using this VueLexer for vue SFC files - I have defined a custom lexer for them that is based on the JavascriptLexer.
And that is a pity as there is nothing else apart from the presence of the VueLexer, that prevents us from using this package with vue3.

[karellm]

You are welcome to make a PR to solve the situation! I will review and merge it.

[leokolezhuk]

You are welcome to make a PR to solve the situation! I will review and merge it.

Hi @karellm,

I am open to doing that.
But while thinking about how to approach it best, I am coming to the conclusion that this VueLexer might not even be needed at all. Please, correct me if I am wrong on this.

So in Vue SFC files you have the template and script sections that can contain localizable messages. Regardless of where the message is defined, template or script, it will still be wrapped in a function $t() or t(). Therefore, it seems to me that the JavaScriptLexer alone is enough to deal with this case. That is how I am using the parser in my project as well - with the same lexer config for js and vue files. There is no need to compile the .vue file as the VueLexer does it, you can just parse it as a normal JS file then.

The only case that is not covered with this approach is when one would use a i18next vue wrapper like this one and uses the directives(HTML attributes) to define localizable messages. But this case is not covered with the current VueLexer either. But if you use the HTML lexer in combination with the JS lexer for a case like this, you should be covered.

To sum up at this point I actually see no reason for the VueLexer to exist even for vue users.
Removing it would also remove the nasty vue-template-compiler dependency that prevents usage with vue3.

What do you think, @karellm ?

[pascalvos]

i agree remove it 👍 its causes more problems / peer dependency

[do-web]

You can use my fork with vue 3
https://github.com/do-web/i18next-parser

[karellm]

I don't recommend using a fork, make a PR and have it merged into the main project.

[karellm]

Should be fixed as of 9.0.0

[poicooler]

I seem to have a slight issue using version 9.0.0 with vue 3.

When using the translation function in a prop, it is not detected by the parser.

Exemple in some vue files:

<template>
  <button :aria-label="t('button aria label')">
    {{ t('button label') }}
  </button>
</template>

...

In this case, "button label" is detected and thats fine. However, "button aria label" is not detected and is ignored.

[daniel100097]

Does anyone have a solution for parsing attribute translations ?

like this:

:attr="t('languagekey')"

[PBK-B]

I seem to have a slight issue using version 9.0.0 with vue 3.

When using the translation function in a prop, it is not detected by the parser.

Exemple in some vue files:

<template>
  <button :aria-label="t('button aria label')">
    {{ t('button label') }}
  </button>
</template>

...

In this case, "button label" is detected and thats fine. However, "button aria label" is not detected and is ignored.

@karellm According to your description, it feels like this matching should be effective, but I still can't get it correctly when I test this usage. Is there any progress on this?