i18n.md

render_macros

Internationalization

With built-in internationalization support, you can use ILC to run micro frontends on websites that require a multilingual presence. !!! warning "" Internationalization support is not comprehensive, though. You still need to provide i18n capabilities from the micro-frontends side.

Routing

ILC uses a 2-tier routing model:

1. ILC handles only global routing that determines what applications should be loaded at which URL.
2. Micro frontend has its own routing that determines components to be rendered.

1st tier: ILC

ILC allows you to handle localized URLs globally - make sure that the i18n.enabled parameter is enabled in the ILC Registry.

Currently, ILC supports two routing schemes:

• Prefixing all routes with locale except those of the default locale.
• Prefixing all routes with locale.

In the Registry, you continue specifying all routes without locale information.

2nd tier: Micro frontend

When dealing with internationalization in micro frontends, it is recommended to separate concerns as you don't want to hardcode localized links in the source code of every micro frontend.

Separation allows you to manage internationalization from a single place, and flexibly select localization patterns for your URLs.

Localization implies two processes:

1. Trimming actual location.href (to get locale) before passing the "normalized" URL to the application's router.
2. Localization of the URL before rendering into the DOM.

Both processes should be synchronized across all the applications and ILC. To do this, ILC provides IlcIntl class via App SDK that can be used at SSR and CSR.

Example: React with SSR

Synchronized language / currency change

Let's say the customer wants to change the locale or currency on the website. Usually, it's impossible to render an updated content immediately as localization files or updated prices should be loaded first.

If only the locale/currency change event is triggered, and every micro frontend would handle this event separately, the customer would likely see the blinking on the frontend as a result of re-rendering of parts of UI at different moments in time.

To prevent blinking, ILC uses prepare/execute pattern to synchronize re-rendering of all micro frontends.

Example

class Root extends React.Component {
    constructor(props) {
        super(props);

        this.state = { links: [] };

        // This is a root React component, so it receives appSdk as property from ILC.
        const lang = this.props.appSdk.intl.get().locale;
        import(`./links/${lang}.json`).then(v => {
            this.setState({links: v.default});
        });
    }

    componentDidMount() {
        this.props.appSdk.intl.onChange(
            (e) => import(`./links/${e.locale}.json`), // Prepare all necessary data
            (e, langModule) => { // Perform language change
                this.setState({links: langModule.default});
            }
        );
    }

    changeLocale(locale, e) {
        e.preventDefault();

        this.props.appSdk.intl.set({ locale });
    }

    render() {
        return (
            <div className='navbar-app'>
               {
                   this.state.links.map((link) => {
                       return (
                           <NavLink key={link.href}
                                    to={this.props.appSdk.intl.localizeUrl(link.href)}>
                               {link.name}
                           </NavLink>
                       )
                   })
               }

               <div className='lang-selector'>
                   <NativeListener onClick={this.changeLocale.bind(this, 'en-US')}>
                       <a href="#" style={{color: 'white'}}>EN</a>
                   </NativeListener>
                   /
                   <NativeListener onClick={this.changeLocale.bind(this, 'ua-UA')}>
                       <a href="#" style={{color: 'white'}}>UA</a>
                   </NativeListener>
               </div>
           </div>
        );
    }
}