Hi,
I don't know if i misread the documentation or if it's a bug.
I did copy/paste the following example from the documentation:
<p>
<Plural
value={messagesCount}
one={`There's # message in your inbox, ${name}`}
other={<Trans>There're <strong>#</strong> messages in your inbox, {name}</Trans>}
/>
</p>
When i extract the translations i get:
msgid "{messagesCount, plural, one {There's # message in your inbox, {name}} other {}}"
msgstr "" // here i copied the id
So when the count is '1', i get the correct translation (with the correct values). If i force the value attribute to 2 i got nothing (empty string).
Have you used Trans from @lingui/macro or from @lingui/react? I haven't tested this out yet, but it might work with macros only.
Either way, the safe bet is to use template literal (backticks) which should be working just fine.
You're right, i forgot to mention i use the macro.
I use the Trans macro because i need to inject some components into my translation (<strong/> in the example)
I pasted this code into the webpack-react example :
<p>
<Plural
value={messagesCount}
one={`There's # message in your inbox, ${name}`}
other={<Trans>There're <strong>#</strong> messages in your inbox, {name}</Trans>}
/>
</p>
When i re-run the messages extraction, i don't get a new entry.
If i wrap the p tag into Trans i get ths following new entry :
msgid "<0>{messagesCount, plural, one {There's # message in your inbox, {name}} other {There're <1>#</1> messages in your inbox, {name}}} </0>"
Is it the exected behavior? In this case, i think we could make the documentation more explicit about the nesting possibilities.
I get the expected behavior for my use case with the following syntax:
<Trans id="messages.count">
<Plural
value={messagesCount}
one={`There's # message in your inbox, ${name}`}
other={<Trans>There're <strong>#</strong> messages in your inbox, {name}</Trans>}
/>
</Trans>
Hey @ghostd, this is definitely a bug. I'm just refactoring macros, so I'll take a look.
Any progress on this? I'm running into the same issue. I've tried using macros and the react versions, though neither work.
Got same bug.
Had to set "few" and "many" props, then translations appeared. As I can see, empty (or not set) "few"\"many" prop doesn't result in fallback to "other" prop.
Hmm, I'm running into this issue as well, but I added "few" and "many" and am still getting a "missing" warning, even w/ fallbackLocale and sourceLocale specified:
module.exports = {
localeDir: '__generated__/locales',
srcPathDirs: ['src'],
format: 'po',
fallbackLocale: 'en',
sourceLocale: 'en',
pseudoLocale: 'en-PL',
};
import { Trans, Plural } from '@lingui/macro';
…
<Trans id="speakers.count">
About the{' '}
<Plural
value={data.video.presenters.length}
one={<Trans>speaker</Trans>}
few={<Trans>speakers</Trans>}
many={<Trans>speakers</Trans>}
other={<Trans>speakers</Trans>}
/>
</Trans>
#: src/components/slug/info-details.tsx:57
msgid "speakers.count"
msgstr "About the {0, plural, one {speaker} few {speakers} many {speakers} other {speakers}}"
#: src/components/slug/info-details.tsx:57
msgid "speakers.count"
msgstr ""
In the ui, I'm seeing the "fallback" text applied in I18nProvider no matter which locale is active:


any workarounds?
This may be related to @VinSpee's problem. I've noticed a problem when using <Trans> nested within <Plural>.
It seems as though import order matters:
import { Plural, Trans } from '@lingui/macro'; // results in correct behaviour
import { Trans, Plural } from '@lingui/macro'; // results in incorrect behaviour
Given the following translation:
<Plural
value={totalCount}
one={
<Trans>
<strong>#</strong> Issue
</Trans>
}
other={
<Trans>
<strong>#</strong> Issues
</Trans>
}
/>
When I import in the "incorrect order", I get the following:
// Trans before Plural
import { Trans, Plural } from '@lingui/macro';
msgid "{0, plural, one {} other {}}"
msgstr "{0, plural, one {} other {}}"
When I import in the "correct order", I get the following:
// Plural before Trans
import { Plural, Trans } from '@lingui/macro';
msgid "{0, plural, one {<0>#</0> Issue } other {<1>#</1> Issues }}"
msgstr "{0, plural, one {<0>#</0> Issue } other {<1>#</1> Issues }}"
The latter example here is what I expect in both scenarios.
We are using:
@lingui/loaderbabel-plugin-macrosYea, macros tend to suffer from ordering issues. It's kinda logical when you think about it. If Trans is first, it does its job of core transformation, and then Plural does its part but Trans no longer has an option to see that and modify its output accordingly.
Honestly, I don't know about any good solution for that. Only that Trans would need to analyze more deeply and if it sees a "known" macro, it would scream a warning.
This is already fixed in v3 (please checkout pre-release #334).
Ordering of imports doesn't matter, the top-most macro is always processed first and "consumes" all inner macros.
Hello guys. I have a similar issue (or maybe not). I have all working fine locally, but on production, something is wrong:
Local server:

Production:

Component:
import { Trans, Plural, t } from '@lingui/macro';
<Alert>
<p>
<Trans>
Are you sure you want to delete <strong>{selectedRows.length}</strong>{' '}
<Plural value={selectedRows.length} one="reference" other="references" />
</Trans>
?
</p>
<p>
<strong>
<Trans>THIS OPERATION IS IRREVERSIBLE</Trans>!
</strong>
</p>
</Alert>
If I change the import order as suggested above, that is to import { Plural, Trans, t } from '@lingui/macro';
The local output is following:

The production:

I thought that maybe since @lingui/macro; is a dev-dependency, it's not installed during the production build, but if I import from @lingui/react'; then it stops rendering anything where <Trans> is used:

One may wonder, why dialog buttons have text labels then. For their labels I don't use <Trans>, but i18n._(t`Cancel`).
What can be the cause of such undesired behavior?
P.S. I am using ligui packages version 2.9.1 within create-react-app version 3.4.0.
Most helpful comment
Got same bug.
Had to set "few" and "many" props, then translations appeared. As I can see, empty (or not set) "few"\"many" prop doesn't result in fallback to "other" prop.