Dynamic values are pretty much impossible

[lukescott]

Describe the bug
The id is stored in the localization file. If you remove it manually, it falls back to id in i18n._. If your message is a variable, Lingui refuses to use it.

To Reproduce

{i18n._({
  id: "address.label",
  message: label,
})}

OR

{i18n._({
  id: "address.label",
  message:"",
}) || label}

In either case the extractor sees message as "", so it falls back to id.

Then if you manually remove it from the file (which it will store again on next run because it sees it as empty), this line falls back to id again:

https://github.com/lingui/js-lingui/blob/main/packages/core/src/i18n.ts#L234

Expected behavior
I expect to be able to use a dynamic value as a fallback.

Additional context

I have pre-localization values that are user provided. They are basically custom text field labels. For this particular id the localization value will always be empty "". When it is empty it should fall back to the pre-localization value (without error).

What we are planning to do is provide a localization section where the user can override specific labels for a specific localization. The pre-localization is essentially what we would consider the user's "base language".

Proposed Solution

Do not fall back to id for extract, and do not fall back to id in i18n._.

This should be possible but currently isn't because i18n._ always returns a non "" value.

{i18n._({
  id: "id1",
} || i18n._({
  id: "id2",
})}

Perhaps consider checking for undefined instead of falsy so you could do something like this as a compromise:

{i18n._({
  id: "id1",
  message: "",
} || i18n._({
  id: "id2",
  message: "",
}) || "my own debug message"}

[lukescott]

Looks like the compiler also default to id... So even when I use a custom formatter and clear out the id as a translation, the compilation falls back again. This is really frustrating.

[timofei-iatsenko]

Both examples are misuse of a library. The message field is used only, and inclusively, for extractor. It usually got removed from production bundle and not actually used to show a message. Catalogs are also static and precompiled thing. So your code

{i18n._({
  id: "id1",
} || i18n._({
  id: "id2",
})}

Just have no sense, because if you know that id1 would be empty ahead of time, you can write it directly in your code.

Also "dynamically" provided by user message will not work as well. Because messages should be compiled beforehand. So if you want to do something like this (pseudocode):

"Hi {name}" (from user) || "Hello {name}" (from catalog)

The interpolation for user messages will not work. If you want to use without interpolation, so it's easy as

userMessage (variable from user) || "Hello world" (from catalog)

[lukescott]

I ended up doing something like this:

t(i18n)({
  id: "id1",
  message: `${label}`
})

OR

<Trans id="id1">
  {label}
</Trans>

Which in the translation produces id1: "{label}". This makes take user input by default, and allows us to override with user translation later.

I know the messages have to be compiled. We plan to compile the user's input and combine them with precompiled system language. User provided language translations is essential. Our system isn't static and has user generated content.

The reason for this use-case (tweaked a bit for clarity):

{i18n._({
  id: "id",
 message: "default translation for instance"
} || i18n._({
  id: "id/" + instanceId,
})}

The default translation "id" is for a specific block type (user is building content). There can be multiple instances of the same block, so we need a way to override a specific instance with a secondary id.

So id is predefined, but "id/" + instanceid is never defined ahead of time.

I actually found a way to satisfy this use-case by wrapping I18n in a Proxy and I check for "id/" + instanceid and then fallback to "id". It's probably a better solution anyway because we don't have to manually specify the "id/" + instanceid variants.