Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not extracted messages get replaced with generated ids in the production build #1803

Closed
1 of 3 tasks
krzkaczor opened this issue Nov 16, 2023 · 2 comments
Closed
1 of 3 tasks

Comments

@krzkaczor
Copy link

Describe the bug
Not extracted messages get replaced with generated ids (ex. c1GOrp) but only in production builds.

To Reproduce
My lingui.config.ts:

import type { LinguiConfig } from '@lingui/conf'

const config: LinguiConfig = {
  locales: ['en-US', 'pl-PL'],
  catalogs: [
    {
      path: '<rootDir>/src/locales/{locale}',
      include: ['src'],
    },
  ],
  fallbackLocales: {
    default: 'en-US',
  },
  sourceLocale: 'en-US',
}

export default config

I can provide full repro code but it seems like I am obviously missing something.

Expected behavior
It should fallback to a string used in code == same behaviour as in dev mode.

Additional context
I would appreciate any guidance. Should we bail our CI if we detect that a developer forgot to run message extraction? should we maybe run extraction just before vite build to deal with untranslated strings automatically? Context: the app is under heavy development and missing translations are not a problem for us now.

I already played with fallback located and source locale but nothing seems to work. I am feeling like I am missing something obvious.

  • jsLingui version 4.5.0
  • Babel version npm list @babel/core
  • 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): VITE
"@lingui/core": "^4.5.0",
"@lingui/macro": "^4.5.0",
"@lingui/react": "^4.5.0",
"@lingui/cli": "^4.5.0",
"@lingui/conf": "^4.5.0",
"@lingui/swc-plugin": "^4.0.4",
"@lingui/vite-plugin": "^4.5.0",

vite.config.ts:

import path, { resolve } from 'path'
import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react-swc'
import { lingui } from '@lingui/vite-plugin'

export default defineConfig({
  plugins: [
    react({
      plugins: [['@lingui/swc-plugin', {}]],
    }),
    lingui(),
  ],
})
@timofei-iatsenko
Copy link
Collaborator

@krzkaczor hey, this is intentional design decision. During development (NODE_ENV==development) default messages included in bundle with a compiler. But for production build all non-essential properties and message compiler dropped. There is literally nothing to fallback to in production build.

The good solution would be to add an extract step just before running a production build in your CI pipeline.
I also recommend to use extract to template instead of normal extract.

Extract to template creating a "template" which you can then add to git ignore because it's an artifact produced from your code, such as sourcemaps. All cli tooling is aware of templates and will use it to fallback in case of message not found in original catalog.

I also recommend to use vite loader or webpack loader for catalogs to avoid explicit compilation step. So full solution would be:

  • Use vite plugin or webpack loader and load your ".po" catalogs directly, example
  • Add lingui extract-template just before build your application
    // package.json
        "build": "yarn extract-messages && next build",
        "extract-messages": "lingui extract-template",
  • Use any TMS you want to manage and merge translations. The mimimal requirement is to support ICU message syntax and PO format. We use crowdin and it works fine.
  • With lingui extract-template you load template file (for po-format it is template.pot) into TMS and download catalogs with translations (bunch of {lang}.po files). Even without TMS you can use POEditor desktop app to handle workflow with templates.

Note: As you see i also recommend to use Po format. I know that many developers in the beginning deciding to go with JSON because they think it would be easier to start with. But there are no advantages of json over PO files, because both of them you need to compile before use, but PO file will provide way better developer and translation experience than json.

@krzkaczor
Copy link
Author

@thekip Thank you for this detailed explanation. Helps a lot.

hey, this is intentional design decision. During development (NODE_ENV==development) default messages included in bundle with a compiler. But for production build all non-essential properties and message compiler dropped. There is literally nothing to fallback to in production build.

The good solution would be to add an extract step just before running a production build in your CI pipeline.
I also recommend to use extract to template instead of normal extract.

It would be great to mention this somewhere in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants