i18n._ does not format values in production build

[nmoinvaz]

Describe the bug
When using i18n._ with the second argument "values" those values are not inserted into the string in production build, but they are inserted into the string in development when running npm run start.

To Reproduce
I have created a sample repository that can be used to reproduce the problem:

https://github.com/nmoinvaz/lingui-values-bug

Relevant code file:
https://github.com/nmoinvaz/lingui-values-bug/blob/main/src/App.js

• npm install
• npm run start

In development the strings are properly replaced:

• npm build
• serve -s build

In production the strings are not properly replaced:

Expected behavior
The values object should be inserted into the string. For example {a} should be replaced with 1.

Additional context

• ling-ui version 3.9.0
• Create React App

[doender]

I've got the same issue using a custom webpack config

[AlexSCorey]

I have the same issue using CRA webpack config and marking strings with t`string`. I am using @lingui/macro 3.9.0 @semoal

[nakkamarra]

Looking at your example, this seems to be an issue that I've seen @tricoder42 answer before many times. The issue is essentially that, when the NODE_ENV=production, Lingui does not include a default formatter and AFAICT this is intentional, to keep the size of production builds small. However, it comes with the oft-reported-as-a-bug caveat that attempting to render something that doesn't exist in the catalog will result in an unformatted source string.

This brings us to your issue. Your example repo has neither the extracted catalog file nor the compiled catalog file (unless I'm missing something) and these files are critical to get this to work properly. If you lingui extract and lingui compile, and load the message catalogs your example should work properly.

[nmoinvaz]

I am not using catalogs with string extraction because in my use case the localization files are loaded dynamically.

[nakkamarra]

I am not using catalogs with string extraction because in my use case the localization files are loaded dynamically.

Ah, I see. I hadn't read that deep in. Cloning your repo and messing around a touch, and I can't get <Trans> or t to properly apply formatting either, something that I know for certain that the two do correctly in a production environment. This points moreso to something being broken in your project's setup than the library's API itself.

One thing I noticed is your example doesn't have a lingui config (ok, assuming the default config) but you also don't seem to have an instance of babel (I guess its coming from CRA?), or babel macros and if I had to guess, it's the absence of that last one that might be causing the issue.

[nmoinvaz]

I'm not so sure if it is due to lack of a package being installed because it does work in development mode. Another project I have does use additional babel plugins and it also has the same problem. I believe CRA does use babel.

[AlexSCorey]

@nmoinvaz I too think there is a packaging problem here. LingUI recently udpated to resolve a very similar issure in their development environments, and that was resolved via some packaging #1059

[nmoinvaz]

@AlexSCorey 3.9.0 version of LingUi does have that commit in it. So I downgraded LingUI to the version prior (before #1059) to see if that was the cause. I used the following command lines:

npm install @lingui/react@3.8.10
npm install @lingui/cli@3.8.10
npm install @lingui/macro@3.8.10

However, the problem is still present in 3.8.10.

UPDATE: I have also tried 3.10.2 and it also has the same issue.

[nmoinvaz]

Cloning your repo and messing around a touch, and I can't get or t to properly apply formatting either..

You are right, Trans with values parameter is not working in production builds either. I have updated my repo with to also show Trans not working.

I'm not using anything special, just create-react-app and lingui.

[semoal]

Hello guys, @AlexSCorey issue you mentioned was occurring in development environment when we replaced some Plurals' keys for example, we had to re-run extract, this is fixed since 3.9.0.

About your issue @nmoinvaz just cloning your repo right now, give a me a few minutes and I take a look.

In a fast look I already saw some issues with your repo:
1º No .linguirc, how do you plan to add locales mate?
2º No scripts for extracting and compiling
3º Lingui@core dependecy is not installed.

[nmoinvaz]

Thank you @semoal !

1. I don't use string extraction because I load all localization remotely/dynamically. I use i18n.load to load new localizations.
2. Same as above

[semoal]

That's the tick of the story ^^, are these localization remotely compiled?

[semoal]

If they aren't, basically with the structure when we run lingui compile, it won't work.

On 3.10 I've released a new tool called remoteLoader() which accepts a .json structure, .po string, .csv string, and under the hood compiles it to Lingui (basically ICU formats), in that way you can safely use i18n.load() with the messages returned from the remoteLoader function.

BUT, there are some issues i'm struggling with (node dependencies with babel that can't be released to front-end), I'll try to get it fixed today.

Here it is the pull request where I've introduced this feature(isn't ready to use yet): #1080

[nmoinvaz]

They aren't compiled. In my main application (not the repo), I am remotely loading json key/value pair files that have the localization id and the string value using fetch and passing it to i18n.load.

When using fetch I do some thing a bit differently for my use case:
The first URL that succeeds I use and load using i18n.load.

• myserver.com/locales/es-MX.json (language-country code)
• myserver.com/locales/es.json (language code only)
• myserver.com/locales/en-US.json (fallback if neither of the above work)
• myserver.com/locales/en.json (fallback if none of the above work)

But I would be happy to just get the my example repo working.

[nmoinvaz]

3º Lingui@core dependecy is not installed.

I tried with @lingui/core@3.10.2 but the issue still persists. .☹

[semoal]

I explained to you, why it fails in the previous comment. It won't work as simply .json because Lingui doesn't accept that, they need to be compiled.

I'm working on this feature (since someone requested it too), and this feature could be possibly just using the remoteLoader utility function

[nmoinvaz]

I see. I think I must have missed this comment in the docs for i18n.load. I suppose I saw the example and just went with it.

Formatting of messages as strings (e.g: "My name is {name}") works in development only, when messages are parsed on the fly. In production, however, messages must be compiled using compile command.

I will wait for the remoteLoader utility.

[semoal]

Production build with remoteLoader():

    const compiledMessages = remoteLoader({
      messages: {
        "abc": "{a} hello {b} world {c} goodbye",
        "xyz": "123"
      }
    })
    i18n.load("en", compiledMessages);

[semoal]

Polish some details and I'll release a new version with this new tool

[semoal]

Released with 3.10.3 with:

import { remoteLoader } from "@lingui/remote-loader"

Once I get free 10 minutes, I'll write a section in the documentation

[nmoinvaz]

It might be a good idea to update the example code for i18n.load located here https://lingui.js.org/ref/core.html to use remoteLoader. And then the warning below it can also be removed.

[nmoinvaz]

@semoal how long does it normally take npm to pick up the new release?

[semoal]

Hm, should be instant give it a try to 3.10.4, just released a fix about remoteLoader.
Should be already available

[nmoinvaz]

Figured it out, works like a charm in development and production builds! Thank you.

[jaisonjamesfs]

Figured it out, works like a charm in development and production builds! Thank you.

May I know how do you solve? Can you please explain a bit? We are having the same issue

[nmoinvaz]

I ended up using the remoteLoader to solve my issue. Lingui requires the localizations to be compiled and I was not compiling them because I was remotely loading them. So my problem ended up being I needed another mechanism to load the localizations after the app was already running.

I suppose I shouldn't have deleted my example repo in the description, but I can't raise it from the dead now..

[crazyyi]

I got the same issues using the @lingui/loader compiling the PO files. It only display keys in production build.
I am thinking using this remote-loader but it doesn't work with SSR.