DOCSEARCHbyAlgolia
Submit Docs

inlang Documentation

repository·main·Indexed 23 days ago

https://github.com/opral/inlang

An open-format Translation Management System (TMS) that treats localization data as portable files. The ecosystem includes the @inlang/cli for project configuration and machine translation, Fink for visual message editing and QA, the inlang Marketplace for plugins and lint rules, and the Parrot Figma plugin for managing translations within design files.

Tokens
67.8K
Snippets
156
Records
392
Agent score
81%

What's inside inlang

  1. What is inlang?

    main

    inlang is an open-format Translation Management System (TMS) designed for software teams. It allows you to store translations in a vendor-neutral file format (a .inlang file, which is a SQLite database) so that developers, translators, CI/CD, and AI agents can all interact with the same localization source of truth.

    Key components:

    • .inlang file: The canonical single-file binary (SQLite) containing messages, variants, and locale data. For Git-based workflows, this can be represented in an unpacked format (a directory of plain files).
    • @inlang/sdk: The reference implementation for programmatically reading and writing .inlang projects.
    • Plugins: These handle compatibility by importing and exporting existing formats like JSON, ICU MessageFormat v1, i18next, and XLIFF.
    • Lix: Provides the underlying versioning, history, review, and rollback infrastructure.

  2. Overview of Fink

    main

    Fink is a tool designed to enhance the localization workflow. It provides capabilities for:

    • Visual Message Editing: Edit translation messages through a visual interface.
    • Version Control Collaboration: Facilitate team collaboration by leveraging version control systems.
    • Quality Assurance: Ensure translation quality by applying lint rules to message bundles.

  3. What is inlang and how to choose a path

    main

    inlang is an open format Translation Management System (TMS) that uses a vendor-neutral .inlang project as the single source of truth for localization data. This allows engineering, design, and translation teams to work on the same data using different tools.

    Choosing your path

    • Building an app runtime? Use Paraglide to compile from .inlang.
    • Giving translators a UI? Use Fink to edit .inlang without requiring Git.
    • Adding CI or automation? Use the CLI and SDK on the same project data.
    • Building an editor, migration, report, plugin, runtime, or AI agent? Use @inlang/sdk instead of inventing a custom i18n schema.
    • Keeping existing JSON, ICU, i18next, or XLIFF files? Connect them through plugins while .inlang remains the shared project model.

  5. Understand the inlang ecosystem components

    main

    The inlang ecosystem (v0.2+) is designed to decouple internationalization (i18n) from localization (l10n) through a set of specialized tools:

    • VS Code Extension: Enables developers to extract, view, and lint translation patterns directly within the IDE, eliminating manual copy-pasting.
    • CLI: Automates the synchronization between translation files in your source code and remote translation files used by non-technical team members.
    • Dashboard: A web-based interface for non-technical team members and translators to manage translations, including linting, without interacting with the source code.

    The architecture is agnostic, meaning it works independently of your chosen i18n library, framework, or programming language, provided you use the Fluent file format or have a compatible converter.

  6. Understand the inlang Tech Stack and Architecture

    main

    The inlang editor and website are built using a monolithic architecture designed for high development speed and future scalability. This approach allows the website and editor to be co-developed in a single codebase, which can later be unbundled into separate services (website, editor, and server) without changing routing or server logic.

    Core Tech Stack:

    • Framework: SolidJS (chosen for performance and decoupled reactivity).
    • Metaframework: Vite Plugin SSR (Vike) (enables mixed rendering modes: SPA for the editor and SSR for the website).
    • Design System: Tailwind CSS + Shoelace + Zag.js (provides styling, off-the-shelf components, and component logic).
    • Markdown: Markdoc (used for its simplicity, portability, and customizable validation).

  7. Git SDK Roadmap and Features

    main

    The Git SDK is designed to provide a high-level interface for repository interaction with the following core features:

    1. Standard Git commands for repository interaction.
    2. Lazy loading via fetch-pack filtering and promisor packfiles.
    3. File-based authentication built on the existing Git protocol.
    4. Advanced hooks and diffing via smudge, clean, and custom diff providers to support binary and structured files.
    5. Patch support to facilitate both patch/send-email and fork/PR workflows (including functionality to generate and apply patches).

  10. Use the t Function Matcher with Sherlock

    main

    The t Function Matcher plugin provides several features when used with the Sherlock VS Code extension:

    • Inline previews: View translations directly within your code editor.
    • Message extraction: Automatically extract hardcoded strings into translation messages.
    • Linting: Receive warnings for missing or invalid message references.

    Supported file types

    • TypeScript (.ts, .tsx)
    • JavaScript (.js, .jsx)
    • Svelte (.svelte)
    • Vue (.vue)
    • Astro (.astro)

  11. What is lix?

    main
    lix is a version control system designed to manage changes in various file formats (such as .csv, .inlang, music, video, etc.). Unlike Git, which is primarily optimized for source code, lix is built to handle change tracking, automation pipelines (CI/CD), and review systems for diverse data types, reducing the coordination effort required for globalization workflows.

  12. What is an unpacked project?

    main

    An unpacked project is a Git-friendly directory representation of the canonical .inlang binary file (which is a SQLite database). While the packed format is a single portable binary, the unpacked format allows translation changes to be diffable, mergeable, and reviewable in Pull Requests.

    Key distinction:

    • Packed (.inlang file): The canonical single binary file used for sharing, backups, and tools like Fink.
    • Unpacked (directory): A directory structure used for storing projects in Git repositories.

    In an unpacked project, settings.json is the primary file tracked by Git. Translation files (e.g., messages/en.json) typically live outside the project.inlang/ directory and are managed via plugins.