Incorrect usage of Trans (Macro)

[whytspace]

Hi,

I m trying to migrate a big project from v4 to v5.
Unfortunately when running the extract command, I get thousands of errors, almost all of them like this:

Error: Incorrect usage of Trans
<Trans id="generic.fields.title" />

In this project, I used lingui extensively, using custom translation ids and reusing ids when the same string is needed mutliple times.
Example:

<Trans id="myCustomTranslationId">
  Something to translate
</Trans>

When I needed the same translation again, I would simply write <Trans id="myCustomTranslationId" />.

This has worked in v2 when I started, through v3 and v4 (v4.7.1) – but now in v5 it breaks (v5.3.0).

Don't get me wrong, I am fine with things working differently in the new version, but right now I am unsure how to migrate…
Do I really have to add the default text to every single usage of the Trans macro, even though it gets replaced by the translation anyway?
Do I have to switch to Trans from @lingui/react (instead of @lingui/react/macro)
Am I missing something? Any ideas on how to move forward? Suggestions welcome! 😀

Thanks in advance!

[timofei-iatsenko]

Do you use Typescript? If yes, you should have tons of errors in the typescript as well.

If you want just to show message by id you need Trans from @lingui/react.

By the way, this is an error-prone, time-consuming and hard to maintenance approach.
I highly discourage you from doing so (using mix of custom ids with text), just write the messages as you would do without i18n, wrap them in Trans (you can use eslint plugin to enforce this) and let the magic happened. Don't need to invent a message key, fight with duplicates or outdated messages and so on. So much easier.

[whytspace]

Do you use Typescript? If yes, you should have tons of errors in the typescript as well.

Yes, I do. And no, I don't have any Typescript errors.

If you want just to show message by id you need Trans from @lingui/react.

Ok, I'll give that a try.

By the way, this is an error-prone, time-consuming and hard to maintenance approach.
I highly discourage you from doing so (using mix of custom ids with text), just write the messages as you would do without i18n, wrap them in Trans (you can use eslint plugin to enforce this) and let the magic happened. Don't need to invent a message key, fight with duplicates or outdated messages and so on. So much easier.

I've been using custom ids mainly for three reasons:

• keys would sometimes change if variable names change. That makes it unmaintainable. I have over 20 languages. Small code changes must not invalidate any of those.
• keys would sometimes change when prettier would reformat the childeren of the component
• Sometimes variables I want to pass into Trans are from nested objects (e.g. {user.name}), function return values (e.g. {getDisplayName(user)}) or components themselves. For easier translation, I want to be able to give the variables a name instead of the generic by index (eg. {0}, {1}), therefore I use values={{ user: getDisplayName(user) }} directly.
• I used the keys to order/group the translations, providing a little bit of context as well

I can't say how much of that is still true witch version 5. As I said, I joined in version 2.
Maybe I have to reconsider my approach…

[timofei-iatsenko]

All problems you listed are fixed now in v5:

keys would sometimes change if variable names change. That makes it unmaintainable. I have over 20 languages. Small code changes must not invalidate any of those.

It now possible to make explicit labeled placeholder so changes to variables name, which by design should not change the behavior would not change the placeholder name

t`Hello ${{name: getName()}}`
t`Hello ${{name}}` // <-- shortcut

There is a eslint rule which forces this pattern, and i also considered an automatic migration and sunsetting of using identifier name as placeholder. It looks useful from first impression but then reveal problems as you mentioned.

I have over 20 languages. Small code changes must not invalidate any of those.

This issue usually solved by TMS, there is a translation memory which helps in 99% of such cases.

keys would sometimes change when prettier would reformat the childeren of the component

Prettier only do safe change which should not affect how the produced code should behave, including JSX. Lingui changed how whitespaces handled in v5, so they are now 100% following JSX spec, and should not diverge from what prettier could change.

Sometimes variables I want to pass into Trans are from nested objects

This is covered with labeled placeholders i described above.

I used the keys to order/group the translations, providing a little bit of context as well

Just relax and let lingui do the job for you. So much relief when you don't need to think about i18n that much because everything happened automatically.

[whytspace]

Hey @timofei-iatsenko,

Thank you very much for the detailed explanation. Very much appreciated!

It now possible to make explicit labeled placeholder so changes to variables name, which by design should not change the behavior would not change the placeholder name

I did not notice the possibility for named placeholders. Nice! 👍

Just relax and let lingui do the job for you. So much relief when you don't need to think about i18n that much because everything happened automatically.

That sounds great. I will give it a try. I will report back here after the refactoring; could be a while 😀

Thanks!