Overview

In addition to the sections below, the source code is full of additional READMEs and one of the best recourses to understand the architecture behind inlang more in-depth.

Everything is a file

Inlangs architecture is designed to accomodate two different problem spaces with as much overlap as possible:

  1. Developer facing (source code) solutions.
    Developers are responsible for feeding translations into the software (i18n).

  2. Translation management (cloud) solutions.
    Translations need to be created and managed.

The first problem is inherently a file based problem. Whether translation files live in source code, or are fetched from an API: A data format (aka file) is needed to load translations into software. By building the translation management solutions to act on (parsed) files (as AST) instead of leveraging a classical relational database schema, the majority of code can be shared between those two problem spaces. Leading to synergy effects with each update.

Build on top of Fluent

Mozilla's recently released localization system Fluent is the best bet to standardize the localization process of software. In a nutshell, it's a dedicated system (syntax, file format etc.) soleley to express human languages. Nothing more, nothing less. By defining the scope of the system soleley to express human languages, it solves many edge cases and nuance problems with existing localization systems. For more in-depth information about Fluent, follow this link.

Support for file formats other than Fluent

While Fluent is great and we hope to uplift it to the standard localization format, a lot of software out there is using different translation file formats such as ICU. To accomdodate those software projects, and increase adoption of Fluent, inlang provides Fluent Syntax Converters (@inlang/fluent-syntax-converters).

💡

Only features that Fluent supports can be supported by converters. For example, Fluent only supports one nested layer of attributes i.e. an id with two layers named login.button.close won't work. See the Fluent syntax specification.

Open source

Inlang strives to foster an ecosystem around Fluent. To do so, inlang itself is open source and broken into smaller packages (see inlang/packages). We hope that those packages help developers extend the ecosystem and build solutions for their own needs.