Macro: t inside t causing ReferenceError: t is not defined

[Kepro]

Describe the bug
t inside t causing ReferenceError: t is not defined

btw Trans in Trans is working

To Reproduce

try code

import { t } from "@lingui/macro"

t`Field ${t`First Name`} is required`

why t in t? for YUP validation schema error messages...
e.g.

Yup.string().matches(/^([0-9]{16})$/, t`'${t`First name`}' must be ${16} characters.`),

Expected behavior
t in t should work

Additional context
Add any other context about the problem here.

I can reproduce it also with fresh CRA

• jsLingui version lingui --version 4.6.0
• Babel version npm list @babel/core @babel/core@7.22.8
• Macro support:
• I'm using SWC with @lingui/swc-plugin
• I'm using Babel with babel-macro-plugin
• I'm not using macro
• Your Babel config (e.g. .babelrc) or framework you use (Create React App, NextJs, Vite)

module.exports = {
    presets: [['@babel/preset-env', { targets: { node: 'current' } }], '@babel/preset-react', '@babel/preset-typescript'],
    plugins: ['babel-plugin-macros', '@babel/plugin-transform-runtime'],
};

[timofei-iatsenko]

Yup.string().matches(/^([0-9]{16})$/, t'${tFirst name}' must be ${16} characters.),

is it a real example? Still don't understand the need for using t in t.

This i suppose known issue, the macro treat {t`First name`} as a variable and keep it intact, so t is not transpiled.

May I ask what you expect to get in extracted messages in this case?

[Kepro]

Hey, yeah, it is a real example... just migrating our legacy translation system to Lingui
old message format was UPPER_CASE and the second parameter was values e.g.

const FORM_MAX_CHARACTERS = "[FIELD] must be [NUM] characters";
t("FORM_MAX_CHARACTERS", { FIELD: t("FIRST_NAME"), NUM: 16 }

in the whole application, we are using Macro t and Trans and hash-generated IDs

I know I can use i18n._ but then I need to provide id which we don't want...

May I ask what you expect to get in extracted messages in this case?

basically {0} must be {1} characters

but if it is a limitation of babel-macro and there is nothing to do, then we can close it

[timofei-iatsenko]

Yeah, you probably can solve this differently in your code. This is not a limitation of babel-macro itself, rather how lingui macro is written, and i don't really want to touch it since it may break something else.