Js-lingui: Catalog namespaces

[tricoder42]

I've been thinking about namespaces for a while and https://github.com/i18next/react-i18next/issues/199#issuecomment-281654374 made me to write it down.

Multiple namespaces

Sometimes are messages split in several message catalogs. Both catalogs might contain message with the same ID and it that case it would be overwritten without namespacing messages from different catalogs.

This feature already exists in most i18n libs.

Local namespaces

What's more interesting and what I actually would like to do are local namespaces. There're two possible use cases:

1. Reusable components
2. Code splitting

Reusable components

Imagine you have a React component and you want to ship translations with it. Ideally, developer using this component should just spin up it's own i18n provider to activate language, but the messages should be loaded directly from component. All translations inside this components should be tied to the component only.

lingui-cli should only extract messages from 3rd party components if it isn't translated in some language, otherwise it should ignore it

Code spliting

As we split the code, we should be able to split the message catalog. This should be fully automated: only messages in bundled code are added to the bundle.

[snegostup]

Catalog splitting is an absolutely necessary feature for any real world website or SPA. Is it planned to implement anytime soon?

[Photonios]

I have been thinking of a solution to catalog splitting for our rather large SPA. The approach I came up with assumes that you're using webpack.

During the webpack build, you know which message is where. Even better, webpack already understands the concept of code splitting.

One could develop a webpack loader that is chained to your other loaders that extracts all the messages in the file currently passing through the loader. All the messages would collected during this process would be aggregated into a structure that maps webpack chunks to a list of messages. For example:

messages = {
      'chunka.js': [
            'My test string',
            'Another string',
      ],
      'chunkb.js': [
           'String in another chunk',
      ]
};

At the end of the webpack build, a plugin would run that matches the messages extracted during the build against the translations stored in the catalog. Essentially, building a new catalog for each chunk, containing only the messages contained in that chunk.

Pros

No additional configuration would be needed for people already using webpack. They'd have to configure the special loader and plugin. These would extract the messages per chunk, or entry point (both are possible).

Cons

Does not work for people not using Webpack. This is solve-able. Lingui could ship with a tool that takes some special configuration, generates a webpack config, runs webpack with the loader and plugin and spits out splitted translations.

[saravanan10393]

@Photonios Is there plugin or loader your have mentioned available. I am in need of this feature. without this, i can not go further and use this project. Any help.

[tricoder42]

@snegostup I'm planning to work on it after I release jsLingui 3.0 next week. ETA late August

@Photonios That's exactly what I'm working on at the moment!

@saravanan10393 Sorry, it's not available right now. I'm working on it though and it should be available by the end of the month. Could you please share what's your use case? How do you use namespaces in your project?

TL;DR: I don't want to add namespaces to this project just for the sake of having it. Instead, I want to focus on solving problems which aren't solved in any i18n lib yet. Namespaces are just a byproduct of such effort.

I'm rushing to release 2.4, then cleanup the lib and add integration tests for CRA before releasing 3.0 (which is mostly ready, but there're few minor problems I need to solve). After that, I'll start coding working on this one. Stay tuned!

[saravanan10393]

@tricoder42 , My first concern for having namespaces is to having separate separate resource files per module ( to extend per bundle where one module can have multiple bundles since my app is growing large ) to make the translation process to different language easier and maintainable. Verifying JSON file with 2000 lines, will be harder than having 200 lines per bundle. Another advantage i am seeing is that faster page loading by reducing initial file size load by loading only translation content.

@tricoder42, So Can i proceed with believe that i will get this feature in the end of August.

[tricoder42]

@saravanan10393 end of August sounds reasonable, definitely mid September.

[chrischen]

Is catalog splitting planned for 3.0? Currently my app is setup to dynamically split based on components so bundle size never grows beyond the core libs, except for the js-lingui catalog, which will still grow as the app grows.

[tricoder42]

Closing in favor of #326 and #503. Both will land in v3.