BUG: script translations with $gettext does not get extracted/detected

[ndragun92]

App.vue

<template>
      <h2>
        {{ $gettext("My message") }}
        {{ $gettext("My message 3") }}
      </h2>
      <h3>
        {{ data2 }}
      </h3>
      <h3>
        {{ data2ref }}
      </h3>
</template>

<script setup lang="ts">
import { useGettext } from "vue3-gettext";
import { ref } from "vue";
const language = useGettext();

const data2 = language.$gettext("My message2");
const data2ref = ref(language.$gettext("My message2ref"));
</script>

This is my code and when I run gettext:extract I only get My message and My message 3 everything else from script is ignored

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"

#: src/App.vue:35
msgid "My message"
msgstr ""

#: src/App.vue:36
msgid "My message 3"
msgstr ""

[ndragun92]

Package version is "vue3-gettext": "2.4.0"

[ndragun92]

@lzurbriggen is this a known issue?

[lzurbriggen]

@ndragun92 no, this is a case that usually works. can you check if it works if you use destructuring?

const { $gettext } = useGettext();

const data2 = $gettext("My message2");

i'm honestly thinking about removing the whole parser stuff and just use a regex-approach to extract messages, that also has downsides but it would probably be more reliable and reduce complexity.

[ndragun92]

@ndragun92 no, this is a case that usually works. can you check if it works if you use destructuring?

const { $gettext } = useGettext();

const data2 = $gettext("My message2");

i'm honestly thinking about removing the whole parser stuff and just use a regex-approach to extract messages, that also has downsides but it would probably be more reliable and reduce complexity.

That works but for example not sure why assigning such variable loses its reactivity

So from these 3 cases when you change language only 3rd option works which means that you cannot initially set a reactive variable in ref/reactive

const data2 = $gettext("My message2"); // Does not work
const data2ref = ref($gettext("My message2ref")); // Does not work
const data2refcomputed = computed(() => $gettext("My message2ref")); // Works

[dschmidt]

@ndragun92 no, this is a case that usually works. can you check if it works if you use destructuring?

const { $gettext } = useGettext();

const data2 = $gettext("My message2");

i'm honestly thinking about removing the whole parser stuff and just use a regex-approach to extract messages, that also has downsides but it would probably be more reliable and reduce complexity.

We are currently porting our project from easygettext extractor to the extractor that comes with vue3-gettext - we noticed a few occurences of this exact issue.
AFAWCT this analysis was correct (and the title of the issue is misleading): $gettext needs to be destructured from the language object/useGettext() return value. For now it's not a big issue for us, we only have a few occurences and can easily port them to the destructured syntax - but we are afraid to forget about this and lack some translations in the future.

What's your current stance on parser vs regex approach by now, @lzurbriggen?

P.S.: @ndragun92:

So from these 3 cases when you change language only 3rd option works which means that you cannot initially set a reactive variable in ref/reactive

const data2 = $gettext("My message2"); // Does not work
const data2ref = ref($gettext("My message2ref")); // Does not work
const data2refcomputed = computed(() => $gettext("My message2ref")); // Works

This is just how reactivity in Vue works. const data2 = $gettext("My message2"); is essentially the same as doing const data2 = props.someMessage that loses reactivity as well. If you want it reactive, you need to use the 3rd option.
But that's unrelated to this issue.

[lzurbriggen]

I implemented a new, simpler extraction parser that extracts all the messages in the original example.

You don't need to do destructuring with the new parser, but for the sake of robustness, it will also extract stuff like foo$gettext("bar").

Make sure to check the breaking changes though: v4.0.0-alpha.4 and v4.0.0-alpha.2