How to localize text unknown at compile time?

Problem: A lot of our application text (or keys, that’s irrelevant in this case) comes from a backend. For example, enum types. We’d like to localize those texts too, and we can’t use i18nMark because, as discussed at #177, this content is unknown at compile time.

Question: Is there a way to solve this problem using linguijs? Or plans to support this in the future?

Feature request: Given a fully automated solution seems unfeasible (beyond what was commented at https://github.com/lingui/js-lingui/issues/177#issuecomment-373749758), our current approach is to manually add entries (without an origin) to the catalogs. However, in this case lingui extract marks these entries as obsolete, so we risk deleting them whenever anyone runs lingui extract --clean. Is it even acceptable to manually modify the catalog? Would it be possible to support adding manual entries to the catalog?

[tricoder42]

I’m trying to say that my original proposal isn’t about loading locales, but only message definitions. No matter if messages are extracted from source files or remote API, first you always need just message definitions and then you create locale files by merging with existing catalogs. Yes, we could also add loading translations from API, but that’s another step.

In your case you would load message IDs and default values:

export default async function loadEnumsFromGraphQL() {
    await response
    return [
        {
            id: 'Episode.NEWHOPE',
            defaults: 'New Hope'
        }, {
            id: 'Episode.EMPIRE',,
            defaults: 'Empire Strikes Back'
        }, {
            id: 'Episode.JEDI',,
            defaults: 'Return of the Jedi'
        }, 
    ]
}

In gettext, the workflow was usually extract file with message definitions messages.pot (mind the pot extension) from source files and then generate locale files en.po, cs.po, etc.

My idea here is similar: query API for message definitions only, because then we can guarantee that each locale files have the same messages (and warn user about missing translations, etc).

Also if export of that file is supposed to be a catalog, how would you tackle asynchronous nature of it? It has to be able to return Promise and wait for it.

Reading from FS is synchronous at the moment, but we could change it to be async and then the messages from all sources would be loaded in parallel.

[tricoder42]

At the moment I’m implementing this RFC which improves localeDir config. I guess we could add support for a) static catalogs and b) catalogs loaded from scripts (e.g. query graphql backend)

Something like:

{
   "lingui": {
      "localeDir": {
         // messages.json extracted from source code
         "./locale/{locale}/messages": "./src/",

         // graphql.json loaded from script
         "./locale/{locale}/graphql": "!./scripts/loadGraphQLEnums.js",

         // static.json edited manually
         "./locale/{locale}/static": true,
      }
   }
}

Loading from script

Load message descriptors from local FS or remote API and export them. lingui extract will collect them and create a catalog for them, something like this:

const catalog = loadEnumsFromGraphQL()
// catalog = [
  {
    id: 'Episode.NEWHOPE',
  }, {
    id: 'Episode.EMPIRE',
  }, {
    id: 'Episode.JEDI',
  }, 
]

export default catalog

Generated graphql.json will look like this (depending on format, this is minimal json, where values are translations):

{
    "Episode.NEWHOPE": "",
    "Episode.EMPIRE": "",
    "Episode.JEDI": "",
}

Static files

These files are basically ignored in lingui extract, but messages from them are used in lingui compile.

---

What do you think?