feat: Extract strings starting with a variable followed by a space or 's

[Stadly]

Problem

The default script heuristic ignores strings where the first character is a non-letter character:

If the first character is a lowercase English letter ([a-z]) or is any non-letter character, it is ignored.

This means template literals that start with a variable like:

const message = `${organization.name} was successfully deleted!`;
const message = `${user.email}'s role was updated to ${user.role}.`;

...are not extracted, because the resolved first character is $ (from ${}), which is a non-letter. However, these are clearly translatable natural language strings — they just happen to start with a placeholder.

Proposed heuristic change

If a string in script context starts with a template expression (${...}) followed by either:

• a space (e.g. `${name} was successfully deleted!`)
• 's (e.g. `${name}'s role was updated`)

...it should be extracted by default, since these patterns strongly indicate natural language content meant for users.

Other characters that commonly follow a leading ${...} — such as /, ?, :, -, ., or another $ — are structural/technical (paths, query strings, class names, filenames) and should continue to be ignored.

Current workaround

The only workaround is adding // @wc-include above every such string:

// @wc-include
const message = `${organization.name} was successfully deleted!`;

This is repetitive and easy to miss, especially when the pattern is common across many files.

[K1DV5]

Yes I ran into this, but I wasn't sure what pattern to look for to prevent false positives, because it can also be other strings. Maybe it can be like "first char is not a letter and the string contains letters and spaces"? That may work. Will include it in the next version.

[Stadly]

Thanks. If you send me the function you plan on using and a hint how to set it up I can try it on my code base to see if there are many false positives.

[K1DV5]

Great! I will.

[Stadly]

Did some testing. In our code base, your suggestion produces lots of false positives:

• Tailwind classes (this is the main driver of false positives), such as -mt-2 px-0, [--row-bg:var(--background)] px-0, **:data-command-group:px-2 mx-0, @container/card-header grid
• CSS styles (also quite a lot of these), such as --sidebar-width: {0};, --normal-bg: var(--color-popover);
• Cookies with variable name, such as document.cookie = `${SIDEBAR_COOKIE_NAME}=${open}; path=/; max-age=${SIDEBAR_COOKIE_MAX_AGE}`;

So I think first char is not a letter is too loose. How about this one? Extract strings where either:

• First char is a number and the string contains letters and spaces
• String starts with a variable (something that is replaced by {0} in the .po file) and contains letters and spaces

I think that would leave the cookie as the only false positive in our code base, and there would not be any false negatives as far as I know.

[K1DV5]

Yeah that's what I was afraid of. But your suggestion seems better. Is there no false positive caused by the First char is a number in your codebase?

[Stadly]

I have only tested on one part of the code base, and found no false positives. I can do a more thorough test later this week. We can also just start with extracting strings starting with a variable and then add strings starting with a number later after some more investigation.

[Stadly]

I've now run in through the rest of our code base.

• Strings starting with a variable: No additional false positives, just the cookie one.
• Strings starting with a number: No false positives. Only used for two types of strings in my code base:
  1. Dummy texts, like "1 hour ago" on our design system page showcasing different components with static content.
  2. Describing people, like "6 years of experience from ..."
• Strings starting with other characters: Lots of false positives, and a few cases worth mentioning:
  1. Markdown strings such as # Header. (Probably debatable whether this is something that should be translated using wuchale).
  2. Strings starting with a space, like name + " has been created". But much better to change this to ${name} has been created and have it covered by strings starting with a variable.

Here is my assessment:

• String starts with a variable and contains letters and spaces: Let's extract it by default!
• String starts with a number and contains letters and spaces: I think this one is useful too, but not as important.
• String starts with any other non-character: Keep ignoring it.

[Stadly]

Have you had a chance to look into this, @K1DV5? Thank you so much for your hard work! ❤️

[K1DV5]

Hi @Stadly, sorry for the delay. Yes your idea seems reasonable. I was gathering my ideas for #377, which may also affect the heuristic function, that's why. But I plan to include it in the next version with the current changes. And thank you 🙏